multi-agent ai-agents architecture llm agent-patterns

四种多智能体系统架构的比较：子智能体、技能、任务交接、路由器。

对四种用于AI智能体的核心多智能体系统架构的实用对比：每种架构的成本、适用场景，以及如何选择以避免功能过剩。

发布者：REACTAPP.TOP加入本站 2026年10月28日阅读约 7 分钟1611 词

来源: I’ve Been Building AI Agents Wrong. Here’s What I Learned About Multi-Agent Architectures.

这是个常见的故事：一个团队构建了一个复杂的代理系统，其中包含多个模型、错综复杂的路由机制以及能够生成其他代理的代理，结果却发现，一个在周末仓促搭建的单代理版本在延迟、可调试性以及所有其他关键指标上都更胜一筹。要摆脱这一困境，首先就要明白几乎所有成熟的多代理系统都是基于四种模式构建的，并且要清楚每种模式会带来什么代价以及能带来什么好处。

真的需要多个代理吗？

通常不需要。由于宣传效应以及满是箭头的图表所带来的吸引力，很多人会在第一周就选择使用多代理框架，但这样的结果往往是系统脆弱且成本高昂，而使用一个经过恰当配置的单代理往往能取得更好的效果。

有两种情况确实需要额外的机制。其一便是上下文窗口的限制。你无法将法律分析、医疗编码、财务建模和情感分析全部放入同一个提示词中并期望得到连贯的输出，因为过大的上下文量会降低质量并延缓响应速度。其二则是团队职责划分问题。当一个团队负责库存管理，另一个团队负责订单处理时，若让他们使用同一个统一的提示词，就容易引发冲突、导致系统故障，还会让人不清楚各负责哪些工作。面对这两种问题时，以下的模式便成了实用的解决方案，而非仅仅为了架构而存在的架构。

子代理：幕僚长

想象这样一位参谋长：他从不亲自处理工作，但却清楚该找谁来处理。一名主要监督代理负责掌控全局。当需要获取CRM数据、起草邮件或进行计算时，它会像使用工具一样调用相应的专业子代理，获取结果后再将所有内容整合起来。

其优势在于整洁性。每个子代理都在独立的、范围有限的上下文中工作，因此不同领域之间不会相互干扰：负责法律事务的子代理对库存情况一无所知。当各个领域规模庞大且彼此独立时，这种隔离机制能发挥巨大作用，因为每个专家都能专注于深入的任务，而无需与无关信息争夺资源。此外它还便于测试，因为每个子代理都可以单独进行评估。不过代价是每次请求都需要额外调用模型一次，因为结果需要通过监督代理传回，所以三个子代理意味着要多进行三次往返传输。对延迟敏感的应用程序很快就能感受到这种影响。

它适用于将工作分配给领域专家的研究平台、能够同时协调日历、邮件和任务的个人助理，以及由主处理员同步向多个临床子处理员派发任务的医疗分诊系统。有研究显示，采用大型模型作为主模型、小型模型作为子模型的架构，在内部测试中比单独使用大型模型的效果高出90%以上。当任务需要时，可在不同的上下文窗口中进行并行推理，这具有很强的实用性。

技能：一个处理员，多种职能

从技术层面讲，这仍然属于单一智能体，尽管它的行为方式并不像传统智能体。它开始每段对话时只知道可用技能的名称和简短描述，当出现相关内容时才会加载该技能的完整上下文。全科医生也是类似的工作方式——遇到特定病症时才会调出相应的专业诊疗方案，而不会在每次问诊时都记住所有方案。

实际的好处在于独立性。Python团队负责维护Python技能，数据库团队负责维护SQL技能，两者都是独立的模块，无需围绕统一的提示词进行协调。对于分布式工程组织而言，这无疑是个巨大的便利。不过缺点是上下文积累问题：对话持续的时间越长，加载的技能越多，上下文负担就越重，最终会在会话后期影响成本与质量。虽然可以控制，但这个问题确实存在。

这些技能适用于在前端、后端和基础设施模式之间切换的编程助手，适用于能改变写作风格的创意工具，也适用于能够根据客户实际问题调用专业知识的客服人员。

任务交接：接力赛

