文章作者、来源：X平台

编者按：这篇文章梳理了 Codex 操作外部环境的三种入口：Computer Use、Chrome 扩展和应用内 Browser。三者看似都在解决「让 Codex 使用电脑」的问题，但对应的是不同的任务场景、权限边界和信任级别。

其中，Computer Use 覆盖面最广，可以直接操作 macOS / Windows 上被授权的原生应用、系统设置、iOS 模拟器，甚至跨多个应用完成工作流。它适合那些没有 API、插件或结构化工具支持的 GUI 流程，但代价是速度更慢，权限边界也最宽。Chrome 扩展则适合依赖登录态、Cookies、多标签页和浏览器身份的任务，例如 Gmail、LinkedIn、Salesforce、内部后台，或跨多个网站的已登录研究。应用内 Browser 更偏向开发和调试场景，尤其适合本地服务、视觉 bug、响应式布局和设计批注；它不继承用户正常浏览器的登录状态，能力更窄，但隔离性也更强。

文章的核心判断是，Codex 并不是只有一种「用电脑」的方式，真正重要的是根据任务选择最窄、最安全、最结构化的操作界面。能用插件或 MCP，就不应先动用视觉控制；任务只涉及网页开发，就优先使用应用内 Browser；需要用户浏览器身份和登录状态时，再切换到 Chrome；只有当结构化工具无法覆盖，且任务必须依赖桌面图形界面时，Computer Use 才是最后一公里。

Appshots 则不是第四种控制电脑的方式，而是把当前屏幕上下文「指给 Codex 看」的工具。它解决的是上下文输入问题，而 Browser、Chrome 和 Computer Use 解决的是行动问题。放在一起看，这套分层实际上揭示了 AI Agent 产品化的关键：不是让模型获得无限权限，而是在具体任务中不断收窄权限、明确边界，并让用户保留对关键行动的审核权。

以下为原文：

Codex 使用电脑有三种方式：Computer Use、Chrome 扩展，以及应用内浏览器。

它们之间有一定重叠，刚好重叠到容易让人困惑。

读完这篇文章，你会知道如何安装并触发这三种方式，分别该在什么场景下使用，Appshots 和 Developer mode 如何把它们连接起来，以及该在 AGENTS.md 里写些什么，让 Codex 能自己选择合适的操作界面。

简单版是：

话虽如此，只要可以，还是优先使用插件或 MCP。比如 Slack 插件能比在 Slack 里到处点击更精准地检索一个线程；GitHub 插件产生的操作，也比让 Codex 驱动网页更容易检查。视觉控制最适合用在结构化工具能力到达边界的地方。

一切都可以是 @Computer

Computer Use 是这三种操作界面里覆盖面最广的一个。它让 Codex 能够在 macOS 和 Windows 上查看并操作图形界面，包括窗口、菜单、键盘输入，以及你授权应用里的剪贴板。

它通常也是最慢的。结构化插件可以直接调用 API；Computer Use 则需要观察界面、判断该点击哪里、等待应用响应，再检查下一步状态。这个视觉循环会消耗时间，但也意味着 Codex 可以操作那些完全没有可用 API 的应用。

在 macOS 上，慢并不一定意味着会打扰你。Computer Use 可以在后台操作你授权的应用，而你仍然可以继续使用电脑的其他部分。很多时候，我在用 Codex 时打开某个应用，才发现 Codex 已经在后台安静地完成了一套工作流。

根据你电脑上安装并授权了哪些应用，这些操作对象可以包括 Spotify、Xcode、System Settings、iOS 模拟器，甚至是用 iPhone Mirroring 控制你的 iPhone。它也可以在多个应用之间切换，处理横跨不同应用的工作流。

当任务依赖以下内容时，可以使用它：

原生桌面应用，比如 Spotify 或金融类应用；

iOS 模拟器、iPhone Mirroring，或其他只能通过图形界面操作的流程；

系统或应用设置；

没有插件或 API 的数据源；

