Anthropic 发布 Computer Use 最佳实践

Anthropic 最新发布了一篇 Computer Use 的开发者最佳实践，从截图怎么传、模型怎么选、上下文怎么管，到怎么防提示注入，可以说是事无巨细全都给写出来了。

其中最为重要的一条建议是：想让 AI Agent 点得更准，请先把截图缩小。

缩小截图

对点击准确率影响最大的优化，同时也是最简单的一个，就是在发送给 API 之前，先把截图降采样。

原因很好理解。

Claude 的 API 内部，有一个图片分辨率上限。具体的，Claude 4.6 系列最大支持长边 1568 像素、总像素 1.15MP，Opus 4.7 则宽松一些，长边 2576 像素、总像素 3.75MP。

如果超过了这个限制会怎样呢？答案是 API 会自动帮你缩小图片。

但问题在于，模型看到的是缩小后的截图，返回的坐标也是基于缩小后的尺寸，而你的客户端还在用原始分辨率去执行点击。

坐标对不上了，显然……就不可能点对地儿了。

这正是高分辨率下点击不准的头号元凶。

知道了原因，解法自然也就不难：自己先把图片缩小，不要让 API 替你去缩。

Anthropic 推荐的起始分辨率是 1280×720，大约用掉 80% 的像素预算，训练数据里也常见这个尺寸，兼容性最好。如果用 Opus 4.7，则可以直接上 1080p.

不过缩完了之后要记得一件事：坐标要缩放回去。

模型返回的点击坐标是基于你发送的缩小尺寸，执行的时候得乘以缩放系数还原到屏幕真实坐标。参考代码如下：

●●●
scale_x = screen_w / display_w
scale_y = screen_h / display_h
screen_x = int(api_returned_x * scale_x)
screen_y = int(api_returned_y * scale_y)
└

这里还有个 macOS 的坑：macOS 的截图默认是 2 倍 DPI，一块 1440p 的屏幕截出来的图实际是 2880p，远远超出 API 上限。不处理的话，点击准确率会直接崩飞了。

先说再看

另外，在构造消息时，要记得把文字指令放在图片前面。

●●●
# 推荐：先文字后截图
content = [
    {"type": "text", "text": "点击提交按钮"},
    {"type": "image", ...},
]
└

原理在于，模型先读到「点击提交按钮」，再看截图，就知道该找什么了。如果先看图再看指令，模型还得回头重新理解图片，准确率会有所下降。

就像你让人在一堆文件里找某份合同，先告诉他找什么，比先把文件堆在面前再说要求，效率高得多。

也好比给人发微信时，最好不要莫名其妙的给对方发一张截图，然后再花 5 分钟打好字给发送过去……那这 5 分钟对面基本上，会处于蒙逼状态之中。

我的经验里，这么干的人真不在少数，我自己就真的从不会这样。

谁点得准

Anthropic 在内部测试中发现，不同模型各有所长：

Sonnet 4.6 的点击精度最高，空间定位准，近距离失误少，而且对图片压缩的容忍度也更好。适合大部分机械执行类任务。

Opus 4.7 的推理能力更强，而且点击精度已经追上了 Sonnet 4.6. 加上它的分辨率预算更大（3.75MP vs 1.15MP），需要压缩的幅度也更小。如果任务既需要推理又需要精准点击，Opus 4.7 是目前的最优解。

Haiku 4.5 则是延迟优先的选择，适合对速度要求极高的场景。

对于复杂工作流，这里还有一个高级模式：用一个推理能力强的模型做「指挥官」负责规划和决策，再让 Sonnet 或 Haiku 去执行具体的点击操作。分工协作，各司其职。

目标太小怎么办

大按钮、输入框、标准菜单项，这些 Claude 都能稳定点中。

但换成复选框、系统托盘图标、下拉箭头、小开关这些元素……准确率就开始下滑了。

原因也不难理解，一张 4K 屏幕（3840×2160）压缩到 720p 之后，原本 16 像素的复选框大概只剩下 5 个像素。

而一个 5 像素的目标，换谁来点都有点够呛啊……

