这篇文章来自 OpenAI Codex 团队的开发者体验工程师 Jason,系统梳理了 Codex 桌面应用中三种与计算机交互的方式——Computer Use、Chrome 扩展和应用内浏览器——各自的能力边界和最佳使用场景。
核心问题不是"哪个能点按钮",而是任务需要什么上下文、你愿意暴露多少权限。Computer Use 范围最广,能操控任意已授权的桌面应用(Spotify、Xcode、iOS 模拟器等),代价是速度最慢,因为它走的是"看屏幕→判断→点击→等响应"的视觉循环;Chrome 扩展继承你的浏览器登录态和 Cookie,适合 Gmail、Salesforce、内部仪表盘等需要身份认证的网页任务,且支持多标签页协同;应用内浏览器则高度隔离,不带任何登录状态,专为本地开发调试、视觉 Bug 复现和设计批注反馈设计。
文章还介绍了 Appshot(Mac 上连按两下 Command 截取当前窗口)作为上下文输入手段,以及一个关键原则:能用结构化插件或 MCP 解决的就别用视觉控制,后者留给没有 API 的场景。整体读下来,是一份很实用的 Codex 界面选择决策指南。
以下为文章原文
在这些环境中,Codex 有三种工作方式:Computer Use、Chrome 扩展程序 和 应用内浏览器。它们的重叠程度足以让人困惑。
有用的区别不在于“哪个能点击按钮”,而在于任务需要的上下文,以及你愿意暴露多少你的计算机。
读完这篇帖后,你将知道:
- 在
AGENTS.md 中写什么,让 Codex 自己选择合适的界面
简短版总结:
话虽如此,能用插件或 MCP 就优先用插件。一个 Slack 插件检索线程会比到处点击更精确;一个 GitHub 插件产生的操作比直接操作网页更容易检查。视觉控制最适合用在结构化工具已经做不到的地方!
旁注:本文说明适用于 Codex 桌面应用。Computer Use 目前在支持地区可用于 macOS 和 Windows,Appshots 目前只能在 macOS 上创建。工作区管理员也可以限制个别功能。
1. 一切皆 @Computer
Computer Use 是三种界面中最广的。它能让 Codex 通过窗口、菜单、键盘输入和剪贴板,在你批准的 App 中查看并操作 macOS/Windows 的图形界面。
它通常也是最慢的。结构化插件可以直接调用 API,而 Computer Use 需要看界面、判断点哪里、等应用响应、再检查新状态。这种“视觉循环”会消耗时间,但它的优势是:Codex 可以操作那些完全没有 API 的应用。
在 macOS 上,“慢”不一定代表干扰。Computer Use 可以在后台操作已批准的 App,而你同时正常使用电脑。很多时候我用 Codex 的时候,打开一个 App 才发现 Codex 已经在悄悄完成整个工作流了。
根据你电脑上安装和授权的应用,它可以操作:
- iOS 模拟器、iPhone Mirroring(镜像控制 iPhone)
适合使用 Computer Use 的场景:
- iOS 模拟器、iPhone Mirroring 等纯 GUI 流程
安装:打开 Codex → 设置 → Computer Use → 点击安装。
触发:直接 @Computer,或者明确说“使用 Computer Use”。模型越来越聪明后,它会自己判断什么时候该用。
真实案例:
- 包裹被偷,Amazon 要等 25 分钟接通客服。我让 Codex 用 Computer Use 每 5 分钟检查一次聊天,客服出现后改成每分钟检查,最后成功拿到退款。
- 另一个案例中,Codex 已经用结构化工具完成了 Slack 读反馈 + 改代码 + 渲染视频,但 Slack 集成无法上传文件,于是 Computer Use 帮它点了一下“添加文件”就完成了。
信任边界:这是三种方式里最广的。一次只给它一个清晰的 App 或流程,敏感 App 不用时就关掉,涉及财务、账号、支付、隐私等操作时一定要在场监督。
2. @Chrome(用于多标签页和已登录状态)
Codex Chrome 扩展能让 Codex 访问你已登录的 Chrome 状态(cookie、账号、浏览器配置文件)。
适合场景:
安装:Codex → 插件 → 添加 Chrome → 按提示安装扩展并授权。
触发:@Chrome 或明确说“用我的 Chrome 浏览器”。
优势:
- 支持多标签页协同(可以在多个标签间读取、对比、继续工作)
- 把浏览器工作流理解为“浏览器任务”,而不是一堆屏幕坐标
真实案例:
我把一个已经打开的 Strudel Composer 标签页交给 Codex,让它把音乐改得更有趣。Chrome 直接给了它当前标签页 + 页面的 WebMCP 工具,Codex 就完成了和声重写、形式调整、速度修改、保存等操作,而不需要视觉上到处找控件。
我还用它做长期 Twitter 线程管理,每天让它检查 DM、看新闻、收集反馈并存入知识库(但不发帖)。
信任边界:网站会把 Codex 的操作当成你本人的操作。重要步骤(尤其是发送、发布、购买)一定要要求人工确认后再执行。
结论:如果任务主要在浏览器里完成,优先用 Chrome,而不是 Computer Use。
3. 应用内 @browser(用于你正在构建的网站)
应用内浏览器是 Codex 线程里自带的浏览器。你和 Codex 看到的是同一个渲染页面,特别适合开发和调试 Web 应用。
适合场景:
特点:高度隔离,不使用你的正常浏览器配置文件、cookie、扩展、登录状态。这在不需要登录时是优势,需要登录时就是限制。
安装:插件 → 添加 Browser 插件并启用。
触发:@Browser 或明确要求使用应用内浏览器。
最强用法:注释反馈循环
你可以在页面上直接点击元素或选区留下评论,Codex 会收到带截图和元素上下文的反馈,修改代码后重新打开同一页面继续迭代。
我经常让 Codex 把一个想法直接生成一个 index.html,然后在应用内浏览器里打开,直接在页面上批注设计问题(“这个层级反了”“这个卡片感太强了”“控件间距不够”……),比纯文字描述高效得多。
混合使用示例:先在应用内浏览器打开一个 X 帖子确定上下文,再切换到结构化工具(Twitter CLI)抓取 38 条回复(包括嵌套回复)。
权衡:当需要 Google 登录、通行密钥或浏览器扩展时,就要切换到 Chrome。
Appshots(截图指向)
Appshot 不是第四种控制方式,而是让你把 Codex 指向你当前屏幕内容的方式。
在 Mac 上按 CMD + CMD 即可捕获当前窗口,Codex 会自动附上图片 + 可提取的文字。你可以直接说:“看这个错误 / 这个设计 / 这个设置面板,帮我……”
核心心智模型:
- Browser / Chrome / Computer Use = Codex 实际去操作
Appshots 目前仅支持 macOS 的 Codex 应用,且只捕获最前面的窗口(而非整个桌面),非常适合提供聚焦上下文而不授予完整控制权。