Anthropic 推出 Claude Computer Use 开发者最佳实践指南

AI教程 2026-05-15 12:00:48 AI导航网

Anthropic 推出 Claude Computer Use 开发者最佳实践指南，涵盖截图预处理、模型选型到安全防御的完整方案。面向 Claude 4.6 家族与 Opus 4.7 模型，核心建议包括预缩截图至 1280×720 提升点击准确率、文字先于截图排序、以教学模式替代 Prompt 工程，同时集成三层注入防御与长对话上下文压缩策略，助力构建生产级 Agent 自动化系统。

分辨率与缩放

点击准确率是 Computer Use 集成的根基。若点击偏移，后续所有工作流都会失败。文章指出，影响最大的优化同时也是最简单的：在发送 API 前，预先将截图降采样。

API 内部处理限制

Claude 4.6 家族的 API 限制为：

长边最大 1568 像素
总像素最大 1.15MP
超出任一限制即被内部静默降采样

Opus 4.7 支持更高分辨率：

长边最大 2576 像素
总像素最大 3.75MP
超出限制同样会被静默降采样

核心问题

当截图超过 API 限制时，模型看到的是被压缩后的图像，返回的坐标也基于压缩后的尺寸，客户端 harness 仍按原始分辨率执行点击。坐标空间与模型感知的图像不匹配，是高分辨率下点击不准的首要原因。

推荐分辨率

通用默认：1280×720。使用约 80% 像素预算，在训练数据中常见，兼容性好。
Opus 4.7 推荐：1080p，在 token 消耗与性能间取得更好平衡。
最大化 API 适配：按原生宽高比计算最优分辨率，避免强制拉伸导致的比例失真。

需避免的分辨率

原生分辨率（未缩放）：除非碰巧低于限制，否则是点击不准的最常见原因。
过低分辨率（低于 960×540）：细节丢失过多，模型无法识别小 UI 元素。
macOS 注意：截图常带有 2x 设备像素比，1440p 屏幕实际输出 2880p，远超 API 上限。
4.6 家族避免 1920×1080 及以上：会超出像素限制被静默压缩；Opus 4.7 上限更高，1080p 和 1440p 在预算内，但仍需避免原生 4K 不缩放直接发送。

坐标缩放

发送前自行缩小截图后，模型返回的坐标基于发送时的 display_width_px / display_height_px，执行前必须按比例还原到真实屏幕坐标：

消息数组内容排序

构造消息 content 数组时，将文字指令放在截图之前。

推荐顺序：

content = [{"type": "text", "text": "Click on the Submit button"},{"type": "image", ...},]

不推荐顺序：

content = [{"type": "image", ...},{"type": "text", "text": "Click on the Submit button"},]

模型选择

基于 Anthropic 内部测试，不同模型各有所长：

Sonnet 4.6：机械点击精度最高，空间定位准，近距离失误少，对重度图片压缩的容忍度更好。适合大部分机械执行类任务，在准确率、推理和成本间取得最佳平衡。
Opus 4.7：推理能力更强，且点击精度已追上 Sonnet 4.6。加上分辨率预算更大（3.75MP vs 1.15MP），需要压缩的幅度更小。若任务既需推理又需精准点击，Opus 4.7 是目前最优解。
Haiku 4.5：延迟优先的选择，适合对速度要求极高的场景。

高级模式：指挥官模式（Orchestrator + Sub-agent）

复杂工作流中，可用一个推理能力强的模型（如 Opus）做”指挥官”负责规划和决策，再让 Sonnet 或 Haiku 执行具体点击操作，分工协作。

小目标处理

大按钮、输入框、标准菜单项，Claude 都能稳定点中。复选框、系统托盘图标、下拉箭头、小开关等微小元素，准确率会下滑。

原因：4K 屏幕（3840×2160）压缩到 720p 后，原本 16 像素的复选框大概只剩 5 个像素，难以精准命中。

解决方案

开启 Zoom：Claude 4.6 和 4.7 支持 zoom 能力，让模型先放大特定区域看清再点击。工具配置中加 “enable_zoom”: True。
放大目标：若 UI 可控，增大点击目标尺寸（降低系统 DPI、放大浏览器缩放、调整 UI 比例）对准确率有不成比例的提升。
键盘替代：对极小元素，Tab 导航或快捷键比鼠标点击更可靠。
考虑源分辨率：4K+ 显示器压缩到 720p 会丢失大量细节。若使用 4.6 模型，可尝试降低 DPI 或聚焦截图到相关屏幕区域；若用 Opus 4.7，更高分辨率预算可减少压缩需求。

思考力度（Thinking Effort）调优

Claude 支持自适应思考（adaptive thinking），通过 thinking 参数设置力度：low、medium、high、xhigh（仅 Opus 4.7）、max。

Opus 4.7

在 OSWorld Verified 基准测试中：

high 档准确率接近 max，输出 token 仅约一半。
low 档得分与 Opus 4.6 的 high/max 相近，token 用量约为 1/10。
max 档得分最高，token 成本显著增加。

提示注入防御

让 AI Agent 直接操作电脑，安全至关重要。Anthropic 的防御体系分三层：

