Claude Computer Use 完整指南：API 工具、Cowork 和 Claude Code 怎么选？

今天的 Claude Computer Use 实际上指两套不同的执行合同。 在 API 这一侧，Anthropic 给开发者的是一个 beta 级计算机使用工具：Claude 通过截图理解界面，在你控制的沙箱里调用鼠标、键盘和桌面自动化动作。到了产品侧，Cowork 和 Claude Code 指的是 Claude 在你自己的电脑上工作，由 Anthropic 的桌面产品编排会话，而你决定它能接触哪些文件、连接器和审批边界。

最短、也最靠谱的判断是：如果你是在做产品级自动化，就走 API 路线；如果你是想让 Claude 在你自己的电脑上替你做事，就看 Cowork 或 Claude Code。 真正要回答的问题不是“Claude 能不能点按钮”，而是“谁拥有执行环境、谁拥有工具循环，以及你愿意接受哪一套权限和数据保留边界”。

“

证据说明：本文基于 Anthropic 当前的 computer use API 文档、Cowork 帮助中心、Cowork 产品页 和 computer use 隐私说明，于 2026 年 3 月 28 日核对。

TL;DR

• Anthropic API computer use 面向开发者。你要自己启用 beta 工具，把 Claude 放进你控制的 VM 或容器里执行动作，然后把工具结果回传给模型。
• Cowork 和 Claude Code 面向“把任务委托给 Claude，在自己电脑上完成”的工作流。Anthropic 的桌面产品负责会话编排，你决定开放哪些文件夹、连接器和审批权限，以及 Claude 是否会从文件或浏览器路径升级到直接操作屏幕。
• 如果你只是想最快体验，API 侧应该从 Anthropic 的 reference implementation 起步；桌面侧则直接从 Claude Desktop -> Cowork 开始。
• 这两条路不是一套统一的权限、配置或数据保留合同。必须分开理解。
• 更安全的默认顺序是：连接器或本地文件优先，浏览器任务第二，屏幕级控制最后。
• 只要任务涉及敏感账号、支付、同意授权或必须零误差的操作，无论哪条路线，都应该保留人工确认。

Claude Computer Use 现在到底指什么

在这个词刚出现的时候，它更像一个单独的开发者能力：Anthropic 让 Claude 能看截图、调用鼠标和键盘动作、在受控桌面环境里执行任务。对于要做 agent 产品的人来说，这条路线今天依然是核心。

真正让情况变复杂的，是 Anthropic 现在把同一类能力也放进了 Cowork 和 Code 的产品叙事里。当前的 Cowork 产品页写得很明确：Claude 可以在手机和桌面之间持续同一个任务，会用连接器，会用 Chrome 做网页任务，也会在没有直接集成时“使用你的电脑”。帮助中心页则给了更落地的解释：Cowork 在 Claude Desktop 里运行，会在你的电脑上处理任务，执行时桌面应用必须保持开启，你也可以在过程中随时接管或修正。这意味着同一个短语现在实际对应两套不同的运行合同。

这会带来一个很实际的误判：开发者可能高估 Anthropic 在 API 侧替自己承担了多少集成工作，桌面用户则可能低估本机上的权限、范围控制和审批仍然有多重要。更可靠的理解方式，是先看“谁拥有执行环境”。 如果是你的应用在接收 tool call、执行动作、回传结果，那就是 API 路线；如果是 Anthropic 的桌面产品在你自己的电脑上帮你编排和执行，那就是 Cowork 或 Claude Code 路线。

还有一个必须提前讲清的点：浏览器使用和完整电脑使用并不是一回事。 Anthropic 自己在 Cowork 页面的表述其实已经给了最合理的层级：能走连接器就走连接器，能在 Chrome 完成就先用浏览器，只有没有直接集成时，才升级到屏幕级操作。这比一句“Claude 可以操作你的电脑”有价值得多，因为它告诉你什么才是默认路径，什么才是真正的兜底方案。

路线一：Anthropic API 的计算机使用工具

如果你要做的是自动化产品、内部 agent 工具，或者必须像人一样操作软件界面的工作流，那么你真正该关心的是 API 路线。Anthropic 当前文档把 computer use 定义成一个 beta 工具：Claude 可以获取截图、控制鼠标、输入键盘，并执行一般性的桌面自动化。API 示例里最关键的不是“Claude 会点击”，而是它反复强调的合同形态：Claude 返回 tool call，你的应用在 VM 或容器里执行动作，再把 tool_result 回给模型，直到任务完成。

