Codex三副眼睛功能详解：Computer、Chrome、Browser 用法与选择指南
之前盘点新功能时我简略提到过这几个工具，但陆续有读者反馈，Computer、Chrome、Browser 三者到底有何不同、什么时候该用哪一个，始终理不清楚。说实话我自己也曾混淆过。它们表面看起来都围着浏览器转，但实际定位和用法差别极大，一旦选错，不仅效率锐减，还会白白浪费 tokens。这篇文章就把三者之间的关系彻底讲透。
三条路径的核心功能
Codex 目前通过三条路径与你的电脑及浏览器交互：
@Computer —— 覆盖面最广的一种。它可以操作桌面上任意获得授权的应用，走的是一条「观察屏幕 → 决定点击位置 → 移动鼠标 → 执行点击 → 再次观察」的虚拟键鼠道路。这条路径慢，但包容性强，即便没有开放 API 的软件也能操控。
@Chrome —— 接入你当前登录过的 Chrome 浏览器状态。你的登录凭据、Cookie、已安装的扩展都能为其所用，适合那些必须凭账户权限才能访问的网站，比如公众号后台、小红书、头条号、知乎、Boss 直聘，以及各种内部业务系统。
@Browser —— Codex 对话窗口中内置的浏览器。适合调试本地开发的页面，或浏览无需登录的公开网站。你和 Codex 共享一个渲染视图，你能直接在页面上点击元素或框选区域留下评论，它能精准理解你说的「这个按钮再放大一点」。
一个使用建议： 当存在专用的插件或 MCP 工具时，优先选择插件。例如飞书 MCP 插件比 @Computer 在飞书界面逐一点击按钮要精准得多，GitHub 插件也比驱动 GitHub 网页更可审计、更可靠。可视化控制最好用在「结构化工具覆盖不到的地方」。
@Computer：无需依赖 Chrome 也能操控浏览器
@Computer 并不直接操作浏览器，但它能操控任何桌面应用——其中也包括浏览器。
安装方式： Codex → 设置 → Computer Use → 点击安装。
调用方式： 在提示词中 @Computer，或直接说「用 Computer Use 做某事」。
适用场景：
- 操作原生桌面应用，如 QQ 音乐、财务软件
- 控制安卓模拟器、小程序等纯 GUI 环境
- 调整系统设置与应用偏好
- 处理没有插件或 API 可用的数据源
- 在多个应用之间串联自动流程
- 为已有 MCP 插件补充某个缺失的操作步骤
真实案例： 我曾用 Codex 搭建过一个工作流——打开微信朋友圈，让 Codex 依次给我的所有动态点赞，它就能完整执行一遍。
安全边界： @Computer 涉及的权限最大，尽量不要用它处理敏感操作；在最终发送指令前最好亲自确认，否则一旦执行可能后悔莫及。
@Chrome：带着你的登录态干活
@Chrome 解决了一个非常现实的痛点：很多网站需要登录后才能操作，而 Codex 应用内浏览器并不具备你的登录状态。这个扩展就是为了把 Chrome 中已有的登录状态借给它用。
安装方式： Codex→插件→添加 Chrome→安装 Chrome 扩展（会跳转至商店）→当扩展显示 Connected 即表示成功。早期 Chrome 扩展偶有安装失败的情况，现在基本已经稳定可用。
调用方式： @Chrome，或直接说「用我的 Chrome 浏览器查一下某内容」。
适用场景：
- 小红书、知乎等个人常用工具
- 飞书后台、客服系统等业务平台
- 内部管理系统
- 跨多个已登录站点的调研任务
- 依赖浏览器扩展或账户权限的操作
优势： 可以同时控制多个标签页。Chrome 能将不同标签关联到同一个任务——在一个标签中读上下文，在另一个标签中做对比，在第三个标签里继续操作。@Computer 虽然也能驱动浏览器，但那是以「看屏幕点坐标」的方式实现的，远不如 @Chrome 对浏览器原生结构的理解高效。
安全边界： 网站会把 Codex 的操作视作你本人的行为。不过许多网站都有反机器人机制，可能会触发验证码，如果没有及时处理，存在被封号的风险，请务必留意。
使用习惯推荐： 如果任务全程都在浏览器内完成，优先考虑 @Chrome 而不是 @Computer。@Chrome 只借用了浏览器访问权，无需把整个桌面控制权交出去。
@Browser：开发调试的快捷通道
@Browser 是 Codex 对话窗口内嵌的浏览器，它的最大优势在于反馈极快：Codex 修改代码 → 在应用内浏览器打开页面 → 查看渲染效果 → 再次修改 → 再次刷新，整个过程都无需离开 Codex。
最实用的功能是页面标注。打开一个本地页面时，可以直接在页面上点击元素或框选区域并留下评论，比如「这个层级反了」「这两个间距不对」「这里字体改小一点」。Codex 收到的评论自带截图和元素上下文，改完后直接重新打开页面即可。
非常适合设计工作流：让 Codex 将项目 brief 输出为 index.html，在内置浏览器中打开，直接对着实际页面标注，而不用在另一条 prompt 里反复描述整个设计。
安装方式： Codex→插件→添加 Browser 插件→启用。
调用方式： @Browser，或「在应用内浏览器打开某个页面」。
适用场景：
- 本地开发服务器上的页面
- 文件预览
- 无需登录的公开网页
- 复现界面 bug
- 检查响应式布局
- 向设计稿提供界面级反馈
一个巧妙的用法： 首先在应用内浏览器打开一个网页，让 Codex 看清上下文，再切换至结构化工具进行深度检索。浏览器的能力只用来定位「我在说什么」，具体执行交给更快的工具。
限制： 应用内浏览器不携带你的 Chrome 登录状态、扩展与已保存密码。需要身份认证的网站，应切换到 @Chrome。
如何选择最适合的路径
三个方式并非越贵越好，也不是覆盖面越宽越佳。
纯浏览器操作且需要登录态 → 选 @Chrome。
本地页面调试、无需登录 → 选 @Browser。
跨应用流程、桌面软件、或为某个插件补足缺失环节 → 选 @Computer。
绝大多数情况下，一条路径就够用了。选对路径，比路径本身更重要。
总结
这三种方式已经推出一段时间了，但很多人依然没有真正用起来，可能仅仅是还不清楚什么时候该选择哪一个。
工具越强大，越要懂得选择。该用 @Chrome 的时候不要启动 @Computer，该用 @Browser 的时候不必折腾插件。路径对了，效率自然翻倍；路径错了，多等几分钟还容易觉得「这功能不行」。
选对路，真的比路本身重要。