Codex 控制电脑的三种方式：Computer Use、Chrome 扩展、内置浏览器

原文链接：https://x.com/jxnlco/status/2066970432855581052

更新：Computer Use 现已在欧盟/英国可用 ;) 畅用！

Codex 控制电脑共有三种方式：Computer Use、Chrome 扩展和内置浏览器。

它们的功能重叠得刚好让人犯迷糊。

读完这篇，你就会知道如何安装和触发这三种方式、各自该用在什么场景、Appshots 和 Developer mode 是怎么把它们串起来的，以及该往 AGENTS.md 里加点什么，让 Codex 自己挑对工具。

简版总结如下：

话虽如此，能用 plugin 或 MCP 时还是优先用它们：Slack 插件取一条 thread 比在 Slack 里点来点去更精准；GitHub 插件产生的动作比驱动网站更容易审阅。可视控制最有用的地方，恰恰是结构化工具失效的边界地带。

1. 用 @Computer 实现最全功能

Computer Use 是三种方式中覆盖面最广的一种。它让 Codex 通过窗口、菜单、键盘输入和剪贴板，在你授权的应用里看到并操作 macOS 和 Windows 的图形界面。

它通常也是最慢的。结构化插件可以直接调 API；Computer Use 得先看界面、决定点哪儿、等应用响应、再检查下一步状态。这个视觉循环耗时间，但也意味着 Codex 能驾驭那些完全没有可用 API 的应用。

在 macOS 上，慢不一定意味着打扰。Computer Use 可以在后台操作已授权的应用，你照常用电脑的其余部分。很多时候我用着 Codex，顺手打开一个 App，才意识到 Codex 一直在默默地跑某条工作流。

根据你机器上装了什么、授权了什么，它可能包括 Spotify、Xcode、系统设置、iOS 模拟器，甚至 iPhone Mirroring 来远程控制你的 iPhone。它也能在多个 App 之间穿梭，把跨 App 的工作流串起来。

适合的场景包括：

• 原生桌面应用，比如 Spotify 或某个金融软件
• iOS 模拟器、iPhone Mirroring 或其他只有 GUI 的流程
• 系统或应用设置
• 没有插件、没有 API 的数据源
• 需要在多个 App 之间跳来跳去的工作流
• 某个结构化集成里缺的那一个动作

安装方式：在 Codex 里打开 Settings > Computer Use，点 Install。

触发方式：提及 @Computer，或直接让 Codex 用 Computer Use。随着模型变强，需要时它会自己主动调起来。

先试几个例子：

我最喜欢的一个例子，从被偷的快递开始。亚马逊告诉我接通客服大概要 25 分钟。我把一个 Codex 线程挂上 Computer Use，让它每五分钟看一次聊天窗口，客服出现后改成每分钟一次，尽全力把钱要回来。等我洗完澡回来，退款已经到账。

Use @Computer to open Spotify, find my Discover Weekly playlist, and start it. Do not change my account or subscription settings.

Use @Computer to open iPhone Mirroring, reproduce the onboarding bug in the iOS app, and take a screenshot of the failing state. Fix the smallest relevant code path, then run the same flow again.

我也常把 Computer Use 用作“最后一公里”。在一个发布视频里，Codex 能从 Slack 读反馈、改代码、渲染新视频，但那条线程挂的 Slack 集成没法上传文件。Computer Use 帮它点了“添加文件”，补完了那一步。

它也是三种方式中信任边界最广的。一次只交给它一个明确的 App 或流程；不参与任务的敏感应用随手关掉；权限弹窗仔细看；涉及财务、账号、支付、凭证、隐私和系统安全的改动，全程在场。

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

Codex Chrome 扩展 让 Codex 拿到你已登录的 Chrome 状态。任务依赖账号、Cookie、浏览器配置或已登录的标签页时，就该用它。

适合这些工具里的活：

• Gmail 或 LinkedIn
• Salesforce 或某个客服后台
• 内部数据看板
• 跨多个站点的带登录态调研
• 依赖你账号或浏览器扩展的表单