第一层：训练免疫

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

第二层：实时分类器

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

使用官方 computer_20251124 工具类型时，提示注入分类器自动运行，与模型推理并行，零额外延迟，零额外成本。若自行实现工具而未用官方类型，则没有这层自动保护。

第三层：人类兜底（Human-in-the-loop）

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

长对话上下文管理

Computer Use 任务往往很长，每次截图消耗 1000–1800 token，200K 上下文窗口不到 100 张截图就满，1M 窗口同样吃紧。

第一层：缓存断点（Cache Breakpoints）

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

第二层：滚动缓冲（Rolling Buffer）

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

关键细节：采用批量替换而非逐张清理。默认保留最近 3 张（keep_n=3），每累积 25 张做一次清理（interval=25）。若逐张替换，对话前缀每轮变化会导致缓存失效；批量替换能让前缀在多轮内保持字节一致，维持缓存命中率。

第三层：LLM 压缩

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

压缩提示模板要求保留 8 类信息：用户完整指令（逐字保留所有”必须””不要””始终”等约束）、任务模板、约束规则、已执行操作、出错及修复记录、进度追踪、当前状态、下一步计划。

最关键原则：必须逐字保留所有用户指令。用户指令是最关键的元素，丢失会导致 Agent 偏离任务。

服务端自动压缩

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

教学模式

传统做法是用文字描述任务，但写起来费劲，模型理解也容易偏差。原文提出新思路：别告诉 Claude 怎么做，直接”示范”给它看。

录制阶段

用户手动执行一遍任务，系统录制每一步操作（点击坐标、输入内容、页面导航），每步配一张截图，截图上用蓝色圆圈标注点击位置。

回放阶段

Claude 收到完整操作示范：”第 1 步，点击费用类型下拉菜单”配标注截图，”第 2 步，选择差旅类型”配下一张截图……Claude 在当前真实环境中执行相同序列，但不会死板按坐标重放。若 UI 布局变化、按钮移位、菜单重排，Claude 会根据示范理解”要做什么”，在当前界面找到对应元素。

三种回放模式

严格模式：完全按步骤执行，UI 变化太大就停下来报告。适合合规敏感场景。
自适应模式：以示范为参考但灵活调整，应对轻微布局变化、按钮改名、菜单重排。推荐默认模式。
目标导向模式：只关注最终结果，录制步骤仅作参考。适合 UI 经常变但目标不变的场景。

顾问模式

Computer Use 大部分操作是机械性的（点击、输入、滚动），用 Sonnet 成本低速度快。但偶尔需要深度思考：该不该点这个按钮？信息不对怎么办？流程走错怎么回退？

做法：让 Sonnet 自行执行常规操作，在需要战略决策时调用 Opus 4.7 做顾问。Opus 做出决策后，交回 Sonnet 继续执行机械步骤，实现低成本与高智能的平衡。

无效优化（经内部测试未见效）

原文明确列出以下方法在内部评估中未产生一致提升：

将截图切分为小瓦片（quadrants/regions）分别发送。
在截图上叠加坐标网格帮助模型定位。
更换缩放算法（PIL LANCZOS、sips 等结果无差异）。

故障诊断速查表

原文提供系统化的诊断框架：

症状	可能原因	解决方法
点击系统性单向偏移	display 尺寸与实际发送图像不匹配；截图超 API 限制被静默压缩；消息数组图片在前	确保 display 尺寸与缩放后截图一致；预缩至 1280×720；文字先于图片
大致正确但偏离目标	目标极小；源图 4K+ 压缩过度；强制非原生比例	开 `enable_zoom`；降低 DPI 或裁剪区域；保持宽高比
完全点错元素	指令歧义；视觉相似元素；单步过于复杂	增加位置上下文；拆分为小步骤；补充页面布局描述
整体准确率差	截图超上限；4K+ 高分辨率源；分辨率过低	预缩放；Opus 4.7 减少压缩；尝试 1280×720 基线

特殊场景：某些下拉菜单可能调用系统级 UI，浏览器视口无法捕获——模型看似失败，实则是看不见菜单。此时应让模型改用 JavaScript 执行、键盘导航或直接 DOM 操作，非点击。

快速参考代码

指南提供可直接使用的 Python 代码模板，涵盖：

compute_max_api_fit()：基于原生宽高比计算最优 API 适配分辨率
prepare_screenshot()：缩放截图并转为 base64
scale_coordinates()：将 API 返回坐标还原为屏幕真实坐标

以及完整的 API 调用示例：从截图捕获、预缩放、消息构造（文字先于图片）、工具配置到坐标还原执行的完整流程。

总结

指南的核心工程逻辑可归纳为：预缩放截图消除坐标错位 → 文字先于截图优化理解 → 按场景选型（Sonnet 执行/Opus 推理）→ 小目标开 zoom 或键盘替代 → medium/high 思考力度最优 → 三层防御保安全 → 三层漏斗管上下文 → 录代替写降成本 → 顾问模式省 token。”预缩放截图”是投入产出比最高的单点优化，”教学模式”代表了从 Prompt Engineering 向 Demonstration Learning 演进的新范式。