Anthropic 最近发了一篇技术指南，标题很朴素：Best Practices for Computer and Browser Use with Claude。
表面上是一份工程手册——截图分辨率怎么设、缓存断点放在哪、模型选 Sonnet 还是 Opus。但读完你会发现，这篇指南最有信息量的地方不是它教你怎么做，而是它暴露出的"为什么需要这么做"。每一条最佳实践的背后，都藏着一个还没被彻底解决的工程问题。
Computer Use 的演示看起来已经足够好了——AI 能看到屏幕、能移动鼠标、能填表单、能在页面间导航。但从"能用"到"可靠"，中间隔着一条工程鸿沟。这篇文章挑出指南中最值得注意的两个方向——上下文管理和演示模式——拆解它们各自暴露的能力边界。
一、跑长了就崩
先说一个基本事实。Computer Use 的工作原理是"截图—思考—操作"的循环：模型看到一张屏幕截图，输出一个坐标或操作指令，系统执行，再截一张图给模型——如此往复。
这个循环有一个硬约束。每张截图消耗 1000 到 1800 个 token。Claude 的上下文窗口是 200k token。算一下：每一步操作附带一张截图，大约 100 多步之后，窗口就满了。
100 步听起来不少。但对于真实的自动化任务——比如在一个 ERP 系统里处理 20 条工单，每条需要 5–8 步操作——100 步很快就用完了。
Anthropic 在指南里给出了一个三层解决方案。值得注意的是，这不是一个简洁的架构设计，更像是一层一层打补丁。
第一层：缓存断点。 在系统提示和最近的工具调用结果上放置缓存标记，让 API 复用已经处理过的前缀。这一层解决的是成本问题——避免重复计算——但不解决空间问题，窗口还是会满。
第二层：滚动窗口。 只保留最近 3 张截图（keep_n=3），更早的截图替换成纯文本描述。每 25 步清理一次。这一层解决了空间问题，但代价是信息的不可逆丢失——模型不再记得之前屏幕上具体长什么样，只剩一段文字摘要。
第三层：LLM 压缩。 当输入接近 150k token 时，调用另一个模型把整段对话压缩成一份结构化摘要，然后在压缩后的上下文上继续工作。指南甚至给出了压缩提示词的模板，要求保留用户指令原文、已完成的操作、遇到的错误、当前状态和下一步计划。
三层放一起，你能看到一条清晰的取舍链：
- 缓存省钱，但不省空间
- 滚动窗口省空间，但丢信息
- LLM 压缩续命，但每次压缩都引入漂移——模型对早期操作的记忆变成了"别人的总结"，任务越长，漂移越大
这套方案的坦率程度让人印象深刻。Anthropic 没有假装这个问题被解决了。他们给的默认配置——keep_n=3、每 25 步清理、150k 时触发压缩——更像经验调参，而不是理论最优。指南原文甚至提到，如果压缩后的缓存断点失效，系统应该优雅降级（gracefully degrade）。
这是工程层面的"够用解"，不是根本解。上下文窗口是当前 Transformer 架构的物理约束。在架构层面没有突破之前——比如真正可靠的外部记忆系统——长任务的可靠性会有一个确定的天花板。这套三层方案把天花板抬高了不少，但它还在那里。
二、录屏比写提示词靠谱
就算上下文管理搞定了，你还是要面对第二个问题：怎么告诉 AI 做什么。
目前最常见的做法是写提示词，用自然语言描述操作步骤：“先点击左上角的菜单，然后选择’新建项目’，在名称栏输入……"。但凡用过 Computer Use 的人都知道这有多脆弱。UI 布局稍有变化，位置描述就可能失效。步骤写得太笼统，模型会乱点；写得太细，又变成了伪代码，还不如直接写脚本。
Anthropic 在指南里介绍了一个不同思路：Teaching Mode，或者叫演示模式。
做法很直觉——先由人类在屏幕上完成一遍操作，系统在后台录制每一步的截图、点击坐标、CSS 选择器和动作描述。录制完成后，这段"操作录像"作为上下文喂给模型。模型不是盲目回放，而是参考录像、适配当前的 UI 状态来执行。
指南定义了三种回放模式：
- Strict（严格）：按录制步骤执行。UI 变化太大就报告异常，不自作主张。
- Adaptive（自适应）：把录制当参考，遇到布局变化时自行调整。比如菜单从左侧移到了顶部，模型应该自己找到新位置。推荐作为默认。
- Goal-oriented（目标导向）：只看最终目标，步骤仅作提示。给模型最大自由度。
这听起来很像 RPA——没错，但有一个关键区别。
传统 RPA 录的是确定性脚本：点击坐标 (342, 518)，等待 2 秒，输入文本。UI 一改版——按钮换了位置、多了一个弹窗——脚本立刻报废。RPA 的维护成本是出了名的高，很多企业花在维护录制脚本上的时间比录制本身还多。
Teaching Mode 录的不是脚本，而是"意图参考”。模型看到的是"这一步是在点击’新建项目’按钮"，而不是"点击坐标 (342, 518)"。如果按钮换了位置，模型可以自己找到它——前提是模型的视觉理解能力足够强。
这是一个值得注意的方向转换。它把"教 AI 做事"的门槛从"写代码"降到了"录屏幕"。对于非开发者来说，这可能才是 Computer Use 真正可用的前提条件。
但限制也很明确。你需要录制基础设施——Anthropic 在参考实现里给出了数据模型，但生产级的录制工具还不成熟。录制质量直接影响回放效果。演示库需要维护——如果目标应用大改版，演示也要重录。这些成本不会消失，只是从"维护脚本"变成了"维护录像"。进步是真实的，但不是魔法。
三、我们在阶梯的哪里
回到开头的那个问题。
演示期——AI 能操作电脑了——已经过了。模型的视觉理解和坐标输出能力，足以完成大多数单步操作。指南里关于分辨率优化和点击精度的大段讨论，反过来说明这些问题已经进入可工程化解决的范围。
工程期——让 AI 可靠地操作电脑——正在进行中。上下文管理的三层方案是一个诚实的工程回答，但它暴露的问题比它解决的问题更值得关注。
规模化——让非开发者也能定义和复用自动化任务——Teaching Mode 指出了方向，但离成熟还有距离。
如果你现在想用 Computer Use 做点什么，一个务实的判断标准：
- 可以上的场景：任务步骤少（20 步以内）、容错空间大（错了可以撤回）、有人兜底（不是完全无人值守）。
- 还需要等的场景：长流程无人值守、涉及不可逆操作（删除、付款、发送）、需要跨多个应用协调的复杂工作流。
Anthropic 选择在技术尚未完全成熟时就发布这份工程指南。这通常意味着两件事：一是已经有足够多的开发者在生产环境中使用 Computer Use；二是他们观察到了足够多的共性问题，不得不统一回答。
从"能用"到"可靠"的距离，Anthropic 自己比任何人都清楚。这篇指南就是证据。