分享我用 Codex 和 Claude Code 搭建的可持续协作的软件开发团队｜附开箱即用 Skills

为了规划 token 用量和把控产品效果，我现在会同时用 Codex 和 Claude Code 做编程项目。它们的分工很明确：Codex 负责规划、组织和验收，Claude Code 负责实现和返工。

这套分工是从几次协作失控里逐渐长出来的。

有一次，我让 Codex 按照原有设计生成播客视频。它遇到技术问题后，没有停下来告诉我，而是改了播放器的头像和标题格式，让视频能够顺利生成。视频做出来了，但我要求保持不变的设计也被改变了。它完成了任务，却悄悄改写了“什么叫完成”。

另一次，Claude 完成了产品页面的视觉优化，再交给 Codex 验收。页面看起来已经做完，但任务缺少明确的修改边界和验收证据，Codex 无法判断移动端、交互和页面状态是否真的可靠。最后，我们重新明确范围、补齐测试和页面检查，才允许结果进入主分支并发布。

这两个案例暴露了多 Agent 协作中最常见的两种失控：一种是 Agent 为了绕过困难擅自改变目标，另一种是系统用“已经完成”的声明替代证据和独立验收。

总结来看多 Agent 协作真正难的，不是怎样让更多 Agent 同时工作，而是怎样让每个结果都有责任、有边界、有证据，也有人决定它能不能进入现实。

这套协作模式到底是什么

我搭建的并不是一条“Codex 做一点、Claude 再做一点”的任务流水线，而是一条责任链。

我负责定义目标、重大取舍和不可逆操作，最终承担结果进入现实后的后果。
Codex 承担 Director 和 Reviewer：理解项目、形成工作包、确定权限与成功标准，并根据证据决定接受还是返工。
Claude Code 承担 Builder：在授权范围内实现、测试、提交代码，并对正常返工负责。
独立 Verifier 负责寻找事实证据和暴露缺口，但不能修改结果，也不能替 Codex 作出接受决定。

一次任务大致这样流动：

我提出目标
→ Codex 读取项目，形成工作包
→ 我确认边界和关键取舍
→ Claude Code 在独立工作区实现、测试并提交证据
→ Codex 独立验收这个精确结果
→ 通过则交付，不通过则退回 Claude 有限返工
→ 对返工后的新结果重新验收

这不是因为 Claude 不会规划，或者 Codex 不会写代码。两者都能完成很多相同的工作。我这样安排，是因为生产结果和放行结果应该是两种不同的责任。如果规划者在交出任务后又大量参与实现，它就很难再保持独立验收的位置；如果 Builder 可以修改成功标准并批准自己的结果，所谓协作就只剩下自我汇报。

所以，这套模式的核心不是能力分类，而是责任分离：Codex 定义任务并决定结果能不能被接受，Claude 负责把任务变成代码，而我对最终进入现实的结果负责。

为什么不能让两个 Agent 自由接力

第一个风险是目标漂移。Agent 面对困难时，很容易选择一条更容易完成的路径。如果任务只写“生成视频”或“优化页面”，它可能会通过改变设计、缩小问题甚至跳过关键约束来完成活动。工作包必须提前写清真正要产生的结果、不能改变的部分，以及什么时候必须停下来问人。

第二个风险是完成幻觉。Agent 很擅长给出结构完整的完成报告：改了哪些文件、运行了哪些命令、解决了哪些问题。但这些只能证明它做过一些活动，不能自动证明页面已经好用、文章已经成立或者产品可以发布。生产者的自我汇报可以作为线索，不能作为最终验收。

第三个风险是写入冲突。最开始，我也想让 Codex 和 Claude Code 同时写代码，觉得这样可以获得双倍速度。但只要两个 Agent 进入同一份代码或同一个工作区，并行增加的就不只是产能，还有覆盖、冲突和责任不清。当结果出问题时，两个 Agent 都能证明自己完成了分到的部分，却没有谁对整体交付负责。