这句“you own the loop”比任何营销话术都重要。它意味着 Anthropic 并没有替你远程驱动一台机器。真正负责系统集成的人是你。你要决定显示环境长什么样，截图怎么采集，高分辨率下坐标怎么映射，点击和输入如何真正执行，以及模型的动作能不能越出你设计的边界。换句话说，computer use 在 API 这一侧并不是“打开一个神奇开关”，而是“给 Claude 一个工具合同，再由你把它接进真正的执行环境里”。

当前 beta 头部也说明了这依然是一个显式工具，而不是默认常开能力。Anthropic 目前列出的头部是：

• computer-use-2025-11-24：适用于 Claude Opus 4.6、Claude Sonnet 4.6 和 Claude Opus 4.5
• computer-use-2025-01-24：适用于 Sonnet 4.5、Haiku 4.5、Opus 4.1、Sonnet 4、Opus 4，以及已弃用的 Sonnet 3.7

最小可运行骨架大致长这样：

bash
curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: computer-use-2025-11-24" \
  -d '{
    "model": "claude-opus-4-6",
    "max_tokens": 1024,
    "tools": [
      {
        "type": "computer_20251124",
        "name": "computer",
        "display_width_px": 1024,
        "display_height_px": 768,
        "display_number": 1
      }
    ],
    "messages": [
      {
        "role": "user",
        "content": "Open the browser and summarize the dashboard."
      }
    ]
  }'

这个请求已经把本质暴露得很清楚了：你不是在“打开 Claude 的泛化电脑控制能力”，而是在告诉模型应该用哪个 beta 工具合同、哪个显示界面、哪条运行链路。真正难的部分不是第一条请求，而是你围绕它搭出来的执行环境。

这条路最适合那些确实只有界面、没有干净 API 可走的场景。比如老旧企业软件、只能通过 GUI 完成的内部流程、浏览器里的 RPA 任务、端到端测试等，computer use 都可能是合理工具。反过来说，如果系统已经提供了 API、CLI、数据库钩子或 webhook，那直接去做屏幕自动化通常就是更差的工程选择。不是因为 computer use 没用，而是因为你在用最脆弱的一层去模仿本来就存在的机器接口。

成本也会进一步提醒你别滥用这一层。Anthropic 当前文档写得很明确：computer use beta 会额外增加 466-499 个 system prompt tokens，Claude 4.x 模型还要再付 735 个工具定义输入 tokens，除此之外还有截图本身的视觉 token 成本，以及工具结果返回给模型的额外成本。也就是说，屏幕级自动化天然带着更高的上下文负担。只有当 UI 本身就是系统的真实入口时，这种开销才值得。

文档里最有价值的部分其实是安全建议。Anthropic 推荐在独立 VM 或容器里运行、限制联网域名、对有真实后果的动作保留人工确认，并且明确提醒网页和图像中的 prompt injection 风险。这不是形式化免责声明，而是 computer use 的工程真相：一旦模型可以读取屏幕上的内容并按它理解的方式行动，你就必须把环境当成潜在对抗输入，而不是把它当成“只要模型够强就能自动完成”的玩具。

还有一个很实操但容易被忽略的点：坐标缩放。Anthropic 当前文档提醒，模型分析的截图尺寸可能比你真实控制的屏幕更小。如果你不自己做缩放和坐标回映射，模型即便判断正确，也可能点错位置。这正是为什么 API 路线属于开发者路线：它不是“会点鼠标”就够了，而是要把视觉理解、工具执行和环境约束完整接起来。

路线二：Cowork 和 Claude Code 在你电脑上的工作流

很多人说自己想要“Claude 操作电脑”，真正想要的其实就是这条桌面产品路线。这里最关键的差别是：你不是在往自己的产品里接一个工具循环，而是在用 Anthropic 的桌面环境，把任务委托给 Claude，让它在你自己的机器上完成。当前 Cowork 帮助中心写得很清楚：Cowork 需要 Claude Desktop，支持 macOS 和 Windows，但它本身不是 Web 或移动端的独立执行面；任务执行期间桌面应用必须保持开启。

这已经让它和 API 工具非常不像同一个东西了。API 是一种集成合同，Cowork 更像是一种产品工作流。Anthropic 对 Cowork 的描述也更像“把任务交给 Claude，回来拿结果”：桌面应用能访问你授权的文件夹，能调连接器，能处理本地文件，能跑更长时间的任务。帮助页还特别提到，你可以在任务运行期间从手机给 Claude 发消息继续推进。这和 API 完全不是同一种便利性。前者是你在使用产品，后者是你在构建运行时。

Cowork 产品页还有一个比很多二手教程更健康的表述：Claude 会优先选择最快、控制最小的路径。能用连接器，就先走连接器；网页研究能在 Chrome 完成，就先走浏览器；只有没有直接集成时，才升级到屏幕级操作。这个顺序比“Claude 可以操作你的电脑”更有决策价值，因为它告诉你屏幕级控制在 Anthropic 的产品逻辑里，本来就应该是兜底层，而不是默认层。

