跳转到主内容多智能体编排：让 AI 团队协作完成复杂任务
在第九篇里，我们认识了子智能体：Claude Code 能启动独立的子进程完成特定任务，我们也学会了定义自定义 Agent。
但那只是起点。当你面对一个真正复杂的任务——比如从需求分析到代码上线的全流程——单个 Agent 就算再强，也会遇到瓶颈：上下文窗口被塞满、角色混乱、一个环节出错整个流程重来。
这篇讲的是下一步：怎么让多个 Agent 像一个团队一样协作。
为什么需要多智能体编排
让一个 Agent 做「给项目加一个用户反馈功能」，它需要：理解需求、设计数据库、写后端、写前端、写测试、代码审查、更新文档。
如果一口气做完，会遇到三个问题：
上下文污染。 到第五步时，前面几步的代码和思考过程塞满了上下文，早期的设计决策开始被「忘记」。
角色冲突。 写代码的思维和审查代码的思维不同。同一个 Agent 既当运动员又当裁判员，审查质量打折。
容错困难。 第四步出了问题，得从头来过——因为整个流程是一个连续对话，没有清晰的断点。
多智能体编排的核心思路：把复杂任务拆成阶段，每个阶段由专门的 Agent 负责，通过明确的接口传递信息。
三种编排模式
串行流水线：A → B → C
一个 Agent 做完，把结果交给下一个。
规划 Agent → 实现 Agent → 测试 Agent → 审查 Agent
适用于步骤之间有严格先后依赖的场景。用 Skill 文件定义流程，每个阶段调用不同的自定义 Agent，Agent 的输出作为下一个的输入。
并行分工：A + B → 汇总
┌→ 前端 Agent ──┐
规划 Agent ──┤ ├→ 集成 Agent
└→ 后端 Agent ──┘
关键是定义好接口契约——前后端 Agent 各自独立工作，但遵守同一份 API 定义。集成 Agent 负责最后对齐。
主从模式：Boss + Workers
最灵活的模式。主 Agent 负责全局规划，根据中间结果动态分配任务。
┌→ Worker A
Boss ────┼→ Worker B
└→ Worker C（根据 A 的结果决定是否启动）
主从模式的区别在于：主 Agent 会根据中间结果动态调整计划，不是预先定好所有步骤。
完整案例：新功能从需求到上线
定义 Agent 团队
每个 Agent 是 .claude/agents/ 下的一个 .md 文件，定义了角色、职责和输出格式。
planner.md——规划者：分析需求，输出技术方案和任务清单。只做规划不写代码。
coder.md——实现者：根据任务描述写代码。严格按任务范围执行，不做额外「改进」。
tester.md——测试者：为变更代码编写测试，运行测试，报告发现的问题。
reviewer.md——审查者：用审查者视角检查代码，关注逻辑错误、安全隐患、规范一致性。
定义编排流程
创建 .claude/commands/feature-flow.md：
# 新功能开发流程
## 1. 规划
调用 planner 智能体，传入需求。展示方案给用户确认。
## 2. 实现
根据任务清单，逐个调用 coder 智能体。每完成一个任务记录变更文件。
## 3. 测试
调用 tester 智能体，传入变更文件和功能描述。
发现 bug 则传给 coder 修复，修复后重新测试。最多重试 2 次。
## 4. 审查
调用 reviewer 智能体，传入变更文件和技术方案。
审查不通过则传给 coder 修复。最多重试 2 次。
## 5. 收尾
汇总所有变更，建议 commit message。
实际使用
/feature-flow 用户反馈功能：页面底部提交评分和文字，管理员后台查看
Claude Code 按流程依次调用各 Agent：规划 → 确认 → 逐步实现 → 测试 → 审查 → 完成。你在关键步骤按 y 确认即可。
控制 Agent 之间的信息传递
用结构化格式传递。 不要让 Agent 用自由文本沟通，定义明确的输出格式（JSON 或固定 Markdown 结构），编排层可以可靠地提取和转发。
用文件系统作为共享状态。 Agent 之间除了直接传递文本，还可以通过文件共享信息。文件不受上下文窗口限制，可以被多个 Agent 反复读取。
只传递必要信息。 不要把前一个 Agent 的完整输出全部塞给下一个。传文件路径让 Agent 自己去读，而不是把文件内容塞进 prompt——这是大幅节省上下文的关键技巧。
什么时候值得用多 Agent
值得： 跨越多个关注点的任务、需要不同视角的任务、长流程任务（20 分钟以上）、需要容错的任务。
不值得： 单文件修改、探索性任务、简单的 CRUD。
经验法则：如果你发现自己想在 prompt 里说「先做 X，然后做 Y，记住 X 的结果来做 Z」——这通常是需要拆成多 Agent 的信号。
常见陷阱
信息丢失——Agent A 的关键决策没传给 Agent B。解决：显式定义需要传递的信息，关键决策必须包含。
编排过度复杂——设计了精密的多级系统，维护成本反而更高。解决：从简单开始，三四个 Agent 的流水线足够。如果编排逻辑超过 100 行，多半过度设计了。
成本失控——每个子 Agent 都消耗 token，四步流水线总成本可能是单 Agent 的三到五倍。解决：简单任务主 Agent 自己做、传文件路径而非内容、设置重试上限。
角色模糊——两个 Agent 职责重叠。解决：像写岗位说明书一样，明确每个 Agent「做什么」和「不做什么」。
起步建议
不要一上来就搞五个 Agent 的流水线。从最小方案开始：
一个主 Agent 写代码 + 一个审查 Agent 审查。在 CLAUDE.md 里加一条：「每次完成代码修改后，用 Agent 工具调用 reviewer 审查，修复问题后再提交。」
感受到好处后，再逐步添加 tester、planner 等角色。
编排的本质是软件工程最古老的智慧：分而治之。从简单开始，遇到瓶颈再加复杂度。最好的编排是你几乎感觉不到它的存在——它只是让事情自然地按正确的顺序发生。
本篇要点：
- 三种编排模式：串行流水线、并行分工、主从模式
- 每个 Agent 在
.claude/agents/ 中定义，编排流程在 .claude/commands/ 中定义
- Agent 之间用结构化格式传递信息，用文件系统共享状态
- 从最小方案开始（主 Agent + 审查 Agent），逐步添加角色
- 控制成本：简单任务不启动子 Agent，传路径而非内容，设重试上限
