核心内容：不只用一个模型，而是编排多个模型协同工作

前面 16 集我们聚焦于如何用好 Claude Code 这一个工具。但随着 OpenAI 发布 Codex 插件接入 Claude Code，一个全新的范式已经到来：模型不再等于产品，模型等于可调用的能力节点。你的竞争力不再是“用哪个模型”，而是“如何编排多个模型协同工作”。本集将深入解析多模型协作的三种模式、五阶段编排流程，以及必须警惕的风险。

1. 范式转变：从单模型到多模型编排

1.1 旧范式 vs 新范式

旧范式：

你 → 选择一个模型 → 期待它完成所有事情

“Claude 好还是 GPT 好？”

新范式：

你 → 编排多个模型 → 每个模型做它最擅长的事

“这个任务用 Claude 做架构设计，用 Codex 做对抗审查，用 Gemini 做文档生成”

1.2 为什么需要多模型？

原因	说明
单模型偏见	每个模型有自己的“思维定式”，独立审查能发现盲区
能力互补	Claude 擅长架构推理，Codex 擅长代码生成，Gemini 擅长长上下文理解
容灾切换	当一个模型卡住时，另一个可以接管任务
质量下限	多个模型独立审查，系统性提高代码质量

1.3 核心认知转变

模型不再是产品，模型等于可调用的能力节点。你的竞争力不再是“用哪个模型”，而是“如何编排多个模型”。

初级开发者：我该用 Claude 还是 GPT？

高级开发者：我用 Claude 做方案设计，Codex 做对抗审查，最后人工验证关键路径。

2. 三大协作模式

2.1 标准审查（/codex:review）

核心思想：就像代码需要别人 Review，AI 生成的代码也需要另一个 AI 来审视。引入第二个模型做独立判断，避免单模型偏见。

适用场景：

• PR Review —— 用不同模型做独立审查
• 重构回归检查 —— 确保重构没有引入新问题
• 规范校验 —— 检查代码是否符合团队规范

使用方式：

> 帮我实现 src/services/order.ts 的订单状态机

[Claude 生成代码]

/codex:review src/services/order.ts

Codex 正在审查...

独立审查报告

�� Critical

• handleStateTransition() 缺少并发保护：两个请求同时修改订单状态时

可能出现状态不一致。建议添加乐观锁或分布式锁。

�� Warning

• cancelOrder() 未验证订单当前状态：应该只有 PENDING 和 PROCESSING

状态的订单可以被取消，但代码允许取消任何状态的订单。

�� Suggestion

• 状态机转换表建议提取为常量，便于维护和测试

对比

Claude 实现质量：良好（逻辑完整，类型安全）

Codex 发现问题：3 个（Claude 未发现）

• 并发安全问题（Claude 盲区）
• 状态验证缺失（Claude 盲区）
• 代码组织建议（风格偏好）

修复 Codex 发现的问题

[Claude 修复，Codex 重新审查确认]

为什么有效：

单一模型审查的问题：

Claude 审查自己生成的代码 → 相同的思维路径 → 相同的盲区

“既然我这样写了，那应该没问题”

多模型审查的优势：

Claude 生成 → Codex 审查 → 不同的训练数据、不同的推理路径 → 不同的视角

“这个边界条件 Claude 没想到，但我注意到了”

2.2 对抗性审查（/codex:adversarial-review）

核心思想：最具工程价值的能力——主动挑战你的实现假设。不是检查代码风格，而是进行安全测试级别的思维对抗：追问边界条件、寻找隐式信任、探测绕过路径、检查并发安全。

适用场景：

• 安全敏感模块（认证、支付、权限）
• 核心业务逻辑（订单状态机、库存扣减）
• 关键基础设施（数据库连接管理、缓存策略）

使用方式：

> 实现用户密码重置功能

[Claude 生成实现]

/codex:adversarial-review src/services/password-reset.ts

Codex 正在进行对抗性审查...

对抗性审查报告

攻击路径分析

�� 攻击路径 1：Token 重放攻击