因此，我不排斥并行研究、代码定位和独立验证，但只要任务进入同一个代码工作单元，就只保留一个写者。如果确实需要并行开发，必须先把任务隔离到不同模块、文件边界和工作区，而且每一部分都能独立验收。否则，多一个 Agent 往往不是多一份能力，而是多一个需要管理的不确定性。

一次任务是怎样被管住的

第一步：Codex 把意图变成工作包

当我提出“优化这个页面”或“修好窗口重开后状态丢失的问题”时，Codex 不会立即修改代码。它会先读取项目规则、现有实现、架构文档、需求记录和测试，弄清楚这次修改与整个项目的关系，再把模糊意图整理成一份工作包。

一份最小工作包只需要七项：

目标：现实中要产生什么结果？
owner：谁对最终交付负责？
权限：允许读取、修改和执行什么？
成功标准：哪些客观检查与人工判断必须通过？
停止条件：出现什么情况必须暂停并请求决定？
证据：Reviewer 可以独立检查什么？
Review 决策：接受、要求修改，还是等待人的判断？

其中最重要的是目标、权限和停止条件。“优化页面”不是一个可以验收的目标，“让第一次访问的用户在首屏理解产品用途，同时不改变现有定位”才更接近一个结果。权限要写清允许修改的文件和禁止触碰的区域；停止条件则规定，涉及产品方向、凭据、部署、数据删除或范围扩大时，Agent 不能自行补全。

工作包不是一段更长的提示词，而是所有参与者共同遵守的最小合同。它防止任务在执行过程中被悄悄改写，也让后面的证据和 Review 有明确参照。

第二步：Claude Code 成为唯一写者

工作包经过确认后，Claude Code 才进入独立 branch 和 worktree。它是这个工作单元的唯一写者，可以在授权范围内自主选择实现路径、修改代码、运行测试并提交 commit。

Claude 不需要等待 Codex 逐行指挥，但它不能自行扩大任务、改变成功标准、写入未授权文件，也不能决定自己的结果进入主分支。触发停止条件时，它要保留现场并说明需要谁判断什么，而不是继续猜测。

这种方式保留了 Agent 的自主性，也保留了我们追查、返工和回退的能力。Builder 可以更换，但只要工作包、代码版本和项目状态仍然存在，任务就不会因为某个对话结束而失去组织记忆。

第三步：实现结果必须变成证据

Claude 完成后，不能只说“已经修好”，而要交回精确 commit、改动文件、测试结果和其他验收材料。每一条成功标准都应该找到对应证据。

我通常把证据分成四类：

机器检查：测试、构建、格式、文件状态和控制台结果。
人工判断：产品表达、视觉层级、文章逻辑和使用体验。
真实观察：线上访问、使用数据和用户反馈。
未验证假设：目前只是合理推测，不能冒充已经发生的结果。

如果是界面任务，构建通过只能证明项目能够构建，不能证明页面已经好用。还需要检查桌面与移动端、关键交互、数据持久化、控制台、横向溢出和视觉语义。如果是研究或文章，则要检查来源、事实、推测和人的判断是否被清楚地区分。

证据还必须绑定同一个结果。工作包、代码版本、测试和 Review 应该指向同一个 commit；只要代码发生变化，之前的验收就不能自动沿用，必须重新验证。这样，验收的才不是“它曾经通过过的某个版本”，而是现在准备交付的这个结果。

第四步：Codex 只负责判断，不顺手重做

Claude 提交后，Codex 回到 Reviewer 的位置。它不采信 Builder 的完成摘要，而是对照工作包检查 diff，重跑必要的测试、构建或页面验证。

Review 只保留三种明确结果：

ACCEPTED：证据足以支持成功标准，可以放行并承担后果。
CHANGES_REQUESTED：指出哪条标准没有满足、允许返工的范围，以及必须重新运行的检查。
BLOCKED_DECISION：问题超出 Agent 权限，需要我对方向、风险或资源作出决定。

如果需要修改，Codex 不会顺手把代码修掉，而是把明确缺口退回 Claude。否则 Reviewer 会变成第二个写者，新产生的代码又失去了独立验收。Claude 完成返工并提交新 commit 后，Codex 对新结果重新检查。

