Codex操控电脑的三种方案

公众号名称：AI编程实验室

作者名称：鲁工

发布时间：2026-06-17 10:57

大家好，我是鲁工。

Codex现在能自己用电脑了，这事大家都知道。但它具体怎么用，分三套完全不同的方式，触发词分别是@Computer、@Chrome、@Browser。三个名字都沾着电脑或者浏览器的边，功能又互相有重叠，第一次接触很容易搞混，然后用起来不得其法。

比如说你让它去一个要登录的后台干活，它却用了那个隔离的内置浏览器，在里面死活登不上你的账号；或者一个本地localhost的调试任务，你放它走 Computer Use去肉眼点浏览器，慢得让人想关机重来。

把这三者掰开揉碎讲清楚的，是OpenAI内部做Codex桌面体验的Jason（@jxnlco）。他今天在X上写了篇文章，我对着官方文档把每个surface（可以理解成Codex伸手去操作外部世界的一个入口）的安装、触发、边界都核了一遍，再按咱们国内用户的实际处境聊聊该怎么选。

先给一张总表，记不住细节的，记这张就够用了。

任务需要	用哪个	怎么触发
操作原生桌面app，或者跨好几个app的活	Computer Use	@Computer
你已经登录好的浏览器状态、cookie、标签页	Chrome扩展	@Chrome
本地web app、公开网页、不需要登录的临时会话	内置浏览器	@Browser

@Computer：最标准的Computer Use，但是速度巨慢

Computer Use是三个里管得最宽的。它让Codex在macOS或者Windows上像人一样看屏幕、点菜单、敲键盘、用剪贴板，操作你授权过的app。

代价是慢。​一个结构化的插件能直接调API把活干了，Computer Use得先看一眼界面、判断点哪、等程序响应、再看下一帧，这个视觉循环天生费时间（没错，目前Computer Use的主流方案仍然是截图 + CV）。​但它换来的，是能操作那些没有API的程序。​这点放在国内特别有用，我们日常打交道的不少桌面软件，财务的、办公的、医疗的、各种行业内部系统，根本不对外提供接口，看上去跟AI世界与世隔绝，现在好歹能靠看着点够得着。

macOS上还有个好处，慢不等于打扰。它能在后台操作你授权的app，你该干嘛干嘛。Jason说他经常开着别的程序，回头才发现Codex已经默默把某个流程跑完了。

他举的一个例子我觉得挺有代表性。他有个包裹被偷了，找Amazon客服，系统说要排队约25分钟才接通人工。他就给一个Codex会话开了Computer Use，让它每5分钟去聊天窗口看一眼，人工一上线就改成每分钟盯着、尽量把退款办下来。他去洗了个澡，回来退款已经办好了。这种替你耗着等、来回点的脏活累活，恰恰是它的舒适区。

再比如，我让Codex打开我本地的Zotero文献库，找出发表的影响因子大于5分的颅内动脉瘤相关的论文，放在后台让它操作，5分钟不到就完成了：

安装和触发都不复杂。直接在插件中找到Computer Use安装就好，macOS上还要给两个系统权限，屏幕录制和辅助功能，一个让它看得见，一个让它点得动。触发就是在prompt里@Computer，或者直接说让它用Computer Use。

Computer Use有两个边界需要谨记。它操作不了终端命令行，也操作不了Codex自己，这是OpenAI故意拦的，防止它绕过安全机制。还有Windows上它跑在前台，会接管你的鼠标和当前窗口，没法后台跑，这点跟macOS不一样。

它也是三个里信任边界最大的一个，相当于是把你整台电脑的一部分操作权交出去了。我的建议是一次只给它一个明确的app或者一件事，不相关的敏感程序先关掉，碰到付款、改账户、动密码这类，一定自己盯住了。

@Chrome：带着的登录状态干活

Codex的Chrome扩展，给的是你那个已经登录好一切的Chrome。任务依赖账号、cookie、浏览器配置、已经开着的认证标签页时，那就用@Chrome。

适合的场景很具体：Gmail、LinkedIn、Salesforce、X、公司的客服后台和内部dashboard，还有那种需要跨好几个已登录站点来回查的调研。这些任务的共同点，是离了你的登录态就没法干。翻成咱们这边的处境，就是各种SaaS后台、自家公司的内网系统、需要扫码登录过的管理页。

这一点，我在用Claude Code各种操控浏览器的MCP时深有感触。我经常有需要用Claude读X网页的需求，但使用chrome devtools或者playwright访问X时，会因为没有登录状态而无法访问。但使用官方的Claude in Chrome就能自动承接Chrome端各个网页的登录状态，所以跟Codex一样，Claude in Chrome就相当于@Chrome，chrome devtools或者playwright就相当于@Browser。

安装稍微绕一点。在Codex里进Plugins，找到Chrome，跟着引导装那个Codex的Chrome扩展，再批准Chrome的一堆权限，这个跟Claude in Chrome是一个思路。等扩展显示Connected，开个新对话就能用了，触发还是@Chrome。

它比Computer Use强在两个地方。一是tab groups，一个Codex任务相关的标签页会被归到一组，不会跟你自己开的几十个tab混一起，这跟Claude in Chrome也一样。二是多标签协同，它能在一个tab读上下文、另一个对比、第三个接着干，把整件事当成一个浏览器工作流来理解，而不是Computer Use那种一串屏幕坐标。