前提：攻击者获取了一个有效的重置 token

路径：在 token 使用后，短时间内重复提交

原因：token 使用后未立即失效，存在竞态窗口

修复：token 使用前用 Redis SETNX 加分布式锁

�� 攻击路径 2：用户枚举

前提：攻击者尝试重置不同邮箱

路径：分析响应时间差异来判断邮箱是否已注册

原因：已注册和未注册邮箱的处理时间不同（一个是查数据库，一个是直接返回）

修复：统一响应时间，无论邮箱是否存在都模拟数据库查询

�� 攻击路径 3：Token 暴力破解

前提：重置 token 只有 6 位数字

路径：6 位数字只有 100 万种组合，可能被暴力破解

修复：使用 32 位加密随机字符串

�� 攻击路径 4：旧 Token 复用

前提：用户申请了多个重置 token

路径：使用第一个 token 重置后，第二个 token 仍然有效

修复：一次重置请求使该用户所有未使用的 token 失效

边界条件检查

❌ 空邮箱 → 未处理

❌ 超长邮箱（1000+ 字符）→ 可能导致数据库错误

❌ 并发重置请求 → 未加锁

❌ 重置 token 过期后重新请求 → 逻辑正确 ✅

❌ 用户在重置过程中登录 → 未处理（应取消重置流程）

修复优先级

1. Token 重放攻击（Critical）—— 立即修复
2. 用户枚举（Critical）—— 立即修复
3. 旧 Token 复用（High）—— 本次修复
4. 空邮箱和超长邮箱（Medium）—— 本次修复
5. Token 暴力破解（Medium）—— 规划中修复
6. 并发重置（Low）—— 后续迭代

对抗性审查的价值：

普通审查发现的问题：

“变量命名可以更好” ← 风格问题

“函数有点长” ← 结构问题

“缺少注释” ← 文档问题

对抗性审查发现的问题：

“存在 Token 重放攻击” ← 安全隐患

“时间响应差异可被用于用户枚举” ← 安全漏洞

“并发状态下数据可能不一致” ← 逻辑缺陷

“6 位数字 Token 可被暴力破解” ← 安全风险

前者提升代码质量上限，后者守住代码质量下限。

2.3 任务接管（/codex:rescue）

核心思想：当 Claude Code 卡住或反复在同一问题上犯错时，把当前上下文完整交给 Codex 接管。本质是多智能体的容灾切换（failover）——不把鸡蛋放在一个篮子里。

适用场景：

• Claude 反复在同一个问题上失败（3 次以上）
• Claude 陷入无限循环（修复 A 导致 B 错误，修复 B 导致 A 错误）
• 任务超时，需要快速产出结果
• 特定领域问题，Claude 不擅长

使用方式：

> 排查这个 WebSocket 连接泄漏问题。现象：运行 30 分钟后连接数持续增长直到 OOM。

[Claude 尝试 3 次...]

第 1 次：分析了代码，认为问题在连接超时设置，修改后问题依然存在

第 2 次：怀疑是事件监听器未移除，修复后连接泄漏减少但未根除

第 3 次：检查了所有关闭逻辑，但仍有约 5% 的连接未正确释放

/codex:rescue

正在将当前上下文移交给 Codex...

移交内容包括：

• 问题描述和复现步骤
• 相关代码文件（WebSocket 管理模块）
• Claude 的 3 次尝试和结果
• 当前代码状态（包括 Claude 的修改）

Codex 接管中...

Codex 分析

Claude 遗漏的关键点

Claude 的 3 次尝试都聚焦在显式断开连接的处理上。

但泄漏的 5% 连接有一个共同特征：它们都在 GC 之前就失去了引用。

根因定位

问题不在断开逻辑，而在连接管理器的引用持有方式。

当前代码使用 WeakMap 存储连接引用，预期 GC 自动清理。

但 WebSocket 连接在底层有 C++ 回调引用，阻止了 GC。

修复方案

在 onclose 事件中显式调用 terminate() 方法，释放底层资源。

