Codex 使用计算机的三种方式

jason (@jxnlco) 2026-06-17 D 原文
EN Markdown

更新：Computer Use 现已在欧盟/英国上线 ;) 尽情享用吧！

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

它们重叠的部分恰好多到足以让人困惑。

读完这篇文章，你会知道如何安装并触发这三者、什么时候用哪一个、Appshots 和开发者模式（Developer mode）是怎么把它们串起来的，以及该往 AGENTS.md 里加些什么，好让 Codex 能自己挑出合适的操作界面。

简短版是这样：

话虽如此，能用插件或 mcp 的时候就优先用：Slack 插件检索一个会话串，比在 Slack 里点来点去要精确；GitHub 插件产生的动作，比起去操作网站要更容易检查。视觉控制最有用的地方，在于一个结构化工具止步的那个边界处！

1. 一切皆 @Computer

Computer Use 是这三个操作界面里最宽泛的一个。它让 Codex 能在 macOS 和 Windows 上查看并操作图形界面——在你批准的应用里，与窗口、菜单、键盘输入和剪贴板打交道。

它通常也是最慢的。一个结构化插件可以直接调用 API；而 Computer Use 得先看界面、判断该点哪里、等应用响应、再检查下一个状态。这个视觉循环要花时间，但它意味着 Codex 能去对付那些根本不暴露任何有用 API 的应用。

在 macOS 上，慢不一定就意味着碍事。Computer Use 可以在后台操作已批准的应用，同时你照常用你电脑上的其余部分——好多次我一边在用 Codex，一边打开某个应用，才意识到 Codex 一直在悄悄跑某个工作流。

取决于你电脑上装了什么、批准了什么，这可以包括 Spotify、XCode、系统设置、一个 iOS 模拟器，甚至 iPhone 镜像（iPhone Mirroring）应用——来控制你的 iPhone！当一个工作流横跨好几个应用时，它也能在这些应用之间穿梭。

在以下情况用它，当任务依赖于：

  • 一个原生桌面应用，比如 Spotify 或某个理财应用
  • 一个 iOS 模拟器、iPhone 镜像，或者另一种只有图形界面的流程
  • 系统或应用的设置
  • 一个没有插件或 API 的数据源
  • 一个在好几个应用之间穿梭的工作流
  • 一个本来挺有用的结构化集成里缺掉的某个动作

要安装它，在 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 点了 Add file，把那一个缺掉的步骤补上了。

它也是这三者里信任边界最宽的一个。一次只给它一个清晰的应用或流程。不属于当前任务的敏感应用就关掉，审阅权限提示，并在涉及财务、账户、支付、凭据、隐私和系统安全的变更时全程在场。

2. @Chrome 应对多标签页与鉴权

Codex 的 Chrome 扩展让 Codex 能访问你已登录的 Chrome 状态。当任务依赖于你已经拥有的账户、cookies、浏览器配置文件或已鉴权的标签页时，就用它。

对于在下列工具里的工作，这是合适的操作界面：

  • 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 是把这份工作理解成一个浏览器工作流，而不是一串屏幕坐标。

在最近的一个会话串里，我把一个已经打开的 Strudel Composer 标签页交给 Codex，让它把音乐弄得更有意思些。Chrome 给了它选中的那个标签页，以及该页面的 WebMCP 工具。Codex 检查了这段作曲，重写了和声和四分钟的曲式结构，改了节奏，保存了曲目，并让它继续播放着。它不需要靠视觉一个个去找每个控件，因为 Chrome 能把标签页上下文和页面暴露出来的结构化能力结合起来。

我把这个用在一个长期运行的 Twitter 会话串上。指令大致是：

每天用 Chrome 查看我的私信、读相关新闻，并留意我该知道的反馈或提及。把任何值得长期保留的东西加进我的知识库。不要发帖或发消息。

有意思的地方不在于 Codex 能打开 Twitter，而在于这个会话串能随着时间一次次回到同一份已登录的工作上，把它发现的东西和本地文件连接起来，再给我留下一个可供审阅的结果。

信任边界很重要。网站可能会把 Codex 的点击、表单提交和消息，当作是你本人做出的动作。页面内容同样是不受信任的输入。让有后果的步骤保持显式：自动地调研、导航、起草；而在发送、发布、购买或提交之前，要求经过你的审阅。

如果整个任务都待在浏览器里，就优先用 Chrome 而不是 Computer Use。Chrome 拥有任务所需的浏览器原生上下文，又不会把对桌面其余部分的访问权打开。

3. 应用内 @browser，应对你正在搭建的网站

应用内浏览器是一个活在 Codex 会话串内部的浏览器。你和 Codex 共享同一个渲染好的页面，所以它尤其适合搭建和调试 Web 应用。

下面这些事我都从这里开始：

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

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

要把它设置好，在 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 可以改代码、操作页面、检查渲染出来的状态、截图，并在修复之后把这个流程再走一遍。

我最喜欢的部分是标注。当我在审阅一个本地应用时，我可以直接点在某个元素上、或者框选一块区域，然后留下一条评论。那些样式控件还让我能预览，并就文字、字体、间距和颜色发送更精确的反馈。我倾向于把这个和语音输入与引导结合起来：我审阅页面、留下评论，在 Codex 处理这些反馈的同时再排进更多反馈。页面本身成了规格说明。

这对设计工作尤其有用。我常常让 Codex 把一个想法、一份调研资料包，或者一个项目状态，变成单个 index.html 文件，然后在应用内浏览器里把它打开。我不去用另一段提示词试图把整个设计描述清楚，而是直接在真实的页面上标注：「这个层级关系反了」「让这个少点卡片的感觉」「这些控件需要更多空间」，或者「整体都用这套字号比例」。Codex 连同相关的截图和元素上下文一起收到这条评论，改动文件，再重新打开同一个页面，进行下一轮。

为这份项目简介创建一个单文件的 index.html，并在应用内 @Browser 里把它打开。

那个循环，感觉上比来回传截图和文字，要更接近和一位设计师在同一块画布上一起工作。

应用内浏览器作为一个混合工作流的起点也很有用。在另一个会话串里，我在应用内浏览器里打开了一条 X 帖子，让 Codex 去调查那里的讨论。可见的页面确立了我指的是哪条帖子；接着 Codex 切换到 Twitter CLI，取回了 38 条回复，包括浏览器视图里被隐藏掉的嵌套回应。这就是「最窄操作界面」规则的实战：用浏览器拿屏幕上的上下文，再用一个结构化工具去做更深的检索。

这里有个权衡。让应用内浏览器成为一个好的开发界面的那份隔离，也意味着它是个错误的地方——你不该在那里去跟 Google 登录、通行密钥（passkey），或者一个依赖你浏览器扩展的站点较劲。当身份很重要时，转去用 Chrome。

Appshots

Appshot 不是 Codex 控制计算机的第四种方式。它是一种把 Codex 指向你眼前已有上下文的办法。

在 Mac 上，按两下 CMD+CMD 键来捕获最后一个窗口。Codex 会把一张图片和任何可用的文本附加到一个会话串里。你可以对一个报错、一封邮件、一份设计、一个设置面板，或者一个陌生的表单做 Appshot，然后只需说：

这就是我觉得最容易记住的心智模型：

Appshots 是你指向你计算机上某样东西的方式。Browser、Chrome 和 Computer Use 则是 Codex 采取行动的方式。

Appshots 目前是从 macOS 上的 Codex 应用创建的。它们捕获的是最前面的那个窗口，而不是整个桌面，这让它们成为一种有用的办法——在不授予对应用的控制权的前提下，提供聚焦的上下文。

如何跟进这些进展

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