换作以前，这意味着我们要么盯着聊天窗口发呆，要么开着网页干别的事，同时隔几分钟切回来看看排到没有，不然一不小心退出去又要重新排队。
新加入 OpenAI 的开发者体验工程师 Jason Liu 选择了第三种方案。他把这件事交给了 Codex。
然后，他去洗澡了；等他回来时，Codex 已经把退款办完了。
每天早上扫一遍私信和新闻，把值得留的东西归档进笔记库；甚至打开一个在线音乐编辑器，重写整首曲子的和声和结构，调好节奏，存档，然后让它继续放着。
这些都是 OpenAI 在 Codex 上最近重点推进的一项能力：让 AI 真正获得操作电脑的能力。
OpenAI 的工程师 Jason Liu 专门写了一篇长文，解释 Codex 现在拥有的三种「电脑操作能力」：Computer Use、Chrome 插件、应用内浏览器。
这三种让 Codex 操作电脑的能力，名字看起来有点绕，功能大概也有些重叠。
很多人第一次看到，都会冒出同一个问题：为什么一个 Agent，要做三套电脑操作的系统？
从功能本身来说，它们都是让 Codex 拥有接管电脑的能力，但 Browser、Chrome 和 Computer Use 背后对应的，其实是 OpenAI 给 Agent 设计的一套行动权限体系。
不同的操作模式，有不同的适应场景。像是能用插件就不要点网页，能直接调用 API 就别让 AI 用识屏操作界面。
就像是如果微信给 Agent 提供了接口，AI 发送消息只需要执行一次函数。
而如果没有接口，Codex 就得先打开微信，找到消息，选择联系人，点击输入框，复制内容，再按发送。
从结果上看，两种方式完成的是同一件事，但从效率和可靠性来看，却完全不在一个量级。所以在 OpenAI 的设计里，Computer Use 更像一个兜底方案。
要搞清楚什么时候用 Computer Use，什么时候用 Chrome 来进行电脑操作，我们结合 Jason Liu 的帖子把这三种授权模式讲清楚，方便大家更好地让 Codex 来操作电脑。
最宽的那道门
先说能力最「大」的：Computer Use。
我们之前分享过多篇 Codex 的使用指南，从目标管理到电脑使用和浏览器操作，里面就曾演示过，使用 Computer Use 能直接修改我们的备忘录。
Codex 能直接自动编辑我们的备忘录
它能看屏幕，能操作几乎任何图形界面，能用键盘、菜单、剪贴板，跟我们授权过的 App 打交道。没有 API 的软件它照样能用，它完全依靠「看着屏幕，自己判断该点哪」。
代价是慢。结构化的插件可以直接调一个接口；Computer Use 得先看清界面、判断点哪、等 App 反应、再看下一屏，这个视觉循环相当浪费时间。
那慢有什么用？
最好是用在那些只有图形界面、压根没接口的地方。而且，在 Mac 上，慢不一定碍事，它能在后台安静地操作我们授权的 App，它工作的时候，我们该干嘛干嘛，回头一看它已经默默跑完了某个流程。
但一走开，也可能不放心，毕竟这也是三者里最宽的一道信任边界，我们等于把整台桌面交了出去。
用 Codex 使用 Claude，问 Codex 好还是 Claude Code 好，Codex 表示不认可 Claude 的回答
OpenAI 官方也反复提醒，一次只给它一个明确的 App 或流程，不相关的敏感软件该关就关，碰到钱、账户、密码、隐私、系统安全的操作，我们还是得守在旁边。
它最妙的用法，可能是用来作为一种补位。目前大多数的 Agent 都能连接第三方的软件，像是连接 Gmail、Slack 等工具。
Codex 也能直接从 Slack 读反馈、改代码、重新渲染视频，但当 Slack 集成工具没法上传文件时，这个时候Computer Use 出手，点了一下「添加文件」，把这一步补上的。
OpenAI 工程师在最后给出的建议是，当任务取决于以下情况时，请使用 Computer Use：
类似 Spotify 的原生桌面应用程序或金融应用程序
iOS 模拟器、iPhone 镜像或其他纯 GUI 流程
系统或应用程序设置
没有插件或 API 的数据源
在多个应用程序之间切换的工作流程
在其他方面都很有用的结构化集成中，缺少一个步骤
带着你身份的门
第二道窄一点：Chrome 插件。它接管的，是我们已经登录好的浏览器。
早些年的 Agent 操作浏览器，要它去 X 搜索某个东西，经常报错说什么没有凭证信息，Chrome 解决的就是这件事。
Cookie、配置、登录态、开着的标签页，这些它都能用，所以 Gmail、LinkedIn、Salesforce、公司内部后台，这类需要登录才能访问到网页信息的任务，就可以交给 Chrome 来完成。
让 Codex 操作浏览器汇总 X 首页的资讯
关键的差别在这里，由于 Chrome 浏览器使用，带着我们的身份，网站会直接把它的点击、提交、发消息，当成是我们本人在操作。能力更强，风险也更大。
Jason Liu 把一个已经打开的在线作曲页面丢给 Codex，告诉它「把音乐弄得更有意思些」。
Chrome 就会自动把这个标签页连同页面自带的工具一起交给 Codex，它读完整首曲子，重写和声、改掉四分钟的曲式、调了速度、存档，最后让它接着播放。
从修改编曲到最后的完美播放，Codex 全程没满屏乱找按钮，因为它能把标签页的上下文，和页面提供的能力拼起来用。
Jason 还提到他使用 Chrome 浏览器使用的另一个案例，是拿它盯一个常年更新的 Twitter 长帖。指令大概是，「每天用 Chrome 看看私信、读相关新闻、找找值得了解的反馈和提及，把能沉淀的都存进笔记库，但别发帖、别发消息。」
Codex 就能打开 Twitter，更有意思的是，这个任务能日复一日回到同一个登录态里，把找到的东西跟我们本地文件接起来，最后交付一份能复核的结果。
所以如果整件事都发生在浏览器里，优先用 Chrome。他也提到使用 Chrome 插件进行任务的理想界面是，
Gmail 或 LinkedIn
Salesforce 或支持控制台
内部仪表盘
跨多个网站的权威研究
取决于您的账户或浏览器扩展程序的表单
干净隔离的门
第三道最窄：应用内浏览器。它就在 Codex 的对话里，我们和它看的是同一个渲染出来的页面。
最要紧的一点是隔离，应用内浏览器不会使用我们平时的浏览器配置、不带 Cookie、没有插件、没有登录态。
所以针对本地开发、调试 Web 应用、复现视觉 bug、看响应式布局，用应用内浏览器大概是最方便的。它能直接改代码、操作页面、看渲染结果、截图，改完自己再跑一遍，直到交付预期的成果。
最有意思的是批注，无论是 Vibe Coding，还是完成真实项目，我们在审核一个本地页面时，可以直接点某个元素，或者圈出一块区域，留一句话，「这个层级反了」「这块别做成卡片」「这些控件得再松一点」。
Codex 会收到带着截图和元素上下文的评论，改完文件，再把同一个页面打开给你看下一版。
浏览器使用和 Chrome 使用不同的地方其实就在于登录状态，这也导致浏览器使用更适合在开发阶段，我们可以和自己的同事一样，直接指着某个地方告诉 Codex，而不是来回甩截图和文字，页面本身，就成了需求文档。
它的代价也来自隔离，让这个 Codex 内置的浏览器去处理 Google 登录、passkey、或者依赖我们浏览器插件的网站，几乎是做不到。
根据 Jason 在博客中的总结，应用内浏览器会特别适合构建和调试 Web 应用程序。
本地开发服务器
文件支持的预览
无需登录的公共页面
重现视觉错误
检查响应式布局
留下元素级设计反馈
在这三项之外，OpenAI 工程师还提到和计算机使用相关的第四项功能是 Appshots。我们之前也介绍过这项功能，在 macOS 平台上，任何场景同时按下空格键左右两边两个 Command 键，就会自动把窗口截图、窗口上下文信息，一起发给 Codex。
他专门提到这项功能的是想表达，Appshots 负责指，Browser、Chrome、Computer Use 负责动手。
一开始，我们一想到「AI 用电脑」，脑子里浮现的画面，大概都是它像人一样移动鼠标、敲键盘、一下一下点过去。好像 AI 越像人在操作电脑，就越厉害。
但 OpenAI 自己的最佳实践，指向的是相反的方向：像人一样点击，是最慢、最脆弱、信任成本最高的那条路。真正想要的，是给 agent 足够结构化的接口，让它尽量用不着去点。
那个看起来最像「AI 终于会用电脑了」的视觉控制，恰恰是整套体系里兜底的一环，结构化工具走不通时，才轮到它上场。
总结下来就是，跨应用走 Computer Use，要带身份/登录态走 Chrome 扩展，干净独立的网页任务走内置浏览器。
本文来自转载APPSO ，观点仅代表作者本人，发现AI平台仅提供信息存储空间服务。
如若转载，请联系原作者；如有侵权，请联系编辑删除。
微信扫一扫 