这个方法是 2024 年才加入的 API，Claude 的训练数据可能未覆盖。

修复代码

[提供具体修复代码]

验证方案

1. 用 autocannon 模拟 1000 个并发连接
2. 监控 process.memoryUsage() 30 分钟
3. 确认连接数在预期范围内波动

应用 Codex 的修复

✅ 修复完成，验证通过！

30 分钟压测：连接数在 50-80 之间正常波动，无持续增长。

任务接管的最佳实践：

场景	接管策略
Claude 3 次修复失败	立即触发接管，不再浪费 Token
任务超时 5 分钟+	触发接管，争取快速产出
特定领域问题	如果知道其他模型更擅长，主动切换
Claude 陷入修复循环	触发接管，打破循环

3. 五阶段 Agent 编排模式

3.1 模式概述

这是来自黑客松冠军团队的最佳实践，将复杂开发任务分解为五个标准阶段，每个阶段使用最适合的 Agent：

┌─────────────────────────────────────────────────────────┐

│ Phase 1: RESEARCH — Explore Agent 调研 │

│ 输入：需求描述 │

│ 输出：research-summary.md │

│ 上下文：全新 │

└─────────────────────────────────────────────────────────┘

↓

┌─────────────────────────────────────────────────────────┐

│ Phase 2: PLAN — Planner Agent 规划 │

│ 输入：research-summary.md │

│ 输出：plan.md │

│ 上下文：仅加载 research-summary.md │

└─────────────────────────────────────────────────────────┘

↓

┌─────────────────────────────────────────────────────────┐

│ Phase 3: IMPLEMENT — TDD 引导 Agent 实现 │

│ 输入：plan.md │

│ 输出：代码变更 + 测试结果 │

│ 上下文：仅加载 plan.md │

└─────────────────────────────────────────────────────────┘

↓

┌─────────────────────────────────────────────────────────┐

│ Phase 4: REVIEW — Code Reviewer Agent 审查 │

│ 输入：代码变更 │

│ 输出：review-comments.md │

│ 上下文：仅加载变更文件和 plan.md │

└─────────────────────────────────────────────────────────┘

↓

┌─────────────────────────────────────────────────────────┐

│ Phase 5: VERIFY — Build Error Resolver 修复与验证 │

│ 输入：review-comments.md │

│ 输出：修复后的代码 + 通过验证 │

│ 上下文：仅加载 review-comments.md 和变更文件 │

│ │

│ 如果验证失败 → 回到 Phase 4 重新审查 │

│ 如果验证通过 → 任务完成 │

└─────────────────────────────────────────────────────────┘

3.2 关键规则

规则一：职责单一

每个 Agent 只有一个清晰输入和一个清晰输出。

❌ 错误设计：

Agent 1：调研 + 规划 + 实现

→ 职责混杂，难以判断哪个环节出问题

✅ 正确设计：

Agent 1（Explore）：调研 → research-summary.md

Agent 2（Planner）：规划 → plan.md

Agent 3（Implementer）：实现 → 代码变更

Agent 4（Reviewer）：审查 → review-comments.md

Agent 5（Resolver）：修复 → 通过验证

→ 每个环节独立、可替换、可调试

规则二：阶段间清理上下文

每完成一个阶段，用/clear清理上下文，防止上下文膨胀和污染。

Phase 1 完成 → /clear

Phase 2 完成 → /clear

Phase 3 完成 → /clear

Phase 4 完成 → /clear

Phase 5 完成 → /clear

为什么？

• Phase 1 的调研对话细节对 Phase 3 的实现没有帮助
• Phase 3 的实现过程对 Phase 4 的审查来说是噪音
• 清理上下文让每个 Agent 只看到它需要的信息

规则三：文件即契约

中间输出存储为 Markdown 文件，实现阶段间状态传递。让每个 Agent 都基于明确的产物工作，而非依赖对话历史。

research-summary.md → plan.md → 代码变更 → review-comments.md

每个文件都是阶段间的契约：

