Codex 已经具备了直接操控操作系统的能力，这为自动化工作流带来了全新的想象空间。

然而，在实际使用中，Codex 提供了三种截然不同的控制入口：@Computer、@Chrome 和 @Browser。

这三个入口虽然都与“电脑”或“浏览器”相关，但其底层逻辑、适用场景和安全边界有着本质区别。

如果选错了工具，轻则导致任务失败，重则可能面临敏感数据泄露的风险。

本文将深度剖析这三种方案的运行机制，帮助你根据实际需求选择最合适的控制方式。

---

一、 核心方案快速对比

在深入细节之前，我们可以通过下表快速了解这三种方案的核心差异：

| 维度 | @Computer (Computer Use) | @Chrome (Chrome 扩展) | @Browser (内置浏览器) | | :--- | :--- | :--- | :--- | | 控制范围 | 整个操作系统（跨应用、桌面软件） | 用户本机的 Chrome 浏览器 | Codex 内部隔离的沙箱浏览器 | | 登录状态 | 依赖本地已登录的桌面应用 | 共享用户 Chrome 中已登录的 Cookie | 完全隔离，无任何初始登录状态 | | 运行速度 | 极慢（依赖截图与视觉识别循环） | 较快（通过 DOM 和结构化 API） | 较快（通过 CDP 协议与渲染引擎） | | 安全边界 | 极大（需授权屏幕录制与辅助功能） | 中等（受限于浏览器沙箱与扩展权限）| 极小（完全隔离的临时沙箱环境） | | 典型场景 | 财务系统、本地客户端、跨软件协作 | SaaS 后台、内网管理系统、社交媒体 | 本地开发调试、公开网页抓取、UI 批注 |

---

二、 @Computer：基于视觉反馈的全局系统控制

@Computer 是能力范围最广、但运行速度最慢的方案。

它让 Codex 像人类用户一样，通过“看”屏幕、移动鼠标、点击菜单、敲击键盘以及操作剪贴板，来控制你授权的任何桌面应用程序。

1. 运行机制与技术局限

@Computer 的底层主要依赖于“截图 + 计算机视觉（CV）”的闭环控制。

Codex 无法直接读取非标准桌面应用的内部结构化数据，因此它必须经历以下循环：

1. 截取当前屏幕：获取当前桌面的高分辨率图像。
2. 视觉解析：通过多模态模型分析图像，识别出需要点击的按钮、文本框或菜单位置。
3. 执行动作：向系统发送鼠标移动、点击或键盘输入指令。
4. 等待响应：等待程序界面发生变化，然后进行下一次截图。

由于每一次动作都需要经过“截图-传输-模型推理-指令下发”的完整链路，其响应速度天生较慢。

2. 适用场景：无 API 的封闭式桌面软件

尽管速度较慢，但 @Computer 的核心价值在于能够操作那些没有对外提供任何 API 接口的传统软件。

在国内的企业级应用中，存在大量财务、税务、医疗、OA 等本地客户端系统。

这些系统与现代 AI 生态完全脱节，而 @Computer 是目前让 AI 触达这些数据的唯一手段。

在 macOS 上，该功能支持后台静默操作。Codex 可以在不干扰你当前工作的前提下，在后台虚拟桌面上默默完成复杂的报表导出或数据比对任务。

3. 安装与权限配置

在 macOS 或 Windows 上启用 @Computer，需要完成以下步骤：

打开“系统设置” -> “隐私与安全性”。 分别在屏幕录制（Screen Recording）和辅助功能（Accessibility）中，允许 Codex 访问。

1. 在 Codex 的插件市场（Plugins）中找到 Computer Use 并点击安装。
2. 系统权限授权（仅限 macOS）：
3. 在对话框中输入 @Computer 或直接描述任务即可触发。

4. 安全边界与避坑点

• 终端限制：出于安全考虑，Codex 默认被禁止通过 @Computer 操作终端命令行（Terminal），以防止执行恶意脚本。
• 前台占用（Windows）：在 Windows 系统中，@Computer 会直接接管你的物理鼠标和当前活动窗口，运行期间你无法进行其他操作。
• 安全建议：由于该方案拥有极高的系统权限，建议在运行前关闭包含敏感信息（如密码管理器、个人聊天软件）的窗口。涉及支付、修改账户密码等高风险操作时，必须人工介入确认。

---

三、 @Chrome：承接本地登录态的高效浏览器协同

当你的自动化任务完全集中在 Web 端，且需要依赖你现有的账号登录状态时，@Chrome 是最理想的选择。

1. 运行机制：共享 Cookie 与 Session

