业务背景
把一个大任务交给单个 Agent，问题不在模型能力，而在上下文与稳定性：任务越长，上下文越容易漂；一旦某一步失败，整个会话要重来。多智能体编排的思路，是把大任务拆成可独立执行、可独立验收的子任务，由一个 Coordinator 统一调度。
关键挑战
- 任务拆解粒度：拆太粗，子 Agent 仍会上下文爆炸；拆太细，调度开销与 token 成本上升。
- 状态共享：子 Agent 之间如何同步"已知信息"（代码库怎么测、团队偏好什么），否则每个子 Agent 都在重复探索。
- 失败恢复：某个子 Agent 挂了，是重试、降级，还是回滚？没有统一策略就会互相甩锅。
- 成本放大：并行不是免费的。参考 Cursor 官方文档，五个子智能体并行约等于五倍 token 消耗——因为它各自维护独立上下文。
方案：Coordinator-Subagent 分层
核心是把"决策"和"执行"分离。Coordinator 只做规划、派活、验收，不直接干活；Subagent 只做被指派的事，做完即返回。
# 伪代码：最小可用的分层编排骨架
class Coordinator:
def run(self, goal: str):
plan = self.decompose(goal) # 1. 拆解为可验收子任务
results = {}
for task in plan.tasks:
agent = self.spawn(task) # 2. 派活（可并行）
result = agent.execute(task)
if not self.verify(task, result): # 3. 验收失败则重派/升级
result = self.retry_or_escalate(task)
results[task.id] = result
return self.merge(results) # 4. 汇总，交回人工终审
def verify(self, task, result) -> bool:
# 验收标准来自预先写好的 checklist，不依赖模型自由发挥
return all(check(result) for check in task.acceptance_criteria)
三个设计要点：
- Coordinator 不写代码/不产内容，只调度。这样它永远不会被单个子任务卡住，始终能响应新指令。
- 验收标准前置：
task.acceptance_criteria在拆解时就确定，避免"做完才发现不对"。 - 共享上下文文件：把"怎么测、怎么部署、团队偏好"沉淀成项目级文件，所有子 Agent 继承，减少重复探索。
实测观察
| 维度 | 单 Agent | 分层多 Agent |
|---|---|---|
| 长任务稳定性 | 上下文易漂，中断即重来 | 子任务独立，失败可局部重试 |
| 并行能力 | 受单会话限制 | 受资源与预算限制（非数量限制） |
| token 成本 | 线性 | 约按并行数倍增 |
| 适用任务 | 短、单步 | 长、可拆解、可验收 |
踩坑记录
- 并发不是越多越好。社区有反馈：一次性拉起数十个子 Agent 会打爆执行宿主，出现"无法启动""工作区断开"。稳妥做法是分批（wave），一批跑完再起下一批。
- 递归深度要限制。子 Agent 再开子 Agent 会形成树，失控。建议限制层级（部分产品已限制为两层）。
- 验收标准模糊的任务别交给多 Agent。编程任务有测试可自动验收，所以效果好；换成"写一份市场分析"，验收标准一模糊，产出质量就不可控。
适合 / 不适合
适合：任务可拆解、每步有明确验收标准、重复度高（迁移、批量重构、持续维护）。 不适合：任务边界模糊、验收靠主观判断、数据敏感且无法自托管的场景。
结论：多智能体编排降的是"搭编排层"的工程成本，不是"把活想清楚"的认知成本。后者仍是人的活。
