ChatGPT Desktop 里的 Work 和 Codex 都能读文件、调用工具，也都可能生成代码。只看功能列表，很容易把它们理解成两个能力相近的入口。
更可靠的区分方法，是看任务围绕什么对象展开，以及最终怎样验收：代码库是核心对象、可运行结果是验收标准，优先用 Codex；文档、研究、表格、演示或跨应用成果是交付物，优先用 Work。
因此，不建议把 Work 当成日常主要编程模式。它能写代码，但代码通常只是完成任务的一种手段。
一张表先划清边界
| 任务 | 更适合的入口 | 主要原因 |
|---|---|---|
| 写代码、改代码、读 Repo、跑测试 | Codex | 工作空间围绕代码库、终端、测试和版本控制展开 |
| 分析代码片段、讨论技术方案 | Chat + Thinking / Pro | 重点是解释与推理，不一定需要修改工作区 |
| 跨多个步骤完成一份工作成果 | Work | 可以组合文件、网页、应用操作和文档产出 |
| 查大量外部资料并形成带来源的结论 | Deep Research | 强项是多轮检索、证据核对和引用报告 |
| 长期维护某个主题或项目上下文 | Projects | 聚合聊天、文件和项目指令，方便持续协作 |
这张表讨论的是默认路由，不是绝对权限。现实任务经常跨界，关键在于哪个对象占主导。
Codex 管的是软件成果
Codex 的核心工作面是 Repo。它关心文件树、依赖、命令、测试结果、Git diff 和运行环境。
一个典型任务是：
Clone OpenClaw，找到 Context 相关源码，修改压缩算法，补测试，跑完整测试集并修复失败项。
这类任务的每一步都围绕代码状态推进：
- 阅读仓库和工程约束；
- 定位调用链与影响范围；
- 修改源码和测试；
- 执行 lint、typecheck、test 或 build；
- 检查 diff，必要时整理 commit 或 PR。
最终验收也很工程化：代码能否运行，测试是否通过，改动有没有越界，diff 是否可审查。
当前 ChatGPT Desktop 中，Codex 还带有本地项目、工作树、终端与项目路径等明显的代码执行语义。OpenAI 对 Codex 的公开定位同样聚焦 coding agent：读取和修改代码、执行命令、处理并行工程任务，并把结果交给开发者审查。Codex 官方介绍
Work 管的是工作成果
Work 更接近通用项目执行环境。它面对的可能是一份调研报告、一张分析表、一套演示材料，或者跨多个应用完成的业务结果。
例如：
分析 OpenClaw 的 Context Management 设计，结合 Hermes Agent、Claude Code 和 Codex 做横向比较，最后输出架构评估报告，并提出内部 Agent Runtime 的改造建议。
这项工作可能包含检索资料、读本地文件、分析源码、整理数据、制作表格和编写文档。代码会出现，终端也可能参与，但验收重点是报告是否完整、证据是否可靠、建议能否支持决策。
ChatGPT Desktop 当前安装包里也能看到这种能力取向：Work 入口和本地/云端访问开关相连，并打包了浏览器控制、Computer Use、Deep Research、可视化、LaTeX、Sites 等插件。这个组合更像一张通用工作台。不同账号、订阅和灰度版本看到的具体工具可能不同，因此这里讨论的是产品边界，不保证每个入口都同时开放。
四个维度比“它能不能做”更有用
1. 核心对象
- Codex：代码库、分支、依赖、测试、构建产物。
- Work：文件、网页、应用、文档、表格、演示和业务结果。
Work 可以处理代码，Codex 也能写说明文档。判断时要看大部分上下文围绕谁组织。
2. 过程形态
Codex 的过程通常是工程闭环：读代码、改代码、运行、验证、复查。
Work 的过程更像任务编排：搜集、读取、分析、操作、整理、生成交付物。步骤可能很多，但不一定落在同一个 Repo 里。
3. 验收方式
Codex 适合机器可验证的标准：
- 测试通过；
- 构建成功；
- diff 符合范围；
- Bug 可以复现并确认修复；
- 性能指标达到要求。
Work 更适合成果型标准：
- 报告回答了决策问题；
- 数据有来源；
- 文档结构完整；
- 表格或幻灯片能直接使用；
- 跨应用操作完成且结果可检查。
4. 风险模型
Codex 的主要风险是代码破坏：误改文件、测试覆盖不足、依赖或权限变化、提交范围失控。
Work 的风险面更宽：它可能访问网页、文件和桌面应用，甚至触发对外操作。任务里只要包含发送、发布、购买、删除或账户操作，就需要更明确的确认点。
Chat、Thinking / Pro、Deep Research 和 Projects 放在哪
把这些入口混在一起，常见原因是把“模型能力”“执行模式”和“上下文容器”当成同一层概念。
Chat + Thinking / Pro：把问题想明白
适合解释代码、评审方案、推演架构和讨论取舍。输出通常直接出现在对话里，不要求操作完整仓库，也不强制生成正式成果文件。
例如：
OpenClaw 的 Agent Loop 在长 Context 下为什么容易丢失早期约束？请从记忆压缩和工具反馈两个角度分析。
这类问题先用高推理模式讨论，成本通常低于启动一条完整执行链。
Deep Research：把证据找齐
Deep Research 面向多轮检索、来源交叉核验和引用报告。OpenAI 的公开说明强调，它会搜索、分析并综合大量在线来源，适合市场研究、技术比较和需要出处的复杂问题。Deep Research 官方介绍
如果任务只需查一个 API 参数或确认一个发布日期，普通搜索或 Chat 已经够用。Deep Research 更适合证据分散、来源可能冲突的题目。
Projects：把上下文留住
Projects 是长期上下文容器。它把相关聊天、上传文件和项目指令放在一起，方便持续维护某个主题。Projects 官方帮助
Projects 本身不决定任务该由谁执行。一个 Project 里可以讨论方案，也可以调用研究或编码能力。它解决的是上下文组织问题。
三个例子，基本就能形成直觉
场景一：研究源码并形成选型报告
调研主流 Agent Framework，分析 OpenClaw 源码架构，输出技术选型报告。
主交付物是报告，优先 Work。若需要深入追踪某条调用链，可以把源码分析拆给 Codex，再由 Work 汇总。
场景二：给 Agent Loop 增加观测 Hook
找到 OpenClaw agent loop 的实现，增加 hook，让每次 tool call 都记录 latency，并补测试。
主交付物是可运行代码，直接用 Codex。验收项应该写成测试、日志字段和性能开销。“给一份分析”不算完成。
场景三：解释长 Context 为什么会失忆
从架构角度分析 Agent Loop 在长 Context 下失忆的原因。
先用 Chat + Thinking / Pro。只有需要查论文、比较多个框架的实测数据时，再升级到 Deep Research；只有要把结论做成正式报告或演示材料时，再交给 Work。
一套更省资源的组合方式
复杂任务可以拆成流水线：
Deep Research：补齐外部资料和证据
↓
Codex：阅读 Repo，验证实现细节
↓
Chat + Thinking / Pro：做架构推理和取舍
↓
Work：整理报告、表格或演示材料
↓
Projects：沉淀长期上下文
这套组合能减少模式误用。小问题停在 Chat，代码闭环交给 Codex，证据密集型调查交给 Deep Research，跨步骤成果再进入 Work。
选择入口时，可以先问两个问题：
- 最终交付物是可运行代码，还是一份可使用的工作成果？
- 验收主要依赖测试和 diff，还是内容完整性、证据与表达？
前者分别指向 Codex 和 Work。边界模糊时，把任务拆开，通常比把所有步骤塞进一个模式更稳。
参考资料
注：Work 是 ChatGPT Desktop 当前版本中的产品入口，具体名称、工具和权限可能随账号、平台及灰度发布变化。公开资料对它的独立说明仍有限，文中的边界结合当前桌面版能力结构与任务模型归纳，适合作为选型方法，不应当作永久不变的产品规格。
评论前必须登录！
立即登录 注册