jason (@jxnlco)
2026-06-17
D
原文
---
title: "Codex 使用计算机的三种方式"
author: "jason (@jxnlco)"
source_url: "https://x.com/jxnlco/status/2066970432855581052"
published_at: "2026-06-16T19:45:28.000Z"
fetched_at: "2026-06-17T16:03:44Z"
updated_at: "2026-06-17T16:03:44Z"
language: "zh"
review_status: "draft"
---
# Codex 使用计算机的三种方式
***更新：Computer Use 现已在欧盟/英国上线 ;) 尽情享*用吧！**
Codex 使用计算机有三种方式：Computer Use、Chrome 扩展，以及应用内浏览器。
它们重叠的部分恰好多到足以让人困惑。
读完这篇文章，你会知道如何安装并触发这三者、什么时候用哪一个、Appshots 和开发者模式（Developer mode）是怎么把它们串起来的，以及该往 AGENTS.md 里加些什么，好让 Codex 能自己挑出合适的操作界面。
简短版是这样：
话虽如此，能用插件或 mcp 的时候就优先用：Slack 插件检索一个会话串，比在 Slack 里点来点去要精确；GitHub 插件产生的动作，比起去操作网站要更容易检查。视觉控制最有用的地方，在于一个结构化工具止步的那个边界处！
### 1. 一切皆 @Computer
[Computer Use](https://developers.openai.com/codex/app/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 扩展](https://developers.openai.com/codex/app/chrome-extension)让 Codex 能访问你已登录的 Chrome 状态。当任务依赖于你已经拥有的账户、cookies、浏览器配置文件或已鉴权的标签页时，就用它。
对于在下列工具里的工作，这是合适的操作界面：
- Gmail 或 LinkedIn
- Salesforce 或某个客服控制台
- 内部仪表盘
- 跨多个站点的、需要鉴权的调研
- 依赖你的账户或浏览器扩展的表单
要安装它，在 Codex 里打开 **Plugins**，添加 **Chrome**，然后按照设置流程走。Codex 会引导你安装 [Codex Chrome 扩展](https://chromewebstore.google.com/detail/codex/hehggadaopoacecdllhhajmbjkdcmajg) 并批准 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，应对你正在搭建的网站
[应用内浏览器](https://developers.openai.com/codex/app/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](https://developers.openai.com/codex/appshots) 不是 Codex 控制计算机的第四种方式。它是一种把 Codex 指向你眼前已有上下文的办法。
在 Mac 上，按两下 CMD+CMD 键来捕获最后一个窗口。Codex 会把一张图片和任何可用的文本附加到一个会话串里。你可以对一个报错、一封邮件、一份设计、一个设置面板，或者一个陌生的表单做 Appshot，然后只需说：
这就是我觉得最容易记住的心智模型：
> Appshots 是你指向你计算机上某样东西的方式。Browser、Chrome 和 Computer Use 则是 Codex 采取行动的方式。
Appshots 目前是从 macOS 上的 Codex 应用创建的。它们捕获的是最前面的那个窗口，而不是整个桌面，这让它们成为一种有用的办法——在不授予对应用的控制权的前提下，提供聚焦的上下文。
### 如何跟进这些进展
这些操作界面变化得很快。如果你想要那些有用的细节，而不是等一份巨大的发布总结：
- 关注 [Ari Weinstein (@AriX)](https://x.com/AriX)，了解 Computer Use、Appshots
- 关注 [James Sun (@JamesZmSun)](https://x.com/JamesZmSun)，了解一切与 Browser 相关的事
- 关注 [Andrew Ambrosino (@ajambrosino)](https://x.com/ajambrosino)，了解 Codex 应用的发布，以及更大的桌面产品故事。
- 关注 [OpenAI Developers (@OpenAIDevs)](https://x.com/OpenAIDevs)，了解更广泛的 Codex 与 OpenAI Platform 新闻。