Jason举的例子，是他把一个已经打开的Strudel Composer网页丢给 Codex，让它把音乐弄得更有意思。Chrome把选中的标签页，连同这个页面自己暴露出来的结构化工具（WebMCP）一起交给了它，它就直接读了作曲、改了和声和结构、调了速度，存好继续放着，全程不用一个个控件去视觉里找。

再比如，我让Codex使用Chrome打开我的X页面，找到Claude官方账号，总结其最近的三条内容：

这里有个需要注意的点，就是信任边界。网站会把Codex的点击、提交、发消息，当成你本人在操作。页面上的内容本身也属于不可信输入，万一页面里藏了诱导指令，它可能被带跑。所以稳妥的做法是，让它自动去查、去导航、去把草稿拟好，但凡涉及发送、发布、下单、提交，留到你自己过一眼再点。Codex把那个”永远允许浏览器内容”的开关专门标了高风险，是有道理的。

一句话原则：整件事都在浏览器里完成的，优先用Chrome，Chrome给的是浏览器原生的上下文。

@Browser：给你正在做的网站用

第三个是内置浏览器，一个活在Codex对话里的浏览器。你和Codex看的是同一个渲染出来的页面，所以它特别适合做网站、调网站。

它的关键特点是隔离。它不用你正常浏览器的配置、cookie、扩展、登录态、已开标签页，等于一个干净的临时环境。需要账号的时候这是限制，不需要账号的时候这是个好用的边界，你做本地开发、看公开页面，并不希望它碰你的真实身份。

在我看来，这个是三个里跟日常Vibe Coding关系最近的。本地起个dev server、预览个文件、复现一个只在某个屏幕宽度下才冒出来的视觉bug，都走@Browser。

安装是在Plugins里加Browser插件、启用。触发用@Browser，或者直接快捷键Cmd+Shift+B（Windows上Ctrl+Shift+B）。它能形成一个很紧的循环Codex改代码、操作页面、看渲染结果、截图、修完再跑一遍同一个路由。

Jason最推荐的是批注。​审本地页面时，你可以直接点某个元素，或者框选一块区域留评论，旁边还有style控件，能更精确地说清字体、间距、颜色要怎么改。​他的用法是把一个想法或者项目状态，先让Codex生成一个index.html，在内置浏览器里打开，然后不靠写一长串prompt去描述，而是直接在真实页面上点着批注，“这个层级反了”、“别那么像卡片”、“这块控件需要更多空间”，Codex收到评论加截图加元素位置，改文件，重开同一页再来一轮。​他说这个体验比来回传截图和文字，更像跟设计师在同一块画布上改东西。

想再深一层的，文档里还藏着个Developer mode，在Settings > Browser里能打开完整的CDP访问（Chrome 调试协议），JS profiling、console、网络请求都能看，但要注意数据风险。这也是这套东西能闭环的底层原因。

它的取舍同样清楚。隔离让它适合开发，但也意味着它不该拿去跟Google登录、passkey、依赖浏览器扩展的站点死磕。身份重要的活，回到Chrome。

此外，Json还提一个容易跟它们混的东西，Appshots。它不是第四种控制电脑的方式。它干的是另一件事，把你眼前已经有的东西指给Codex看。

Mac上连按两下Command键，它抓取你最前面那个窗口，把截图和能拿到的文字一起塞进当前对话。一个报错、一封邮件、一个设计稿、一个设置面板、一个看不懂的表单，Appshot一下，然后直接问它就行。

记这个区分就够了：Appshots负责指，Browser、Chrome、Computer Use 负责动手。它只抓最前面那个窗口，不是整个桌面，所以是个给聚焦上下文、又不交出控制权的轻办法。但目前这个功能只有macOS的Codex app能用。

让Codex自己选择用哪个

三个surface加一个 Appshots，每次都手动指定用哪个，其实挺累。Jason给的思路，是定一个优先级：能用更结构化、更好审查的工具，就别用更靠肉眼的。

排下来大概是这样。​能用插件或者MCP解决的，优先用插件和MCP，因为它产生的动作最精确、最好检查，一个Slack插件取一条thread，就比让agent在Slack界面里点来点去靠谱得多。​需要登录态的浏览器活，用@Chrome。​本地和公开网页，用@Browser。​只有当一件事落在所有结构化工具都够不着的地方，才上Computer Use去肉眼操作（主要针对本地桌面软件操作）。​视觉控制最该花在这个边界上。

这套逻辑可以直接写进AGENTS.md，让Codex自己按规则选，不用每次都 @。所以可以这么写：

# 选择操作surface的优先级
1. 有对应插件或MCP，优先用，动作更精确、好审查
2. 需要我登录态的浏览器任务，用Chrome（@Chrome）
3. 本地dev server / 公开页面 / 不需要登录，用内置浏览器（@Browser）
4. 原生桌面app、跨 app、或者前面都够不着，才用Computer Use（@Computer）
5. 发送、提交、下单、发布前停下来让我确认。

往大里看一眼，Codex把用浏览器、用整台电脑这些能力一个个补齐，跟它前阵子上线的插件、站点、批注是同一个方向。正如我之前所说，Codex，早就不是Coding App了。

这种场景的分化，让我感觉Claude和Codex在各种赛道上区别越来越明显了。功能是同一个功能，但Codex在App场景上越来越深入，而Claude持续专注的聚焦CLI Coding Harness。

如果觉得有用，点个赞或者在看，也方便更多朋友看到。

感谢您阅读我的文章。我是鲁工，九年AI算法老兵，AI全栈开发者，深耕AI编程赛道与AI科研赛道。

>/ 作者：鲁工

---

内容效果不满意？点此反馈