Anthropic 对可用性的表述也比较谨慎。帮助中心说 Cowork 本身通过 Claude Desktop 在 macOS 和 Windows 上可用，且当前属于付费计划的 research preview。产品页里那句更强的“Anything you can do on your computer, Claude can do”，目前则标注为 Available on macOS。更稳妥的做法不是把这两句话强行揉成一句“所有平台都一样”，而是按页面原文来理解：Cowork 作为桌面工作流覆盖 macOS 和 Windows，但产品页里明确的“电脑级操作”表述目前指向 macOS。

另外，产品页还写到，这次“手机到桌面持续同一对话”和“computer use”更新是跨 Cowork 和 Code 的。但如果你真的要找最具体的公开设置步骤，当前最完整的文档依然是 Cowork 侧，而不是 Code 侧。所以更安全的表达应该是：Code 和 Cowork 现在属于同一类持续桌面工作流家族，但如果你想要一个最清晰的“先怎么开起来”的路径，还是先以 Cowork 文档为准，而不要脑补 Code 已经有一套完全对称、完全公开的设置说明。

权限边界在这里也明显更偏“产品化”。帮助中心说 Cowork 在永久删除文件之前必须获得你的明确授权。产品页则强调你可以决定 Claude 能访问哪些文件夹和连接器，Claude 在行动前会先展示计划并等待批准。这和 API 路线完全不同：API 是你自己设计沙箱和审批机制；桌面路线则是 Anthropic 给你一套带权限边界的委托 UI。

对于很多非开发者场景来说，这恰好是更好的模型。整理下载文件夹、从零散笔记草拟报告、把收据截图整理成表格、做周期性摘要，这些事情都更像 Cowork 的任务，而不是 API computer use 的任务。即便在编码相关场景里，问题也应该是：你到底需要一个可编程 agent 运行时，还是你只是想让 Claude 在你自己的电脑上做事、你在旁边监督？如果是后者，Cowork 或 Claude Code 才是天然入口。

如果你现在真正纠结的是计划和订阅层面的接入条件，可以配合看我们的 Claude Code 定价指南。如果你的真实需求并不是广义的“computer use”，而是想让 Claude 在代码仓库里更安全地跑长任务，那 Claude Code Auto mode 指南 往往更相关。

每条路线最快的起步方式

如果你不想先读完整个生态再开始上手，最短的起步路径如下。

API 路线：直接从 Anthropic 的 reference implementation 开始，而不是自己从零写一个“点鼠标执行器”。先把当前 beta header 配好，在独立 VM 或容器里运行环境，把 computer tool 和 prompt 一起发给 Claude，执行模型返回的动作，再把 tool_result 回传。关键不在第一条请求，而在请求外侧那层隔离边界是否做对。

桌面路线：打开 Claude Desktop，切到 Cowork，选择 Claude 可以访问的工作文件夹或文件，描述你想要的交付结果，先看它给出的计划，再开始执行。任务运行期间桌面应用必须保持开启；如果你想中途从手机补充说明，可以用 Anthropic 当前文档里的手机续接路径，但真正执行仍然绑定在桌面应用上。

到底该选哪条路？

如果你的目标是把 agent 能力集成进自己的产品，选 API。
如果你的目标是把任务交给 Claude，在你自己的电脑上完成，选 Cowork 或 Claude Code。更细一点可以这样看：

最清晰的心智模型其实只有一句话：API 路线是给“要做工具的人”的，桌面路线是给“要做委托的人”的。 关键不在于把能力说得更大，而在于先把执行环境的所有者说清。只有这样，风险、配置成本、审批流程和适用场景才不会混在一起。

隐私和数据保留必须按产品面向分别看

这也是最容易被写错的一段。Anthropic 当前公开材料，并没有给所有 computer use 场景提供一句完全统一、覆盖一切的保留说明。

对 API 路线来说，computer use 文档写的是：这个功能是 client-side tool，在有 ZDR 安排的组织下，可以做到 API 返回后不再存储数据。但 Anthropic 的隐私中心文章针对商业产品又写到：默认情况下，截图会在后端保留 30 天后删除，除非客户和 Anthropic 有其他协议。而 Cowork 产品页强调的则是：任务历史默认保存在本地，除非你主动提交反馈或诊断信息。

正确的结论不是“Anthropic 前后矛盾”，而是：computer use 现在已经跨越了不止一个产品面向，每个面向的数据处理语境不同。对开发者来说，最稳妥的做法是把 retention 视为实现合同的一部分，按你所用的计划和产品面向去读对应文档。对桌面用户来说，应该以本地历史、桌面权限和产品授权边界为主，而不是直接套用 API 工具那一侧的说法。真正不该做的，是从某一页抄一句 retention 描述，贴到另一种产品面向里，当成通用真理。

