同一个 Agent，两种工作台：ChatGPT Work 与 Codex 架构拆解

导语

2026 年 7 月 9 日，OpenAI 把 Codex 的能力进一步带进 ChatGPT 桌面端，并推出了 Work mode。

很多人的第一反应是：

Work 是不是一个新的 Agent？
它和 Codex 的底层架构有什么区别？
做研究、写文档、改代码时，到底该选哪个？

OpenAI 官网给出的答案很关键：Work mode 和 Codex 使用同一个 agent，能力也有重叠。

真正不同的，不是“谁更聪明”，而是产品把同一个代理内核包装成了两种工作台：

Work 面向研究、分析、文档、演示和表格，优先呈现可以直接审阅的成品；
Codex 面向软件开发，主动暴露 Git、终端、Diff、测试和 Pull Request 等工程细节。

这篇文章不做功能清单，而是从架构角度拆解它们：同一个 Agent 如何接收上下文、调度 Memory、压缩长对话、按需加载工具、进入执行环境，并在权限边界内完成任务。

一、先记住结论：不是两个大脑，而是两套驾驶舱

Chat、Work 和 Codex 可以理解为三个不同层级的交互入口。

入口	更适合什么任务	默认交付方式
Chat	问答、搜索、讨论、短文案	一次回答或多轮对话
Work	有明确结果的多步骤知识工作	文档、演示、表格、分析等可审阅成品
Codex	需要开发工具和技术细节的软件工程	代码修改、Diff、测试结果、分支或 PR

官网明确说明，Work 与 Codex 共用同一个 agent。桌面应用切换的主要是界面、默认表达方式和结果展示方式。

因此，更准确的架构不是：

Work Agent + Codex Agent

而是：

流程图

你可以把它想成同一台车的两套驾驶舱。

Work 把复杂机械结构藏在下面，让你关注目的地和交付物；Codex 则打开仪表、引擎状态和维修面板，让开发者看见执行细节并随时介入。

二、第一层：上下文从哪里来

Agent 要完成工作，首先需要拿到正确的上下文。

Work 可以使用当前对话、上传文件、项目资料、工作区资源，以及通过插件连接的外部系统。根据企业配置和用户权限，这些来源可能包括文档、代码仓库、工单、频道、邮件和日历。

在桌面端，Work 还可以在工具可用时使用本地文件、应用和浏览器。

Codex 更强调“项目就是上下文边界”。本地项目可以连接电脑上的一个或多个文件夹；对于代码仓库，项目目录会成为 Codex 的工作目录。相关对话可以共享项目级资料，但每个独立结果仍建议放在单独的对话中，避免任务互相污染。

这里有一个容易误解的点：项目负责组织上下文，不负责授予权限。

把某个文件夹加入项目，表示这个任务可能需要它；Agent 最终能否读取、修改或通过网络访问其他资源，仍由沙箱和权限策略决定。

三、第二层：工具如何接进来

只有上下文，没有行动能力，Agent 仍然只是一个会分析的聊天机器人。

Work 和 Codex 的共同方向，是通过可安装、可复用的能力包扩展自己：

Skill：一套可复用的任务说明、步骤、模板和参考资料；
Plugin：可安装的能力包，可以包含 Skill、Connector 或二者；
Connector / MCP Server：把外部数据和动作暴露给 Agent；
Tool：Agent 在具体任务中实际调用的搜索、读取、写入或执行动作。

其中，MCP（Model Context Protocol）可以理解为 Agent 与外部工具之间的标准接口。它让 Google Drive、Slack、GitHub 或企业内部系统不必把所有逻辑塞进 Prompt，而是以结构化工具和资源的形式接入。

工具很多时，为什么不会一次塞满上下文

答案不是“模型硬记住所有工具”，而是分层发现、按需加载。

以 Codex 的 Skill 机制为例，官网公开了三层渐进式加载：

