上一篇单Agent架构演进提到，Agent的架构是为了解决LLM的不足，而LLM的不足主要在于以下三个方面：
- 基于Next-Token的预训练机制：由此倾向于自圆其说，并且越强的模型自圆其说的能力越强，缺乏反思能力和机制；由此需要强化反思，产生Reflection模式；
- 概率模型：由此在精度要求高的计算任务上表现差；由此产生CodeAgent模式；
- 扁平化token序列的状态表示：由此引起lost-in-middle、注意力倾斜等问题，大模型的状态本身是没有任何结构化的，完全依赖注意力机制提取；Plan-And-Execute、ReWOO都是在尝试解决这个问题。
上面的三个不足，主要瞄准的是任务的完成准确性，在实际应用中，除了准确性之外，还有一个重要的指标即响应时间，响应时间过长显然会大幅降低系统的用户友好性，在单Agent模式中，LLMCompiler用于解决此问题。
1 为什么需要多Agent架构
当需要完成的任务复杂度达到一定程度时，融合上一篇提到的各类单Agent模式的各种思路，虽然可以比较好的解决问题，但是复杂度会显著上升，而这种复杂度的良好治理，对于扩展Agent系统的功能边界（例如支持新的智能能力）、定位和解决问题（例如优化某一类用户任务的表现）会带来明显的益处。
治理的方式，思路一如既往的是分而治之的思路，类似于服务化于互联网系统，从运行上（而非仅仅逻辑上）将单个Agent按照职能进行拆分，多个Agent之间基于明确的Schema进行通信，即多Agent架构。
从另外一个角度，多Agent也类似于人类生产系统的组织，一个任务复杂到单个个体无法高效完成，就使用组织的方式来完成，组织内部基于职能进行拆分，承担各个职能的人专注于提升自身在所负责职能上的能力，各个职能的人之间通过约定的规则进行交互（例如产品经理产出原型和PRD提交给开发和测试，而开发和测试则一定程度上可以并行开展工作）。
多Agent架构除了能够比较好治理Agent系统的复杂性，以更小人类心智代价去降低LLM前述3个不足的影响，并自然而然的支持Agent级别的并行执行而降低任务的响应时间外，考虑LLM的类人智能特性和其上下文有效窗口（实际上只有LLM最大上下文窗口的部分大小）的有限性，因为各个Agent仅需关注自身的能力，并不需要整个任务的完整上下文传递，因此LLM正确理解的概率上升因而正确推理的概率上升，也十分有利于整体准确度的提升。
一句话总结，按照我的理解，多Agent的核心益处，并非在于提供新的问题域方法解决LLM的不足，而是提供了一个新的解决域Agent构建方式，通过统一的方式（分工+通信规约）使得单Agent架构中各类解决LLM不足、降低用户响应时间等各类特性的实现方式变得统一而自然，由此显著降低Agent系统的解决方案复杂度，进而间接的提升Agent系统的性能表现。
2 多Agent架构拆分
多Agent架构的分法不少。
例如Google 2025年12月的文章“Developer’s guide to multi-agent patterns in ADK”中，分为Sequential Pipeline Pattern（顺序流水线模式）、Coordinator/Dispatcher Pattern（协调者/调度者模式）、Parallel Fan-Out/Gather Pattern（并行扇入扇出模式）、Hierarchical decomposition（层次模式）、Generator and critic（生成器与评论者模式）、Iterative refinement（逐步精细化模式）、Human-in-the-loop（人在回路中模式）、Composite patterns（组合模式）8大类。
而微软在2025年9月的文章“Build Multi‑Agent AI Systems with Microsoft”中则主要提出“Orchestration via a Lead Agent”，这个与Google的层次模式比较类似。
Anthropic在2024年12月的文章“Building effective agents”中则提出Workflow: Prompt chaining（工作流：提示词链）、Workflow: Routing（工作流：路由者）、Workflow: Parallelization(工作流: 并行处理)、Workflow: Orchestrator-workers（工作流: 协调器与执行者）、Workflow: Evaluator-optimizer（工作流：评估器-优化器）、以及Agents（实际上就是单Agent架构中的ReAct模式）。
可以看到，各家的分类方法差别不小，这一方面固然是因为各家有各自的商业目的，另一方面，也跟当前多Agent其实还处于较早期阶段有一定关系。架构模式，其实关键在于Agent的职责分工，因此可以简化为两大类。其一为存在职责主从关系的，其二为各个Agent职责对等的。
存在主从关系的多Agent架构模式
由主Agent负责拆分任务、分派任务、收集任务结果产生最终结果，而各个从Agent则按照职责划分各自负责某个领域内的单个或多个子任务的执行。Google的Coordinator/Dispatcher Pattern等价于Anthropic的Wokrflow: Routing，其中Coordinator Agent（或者Routing）是主，其他的具体干活的不定数量的Agent是从；Parallel Fan-Out/Gather Pattern中的ParallelAgent和Synthesizer分别承担了主Agent的拆分任务并分派任务、收集结果生成最终结果的职责，各个与业务领域相关的则为从Agent，Hierarchical decomposition则是一个多层的主从模式。Orchestrator-workers中Orchestrator是主，workers是从。
存在主从关系的多Agent架构，模拟的是人类最常见的层级+专业分工的组织方式，只需要把Agent视为一个个独立的人或者由人组成的小团队（因为Agent也允许层级组织，参考google的层级模式）。
各个Agent对等的架构模式
我感觉这个属于想法酷，但是实际应用到生产系统ROI太低的方式，太过于依赖去中心化条件下的共识形成了。即便要发挥多个Agent独立思考的优势，多运行几个不同风格、角色定义的Agent再使用一个协调者来汇总，显然具有更好的可控性。
工作流多Agent架构模式
而像Generator and critic、Iterative refinement、Human-in-the-loop则其实已经变成Workflow，即事先定义好任务的执行路径的方式了。
这是看起来最不高科技的方式，但是事实上也是可靠性最高、成本最低的方式。
3 多Agent架构的代价
架构其实是个tradeoff的活儿，多Agent架构解决了一批问题，也带来的新的问题，最大的痛点就是通信开销与状态不一致，例如通信Schema如何定义、变化时如何处理、失败重试语义幂等等，这些值得另外写一篇了。