什么时候不要用 computer control

Anthropic 当前的产品表述其实已经给了正确答案：用能解决问题的最低控制级别。 如果 Claude 可以通过连接器拿到答案，就让它走连接器；如果它可以通过你授权的本地文件完成任务，那通常也比让它点开一个应用窗口更可靠；如果问题本质上是网页研究、表单填写或浏览器任务，那 Chrome 往往比“整台屏幕”更可控。只有在没有直接集成、也没有更窄的浏览器路径时，完整电脑控制才应该成为最后一级。

这同时关乎安全和稳定性。连接器和文件访问更容易限定范围，也更容易审计。浏览器任务虽然比 API 更脆弱，但通常比完整桌面交互更可控。屏幕级自动化是能力最强、也最难推理的一层，所以它应该是最后一层兜底，而不是默认起点。

还有一类任务，哪怕“Claude 能做”，也不代表“Claude 应该独立做”。Anthropic 在文档里明确要求对有真实后果的动作保留人工确认，这个标准本身就是正确的。Cookie 同意、支付、合同确认、破坏性删除、敏感账号访问，或者任何要求极高精度的动作，都应该继续由人主导。即使模型大多数时候能做对，也不代表它已经足够承担错误成本。

同样的道理也适用于“其实已经有更好接口”的任务。如果你明明可以通过 dashboard 的导出按钮、数据库查询或 API 拿到数据，却偏要让 Claude 去看屏幕、点按钮、抄数，那就不是在发挥 computer use 的价值，而是在主动选择更脆弱的路径。computer use 有价值，是因为有些软件天生就是“给人操作的”；不是因为“会点按钮”本身更高级。

FAQ

Claude Computer Use 只是 Anthropic API 里的那个工具吗？

不是。对开发者来说，API 工具当然是最重要的一层含义；但 Anthropic 当前的 Cowork 和 Code 页面也把类似能力纳入了桌面委托工作流里。所以今天这个词已经不只指一个产品表面。

我需要自己实现工具循环吗？

只有在 API 路线里需要。Anthropic 当前文档写得很清楚：你的应用要负责提取 tool call、在 VM 或容器里执行动作，再把 tool_result 回给 Claude。桌面路线则是 Anthropic 的产品替你管理这层执行逻辑。

Cowork 是在 Web 上跑的吗？手机能直接执行吗？

当前帮助中心的说法是：Cowork 需要 Claude Desktop，在 macOS 或 Windows 上运行，本身不是 Web 或手机端的独立执行面。你可以从手机继续给 Claude 发消息，但真正执行任务的还是桌面应用。

只要 Cowork 可用，就代表完整电脑使用也同样可用吗？

不要这样假设。帮助中心写的是 Cowork 在 macOS 和 Windows 上可用；但产品页里那句更明确的“Anything you can do on your computer, Claude can do”目前标的是 Available on macOS。所以更安全的理解是：Cowork 桌面工作流更广，明确的电脑级操作表述目前以 macOS 为准。

API 路线贵不贵？

会比普通文本调用贵，原因不是一句“模型更强”就能解释，而是它额外叠加了工具开销和截图开销。Anthropic 当前文档列出的额外成本包括：466-499 个 beta system prompt tokens、Claude 4.x 上 735 个工具定义 tokens，以及截图和工具结果返回带来的额外 token 消耗。这也是为什么它应该被留给那些确实只有 UI 可走的场景。

Anthropic 会保留截图吗？

这个问题必须按产品面向来回答，而不能求一句全局通用答案。API 文档写的是 ZDR 资格；隐私文章写的是商业产品默认 30 天删除；Cowork 产品页强调的是本地历史存储。如果 retention 对你的场景真的重要，就去看你实际所用产品面向和合同下的文档，而不是假设“computer use”天然就只有一种数据处理方式。

真正有用的问题，不是“Claude 会不会点击”

Claude 会点击，这件事本身已经不稀奇了。

真正有用的问题是：你到底要构建什么样的系统，或者把什么级别的控制权交给它。 如果你在做产品，就把 API 工具当作一个真正的自动化运行时来看待，把它放进真实沙箱和真实审批边界里；如果你只是希望 Claude 在你自己的电脑上替你做事，就用 Cowork 或 Claude Code，让 Anthropic 的桌面产品帮你管理会话，而你负责文件夹、连接器和关键审批。

当你这样理解之后，Claude Computer Use 就不会再是一个看上去很魔法、实际上很模糊的说法。它会变成一个具体而清晰的路径选择题。而真正的实现质量和判断力，也正是从这一步开始分出高低。