启动时只放入 Skill 的名称、简介和路径，用于判断它是否匹配当前任务；
选中某个 Skill 后，才读取完整的 SKILL.md 工作流；
真正执行到某一步时，才继续读取相关参考资料或运行脚本。

初始 Skill 列表还有明确预算：最多使用模型上下文窗口的 2%；如果无法确定窗口大小，则最多 8,000 个字符。Skill 太多时，Codex 会先缩短简介，必要时省略一部分候选项并提示用户。

流程图

Skill 解决“该走哪套工作流”，MCP 解决“外部系统提供哪些数据和动作”，具体 Tool 才负责执行一次搜索、读取或写入。

当前 Codex 更新日志还明确写到，MCP 工具默认使用 tool search。可以把它理解成：先检索与任务相关的工具，再把候选工具交给 Agent，而不是把所有 MCP 工具定义永久铺在当前上下文里。

这里需要保留一个证据边界：官网公开了 Skill 的渐进式加载规则，也公开了 Codex 当前使用 MCP tool search；但 Work 与 Codex 内部完整的工具排序算法、打分公式和所有自动触发条件并未公开。

两种工作台在工具选择上有明显倾向：

Work 更常组合搜索、文件处理、浏览器、办公文档和业务系统；
Codex 更常组合文件编辑、Shell、Git、测试、代码审查和开发环境。

但这只是默认体验，不是硬边界。官网明确提到：如果你已经习惯用 Codex 做研究、文档或演示，可以继续使用；Work 只是为日常知识工作提供了更自然的呈现方式。

四、第三层：任务到底在哪里运行

这是 Work 与 Codex 在架构上最值得区分的部分。

先直接回答一个容易产生误解的问题：Work 会不会执行在远端？会，但不能把所有 Work 都理解成同一台远端电脑。

官网明确把 Web 上的 Work 长任务称为 hosted long-running work；Work 的子代理也运行在 ChatGPT 托管环境。与此同时，桌面端 Work 可以调用本地文件、应用和浏览器；桌面端与 Codex 对话的本地动作遵循 Codex 的沙箱和审批控制，在用户电脑上执行。

如果任务又调用 Google Drive、Slack 或 GitHub，读取或写入动作最终还会发生在对应的外部系统中。

因此，一次 Work 任务可能跨过三类位置：

位置	负责什么	典型例子
ChatGPT 托管环境	Web 长任务、Work 子代理等托管执行	研究、并行分析、汇总结果
用户电脑	桌面端获准使用的本地工具	读取文件、操作本地应用、运行本地命令
外部服务	Connector / MCP 对应的数据与动作	搜索网盘、读取频道、更新工单

所以“远端电脑”不是最准确的心智模型。更准确的说法是：一个任务由 Agent 编排，但每个工具在自己的运行边界内执行。 普通对话、连接工作流、定时任务和 Codex 对话，也可能拥有不同的工具、网络权限与治理规则。

Codex 在桌面端则把运行位置直接做成了可见选项：

Local：直接在当前项目目录工作
Worktree：在独立 Git worktree 中隔离修改
Cloud：在配置好的远程云环境中执行

Local 和 Worktree 都运行在用户电脑上。

Worktree 尤其能体现 Codex 的工程架构：它为同一个 Git 仓库创建第二份检出，让多个任务并行改代码，又不碰乱开发者正在使用的本地目录。多个 worktree 共享 Git 元数据，但各自有独立文件副本和工作状态。

所以 Work 更关注“把任务交付出来”，Codex 更关注“这次修改在哪个工程环境里发生、如何隔离、怎样合并回主工作区”。看到 Cloud、hosted 或远程连接时，要继续追问：远程的是 Agent 任务、命令执行环境，还是外部工具本身？三者不是一回事。

五、第四层：Agent 能做什么，由谁说了算

Agent 架构里最重要的不是模型，而是权限边界。

OpenAI 把本地执行的控制拆成两个独立机制：

