Codex 和 Claude Code 都是终端型 AI 编程助手，但风格不同。这篇基于真实工程任务，讲多 Agent 如何分工协作–ChatGPT 做总工，Codex / Claude Code 做施工与审查，WorkBuddy 做本地执行–以及为什么关键不是工具强弱，而是任务事实。

单 Agent 为什么容易闭环误判

很多人用 AI 做项目，习惯把一个任务完整丢给一个 Agent：让它分析，让它写代码，让它测试，让它总结，最后让它告诉你“已经完成”。这个方式在简单任务里没问题。

但只要项目稍微复杂一点，问题就会出现：它会顺着自己的思路一直往下改，写完之后自己检查自己，很容易看不出问题。它可能遗漏边界条件，误判环境，跳过验证，把没有跑通的东西说成已经完成。

这不是某个模型的问题，而是单 Agent 工作模式天然存在的问题。真实项目里，一个人写完代码还需要别人 code review，一个方案做完还需要别人质疑，一个系统上线前还需要测试验证。AI Agent 也是一样。如果一个 Agent 从头到尾自己做、自己验、自己宣布完成，复杂任务里的风险就会被隐藏起来。

Agent 协作不是复杂编排

一提到 Agent 协作，很多人会想到复杂的自动化平台、任务队列、多 Agent 框架、自动调度系统。但我现在更认可一种轻量方式：不急着做复杂编排，先让不同 Agent 在真实项目里承担不同角色。

比如：一个 Agent 做方案，一个 Agent 做施工，一个 Agent 做审查，一个 Agent 做验证，一个 Agent 做总结沉淀。这不一定需要复杂系统。很多时候，只要任务边界清楚、文件改动清楚、版本记录清楚，不同 Agent 就可以通过很简单的方式协作。对个人项目来说，最重要的不是搭一个宏大的 Agent 平台，而是先把最小有效协作跑通。

我的基本分工

我现在更常用的方式是：ChatGPT 做总工判断，Codex / Claude Code 做施工或审查，WorkBuddy 负责本地执行辅助，Git / Jujutsu 作为版本事实层。这不是固定绑定，而是一种常见分工。

ChatGPT：总工与复盘

ChatGPT 更适合做需求整理、架构判断、任务拆解、风险识别、验收标准设计、文章与文档整理、项目复盘和 Skill 沉淀。我通常不会让它直接承担所有施工，而是让它先帮我判断：这个任务到底该不该做，怎么拆，风险在哪里，哪些地方需要验证，哪些地方可以轻量处理。它更像是一个总工、产品经理、复盘者和方法论整理者的组合。

Codex：代码施工与局部修改

Codex 更适合承担比较明确的代码任务。比如修一个具体 bug、改一个具体模块、按要求补一个脚本、重构某个局部功能、生成测试或辅助工具、根据既定方案做实现。

我更倾向于给 Codex 明确边界：这次只改哪些文件，不要扩散到哪些模块，完成后跑哪些验证，不要重构无关逻辑，不要因为找不到依赖就重新安装一套环境。这样 Codex 更容易稳定发挥。

Claude Code：复杂工程施工与审查

Claude Code 更适合处理一些复杂工程任务，尤其是需要读上下文、理解项目结构、做多文件修改或进行独立审查的时候。它可以承担较复杂的代码施工、多文件影响分析、对 Codex 改动进行审查、检查任务是否真的完成、找出遗漏和边界问题。

我比较看重 Claude Code 的一个用法是：让它换角度检查另一个 Agent 的工作。一个 Agent 写，一个 Agent 审，这种方式非常轻量，但效果往往很好。

WorkBuddy：本地执行与环境辅助

WorkBuddy 更适合处理和本地 Windows 环境相关的任务。比如执行脚本、整理目录、收集日志、打包文件、跑本地验证、辅助检查路径、环境和依赖。它不一定负责架构判断，但非常适合作为“真实环境里的执行助手”–因为很多 AI 工程问题，最终都要落到本地机器上验证。

关键不是工具，而是任务事实

很多人讨论 Agent 协作时，会把重点放在工具强弱上。哪个模型更强，哪个 IDE 更好，哪个 Agent 框架更先进。这些当然重要，但在真实项目里，我觉得更关键的是：所有 Agent 是否围绕同一个任务事实工作。

如果任务事实不清楚，不同 Agent 只会各说各话。所以我会尽量明确几件事：本次任务目标是什么，不做什么，涉及哪些文件，当前可信环境是什么，正式入口是什么，哪些验证必须跑，哪些结果算完成，哪些失败必须停下来反馈。只要这些事实清楚，不同 Agent 就可以轻量协作。如果这些事实不清楚，即使上再复杂的 Agent 框架，也只是把混乱自动化。

Git / Jujutsu 是事实层

我现在越来越重视版本事实层，因为聊天记录不适合作为工程事实。

Agent 说它改了什么，不如直接看 diff。Agent 说它完成了，不如看 commit 和验证结果。Agent 说它只改了一个地方，不如看实际文件变更。这也是为什么 ACE 里会采用 Jujutsu + Git 的路线：Git 是通用事实层，负责 commit、diff、历史记录、回滚、审计和跨工具协作；Jujutsu 更适合本地施工过程，负责本地变更整理、工作区管理、撤销和调整提交。在 Agent 协作中，这套组合的价值是：让不同 Agent 不只是在聊天，而是在同一个版本账本上协作。

一个典型协作流程

一个典型的 ACE Agent 协作流程大概是这样：

  1. 总工 Agent 梳理任务：明确目标是什么、风险在哪里、是否需要拆分、是否涉及环境、是否需要版本事实层、验收标准是什么。简单任务直接轻量处理，复杂任务进入工程路径。
  2. 施工 Agent 执行任务：施工 Agent 不需要重新发明方向，而是按照明确边界完成改动，并把实际改动留在版本事实层里。
  3. 审查 Agent 换角度检查：不只看“有没有完成”，还要看有没有改错范围、有没有遗漏验收、有没有引入新风险。
  4. 本地执行或验证：需要在真实环境里跑的任务，交给贴近本机环境的工具或人工确认，避免只停留在推断。
  5. 总结和沉淀：只有真正可复用、高风险、反复失败或能提高效率的做法，才值得沉淀成 Skill。

在项目里的体现

这套分工不是抽象方法论，已经在几个真实项目里落地：

  • TemuCanvas 里，Agent 协作体现在数据分层、候选生成、人工复核、错误放行控制、失败诊断和版本冻结。
  • AI PPT Workflow 里，体现在任务预检、内容战略、逐页计划、静态版验收和动效增量施工。
  • Anchor AI Lab 里，体现在内容迁移、架构演进、静态站冻结、Astro 迁移、部署复查和文档沉淀。

工具会变，模型会迭代，但“围绕任务事实、轻量分工、版本留痕”这套协作方式，是能在真实项目里持续生效的。