作者：jason；编译：Peggy，BlockBeats
Codex并非只有一种“使用电脑”的方式。实际上，它通过三种不同的入口——Computer Use、Chrome 扩展和应用内 Browser——来操作外部环境。这三种方式虽有重叠，却对应着截然不同的任务场景、权限边界和信任级别。
优先选择结构化工具
文章强调，只要可能，应优先使用插件或 MCP（Model Context Protocol）等结构化工具。例如，Slack 插件能比在网页中点击更精准地检索线程；GitHub 插件的操作也更容易审计。视觉控制应仅用于结构化工具能力无法覆盖的“最后一公里”场景。
Computer Use：覆盖面最广，权限最宽
Computer Use 允许 Codex 在 macOS 和 Windows 上直接操作图形界面，包括窗口、菜单、键盘输入及授权应用的剪贴板。它适用于：
- 原生桌面应用（如 Spotify、金融软件）
- iOS 模拟器或 iPhone Mirroring
- 系统或应用设置
- 无 API 或插件支持的数据源
- 跨多个应用的工作流
- 结构化集成中缺失的最后一步
尽管功能强大，但 Computer Use 速度较慢，且权限边界最宽。建议仅在必要时启用，并在涉及金融、账户、支付等敏感操作时保持人工监督。
安装路径：Codex Settings > Computer Use > Install。触发方式为在提示中使用 @Computer。
@Chrome：处理登录态与多标签页任务
Codex Chrome 扩展可访问用户已登录的 Chrome 浏览器状态，适用于依赖账号、Cookies、浏览器配置文件或多标签页协同的任务，例如：
- Gmail、LinkedIn、Salesforce 等企业工具
- 内部后台系统
- 跨网站的已登录研究
- 依赖浏览器扩展的表单操作
Chrome 扩展将任务理解为浏览器工作流，而非屏幕坐标操作，支持多标签页上下文联动。其信任边界较高——网站可能将 Codex 的操作视为用户本人行为，因此发送、提交、购买等关键步骤需人工审核。
安装方式：在 Plugins 中添加 Chrome 并按指引完成授权。触发关键词为 @Chrome。
应用内 @Browser：专为开发与调试设计
应用内 Browser 是 Codex 线程内置的隔离浏览器，不继承用户常规浏览器的登录状态、Cookies 或扩展。它特别适合：
- 本地开发服务器（如 http://localhost:3000）
- 复现视觉或响应式布局 bug
- 单文件 HTML 原型评审
- 设计元素标注与反馈
其强隔离性保障了安全性，但也限制了对 Google 登录、Passkey 等身份验证流程的支持。当任务无需身份信息时，这是最窄、最安全的选择。
触发方式为在提示中使用 @Browser。
Appshots：提供上下文，而非执行操作
Appshots 并非第四种控制方式，而是将当前屏幕窗口“指给 Codex 看”的工具。在 macOS 上双击 CMD 键即可捕获最前窗口，附带截图与文本上下文。它解决的是输入问题，而 Browser、Chrome 和 Computer Use 解决的是行动问题。
AI Agent 产品化的关键原则
这套分层机制揭示了 AI Agent 产品化的核心逻辑：不是赋予模型无限权限，而是在具体任务中不断收窄权限、明确边界，并让用户保留对关键行动的最终审核权。
跟进进展
关注以下开发者获取最新动态：
- Ari Weinstein（@AriX）：Computer Use 与 Appshots
- James Sun（@JamesZmSun）：Browser 相关更新
- Andrew Ambrosino（@ajambrosino）：Codex 桌面应用发布
- OpenAI Developers（@OpenAIDevs）：Codex 与 OpenAI Platform 新闻