多 Agent 编排与协作模式
什么是 AI Agent
在 AI 辅助开发的语境中，Agent（智能体） 是指能够独立执行一系列任务的 AI 实例。与简单的"问答式"交互不同，Agent 能够：
- 自主规划完成目标所需的步骤
- 调用工具（读写文件、执行命令、搜索代码）
- 根据工具返回的结果调整后续行动
- 在多轮操作中保持任务上下文
Claude Code 中的子代理（subagent）、Cursor 的 Composer Agent、GitHub Copilot Workspace 都是 Agent 的典型实现。理解 Agent 的能力边界，是有效编排多 Agent 协作的基础。
单 Agent vs 多 Agent 模式
单 Agent 模式
一个 AI 会话处理整个任务流程：
用户 → Agent → 分析需求 → 编写代码 → 运行测试 → 修复问题 → 完成适用场景：
- 任务规模较小，单个 Agent 的上下文窗口足够容纳
- 任务各步骤紧密关联，需要共享大量上下文
- 团队刚开始使用 AI 辅助开发，复杂度较低
局限性：
- 长任务会导致上下文窗口压力增大，质量下降
- 无法并行处理独立子任务
- 单点故障：一个 Agent 卡住，整个流程停止
多 Agent 模式
多个 AI 实例协同工作，各自负责不同的职责：
编排 Agent（Orchestrator）
├── 实现 Agent A（负责后端代码）
├── 实现 Agent B（负责前端代码）
└── 审查 Agent C（负责代码审查）适用场景：
- 大型任务需要超过单个上下文窗口的代码量
- 存在可以并行处理的独立子任务
- 需要角色分离（实现者与审查者相互独立）
- 对质量要求较高，希望通过多轮验证提升可靠性
任务分发策略
按技术层分发
最常见的分发方式，将系统的不同技术层交给不同 Agent：
任务：实现用户个人资料功能
Agent 1（数据层）：
- 设计数据库 schema
- 编写 Prisma 模型
- 创建数据迁移文件
Agent 2（API 层）：
- 实现 RESTful 接口
- 编写 API 测试
- 处理认证和权限
Agent 3（前端层）：
- 实现 React 组件
- 实现状态管理
- 编写组件测试按功能模块分发
当多个功能模块互相独立时，水平分发效率更高：
任务：重构电商系统
Agent A → 用户模块（注册、登录、个人资料）
Agent B → 商品模块（列表、详情、搜索）
Agent C → 订单模块（创建、支付、状态追踪）
Agent D → 通知模块（邮件、站内信、推送）这四个模块可以完全并行开发，最后统一集成。
按角色分发
在质量要求较高时，引入角色分离：
| 角色 | 职责 | 工作内容 |
|---|---|---|
| 架构 Agent | 设计决策 | 技术选型、接口设计、模块划分 |
| 实现 Agent | 编写代码 | 按规格实现功能 |
| 审查 Agent | 质量把关 | 代码审查、安全检查 |
| 测试 Agent | 质量验证 | 编写测试、覆盖率分析 |
Agent 通信模式
通过文件传递上下文
最简单可靠的通信方式：Agent 通过读写文件交换信息。
规格文档（spec.md）
↓ Agent A 读取规格
Agent A 实现后端代码
↓ 输出到 src/api/
Agent B 读取 spec.md + src/api/（接口定义）
Agent B 实现前端代码
↓ 输出到 src/components/
Agent C 读取所有代码文件
Agent C 进行代码审查，输出 review.md这种方式天然适合 Claude Code，因为子代理可以访问文件系统。
通过结构化输出传递
要求 Agent 以固定格式输出结果，便于后续 Agent 解析：
markdown
## Agent A 输出格式（接口定义）
### 已实现的 API 接口
| 路径 | 方法 | 描述 | 请求体 | 响应 |
|------|------|------|--------|------|
| /api/users | POST | 创建用户 | UserCreateDTO | UserResponseDTO |
| /api/users/:id | GET | 获取用户 | - | UserResponseDTO |
### TypeScript 类型定义
[代码块：所有 DTO 和响应类型]
### 注意事项
- 认证方式：Bearer Token
- 所有错误响应格式：{ error: string, code: string }当 Agent B 需要调用这些接口时，只需读取这份结构化输出。
编排 Agent 模式
使用一个主 Agent 来协调其他 Agent 的工作（在支持子代理的工具如 Claude Code 中）：
你是一个编排 Agent。你的任务是协调以下工作流完成用户认证功能的实现。
步骤 1：调用 subagent，让它分析现有代码库，输出：
- 当前项目使用的技术栈
- 现有的认证相关代码（如果有）
- 建议的实现方案
步骤 2：基于步骤 1 的分析，调用 subagent 实现后端认证 API
步骤 3：后端完成后，调用另一个 subagent 实现前端集成
步骤 4：调用 subagent 对生成的所有代码进行安全审查
在每个步骤完成后，向我汇报进展，等待我确认后再执行下一步。实用协作模式
模式一：实现者 + 审查者
这是最简单也最实用的双 Agent 模式：
对话 1（实现者）：
系统提示：你是一位专注的后端开发者，使用 Node.js + Express + Prisma。
任务：实现订单创建 API，要求：[详细规格]
→ 实现者输出代码
对话 2（审查者）：
系统提示：你是一位资深代码审查员，专注于安全性和代码质量。
任务：请审查以下代码，重点关注安全漏洞、边界条件和可维护性：
[粘贴实现者的输出]
→ 审查者输出审查意见
对话 1（实现者修复）：
根据以下审查意见修改代码：[粘贴审查意见]为什么有效： 同一个 AI 在不同的角色框架下，会以不同的视角审视代码。实现者倾向于让代码"能工作"，审查者则会主动寻找问题。
模式二：并行 Agent 处理独立任务
当有多个完全独立的任务时，并行启动多个 Agent 会话：
bash
# 用 Claude Code 的 worktree + 多窗口实现并行
# 终端 1：Agent 处理支付集成
cd /project-feature-payment
claude "实现 Stripe 支付集成，参考规格文档..."
# 终端 2：Agent 处理邮件通知
cd /project-feature-email
claude "实现 SendGrid 邮件通知服务，参考规格文档..."
# 终端 3：Agent 处理数据导出
cd /project-feature-export
claude "实现 CSV/Excel 数据导出功能，参考规格文档..."三个任务完全并行，显著缩短整体开发时间。
模式三：探索 + 实现流水线
用一个 Agent 探索多种方案，选定方案后用另一个 Agent 精确实现：
探索 Agent 任务：
分析以下需求，提供 3 种不同的实现方案，
包括各方案的优缺点、技术风险和估计工作量：
[需求描述]
→ 人类选择方案 B
实现 Agent 任务：
按照以下方案设计精确实现代码，不要偏离方案设计：
[方案 B 的详细描述]
[相关规格约束]这种方式充分利用 AI 的"广度探索"能力，同时保持实现阶段的精确性。
编排工具对比
| 工具 | Agent 能力 | 并行支持 | 适用场景 |
|---|---|---|---|
| Claude Code | 原生 subagent，可调用工具 | 多窗口手动并行 | 复杂代码库任务 |
| Cursor Composer | 单 Agent，强文件操作 | 多标签页 | 前端开发、重构 |
| GitHub Copilot Workspace | 规划 + 实现两阶段 | 有限 | PR 级别任务 |
| LangChain/LangGraph | 完全可编程编排 | 原生支持 | 自定义复杂流水线 |
| CrewAI | 角色化多 Agent 框架 | 原生支持 | 结构化团队协作模拟 |
多 Agent 的常见陷阱
上下文不一致
多个 Agent 并行工作时，可能对同一个问题做出不同的假设（如接口命名、错误码格式）。
解决方案： 在任务分发前，用规格文档明确所有共享约定，并作为每个 Agent 的必读上下文。
集成失败
各部分单独测试通过，但集成时出现问题。
解决方案： 明确定义集成点（接口契约、事件格式、数据结构），并在集成前进行契约验证。
编排复杂度失控
过度设计多 Agent 系统，编排逻辑比被解决的问题本身更复杂。
解决方案： 从最简单的单 Agent 方案开始，只在有明确收益时才引入多 Agent。多 Agent 是手段，不是目的。
循环依赖
Agent A 等待 Agent B 的输出，Agent B 又在等待 Agent A。
解决方案： 在任务分解阶段就绘制依赖关系图（参考任务分解文章），确保依赖是有向无环的。
实践建议
- 从单 Agent 开始：先用单个 Agent 完成任务，了解瓶颈后再考虑引入多 Agent
- 保持通信简单：优先使用文件作为通信媒介，避免复杂的消息传递机制
- 人在回路中：关键决策点保留人工确认，不要完全自动化
- 记录 Agent 行为：让每个 Agent 输出工作日志，便于调试和回溯
- 逐步增加复杂度：掌握双 Agent 模式后，再考虑更复杂的编排