@Chrome 通过在你的本地 Chrome 浏览器中安装专用扩展程序来实现控制。

它不需要像 @Computer 那样进行繁琐的截图识别，而是直接通过 Chrome 的扩展程序 API 读取网页的 DOM 结构。

最关键的是，它直接共享你当前浏览器中已经登录的所有状态，包括 Cookie、LocalStorage、已认证的标签页等。

2. 适用场景：需要身份认证的 SaaS 与内网系统

任何需要登录才能访问的平台，都是 @Chrome 的主战场：

• 企业内部系统：如公司的 CRM、ERP、客服后台或 Dashboard。
• 社交媒体与专业平台：如自动读取已登录的 LinkedIn、Gmail 或 X（原 Twitter）上的最新消息并进行整理。
• 跨站调研：需要在多个已登录的付费数据库或内部工具之间来回比对数据。

相比于使用 Playwright 等自动化工具需要繁琐地处理扫码登录、验证码绕过，@Chrome 直接利用了你已经建立的安全会话。

3. 安装与配置流程

1. 进入 Codex 的 Plugins 页面，找到 Chrome 插件。
2. 按照引导跳转至 Chrome 应用商店，安装 Codex Chrome Extension。
3. 批准扩展程序所需的权限，确保扩展状态显示为 Connected。
4. 在新对话中输入 @Chrome 即可开始使用。

4. 核心优势：标签页组与多标签协同

• Tab Groups 隔离：Codex 启动的任务标签页会被自动归类到一个独立的标签组（Tab Group）中，不会与你个人正在浏览的网页混淆。
• 多标签并行处理：它能够同时打开多个标签页，在 Tab A 中读取参考文档，在 Tab B 中进行数据对比，并在 Tab C 中生成最终报告。

---

四、 @Browser：完全隔离的 Web 开发与调试沙箱

@Browser 提供的是一个运行在 Codex 内部的、完全隔离的内置浏览器环境。你和 Codex 共享同一个渲染视窗。

1. 运行机制：干净的无状态沙箱

与 @Chrome 相反，@Browser 是一个绝对干净的环境。

它不携带你的任何本地 Cookie、历史记录或浏览器扩展。

这种彻底的隔离性，使其非常适合用于开发测试，避免了本地缓存或既有登录状态对测试结果的干扰。

2. 适用场景：Vibe Coding 与本地页面调试

• 本地 Dev Server 预览：当你使用 Codex 修改本地代码并启动了本地开发服务器（如 localhost:3000）时，可以使用 @Browser 直接打开并预览效果。
• UI 批注与交互式修改：你可以在内置浏览器中直接框选某个不合理的 UI 元素，添加批注（如“这个按钮偏右了”），Codex 会结合 HTML 结构和你的批注直接修改本地代码。
• 公开网页抓取：对于不需要登录的公开技术文档、新闻网站，使用 @Browser 可以快速获取内容，且不会暴露你的个人浏览器指纹。

3. 高级配置：开发者模式（Developer Mode）

在 Settings > Browser 中，你可以开启 Developer Mode。

这会启用完整的 Chrome 调试协议（CDP）支持。

开启后，Codex 能够直接读取 JS 控制台日志（Console Logs）、网络请求（Network Requests）以及进行性能分析（Profiling），从而实现极高精度的前端 Bug 排查。

---

五、 模型服务配置与环境部署

在实际部署和调试 Codex 自动化工作流时，底层的模型调用稳定性与响应速度至关重要。为了方便演示，本文的配置流程采用 iThinkAPI 作为 OpenAI Compatible API 的演示环境。由于 Codex 支持标准的 OpenAI 兼容格式，我们在配置第三方模型服务时，重点需要关注 API Key、Base URL 以及具体的模型名称。在测试复杂任务（如基于视觉的 Computer Use）时，可以灵活选择对应的多模态模型进行测试，具体可用模型和接口格式建议参考服务文档。

Base URL：https://token.ithinkai.cn/v1
API Key：YOUR_API_KEY
Model：以服务文档为准，最新模型 claude-fable-5, gpt-5.5, claude-opus-4-8,gpt-image-2 模型都有几乎在 0.05¥/图，支持 2k,4k

 

第二步：挑选模型与确定分组

在使用之前，请先确认您想使用的模型及其对应的线路。

1.进入模型广场：点击顶部导航栏的 “模型广场”。

2.搜索模型：在搜索框中输入关键词（如 gpt, claude, image 等）查找模型。

3. 确定模型分组（线路选择）：

什么是分组？ 每个分组代表一条不同的调用线路。由于 Tokenrouter 接入了多种资源，同一模型在不同分组下价格和质量不同。

