多智能体里的并行，经常在演示里看起来非常顺滑：控制器把任务一拆，多条分支同时跑，最后再把结果收回来。但真正进入生产环境后，问题通常不出在 fan-out，而是出在 join。分支跑得越多，会合越容易失控。
如果控制器没有提前定义会合契约，分支就会以不同格式、不同粒度、不同置信度回传结果。这样一来，并行带来的不再是吞吐提升，而是冲突裁决、结果对齐和恢复成本的持续上升。fan-out 只是开始，join contract 才决定并行是否真的可用。
为什么这个问题重要
真实运行代价
并行分支的真实成本，不只是在执行阶段。控制器要承担分支打开、状态追踪、超时处理、结果比对和最终裁决。如果这些分支最后只回到一段自然语言总结，控制器就无法稳定知道哪些分支完成了、哪些结论冲突、哪些证据缺失，以及下一步是否可以自动继续。
- 分支返回格式不一致，控制器无法统一合并。
- 分支完成时间不同，容易出现孤儿分支和重复等待。
- 冲突结论没有共同字段，后续裁决依赖人工理解。
如果不处理会怎样
没有 join contract 的并行，最常见的结果是“表面并行，实质返工”。多个角色虽然同时运行，但控制器最终只能靠二次总结去理解结果，导致会合时继续开新分支、反复追问缺失信息，或者干脆把任务交回人工。并行分支越多，回收成本反而越高。
适用场景
谁最需要这套方法
只要流程存在多源调查、并行取证、异步外部查询或多角色协同验证，join contract 都应该被前置设计。尤其是控制器要汇总多个专家角色输出，再决定是否继续、是否重试或是否触发人工审批时，会合契约直接决定系统能否规模化。
- 同一目标需要从多个来源并行收集证据。
- 多个执行角色返回不同类型结果，需要统一裁决。
- 系统需要在部分成功、部分失败的情况下继续推进。
什么时候先不要这么做
如果任务本身仍然是线性步骤，或者不同分支并不会在同一个控制点会合，那么并行只会增加额外状态和调度成本。这种场景更适合保持单路径执行，把清晰的恢复逻辑做完，再考虑是否值得 fan-out。
推荐系统结构
核心角色与状态
安全会合的关键，是让控制器在 fan-out 前就定义 join contract，而不是等分支跑完再即兴归纳。join contract 至少要包含分支标识、结果字段、证据链接、置信度、失败原因和截止时间。这样控制器在 join 阶段看到的不是三段散乱文本，而是一组可比较、可裁决、可恢复的结构化结果。
- fan-out 前先声明每个分支的输入、目标和回传字段。
- join 时按 contract 校验完成状态、缺失字段和冲突项。
- 把未完成、失败和冲突都纳入同一会合判断，而不是只看成功分支。
与 TaskPilots 的映射
在 TaskPilots 的多 Agent 协作编排集群里，join contract 对应的其实就是控制面上的“分支回收协议”。控制面知道哪些分支被打开、每条分支的期望回传结构是什么、哪些字段会触发继续执行，哪些字段会直接升级为人工审查。这样并行分支越多，控制器越需要依赖 contract，而不是依赖模型自己“看着办”。
风险与失效点
常见失控方式
最危险的并行，不是跑得慢，而是看起来跑完了却没法可靠会合。分支各自命名不同、证据粒度不同、失败原因写法不同，控制器最后只能把 join 退化成一次新的模型总结。另一类风险，是没有关闭条件的 fan-out，导致分支不断被追加，最终成本和等待时间一起失控。
- 部分分支成功后，控制器没有规则处理失败分支。
- 不同分支回传不同 schema，冲突无法自动识别。
- 没有 join 截止时间，系统持续等待低价值分支。
需要人工兜底的地方
当 join 阶段出现高价值冲突、关键证据缺失，或者并行分支中存在需要外部业务判断的结论时，人工接管应当发生在会合点，而不是分散到每个分支里。人工看到的最好是结构化 join 视图：各分支状态、证据、分歧项和建议动作，而不是三段彼此矛盾的自然语言摘要。
验证指标
上线前怎么验证
上线前应该刻意构造几类 join 测试：全部成功、部分失败、结果冲突、超时未回传。验证目标不是“分支都能跑完”，而是控制器能否在这些情况下稳定做出一致判断。只要 join contract 稍微模糊，这类测试就会很快暴露问题。
- 检查不同分支是否始终按统一字段回传。
- 检查部分失败时是否能继续、回退或补偿。
- 检查冲突结果是否能被明确标识和升级。
上线后怎么持续判断
生产阶段建议长期跟踪分支完成率、孤儿分支率、join 冲突率和会合延迟。孤儿分支率高，说明 fan-out 过宽或回收规则太弱；join 冲突率高但人工裁决效率低，说明 contract 字段设计不够支撑决策；会合延迟持续上升，则说明并行本身已经开始吞掉收益。
下一步 / FAQ
下一步建议
如果你的团队已经开始做并行分支，下一步不要继续加角色，而是先把 join contract 画出来。定义好每条分支必须回传什么、冲突如何识别、失败如何分类、超时如何关闭。只要 join 被做成显式结构，并行能力才算真的进入可运营阶段。
FAQ
join contract 会不会让分支变得太僵硬？ 不会。它约束的是回传结构，不是分支内部的推理过程；分支依然可以灵活工作，但最终必须以可会合的格式回来。
所有并行都需要 join contract 吗？ 只要多个分支要在同一个控制点汇总并决定下一步，就需要；否则问题只会被推迟到更晚的阶段爆发。
部分成功时一定要重跑全部分支吗？ 不一定。前提是你先设计好了哪些字段足以继续、哪些字段缺失就必须补跑。