多智能体协作设计要点：角色拆分、编排拓扑与状态管理

从单 Agent 到多 Agent，难点往往不在“多”，而在协作边界是否清楚。本文从工程视角梳理多智能体系统的角色拆分、编排拓扑、消息与状态设计，以及失败处理与可观测性的关键取舍。

一、先判断：真的需要多智能体吗

单 Agent 在上下文过长、职责混杂、工具过多时容易暴露三类问题：指令互相干扰、工具选择错误率升高、出错后难以定位。多 Agent 的价值在于把一个大而模糊的任务拆成若干边界清楚、上下文独立的子任务，让每个 Agent 只携带自己需要的信息。

但它同时引入新的成本：通信开销、状态一致性、调试复杂度都会上升。实践中的经验是，满足以下任一条件再考虑拆分：

• 子任务需要不同的工具集；
• 子任务需要独立且较长的上下文；
• 子任务之间可以并行；
• 子任务需要不同的模型、成本档位或权限。

如果以上都不成立，先把单 Agent 的 prompt、工具定义和输出校验做好，收益通常更大。

二、角色拆分：按交付物，而不是按“岗位”

最常见的错误是照搬组织架构——产品经理 Agent、开发 Agent、测试 Agent——结果每个 Agent 都很“泛”，prompt 越写越长，职责仍然重叠。

更稳的拆法是以交付物为边界：每个 Agent 的输入和输出都应是结构化、可校验的产物，例如一段代码补丁、一份 JSON 格式的评审结论、一个测试报告。判断拆分是否合理，可以用三个问题自检：

1. 这个 Agent 的输出能否被 schema 校验？
2. 它需要的上下文能否独立获取，而不依赖其他 Agent 的隐式记忆？
3. 它失败时能否被独立重试，而不必重跑整条链路？

三个问题都能回答“是”，拆分的边界基本就是可靠的。

三、编排拓扑：优先中心化，再谈自治

常见的编排方式可以归纳为四类：

Supervisor（中心调度）：由一个 Leader 负责任务拆解、分派与汇总，Worker 只处理被分派的子任务。实现简单、链路清楚，是大多数业务场景的默认选择。代价是 Leader 的上下文容易成为瓶颈，需要控制它的记忆规模。

Pipeline（流水线）：按阶段串行执行，例如“生成—评审—修复”。天然有序、每段可独立重跑，适合流程稳定的场景；缺点是并行度低。

Blackboard（共享黑板）：Agent 之间不直接对话，而是通过共享存储读写中间结果。解耦程度高，但必须处理并发写冲突与版本覆盖问题。

Peer-to-peer（点对点协商）：Agent 之间直接传递消息。灵活，但行为难以预测，容易陷入循环对话。除非有明确的终止条件和预算上限，否则不建议作为第一版方案。

一个务实的演进路径是：单 Agent → Supervisor → 在 Supervisor 内部把高频子流程改为 Pipeline。不要一开始就追求全自治的 Agent 团队。

四、通信与状态：消息要小，状态要显式

消息设计建议遵循三条规则：

• 只传必要信息，避免把完整对话历史复制给每个 Agent；
• 消息带类型和版本，例如 {type: "task.assign", task_id, payload, schema_version}；
• 关键决策留痕，便于回放与审计。

共享状态应当显式建模，而不是藏在某个 Agent 的 prompt 里。可以维护一张任务表（task_id、owner、status、artifact_ref、retry_count），所有 Agent 只读写这张表，消息仅作为变更通知。这样即使某个 Agent 异常退出，也能从表中恢复现场，而不是从头再来。

五、失败处理：把重试写进协议

多 Agent 系统的失败模式比单 Agent 更多：循环调用、消息丢失、产物格式不合法、子任务超时。几条实用的约束：

• 为每个 Agent 设置最大步数与超时，避免无限循环；
• 对产物做 schema 校验，校验失败优先让原 Agent 修复，而不是换一个 Agent 重做；
• 检测循环：同一个 task_id 在短时间内被重复分派即触发告警；
• 设计降级路径：Leader 不可用时，能否退化为单 Agent 完成核心部分。

六、可观测性与评测

多 Agent 的调试成本主要来自“看不见”。至少应记录：每条消息的发送方与接收方、耗时、token 消耗、产物引用，并用 trace_id 把一次用户请求下的所有 Agent 调用串起来。

评测不要只看最终答案，可以把指标拆成：任务成功率、平均步数、无效调用占比、人工接管率。对多 Agent 系统还应单独评估“协作增益”——与单 Agent 在同一测试集上的对比。如果增益为负，说明拆分方式或编排拓扑本身有问题，此时增加 Agent 数量只会放大成本。

七、小结

多智能体的核心不是让更多模型同时说话，而是用工程手段约束协作边界：交付物驱动拆分、优先中心化编排、消息最小化、状态显式化、失败可重试、过程可观测。把这些基础打牢之后，再讨论自治与涌现，才不会陷入“看起来很热闹、实际不可用”的困境。