当单智能体难以应对复杂业务场景，多智能体协同已成为 AI 应用的新方向！这篇文章从行业范式转变切入，用一个真实商家智能助手案例，把多智能体的核心逻辑讲透 。
本文目录：
过去三年间，技术范式、产品范式和商业模式都发生了关键转变。
一个是技术范式的转移。过去以“预训练+SFT（监督微调）”为主，强调高质量数据标注与人工指令优化，让模型学习并模仿人类提供的标准答案。而现在，新范式开始转向“预训练+RL（强化学习）”的闭环方式，基于预训练构建的模型世界观为其注入价值观和方法论，通过人类反馈或自动化的奖励信号来实现自我优化。
一个是产品范式的切换。AI应用从早期的对话交互，转向具备主动执行力和上下文记忆的Agent（智能体）。过去产品形态的核心是问答与聊天，用户输入提示，模型生成文本，价值点在于信息的组织与呈现。但现在以及更长远的未来，产品形态的核心是感知-决策-执行，价值点不再局限于说了什么，而是做了什么。 Agent(智能体)成了AI行业新的叙事主体。
一个是商业模式的转变。过去很多AI企业的商业模式以API服务计费为主，通过API打造生态，拓展模型能力的使用边界。现在越来越多的模型厂商会直接下场做“一方产品”，一方面便于测试与验证底层模型的通用性，一方面能直接掌握用户与数据反馈，打造品牌与商业闭环，进而增强生态议价权，比如 ChatGPT Plus、Claude Pro、Kimi Pro 等订阅业务都能直接带来现金流。
而这些变化的背后，都离不开一个核心问题：单模型性能的边际提升正在快速递减，单一模型的性能天花板开始显现。与之对应的是，把模型用好用巧，在AI系统工程架构上的创新，尤其是基于大模型建构的智能体应用，成了新的市场焦点。
AI 智能体是一个以语言模型为“大脑”，通过“规划”来拆解目标，利用“记忆”来保存经验，借助“工具”来突破边界，并通过“行动”来影响环境的自主任务执行系统。
AI 智能体的基本运作原理是：目标——>观察——>行动，行动会影响环境，继而产生新的观察。循环往复，直到达成目标。
基于上述核心循环，可以将AI Agent用如下公式表示：
AI Agent=LM x（规划+记忆+工具+行动）。
「LM」，是智能体的大脑，可以是任何大小的小型/大型语言模型，一般会根据特定agent架构的需求进行微调，具备强大的语言理解、生成、逻辑推理和知识库能力；
「规划」，是智能体的策略制定能力。本质是将复杂目标分解成子目标，将复杂任务分解成一系列可执行的子任务或步骤；
「记忆」，一般分为短期记忆和长期记忆，是智能体的经验储存库。短期记忆，适用于当前对话的上下文学习，也特指工作记忆或上下文窗口，能保证智能体进行连贯的对话，一般受限于模型的上下文窗口，对话一旦超出该长度，最早的信息就会被挤出去。长期记忆，通常是一个外部的、可存储和检索的数据库，用于存储跨不同对话的关键信息，能让智能体了解你、记住你的偏好并积累经验。在后续的任何一次对话中，系统可以通过RAG（检索增强）从中搜索与当前问题相关的记忆，并将其作为上下文的一部分注入给模型；
「工具」，是能力边界和行动范围的扩展，是agent的手脚。任何可以被定义接口、能被调用的能力，都可以被视为“工具”。而使用工具=调用函数（function calling），这就要求开发者搭建桥梁，将工具指令转化为实际的函数调用。比如，通过联网搜索和数据库查询，Agent能获取实时与专有信息，打破模型固有的知识截止限制；再比如，Agent可以通过API调用操作各类软件，从发送邮件、更新CRM，到在飞书中发布消息，真正融入企业的工作流。
「行动」，是智能体执行任务的过程，它根据模型的推理和规划，具体调用工具或生成回应，并负责最终把结果以语言/操作的形式输出给用户。
简言之，「规划」和「记忆」是认知层，「工具」和「行动」是执行层，认知层和执行层的闭环互动，构成了智能体自主应对复杂挑战的核心循环。
而当单个agent具备了强大的行动与规划能力后，产业的想象力便自然延伸到下个阶段——多智能体（Multi-Agent）系统。
的确，单agent可以很好地服务于目标明确、责任集中、决策流相对简单的任务，架构部署简单，无需处理智能体间的通信协议，且决策更高效，响应延迟低。但结合前文提到的公式，单智能体的能力受限于核心大脑（主模型）的知识，即便你在认知层和执行层有充分的支持，核心模型的任何错误都会直接导致任务失败。且即使你可以调用多个工具，你核心的规划和推理过程是串行的，很难并行处理多个需要深度思考的子任务。
而通过有效的协同机制，构建多智能体系统，让多个具备不同能力的小模型或专有模型分工合作，往往能以更低的成本、更高的鲁棒性，解决那些远超单体模型能力范围的复杂问题。
顾名思义，多智能体是由多个具备自主性的智能体组成的系统，智能体之间通过特定的通信机制进行交互，彼此可能是协作、竞争或是混合的关系，最终完成各自或共同的目标。
比如，在工业制造领域，多机器人团队能协同完成装配、搬运和检测任务，每个机器人都作为一个智能体独立执行任务，再与其他机器人协同合作，确保生产线的高效运行。
再比如，在软件开发中，AI智能体们可以组成一个集项目经理、架构师、程序员和测试员于一体的数字员工团队，自动化完成从需求到代码的生产流程。
可见，针对高度专业化且需要不同底层模型（独立意志）的领域，多智能体能从多角度分析问题，由不同智能体并行执行不同的子任务。尤其是在垂直行业领域里，多智能体也成了很多公司尝试的方向。
注：区分单智能体和多智能体系统的根本标准，不在于模型/组件的数量，而在于决策权的分布。
单智能体拥有一个单一且中心的决策核心，所有规划、推理和协调都是由这个自我去完成，其他组件（包括被调用的模型）都是被动的且没有自主性的工具/程序。
多智能体则是存在多个决策核心。即便是中心化调度的多智能架构，其下属的智能体也会保有最低限度的自主性，能根据自己的感知、状态和目标进行独立推理和决策。
与其做出更聪明的模型，不如让模型们协作，这种范式的转变不仅是技术架构的升级，更是思维方式的转变。
先说一个伪多智能体的架构。
表面上模拟了多角色协作，但底层决策权完全集中于一个单一逻辑实体（一般是主LLM）。即：整个系统只有一个真正的大脑，所有的规划、路由和最终决策都由这个大脑完成。
而所谓的中心化调度，其实是基于条件的内部函数调用或提示词路由，系统中的其他智能体本身没有独立的目标和持续的记忆。每次被调用时，这些智能体会被赋予一个特定的角色提示词，处理一段输入，生成输出，然后状态消失。且智能体之间不能直接通信，所有信息都必须通过中央主控智能体中转。
这种系统本质上还是单智能体的内核，并不是多智能体架构。
与之一线之隔的是多智能体架构中的轻量级的中央调度模式。中央调度模式的多智能体架构同样不允许专家智能体之间直接通信，通常会由一个中央控制器（Supervisor/Controller）接收请求→分派到若干专家智能体→收集并整合信息输出。
这条分界线，就是决策自主性的边界划分。
打个比方，伪多智能体架构像是开启了「编剧模式」，通过复杂的、动态的提示词工程技巧给专家智能体设定角色，所有专家智能体的智慧，都受制于同一个主模型的知识和推理模式；而中央调度的多智能体架构是一种「邮差模式」，由controller/Supervisor中央调度器负责意图识别、分配任务和消息路由，再由每个专家智能体基于自己的大脑处理接收到的信息并生成响应。
该模式的多智能体架构适用于业务线清晰、需强监管的企业级场景（IT客服、财务助手）等，但随着专家智能体种类和任务复杂度的增加，controller需要编排的任务策略和路由规则会愈加复杂。此外，如果controller本身是LLM的架构，那么它对于每个用户请求进行的任务规划推理，都会产生显著的延迟和API成本。且在高并发场景下，controller本身会成为吞吐量的上限。
基于上述背景，滋生了另一种多智能体架构——分层与模块化调度。无独有偶，该架构依然存在一个中央调度器，但只负责粗粒度的任务分解，再将子任务交给专家智能体进行更细粒度的分配。姑且称之为「CEO模式」吧。
第一层是CEO，负责设定战略目标，将宏大目标分解成几个战略性的子目标，再决定将这些子目标分配给哪个部门，并设定好各部门之间的分工边界；
第二层是部门总监，负责一个特定的领域，在接收战略子目标后将其细化成具体可执行的工作界面，再交由下级执行；
第三层是一线工程师，也就是直接执行具体任务的对象。ta可以调用自身专业领域的工具和能力完成任务，再将任务执行结果返回给上层。
严格意义上来说，这种分层架构也同样受中心调度器的控制，但相比前者，在解决复杂任务编排，需要长链决策和多步骤执行的业务中，会更有优势。
除此之外，市面上也有一些去中心化的多智能体架构，比如网状结构，专家agent 之间允许点对点通信和多向协作，不依赖中央决策点。还有一些无中心的架构，比如群体结构，多个 agent以自治/协作方式运行，系统中的整体行为呈现出“涌现特性”，即：通过很多弱规则实现agent 的局部交互，以达成全局目标，也因此更容易失控。
多智能体架构在不同维度上的评估，可以参考下表。更多细节可以自行搜索学习，在此不再赘述。
五花八门的架构和命名不是关键，记不住也没关系。一个更符合现状的论断是，对于大多数已落地的、解决明确领域问题的AI应用，轻量级的中央调度架构是目前使用最广泛的架构，即：
一个中央调度器（可能是一个轻量级模型+规则引擎，或是一个高效的controller）负责理解意图、规划任务并路由到专家智能体去完成任务。该架构在复杂任务的处理和开发难度&成本之间取得了平衡。
下文我们以中央调度的多智能体架构为主，结合案例说明实际的规划工作。
前文已明确了轻量化中央调度的架构，以及中央调度器的能力要求，那么与之紧密协作的另一个角色——专家agent，要如何定义和区分？
定义任何一款产品的功能之前，都要先找准产品的服务目标和场景。
以某行业的商家智能助手为例，在没有AI赋能前，你的商户日常高频咨询的是什么问题？
如果你发现，咨询的问题主要来自专业程度极高的某个领域，那么按业务领域划分为不同的业务专家智能体（比如营销、订单、库存等）更合适。尤其是，按照公司运营的关键业务领域搭建agent，能和现有的组织心智模型相匹配，便于各agent内部的协作。
如果商户日常的咨询已经是高度碎片化了，甚至有大量问询是跨业务交叉讨论的，那么你的目标优先是打造一个能应对前台80%碎片化问询的“全能型前台员工”，以agent的能力划分专家智能体的边界更有把握。一开始就按业务域划分，可能会容易陷入“答非所问”或“能力覆盖不全”的被动局面。
比如，你识别到商户的所有query基本绕不开「查询——>诊断——>操作」的能力范畴，那么你完全可以由中央调度器识别意图后判断其核心意图是哪一项，再路由给对应的专家智能体。
1）「查询」：核心是 “精准” ，目标是快速、准确地找到用户问题的答案。支持RAG检索静态知识库，也支持通过function call查询商户的动态个性化数据，但不做过多的分析和扩展；
2）「诊断」：核心是 “洞察” ，目标是提供诊断结论和建议。可以利用查询Agent的结果或直接调用数据查询能力作为输入，优先覆盖核心经营业绩诊断、流量与转化漏斗诊断、价格与收益优化、客源与竞争诊断、运营与服务质量诊断等，通过分析、推理、对比得出诊断建议。
3）「操作」：核心是 “执行” ，目标是准确、安全地完成用户指令，在执行前应有明确的确认机制（尤其是高风险操作），优先覆盖商户最高频的操作行为，比如库存管理、订单管理、信息维护等操作。
综上，你可以按用户意图所涉及的「能力」划分专家agent，包括查询agent，诊断agent，操作agent。在轻量化中心调度的架构下，由controller作为中心调度器，负责识别意图并编排任务，路由到对应专家智能体后，由对应智能体进一步细化为具体的、可执行的计划并完成任务。
注意，上述各专家智能体的能力并不单独存在，比如RAG、function calling等能力会下沉为所有专家agent都可直接调用的通用能力层，避免各专家agent重复建设，或是因为要强依赖某一个专家agent的知识检索/数据查询导致系统的延迟。
但不可否认，纯能力划分必然会缺乏业务深度。为解决这个问题，短期内你完全可以为每个专家智能体注入业务的上下文。
1）在知识层面：既然是垂直行业的智能体，外挂业务知识库，通过RAG检索行业/平台相关知识是必须的，避免大模型直接生成内容时泛泛而谈。相反，以RAG为基石，用大模型提升其智能，是垂直领域AI应用时最常用且有效的方法。关于这一点，详情可查阅AI系列（三）
2）在工具层面：前文提到，目前使用工具=调用函数（function calling），你需要理出商户在平台侧的相关数据API或插件，便于调用函数时返回实时真实的业务数据；
3）在提示词层面：如果有一些涉及到内容生成的场景，可以在提示词中明确其角色是“xx行业的xx文案助手”，并要求其风格必须符合该行业的品牌调性，也会让智能助手的答复更贴商户诉求。
此外，随着时间的推移，长远来看，如果后续某专家智能体在特定业务领域复杂过重或效果不佳时，可以再从中孵化出该能力智能体下的业务域智能体。先通才，再专才，最终演进成一个混合架构。
接着上述的案例，我们已经按用户意图所涉及的「能力」划分专家agent，由controller负责识别意图并编排任务，路由到对应专家智能体进一步细化为具体的、可执行的计划并完成任务。
那么，具体的路由规则怎么定？
这里有三个关键点：
1）主意图判断：在复合意图中，controller 必须能准确识别用户的核心目标（查询or诊断or操作）；
2）始终坚持单agent闭环优先，只有当任务超出单agent能力边界时，才启动多agent编排，并且流程链路尽量简化；
3）当意图均未命中时，再由controller调用大模型对用户意图进行澄清，或是直接生成内容。
注意，每个专家agent都有各自的主目标，即：
其中，诊断agent和操作agent也同样具备查询能力，查询是所有agent的前提。
具体路由规则如下图所示：
举个例子，商户query：“结合平台规则，给出商品价格的调整建议”。
商家智能助手执行逻辑：
controller判断商户意图为【查询+诊断】，查询仅为前提，核心是给出诊断，因为诊断agent本身含查询功能，可以直接路由给诊断agent闭环完成。于是：
诊断agent首先通过RAG获取平台规则知识，通过function calling获取当前商品的价格；
诊断agent接受数据后进行下一步的诊断，给出价格的调整建议，返回给controller再给到前端会话层进行展示。
再举个复合型的例子，用户query：“我的商品最近一周的预订量下降了不少，但同期平台的流量是上涨的。帮我查一下是怎么回事，如果是价格问题，就帮我参考竞对调整一下价格。”
还记得吗，谁能直接完成任务，就由谁直接调用公共能力。Controller只负责初始路由和最终汇总，不干涉过程中的数据传递。
于是，智能助手执行逻辑：
1）controller识别用户的复合意图为「查询+诊断+操作」意图，核心意图是诊断，并附带一个条件性操作。于是初始路由到诊断agent；
2）诊断agent：查询自身业绩数据、竞争圈价格数据，再调用公共function calling服务，获取预订量、流量和竞品价格；
3）诊断agent：基于数据进行分析推理，得出价格调整建议再返回给controller；
4）controller接收到诊断建议后识别到是个价格问题，再将操作建议作为明确指令二次路由给操作agent；
5）操作agent：根据策略执行调价操作。执行完毕后由controller整合信息并返回前端进行结果展示。
上述的例子不一定适用于你当下的业务情况，但思考路由规则的过程，期待对你有所帮助。
恭喜你看到这了。任何AI产品都是概率型产品，产品的竞争力主要依托于模型的性能和高质量的数据飞轮。你最大的挑战不是架构设计，而是接受任何架构带来的不确定结果，为此你只能通过建立一套完善的机制来管理概率、处理错误，并在这个过程中持续学习和进化。
如何结合大模型本身的能力边界，适用场景和工程手段，整合成一个解决方案，让系统相对稳定地输出，是个需要持续钻研的命题。
今天我主要跟你分享了最近在多智能体架构上的思考，但我并不推荐你一上来就想解决所有问题的一个万能智能体，单智能体能满足的话自然是最好不过。
在模型的能力范围之内，选一个刚需、可控又能衡量ROI的业务场景，先把这个点打穿；然后再靠一些工程的手段，把大模型变得尽量的稳定，比如加入一些规则引擎套用模板，RAG，知识图谱，function calling 以及审核和兜底机制，确保大模型的输出是可控的。
最后是一些闭环反馈的机制，智能体上线后，不是模型本身的数据可贵，而是用户使用后真实的反馈数据值得关注。你需要基于这些数据不断微调和优化，形成一个可持续迭代的闭环系统。把机制跑起来，系统才能变得越来越准，越来越聪明。
话说回来，今天我们虽然还在聊基于大模型能力的产品化智能体，但以Deep Research为代表的智能体化的大模型，内置自主思考、规划、反思、决策、工具调用与执行能力的大模型，也逐渐成为下一代 AI 助手发展方向的代表。
模型即产品，模型即服务。也许到时候还有一些新的发现呢，可以拭目以待。
本文由人人都是产品经理作者【健壮的大姐姐】，微信公众号：【健壮的大姐姐】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。