ChatGPT 合并 Codex 之后：OpenAI 正在搭建 Agent 工作操作系统

核心结论

这次变化不能简单理解为“ChatGPT 把 Codex 改了个名字”。

更准确的判断是：ChatGPT 桌面端正在从一个聊天应用，重构为统一的 Agent 工作平台。

在这套平台中：

Quick chat 负责即时问答；

ChatGPT Work 负责研究、分析、文档和业务成果交付；

Codex 负责真实代码仓库中的工程执行与验证；

Skills、插件与连接器 提供可复用能力和外部上下文；

Scheduled Tasks 负责持续、定时和条件触发的工作；

多 Agent 模式 负责并行拆解复杂任务。

Codex 并没有消失。它正在从一个独立 Coding App，变成 ChatGPT 工作系统中的软件工程专业模式与执行基础设施。

一、表面是应用合并，实质是产品架构重组

2026 年 7 月 9 日之后，部分用户更新 Windows 版 Codex，发现应用名称和图标变成了 ChatGPT，但安装目录中的可执行文件仍可能保留 Codex.exe，界面中则出现 ChatGPT Work 与 Codex 两个入口。

如果只看这些现象，很容易得出两个错误结论：

Codex 被 Work 取代；

Work 只是 Codex 换了一个面向普通用户的名字。

更合理的解释是：OpenAI 把原本分散的产品入口，重新组织进同一个桌面工作台。

原有 Codex 项目、设置和工作流继续保留；Codex 仍然可以作为主要视图。Windows 中残留的可执行文件名称，更可能属于安装兼容、迁移路径或内部启动机制，而不是两个完全独立的产品同时运行。

二、一个工作台，两种专业模式

理解这次更新最简单的方式是：

Work：给它一个业务目标，让它交付完整成果。

Codex：给它一个工程目标，让它完成并验证代码变更。

两者可以共享账号、模型家族、任务调度和一部分 Agent 基础设施，但面对的工作对象并不相同。

维度	ChatGPT Work	Codex
核心对象	资料、业务系统、文档、数据	仓库、文件、分支、测试环境
主要目标	研究、分析并交付成果	实现、验证并交付代码变更
常见产物	报告、表格、演示、Sites	Diff、Commit、PR、测试结果
默认流程	收集信息 → 分析 → 制作成品	理解仓库 → 修改 → 测试 → 审查
主要用户	产品、运营、咨询、研究、管理	开发者、工程团队、技术负责人

它们不是“强弱关系”，而是工作对象与验收方式不同。

三、ChatGPT Work：从回答问题转向交付成果

传统 ChatGPT 的基本闭环是：用户提出问题，模型生成答案。

Work 的目标更进一步：接手一段持续时间更长、步骤更多、需要多种工具配合的工作流程。

典型能力包括：

搜集并分析公开信息；

读取已连接的文件、应用和内部资料；

把复杂目标拆分成多个步骤；

执行过程中汇报进度并请求确认；

生成文档、表格、演示、报告和 Sites；

通过 Scheduled Tasks 定时、重复或按条件运行任务。

例如：

调研某个市场，结合公司内部资料和公开数据，输出竞争格局、关键指标、风险判断，并制作一份面向管理层的报告和演示文稿。

这个任务的价值不在于生成几段文字，而在于能否完成：

资料收集 → 交叉验证 → 判断 → 结构化表达 → 成品制作。

因此，Work 更接近知识工作中的项目执行者，而不是高级聊天框。

四、Codex：仍然是面向真实工程环境的执行 Agent

Codex 的核心始终不是“更会生成代码”，而是能直接操作和验证真实工程对象。

它围绕以下环境工作：

本地或远程代码仓库；

Git 分支与 Worktree；

Shell、构建工具、测试和 Lint；

文件级 Diff 与行内评论；

Commit、Pull Request 和代码审查；

AGENTS.md、Skills、Hooks 与工程规范；

CLI、IDE、云端任务与 SSH 主机。

一个完整的 Codex 任务通常包含：

理解仓库结构与任务约束；

检查相关文件、依赖和既有实现；

制订修改计划；

跨文件实施变更；

运行测试、构建和静态检查；

根据结果继续修正；

输出可审查的 Diff、Commit 或 PR。

这正是 Codex 与普通代码聊天助手的边界：

聊天助手主要提供答案；Codex 直接修改、执行并验证工程环境。

五、两者是否使用同一个“Codex 底座”

可以较明确确认的部分

OpenAI 对 Work 的产品描述强调了其 Agent 执行能力，而 Codex 已经拥有成熟的长任务循环、文件操作、工具调用和人工确认机制。

因此，两种模式共享以下基础设施是合理的：

目标拆解与子任务管理；

长时间运行的任务循环；

文件和工具调用；

权限确认与人工介入；

并行任务与状态追踪；

Skills、插件和连接器；

本地与远程执行环境。

更偏向架构推断的部分

“共享基础设施”不意味着两个模式完全相同。它们很可能在以下层面采用不同配置：

系统指令和任务策略；

默认开放的工具与权限；

上下文检索和注入方式；

Project、仓库与工作空间抽象；

审查、确认和回滚机制；

产物展示与交付界面。

因此，最合理的技术抽象是：

同一套 Agent Runtime 上的两个专业 Agent。

Work 面向开放式知识工作；Codex 面向约束更强、验证要求更高的软件工程。

六、GPT‑5.6：单 Agent 深度与多 Agent 并行开始分化

这次更新不仅是产品入口的变化，也伴随着 GPT‑5.6 模型体系和推理模式的调整。

原文列出的模型分层包括：

Sol：旗舰能力，适合高难度任务；

Terra：在能力、速度和成本之间平衡；

Luna：强调速度和较低成本；