需要在多个应用之间切换的工作流；

某个结构化集成里缺失的最后一步操作。

安装方式：打开 Codex 的 Settings > Computer Use，然后点击 Install。

触发方式：提到 @Computer，或者明确要求 Codex 使用 Computer Use。随着模型能力提升，未来在需要时它也会自己调用。

可以先试几个例子：

我最喜欢的一个例子，起因是一个包裹被偷了。Amazon 告诉我，要等大约 25 分钟才能接通客服。我把一个 Codex 线程交给 Computer Use，让它每五分钟检查一次聊天窗口，等客服出现后改为每分钟检查一次，并尽力帮我拿到退款。等我洗完澡回来，退款已经完成了。

我也把 Computer Use 用作结构化工作流里的「最后一公里」。在一次发布视频中，Codex 可以从 Slack 读取反馈、修改代码并渲染新视频，但当时该线程里的 Slack 集成无法上传文件。于是 Computer Use 点击了 Add file，补上了这个缺失的步骤。

它也是三者中信任边界最宽的一种。一次只给它一个明确的应用或流程。当某些敏感应用不是任务的一部分时，保持关闭；仔细检查权限弹窗；涉及金融、账户、支付、凭证、隐私和系统安全变更时，最好人在场监督。

用 @Chrome 处理多标签页和登录状态

Codex Chrome 扩展让 Codex 能访问你已经登录的 Chrome 状态。当任务依赖账号、cookies、浏览器配置文件，或你已经打开并认证过的标签页时，就应该使用它。

这类操作界面适合以下工具中的工作：

Gmail 或 LinkedIn；

Salesforce 或客服后台；

内部仪表盘；

跨多个网站的已登录研究；

依赖你的账号或浏览器扩展的表单。

安装方式：打开 Codex 的 Plugins，添加 Chrome，并按照设置流程操作。Codex 会引导你安装 Codex Chrome 扩展，并批准 Chrome 权限。当扩展显示 Connected 后，开启一个新线程。

触发方式：提到 @Chrome，或者明确要求 Codex 使用你已登录的 Chrome 浏览器：

Chrome 任务会在标签页组里运行，这有助于把某个 Codex 线程相关的标签页放在一起。和应用内浏览器不同，这个操作界面携带的是你的浏览器身份。这让它能力更强，也更敏感。

另一个主要优势是多标签页控制。Chrome 可以让多个标签页与同一个任务关联起来，在一个页面里读取上下文，在另一个页面里对照信息，再到第三个页面继续工作流。Computer Use 也可以通过视觉方式驱动浏览器，但 Chrome 会把任务理解为一个浏览器工作流，而不是一连串屏幕坐标操作。

最近有一个线程，我把一个已经打开的 Strudel Composer 标签页交给 Codex，让它把音乐做得更有趣。Chrome 给了它被选中的标签页，以及这个页面暴露出来的 WebMCP 工具。Codex 检查了乐曲结构，重写了和声和四分钟的整体形式，修改了速度，保存了曲目，并让它继续播放。它不需要在界面上视觉搜寻每一个控件，因为 Chrome 可以把标签页上下文和页面提供的结构化能力结合起来。

我还用它跑一个长期 Twitter 线程。大致指令是：

有意思的地方，不是 Codex 能打开 Twitter，而是这个线程可以长期回到同一个已登录工作环境，把发现的内容连接到本地文件，并留下一个可供我审核的结果。

这里的信任边界很重要。网站可能会把 Codex 的点击、表单提交和消息发送视为你本人采取的行动。网页内容本身也是不可信输入。把后果较重的步骤明确区分出来：研究、导航和起草可以自动完成；发送、发布、购买或提交之前，需要你审核。

如果整个任务都在浏览器里完成，优先用 Chrome，而不是 Computer Use。Chrome 拥有这类任务需要的浏览器原生上下文，同时不会把访问范围扩大到整个桌面。

用应用内 @Browser 处理你正在开发的网站

