Reference 0004
编排与多 Agent
先决定控制流是否需要动态性，再决定是否需要多个决策单元。
架构选择阶梯
| 场景 | 优先方案 | 理由 |
|---|---|---|
| 步骤、规则和输出格式已知 | 确定性 workflow | 可预测、便宜、容易测试 |
| 工具较少但路径需要动态判断 | 单 Agent | 上下文集中，通信成本低 |
| 子任务独立且可以同时运行 | 并行编排 | 减少等待，但需要汇总和失败策略 |
| 领域边界清晰、权限不同 | 多 Agent | 隔离上下文、工具和责任 |
| 只有增加 Agent 才能掩盖混乱 | 先重构 workflow | 多 Agent 会放大协议和调试成本 |
六种常见编排模式
Prompt chaining
把一个任务拆成固定的多个模型步骤，中间用结构化输出连接。
Routing
先分类，再把请求送到最合适的路径、工具或专长 Agent。
Parallelization
独立子任务并行执行，最后由汇总器合并结果并处理缺失项。
Orchestrator-workers
中央 Agent 动态拆分任务，worker 完成局部工作并返回约定结果。
Evaluator-optimizer
生成器产出结果，评估器按明确标准反馈，直到达到预算或质量门槛。
Handoff
当前 Agent 把控制权和必要上下文交给另一个 Agent，所有权发生转移。
多 Agent 必须先定义的合同
- 角色边界：每个 Agent 能决定什么，不能决定什么？
- 输入输出：交接使用什么 schema，哪些上下文必须过滤？
- 状态所有权：谁能写任务状态，谁只能返回建议？
- 工具权限：不同 Agent 的工具、数据和审批范围是什么？
- 终止与预算：何时返回上层、升级给人或停止重试？
- 失败语义：部分成功、超时、冲突和重复动作如何表达？
什么时候不该增加 Agent
如果新增 Agent 只是为了让 prompt 变短、把同一个决策来回转发，或者把权限问题藏到另一个名字后面，它通常不会提升可靠性。新增 Agent 至少应该带来一种清晰收益：上下文隔离、权限隔离、领域专长、真正的并行度，或更容易验证的局部合同。
多 Agent 是组织边界，不是能力魔法。
每增加一个 Agent，就增加一次交接、一次失败面、一套观测责任和一份成本预算。