OpenAI Codex 中三种操作电脑能力：Computer Use、Chrome Extension 和 in-app Browser 分别怎么用？

Codex 团队 @jxnlco 这篇文章强烈推荐阅读：
1. @ Browser：线程内隔离浏览器
· 用于本地开发、视觉调试、设计迭代
· 无登录态、无扩展
2. @ Chrome：你的真实 Chrome 身份
· 多标签、已登录 SaaS、跨站工作流
· 操作算你的，敏感度高
3. @ Computer：整台桌面 GUI
· 原生 App、系统设置、无 API 流程
· 最慢、信任面最广

展开看看怎么选、怎么用

1. @ Browser — 线程内隔离，专做 Web 开发
是什么： 线程内浏览器，你与 Codex 共享同一页面，适合 build/debug。
何时用： localhost、单文件预览、公开页、响应式/视觉 Bug、元素标注改设计。
约束： 无 Cookie/扩展/登录态——要 Google 登录或依赖扩展 → 换 Chrome。
亮点： 改代码 <-> 看页面闭环极短；标注即规格。可先 Browser 定上下文，再 CLI/API 深抓。
触发： Plugins → Browser；对话 @ Browser。

2. @ Chrome — 你的 Chrome 身份 + 多标签
是什么： 访问已登录 Chrome：Cookie、扩展、已有标签。
何时用： Gmail、Salesforce、内部 Dashboard 等需账号的 Web；多标签对照（客户页 vs 工单页）；页面有 WebMCP 时可结构化 + 浏览器上下文。
vs Computer： 浏览器任务优先 Chrome——理解 DOM/标签，不是点坐标。
触发： Plugins → Chrome → Connected → 新线程；对话 @ Chrome。
边界： 操作视同本人；页面内容不可信。可自动研究/草稿，发送/购买/提交须人工确认。

3. @ Computer — 桌面 GUI，最广最慢
是什么： 通过窗口、菜单、键盘、剪贴板操作已授权的 macOS/Windows 应用。
何时用： 无 API 的原生 App、系统设置、模拟器/iPhone 镜像、跨 App 串联，或结构化工具差「最后一步 UI」（如 Slack 不能上传文件）。
代价： 视觉循环慢（看屏 → 点击 → 等响应 → 再看），但 macOS 上常可后台跑。
触发： Settings → Computer Use → Install；对话 @ Computer。
边界： 信任面最大。一次一个 App/流程；敏感 App 不用即关；涉及账号、支付、安全须人在场审。

Appshots：第四种误解
Appshots 不是第四种控制方式，而是把当前上下文指给 Codex：
· Mac 上 双 Cmd 捕获最前窗口（非整屏）
· 附带图像与可用文本进线程
· 只给上下文，不给控制权
记忆法：Appshots = 指向；Browser / Chrome / Computer = 行动。

决策框架（可写进 AGENTS.md）
1. 有插件/MCP/API 且能覆盖任务？ → 用结构化工具
2. 本地 dev / 无登录 / 视觉调试 / 设计标注？ → @ Browser
3. 需要已登录 Chrome、多标签、SaaS 控制台？ → @ Chrome
4. 原生 App、系统设置、模拟器、跨 App、API 缺失的最后一步？ → @ Computer
5. 只想让 Codex 看见某窗口、不必操作？ → Appshot（双 Cmd）

三个典型故事背后的模式
1. Amazon 退款： Computer Use + 定时轮询 + 状态切换（5 分钟 → 1 分钟）—— 无 API 的长等待客服流。
2. Slack 发视频： 结构化读 Slack + 改代码 + 渲染，Computer Use 只补「上传文件」—— 结构化为主，视觉为最后一步。
3. Strudel / Twitter： Chrome 或 Browser 建立上下文，页面工具或 CLI 做重活—— 界面定意图，工具做深度。