Anthropic Computer Use 实测——桌面自动化到底有多靠谱
Anthropic Computer Use 实测——桌面自动化到底有多靠谱
适读人群：对 AI Agent 和自动化感兴趣的工程师 | 阅读时长：约15分钟 | 核心价值：用真实数据告诉你 Computer Use 的能力边界，不神化不贬低
上个月我花了整整一个周末测试 Anthropic 的 Computer Use 功能。不是为了写评测文章，是因为一个客户想把它用在实际项目里——一个需要定期操作某政府网站下载报表的任务，手工做要两个小时，他问我能不能用 AI 自动化。
我的第一反应是：能，但得先搞清楚边界在哪里。
于是我准备了一台干净的 Ubuntu 虚拟机，拉了官方的 Docker 镜像，设计了 20 多个测试场景，从最简单的"打开文本编辑器写一段文字"到最复杂的"登录某平台下载带验证码的报表"，跑了整整两天。
结论放在最前面：Computer Use 在可预期的、重复性的、界面固定的任务上，成功率在 70% 以上；一旦涉及动态界面、多步骤状态依赖、或者任何形式的人机验证，成功率断崖式下跌到 20% 以下。
环境搭建：官方路线的坑
先说环境。Anthropic 官方提供了一个参考实现，基于 Docker，包含 VNC 服务、工具调用接口，Claude 通过截图感知屏幕、通过工具调用操作鼠标键盘。
# 官方参考实现
git clone https://github.com/anthropics/anthropic-quickstarts
cd anthropic-quickstarts/computer-use-demo
# 构建并运行
docker build -t computer-use-demo .
docker run \
-e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
-v $HOME/.anthropic:/home/user/.anthropic \
-p 5900:5900 \ # VNC 端口
-p 8501:8501 \ # Streamlit UI
-p 6080:6080 \ # noVNC Web 界面
computer-use-demo第一个坑：默认镜像里的 Chrome 版本和某些网站有兼容性问题，特别是用了新版 CSS 特性的页面，截图里看起来布局是错的，Claude 识别的坐标就会偏。我后来换成了 Firefox，好一些。
第二个坑：VNC 默认分辨率是 1024×768，这个分辨率下很多现代网页的响应式布局会变成移动端样式，按钮位置和桌面版完全不同。改成 1280×800 之后识别准确率提升了不少。
# 工具定义——Claude 通过这些工具操作屏幕
tools = [
{
"type": "computer_20241022",
"name": "computer",
"display_width_px": 1280,
"display_height_px": 800,
"display_number": 1,
}
]测试结果：分场景拆开看
我把测试场景分成五类，逐类看结果。
第一类：基础文件操作（成功率 85%）
任务举例：
- 打开文本编辑器，输入一段文字，保存到指定路径
- 打开文件管理器，把某个文件夹里的 .csv 文件全部移动到另一个目录
- 打开终端，执行一个 Python 脚本，把输出结果截图
这类任务 Claude 表现很稳。原因很简单——这些界面元素固定，按钮位置不变，操作步骤有明确的视觉反馈。
失败的 15% 主要是因为：文件名包含中文时拖拽识别有问题；有时候它会把"确认覆盖"的弹窗错过，导致任务没完成但它以为完成了。
第二类：固定界面的网页表单（成功率 73%）
任务举例：
- 在 Google 搜索框输入关键词，点击搜索，截图第一页结果
- 填写一个静态的 HTML 表单（姓名、邮箱、电话），提交
- 在 GitHub 上打开某个 issue，复制标题文字到剪贴板
成功率还可以，但有几个规律性的失败点：
下拉菜单是噩梦。 特别是那种自定义样式的下拉菜单（不是原生 <select>），Claude 经常以为点开了，其实选项列表没出现。它会等一会儿，然后再试，有时候反复点几次才选上，有时候就放弃了。
分页操作容易丢状态。 比如让它在一个列表页面找到某条记录然后点开，如果列表有分页，它可能在第一页没找到就报告"找不到"，没有翻页的意识。
第三类：登录后的业务操作（成功率 41%）
任务举例：
- 登录某 SaaS 平台，导出某个时间段的数据报表
- 登录内部系统，填写一个多步骤的申请表单
- 登录电商后台，批量修改某个分类下的商品状态
这里成功率开始明显下跌。核心问题是登录状态管理。
Claude 不理解"我已经登录过了"和"我需要重新登录"的区别，每次任务开始它都会先截图看一眼，但有时候登录 session 过期了，它没有意识到当前页面已经是登录页，继续往下操作，然后在一个它完全看不懂的错误页面迷失。
另一个问题是多步骤表单的依赖关系。比如一个四步骤的申请表，第三步的选项依赖于第二步的输入，Claude 有时候第二步填完之后，没有等页面刷新就点下一步，第三步的选项还是空的，它依然点选了一个看不见的选项，整个任务静默失败。
第四类：带验证码的任务（成功率 8%）
这个不用多说了。图形验证码 0% 成功。
短信验证码的流程让我比较意外，我测了一个场景：让它填好表单，然后我手动告诉它验证码（通过对话输入），看它能不能继续完成。这个场景成功率还行（约 60%），说明验证码本身不是技术问题，是流程设计问题——这个环节需要人工介入。
点选式验证码（"点击所有包含汽车的图片"）完全不行，我试了 10 次，1 次都没过。
第五类：动态单页应用（成功率 22%）
任务举例：
- 操作一个 React 写的复杂表格：排序、筛选、选中多行、批量操作
- 使用一个拖拽式编辑器（类似低代码平台）完成某个配置
- 在一个实时协作工具里编辑文档
这类任务失败的根本原因：Claude 只能看到静态截图，感知不到 JS 驱动的状态变化。
最典型的例子：我让它在一个类 Notion 的编辑器里给某个标题加粗。它看到了标题，双击选中了文字（截图显示已选中），然后按了 Ctrl+B，截图里文字看起来变粗了，它报告成功。但实际上它按 Ctrl+B 的时候焦点已经从编辑器跑到浏览器标签页了，什么都没发生。
它无法感知"焦点在哪里"，这是 Computer Use 目前最大的盲区之一。
成本和速度：真实数据
跑完这些测试，API 账单是关键参考。
每次工具调用 Claude 都需要截图（约 200-400KB 的图片），算作输入 token。一个中等复杂度的任务（比如登录后导出报表），通常需要 8-15 轮工具调用，每轮截图加上文字描述，input token 大概 5000-8000，output token 约 500-1000。
按 Claude claude-sonnet-4-5 的价格（$3/MTok input，$15/MTok output），一个中等任务的成本约 $0.05-$0.15。
速度上：简单任务 30-60 秒，复杂任务 3-8 分钟。不是因为 API 慢，是因为每步操作之后要等页面响应，还有思考时间。
这意味着：用 Computer Use 替代人工的经济账要仔细算。如果一个任务人做要 2 分钟，Computer Use 做要 5 分钟还有 30% 失败率，未必合算——除非这个任务需要 7x24 不间断跑，或者人工成本特别高。
哪些场景真的适合用
综合测试下来，我认为 Computer Use 目前真正适合落地的场景有以下特征：
界面固定：不会随用户行为动态变化，没有 A/B 测试导致的版本差异，没有响应式布局的大幅变化。
可以容忍失败重试：不是那种"操作一次就不能撤销"的场景。批量下载文件失败了重试就行，但涉及金融交易的操作出错代价太高。
有清晰的完成信号：任务完成后有明确的视觉反馈，比如弹出"下载成功"，而不是那种"反正页面还是一样，但数据已经提交了"的静默完成。
操作频率不高、时效性不强：每天跑一次的批处理任务，比需要毫秒级响应的实时任务更适合。
最后说那个客户的需求
回到最开始的那个政府网站报表下载需求。
我最后给的建议是：可以用，但要加监控和人工回环。
方案是这样的：写一个 Python 脚本，调用 Computer Use API 执行下载流程，成功后把文件发到钉钉群；失败了（无论是超时、找不到元素、还是 Claude 自己报告失败）就发告警，人工介入重跑。
跑了两周，成功率是 78%，剩下的 22% 是因为政府网站周末有维护或者验证码更新了。
这个成功率客户可以接受——他原来是让实习生每天早上手工下载，每周总有几次忘了或者下错了。78% 自动成功 + 异常时告警，比全靠人工可靠多了。
Computer Use 不是魔法，也不是玩具。它是一个有明确能力边界的工具，搞清楚边界，在边界内用，就是很实用的东西。