安装方式：在 Codex 的 Plugins 里加 Chrome，跟着引导走。Codex 会带你装上 Codex Chrome 扩展 并批准 Chrome 权限。当扩展显示 Connected，新开一条线程即可。

触发方式：提及 @Chrome 或直接让 Codex 用你登录好的 Chrome：

Use @Chrome to review the open customer account, compare it with the support ticket in the other tab, and draft the missing fields. Stop before submitting.

Chrome 任务跑在标签组里，方便把同一条 Codex 线程的标签聚拢。与内置浏览器不同的是，这条通道带着你的浏览器身份，所以更强，也更敏感。

另一个主要优势是多标签控制。Chrome 能把多个标签页绑在同一个任务上：一个读上下文，另一个做对比，第三个继续推进工作流。Computer Use 也能视觉地操作浏览器，但 Chrome 把它当作一条浏览器工作流来理解，而不是一连串屏幕坐标。

最近一条线程里，我交给 Codex 一个已经打开的 Strudel Composer 标签页，让它把音乐改得更有意思。Chrome 给它选中标签页和该页的 WebMCP 工具。Codex 检查了作曲、重写了和声和四分钟的曲式、改了节奏、保存了曲目，然后让它继续放着。它不需要为每个控件去视觉地找，因为 Chrome 把标签上下文和页面暴露的结构化能力合到了一起。

我用它跑一条长尾 Twitter 线程，指令大致是：

每天用 Chrome 查我的 DM，读相关新闻，找我应该知道的反馈或提及。把值得长期保存的加进我的 vault。不要发帖、不要发消息。

有意思的地方不是 Codex 能打开 Twitter，而是这条线程能随着时间回到同一份带登录态的工作上，把发现连到本地文件，给我留下一份可回看的结论。

信任边界很重要。网站可能把 Codex 的点击、表单提交、发消息当作“你本人”的动作。页面内容也是不可信输入。把后果明显的步骤写清楚：调研、导航、起草自动跑；发送、发布、付款、提交之前，必须经过你的审阅。

如果整件事都在浏览器里完成，Chrome 比 Computer Use 更合适。Chrome 自带浏览器原生的上下文，不需要把桌面其余部分也开放出去。

3. 用内置 @browser 处理你在构建的网站

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

我会在这些场景里首选它：

• 本地开发服务器
• 文件驱动的预览
• 不需要登录的公开页面
• 复现视觉 bug
• 检查响应式布局
• 留元素级的设计反馈

关键约束是隔离。内置浏览器不用你日常的浏览器配置、Cookie、扩展、登录态或现有标签页。当任务需要账号时，这是限制；当任务不需要时，这是有用的边界。

设置方式：在 Codex 的 Plugins 里加 Browser 插件，启用即可。

触发方式：在提示里提及 @Browser 或直接让 Codex 用内置浏览器：

Use @Browser to open vite app on <http://localhost:3000/>, reproduce the mobile overflow bug, fix it, and verify the same route again at desktop and mobile widths.

这就形成一个紧凑的反馈闭环：Codex 改代码、操作页面、检查渲染状态、截图，修完再跑一遍。

我最喜欢的部分是标注。审本地 App 时，我能直接点一个元素或框选一片区域，留一条评论。样式控件还能让我预览、发送更精准的文本、字体、间距和颜色反馈。我常把它和语音输入、steering 一起用：审页面、留评论、一边 Codex 在改一边继续排队反馈。这张页面本身就成了 spec。

这对设计工作尤其有用。我经常让 Codex 把一个点子、调研材料或项目状态做成一个 index.html，然后用内置浏览器打开。与其在下一条 prompt 里描述整个设计，我直接在真实页面上标注：「这个层级反了」「这块别做得像卡片」「这些控件需要更多空间」「全局统一用这套字号阶梯」。Codex 收到带相关截图和元素上下文的评论，改完文件，再打开同一页面进入下一轮。

Create a single-file index.html for this project brief and open it in the in-app @Browser

这个循环比来回传截图和文字更接近“和设计师在同一张画布上协作”。

内置浏览器也常作为混合工作流的起点。在另一条线程里，我用内置浏览器打开一条 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 平台新闻