在各大厂狂卷开发者工具生态之际，Anthropic 也在频繁推出新工具。
北京时间昨天夜里，Anthropic 宣布在其开发工具 Claude Code 中引入一项极具突破性的能力——“Computer Use”（计算机操作能力）。这一功能目前以研究预览（research preview）形式在 macOS 平台上线，允许 Claude 直接通过命令行界面（CLI）操控用户计算机，实现从代码编写到应用验证的完整闭环。
Computer Use 正式可用
传统的 AI 编码工具，无论是 GitHub Copilot 还是早期的 Claude Code，本质上仍停留在“生成代码”的范畴——开发者需要手动完成编译、运行、调试、验证等步骤。而“Computer Use”能力的出现，彻底改变了这一流程。
根据 Anthropic 发布的技术说明，Computer Use 能处理任何你通常需要离开终端手动完成的任务，例如：
构建并验证原生应用：请 Claude 构建一个 macOS 菜单栏应用。Claude 会编写 Swift 代码，编译并启动它，并在你打开应用之前逐个点击每个控件进行验证，以确保其正常工作。
端到端 UI 测试：让 Claude 打开本地 Electron 应用，并告诉他“测试用户引导流程”。Claude 打开应用，点击注册按钮，并截取每个步骤的屏幕截图。无需 Playwright 配置，也无需测试框架。
调试视觉和布局问题：告诉 Claude “模态框在小窗口中显示不全”。Claude 调整窗口大小，重现问题，截图，修改 CSS，并验证修复效果。Claude 看到的问题与你看到的一致。
仅支持 GUI 的工具：与设计工具、硬件控制面板、iOS 模拟器或没有 CLI 或 API 的专有应用程序进行交互。
这意味着，开发者无需离开终端，即可完成过去需要 IDE、浏览器、模拟器等多工具协作的复杂流程。更关键的是，这种能力并不限于 CLI 环境，而是覆盖所有需要 GUI 交互的场景，例如：
原生 macOS 应用（如 SwiftUI）
Electron 桌面应用
无 CLI 或 API 的专有软件
iOS 模拟器、设计工具等
换句话说，Claude 不仅“会写代码”，还“会用电脑”。
技术实现：基于 Agent Loop 与 MCP
从技术角度来看，“Computer Use”并非简单的自动化脚本，而是构建在完整的智能体（Agent）执行框架之上。
该能力通过一个名为 computer-use 的内置 MCP（Model Context Protocol）服务器实现。MCP 是 Anthropic 近年来重点推进的接口标准，用于统一模型与外部工具、数据源之间的交互方式。
在这一架构中：Claude 作为决策核心（模型）、CLI 作为交互入口、MCP 服务器作为工具调度层，本地系统作为执行环境。Claude 会根据任务自动选择最合适的执行路径：
这种“分层决策”机制，本质上是一种成本与效率的优化：GUI 操作最通用，但也是最慢、最不精确的方式，因此仅作为兜底方案。
在引入“computer-use”能力之后，Claude 对本地应用的调用方式并非完全开放，而是建立在一套以“会话为单位”的权限控制机制之上。这一机制的核心目标，是在提升自动化能力的同时，确保用户对系统访问范围拥有清晰、可控的边界。
首先需要明确的是，启用 computer-use 服务器，并不等同于允许 Claude 直接访问用户计算机中的所有应用程序。系统默认采取的是按需授权策略：只有当 Claude 在当前任务执行过程中，首次尝试调用某个具体应用时，才会触发权限请求流程。
在这一过程中，终端会弹出提示信息，向用户明确展示几项关键内容：其一，Claude 当前希望控制的具体应用名称；其二，该操作是否涉及额外权限请求，例如访问剪贴板等敏感资源；其三，在 Claude 执行相关任务期间，是否会对其他正在运行的应用产生影响，例如被隐藏或暂时不可见。
用户需要基于这些信息进行决策，选择“允许”或“拒绝”。这一授权行为具有严格的作用域限制——所有批准仅在当前会话期间有效，一旦会话结束，相关权限将自动失效，不会被长期保留或跨会话继承。这种设计有效降低了长期权限滥用的风险。
此外，当 Claude 在同一时间需要访问多个应用时，系统支持用户进行批量授权，从而减少频繁确认带来的操作负担。这一设计在多步骤任务或复杂工作流中尤为关键，可以在效率与安全之间取得平衡。
社区反馈两极分化
在 Reddit 社区中，这一新功能迅速引发了广泛而激烈的讨论。
有趣的是，用户情绪呈现出一种明显的分裂：一方面认可功能本身的技术价值，另一方面则对其现实可用性表达出强烈不满。
一部分用户认为该功能“概念上很酷”，但在当前使用限制之下几乎缺乏实际意义。
有评论直言，这类发布“显得不合时宜”，甚至在社区中形成了一种带有讽刺意味的共识——“很酷，但谁在乎？”点赞较高的评论集中批评 Anthropic 的产品策略，认为连付费用户的基础体验都未得到保障，更不用说尝试这种高消耗 token 的新能力。在他们看来，资源分配和优先级判断存在明显偏差。
与此同时，一些具体问题也被反复提及。例如，Windows 和 Linux 用户对该功能迟迟未覆盖表示不满，认为 Mac 优先的发布路径忽视了更广泛的开发者群体。此外，该用户也表示对不同产品形态之间的定位感到困惑。社区中较为一致的解释是：“Cowork”更像是桌面端的沙盒助手，用于处理常规任务；而“Computer Use”则是面向开发者的命令行工具，具备更深层的系统访问能力，主要服务于代码相关工作流。
还有一部分用户，则进一步延伸到了成本与商业模式问题。
有用户指出，当前的定价体系本质上处于“被补贴”的状态。一旦单位经济模型趋于稳定，价格结构很可能发生显著变化，例如更严格的分级套餐、更低的使用上限，以及针对重度用户的高价订阅（每月 50 至 100 美元甚至更高）。这种判断的依据在于：如今普通用户仅用每月 20 美元，就可以完成过去可能需要数万美元外包成本的工作。
在这一逻辑下，即便模型推理成本正在下降，总体支出仍可能持续上升——因为用户规模扩大、上下文长度增加，以及任务复杂度提升，都会不断推高整体算力消耗。因此，无论是提高价格、收紧配额，还是引入更多限制，在部分用户看来几乎是“不可避免”的趋势。
当然，也有声音以更直观的方式表达了当前的使用困境。有用户调侃称，也许未来某一天，自己能够攒够足够的 token，至少尝试一次这个功能，而不至于消耗掉整整一周的额度。
OpenAI 同日发布新插件，把手伸进 Claude 生态
值得注意的是，昨天 OpenAI 连夜也发布了一个新插件 codex-plugin-cc，能让开发者直接在 Claude Code 里调用 Codex 做代码审查、对抗性审查，甚至把任务整个移交给 Codex 执行。
从产品策略上看，这并不是简单的兼容或适配，而更像是一种“反向渗透”：Claude Code 已经形成了自己的插件生态，而 OpenAI 选择以官方身份入场，将 Codex 明确定位为工作流中的“第二意见系统”。它不直接接管主流程，而是在关键节点提供独立判断，形成一种带有对抗性的协作关系。
这一插件（codex-plugin-cc）的设计非常克制，核心只提供三类命令，但覆盖了开发流程中最关键的风险点。
首先是 /codex:review，用于执行标准的只读代码审查。这一模式不修改代码，重点在于识别常规问题，例如代码质量、结构缺陷或潜在错误。
其次是 /codex:adversarial-review，这是插件中更具特色的能力。它并不满足于表层检查，而是主动挑战现有实现中的“隐藏假设”，例如边界条件、权限逻辑或系统耦合点。这类审查尤其适用于高风险场景，如系统迁移、鉴权机制调整或基础设施脚本变更，本质上是在用另一套模型思维对现有方案进行“压力测试”。
第三个命令 /codex:rescue 则更进一步——它允许开发者在任务陷入停滞时，直接将控制权交给 Codex，由其重新规划和执行。
OpenAI 推出的新插件，在 X 上引发了用户的广泛讨论。有用户表示，“直接告诉 Claude 用 Codex 执行器和 tmux，也是可以达到这种效果的，何必多此一举。”
但 OpenAI Codex 团队成员 Dominik Kundel 在该用户下方回复，可以自己去试试上述提到的方法。Dominik 的言外之意或许是：如果这样可以，那我们还做新插件干什么！
也有用户提出疑问，使用 Codex MCP 和这个新插件有什么区别？
Dominik 在评论区回复该用户时解答道：“Codex MCP 是一个更简洁但功能更有限的界面。该插件底层使用 Codex 应用服务器。它与 Codex 应用使用相同的协议，因此可以更方便地添加功能，例如从应用/CLI 添加实际的审阅功能。由于它不是 MCP，因此也不会像 MCP 那样占用过多上下文窗口空间。如果 MCP 对您来说很好用，那就太好了！这是一个替代方案。”
参考链接：
https://code.claude.com/docs/en/computer-use
https://x.com/search?q=Claude%20code%20compute%20use%20&src=typed_query