如果子代理代表并行分配，技能代表动态专业化，那么任务交接则表现为顺序推进，最接近人们处理复杂流程的方式。用户首先与代理A打交道。一旦有信息交流或满足某个条件，控制权就会移交给拥有自身系统提示、工具甚至性格特征的代理B，之后再移交给代理C。在整个过程中，所有讨论过的内容及做出的决定都会随每次交接一同传递。

状态变化由状态驱动。各个节点并非简单相互调用，而是会更新共享状态，而该状态决定了下一个谁处于活跃状态。实际上，这就是一种以节点作为状态的状态机。

这种结构非常适合多阶段的支持流程（先分诊、再诊断、最后解决），也需要在处理案件前进行冲突检查的法律事务流程，以及必须在确认购物车内容后才能开始支付的结账流程。人们常常忽略的一个权衡是：顺序处理意味着无法并行操作：如果必须同时查询三个知识库，那就得另寻他法。它只适用于那些B步骤确实必须等到A步骤完成后才能开始的 Workflow。状态管理也很困难，一旦交接链出现故障，调试并非易事，因此在决定采用这种方案之前，应预留更多时间用于追踪和构建可观测性工具。

路由器：空中交通管制员

从概念上讲，这很简单。前端有机制对每个传入的查询进行分类，然后将其转发给相应的专家。这些专家并行处理，最终的结果会被合并成一条回复。由于路由器不保存任何状态，因此每个请求都会被独立处理。

它的优势在于处理效率。一个涉及三个知识领域的查询会同时发送给这三个处理模块，总耗时大致等于最慢的那个处理时间，而非各时间之和。在企业知识库中，员工的查询可能涉及人力资源政策、信息技术安全规范以及财务合规要求；此时路由器会同时启动这三个处理模块并整合出一条答案，否则就需要发起三次查询，或者让一个处理模块同时承担三个领域的任务，这会导致其负担过重。

一个客观的限制是，无状态意味着没有内存存储。后续问题出现时不会留下任何先前信息的痕迹，这对对话型产品来说是个实际问题。常见的解决办法是将路由器封装在一个有状态的外部代理中，由该代理来保存历史记录，但这样会合并不同的模式并增加复杂性。这种方案适用于那些具有明显独立模块的高流量系统、需要同时调用多个知识源的场景，以及那些更重视单次请求一致性而非对话连贯性的情况。

选择方案

其实不必如此纠结。

多个独立的领域，实现干净的并行执行，并通过集中控制点管理子代理。
由不同团队负责、具备多种专业能力的单个代理，用于调用相应技能。
本质上为顺序式的流程，带有前置条件且状态会持续传递，适用于任务交接场景。

不同领域存在大量查询任务，需要并行处理且无需对话历史记录，这种情况下应使用路由器。

另一个需要考虑的因素是性能。具有状态保持功能的模式、技能和任务交接机制能够通过记住之前的上下文，使重复请求时的模型调用次数减少约40%到50%。而子代理和路由器没有状态保持功能，每次处理都需要付出相同的成本，但优势在于能够实现良好的上下文隔离，这对于处理大规模领域的并行任务非常重要。

先控制再处理

构建多智能体系统并非为了显得高端复杂，而是为了解决你实际面临的问题。合理的开发路径是先从一个拥有优质提示词的智能体开始，再引入工具，只有在遇到诸如上下文溢出、团队职责冲突，或是单智能体无法满足的并行处理需求等具体障碍时，才考虑采用多智能体架构。那些拥有最佳系统的团队，往往是那些最能抵制复杂性、并能解释每项组件存在理由的团队。

下一步是什么

可以将这四种模式视为当前多智能体设计的基本语法，新的相关概念也在不断涌现。那些能够跨会话保留记忆，并能连接个人文件与应用程序的持久化本地智能体，正从研究阶段走向实际产品应用。据报道，模型上下文协议在2026年初的安装量已达9700万次，它正在成为让不同供应商的智能体无需定制集成即可相互通信的基础设施。能够动态生成新智能体、根据任务复杂度调整自身工作规模的智能体网络也开始出现。子智能体、技能、任务交接机制以及路由器是支撑这一切的基础，因此现在掌握这些知识就能获得先机。一个决策的经验法则是：先写下具体的问题，确定能解决该问题的模式，然后再绘制图表。从简单开始，诚实地说明自己的需求，等到真正需要多智能体系统时，你就知道该选择哪条路径了。