Codex 用电脑的三种姿势：选错模式，你就白烧 Token

摘要：OpenAI Codex 现在有三种操作电脑的方式------内置浏览器、Chrome 扩展和 Computer Use。Jason Liu 的新文章把三者的区别讲透了，但真正有意思的是他背后的那套「操作系统」思维。

最近在 X 上看到一条推文，353 个赞，519 个收藏。发帖的是 Jason Liu，OpenAI Codex 团队的。

他发了一篇文章，标题叫《Three Ways Codex Can Use a Computer》。

说实话，我第一反应不是「又有新功能了」，而是------

终于有人把这事儿讲清楚了。

因为我自己用 Codex 也有段时间了，$browser、@chrome、@computer 这三个东西，我一直搞不清什么时候该用哪个。经常是 @computer 一开，鼠标被接管，啥也干不了，然后才发现其实 @chrome 就够了。

这不仅仅是「选个工具」的问题。选错模式，你烧的 Token 是对的好几倍，效率也差得远。

图片来源：x.com/jxnlco/stat...

图表说明：三种模式的核心定位和适用场景

一、三种模式，不是三个功能，是三层抽象

先说结论：这三个东西不是并列的「功能选项」，它们是三种不同深度的计算机控制方式。理解了这一点，你就不会选错了。

`$browser`：内置浏览器------最轻量的起手式

这是 Codex 自带的沙箱浏览器，打开就能用，不需要装任何插件。但它有几个硬性限制：

不支持登录态------你没法用它访问 Gmail、Slack 这种需要登录的站
不支持你的浏览器 Profile------没有 Cookie、没有扩展、没有历史记录
不支持已有标签页------它是完全隔离的环境

那它适合干嘛？

本地开发服务器 。你在 Codex 里起了个 Vite dev server，让它打开 localhost:3000 看效果，这就是 $browser 的主场。你可以在里面做标注（Annotation），选中一个元素说「这个按钮颜色不对」，Codex 就能看到。

Jason Liu 说了个特别到位的观点：

最小的版本往往就是最好的。让模型做一个单独的 index.html，在侧边栏打开，立刻就能交互。不需要服务器。

我自己也是这么干的。写个简单的 index.html，比 Markdown 输出强太多了。因为一旦输出变成了一个可交互的小应用，你和它的关系就变了------你不再是「读一个文档」，你是「用一个东西」。

`@chrome`：Chrome 扩展------需要登录态时的唯一选择

当你的任务涉及「已登录的网站」时，$browser 就不行了。你需要 @chrome。

安装方式是 Codex 设置里添加 Chrome 插件，然后装一个 Chrome 扩展。装完之后，Codex 就可以在你已登录的 Chrome 里操作了。

这玩意最大的价值在于：

能用你已登录的账号------Salesforce、LinkedIn、内部工具，都可以
可以多标签并行------Codex 会用 Chrome Tab Group 组织任务，不会把你的浏览器搞乱
不会霸占整个浏览器 ------这是和 @computer 的关键区别

Jason Liu 有个很好的例子：他工作电脑上 Twitter 登在 Safari 里。如果用 @computer 去读 Twitter，他就没法用 Safari 了。但用 @chrome 就没问题------Codex 在 Chrome 的几个标签页里干活，Safari 照常用。

不过要注意安全问题。Reddit 上有人提醒：永远不要让 AI Agent 操作你真正在乎的账号。因为 Codex 在你已登录的网站上点击、提交表单，网站会把这些操作视为你本人的行为。

`@computer`：Computer Use------最后的核武器

这是最重的一招。Codex 直接截屏、点击、输入，像人一样操作你的桌面。

它能做的事最多：操作任何 GUI 应用、点击任何按钮、输入任何字段。但代价也最大：

macOS 需要授予屏幕录制和辅助功能权限
Windows 上会霸占前台------鼠标被接管，你啥也干不了
Token 消耗巨大------每个操作都要截图+识别+决策
EU/UK 暂时不可用

所以 Jason Liu 的原则很简单：如果某个任务有专门的插件或 MCP 服务器，优先用那个；只在必须操作 GUI 的时候才用 @computer。

图表说明：根据任务类型选择合适的浏览器模式

二、Jason Liu 真正在聊的是什么？

表面上看，这篇文章在讲三种浏览器模式的区别。但如果你读过 Jason Liu 之前那篇更长的文章 Codex-maxxing，你会发现他真正在聊的东西比这深得多。

他在聊一个概念：Operating Loop（运行循环）。

什么是 Operating Loop？简单说就是------让工作在你离开之后还能继续转。

一个完整的 Operating Loop 需要几个组件：

Durable Thread（持久线程）------一个不会消失的对话，积累了历史和上下文
Shared Memory（共享记忆）------把学到的东西写进文件，不是堆在对话历史里
Computer Use（计算机操作）------让 Agent 能看到和操作你的电脑
Heartbeat（心跳）------让线程可以自己定时醒来检查

这三个浏览器模式，其实只是第 3 点的具体实现。但 Jason Liu 的厉害之处在于，他不是孤立地用这些功能，而是把它们串起来。

