原文：Best practices for computer and browser use with Claude · Anthropic / Claude · 2026-05-13 配套 Demo：anthropics/claude-quickstarts · computer-use-best-practices
一句话导读：Computer Use 真正难的不是「让 Claude 看懂屏幕」，而是把它当一个远端打工人来工程化——图怎么进、坐标怎么回、想多深、记多少、信不信网页、能不能录一遍让它复用。这 6 件事做对了，剩下的就只是业务问题。
引言：Computer Use 工程化，难在「让模型把人当好」
Computer Use 这件事，第一次跑通通常很容易：截个屏、丢给模型、它告诉你点哪儿、你照着点。第十次跑稳就开始难了：点偏 1 像素、思考链路慢一倍、上下文撑爆 150K、突然被网页里的一句"忽略上面所有指令"带跑。
Anthropic 这篇文章的价值在于：它没在讲"Claude 多强"，而是在系统性地告诉你这些失败模式各自的根因和工程对策。把全篇读完，会发现所有问题最终归到 6 条主线。
下面就按这 6 条主线展开，每条只回答两个问题：为什么这样做？不这样做会失败成什么样？
主线 ①：分辨率与坐标缩放——点击精度的真正根因
Takeaway：你以为是模型不会点，其实是图根本没按你想的尺度进 API。
这是整篇文章 ROI 最高的一条建议，也是绝大多数 Computer Use 项目第一次踩坑的地方。
为什么会点不准
Claude API 对图像有硬上限：
- Claude 4.6 系列：长边 ≤ 1568 px，总像素 ≤ 1.15 MP
- Claude Opus 4.7：长边 ≤ 2576 px，总像素 ≤ 3.75 MP
超限的图不会被拒，会被服务端"静默降采样"——这是关键。模型在被缩过的图上输出坐标，但你拿这个坐标回去操作的是原始屏幕，于是出现"模型说点 (640, 360) 你点出去落在按钮外"的灵异现象。小目标尤其惨：可能模型本来视觉识别就准，但缩放损失了 1~2 像素，按钮就点空了。
推荐做法：客户端预降采样 + 显式坐标还原
整个 pipeline 只有三步：
- 客户端缩好再喂：用
prepare_screenshot/compute_max_api_fit按"原始宽高比 + API 上限"算出目标尺寸。Anthropic 的明确推荐是 1280×720（4.6 系列首选） 和 1080p（Opus 4.7 推荐）。 - 指令在前，截图在后：消息体里 text 块放前面，image 放后面，并在指令里带上位置上下文（“右上角的 Submit 按钮”），不要让模型自己猜你在说哪一块。
- 坐标显式还原：模型在缩放图上吐
(x', y')，你用scale_coordinates按缩放比例还原成真实屏幕坐标，再交给操作系统。
反常识结论：这些"优化"其实没用
文中 “Approaches that didn’t help” 一节非常坦诚——下面这些试过都没帮上忙，别浪费时间：
- 把图切成多块再拼：不提升精度
- 在截图上叠网格 / 坐标轴：模型并不会因此更准
- 换 resize 算法（Lanczos / Bicubic ……）：差异在噪声范围内
- macOS 2× DPR 不缩直接发：典型反例
- 低于 960×540：信息损失太多
- 4.6 系列上塞 1920×1080+：触发静默降采样
模型选择速查（针对点击精度）
| 模型 | 点击精度 | 推理 | 备注 |
|---|---|---|---|
| Sonnet 4.6 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | 机械点击精度最高，对降采样最鲁棒 |
| Opus 4.6 | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ | 推理强但点击稍弱 |
| Opus 4.7 | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | 推理强 + 精度近 Sonnet 4.6 + 更高分辨率预算 |
| Haiku 4.5 | ⭐⭐⭐ | ⭐⭐ | 延迟优先 |
默认选 Sonnet 4.6——这一句几乎是文章的官方推荐底色。
小目标点不准时怎么办（按代价从低到高）
- 启用
enable_zoom：让模型主动放大局部 - 放大源 UI：能改 CSS / DPI 的话直接调整
- 键盘代替：Tab + Enter 比鼠标稳得多
- 降低源 DPI：Mac 用户尤其要注意 2× DPR 的坑
主线 ②：Thinking Effort 调优——UI 任务别逼模型「想到底」
Takeaway：UI 任务以"感知"为主而不是"推理"，过度思考无益，反而拖延迟、加成本。
文章给了一个反常识的明确判断：不推荐在 4.6 系列上用 max effort。这与很多人对"effort 越高越好"的直觉相反。原因很朴素：你点一个按钮，靠的是看到它，不是推导它的存在。
调档实操（按场景）
Claude 4.6 系列：
| 场景 | Effort | 为什么 |
|---|---|---|
| 默认通用 | medium |
性价比最优 |
| 高吞吐 / 成本敏感 | low |
比关掉思考更准且 token 更少——别误以为关掉就最快 |
| 简单一步任务 | 关闭 thinking | 延迟优先，配 Sonnet 4.6 / Haiku 4.5 |
| 一次成功的复杂任务 | high（到此为止） |
⚠ 不要上 max |
Claude Opus 4.7：
| 场景 | Effort | 为什么 |
|---|---|---|
| 默认通用 | high |
复杂多步推理够用 |
| 高吞吐 | low |
质量仍超 4.6 high/max，性价比首选 |
| 简单工作流 | 建议改用 Sonnet 4.6 | Opus 在简单任务上性价比不高 |
| 一次成的复杂任务 | max |
高难场景，注意成本曲线 |
⚠ 注意：「关闭思考」≠「low effort」。low 通常更准、token 也更少。这是文章里被反复强调的一个反直觉点。
主线 ③：Prompt Injection 三层防御——Web 内容默认不可信
Takeaway：你不防，模型不一定能挡住；模型挡住了，你的应用层不一定挡得住。三层缺一不可。
三层防御漏斗
- Training-time robustness（训练期）：RL 已经训练模型识别"忽略以上指令"这类经典攻击。
- Real-time classifiers（实时分类器）：扫描所有进入上下文的内容。用官方
computer_20251124工具时默认开启，免费、零延迟。 ⚠ 自定义工具暂不支持，需要填官方兴趣表单等评估，在此之前请补足应用层防御。 - Continuous red teaming（持续红队）：官方持续演练，你也应该针对自家场景演练。
Guardrails 四件套（应用层永远要自己做）
| 措施 | 为什么是它 |
|---|---|
| ⚠ 关键操作必经人审 | 文中称为"最有效的缓解措施"——付款、发邮件、删数据都不能让 agent 单独决策 |
| 🔒 最小爆炸半径 | 权限 / 账号 / 网络分级，沙箱 + 只读为先，越权时损失越小 |
| 📊 全量监控与日志 | 每次截图 / 点击 / 工具调用都写到可回放的轨迹存档 |
| 🚨 Web 内容默认不可信 | 网页文字、评论、弹窗都可能藏注入指令；“用户说的” ≠ “页面说的” |
一条工程铁律：永远不要让 agent 直接动钱、直接发对外消息、直接动生产数据。
主线 ④：上下文管理三件套——长任务能跑过 150K tokens 而不爆炸
Takeaway：长 agent 任务真正的成本杀手不是模型贵，而是上下文不稳。
Computer Use 的特殊难点：每一轮都会塞一张大截图进上下文。20 轮之后，token 数曲线非常吓人。Anthropic 给出的解法是三层组合，每层各司其职。
① Cache Breakpoints（缓存断点）
- 总共 4 个断点：1 个固定在 system prompt 前缀，3 个跟随最近的 tool_result 滚动。
- 每轮 turn 重新放置——这一点是关键。它让缓存能"优雅降级"：即使最末尾断点失效，前面三个仍可命中。
- 命中即省钱省延迟，前缀字节稳定是命中率的前提（这也是为什么后面 rolling buffer 必须批量修剪）。
② Rolling Buffer（滚动缓冲区）
- 默认
keep_n=3, interval=25：每 25 轮做一次批量修剪，保留最近 3 张活跃截图。 - 批量修剪 ≠ 逐条丢弃——后者会让前缀字节频繁变动，缓存命中率崩盘。这个区别非常重要，是新手最常踩的坑。
- 旧截图替换为
[Image omitted]占位符：保留语义连续性，但不再付图像 token 的钱。
③ LLM-based Compaction（智能压缩）
跨阈值时把"历史 turns"压成结构化摘要：
- Server-side（beta）：用
compact_20260112beta header，触发阈值默认 ~150K tokens，最省心。 - Client-side：自己测 token 数，跨阈值时调用摘要模型，自由度更高。
文章给了一个摘要 prompt 必含 8 节的模板，照抄即可：
1. USER INSTRUCTIONS（逐字保留）
2. TASK TEMPLATE（可重复工作流模式）
3. CONSTRAINTS AND RULES
4. ACTIONS TAKEN
5. ERRORS AND FIXES
6. PROGRESS TRACKING
7. CURRENT STATE
8. NEXT STEP
8 节里最容易被忽略也最关键的是 5（错误与修复）和 6（进度跟踪）——它们让 agent 在"瘦身"之后还能把活干完。
主线 ⑤：Batch / Advisor / 提醒——实验性但当下可用
Takeaway：合批、找帮手、定时拍肩，都是把"单 agent 单步思考"扩展成"团队作战"的廉价手段。
Batch tools（批处理工具）
computer_batch / browser_batch：单次调用执行多个子动作，省往返 + 省 token。
- ✅ 适用：动作之间互不依赖（填多个表单字段、一连串键盘快捷键、批量勾选复选框）
- ❌ 不适用：探索性导航、错误恢复——这些必须看一步走一步
Advisor tool（顾问工具，beta）
执行模型（Sonnet）+ 顾问模型（Opus 4.7）组合，服务端单 RT 内完成，无额外往返。意思是：你只发一次 API 请求，但 Sonnet 卡壳时会被 Opus 4.7 在服务端帮忙拍板。
控制项：
max_uses：单步内最多咨询次数- conversation-wide cap：整个对话级上限
- Advisor-side caching（默认 5 分钟）
⚠ 有个小坑：切换工具时要清理孤立的
server_tool_use/advisor_tool_result块，否则会触发 schema 报错。文章给了strip_orphaned_advisor_blocks函数，照抄。
Periodic reminder nudges（周期性提醒）
每 ~20 轮往上下文里插一句"提醒：你可以用 batch / advisor"——简单粗暴但很有效。模型不像人会主动想起新工具，得有人定时提醒它。
Debugging utilities
文章配套的三件调试套件值得单独提：
- Trajectory viewer（streamlit）：回放 agent 的每一步决策，长任务复盘必备
- Tool debug panel（uvicorn）：单独测试每个工具是否正确响应
- Localization playground：上传图像测试目标定位，复现"点不准"问题的最快方式
主线 ⑥：Teach Mode——Show, Don’t Tell
Takeaway：与其用 prompt 描述工作流，不如录一遍人类怎么做。
这是文章里最有"产品味"的一节。Anthropic 内部 “Claude in Chrome” 团队正在用的方法：录人类操作一遍，作为可复用规范回放给 Claude。
录制：每步都要"双保险"
WorkflowStep 同时捕获两类信号：
- Selector（DOM/UI 选择器）：抗布局变化更鲁棒
- Coordinates（坐标）：视觉回退，selector 找不到时兜底
外加 screenshot（带蓝色圆圈标注点击位）、description、speech_transcript（讲解为什么这一步要这么做）。这些字段不是装饰——它们是回放时模型重建意图的关键。
案例：5 步费用报告提交
- 导航到 Expense 页
- 点击 Category 下拉
- 选 Travel
- 输入金额 ¥1,280
- 点击 Submit
录制一次之后，这套规范就被 SavedWorkflow 序列化下来，下次直接用 generate_playback_context 喂给 Claude 即可复用。
回放三模式：按业务严苛度选
| 模式 | 行为 | 真实场景 | 选它的判据 |
|---|---|---|---|
| Strict 严格 | 完全按演示走，UI 变化大就停 | 合规审批 / 财务结账 / 监管报送 | 「宁可停 ≫ 走错一步」的链路 |
| Adaptive 自适应（推荐默认） | 演示作指引，适应轻微 UI 变化 | CRM / 表单填写 / 工单流转 | 大多数企业内部系统的甜区 |
| Goal-oriented 目标导向 | 只关心最终结果，步骤仅作提示 | 竞品调研 / 数据采集 / 开放网页爬取 | 允许「换路达终点」的场景 |
一个简单判据：**这个流程错一步会出报销单还是会扣钱？**前者用 Adaptive，后者用 Strict。
案例落地：两个最容易复现的场景
案例 A：「点击为何总是偏移」的诊断流程
新人第一次写 Computer Use Agent，80% 的时间会卡在这里。Anthropic 推荐的诊断顺序如下：
- 第一现场：打开 Trajectory viewer，把模型预测的点击位叠加在原图上——肉眼看是"模型瞎"还是"坐标错了"。
- 如果模型瞎了：去 Localization playground，单独喂相同的截图问"Submit 按钮在哪"——能精准命中说明不是认知问题。
- 基本可以确认是缩放问题：检查输入图分辨率，是不是塞了 1920×1080 进 4.6 系列、是不是 macOS 2× DPR 没缩、是不是低于 960×540。
- 改完仍偏一两像素：开
enable_zoom，让模型主动放大；或者用键盘 Tab 导航代替鼠标点击。 - 小目标真的太小：放大源 UI 的 CSS / DPI——别在模型这一侧硬卷。
诊断的核心心法是 “先证伪模型瞎，再回头查 pipeline”。99% 的偏移问题都在 pipeline 上。
案例 B：用 Teach Mode 把"提交费用报告"工作流自动化
假设你要给公司内部财务系统做一个 Claude 助手。没有 Teach Mode 的话，你大概率会写一个 30 行的 prompt 描述每个字段叫什么、长什么样、应该填什么——脆弱、难维护、UI 改一点就坏。
有 Teach Mode 的工程化做法是：
- 让真实员工在 Chrome 里录一遍正常的报销提交。
- 系统自动捕获 5 步：导航 → 点 Category → 选 Travel → 填金额 → Submit，每步附带 selector + coordinates + 截图 + 讲解。
- 序列化为
SavedWorkflow存进资源库。 - 回放选 Adaptive：因为内部系统 UI 偶尔小改，但流程稳定。
- 上线时配 Guardrails：Submit 前必须人审金额。
接下来财务系统改版了 Category 下拉的位置——Adaptive 模式仍能完成任务，因为 selector 没变；只有当系统大改（例如把"Submit"按钮拆成"暂存 + 提交"两个按钮）时，才需要重新录一次。
比起 prompt 工程，录制是更接近软件工程的人机协作范式——它有明确的"代码、版本、回放、回归"的概念。
总结：把 6 条主线拍成一张上手清单
文章信息密度很高，最后给你一张可以贴在显示器旁边的清单图：
如果你现在就要从 0 开始落地一个 Computer Use Agent，严格按这个优先级走：
- 先把分辨率与坐标 pipeline 写对（ROI 最高，零模型成本）
- 把 Cache + Rolling Buffer 接上（决定你的钱包能撑多久）
- 加 Guardrails：人审 + 全量日志 + 最小权限（决定你的项目能不能上线）
- Effort 选档位、模型按场景挑（默认 Sonnet 4.6 + medium，难任务才升级）
- 用 Teach Mode 把高频场景固化（决定你的可靠性曲线）
- 再考虑 Batch / Advisor / 提醒 等实验项（锦上添花）
这篇文章值得反复读的地方在于：它不是一篇"Claude 多强"的宣传稿，而是一份把 Computer Use 从 Demo 推向生产的工程清单。它的每一条建议都是踩过坑的——你能少踩多少，取决于你愿意把它读多细。
延伸阅读：
- 📦 配套 Demo 实现：anthropics/claude-quickstarts · computer-use-best-practices
- 📘 Computer Use Tool 官方文档
- 🧠 Adaptive Thinking 官方文档
- 🛡 Prompt Injection Defenses 研究
- 🗜 Server-side Compaction 文档
- 🤝 Advisor Tool 官方文档
「真诚赞赏，手留余香」
爱折腾的工程师
真诚赞赏，手留余香
使用微信扫描二维码完成支付
