Codex 操控电脑的三种方式（来自Codex团队成员的详细指南）
Codex 操控电脑的三种方式（来自Codex团队成员的详细指南）
Codex 操控电脑的三种方式（来自Codex团队成员的详细指南） Codex 操控电脑的三种方式（来自Codex团队成员的详细指南） Modified June 18 Codex 使用电脑的三种方式 话虽如此，只要可以，优先使用插件或 MCP。Slack 插件能比在 Slack 里点来点去更精确地取回一个线程；GitHub 插件产生的动作也比驱动网站更容易检查。视觉控制最适合用在结构化工具够不到的边界位置。 1. 一切都是 @Computer Computer Use 是这三种界面里覆盖最广的一种。它让 Codex 能在 macOS 和 Windows 上查看并操作图形界面，通过你批准的应用里的窗口、菜单、键盘输入和剪贴板来完成工作。 它通常也是最慢的一种。结构化插件可以直接调用 API；Computer Use 必须观察界面、判断该点哪里、等待应用响应，再检查下一个状态。这个视觉循环会消耗时间，但也意味着 Codex 可以使用那些完全没有可用 API 的应用。 在 macOS 上，慢不一定意味着打扰。Computer Use 可以在后台操作已批准的应用，而你继续使用电脑的其他部分。很多时候我一边用 Codex，一边打开某个应用，才发现 Codex 已经安静地把某个工作流推进了不少。 根据你电脑上安装并批准的应用，它可以操作 Spotify、Xcode、系统设置、iOS 模拟器，甚至通过 iPhone Mirroring 控制你的 iPhone。一个工作流跨越多个应用时，它也可以在应用之间移动。 当任务依赖下面这些东西时，用它： • Spotify 或财务应用这类原生桌面应用 • iOS 模拟器、iPhone Mirroring，或其他只能通过图形界面完成的流程 • 系统或应用设置 • 没有插件或 API 的数据源 • 会跨多个应用移动的工作流 • 某个原本有用的结构化集成里缺失的动作 安装方式：在 Codex 里打开 Settings Computer Use，然后点击 Install。 触发方式： @Computer，或者明确要求 Codex 使用 Computer Use。随着模型变得更好，它在需要时也会越来越能自己调用。 可以先试几个例子： 我最喜欢的一个例子，起因是包裹被偷。Amazon 告诉我，大概要 25 分钟才能接上客服。我给一个 Codex 线程启用了 Computer Use，让它每五分钟检查一次聊天；客服出现后改成每分钟检查一次，并尽力帮我拿到退款。我洗完澡回来时，退款已经处理好了。 Code block Plain Text Copy Use @Computer to open Spotify, find my Discover Weekly playlist, and start it. Do not change my account or subscription settings. Use @Computer to open iPhone Mirroring, reproduce the onboarding bug in the iOS app, and take a screenshot of the failing state. Fix the smallest relevant code path, then run the same flow again. 我也会把 Computer Use 当作结构化工作流的最后一公里。在一个发布视频里，Codex 可以从 Slack 读取反馈、修改代码并渲染新视频，但那个线程可用的 Slack 集成无法上传文件。Computer Use 点击了 Add file，补上了这最后缺失的一步。 它也是三者里信任边界最宽的一种。一次只给它一个明确的应用或流程。不属于任务的敏感应用要保持关闭，认真查看权限提示；涉及金融、账户、支付、凭据、隐私和系统安全变更时，自己要在场。 2. @Chrome 用于多标签页和登录态 Codex Chrome 扩展 让 Codex 可以访问你已登录的 Chrome 状态。当任务依赖你已有的账户、cookie、浏览器配置文件或已认证标签页时，就用它。 它适合处理这些工具里的工作： • Gmail 或 LinkedIn • Salesforce 或客服控制台 • 内部仪表盘 • 跨多个网站的登录态研究 • 依赖你的账户或浏览器扩展的表单 安装方式：在 Codex 里打开 Plugins，添加 Chrome，并按设置流程操作。Codex 会引导你安装 Codex Chrome 扩展，并批准 Chrome 权限。当扩展显示 Connected 后，开启一个新线程。 触发方式： @Chrome，或者明确要求 Codex 使用你已登录的 Chrome 浏览器： Code block Plain Text Copy Use @Chrome to review the open customer account, compare it with the support ticket in the other tab, and draft the missing fields. Stop before submitting. Chrome 任务会在标签页组里运行，这有助于把同一个 Codex 线程相关的标签页放在一起。和应用内浏览器不同，这个界面携带你的浏览器身份，因此能力更强，也更敏感。 另一个主要优势是多标签页控制。Chrome 可以把多个标签页关联到同一个任务，读取一个标签页里的上下文，和另一个标签页对照，再在第三个标签页继续工作。Computer Use 也能从视觉上操作浏览器，但 Chrome 会把这项工作理解成浏览器工作流，而不是一串屏幕坐标。 最近有一个线程里，我把一个已经打开的 Strudel Composer 标签页交给 Codex，让它把音乐做得更有意思。Chrome 把被选中的标签页和页面的 WebMCP 工具交给了它。Codex 检查了作曲内容，重写了和声和四分钟结构，调整了速度，保存了曲目，并让它继续播放。它不需要逐个视觉寻找每个控件，因为 Chrome 可以把标签页上下文和页面暴露出的结构化能力结合起来。 我会把它用于一个长期运行的 Twitter 线程。指令大致是： Code block Plain Text Copy Every day, use Chrome to check my DMs, read relevant news, and look for feedback or mentions I should know about. Add anything durable to my vault. Do not post or send messages. 有意思的地方并不是 Codex 能打开 Twitter，而是这个线程可以长期回到同一个已登录工作环境，把它发现的东西连接到本地文件，并给我留下可审阅的结果。 信任边界很重要。网站可能会把 Codex 的点击、表单提交和消息视为你本人执行的动作。页面内容也是不可信输入。把关键步骤保持为明确授权：可以自动研究、导航和起草；发送、发布、购买或提交之前，要经过你审阅。 如果整个任务都在浏览器里完成，优先用 Chrome，而不是 Computer Use。Chrome具备任务所需的浏览器原生上下文，而无需开放对桌面其他部分的访问权限。 3. 应用内 @Browser 用于你正在构建的网站 应用内浏览器 是一个存在于 Codex 线程内部的浏览器。你和 Codex 共享同一个渲染页面，所以它特别适合构建和调试 Web 应用。 我会从这里开始处理这些任务： • 本地开发服务器 • 基于文件的预览 • 不需要登录的公开页面 • 复现视觉 bug • 检查响应式布局 • 留下元素级设计反馈 关键约束是隔离。应用内浏览器不会使用你的常规浏览器配置文件、cookie、扩展、登录会话或现有标签页。当任务需要账户时，这是限制；当任务不需要账户时，这是有用的边界。 设置方式：在 Codex 里打开 Plugins，添加 Browser 插件并启用。 触发方式：在提示词里提到 @Browser，或者明确要求 Codex 使用应用内浏览器： Code block Plain Text Copy Use @Browser to open vite app on <http://localhost:3000/ , reproduce the mobile overflow bug, fix it, and verify the same route again at desktop and mobile widths. 这会形成一个紧密反馈循环：Codex 可以编辑代码、操作页面、检查渲染状态、截图，然后在修复后重复同一流程。 我最喜欢的部分是标注。当我审查一个本地应用时，可以直接点击某个元素或选择一块区域并留下评论。样式控件也能让我预览并给出更精确的反馈，比如文本、字体、间距和颜色。我通常会把它和语音输入、持续引导结合起来：我审查页面，留下评论，在 Codex 处理时继续排队补充反馈。页面本身会变成规格说明。 这对设计工作尤其有用。我经常让 Codex 把一个想法、研究材料或项目状态做成单个 index.html 文件，然后在应用内浏览器里打开。与其在另一个提示词里试图完整描述整个设计，不如直接标注实际页面：“这个层级关系反了”，“让它少一点卡片感”，“这些控件需要更多空间”，或者“到处都用这套字号层级”。Codex 会收到评论，以及相关截图和元素上下文，然后修改文件，并重新打开同一个页面进入下一轮。 Code block Plain Text Copy Create a single file index.html for this project brief and open it in the in app @Browser. 这个循环感觉更像是在同一块画布上和设计师协作，而不是来回传截图和文字说明。 应用内浏览器也适合作为混合工作流的起点。在另一个线程里，我在应用内浏览器里打开了一条 X 帖子，并让 Codex 调查讨论内容。可见页面确定了我指的是哪条帖子；随后 Codex 切换到 Twitter CLI，取回了 38 条回复，包括浏览器视图隐藏的嵌套回复。这就是“最窄界面规则”的实际用法：用浏览器获取屏幕上的上下文，再用结构化工具做更深层检索。 这里也有取舍。让应用内浏览器成为良好开发界面的隔离性，也意味着它不适合拿来折腾 Google 登录、passkey，或依赖浏览器扩展的网站。当身份很重要时，切到 Chrome。 Appshots Appshot 不是 Codex 控制电脑的第四种方式。它是一种把 Codex 指向你眼前上下文的方法。 Codex 会把图像和任何可用文本附加到线程里。你可以对错误、邮件、设计、设置面板或陌生表单做 Appshot，然后直接用一句话说明需要它处理什么。 这是我觉得最容易记住的心智模型： Appshots 是你用来指向电脑上某个东西的方式。Browser、Chrome 和 Computer Use 是 Codex 采取行动的方式。 Appshots 目前从 macOS 上的 Codex 应用创建。它捕获最前端的窗口，而不是整个桌面，所以它能在不授予应用控制权的情况下，提供聚焦的上下文。 如何跟进这些能力 这些界面变化很快。如果你想看到实用细节，而不是等一篇巨大的发布回顾，可以关注： • 关注 Ari Weinstein（@AriX），了解 Computer Use 和 Appshots • 关注 James Sun（@JamesZmSun），了解 Browser 相关内容 • 关注 Andrew Ambrosino（@ajambrosino），了解 Codex 应用发布和更大的桌面产品故事 • 关注 OpenAI Developers（@OpenAIDevs），了解更广泛的 Codex 和 OpenAI Platform 动态 Computer Use Codex Chrome 扩展 Codex Chrome 扩展 应用内浏览器 Appshot Ari Weinstein（@AriX） James Sun（@JamesZmSun） Andrew Ambrosino（@ajambrosino） OpenAI Developers（@OpenAIDevs） 话虽如此，只要可以，优先使用插件或 MCP。Slack 插件能比在 Slack 里点来点去更精确地取回一个线程；GitHub 插件产生的动作也比驱动网站更容易检查。视觉控制最适合用在结构化工具够不到的边界位置。 1. 一切都是 @Computer Computer Use 是这三种界面里覆盖最广的一种。它让 Codex 能在 macOS 和 Windows 上查看并操作图形界面，通过你批准的应用里的窗口、菜单、键盘输入和剪贴板来完成工作。 Computer Use 它通常也是最慢的一种。结构化插件可以直接调用 API；Computer Use 必须观察界面、判断该点哪里、等待应用响应，再检查下一个状态。这个视觉循环会消耗时间，但也意味着 Codex 可以使用那些完全没有可用 API 的应用。 在 macOS 上，慢不一定意味着打扰。Computer Use 可以在后台操作已批准的应用，而你继续使用电脑的其他部分。很多时候我一边用 Codex，一边打开某个应用，才发现 Codex 已经安静地把某个工作流推进了不少。 根据你电脑上安装并批准的应用，它可以操作 Spotify、Xcode、系统设置、iOS 模拟器，甚至通过 iPhone Mirroring 控制你的 iPhone。一个工作流跨越多个应用时，它也可以在应用之间移动。 当任务依赖下面这些东西时，用它： • Spotify 或财务应用这类原生桌面应用 • iOS 模拟器、iPhone Mirroring，或其他只能通过图形界面完成的流程 • 系统或应用设置 • 没有插件或 API 的数据源 • 会跨多个应用移动的工作流 • 某个原本有用的结构化集成里缺失的动作 安装方式：在 Codex 里打开 Settings Computer Use，然后点击 Install。 触发方式： @Computer，或者明确要求 Codex 使用 Computer Use。随着模型变得更好，它在需要时也会越来越能自己调用。 可以先试几个例子： 我最喜欢的一个例子，起因是包裹被偷。Amazon 告诉我，大概要 25 分钟才能接上客服。我给一个 Codex 线程启用了 Computer Use，让它每五分钟检查一次聊天；客服出现后改成每分钟检查一次，并尽力帮我拿到退款。我洗完澡回来时，退款已经处理好了。 我也会把 Computer Use 当作结构化工作流的最后一公里。在一个发布视频里，Codex 可以从 Slack 读取反馈、修改代码并渲染新视频，但那个线程可用的 Slack 集成无法上传文件。Computer Use 点击了 Add file，补上了这最后缺失的一步。 它也是三者里信任边界最宽的一种。一次只给它一个明确的应用或流程。不属于任务的敏感应用要保持关闭，认真查看权限提示；涉及金融、账户、支付、凭据、隐私和系统安全变更时，自己要在场。 2. @Chrome 用于多标签页和登录态 Codex Chrome 扩展 让 Codex 可以访问你已登录的 Chrome 状态。当任务依赖你已有的账户、cookie、浏览器配置文件或已认证标签页时，就用它。 Codex Chrome 扩展 它适合处理这些工具里的工作： • Gmail 或 LinkedIn • Salesforce 或客服控制台 • 内部仪表盘 • 跨多个网站的登录态研究 • 依赖你的账户或浏览器扩展的表单 安装方式：在 Codex 里打开 Plugins，添加 Chrome，并按设置流程操作。Codex 会引导你安装 Codex Chrome 扩展，并批准 Chrome 权限。当扩展显示 Connected 后，开启一个新线程。 Codex Chrome 扩展 触发方式： @Chrome，或者明确要求 Codex 使用你已登录的 Chrome 浏览器： Chrome 任务会在标签页组里运行，这有助于把同一个 Codex 线程相关的标签页放在一起。和应用内浏览器不同，这个界面携带你的浏览器身份，因此能力更强，也更敏感。 另一个主要优势是多标签页控制。Chrome 可以把多个标签页关联到同一个任务，读取一个标签页里的上下文，和另一个标签页对照，再在第三个标签页继续工作。Computer Use 也能从视觉上操作浏览器，但 Chrome 会把这项工作理解成浏览器工作流，而不是一串屏幕坐标。 最近有一个线程里，我把一个已经打开的 Strudel Composer 标签页交给 Codex，让它把音乐做得更有意思。Chrome 把被选中的标签页和页面的 WebMCP 工具交给了它。Codex 检查了作曲内容，重写了和声和四分钟结构，调整了速度，保存了曲目，并让它继续播放。它不需要逐个视觉寻找每个控件，因为 Chrome 可以把标签页上下文和页面暴露出的结构化能力结合起来。 我会把它用于一个长期运行的 Twitter 线程。指令大致是： 有意思的地方并不是 Codex 能打开 Twitter，而是这个线程可以长期回到同一个已登录工作环境，把它发现的东西连接到本地文件，并给我留下可审阅的结果。 信任边界很重要。网站可能会把 Codex 的点击、表单提交和消息视为你本人执行的动作。页面内容也是不可信输入。把关键步骤保持为明确授权：可以自动研究、导航和起草；发送、发布、购买或提交之前，要经过你审阅。 如果整个任务都在浏览器里完成，优先用 Chrome，而不是 Computer Use。Chrome具备任务所需的浏览器原生上下文，而无需开放对桌面其他部分的访问权限。 3. 应用内 @Browser 用于你正在构建的网站 应用内浏览器 是一个存在于 Codex 线程内部的浏览器。你和 Codex 共享同一个渲染页面，所以它特别适合构建和调试 Web 应用。 应用内浏览器 我会从这里开始处理这些任务： • 本地开发服务器 • 基于文件的预览 • 不需要登录的公开页面 • 复现视觉 bug • 检查响应式布局 • 留下元素级设计反馈 关键约束是隔离。应用内浏览器不会使用你的常规浏览器配置文件、cookie、扩展、登录会话或现有标签页。当任务需要账户时，这是限制；当任务不需要账户时，这是有用的边界。 设置方式：在 Codex 里打开 Plugins，添加 Browser 插件并启用。 触发方式：在提示词里提到 @Browser，或者明确要求 Codex 使用应用内浏览器： 这会形成一个紧密反馈循环：Codex 可以编辑代码、操作页面、检查渲染状态、截图，然后在修复后重复同一流程。 我最喜欢的部分是标注。当我审查一个本地应用时，可以直接点击某个元素或选择一块区域并留下评论。样式控件也能让我预览并给出更精确的反馈，比如文本、字体、间距和颜色。我通常会把它和语音输入、持续引导结合起来：我审查页面，留下评论，在 Codex 处理时继续排队补充反馈。页面本身会变成规格说明。 这对设计工作尤其有用。我经常让 Codex 把一个想法、研究材料或项目状态做成单个 index.html 文件，然后在应用内浏览器里打开。与其在另一个提示词里试图完整描述整个设计，不如直接标注实际页面：“这个层级关系反了”，“让它少一点卡片感”，“这些控件需要更多空间”，或者“到处都用这套字号层级”。Codex 会收到评论，以及相关截图和元素上下文，然后修改文件，并重新打开同一个页面进入下一轮。 这个循环感觉更像是在同一块画布上和设计师协作，而不是来回传截图和文字说明。 应用内浏览器也适合作为混合工作流的起点。在另一个线程里，我在应用内浏览器里打开了一条 X 帖子，并让 Codex 调查讨论内容。可见页面确定了我指的是哪条帖子；随后 Codex 切换到 Twitter CLI，取回了 38 条回复，包括浏览器视图隐藏的嵌套回复。这就是“最窄界面规则”的实际用法：用浏览器获取屏幕上的上下文，再用结构化工具做更深层检索。 这里也有取舍。让应用内浏览器成为良好开发界面的隔离性，也意味着它不适合拿来折腾 Google 登录、passkey，或依赖浏览器扩展的网站。当身份很重要时，切到 Chrome。 Appshots Appshot 不是 Codex 控制电脑的第四种方式。它是一种把 Codex 指向你眼前上下文的方法。 Appshot Codex 会把图像和任何可用文本附加到线程里。你可以对错误、邮件、设计、设置面板或陌生表单做 Appshot，然后直接用一句话说明需要它处理什么。 这是我觉得最容易记住的心智模型： Appshots 是你用来指向电脑上某个东西的方式。Browser、Chrome 和 Computer Use 是 Codex 采取行动的方式。 Appshots 目前从 macOS 上的 Codex 应用创建。它捕获最前端的窗口，而不是整个桌面，所以它能在不授予应用控制权的情况下，提供聚焦的上下文。 如何跟进这些能力 这些界面变化很快。如果你想看到实用细节，而不是等一篇巨大的发布回顾，可以关注： • 关注 Ari Weinstein（@AriX），了解 Computer Use 和 Appshots Ari Weinstein（@AriX） • 关注 James Sun（@JamesZmSun），了解 Browser 相关内容 James Sun（@JamesZmSun） • 关注 Andrew Ambrosino（@ajambrosino），了解 Codex 应用发布和更大的桌面产品故事 Andrew Ambrosino（@ajambrosino） • 关注 OpenAI Developers（@OpenAIDevs），了解更广泛的 Codex 和 OpenAI Platform 动态 OpenAI Developers（@OpenAIDevs） 原帖链接：https://x.com/jxnlco/status/2066970432855581052 原帖链接：https://x.com/jxnlco/status/2066970432855581052 更新：Computer Use 现在已经在欧盟和英国可用 ;) 玩得开心！ Codex 使用电脑有三种方式：Computer Use、Chrome 扩展，以及应用内浏览器。 它们的功能有足够的重叠，容易让人混淆。 读完这篇文章后，你会知道如何安装和触发这三者，什么时候该用哪一种，Appshots 和开发者模式如何把它们连接起来，以及应该在 AGENTS.md 里加入什么，让 Codex 能自己选择合适的界面。 简短版本是：