Anthropic 给了几个解法：

• 开 zoom：Claude 4.6 和 4.7 都支持一个 zoom 能力，能让模型先放大某个区域看清楚再点击。工具配置里加个 "enable_zoom": True 就行 

• 把目标放大：如果 UI 是你自己控制的，把点击目标稍微做大一点，对准确率的提升是不成比例的。降低系统 DPI、放大浏览器缩放、调整 UI 比例，都可以 

• 用键盘替代：对特别小的元素，Tab 导航或快捷键的方式，会比鼠标点击靠谱得多 

思考强度

Claude 的 Computer Use 支持配置「思考力度」（thinking effort），从 low 到 max 几个档位。

Anthropic 做了测试对比后，建议的结论如下：

Opus 4.7 推荐用「high」。

在 OSWorld 基准测试中，high effort 的准确率接近 max，但 token 消耗只有 max 的一半左右。low effort 也不差，token 用量和 Opus 4.6 的 high/max 差不多，但 OSWorld 得分反而更好。

Claude 4.6 系列 推荐用「medium」。

测试显示 medium 的任务成功率已经接近最高值，再往上加就是花大钱听个响了……low effort 也比关闭思考要好，因为减少了出错和重试的次数，实际消耗的 token 反而更少。

至于 max effort？Anthropic 说的是：不推荐在 Computer Use 中使用 max effort。测试中它比 high 没有任何准确率提升，只会增加 token 成本。

就好像你请了个很厉害的顾问，给他 30 分钟和给他 3 小时，产出其实差不多，但账单差了一倍。

杀鸡上大炮了有点……

提示注入

让 AI agent 直接操作电脑，自然绕不开安全的问题。Anthropic 的防御体系分为三层：

训练层面，模型在训练时就接触过大量含有注入内容的网页和应用界面，通过强化学习学会了识别和拒绝恶意指令。

实时分类器，在每次请求时并行扫描进入 Claude 上下文的内容，检测文本中隐藏的指令、图片中嵌入的指令、以及试图欺骗 agent 的伪造 UI 元素。

持续红队测试，安全研究人员不断试探防线，Anthropic 还参与外部对抗评估来检验防御效果。

用官方的 computer_20251124 工具类型时，提示注入分类器会自动运行，和模型推理并行，零额外延迟，零额外成本。

不过如果你自己实现了一套工具而没用官方类型，就没有这层自动保护了。

而最有效的防御其实是 human-in-the-loop：在执行不可逆操作（提交表单、付款、发消息、改数据）之前，让 agent 暂停，请用户确认。

关键时刻让人过一眼，还是非常的必要和管用。

长对话处理

Computer Use 的任务往往很长很长，比如填一张表可能要点几十次，做一套流程可能要上百个来回。每次截图消耗 1000 到 1800 个 token，200K 的上下文窗口，不到 100 张截图就满了，就是 1M 的窗口也一样不太够造啊……

Anthropic 给了一个三层上下文管理策略。

第一层：缓存断点。

API 支持最多 4 个缓存断点。推荐的做法是：1 个放在系统提示和工具定义上（这些每次都一样），另外 3 个放在最新的 tool_result 上，每轮清除旧标记、放置新标记。这样 API 就不会每次都重新处理整个对话前缀。

第二层：滚动缓冲。

只保留最近 N 张截图的完整数据，更早的截图替换成文字占位符 [Image omitted]。

这里还有个细节，替换采用的是批量替换，并非逐张清理。默认配置是保留最近 3 张截图（keep_n=3），每累积 25 张才做一次清理（interval=25）。

为什么要这样呢？因为如果每张都替换，对话前缀每一轮都在变，缓存就失效了。批量替换能让前缀在连续多轮里保持字节一致，缓存命中率才能上去。

第三层：LLM 压缩。

当对话长到滚动缓冲也兜不住的时候，用模型本身来总结对话历史，然后丢掉原始内容。

博客指南中给了一个详细的压缩提示模板，要求保留 8 类信息：