应用内浏览器是存在于 Codex 线程内部的浏览器。你和 Codex 共享同一个渲染页面，所以它特别适合构建和调试 Web 应用。

我通常会从这里开始处理：

本地开发服务器；

基于文件的预览页面；

不需要登录的公开页面；

复现视觉 bug；

检查响应式布局；

留下针对页面元素的设计反馈。

它最重要的约束是隔离。应用内浏览器不会使用你的普通浏览器配置文件、cookies、扩展、登录会话或现有标签页。当任务需要账号身份时，这是一个限制；但当任务不需要账号时，这反而是一个有用的边界。

设置方式：打开 Codex 的 Plugins，添加 Browser 插件并启用它。

触发方式：在提示词里提到 @Browser，或者明确要求 Codex 使用应用内浏览器：

这会形成一个紧密反馈循环：Codex 可以编辑代码、操作页面、检查渲染状态、截图，然后在修复后重新验证同一流程。

我最喜欢的部分是标注。当我评审一个本地应用时，可以直接点击某个元素，或选中一块区域并留下评论。样式控件也让我可以更精准地预览和反馈文字、字体、间距和颜色。我通常会把它和语音输入、过程引导结合起来：我评审页面、留下评论，并在 Codex 处理当前反馈时继续排队添加更多意见。这个页面本身就变成了规格说明书。

这对设计工作尤其有用。我经常要求 Codex 把一个想法、一份研究包，或一个项目状态整理成一个单文件 index.html，然后用应用内浏览器打开它。相比在另一个提示词里试图描述整套设计，我可以直接在真实页面上标注：「这个层级关系反了」「这里不要那么像卡片」「这些控件需要更多空间」，或者「全站都用这个字号比例」。Codex 会收到带有相关截图和元素上下文的评论，修改文件，然后重新打开同一页面进入下一轮。

这个循环感觉更接近于和一位设计师在同一张画布上工作，而不是来回传截图和文字说明。

应用内浏览器也适合作为混合工作流的起点。在另一个线程里，我用应用内浏览器打开了一条 X 帖子，让 Codex 调查相关讨论。可见页面帮助它确认我指的是哪一条帖子；随后 Codex 切换到 Twitter CLI，检索了 38 条回复，其中包括浏览器视图隐藏掉的嵌套回复。这就是「使用最窄操作界面」原则的实践：用浏览器确认屏幕上的上下文，再用结构化工具做更深层检索。

这里也有取舍。应用内浏览器的隔离性让它成为很好的开发界面，但也意味着它不适合处理 Google 登录、passkey，或依赖浏览器扩展的网站。当身份很重要时，切换到 Chrome。

Appshots

Appshot 不是 Codex 控制电脑的第四种方式。它是一种把 Codex 指向你眼前上下文的方法。

在 Mac 上，按两次 CMD 键，就可以捕捉最近的窗口。Codex 会把一张图片和所有可用文本附加到线程里。你可以对一个错误、一封邮件、一个设计、一个设置面板，或者一个陌生表单做 Appshot，然后直接说：

这就是我觉得最容易记住的心智模型：Appshots 是你用来指向电脑上某个东西的方式；Browser、Chrome 和 Computer Use 则是 Codex 采取行动的方式。

Appshots 目前通过 macOS 上的 Codex 应用创建。它捕捉的是最前面的窗口，而不是整个桌面。这使它成为一种很有用的方式：你可以提供聚焦的上下文，而无需授予对该应用的控制权。

如何跟进这些进展

这些操作界面变化很快。如果你想获得实用细节，而不是等待一篇巨大的发布总结：

关注 Ari Weinstein（@AriX），了解 Computer Use 和 Appshots；

关注 James Sun（@JamesZmSun），了解 Browser 相关内容；

关注 Andrew Ambrosino（@ajambrosino），了解 Codex 应用发布，以及更大的桌面产品叙事；

关注 OpenAI Developers（@OpenAIDevs），了解更广泛的 Codex 和 OpenAI Platform 新闻。