Best Practices for Computer and Browser Use with Claude(Claude 计算机与浏览器使用最佳实践)
- 原文标题
- Best Practices for Computer and Browser Use with Claude(Claude 计算机与浏览器使用最佳实践)
- 原文链接
- https://claude.com/blog/best-practices-for-computer-and-browser-use-with-claude
- 作者
- Lucas Gonzalez、Luca Weihs 等(Anthropic)
- 发布日期
- 2026-05-13
🎯 一句话
让模型直接操作屏幕和浏览器,好处是不需要为每个系统做接入,代价是慢、贵、且容易被界面变化打断。⭐ 能用 API 就别用界面。
📑 本页目录
点击准确率是一切的地基。 把截图正确缩放、选对模型、管好上下文,能显著提升可靠性和成本效益。
最影响成败的一件事:图像缩放
Claude 4.6 系列的图像限制: - 最长边: 1568 像素 - 总像素: 115 万(1.15 megapixels)
超出阈值的图像会被静默降采样,导致坐标错位。推荐从 1280x720 起步——既在限制内又保持合理清晰度。
坐标换算(拿到 API 返回的坐标后要换回原生分辨率):
screen_x = int(api_x * (screen_w / display_w))
screen_y = int(api_y * (screen_h / display_h))
内容顺序: 消息数组中文字指令放在图片之前,能提升准确率。
模型与思考强度选择
| 模型 | 特点 |
|---|---|
| Sonnet 4.6 | 点击准确率、推理与成本的最佳平衡 |
| Opus 4.7 | 推理更强、点击更精确;分辨率预算更高,降采样更少 |
| Haiku 4.5 | 优先低延迟 |
思考强度(thinking effort)建议:
- Opus 4.7 默认 high(token 比 max 少约 50%,成功率接近);成本敏感用 low;复杂一次性任务才用 max
- Claude 4.6 系列默认 medium;高吞吐用 low(因错误更少,总 token 反而更省)
关键洞察:「一点点思考就大有帮助」——即使 low 也远好过不思考,因为它减少了重试循环。
小目标处理
复选框、图标、开关这类小元素是难点:
- 密集 UI 开启 enable_zoom: True
- 把目标做大——元素尺寸对可靠性的影响不成比例地大
- 用键盘替代: Tab 导航或快捷键常常胜过点击小元素
提示词注入防御(三层)
- 训练时鲁棒性: 通过强化学习训练模型抵抗注入内容
- 实时分类器: 用官方
computer_20251124工具时自动扫描对抗性指令,无需配置 - 持续红队: 安全研究员持续探测新攻击手法
无论分类器多有效,仍应:高风险操作人在环、严格限定 Agent 权限、监控并记录所有动作、把网页内容一律当作不可信。
长会话的上下文管理(三层)
- 缓存断点: 稳定前缀(系统提示词)放一个,最近的工具结果放三个,实现优雅降级
- 滚动缓冲: 只保留最近 N 张截图(推荐 keep_n=3、interval=25)。分批修剪以保证缓存前缀在两次修剪之间逐字节一致
- LLM 压缩: 超过约 50 个动作的会话做摘要——「逐字保留所有用户指令……一旦丢失,Agent 就会跑偏」
服务端压缩(beta)可在 token 超阈值时自动完成这一步。
实验性技巧
- 批量工具(Batch Tools): 把连续动作(点击+输入+按键)合并成单次调用——降低延迟和输出 token,但动作依赖视觉状态变化时有错误累积风险
- 顾问工具(Advisor): 执行模型(Sonnet)+ 高智能顾问(Opus 4.7)中途提供战略指导,适合偶尔需要规划的长周期任务
- 演示教学(Teach Mode): 录制用户操作流程并标注点击位置。Claude 会适配 UI 差异而非机械回放——「演示胜于描述」,能优雅应对界面变化
点击问题诊断表
| 症状 | 可能原因 | 解法 |
|---|---|---|
| 稳定的固定偏移 | 尺寸不匹配或 API 降采样 | 核对显示尺寸与实际缩放图一致;预先降采样 |
| 大致准确但错过目标 | 目标太小或降采样过度 | 开启 zoom;用更低 DPI 截图 |
| 完全点错元素 | 指令有歧义 | 用具体的位置描述;拆成更小步骤 |
| 整体都差 | 图像超出 API 限制 | 预先降采样所有截图 |
三种方案怎么选
| 方案 | 适用 |
|---|---|
| 计算机使用(桌面/应用 UI) | 桌面应用的复杂多步流程;需要像素级点击;OCR 或文档解析不够用时 |
| 浏览器使用 | Web 应用和网站;可以操作 DOM 时(比点击快得多);高频表单填写或数据提取 |
| 直接 API 集成 | 应用提供结构化 API 时优先选这个——可靠性更高、延迟和 token 消耗更低 |
已验证无效的做法
- 网格叠加无用: 在截图上加坐标网格没有稳定的准确率提升
- 图像分块无用: 把截图切成四象限没有改善点击准确率
- max 思考强度没必要: 计算机使用任务上 max 不优于 high,只是更贵
结论
可靠性取决于对技术细节的系统性关注。「预先降采样你的截图」这一条的影响,几乎超过其他所有优化的总和。 生产级集成应组合:缓存感知的滚动缓冲 + 定期压缩 + 注入分类器 + 高风险动作人在环,并在代表性流程上测量缓存命中率、token 用量和错误模式来调参。
✅ 检查点
- 计算机/浏览器操作的核心权衡是什么?
- 什么场景值得用它?
- 它有哪些特有的安全风险?
👀 答案
- ⭐ 通用性 vs 可靠性。它能操作任何有界面的系统(不需要对方提供 API),但每一步都要截图、识别、定位、点击,慢且容易因为布局变化而失败。
- ①目标系统确实没有 API(老旧内部系统、第三方 SaaS 的边角功能);②一次性或低频的任务(不值得做正式接入);③需要跨多个系统拼接、而它们之间没有集成。⚠️ 高频、关键路径的任务应该做真正的 API 接入。
- ⭐ ①屏幕上的一切都是不可信输入——网页里的文字可以直接对模型下指令(提示注入),而它看起来只是页面内容;②权限面极大——浏览器里有你所有已登录的会话;③误操作不可逆——点错一个「确认删除」就没了。所以要限制可访问的域名、对写操作和不可逆操作要求确认、并且绝不让它处理凭证输入。
🛑 可以停在这里
⚡ 走神救援
⭐核心权衡:通用性 vs 可靠性——能操作任何有界面的系统(不需要对方提供 API),但每步都要截图/识别/定位/点击,慢且容易因布局变化失败。该用的场景:目标系统确实没有 API、一次性或低频任务、跨多系统拼接;⚠️高频和关键路径应该做真正的 API 接入。⭐⭐三类特有风险:①屏幕上的一切都是不可信输入——网页里的文字能直接对模型下指令,而它看起来只是页面内容;②权限面极大——浏览器里有你所有已登录的会话;③误操作不可逆。对策:限制可访问域名、写操作和不可逆操作要求确认、绝不让它处理凭证输入。