4.8 多智能体协作
多智能体会以新的方式失败#
当系统里有多个 AI 模块（驾驭引擎、复盘引擎、汇流引擎、各种部件）时，每个模块单独看都正常，合在一起仍可能失败。多智能体系统失败分类〔理论〕C（Cemri 等, 2025） 分析了多个多智能体框架的运行轨迹，把失败归为三大类〔具体模式数量未核实〕：
- 规格与系统设计问题：角色定义不清、任务规格含糊、不遵守约束、丢失对话历史；
- 智能体之间的错位：信息不共享、忽视其他智能体的输入、推理和行动不一致、任务跑偏；
- 任务核验与终止问题：过早终止、不核验或核验不充分、不知道什么时候算完成。
组织理论的提醒#
多智能体系统和人类组织面对的是同一类协调问题。协调理论 （Malone & Crowston, 1994）：协调就是管理活动之间的依赖关系，常见的依赖有共享资源、先后顺序、同时进行、任务与子任务。（Steiner, 1972） 的群体生产力模型：实际产出 = 潜在产出 − 过程损失（协调损失和动机损失）。
一心行动的现有做法#
产品在这方面已经有很扎实的工程设计〔产品，A15、M14、Agent/〕：
- 单一写者：每个对象只有一个主人 Agent；多个 Agent 可以并行读和判断，但写入排队；
- 代码合入：写入包带基线哈希和读集，由代码按对象逐条核对后写入；
- 人优先：本人正在编辑或改过的对象，以本人为准；
- 统筹派发：由代码而不是模型来派发任务。
这些设计对付的正是 Cemri 分类里的第一、二类问题。v3 把 A15 从「理论公理」降级为「工程规范」，不是因为它不重要，而是因为它防的是数据完整性问题，而不是行动效果问题。〔本文提议〕
补充建议#
- 独立核验：对付第三类问题。完成判定由代码或独立的模块做，而不是由执行者自己宣布「完成了」。产品已有「已核验完成 / 待人工核对」的区分〔产品，M19〕，方向正确。
- 明确终止条件：每个任务单写明「什么算完成」，与 A3 的「结果预测」合并。
- 模块数量要克制：每增加一个模块，就增加协调开销。新增模块前，先说明它对付的是哪个失败机制（与 P27 一致）。〔本文提议〕