• 上一个阶段的输出 = 下一个阶段的输入
• 如果结果不对，检查中间产物，快速定位问题
• 所有产物可版本控制、可审查、可复用

3.3 完整实战示例

任务：为电商平台添加优惠券系统

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Phase 1: RESEARCH

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

我需要为电商平台添加优惠券系统。请调研：

1. 常见的优惠券类型（满减、折扣、直减）
2. 每种类型的计算逻辑
3. 有效期管理和状态转换
4. 与现有订单系统的集成点

  

产出 research-summary.md

[Explore Agent 调研中...]

✅ research-summary.md 已生成

主要内容：

• 优惠券类型：满减、折扣、直减、运费券
• 计算逻辑：每种类型的公式和优先级
• 状态机：CREATED → ACTIVATED → USED/EXPIRED/DISABLED
• 集成点：订单计算流程、库存扣减、退款处理

/clear

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Phase 2: PLAN

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

基于 @research-summary.md，制定优惠券系统的实现计划。

包含：文件结构、数据库 Schema、API 设计、实现顺序、测试策略。

产出 plan.md

[Planner Agent 规划中...]

✅ plan.md 已生成

文件结构：

• src/db/schema/coupon.ts
• src/services/coupon/

├── types.ts

├── calculator.ts

├── validator.ts

└── manager.ts

• src/api/coupon/

├── create.ts

├── validate.ts

└── apply.ts

数据库 Schema：

• coupons 表（类型、规则 JSON、有效期）
• user_coupons 表（用户领取记录、状态）

实现顺序：

1. Schema + Migration
2. 计算引擎（纯函数，易测试）
3. 验证器
4. 管理器（整合计算和验证）
5. API 端点
6. 与订单系统集成

/clear

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Phase 3: IMPLEMENT

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

基于 @plan.md，使用 TDD 方式逐步实现。

先写测试，再实现功能。每完成一个模块运行测试确认。

[Implementer Agent 实现中...]

1. Schema + Migration ✅
   • 测试：Migration 执行成功，Schema 符合设计

1. 计算引擎 ✅
   • 测试：12 个测试用例全部通过
   • 覆盖：满减、折扣、直减、运费券、叠加规则

1. 验证器 ✅
   • 测试：8 个测试用例全部通过
   • 覆盖：有效期、最低消费、适用范围、使用次数

1. 管理器 ✅
   • 测试：15 个测试用例全部通过

1. API 端点 ✅
   • 测试：10 个测试用例全部通过

1. 订单系统集成 ✅
   • 测试：5 个集成测试全部通过

总测试：50/50 通过 ✅

/clear

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Phase 4: REVIEW

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

审查所有优惠券系统的代码变更。

重点：安全性、正确性、性能、与 plan.md 的一致性。

产出 review-comments.md

[Reviewer Agent 审查中...]

✅ review-comments.md 已生成

�� Critical

• coupon/calculator.ts L78：叠加优惠券计算顺序可能导致

金额为负（先打折再减满减，如果折扣后金额小于满减条件）

�� Warning

• coupon/validator.ts L45：未验证优惠券使用次数上限
• api/apply.ts L23：缺少并发控制（同一优惠券可能被多次使用）

�� Suggestion

• coupon/manager.ts：建议将优惠券规则解析提取为独立函数

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Phase 5: VERIFY

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

根据 @review-comments.md 修复所有问题。

[Resolver Agent 修复中...]

1. 修复叠加计算顺序 ✅

新增 3 个测试用例覆盖边界条件

1. 添加使用次数验证 ✅
2. 添加并发控制 ✅

使用数据库行锁防止重复使用

/codex:adversarial-review src/services/coupon/

对抗性审查通过 ✅

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

✅ 优惠券系统开发完成

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

最终产出：

• research-summary.md（调研报告）
• plan.md（实现计划）
• 代码变更（50 个测试全部通过）
• review-comments.md（审查意见，已全部修复）
• 对抗性审查通过

4. 风险警示与防御措施