第三步：创建 API 令牌 (Key)

这是最关键的一步，你需要生成一个 Key，并为其绑定你选中的分组。

1.进入控制台：点击顶部导航栏的 “控制台”。

2.令牌管理：在左侧菜单栏选择 “令牌管理” -> “添加令牌”。

3.配置令牌信息：必须勾选你在第二步中看中的分组

限制使用模型：不要限制，留空即可。

4.获取 Key：

六、 Appshots：轻量级的视觉上下文指针

除了上述三种主动控制电脑的方案外，还有一个辅助功能不容忽视：Appshots。

需要明确的是，Appshots 不是第四种控制电脑的方式，它不具备操作能力，而是一个“视觉指针”。

在 macOS 客户端中，你只需连按两下 Command 键，Codex 就会自动截取当前最上层的活动窗口，并将截图和提取出的文本直接发送到当前对话中。

当你遇到报错弹窗、看不懂的配置界面或设计稿时，无需手动截图保存再上传，直接双击 Command 键并进行提问即可。

这种方式只提供当前窗口的静态上下文，不移交任何系统控制权，安全性极高。

---

七、 自动化路由：如何在项目中配置最佳优先级

手动在对话中切换 @Computer、@Chrome 和 @Browser 往往会打断开发节奏。

最佳的实践方式是建立一套优先级规则，并将其写入你项目根目录的 AGENTS.md 或系统提示词中，让 Codex 根据任务属性自行选择最合适的入口。

推荐的路由逻辑如下：

# 自动化操作 Surface 选择指南

1. **结构化工具优先**：如果任务可以通过已安装的特定插件或 MCP（模型上下文协议）解决（例如直接通过 API 读取 Slack 消息），必须优先使用，禁止调用浏览器或桌面控制。
2. **需要登录态的 Web 任务**：如果任务涉及需要用户身份认证的 SaaS 系统、内网平台或社交媒体，必须使用 Chrome 扩展（触发词：`@Chrome`）。
3. **本地开发与公开网页**：如果是本地 Dev Server 预览、UI 样式微调、或访问无需登录的公开文档，必须使用内置沙箱浏览器（触发词：`@Browser`）。
4. **无 API 的桌面软件**：只有当目标软件为本地原生客户端，且没有任何 Web 端或 API 替代方案时，才允许启用全局系统控制（触发词：`@Computer`）。
5. **安全红线**：在执行任何涉及“发送”、“提交”、“下单”或“修改账户密码”的写操作前，必须暂停运行并等待用户手动确认。

通过这种配置，Codex 会在保证操作精确度的同时，最大程度降低视觉控制带来的高延迟和安全风险。

---

八、 常见报错与排错指南

在实际使用这些控制方案时，你可能会遇到以下典型问题，可以参考如下方式进行排查：

1. @Computer 提示 "Permission Denied" 或无法移动鼠标

1. 打开“系统设置” -> “隐私与安全性” -> “辅助功能”。 2. 将 Codex 的开关关闭，然后重新打开。 3. 如果仍不起作用，在终端执行 tccutil reset Accessibility 重置系统辅助功能数据库，然后重新授权。

• 原因：macOS 的安全隐私控制拦截了辅助功能权限。
• 排错方式：

2. @Chrome 无法连接，提示 "Extension Not Found"

1. 点击 Chrome 扩展栏中的 Codex 图标，确认状态是否为绿色的 "Connected"。 2. 检查本地是否有其他代理软件或安全防护软件拦截了本地回环地址（127.0.0.1）的通信。

• 原因：Chrome 扩展未正常激活，或浏览器端口被占用。
• 排错方式：

3. @Browser 无法加载本地 localhost 页面

1. 尝试将 localhost 替换为具体的本地 IP 地址（如 127.0.0.1 或 192.168.x.x）。 2. 确认本地 Dev Server 是否绑定在了 0.0.0.0 端口上。

• 原因：内置沙箱浏览器的网络隔离机制导致其无法直接解析本地回环地址。
• 排错方式：

---

九、 总结

Codex 从一个单纯的“代码生成工具”演变为如今能够深度操控系统与浏览器的“智能 Agent”，其核心在于场景的精准分化。

理解 @Computer、@Chrome 和 @Browser 的边界，不仅能帮助你构建出更流畅的自动化工作流，更能确保你的本地系统安全。

在实际开发中，建议遵循“能用 API 不用浏览器，能用沙箱不用真实浏览器，能用浏览器不用全局桌面”的原则，让 AI 辅助开发既高效又安全。