用途：选择多 Agent 系统的组织形式，并理解每种拓扑的失效模式
| 拓扑 |
结构 |
优点 |
失效模式 |
| 顺序流水线 |
A → B → C |
简单可预测、易观测 |
延迟累加；上游错误向下游放大 |
| 并行扇出/汇聚 |
同一输入分发给 N 个 Agent，结果聚合 |
墙钟时间短、多样本投票 |
聚合策略弱则质量被平均；成本 N 倍 |
| 层级（主管-执行者） |
规划 Agent 分解并派发，执行 Agent 完成 |
上下文隔离好、职责清晰 |
规划者不了解执行细节导致任务切分失真 |
| 图/状态机（DAG + 条件边） |
节点是任务，边是数据与控制流 |
支持分支、重试、并行，可观测最好 |
需要显式设计，灵活性下降 |
| 黑板/共享状态 |
所有 Agent 读写同一份外部状态 |
灵活协作、无固定顺序 |
竞态与写冲突、责任不清、难复现 |
| 辩论/对抗 |
多 Agent 持不同立场互相质疑，裁判收敛 |
能暴露单一视角的盲点 |
容易趋同或陷入无效往返，成本高 |
| 自路由（动态规划下一步） |
LLM 决定调用哪个 Agent |
灵活 |
不可预测、难测试、成本失控 |
- 能确定流程就用图/流水线：可观测、可重放、可测试，工程性质最好。
- 需要并行就扇出 + 显式聚合：聚合规则（投票、最优、合并、裁判）必须事先定义。
- 任务边界不清再用层级：主管负责拆分与验收，不负责实现细节。
- 黑板模式慎用：共享可变状态是多 Agent 系统最难调试的问题来源，若必须用，要有字段级所有权与版本控制。
- 自路由留到最后：先让固定拓扑跑稳，再考虑动态决策。
| 要素 |
说明 |
| 任务契约 |
输入、输出格式、成功判据、超时与预算 |
| 状态外置 |
进度与中间产物写入外部存储（文件/DB），不依赖对话上下文 |
| 幂等与重试 |
节点可重跑且结果一致（见“失败恢复与幂等”） |
| 终止条件 |
最大步数、最大成本、无进展检测（避免自说自话循环） |
| 追踪 |
每个节点记录输入摘要、输出摘要、耗时、成本、模型与提示版本 |
| 降级 |
单节点失败时的替代路径（跳过、换策略、升级人工） |
多 Agent 与“一个 Agent + 多个工具”不是对立选项：能用工具解决的不要用 Agent。工具是确定性的（同输入同输出、可测试），Agent 是概率性的。系统的可验证部分应尽量由工具承担，Agent 只处理需要判断的部分。
| 误区 |
修正 |
| 用自由对话式协作替代契约 |
每个 Agent 有明确输入输出与验收标准 |
| 无终止条件的循环 |
步数、成本、无进展三重上限 |
| 聚合靠“取最后一个回答” |
显式定义投票/裁判/合并策略 |
| 拓扑选择凭喜好 |
按可预测性、可观测性与并行收益选择 |
| 忽略追踪与重放 |
无法定位错误来源，问题不可复现 |
- 本站：任务分解粒度、上下文传递与共享状态、失败恢复与幂等
- LangGraph、AutoGen、CrewAI 等开源编排框架的公开文档（拓扑与状态管理设计）