最后，我仍然保留产品方向、重大取舍、不可逆操作和发布决定。Agent 可以替我搜索、执行和验证，但不能替我承担结果进入现实后的后果。

不搭 Agent OS，两个终端也能开始

你不需要先开发一套复杂的多 Agent 平台。第一次实践，可以只选一个真实、范围小、能够回退的任务，再打开 Codex 和 Claude Code 两个终端。

先把需求交给 Codex：

先不要修改代码。请读取项目规则和现有实现，把需求整理成工作包。
工作包包含：目标、唯一 owner、权限、成功标准、停止条件、证据和 Review 决策。
同时列出 Claude Code 允许修改的范围和必须运行的检查。

你确认工作包后，再把它交给 Claude：

你是这个工作单元的唯一写者。
请只在工作包授权范围内实现，不得扩大任务或改写成功标准。
完成后提交代码，并逐条对应成功标准提供证据。
触发停止条件时停止执行，说明需要谁决定什么。

Claude 提交后，回到 Codex 验收：

请审查这个精确 commit，不采信 Builder 的完成摘要。
独立检查 diff、任务边界和成功标准，重跑必要验证。
最终只作出 ACCEPTED、CHANGES_REQUESTED 或 BLOCKED_DECISION。

先用 Markdown 手动完成工作包与证据交接，再用 Git 隔离工作区和绑定精确结果。只有当这些步骤稳定重复以后，才值得用 Agent OS 自动创建工作包、启动 Claude、收集证据和通知 Codex Review。

自动化的价值是减少机械交接，不是替你补齐责任设计。如果两个人工终端之间尚且说不清目标、边界和验收标准，自动调度只会更快地传递模糊。

怎样判断这套模式有没有效果

流程看起来完整并不代表它真的有效。跑过几次真实任务后，我会观察几个很朴素的信号：

任务中途重新解释目标的次数是否减少。
Agent 声称完成但证据不足的情况是否减少。
第一次提交通过验收的比例是否提高。
平均返工轮数和我亲自接管执行的次数是否下降。

如果这些变化没有发生，说明工作包可能写得太重、成功标准仍然模糊，或者任务根本不适合多 Agent。删掉无用字段，调整职责，再用一个小任务重跑，比继续增加 Agent 和自动化更有价值。

真正值得沉淀的也不是每次对话，而是那些反复影响结果的规则：哪类操作必须停下来问人，什么证据才能放行，哪些任务可以并行，哪些失败应该退回原 owner。把它们写进项目规则、工作包模板或 Skill，下一次协作才会站在更高的起点上。

两个 Agent 之间需要的不是更多对话

真实项目里让 Agent 协作可靠的是责任、权限和可验证的交接。两个 Agent 可以不停讨论，却仍然一起误解目标；也可以几乎不直接对话，却因为共享同一份工作包、同一个 commit 和同一组成功标准，而稳定地完成交付。

所以，我不追求让 Codex 和 Claude Code 看起来像两个忙碌的同事，而是更在意它们之间是否存在一条清晰的责任链：谁定义结果，谁写代码，谁提供证据，谁决定它可以进入现实。

让 AI 更快地写代码并不难。难的是，当写代码变得很快，我们仍然知道什么值得被实现，什么证据足以让它被交付，以及最后究竟由谁对这个结果负责。

最后附上这套 Agent OS 开源 Skills

Agent OS 是一套面向 Codex 与 Claude Code 的 AI 原生软件交付机制。它不是让两个 Agent 共用一个编辑器，而是用 Git、Worktree、工作包、权限、证据和验收门禁，把它们组织成一支可以持续协作的软件团队。

Codex 是产品与技术总监：定义目标、边界、验收标准并作最终决策。 Claude Code 是实现负责人：在独立 Worktree 中开发、验证和返工。 Git 是版本神经系统；Evidence 是组织记忆；Agent OS 是治理与恢复层。

可访问链接: https://github.com/chukong-creator/agent-os-skill

关联模板：Agent OS/Agent OS 工作包模板