用户的完整指令（逐字保留所有「必须」「不要」「始终」这类约束）、任务模板、约束规则、已执行的操作、出错及修复记录、进度追踪、当前状态，以及下一步要做什么。

其中最关键的一条是：

“ 必须逐字保留所有用户指令。用户指令是最关键的元素，丢了的话 agent 就会偏离任务。

而这套三层方案，现在也有了服务端自动版本。

在 API 请求里加上 context_management 参数和 compact-2026-01-12 beta 标识，服务端会在输入 token 达到阈值时自动触发压缩。客户端要做的只是在收到压缩响应后，把本地消息数组也截断到相同位置，保持缓存对齐。

教学模式

这应该是整篇指南里，算最有意思的部分了。

传统做法是用文字描述任务：「打开 XX 页面，找到 YY 按钮，点击，然后在 ZZ 输入框里填 123……」人写起来非常的费劲，模型理解起来也容易出偏差，然后你就开始了漫长的 prompt 调试。

指南中提出了一个新思路：别告诉 Claude 怎么做，直接「示范」给它看。

具体的做法是：用户先手动执行一遍任务，系统录制每一步操作，包括点击坐标、输入内容、页面导航，每步都配一张截图，截图上用蓝色圆圈标注了用户点击的位置。

回放的时候，Claude 收到的是完整的操作示范：「第 1 步，点击费用类型下拉菜单」配一张标注了蓝圈的截图，「第 2 步，选择差旅类型」配下一张截图……Claude 看着这些示范，在当前真实环境里执行相同的操作序列。

但它并不会死板地按坐标重放。如果 UI 布局变了、按钮移了位置、菜单重新排列了，Claude 会根据示范理解「要做什么」，然后在当前界面上找到对应的元素。

Anthropic 设计了三种回放模式：

• 严格模式：完全按步骤执行，UI 变化太大就停下来报告。适合合规敏感的场景 

• 自适应模式：以示范为参考但灵活调整，能应对轻微的布局变化、按钮改名、菜单重排。这是推荐的默认模式 

• 目标导向模式：只关注最终结果，录制的步骤只是参考，不是必须遵循的指令。适合 UI 经常变但目标不变的场景 

回顾我们在工作中的「师傅带徒弟」的方式，也同样如此：

“ 先看我做一遍，然后你自己来，遇到意外情况的话……你就灵活处理。

顾问模式

Computer Use 的大部分操作是机械性的：点这里、输入那个、滚动、点下一步。用 Sonnet 就够了，成本低速度快。

但偶尔也会碰到需要深度思考的地方：该不该点这个按钮？表单填到一半发现信息不对怎么办？流程走错了怎么回退？

这里有个 Advisor 的做法是，让 Sonnet 先自行做执行，在需要战略决策的时候去调用 Opus 4.7 做顾问。

●●●
tools=[
    {
        "type": "advisor_20260301",
        "name": "advisor",
        "model": "claude-opus-4-7",
    },
    {
        "type": "computer_20251124",
        "name": "computer",
        "display_width_px": 1280,
        "display_height_px": 720,
    },
]
└

整个咨询过程在服务端一次请求内完成，不需要额外的客户端往返。大部分 token 按 Sonnet 的价格走，只有咨询 Opus 的那几次按 Opus 计费。

不过有个小问题是，在长对话中，Sonnet 容易忘记自己有个顾问可以用。Anthropic 建议每隔 20 轮左右，在上下文里轻轻提醒一下「记得你还有 advisor 工具可以用」。

就像新员工入职后，得偶尔提醒他：

“ 有问题可以问你 mentor 啊，别啥啥自己硬扛啊。

◇ ◆ ◇

博客中的所有代码示例都可以直接拿来用，从截图预处理到坐标缩放、从缓存管理到压缩提示模板，Anthropic 给了一套开箱即用的 Python 参考实现。

从分辨率怎么调、坐标怎么算，到长对话怎么管、安全怎么防，再到「教学模式」这样的新范式，每一层都给了完整的工程方案。

别的不说，A 厂在技术实践的分享方面，还是非常的大方。