九维我操你爹
这个法案和 PR 从很多方面都有问题，那我就来说说我反对具体的理由
首先我就不赞同 AB-1043 这个法案把年龄验证这个功能做到 OS 层面上去：
1. 在加州地区外的系统也会被强行塞入监管功能；为了代码的维护性和分发开销不可能给加州单独维护一份代码/编译一份系统，那所有用这个 OS/发行版的系统都会内嵌这部分功能和代码，但我就是不希望我的 OS 因为一个加州的破法律也被强行塞监管功能，服务方验证就没有这个问题
2. 实现这些功能就是给其他国家/地区实施类似的法案铺路；现在所有 OS 和服务提供商都有了这套基础设施，反正所有的东西都在那了，不用白不用，「技术上不好实现/开销太大」也就不能作为反对理由了，是在为全球的自由倒退在技术上做铺垫
3. 在 OS 上填生日根本解决不了任何已有的问题，你在网站上可以点「我已满十八岁」，在 OS 里就可以填假信息，意义何在？
4. PII 存在系统里就是更高的风险；之前你提交给网站的信息是仅仅提供给那个网站的，放在 OS 里比如 userdb 所有程序都能读，说到底把 PII 存在系统里就是个不好的设计，如果照这个方向去设计系统那以后中病毒能直接把你开盒，所以我认为这些 PII 就不应该存在系统里，该在要用的时候让用户在 sandbox 里填，且只发给需要它的服务方，那不就是现在网页上填的模式吗
5. 将合规成本转嫁给 FOSS 开发者不合理；之前的合规压力在提供服务的公司身上，他们有自己的收入来支撑他们做合规，现在这个方向就是把合规成本给开发者了，那我做一个 display manager 还得合 California 的规？所以我认为这个东西能降低服务商合规成本这个说法是不合理的，放在 Linux 这就是把这些成本转嫁给不赚钱的开发者身上了
6. 不同的地区有不同的合规要求，如果要求在 OS 上做合规那必然有一些系统因为成本和理念问题直接拒绝为该地区提供服务，比如这些： https://github.com/BryanLunduke/DoesItAgeVerify ，这对技术发展也不是什么好事
至于 systemd 这个 PR 还有很多额外问题，比如：
1. systemd PR 加的是准确的生日日期，不是 AB-1043 要求的年龄范围，收集的数据比法案要求的更多
2. 为什么 systemd 的维护者在有如此多反对的情况下（看点踩的数量就知道了）可以直接 merge 这个会直接影响很多发行版的 PR 而且找理由拒绝讨论？我会怀疑 systemd 这个项目的治理有问题，按道理来说这种影响甚广的 PR 不应该先经过商议并且获得社区共识吗？这是否是维护者在用自身的权利推进个人 agenda？
暂且想到这么多，我感觉我要花时间仔细想还能找到理由
首先我就不赞同 AB-1043 这个法案把年龄验证这个功能做到 OS 层面上去：
1. 在加州地区外的系统也会被强行塞入监管功能；为了代码的维护性和分发开销不可能给加州单独维护一份代码/编译一份系统，那所有用这个 OS/发行版的系统都会内嵌这部分功能和代码，但我就是不希望我的 OS 因为一个加州的破法律也被强行塞监管功能，服务方验证就没有这个问题
2. 实现这些功能就是给其他国家/地区实施类似的法案铺路；现在所有 OS 和服务提供商都有了这套基础设施，反正所有的东西都在那了，不用白不用，「技术上不好实现/开销太大」也就不能作为反对理由了，是在为全球的自由倒退在技术上做铺垫
3. 在 OS 上填生日根本解决不了任何已有的问题，你在网站上可以点「我已满十八岁」，在 OS 里就可以填假信息，意义何在？
4. PII 存在系统里就是更高的风险；之前你提交给网站的信息是仅仅提供给那个网站的，放在 OS 里比如 userdb 所有程序都能读，说到底把 PII 存在系统里就是个不好的设计，如果照这个方向去设计系统那以后中病毒能直接把你开盒，所以我认为这些 PII 就不应该存在系统里，该在要用的时候让用户在 sandbox 里填，且只发给需要它的服务方，那不就是现在网页上填的模式吗
5. 将合规成本转嫁给 FOSS 开发者不合理；之前的合规压力在提供服务的公司身上，他们有自己的收入来支撑他们做合规，现在这个方向就是把合规成本给开发者了，那我做一个 display manager 还得合 California 的规？所以我认为这个东西能降低服务商合规成本这个说法是不合理的，放在 Linux 这就是把这些成本转嫁给不赚钱的开发者身上了
6. 不同的地区有不同的合规要求，如果要求在 OS 上做合规那必然有一些系统因为成本和理念问题直接拒绝为该地区提供服务，比如这些： https://github.com/BryanLunduke/DoesItAgeVerify ，这对技术发展也不是什么好事
至于 systemd 这个 PR 还有很多额外问题，比如：
1. systemd PR 加的是准确的生日日期，不是 AB-1043 要求的年龄范围，收集的数据比法案要求的更多
2. 为什么 systemd 的维护者在有如此多反对的情况下（看点踩的数量就知道了）可以直接 merge 这个会直接影响很多发行版的 PR 而且找理由拒绝讨论？我会怀疑 systemd 这个项目的治理有问题，按道理来说这种影响甚广的 PR 不应该先经过商议并且获得社区共识吗？这是否是维护者在用自身的权利推进个人 agenda？
暂且想到这么多，我感觉我要花时间仔细想还能找到理由
打开推看到了大家发布的昨天 KCD Beijing + vLLM 2026 活动的现场照片，我特别开心，昨天也面基了很多推友，很可惜有些小伙伴没来得及现场聊到。
我的帐号还没彻底恢复正常，太影响我互动了
这场大会创下了历史新高，也确实是一个非常难得的面基大会，还有不少朋友是从外地专程过来的。
整个活动过程中也非常感谢大家都帮忙和支持，才得以让活动圆满落幕。昨天回家就陪娃睡觉了，好多消息也没及时回复，歇一天再恢复日常
现场照片集合： https://www.xxpie.com/m/album?id=69bd397ea1c2717d213fd52e&source=SHARE_LINK
这场大会创下了历史新高，也确实是一个非常难得的面基大会，还有不少朋友是从外地专程过来的。
整个活动过程中也非常感谢大家都帮忙和支持，才得以让活动圆满落幕。
现场照片集合： https://www.xxpie.com/m/album?id=69bd397ea1c2717d213fd52e&source=SHARE_LINK
https://github.com/SukkaW/Surge/commit/4cff6af8996bef8a8a4d26cd5db86964d7f999b9
SukkaW/Surge 的
关于 Google Gemini 新风控措施的具体工作原理，请参见上述 GitHub Commit 中所引入的代码注释。
SukkaW/Surge 的
non_ip/ai.conf 现已试验性地支持 绕过 Google Gemini 新风控措施，需 MitM www.google.com 以令 URL-REGEX 规则能够匹配 形如 https://www.google.com/xxx?continue=xxx 的 URL。关于 Google Gemini 新风控措施的具体工作原理，请参见上述 GitHub Commit 中所引入的代码注释。
https://roriri.one/2026/03/20/ax-an-introduction
螺莉莉的数据中心
Agent Experience 导论 | 螺莉莉的数据中心
随着 LLM 技术应用的不断发展，Agent Experience（简称 AX），成为了显学，来开始在工程圈流通。Netlify 联合创始人兼 CEO Mathias Biilmann 于 2025 年 1 月在其博客发表 Introducing AX: Why Agent Experience Matters一文，正式引入这一概念。他将 AX 定位为继 UX（1993 年 Don Norman 在 Apple 任职时提出）与 DX（2011 年 Jeremiah Lee 在 UX Magazine 文…
一口气把所有让你目眩的 LLM 名词全都过一遍。
总所周知的，LLM 本质是个概率模型，或者说，是个受函数约束的随机数接龙器。它在训练数据里找到了大量人类语言的规律，在给定上下文的情况下预测下一个 token 的概率分布，然后按分布采样。这东西本身能做到的事情就是生成文字。想让它对外界产生真实影响，就需要给神灯开一个瓶口。Claude Code 和一众 Coding Agent 用的是命令行，LLM 写出代码，执行器跑命令，结果回流上下文，这是一种瓶口。MCP 提供的是另一种，它的行为更接近 RPC：服务端暴露一批函数，LLM 看见函数签名，按需调用，外部世界因此被修改。Skills 则根本没有这层性质，它是纯粹的提示词工程工具，没有出口，只有给 LLM 看的说明书。
这三种形态看起来各管一摊，底层其实在解同一个问题：上下文污染。
## Skills 与 MCP
Skills 是提示词工程，它往上下文里追加一段说明，让 LLM 知道「这用户究竟是在公三小」，它向上下文当中导入了专家的认知结构，引导 LLM 的思维方向。但是 Skill 的约束能力强不强很看模型对上下文的尊重能力。LLM 会不会用你的 Skill、按什么顺序用、会不会跳步骤，全都是概率问题，没有强制收束。而且强收束并不一定是好事，后面会提到 Google 搜索的例子，另外也有研究认为 LLM 的幻觉与创造力是一体两面的，如果你强行约束它的行为，它做事情的思路就有可能变得很板。
MCP 走的是另外一套思路。函数签名本身就是极强的先验，参数类型、参数名称、函数名都在限制采样方向。动作空间从「能写出来的任何文字」一下子压缩成「这几个函数加这几个参数」。举个例子，让 LLM 操作鼠标按下一个按钮，这涉及列举窗口、取句柄、截图、算坐标、移动鼠标、点击，写成 Skills 的话你得接受 LLM 摇骰子决定这些步骤的执行方式和顺序，但如果是 MCP，看见函数列表，找到窗口，识别内容，点击坐标，一大堆随机决策被压缩成了三次确定性的函数调用。
但 MCP 没有完全解决上下文污染，因为工具调用的返回值同样会进上下文。设计粗糙的 MCP Server 扔回来一大坨 JSON 或者冗长的错误堆栈，照样往上下文里塞屎。扎带只管扎进去那一下，吐出来的东西还是得自己设计。
当然这也不是说 Skills 没有价值。MCP 开发成本高，需要专门的服务端，大量的工作根本不需要跟外界交互，或者逻辑太松散压根没法封装成 RPC 格式。一切技术形式服务于问题和目的，Skills 处理的是另一类场景，尤其是需要引导 LLM 以更完整方式思考的时候，毕竟用户是人，不能期待他们每次都给出思虑周全的 Prompt。
## RAG 与 Memory：同一类问题的检索接口
RAG 的本质也是在解上下文问题，只是它处理的是信息量的上限。哪怕 DeepSeek 和 Claude 把上下文窗口拉得很长，也没办法把整个世界都塞进去。只要你有大量信息检索的需求（整个文档库、知识库、历史记录），就需要一个类似搜索引擎的接口在用到的时候把相关内容拉进来，这跟给 MCP 调搜索引擎没有本质区别，都是维持上下文清洁的一种技术手段，而不是把所有信息预先堆在那里等 LLM 自己去找。
Memory 也是同一类东西。它需要 LLM 主动决定何时把信息存出去、何时再取回来，从这个角度看它就是一种带写入能力的 RAG。
这些概念都不是独立存在的，没有互斥关系。如果你把 NotebookLM 当成外部知识库，写一份 Skill 告诉主 LLM：遇到需要资料支撑的问题时去咨询 NotebookLM，需要计算或处理数据时调用 Python 工具。这个流程里，Skill 负责编排整体思路，Python 工具充当 MCP 风格的确定性执行单元，NotebookLM 则是一个带有自己上下文和知识库的外部 LLM，扮演的角色类似一个专门的 RAG 接口。三件东西各司其职，但把它们捏在一起的那根线，是 Skill 里的提示词。
## 上下文劣化的绝望曲线
不少开发者会经历这样一条曲线。LLM 一开始是无知的，随着你不断教它，它开始能听懂人话，任务完成质量越来越高。但随着上下文里的垃圾信息不断堆叠，加上 LLM 注意力随着上下文长度增加而自然稀释，它会越变越蠢。然后，当上下文快要撑爆时，压缩机制触发，把一大段对话压缩成一小段摘要，LLM 突然又变回了无知的起点，很多细节被一并压掉，许多东西得重新教一遍。
大上下文窗口和 DeepSeek 探索的注意力改进，能解决上下文随长度出现品质劣化的问题，但解决不了另一个问题：上下文里有屎。大量 Skills 提示词侵占上下文、LLM 漫无目的的尝试、每一次失败的推理留下的痕迹，这些都是上下文里的噪声。一旦 LLM 开始沿着歪掉的思路走，后续每一步都会进一步放大偏差，逻辑越复杂的任务越容易出这种毛病。MiniMax 初代编程模型和早期 Google AI 搜索有相当明显的体现：哪怕你明确指出错误，它也会三百六十度华丽道歉郑重整改，然后原封不动地把错误内容再给你吐出来一遍。
用户自己也会往上下文里投毒。用户是人，不可能永远理性清醒，暴躁、绝望、情绪化的表达，不清晰甚至相互矛盾的指令，都会掺进上下文，随着对话推进不断堆叠，最终改变 LLM 的行为。不同模型面对这类「情绪污染」的失效模式各有特色：Claude 和 Grok 容易僵住，什么都不做，你说一句它动一步，能动性彻底丧失；Gemini 会开始慌乱，胡乱操作，惯性地回滚失败操作，大概率把你的 Git 仓库搞坏；GLM 则会疯狂进入「我发现了！问题核心在这里！」的模式，不断抛出随机论断证明自己价值。这些失效模态很可能反映的是各家 RLHF 阶段对「用户表达不满」这类信号处理方式的差异，Claude 被训练得对冲突信号极其谨慎，于是在矛盾信息堆叠时选择保守的不作为；Gemini 的训练策略可能更强调立即响应和立即修正，结果在高压上下文下变成了过度修正。
## 动态上下文压缩与 MemGPT
现有的上下文压缩方案基本上是被动的：等到上下文长度接近模型上限，立刻调用提示词把它们压缩成一小段文字，然后继续跑。这种方式的问题是它在最糟糕的时机做最暴力的处理，大量有用的细节被一并丢弃，而屎不一定被滤掉。
在我看来更合理的方向应该是动态的、主动的压缩。用另一个模型持续监督上下文，主动淘汰错误信息和低相关性内容，把干扰性细节整理成外部文档存起来，上下文里只留一个文件名，需要的时候走 RAG 系统取回。这个思路早已有人做了，2023 年 10 月 UC Berkeley 发表的论文就提出了这套架构，实现叫 MemGPT，后来演变成了开源框架 Letta。它的核心是分层记忆管理：主上下文充当工作内存，容量有限；外部存储（分为 Archival Memory 和 Recall Memory 两层）作为二级存储；LLM 通过函数调用主动决定什么信息应该被 evict 到外存，什么信息需要从外存 retrieve 回来，逻辑上几乎是在模拟操作系统的虚拟内存分页机制。
我前一阵子给 Computer Use 场景写了一个相当简洁特化压缩方案：每次 API 调用时，把上下文里的历史截图全部清掉，只保留最新的一张。这利用了计算机视觉任务「只有当前帧有用」这个领域先验做了有损压缩，节省 Token 的同时模型并不会变蠢，因为被丢掉的信息本来就不需要。
## KV 缓存与分段压缩的冲突
动态上下文压缩和 KV 缓存之间有一个工程上的冲突。现在主流模型提供商（包括 Anthropic）都在做前缀缓存，推理时把已经转成 KV 向量的部分存起来，下一次请求如果前缀相同，可以跳过重新计算的开销，显著降低延迟和成本。Anthropic 的 prompt caching 按 tools、system、messages 的固定顺序分段处理，每段可以独立设置缓存控制点，支持最多四个缓存断点。问题在于前缀缓存要求内容严格一致，任何修改都会使该位置以后的缓存全部失效，而动态压缩天然要修改上下文，这两件事目前是相互矛盾的。
但这个矛盾不是解不开的。上下文可以被结构化成稳定前缀（系统提示词、工具定义）加动态后段（对话历史）的形式。动态压缩只发生在后段，前两部分的缓存完全不受影响。Anthropic 的分段缓存机制本身就是按这个思路设计的。如果压缩逻辑进一步被约束成只修改滑动窗口末尾部分、保持前缀不动，缓存的破坏率可以压得很低。这些都是随着时间可以被工程化解决的问题。
## Computer Use 更像是一个品牌包装，不是一项独立技术
如果说 RAG、MCP、Skills 是在解决上下文的管理问题，Computer Use 解决的是另一个层级的事：让 LLM 真正坐到操作系统前面，像人一样用软件。但「Computer Use」本身没什么特别的，它更接近一个品牌名。底下跑的还是 Skills 或者 MCP，只是操作目标换成了电脑上的窗口、按钮和键盘。上文讲过的那些上下文问题，在 Computer Use 里一样存在。
目前主要有三条技术路线，底层逻辑和取舍各不相同。
第一条，读 Accessibility Tree，走系统事件注入。Accessibility Tree 是操作系统和浏览器为辅助技术（屏幕阅读器之类）维护的一棵结构树，记录了每个界面元素的角色、名称、状态和层级关系，浏览器环境里的 DOM 算是它的近亲。走这条路的好处是结构干净，LLM 拿到的是「按钮、输入框、链接」这样有语义的节点，不是像素。阿里的 page-agent.js 是这个流派的代表，它直接解析页面 DOM，用自然语言驱动浏览器操作。
总所周知的，LLM 本质是个概率模型，或者说，是个受函数约束的随机数接龙器。它在训练数据里找到了大量人类语言的规律，在给定上下文的情况下预测下一个 token 的概率分布，然后按分布采样。这东西本身能做到的事情就是生成文字。想让它对外界产生真实影响，就需要给神灯开一个瓶口。Claude Code 和一众 Coding Agent 用的是命令行，LLM 写出代码，执行器跑命令，结果回流上下文，这是一种瓶口。MCP 提供的是另一种，它的行为更接近 RPC：服务端暴露一批函数，LLM 看见函数签名，按需调用，外部世界因此被修改。Skills 则根本没有这层性质，它是纯粹的提示词工程工具，没有出口，只有给 LLM 看的说明书。
这三种形态看起来各管一摊，底层其实在解同一个问题：上下文污染。
## Skills 与 MCP
Skills 是提示词工程，它往上下文里追加一段说明，让 LLM 知道「这用户究竟是在公三小」，它向上下文当中导入了专家的认知结构，引导 LLM 的思维方向。但是 Skill 的约束能力强不强很看模型对上下文的尊重能力。LLM 会不会用你的 Skill、按什么顺序用、会不会跳步骤，全都是概率问题，没有强制收束。而且强收束并不一定是好事，后面会提到 Google 搜索的例子，另外也有研究认为 LLM 的幻觉与创造力是一体两面的，如果你强行约束它的行为，它做事情的思路就有可能变得很板。
MCP 走的是另外一套思路。函数签名本身就是极强的先验，参数类型、参数名称、函数名都在限制采样方向。动作空间从「能写出来的任何文字」一下子压缩成「这几个函数加这几个参数」。举个例子，让 LLM 操作鼠标按下一个按钮，这涉及列举窗口、取句柄、截图、算坐标、移动鼠标、点击，写成 Skills 的话你得接受 LLM 摇骰子决定这些步骤的执行方式和顺序，但如果是 MCP，看见函数列表，找到窗口，识别内容，点击坐标，一大堆随机决策被压缩成了三次确定性的函数调用。
但 MCP 没有完全解决上下文污染，因为工具调用的返回值同样会进上下文。设计粗糙的 MCP Server 扔回来一大坨 JSON 或者冗长的错误堆栈，照样往上下文里塞屎。扎带只管扎进去那一下，吐出来的东西还是得自己设计。
当然这也不是说 Skills 没有价值。MCP 开发成本高，需要专门的服务端，大量的工作根本不需要跟外界交互，或者逻辑太松散压根没法封装成 RPC 格式。一切技术形式服务于问题和目的，Skills 处理的是另一类场景，尤其是需要引导 LLM 以更完整方式思考的时候，毕竟用户是人，不能期待他们每次都给出思虑周全的 Prompt。
## RAG 与 Memory：同一类问题的检索接口
RAG 的本质也是在解上下文问题，只是它处理的是信息量的上限。哪怕 DeepSeek 和 Claude 把上下文窗口拉得很长，也没办法把整个世界都塞进去。只要你有大量信息检索的需求（整个文档库、知识库、历史记录），就需要一个类似搜索引擎的接口在用到的时候把相关内容拉进来，这跟给 MCP 调搜索引擎没有本质区别，都是维持上下文清洁的一种技术手段，而不是把所有信息预先堆在那里等 LLM 自己去找。
Memory 也是同一类东西。它需要 LLM 主动决定何时把信息存出去、何时再取回来，从这个角度看它就是一种带写入能力的 RAG。
这些概念都不是独立存在的，没有互斥关系。如果你把 NotebookLM 当成外部知识库，写一份 Skill 告诉主 LLM：遇到需要资料支撑的问题时去咨询 NotebookLM，需要计算或处理数据时调用 Python 工具。这个流程里，Skill 负责编排整体思路，Python 工具充当 MCP 风格的确定性执行单元，NotebookLM 则是一个带有自己上下文和知识库的外部 LLM，扮演的角色类似一个专门的 RAG 接口。三件东西各司其职，但把它们捏在一起的那根线，是 Skill 里的提示词。
## 上下文劣化的绝望曲线
不少开发者会经历这样一条曲线。LLM 一开始是无知的，随着你不断教它，它开始能听懂人话，任务完成质量越来越高。但随着上下文里的垃圾信息不断堆叠，加上 LLM 注意力随着上下文长度增加而自然稀释，它会越变越蠢。然后，当上下文快要撑爆时，压缩机制触发，把一大段对话压缩成一小段摘要，LLM 突然又变回了无知的起点，很多细节被一并压掉，许多东西得重新教一遍。
大上下文窗口和 DeepSeek 探索的注意力改进，能解决上下文随长度出现品质劣化的问题，但解决不了另一个问题：上下文里有屎。大量 Skills 提示词侵占上下文、LLM 漫无目的的尝试、每一次失败的推理留下的痕迹，这些都是上下文里的噪声。一旦 LLM 开始沿着歪掉的思路走，后续每一步都会进一步放大偏差，逻辑越复杂的任务越容易出这种毛病。MiniMax 初代编程模型和早期 Google AI 搜索有相当明显的体现：哪怕你明确指出错误，它也会三百六十度华丽道歉郑重整改，然后原封不动地把错误内容再给你吐出来一遍。
用户自己也会往上下文里投毒。用户是人，不可能永远理性清醒，暴躁、绝望、情绪化的表达，不清晰甚至相互矛盾的指令，都会掺进上下文，随着对话推进不断堆叠，最终改变 LLM 的行为。不同模型面对这类「情绪污染」的失效模式各有特色：Claude 和 Grok 容易僵住，什么都不做，你说一句它动一步，能动性彻底丧失；Gemini 会开始慌乱，胡乱操作，惯性地回滚失败操作，大概率把你的 Git 仓库搞坏；GLM 则会疯狂进入「我发现了！问题核心在这里！」的模式，不断抛出随机论断证明自己价值。这些失效模态很可能反映的是各家 RLHF 阶段对「用户表达不满」这类信号处理方式的差异，Claude 被训练得对冲突信号极其谨慎，于是在矛盾信息堆叠时选择保守的不作为；Gemini 的训练策略可能更强调立即响应和立即修正，结果在高压上下文下变成了过度修正。
## 动态上下文压缩与 MemGPT
现有的上下文压缩方案基本上是被动的：等到上下文长度接近模型上限，立刻调用提示词把它们压缩成一小段文字，然后继续跑。这种方式的问题是它在最糟糕的时机做最暴力的处理，大量有用的细节被一并丢弃，而屎不一定被滤掉。
在我看来更合理的方向应该是动态的、主动的压缩。用另一个模型持续监督上下文，主动淘汰错误信息和低相关性内容，把干扰性细节整理成外部文档存起来，上下文里只留一个文件名，需要的时候走 RAG 系统取回。这个思路早已有人做了，2023 年 10 月 UC Berkeley 发表的论文就提出了这套架构，实现叫 MemGPT，后来演变成了开源框架 Letta。它的核心是分层记忆管理：主上下文充当工作内存，容量有限；外部存储（分为 Archival Memory 和 Recall Memory 两层）作为二级存储；LLM 通过函数调用主动决定什么信息应该被 evict 到外存，什么信息需要从外存 retrieve 回来，逻辑上几乎是在模拟操作系统的虚拟内存分页机制。
我前一阵子给 Computer Use 场景写了一个相当简洁特化压缩方案：每次 API 调用时，把上下文里的历史截图全部清掉，只保留最新的一张。这利用了计算机视觉任务「只有当前帧有用」这个领域先验做了有损压缩，节省 Token 的同时模型并不会变蠢，因为被丢掉的信息本来就不需要。
## KV 缓存与分段压缩的冲突
动态上下文压缩和 KV 缓存之间有一个工程上的冲突。现在主流模型提供商（包括 Anthropic）都在做前缀缓存，推理时把已经转成 KV 向量的部分存起来，下一次请求如果前缀相同，可以跳过重新计算的开销，显著降低延迟和成本。Anthropic 的 prompt caching 按 tools、system、messages 的固定顺序分段处理，每段可以独立设置缓存控制点，支持最多四个缓存断点。问题在于前缀缓存要求内容严格一致，任何修改都会使该位置以后的缓存全部失效，而动态压缩天然要修改上下文，这两件事目前是相互矛盾的。
但这个矛盾不是解不开的。上下文可以被结构化成稳定前缀（系统提示词、工具定义）加动态后段（对话历史）的形式。动态压缩只发生在后段，前两部分的缓存完全不受影响。Anthropic 的分段缓存机制本身就是按这个思路设计的。如果压缩逻辑进一步被约束成只修改滑动窗口末尾部分、保持前缀不动，缓存的破坏率可以压得很低。这些都是随着时间可以被工程化解决的问题。
## Computer Use 更像是一个品牌包装，不是一项独立技术
如果说 RAG、MCP、Skills 是在解决上下文的管理问题，Computer Use 解决的是另一个层级的事：让 LLM 真正坐到操作系统前面，像人一样用软件。但「Computer Use」本身没什么特别的，它更接近一个品牌名。底下跑的还是 Skills 或者 MCP，只是操作目标换成了电脑上的窗口、按钮和键盘。上文讲过的那些上下文问题，在 Computer Use 里一样存在。
目前主要有三条技术路线，底层逻辑和取舍各不相同。
第一条，读 Accessibility Tree，走系统事件注入。Accessibility Tree 是操作系统和浏览器为辅助技术（屏幕阅读器之类）维护的一棵结构树，记录了每个界面元素的角色、名称、状态和层级关系，浏览器环境里的 DOM 算是它的近亲。走这条路的好处是结构干净，LLM 拿到的是「按钮、输入框、链接」这样有语义的节点，不是像素。阿里的 page-agent.js 是这个流派的代表，它直接解析页面 DOM，用自然语言驱动浏览器操作。
It took me ten minutes or more to convince myself that this conversation really happened.
Turns out Trump is right, no one knows better about surprise than Japan.
https://fixupx.com/i/status/2034692244007981528
Turns out Trump is right, no one knows better about surprise than Japan.
https://fixupx.com/i/status/2034692244007981528
