MultiAgent 与任务编排：何时拆分，如何协作，怎样合并结果

1. 第一性原理：拆分的价值来自边界，不来自数量

一个任务只有在存在独立目标、独立上下文、可并行工作或不同权限时，拆成多个 Agent 才可能获得收益。否则多个 Agent 只是增加通信、上下文转换、失败面和成本。

先把任务写成依赖图：节点是可验证的工作，边是输入依赖。能并行的节点才有并行价值；必须共享大量上下文的节点通常更适合一个 Agent 内部的 Skill 或工具调用。

2. 四种协作 Pattern

Agent Handoff

一个 Agent 完成阶段性工作后，把恢复包交给另一个 Agent。恢复包不能只是对话记录，应包含目标版本、已验证事实、未完成事项、证据引用、权限和停止原因。Handoff 的难点是语义一致性，而不是消息转发。

Agent as Tool

主 Agent 把子 Agent 当成一个有 Schema 的工具调用。主 Agent 负责目标和预算，子 Agent 返回结构化结果。这个模式适合局部专长，例如让研究 Agent 搜集证据，让代码 Agent 修改仓库。

Leader & N Workers

Leader 拆分任务、分配预算、监控进度、合并和验证；Workers 只承担清晰的子任务。Leader 不能盲信 Worker 的“完成”，必须要求结果、证据、状态和失败原因。

Agent2Agent

多个对等 Agent 通过协议协商。协议至少需要消息类型、任务合同、能力声明、状态、超时、取消、错误、证据和幂等键。没有协议的自由对话很容易变成无法调试的 Prompt 链。

3. DAG、动态重规划与背压

静态 DAG 适合依赖清楚的任务；动态 DAG 允许根据观察结果增加、删除或重排节点。重规划必须受原任务合同约束，不能因为某个 Worker 的局部建议就改变全局目标。

并行度不能只由节点数量决定，还受 API 限流、Sandbox 配额、上下文预算和合并成本限制。Leader 应设置背压：当结果处理不过来时暂停派发，当失败率过高时降低并发或进入人工检查。

4. 结果合并与交叉验证

合并不是字符串拼接。每个 Worker 返回 result、evidence、confidence、errors 和 side_effects。Leader 根据来源可信度、互相独立程度和任务覆盖率合并；冲突信息应显式保留，不能静默选择。

研究任务可以让多个 Worker 从不同角度检索，再建立证据图；代码任务可以让一个 Worker 修改、另一个 Worker Review、第三个 Worker 运行测试。并行的真正价值是增加独立验证，而不是生成更多文本。

5. MultiAgent 与 Skill 的取舍

Skill 适合共享同一个 LoopSession、复用经验流程和低成本切换能力；MultiAgent 适合隔离上下文、权限和资源，或确实需要并行执行。模型能力提高后，One ReActLoop Agent × N Skill 可以替代许多早期路由式 MultiAgent，但不会替代有隔离需求的协作。

决策顺序应是：先尝试单 Agent + Tool，再尝试 Skill；只有当上下文、权限、资源或并行边界明确时才拆 Agent。

6. 失败与恢复

Worker 超时不等于 Worker 没有完成；Leader 必须查询状态或读取检查点。一个 Worker 失败后，可以重试同一节点、换模型、缩小任务、交给人工或让其他 Worker 接管。每种策略都要记录成本和证据，避免重复副作用。

7. 学习者练习

实现一个研究+代码并行任务：两个研究 Worker 独立收集证据，一个代码 Worker 实现最小方案，Leader 合并并让 Reviewer 验证。注入一个互相冲突的研究结果和一个超时 Worker，观察系统是否能保留冲突并继续推进。