如果你最近更新了 ChatGPT 桌面客户端，很容易产生一个疑问：左上角既有 ChatGPT，又有 Codex；进入 ChatGPT 后，上方又能在 Chat 和 Work 之间切换。
问题随之而来：Work 和 Codex 到底有什么区别？既然 Work 也能访问本地文件、调用工具、使用浏览器，甚至内置了 Codex 技术，那为什么 OpenAI 还要保留一个单独的 Codex 模式？
这个问题值得认真拆开，因为到了 2026 年，OpenAI 的产品结构已经不是简单的“聊天机器人 + 编程助手”了。它正在形成三个越来越清晰的层次：
- Chat：快速提问、搜索、讨论与日常对话；
- Work：面向长任务、跨应用协作和最终交付物的通用工作 Agent；
- Codex：面向代码库、终端、测试、Diff、PR 和软件工程流程的专业开发 Agent。
先给出最简短的结论：
Work 的核心问题是“这个工作目标怎么完整做完？”；Codex 的核心问题是“这个软件工程任务怎么安全地改进代码库并交付可审核&查验的变更？”
二者正在共享越来越多的底层能力，但它们的上下文中心、交付物、工具界面和工作流设计仍然明显不同。
一、先搞清楚产品层级：Work 不是 Codex 的改名版
OpenAI 在 2026 年 7 月 9 日正式发布 ChatGPT Work。官方把它定义为一个可以跨应用和文件执行操作、在需要时持续工作数小时，并把目标转化成最终成果的 Agent。
更重要的是，OpenAI 同时明确表示：ChatGPT Work 内置了 Codex technology。这说明 Work 并不是从零重新造的一套 Agent，而是吸收了 Codex 在长任务执行、工具使用和 Agentic workflow 上积累的技术。
但“内置 Codex 技术”不等于“Work 就是 Codex 换皮”。OpenAI 仍然把 Codex 保留成桌面客户端中的独立视图，并且单独维护其历史记录、项目和开发工作流。
官方帮助中心给出的定位非常直接：
- Work：Research、Analyze、Create document / spreadsheet / presentation / report / Site；
- Codex：Write or debug code、run tests and commands、review changes、work with a repository。
所以更准确的理解是：Work 是从 Codex 的 Agent 执行能力向通用知识工作扩展，而 Codex 继续保持软件工程领域的专业界面和专业工作流。
二、Work 和 Codex 的核心区别，一张表先看懂
| 维度 | ChatGPT Work | Codex |
|---|---|---|
| 核心定位 | 通用工作 Agent | 软件开发 / 工程 Agent |
| 主要目标 | 从目标到最终成果 | 从任务到可审核&查验代码变更 |
| 典型输入 | 资料、网页、邮件、表格、文档、应用、项目上下文 | 代码库、Issue、终端、测试、Git 状态、开发环境 |
| 典型输出 | 报告、文档、表格、PPT、Site、研究结果、业务操作 | 代码、Diff、测试结果、修复、重构、PR |
| 本地文件 | 桌面端可访问本地文件和应用 | 深度面向本地文件夹、代码仓库与开发工具 |
| 代码库语义 | 可以处理代码，但不是 UI 核心 | Repository 是核心工作对象 |
| Diff / PR 工作流 | 非核心能力 | 内置 Diff 编辑、PR Review、可审核&查验变更 |
| 多仓库 | 可使用文件和项目上下文 | 支持一个项目中的多个 Repository |
| 并行 Agent | 可执行长任务、调度工作 | 专门面向多个 Coding Agent 并行工作 |
| 浏览器 | 支持内置浏览器和云端 Web 工作 | 桌面端同样可使用内置浏览器 |
| 连接应用 / 插件 | 重点能力，适合 Gmail、Slack、Drive 等业务数据 | 同样支持插件、Skills、Apps，更多用于工程上下文与工具 |
| 自动化 | Scheduled Tasks：定时、触发、监控 | Codex Automations：偏工程型自动流程 |
| 历史记录 | 与 Chat 一起出现在 ChatGPT Recents | 历史记录与 ChatGPT 分开 |
| 跨设备 | Cloud Work 可在 Web、Mobile、Desktop 延续 | 桌面为主，移动端通过 Remote 查看/控制支持的任务 |
| 最适合的人 | 知识工作者、运营、研究、产品、销售、财务、管理者、开发者 | 开发者、工程团队、技术负责人、DevOps / SRE |
三、Work 的中心不是“代码”，而是“交付物”
理解 Work 最好的方式，是看 OpenAI 为它设计的成果类型。
官方发布页明确强调，Work 可以从应用与工作流中收集信息，然后创建：
- 文档；
- 电子表格；
- 演示文稿；
- 报告；
- Sites / 轻量 Web 应用；
- 跨应用完成的业务结果。
这意味着 Work 的“工作单元”不是文件，也不是一段代码，而是一个最终要交付的任务结果。
例如你可以给它这样一个任务：
研究 5 个竞品网站，读取 Google Drive 里的历史调研，分析本季度 Excel 数据，生成一份市场报告和汇报 PPT，然后根据结论更新一个项目 Site。
这个任务里可能会涉及网页、表格、文档、浏览器、连接应用，甚至写少量代码，但这些都只是完成目标的手段。
这就是 Work 最核心的设计哲学：“跨工具完成工作”，而不是“围绕某一种工具工作”。
四、Codex 的中心是 Repository 和可验证的软件工程闭环
Codex 也能搜索网页、使用浏览器、访问工具，甚至现在也越来越适合非纯编码工作。但它仍然保留了一套 Work 没有必要重点强化的代码工程 UI。
OpenAI 在新版桌面应用里专门为 Codex 增加和保留了这些能力：
- Inline editing within diffs：直接在 Diff 中编辑；
- Pull request review：在侧边栏审核&查验 PR；
- Multiple repositories：一个项目中同时处理多个仓库；
- Isolated worktrees：多个 Agent 并行工作时隔离代码改动；
- Reviewable diffs：每个任务输出明确、可检查、可丢弃的代码差异；
- Terminal / tests / commands：运行测试和命令是正常工作流的一部分；
- CLI / IDE / Desktop interoperability：任务可以在 Codex CLI、IDE 和桌面应用之间继续。
这些能力看起来只是 UI 细节，但它们反映了 Codex 与 Work 最大的产品差异：
Codex 默认假设“修改代码”是高频动作，因此整个体验围绕可隔离、可验证、可审核&查验、可合并的代码变更设计。
Work 不需要把每个任务都包装成 Git Diff，因为大部分知识工作根本没有 Git。
五、两者都能打开本地文件夹，但意义不同
这是最容易让人困惑的地方。
OpenAI 目前允许桌面端 Work 打开本地文件夹，并在获得权限后使用本地文件和桌面应用；Codex 同样可以打开本地文件夹、Repository、终端和开发工具。
因此，不能简单理解成：
Work = 云端文件Codex = 本地代码
真正的区别是“打开文件夹之后，它们把什么当成核心语义”。
Work 更关心：
- 这里有哪些资料？
- 哪些文件和任务目标有关？
- 我最终要生成什么成果？
Codex 更关心：
- 这是哪个 Repository？
- 当前 Branch / Worktree 是什么？
- 代码改了哪些文件？
- 测试通过了吗？
- Diff 是否正确？
- 能不能变成一个 PR？
所以，同样是访问本地目录，Work 是“项目资料视角”，Codex 是“软件工程视角”。
六、浏览器也是两者共享的，但使用目的不同
新版 ChatGPT 桌面应用提供了内置浏览器，官方帮助文档明确说明：Work 和 Codex 都可以打开它。
你和 Agent 可以看到同一个网页，Agent 能跨多个 Tab 工作、下载文件，也可以在你登录账号后继续操作。
Work 使用浏览器的典型场景可能是：
- 竞争对手研究；
- 查后台数据；
- 读取在线文档；
- 整理供应商资料；
- 操作 Web SaaS；
- 制作报告或更新业务系统。
Codex 使用浏览器则更常见于：
- 检查本地开发页面；
- 验证前端 UI；
- 复现 Web Bug；
- 查看开发文档；
- 测试登录后的产品流程；
- 结合代码修改做视觉验收。
所以工具相同，并不意味着产品定位相同。
七、Work 更强调“连接应用”，Codex 更强调“开发环境”
ChatGPT Work 的一个重要卖点，是能够跨连接的 Apps 和文件执行工作。
比如 Gmail、Slack、Google Drive、Microsoft 365 等应用提供的是业务上下文。Work 可以从这些地方读取最新信息，再继续完成报告、表格、Site 或后续操作。
2026 年 7 月之后，OpenAI 又把原来的 App Directory 迁移成了 Plugin Directory。Plugin 可以同时打包：
- Skills；
- Apps；
- App templates。
而且官方明确说明，Plugin 同时适用于 ChatGPT 与 Codex。
因此这里也出现了明显的“底层趋同”：Work 与 Codex 不再是两个完全封闭的工具生态，它们可以共享越来越多的插件、Skills 和外部服务。
但使用重心仍然不同：
- Work：业务应用是任务上下文和执行对象；
- Codex：开发环境、代码库和工程工具仍是第一现场。
八、自动化：Work 的 Scheduled Tasks 和 Codex Automations 不是一回事
Work 很强调“任务完成以后还可以继续跑”。
Scheduled Tasks 可以：
- 运行一次；
- 按照时间重复运行；
- 监控某个条件变化；
- 在支持的应用事件发生时触发。
例如：
- 每天检查网站和 Dashboard，汇总变化；
- 每周读取 Slack 新消息并刷新会议 Agenda；
- 监控客户反馈并持续整理产品需求；
- 收到新邮件后更新一个 Presentation。
OpenAI 甚至已经支持部分 Work 任务由 Gmail、Slack 和 GitHub PR 事件触发。
Codex 也有 Automations，但官方将二者明确区分：Scheduled Tasks 是 ChatGPT 面向提醒、周期工作、Briefing 和监控的主动工作能力；Codex Automations 则是运行在 Codex 中、更聚焦软件工程的自动流程。
一个很实用的区分方式是：
“每天帮我看业务有没有变化”更像 Work；“每天在代码库里执行某个工程流程”更像 Codex。
九、Work 更像 ChatGPT 的延伸，Codex 仍然是独立工作区
新版桌面客户端虽然把它们放到同一个 App，但信息架构上仍然刻意分开。
Chat 与 Work：
- 一起出现在 Recents；
- 可以按 Chat / Work 筛选；
- 可以使用现有 ChatGPT Projects；
- Cloud Work 可以跨 Web、Mobile、Desktop 同步。
Codex：
- 仍然是左上角单独的全局视图；
- 历史记录与 ChatGPT 历史分开；
- 围绕 Codex Project / Repository 工作；
- 在 ChatGPT 移动端主要通过 Remote 入口查看和控制支持的桌面任务。
这并不是 UI 偶然，而是说明 OpenAI 目前仍把二者视为两个不同的工作语境。
十、Work 和 Codex 的底层到底有多接近？
这里需要非常谨慎地区分“官方已确认”和“合理推断”。
官方已经明确确认的事实包括：
- Work 内置了 Codex technology；
- Work 与 Codex 使用相同的 Agentic usage / credit structure；
- 企业管理员可以为 Work & Codex 一起设置初始模型、推理等级、速度和 Fast Mode；
- 两者都能使用 Plugin；
- 两者都能在桌面端使用 Voice；
- 两者都能使用内置浏览器；
- 两者都能在获得权限后处理本地内容。
这些迹象足以说明：Work 与 Codex 已经属于同一个 Agent 技术家族。
但 OpenAI 并没有公开宣称“Work 和 Codex 使用完全相同的 Agent Runtime、系统提示、工具集合或执行策略”。因此，把 Work 简化成“Codex 套了一个办公 UI”并不严谨。
更合理的理解是：
OpenAI 正在复用 Codex 已经验证过的 Agent 基础设施，但根据知识工作和软件工程这两个不同任务空间，保留不同的产品层和工具编排。
十一、为什么 OpenAI 不干脆把 Work 和 Codex 合并？
从产品设计上看，完全合并反而会让体验变差。
一个财务人员并不需要天天看：
- Git Diff；
- Worktree；
- PR Review；
- Branch；
- 测试命令。
一个开发者在修 Bug 时，也不希望核心界面一直围绕：
- PPT；
- Spreadsheet；
- 邮件；
- 会议 Agenda；
- 业务报告。
因此，同一套底层 Agent 能力之上保留两个专业化 Surface，是非常合理的产品选择。
这和操作系统里的“文件管理器”和“IDE”很像：IDE 当然也能看文件，文件管理器也能打开源码，但两者围绕不同任务做了完全不同的优化。
十二、作为开发者，到底什么时候用 Work，什么时候用 Codex？
对于开发者来说，两者其实不是二选一，而是很适合组成一条完整工作链。
适合用 Work 的场景
- 研究某个技术趋势并形成报告；
- 比较多个开源项目和商业方案；
- 读产品资料、用户反馈、邮件和数据；
- 整理产品需求和 Roadmap；
- 生成 PPT、表格、项目报告；
- 做内容运营、SEO、竞品研究；
- 跨 Slack / Gmail / Drive / Web 完成一个业务任务；
- 需要长期监控、定时汇总或事件触发。
适合用 Codex 的场景
- 接手陌生 Repository；
- 定位和修复 Bug；
- 跨多个文件做重构；
- 运行 Lint / Test / Build；
- 审核&查验 Git Diff；
- 处理 Pull Request；
- 多 Agent 并行修改不同任务；
- 同时维护多个 Repository；
- 需要隔离 Worktree、防止并行改动互相污染；
- 从需求一直推进到可合并代码。
十三、几个最直观的例子
| 任务 | 推荐模式 | 原因 |
|---|---|---|
| 研究 10 个 AI Agent 项目并写行业报告 | Work | 核心是研究、资料整合和成品文章 |
| 修复 WordPress 插件里的 PHP / JS Bug | Codex | 需要 Repo、测试、Diff 和工程验证 |
| 分析用户反馈，生成产品 Roadmap 和汇报 PPT | Work | 跨数据源并最终生成业务交付物 |
| 升级一个 React 项目并修完 ESLint 问题 | Codex | 典型代码库变更任务 |
| 调研竞品 → 写 PRD → 生成原型 Site | Work | 代码只是最终交付中的一个环节 |
| 根据 PRD 真正改生产代码并提交 PR | Codex | 需要软件工程闭环 |
| 每天检查多个 Dashboard 是否异常并发报告 | Work | Scheduled / monitoring workflow |
| 每天在仓库跑一套工程检查并自动修复 | Codex | Codex Automation 更匹配 |
十四、一个容易被忽视的变化：Work 其实是 Codex 成功后的“泛化”
OpenAI 在 Work 发布文章里透露了一个很有意思的数据：Codex 每周已有超过 500 万用户，其中超过 100 万人已经在软件开发之外使用它。
这件事很可能解释了为什么 Work 会出现。
开发者率先证明了一种新的交互方式：
不是“问 AI 一个问题”，而是“给 Agent 一个目标，让它在文件、工具和环境里持续工作，最后交付结果”。
当这种方式在 Coding 场景跑通后，自然可以扩展到研究、运营、销售、财务、分析和内容生产。
所以，从产品演化角度看，可以把两者理解成：
Codex 先把“Agent 真正做事”的模式在软件工程里跑通；Work 再把这种模式推广给整个知识工作世界。
这也是为什么它们既越来越像，又不会马上合并。
十五、最终怎么选？记住一个判断标准就够了
如果你仍然拿不准，可以只问自己一句：
我的最终成果是“一个完成的工作结果”，还是“一个经过验证的代码库变更”？
如果答案更偏前者，用 Work。
如果答案更偏后者，用 Codex。
当然，两者边界会继续变得模糊。Work 已经能访问本地文件、使用浏览器和 Codex 技术；Codex 也能用插件、Web 和各种非代码数据。但从 OpenAI 目前的产品设计来看，二者并不是重复功能，而是同一代 Agent 技术在两个不同工作空间中的专业化落地。
对于开发者来说，真正高效的方式也许不是纠结“只能选一个”，而是：
用 Work 做研究、规划、资料整合和最终业务交付；用 Codex 接手代码库，把计划转化成可测试、可审核&查验、可合并的软件变更。
评论