双 Agent 接力工作流：Claude Code + Codex

这是什么

本文只解决一个问题：任务大到值得用两个 agent 时，Claude Code 和 Codex 怎么分工、怎么交接、Waza 的 8 个 skill 在两侧怎么路由。

这里的 Claude Code 下文简称 CC。Waza 指一组 agent 工作流 skill，本文只讨论它们在 CC 和 Codex 两侧的使用边界。

接力不是默认流程。小任务用一个 agent 直接跑完；只有任务规模、上下文长度、实现量或验证量值得拆分时，才启用本文流程。

一句话分工：

CC 负责理解、规划、终审；Codex 负责实现、验证、跑量。

CC 适合长上下文、读大库、做架构判断。Codex 适合本地执行、写代码、跑测试、批量验证。接力的价值来自这个差异，不来自多一道流程。

何时启用接力

任务类型	走法
小任务：单文件、小配置、解释代码、简单 bug	不接力，单 agent 跑完
中 / 大任务，且需要读大库、长上下文规划、较多实现量或大量本地验证	启用接力
高风险任务：数据、权限、生产、删除、发布等	接力 + 6 点确认门禁，并在 plan 写清回滚

判断不准时，按更大一档处理。只要命中数据、权限、生产配置、密钥、删除、Git 历史、发布这些触发器，就按高风险处理。

双 Agent 分工 + 8 个 skill 归属

CC = 理解 / 规划 / 终审，适合长上下文、读大库、架构判断。

Codex = 实现 / 验证，适合本地执行、写码、跑测试、跑量。

类别	skill / 动作	归属侧	触发时机
主线必经	`think` 出 plan	CC	每个接力任务开头
	按 plan 实现	Codex	plan 定稿后
	`check` 实现自查	Codex	实现完成后，检查是否照 plan、是否有明显漏洞
	`check` 终审	CC	Codex 回传后，检查架构、回归、跨模块影响、是否还能简化
按需 · 实现侧	`hunt` 查根因	Codex	实现或验证卡 bug 时
	`design` UI 落地迭代	Codex	涉及前端或界面体验时
按需 · 规划 / 收尾侧	`read` 读外部材料	CC	有链接、PDF 或外部上下文时
	`learn` 做陌生领域研究	CC	进入不熟悉领域时
	`write` 润色文档 / release note	CC	写对外文字时
	`health` 做 agent 配置 / 项目体检	CC	低频体检时

Codex 侧承载实现的方式：把 plan 里的目标、验收、范围、约束喂给 Codex 的 /goal（Goal mode），并设好验收命令和停止条件，让它自主跑完“分析 -> 实现 -> 验证 -> 修正”的循环。

plan 定义“做什么、怎样算对”。/goal 定义“如何自主跑到算对”。两者不要重复。

交接物流转

docs/plans/plan-<task>.md 是唯一事实源。两个 agent 之间所有对齐都经过这份文件，不依赖任何一方的记忆。

[CC 侧 · 规划 / 把关]                   [Codex 侧 · 实现 / 验证]
 read / learn(按需喂料)
      │
   think ──► docs/plans/plan-<task>.md ──交接──► 按 plan 实现
      │         (目标 / 验收命令 / 范围 /              │
      │          task list / 约束)                卡 bug► hunt
      │                                                │
      │                                      完成后► check 自查 + 跑验证
      │                                                │
   check 终审 ◄──────── 回传 diff + 验证结果 ◄──────────┘
      │
   通过 → 你 commit    /    不通过 → 回 think 更新 plan，再循环

CC -> Codex -> CC 是有意设计的迭代环。终审不过，就回 think 更新 plan；不要让 Codex 脱离 plan 反复试命令。

`plan-*.md` 必含字段

交接物放在 docs/plans/。一份能让 Codex 不读你脑子也能干活的 plan，至少包含四块：

目标 / 验收标准   做完怎么算对；最好是一条可执行命令或一个测试
改动范围         要动哪些文件；哪些文件明确不准动
task list        分步骤列出任务；每步要能独立验证
约束             既有风格、不引新依赖、边界条件；高风险任务还要写回滚方式

验收标准必须尽量写成可执行命令，而不是模糊描述。Codex 的实现自查要对照这条命令，不对照一段感觉正确的话。这个约束是接力成立的关键。

防重复路由的硬规则

Waza 同时装在两侧时，最容易出问题的是同一个任务被两套路由各跑一遍：质量没有明显提升，成本翻倍。三条规则写死：

规划只在 CC 发生一次：plan 定稿后，Codex 不再重新 think，只执行。
check 可以出现两次，但层级不同：Codex 的 check 是实现自查，对照 plan 和验收命令；CC 的 check 是终审，看架构、回归和跨模块影响。Codex 侧 check 不下方案级结论。
hunt 默认在 Codex：只有 Codex 反复修不好，且需要长上下文通读全局找根因时，才升级给 CC。

Codex 侧安装与约束

codex plugin marketplace add tw93/Waza
codex plugin add waza@waza

Waza 是整包安装，没法只装部分。约束靠路由规则，不靠卸载：Codex 侧只主动用 hunt / check / design，其余 5 个不在 Codex 触发。规划留在 CC。

一次完整接力

以“给某 CLI 加一个新子命令”为例：

1. [CC] 任务进来，分流判定：中任务 + 需要读现有命令结构 -> 启用接力。
2. [CC] think：读 CLI 现有命令注册方式，产出 docs/plans/plan-add-subcommand.md。
        验收写成：`pytest tests/test_cli.py -k new_subcommand` 全绿，
        且 `mycli newcmd --help` 有输出。
3. ──交接 plan──►
4. [Codex] 按 plan 实现：注册子命令、写实现、补测试。每完成一个 task 就勾掉。
5. [Codex] 跑 `pytest ... -k new_subcommand`。如果失败，用 `hunt` 查根因，修到通过。
6. [Codex] `check` 自查：是否照 plan 做、是否有明显漏洞。回传 diff + 验证结果。
7. ──回传──►
8. [CC] `check` 终审：命令注册是否破坏既有命令、是否还能简化、有没有回归风险。
9. 通过 -> 你来 commit；不通过 -> 回第 2 步更新 plan，再循环。

最脆弱假设

这套接力成立，靠一个假设：plan 文件能完整承载意图，Codex 照着执行不会跑偏。

如果 plan 写不全，或者验收标准太模糊，Codex 会把时间花在猜意图上。接力的收益会被交接和返工吃掉。

缓解方式很简单：plan 的验收尽量落成一条可执行命令，Codex 自查对照命令，而不是对照描述。一旦某类任务反复返工，说明它不适合接力，应降回单 agent。

一句话

小任务用单 agent 跑完。任务大到值得“读大库规划 + 大量本地验证”时，才让 CC 规划、Codex 实现，中间只传一份带可执行验收标准的 plan。接力是为了各尽其长，不是为了显得流程完整。