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

Wed, 17 Jun 2026 12:19:30 +0800

Jason 在 X 上整理了一篇关于 Codex 电脑操作能力的长文，核心问题很实用：Codex 现在可以通过 Computer Use、Chrome 扩展和内置浏览器三种方式“使用电脑”，但它们的边界容易混在一起。

简单说：

能用插件或 MCP 解决时，优先用结构化工具。
需要操作桌面应用、系统设置或没有 API 的界面时，用 @Computer。
任务依赖你已经登录的 Chrome、账号状态、Cookie 或多个标签页时，用 @Chrome。
正在开发网页、调试本地页面、检查响应式布局或做视觉反馈时，用 @Browser。

可视化控制最适合放在结构化工具够不到的边界上。比如 Slack 插件通常比让 Codex 去点 Slack 页面更精确；GitHub 插件产生的动作也比驱动网页更容易检查。只有当 API、插件或 MCP 不能覆盖最后一步时，才让 Codex 去看屏幕、点按钮。

原帖：https://x.com/jxnlco/status/2066970432855581052

1. 用 `@Computer` 操作桌面和原生应用

Computer Use 是三种方式里范围最宽的一种。它让 Codex 在你批准的 macOS 或 Windows 应用里观察图形界面，并通过窗口、菜单、键盘、剪贴板等方式完成操作。

它通常也是最慢的。结构化插件可以直接调用 API；Computer Use 需要看界面、判断该点哪里、等待应用响应，再检查下一步状态。这个视觉循环有成本，但好处是它可以处理那些没有可用 API 的软件。

在 macOS 上，“慢”不一定意味着打扰。Computer Use 可以在被授权的应用里后台工作，你仍然可以继续使用电脑的其他部分。它能处理的对象取决于你安装并授权了哪些应用，可能包括 Spotify、Xcode、系统设置、iOS 模拟器，甚至 iPhone Mirroring。

适合使用 @Computer 的任务：

原生桌面应用，例如 Spotify、财务软件、设计工具；
iOS 模拟器、iPhone Mirroring 或其他只能通过 GUI 操作的流程；
系统设置或应用设置；
没有插件、MCP 或 API 的数据源；
需要在多个桌面应用之间切换的流程；
结构化集成已经完成大部分工作，但最后缺一个界面动作。

安装方式：

打开 Codex 的 Settings。
进入 Computer Use。
点击 Install，按提示完成授权。

触发方式：

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

`1`	`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.`

原文里有一个很能说明边界的例子：Jason 曾经让 Codex 处理 Amazon 被盗包裹的客服等待。Amazon 提示大约要 25 分钟才能接入客服，他让 Codex 每 5 分钟检查一次聊天窗口，客服出现后改成每分钟检查，并尽量完成退款沟通。等他回来时，退款已经完成。

还有一种常见用法是“最后一公里”。例如 Codex 可以通过 Slack 读取反馈、修改代码并渲染视频，但当前线程里的 Slack 集成不能上传文件。这时 Computer Use 只需要点击 Add file，完成最后那个结构化工具缺失的动作。

安全边界也要更严格：Computer Use 的权限范围最宽，最好一次只给它一个明确应用或流程。涉及财务、账号、付款、凭据、隐私和系统安全的动作，要保持人在场，并检查权限提示。

2. 用 `@Chrome` 处理登录态、多标签页和账号相关任务

Codex Chrome 扩展让 Codex 使用你已经登录的 Chrome 状态。只要任务依赖账号、Cookie、浏览器资料、现有标签页或浏览器扩展，就更适合用 @Chrome。

适合使用 @Chrome 的任务：

Gmail、LinkedIn 等需要登录的网站；
Salesforce、客服后台或内部控制台；
公司内部仪表盘；
需要跨多个已登录网站做研究；
表单依赖你的账号、Cookie 或浏览器扩展。

安装方式：

打开 Codex 的 Plugins。
添加 Chrome。
按提示安装 Codex Chrome 扩展并批准权限。
看到扩展显示 Connected 后，开始一个新线程。

触发方式：