Sandbox（沙箱）：决定命令能访问哪些文件和网络资源；
Approvals（审批）：决定越过边界时，是暂停询问用户，还是交给自动审查。

二者不能混为一谈。

把审批从“询问我”改成“自动审查”，并不会扩大沙箱。它只是换了越界请求的审核者。真正决定 Agent 能否直接读写某个目录、访问某个域名的，仍然是沙箱配置。

这一层带来了一个实用的信任模型：

流程图

对于企业环境，还会叠加身份、RBAC、插件策略、连接器动作控制和源系统权限。Work 不会绕过 Google Drive、Slack 或代码仓库原有的访问控制；用户只能访问其账号或获批共享连接本来就有权访问的内容。

六、第五层：Memory、上下文压缩和子代理如何分工

长任务还有一个核心问题：对话、工具结果和中间日志越来越多，模型不可能把所有历史内容永远原样放在当前上下文中。

这里要区分四种容易混为一谈的机制。

机制	解决什么问题	作用范围
当前上下文	让模型看到这一步最相关的信息	当前 Thread / Turn
Compaction	缩小长对话占用的上下文	当前聊天
Memory	把有长期价值的信息带到未来任务	跨聊天
Subagent	把探索日志等噪声留在独立线程，只返回摘要	主线程与子线程之间

Memory 调度：不是每次聊天结束都立刻记住

ChatGPT Web 使用 ChatGPT Memory；本地 Codex 客户端则使用一套独立的本地 Memory 存储和控制。两者不能当成同一个数据库。

本地 Codex Memory 默认关闭。启用后，它会从符合条件的历史聊天中提取有复用价值的信息，写入 ~/.codex/memories/ 下的本地文件，并在未来会话需要时注入。

这套调度不是“对话一结束就立刻总结”：

活跃或过短的会话会被跳过；
系统会等待聊天空闲一段时间，避免总结尚未完成的工作；
Memory 在后台更新，可能不会立即出现；
当剩余使用额度低于设定阈值时，可以跳过本轮生成；
提取模型与全局合并模型可以分别配置；
还可以禁止使用过 MCP、Web Search 或 Tool Search 的聊天参与 Memory 生成，减少把外部内容误当成长期事实的风险。

Memory 适合保存偏好、项目背景和过去工作中学到的有用上下文，不适合承担必须遵守的规则。团队的强制规范应该写进 AGENTS.md 或受版本控制的文档，因为显式指令的优先级高于回忆层。

上下文压缩：保留工作状态，不等于写入长期记忆

Codex 提供 /compact 命令压缩当前聊天的上下文；官方的 Codex 模型指南也把 Compaction 描述为支持多小时推理和长对话连续性的关键能力。

可以把它理解为：历史对话仍属于当前 Thread，但送入下一轮模型的工作上下文被收紧，重要目标、约束、决定和进度继续保留，冗长的中间过程不再逐字占据窗口。

不过，OpenAI 当前公开文档没有完整披露 Codex 产品内部的自动压缩触发阈值、摘要结构和保真算法。因此，文章能确认的是“支持压缩”和“可以手动 /compact”，不能把某种具体压缩实现写成官方事实。

子代理调度：把噪声留在旁路

上下文压缩是在同一聊天里做减法；子代理则把工作拆到独立线程。

主 Agent 可以把代码探索、测试日志、资料检索或大文件分段分析交给子代理。每个子代理在自己的线程里使用模型和工具，最后只把摘要和结论交回主线程。这样，需求、关键决定和最终结果不会被大量中间日志淹没。

这也是一种上下文调度：不是扩大主线程窗口，而是控制什么内容有资格进入主线程。代价是子代理会额外消耗 Token，因此适合可并行、读操作较多、输出能被压缩成摘要的任务。

七、为什么 Codex 会暴露 Thread、Turn 和 Item

如果再往下一层看，Codex 的 App Server 把一次 Agent 工作拆成了三个核心对象：