4.1 风险一：死循环与 Token 爆炸

场景：两个 Agent 互相调用，陷入无限循环。

Agent A：我审查发现一个问题，请修复

Agent B：我修复了，但引入了新问题

Agent A：我发现新问题，请修复

Agent B：我修复了，但又引入了另一个问题

Agent A：我发现...

...

结果：无限循环，Token 消耗无上限

防御措施：

{

"multiAgent": {

"maxTotalTurns": 20,

"maxTurnsPerPhase": 5,

"maxCostLimit": 50

}

}

防御策略	说明
设置最大总轮次	超过 20 轮整体任务自动终止，转为人工接管
设置每阶段最大轮次	单个阶段超过 5 轮自动终止，跳过该阶段
设置成本上限	Token 消耗超过阈值自动终止
人工兜底	任何自动终止后，生成详细的状态报告供人工决策

4.2 风险二：成本不可控

场景：多模型叠加使调用次数翻倍、上下文变长、成本激增。

单模型：1 次实现 + 1 次自检 = 2 次调用

多模型：1 次调研 + 1 次规划 + 1 次实现 + 1 次审查 + 1 次修复 + 1 次对抗审查 = 6 次调用

成本 = 单模型成本 × 调用次数 × 上下文长度

防御策略：

成本分级决策：

�� 核心功能（认证、支付、数据完整性）：

→ 启用完整五阶段 + 对抗性审查

→ 成本无上限（质量优先）

�� 重要功能（主要业务流程）：

→ 启用四阶段（跳过独立调研，合并到规划）

→ 成本控制在 $10 以内

�� 一般功能（UI 组件、工具函数）：

→ 启用两阶段（实现 + 标准审查）

→ 成本控制在 $3 以内

⚪ 简单修改（单文件、单函数）：

→ 单模型完成，不启用多模型

→ 成本控制在 $0.5 以内

4.3 风险三：模型间“互相否定”

场景：两个模型的推理路径互相冲突。

Claude：使用 Redis 分布式锁解决并发问题

Codex：使用 PostgreSQL 行锁解决并发问题

两个方案互相否定：

• Claude 指出 Redis 锁有主从切换丢失的风险
• Codex 指出 PostgreSQL 行锁会降低数据库性能
• 陷入“谁对谁错”的死锁

防御措施：

模型冲突解决策略：

1. 记录冲突

[冲突日志] 模型 A 建议方案 X，模型 B 建议方案 Y

1. 分析冲突原因
   • 是信息不对称？（一个模型看到了另一个没看到的上下文）
   • 是偏好不同？（两个方案都可行，但优化方向不同）
   • 是真冲突？（一个方案正确，一个方案错误）

1. 按规则裁决
   • 安全问题 → 遵循更严格的方案
   • 性能问题 → 用基准测试数据决定
   • 风格问题 → 遵循项目 CLAUDE.md 规范

1. 无法裁决时

→ 转为人工判断

→ 在冲突报告中清晰呈现两方的论据

→ 由开发者做最终决策

核心原则：AI 编排不等于无人值守。

多模型协作的价值是提供多视角分析，最终决策权永远在人手中。

5. 学习要点总结

通过本集的学习，你应该掌握：

1. ✅范式转变：模型不再等于产品，模型等于可调用的能力节点
2. ✅标准审查：引入第二个模型做独立判断，系统性提高代码质量下限
3. ✅对抗性审查：主动挑战实现假设，发现单一模型永远找不到的盲区
4. ✅任务接管：当 Claude 卡住时，把上下文完整交给 Codex，实现容灾切换
5. ✅五阶段编排：RESEARCH → PLAN → IMPLEMENT → REVIEW → VERIFY
6. ✅三大关键规则：职责单一、阶段间清理上下文、文件即契约
7. ✅三大风险防御：死循环（设置最大轮次）、成本爆炸（按任务价值分级）、模型冲突（人工兜底）

本文档基于 Claude Code 官方文档及技术社区公开资料整理，信息截止日期 2026 年 6 月。