`1`	`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 扩展使用的是你的真实浏览器身份，所以能力更强，也更敏感。

Chrome 的另一个优势是多标签页控制。它可以在一个标签页读取上下文，在另一个标签页比较信息，再到第三个标签页继续处理。Computer Use 也能视觉驱动浏览器，但 Chrome 更像是以“浏览器工作流”的方式理解任务，而不是一连串屏幕坐标。

原文提到一个 Strudel Composer 的例子：Jason 把一个已经打开的音乐创作标签页交给 Codex，让它把音乐做得更有意思。Chrome 给了 Codex 当前选中的标签页和页面提供的 WebMCP 工具，Codex 检查作品、重写和声与四分钟结构、修改速度、保存曲目，并让它继续播放。它不需要视觉寻找每个按钮，因为 Chrome 可以把标签页上下文和页面暴露的结构化能力结合起来。

长期任务也适合 Chrome。例如可以让 Codex 每天用 Chrome 检查 X 私信、相关新闻和反馈，把值得长期保存的信息加入本地知识库，但明确要求不要发布或发送消息：

1
2
3

Every day, use Chrome to check my DMs, read relevant news, and look for
feedback or mentions I should know about. Add anything durable to my vault.
Do not post or send messages.

这里真正重要的不是 Codex 能打开 X，而是同一个线程可以持续回到同一组登录态任务里，把看到的信息连接到本地文件，并留下可审查的结果。

Chrome 的信任边界同样要清楚：网站会把 Codex 的点击、提交、发送消息视为你的行为；页面内容本身也可能是不可信输入。比较稳妥的做法是允许它自动研究、导航和起草，但发送、发布、购买、提交之前必须由你确认。

如果整个任务都在浏览器里，而且需要登录态，优先选 Chrome，而不是 Computer Use。

3. 用 `@Browser` 开发和调试网页

内置浏览器是 Codex 线程里的浏览器。你和 Codex 看到的是同一个渲染页面，所以它特别适合网页开发、视觉调试和设计反馈。

适合使用 @Browser 的任务：

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

它最重要的约束是隔离：内置浏览器不使用你的正常浏览器资料、Cookie、扩展、登录会话或现有标签页。任务需要账号时，这是限制；任务不需要账号时，这反而是清晰的安全边界。

安装方式：

打开 Codex 的 Plugins。
添加 Browser 插件。
启用它。

触发方式：

`1`	`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，再用内置浏览器打开。相比用另一段提示词重新描述整个设计，你可以直接在页面上标注：

1
2

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

这样页面本身就变成了规格说明。

内置浏览器也适合做混合流程的起点。原文举了一个 X 帖子的例子：先在内置浏览器打开帖子，让 Codex 确认你指的是哪一条；然后切换到 Twitter CLI 拉取 38 条回复，包括浏览器界面隐藏的嵌套回复。这就是“用最窄的表面建立上下文，再用结构化工具深入检索”。

但如果任务卡在 Google 登录、Passkey、浏览器扩展或账号状态上，就应该从内置浏览器切到 Chrome。

Appshots：指向上下文，不负责执行

Appshots 不是第四种电脑控制方式，而是把你眼前的上下文交给 Codex 的方法。

在 Mac 上，可以按两次 CMD 捕获最近的窗口。Codex 会把图像和可用文本附加到线程里。你可以对错误提示、邮件、设计稿、设置面板或陌生表单做 Appshot，然后告诉 Codex你想让它处理什么。

一个好记的模型是：

Appshots 负责指出你电脑上的东西；Browser、Chrome 和 Computer Use 负责行动。

Appshots 当前从 macOS 的 Codex app 创建，捕获的是最前面的窗口，不是整个桌面。这让它适合提供聚焦上下文，而不必直接授予应用控制权。

怎么选择

如果要把这三种方式放进日常工作流，可以按下面顺序判断：

先看有没有插件、MCP、CLI 或 API。能结构化完成，就不要让 Codex 去点界面。
如果需要操作桌面应用、系统设置、模拟器或多个本机应用，用 @Computer。
如果任务在浏览器里，并且依赖你的登录态、Cookie、扩展或多标签页，用 @Chrome。
如果任务是网页开发、公开页面检查、本地预览或设计标注，用 @Browser。
如果只是想告诉 Codex“看这个窗口”，先用 Appshots 提供上下文，再决定下一步用哪个入口。

这些入口的差别不只是功能差别，也是信任边界差别。越接近你的真实账号和桌面环境，就越应该把目标说清楚，把不可执行的动作写明白，并在提交、发送、付款、发布前保留人工确认。

Chrome扩展 on KnightLi的博客

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

1. 用 @Computer 操作桌面和原生应用

2. 用 @Chrome 处理登录态、多标签页和账号相关任务

3. 用 @Browser 开发和调试网页

Appshots：指向上下文，不负责执行

怎么选择

1. 用 `@Computer` 操作桌面和原生应用

2. 用 `@Chrome` 处理登录态、多标签页和账号相关任务

3. 用 `@Browser` 开发和调试网页