编者按:这篇文章梳理了 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 新闻。
