多智能体编排模式
何时该拆分任务、四种协作拓扑，以及为什么大多数任务其实不该拆。
先用单智能体，被迫时才拆
多智能体很有吸引力，也经常被过早采用。每一次拆分都会增加：序列化开销、协作协议、接缝处的故障模式，以及调试难度。
满足以下任一条时才拆：
- 上下文确实装不下。 子任务要探索成千上万行，而只有结论有价值。
- 并行有实际收益。 子任务彼此独立，且挂钟时间要紧。
- 确实需要专业化。 需要不同工具、不同权限，或系统提示词在同一线程里互相冲突。
- 校验必须独立。 需要一个看不到执行者推理过程的独立检查方。
一条都不满足就留在单智能体。「感觉更清晰」不算理由。
四种拓扑及其取舍
| 模式 | 形态 | 适用场景 | 主要风险 |
|---|---|---|---|
| 主管式 | 中心分发给执行者并汇总 | 可良好分解的任务 | 中心成为瓶颈与上下文堵塞点 |
| 流水线 | 顺序阶段，逐级转换产出 | 抽取 → 转换 → 审核 | 错误向下游累积放大 |
| 辩论式 | 两方论证，第三方裁决 | 高风险的决策 | 成本三倍；可能收敛到自信的胡话 |
| 集群式 | 对等节点互相转交 | 开放式探索 | 难调试、难终止 |
默认选主管式。 它最容易推理，也最容易加监控。
中心传递结论，而不是对话记录
最常见的编排缺陷：主管把每个执行者的完整历史拼接起来。上下文爆炸，注意力被摊薄到无关细节。
要为每个执行者定义返回契约：
returns: { task_id, status, findings[], artifacts[], unresolved[] }
中心只看结论和指针。真需要更多细节时再去要——这比永远携带全部要便宜。
给每个智能体设终止条件
智能体会打转。启动前就要定义：
- 每个智能体的最大迭代次数或工具调用次数
- 什么算完成（而不是「看起来差不多了」）
- 哪些情况应交由人工而非重试
没有边界的执行者就是没有上限的账单。
接缝处的故障处理
多智能体有一些单智能体没有的失败形态：部分结果、中途超时、兄弟节点输出互相矛盾。
- 超时：返回部分进展 + 显式的不完整标记，绝不静默丢弃任务
- 矛盾：升级给裁决者或人工，不要让中心随便挑一个
- 反复失败：响亮地让任务失败，而不是第四次重试
调试分布式推理
多智能体系统失败时是静默且昂贵的。最低限度的埋点：
- 贯穿每个执行者与工具调用的 trace id
- 每个智能体的输入/输出分别记录
- 按智能体归集的 token 成本
尽早实现可重放能力：能用相同输入重跑单个执行者，可以把互相甩锅变成定位问题。
关于成本
并行智能体让 token 开销增长得非常快。横向扩容前，先确认「单智能体 + 更好的上下文管理」能否以几分之一的成本拿到九成收益。通常能。