max：让单个 Agent 获得更多推理时间；

ultra：默认协调多个 Agent 并行执行复杂任务。

其中最重要的不是型号，而是两种计算范式的分离：

纵向扩展：max

让一个 Agent 思考更久，投入更多计算完成探索、检查和修正。

适合：

高难度单路径推理；

复杂架构决策；

需要持续自检的任务。

横向扩展：ultra

让多个 Agent 同时处理不同子任务，再由主 Agent 汇总结果。

适合：

可以并行拆分的复杂工作；

大规模研究、代码审查和跨模块任务；

希望缩短总等待时间的工作流。

这说明“推理强度”已经不再只是高、中、低，而是在向单体深思考与多 Agent 编排两个方向演化。

七、普通 ChatGPT 没有消失，只是被重新安排了位置

部分桌面端用户更新后，只看到 Work 和 Codex，于是误以为普通聊天被删除。

更准确的理解是：桌面端的信息架构发生了调整。

左上角主入口用于切换 Work 与 Codex；

普通即时对话通过侧边栏中的 Quick chat 新建；

移动端主要提供 Chat 与 Work；

完整 Codex 工程界面仍以桌面端为主，移动端可以查看或控制部分远程任务。

这反映出 OpenAI 对桌面端的新定位：

持续工作成为主场景，临时问答退到轻量入口。

八、实际使用时如何选择

选择标准不是“哪个模式更聪明”，而是你的核心工作对象是什么、如何验收结果。

使用 Codex 的情况

当任务包含以下内容时，优先选择 Codex：

对真实仓库做跨文件修改；

创建或管理 Git Worktree；

执行测试、构建和 Lint；

审查 Diff、Commit 和 PR；

根据 AGENTS.md 遵守项目规范；

调用工程 Skills、Hooks 和脚本；

连接 CLI、IDE、SSH 或远程开发环境；

让多个编码 Agent 并行处理模块。

使用 Work 的情况

当任务更接近以下类型时，优先选择 Work：

调研主题并生成完整报告；

从多个业务系统搜集资料；

分析数据并制作表格或演示；

生成可分享网页和 Sites；

定期制作周报、市场监控和运营材料；

把研究、需求和资料转化为成品；

执行不以 Git 仓库为中心的复杂流程。

使用 Quick chat 的情况

以下工作没有必要启动完整 Agent 流程：

快速解释概念；

简短改写；

临时问答；

不需要文件、工具和长期上下文的任务。

九、最有效的模式不是二选一，而是组成流水线

Work 与 Codex 不应该竞争。真正高效的方式，是让它们分别承担最擅长的阶段。

第一阶段：Work 负责研究与定义

收集公开信息和内部资料；

澄清用户需求与业务目标；

生成 PRD、规格和验收标准；

识别风险、依赖和约束；

整理决策记录。

第二阶段：Codex 负责工程执行

读取代码仓库和项目说明；

把需求映射到现有架构；

制订实现方案；

修改代码并运行测试；

输出 Diff、Commit、PR 和审查结果。

第三阶段：Work 负责包装与交付

生成发布说明；

更新项目报告；

汇总测试结果和决策；

制作管理层、客户或市场材料；

建立持续跟踪任务。

完整流程可以表达为：

研究 → 规划 → 工程执行 → 验证 → 沟通与交付

过去，用户需要在 ChatGPT 与 Codex 之间反复复制需求、计划、代码结果和总结。统一桌面应用的长期价值，是逐步减少这种手工搬运。

十、ChatGPT 正在形成一套 Agent 工作操作系统

如果只看界面，这次更新只是 Codex 更换品牌入口，并增加 Work 模式。

但从产品演化看，ChatGPT 正在形成以下结构：

Quick chat：轻量交互层；

Work：通用知识工作 Agent；

Codex：软件工程 Agent；

Skills：可复用能力定义；

插件与连接器：外部系统和数据接入；

Computer Use / Browser Use：环境操作能力；

Scheduled Tasks：持续运行和自动化调度；

多 Agent 模式：复杂任务的并行编排；

本地与远程 Runtime：真正执行工作的基础设施。

这已经不再是一个单纯的聊天产品，而更像一个由模型驱动、以任务为中心、可以安装能力并连接外部系统的工作操作平台。

💡

这里的“操作系统”是产品架构类比，不代表传统意义上的 Windows、macOS 或 Linux。它强调的是统一任务入口、能力管理、执行环境、权限、状态和交付物。

十一、对个人和团队意味着什么

对个人

不必纠结“应该只用 Work 还是只用 Codex”。更有效的问题是：

当前任务的核心对象是什么？

最终交付物是什么？

是否需要真实环境执行？

是否存在可验证的完成标准？

对团队

统一应用真正有价值的前提，是建立清晰的治理规则：

哪类任务交给 Work，哪类任务交给 Codex；

Skills 如何命名、维护和共享；

哪些连接器可以读取公司数据；

哪些步骤必须人工确认；

代码、报告和决策分别如何审查；

自动化任务如何监控、暂停和回滚。

如果没有这些边界，多 Agent 只会加速混乱；如果边界清晰，它才会成为稳定的生产系统。

总结

这次更新真正值得关注的，不是“Codex 是否被 ChatGPT 吃掉”，而是 OpenAI 正在把聊天、知识工作、软件工程和自动化执行整合进统一平台。

短期内，工具边界仍然清晰：

代码、仓库和工程验证 → Codex

跨资料研究与成品交付 → Work

即时问答与简单改写 → Quick chat

长期来看，它们会越来越像同一个工作系统中的不同专业角色。

因此，下一阶段真正重要的问题不再是“ChatGPT 和 Codex 哪个更强”，而是：

如何设计一条由多个专业 Agent 协作完成、能够验证并交付的端到端工作流。