Thread：一段持续的用户与 Agent 对话；
Turn：一次用户请求，以及 Agent 随后的完整工作过程；
Item：Turn 中的一项输入或输出，例如消息、命令运行、文件修改或工具调用。

客户端先建立连接并初始化，再创建或恢复 Thread，启动 Turn，并持续接收 Item 的增量事件，最后收到 Turn 完成状态。

这解释了为什么 Codex 界面能实时展示“正在执行命令”“修改了哪些文件”“某个工具调用是否完成”，也解释了为什么用户可以在任务执行中继续补充要求、暂停或分叉对话。

Work 不强调这些工程对象，但同一个代理要完成长任务，背后同样需要任务状态、工具事件和可审阅输出。两种工作台的区别，是把哪些过程细节展示给用户，而不是有没有过程。

八、实际使用时怎么选

不要先问“哪个能力更强”，先问“我需要审阅什么”。

如果最终要审阅的是内容和业务结论，优先选 Work：

做一份带证据的研究简报；
把多份材料整理成演示文稿；
生成可继续编辑的表格或报告；
定期汇总多个业务系统的进展。

如果最终要审阅的是工程变更，优先选 Codex：

查看文件级 Diff；
运行测试和命令；
隔离多个并行代码任务；
创建分支、审查 PR 或处理 Git 工作流。

如果任务跨越两边，例如“研究竞品后修改产品落地页”，可以按审阅对象拆成两个阶段：先在 Work 中形成有来源的结论，再在 Codex 中把已确认结论变成代码，并用 Diff 和测试验收。

一个可靠的提示词至少写清五件事：

目标：最后要交付什么
来源：允许使用哪些文件、项目或插件
约束：哪些范围不能越过
验收：怎样算完成
审批：执行什么动作前必须停下来

结语

Work 与 Codex 的关系，代表了 Agent 产品正在发生的一次重要变化：同一个代理内核，不再只对应一个聊天框，而是可以根据任务类型切换工作台。

它们共享的核心链路是：

目标 → 上下文与 Memory → 工具调度 → 执行环境 → 权限审查 → 可审阅结果

Work 把重点放在“结果能不能直接用”，Codex 把重点放在“过程能不能被开发者检查和接管”。

理解这套架构后，选择就变得简单了：你不是在选择两个不同的大脑，而是在为同一个 Agent 选择最适合当前任务的工作台。

参考资料

OpenAI：Use ChatGPT
https://learn.chatgpt.com/docs/use-chatgpt
OpenAI：Get started with Work mode
https://learn.chatgpt.com/docs/get-started-with-work
OpenAI：Work mode admin FAQ
https://learn.chatgpt.com/docs/enterprise/work-admin-faq
OpenAI：Codex environments
https://learn.chatgpt.com/docs/environments/modes
OpenAI：Projects and chats
https://learn.chatgpt.com/docs/projects
OpenAI：Sandbox
https://learn.chatgpt.com/docs/sandboxing
OpenAI：Worktrees
https://learn.chatgpt.com/docs/environments/git-worktrees
OpenAI：Codex App Server
https://learn.chatgpt.com/docs/app-server
OpenAI：Skills & Plugins
https://learn.chatgpt.com/docs/skills-and-plugins
OpenAI：Memories
https://learn.chatgpt.com/docs/customization/memories
OpenAI：Customization
https://learn.chatgpt.com/docs/customization/overview
OpenAI：Build skills
https://learn.chatgpt.com/docs/build-skills
OpenAI：Slash commands
https://learn.chatgpt.com/docs/reference/slash-commands
OpenAI：Long-running work
https://learn.chatgpt.com/docs/long-running-work
OpenAI：Subagents
https://learn.chatgpt.com/docs/agent-configuration/subagents
OpenAI：Codex Prompting Guide
https://developers.openai.com/cookbook/examples/gpt-5/codex_prompting_guide
OpenAI：Codex changelog
https://learn.chatgpt.com/docs/changelog