多Agent系统设计原则有哪些?

这道题我觉得本质上是在问，当系统里不止一个[[智能体]]的时候，怎么让它们各司其职又拧成一股绳，说白了就是 分而治之加协同治理。

先说角色划分。每个Agent职责必须单一，比如有的专门做规划，有的做执行，有的做验证，还有的做反思。这就像团队里产品、开发、测试各管一摊，不能一个人又写代码又测自己的bug。实现上我习惯用[[System Prompt]]把行为固化下来，避免能力重叠。

再一个就是协作模式。常见的有协作式、层次式、竞争式、市场式，但真正落地很少只用一种。举个例子，在电商客服退款场景里，用户发起退款，我会用层次式：一个调度Agent拆任务，然后分给执行Agent去查订单、算金额、审凭证，这些执行Agent之间又是协作式，共享上下文。如果遇到争议，再让两个Agent竞争出不同方案，调度Agent择优。所以 模式是混搭的，关键看业务流。

通信这块，我常用两种：消息协议和黑板架构。消息协议就是标准化的JSON-RPC，带上sender、receiver、task_id这些字段，适合实时同步调用。黑板架构更像公共白板，Agent们自己上去写、异步读，适合解耦。比如在订单异常处理里，多个Agent可以同时往黑板上写审核意见，最后由仲裁Agent汇总。这里有个坑：如果黑板不加版本控制，很容易读到过期信息导致决策不一致，所以我上线会特别关注 共享内存的读写锁和版本号。

任务分解我倾向用[[ReAct]]加Reflection，Agent在执行中不断自我评估，失败了要么重规划，要么上报。这样能动态调整，不用一开始就把所有子任务定死。

最后是容错和一致性。容错方面，我会给每个Agent设超时熔断，如果某个Agent卡死，调度Agent直接降级到单Agent模式兜底，或者预留人工介入节点。一致性更难，关键决策比如退款金额，我会让验证Agent复核，或者多Agent投票。但投票也有代价，延迟会变高，所以 只在高风险节点用，其他节点信任单个Agent的结果。

其实还有一个方向我没展开，就是当Agent数量超过几十个时，整个系统的收敛性会变差，这时候光靠规则调度就不够了，可能需要引入[[Tree-of-Thoughts]]做搜索剪枝，或者用强化学习动态编排。这个我还在摸索，但我觉得是生产环境必须面对的挑战。

所以整体上，我更倾向于把多Agent设计看成 先合理拆分认知负载，再通过机制设计保证系统收敛到正确解。上线前我会重点压测容错路径，确保单个Agent挂掉不会拖垮全局。