比如他举的这个例子：

我在 Slack 里发了个动画视频，然后告诉 Codex：每 15 分钟检查一下这个线程有没有反馈，如果有就重新渲染一个新版本，然后回复并 @ 那个评论的人。

这个循环跨了三个工具：Slack（获取反馈）、Remotion（渲染视频）、@computer（上传文件，因为 Slack MCP 不支持上传）。

这就是 Jason Liu 说的那个关键时刻：

当 Heartbeats、Connectors 和 Computer Use 不再是独立的功能，它们合在一起变成了一个反馈循环，可以在你不在的时候持续运行。

图表说明：Codex Operating Loop 的四个核心组件

三、Heartbeat 才是真正的杀手级功能

很多人看到 Computer Use 觉得很酷，看到 Chrome 扩展觉得很方便。但我觉得整个体系里真正改变游戏规则的是 Heartbeat。

Jason Liu 的「Chief of Staff」线程是这样的：

复制代码

每 30 分钟，检查 Slack 和 Gmail 里有没有需要我回复的消息。
帮我优先排序。
如果有人问我问题，尽可能深入研究并起草回复，但不要发出去。

他回到 Slack 的时候，回复草稿已经放在那里了。他还是决定什么该发什么不该发，但最耗时的「收集上下文」那部分，已经做完了。

还有一个更离谱的例子：

快递被偷了，Amazon 客服要等大概 25 分钟才能连上真人。我开了个 @computer 线程，让它每 5 分钟检查客服有没有上线，上线了就帮我申请退款。等客服回复后，切换到每分钟检查一次，这样能更快回应。

等我洗完澡出来，退款已经搞定了。

这种用法完全超出了「编程助手」的范畴。Codex 变成了一个可以代你处理重复性事务的 Agent。

四、社区怎么看？

这篇推文 519 个收藏，说明很多人觉得这东西有用。但在 Reddit 和其他社区，我也看到了不少不同的声音。

乐观派（约 40%）：

「Computer Use 彻底改变了我的工作流」
「终于可以让 Agent 操作桌面应用了」
「Chrome 扩展解决了登录态的问题，太需要了」

务实派（约 35%）：

「Computer Use 太烧 Token 了，一次简单操作可能就要好几轮截图」
「Windows 上鼠标被接管，根本没法干别的」
「还是在虚拟机里跑比较安全」

不满派（约 25%）：

「EU/UK 用户又被遗忘了吗？Computer Use 和 Chrome 扩展都不可用」
「月付 200 美元，Windows 用户啥新功能都没有」
「别让 AI 操作你的账号，有被封号的风险」

Reddit 上一个特别现实的评论：

我一直用 Chrome DevTools MCP Server。只要在 Codex 里打开它，告诉它用就行。

这说明社区已经有了自己的替代方案。官方的 Chrome 扩展更方便，但不是唯一选择。

另一个关于安全性的提醒也值得注意：有人在 YouTube 上用 Codex 自动操作时，账号被标记为机器人行为。所以------永远不要让 AI Agent 操作你真正在乎的账号。用小号，或者用 VM。

五、我的判断

先说技术判断：这三种模式的设计是合理的。$browser 是沙箱、@chrome 是桥梁、@computer 是核武器。层级分明，递进关系清晰。

但我觉得 Jason Liu 文章里更有价值的东西，不是这三个模式的区别，而是他把它们放进了一个更大的框架里------Operating Loop。

单独看 Computer Use，就是一个截图+点击的工具。但当你把它和 Heartbeat、Memory、Durable Thread 串起来，它就变成了一个可以自主运行的 Agent 的「手脚」。

这才是 Codex 乃至整个 Agent 领域的方向：不是让 AI 更聪明地回答问题，而是让它能在你不在的时候替你干活。

我的实践建议：

从 $browser 开始 ------在侧边栏里预览 index.html，这是成本最低、效率最高的用法
只在需要登录态时才上 @chrome------而且要做好网站白名单，避免意外操作
把 @computer 当最后手段------而且最好在 VM 里跑，避免鼠标被接管
尝试组合使用 ------一个 Heartbeat + @chrome + Memory 的循环，比单独用任何一个功能都强

但我也得说，目前这些功能还有明显的短板。Token 消耗是个大问题------Computer Use 的每一步操作都要截图、识别、决策，一个简单任务可能烧掉你预期 5 倍的 Token。Windows 体验也远不如 macOS------没有后台运行，没有 Locked Use，功能更新总是慢一拍。EU/UK 用户就更别提了。

不过方向是对的。当 Agent 不只是写代码，而是能操作你的电脑、替你跑流程、在你睡觉的时候还在工作------那才是真正的「AI 同事」。

Jason Liu 有一句话说得特别好：

Codex 让我关心的不是 Agent 能不能替我写代码，而是我的工作能不能在我离开之后继续推进。

这句话值得反复咀嚼。

参考资料

话题标签：#OpenAI #Codex #ComputerUse #AIAgent #浏览器自动化 #Chrome扩展