“多智能体系统 101”这个标题，看起来像一门入门课的名字，实际上它也确实值得被当成一门课来对待。这几年AI圈最热的话题，不再只是一个巨大的模型单打独斗，而是一群能感知、会决策、有目标的“智能体”凑在一起，通过分工、协商、竞争甚至博弈，把一个单体很难完成的复杂任务拆解并解决掉。这就是多智能体系统（Multi-Agent System）。这篇文章写给刚接触这个概念的人：不论你是AI工程师、产品经理，还是单纯对智能协作感兴趣，读完之后你应该能理解多智能体系统解决什么问题、由哪些核心模块组成、怎么设计一个最小可用的多智能体Demo。
1. 多智能体系统到底是什么
1.1 从“一个聪明脑袋”到“一群协作个体”
先讲单体智能。一个问答机器人，输入一个问题，模型生成回答，完了。单体智能系统的特点是单一决策中心，所有信息流入同一个模型，所有决策由一个大脑完成。好处是简单、可控、保持一致。坏处是：当任务变复杂，比如“要产出一份行业调研报告，调研、分析、写作、排版一次做完”时，把这么多步骤压进一个Prompt里，模型会顾此失彼，要么中间环节输出粗糙，要么上下文太长导致后面意识模糊。
多智能体系统换了一种哲学：把一个大任务，分配给多个有不同角色、不同目标、不同能力边界的智能体。每个智能体只负责自己擅长的一小块，通过消息或共享环境沟通，最终产出比单体更稳定、更可控、更可解释的结果。类比生活：一个人开小饭馆，从买菜、做菜、收银、洗碗全自己干，什么都行但什么都累；而一个后厨团队里，切菜的不做热菜，热菜的不管收银，各自专注，配合好了效率和质量都远高于单干。
这个类比里其实透露出多智能体系统的三个核心特征：自主性（每个智能体可以独立决策）、交互性（智能体之间可以交换信息）、涌现性（整体能力超过个体能力简单相加）。这三个词是理解后面所有设计选择的基础。
1.2 多智能体系统和“工作流”“编排”的边界
现在很多说法把大模型应用里“一连串Prompt串起来”也叫Agent、多智能体。这里需要做点区分，否则容易学偏。
单Agent的ReAct模式（思考-行动-观察循环）是一个智能体自己带工具、自己完成任务，本质还是单人作战。多智能体系统至少包含两个以上有独立决策单元的智能体，它们之间不是简单的串联调用，而是存在真实的协作关系：A的输出可能成为B的输入，B可能反过来质疑A，甚至A和B对一个问题持有不同立场，通过辩论收敛结果。
至于“工作流”（Workflow），更准确地说是一种预先写好的流水线，每一步做什么是编译期就确定的，没有太多动态决策空间。多智能体系统更强调运行时自主决策：谁执行下一步、用什么策略做，不是完全固定死的。当然，实际落地时会混合使用——很多系统里，外层是工作流，某个环节内部才是多个智能体动态协作。初学者先搞清楚这个边界，后面看框架文档不会晕。
1.3 多智能体系统到底解决了什么问题
说白了，多智能体系统最擅长的是三类问题：
第一类是高度解耦的复杂任务。一个任务天然能拆成多个相对独立的子任务，比如软件项目的需求分析、编码、测试，内容是分工明确的多个环节，智能体各管一段。
第二类是需要多视角权衡的任务。比如判断一份合同有没有风险，可以让一个智能体扮演法务、一个扮演财务、一个扮演业务方，从不同视角审查，交叉找出问题。
第三类是环境持续变化、需要响应式决策的任务。比如在模拟城市里调度交通信号灯，每个路口一个智能体，根据周边实时车流调整配时，这比一个中央大脑统一计算要快得多、健壮得多。
反过来说，如果任务本身简单、单次Prompt就能搞定，强行上多智能体只会让系统更慢、更贵、更难调试。这一点我后面会反复提到：多智能体是有成本的技术，不该用的时候别用。
2. 设计一个多智能体系统前，必须想清楚的几件事
2.1 角色定义：先问“谁来做”，再问“怎么做”
一个多智能体系统的质量，很大程度上在角色定义阶段就定型了。
角色定义不是简单给个名字叫“市场分析师”，而是明确四个东西：职责边界、输入格式、输出形式、可用工具。职责边界解决“什么归你管”，否则两个智能体会抢活；输入输出格式是智能体间协作的接口契约，我见过太多多智能体项目早期死得很惨，就是因为角色输出是自由文本，下游智能体根本没办法稳定解析。
实操上，我建议先画一张“角色-职责-输入-输出”四列表格，把每个智能体的接口敲定，再动手写代码。这比先写代码再补文档高效得多。
还有一个关键点：角色数量不要贪多。我个人的经验是，从两到三个角色开始，跑通闭环之后再加角色。一个系统里角色超过七个，通信复杂度会以平方级别上升，很快失控。
2.2 通信机制：所有人都说话，等于没人说话
智能体之间怎么通信，是整个设计中最容易想当然的一部分。
常见的通信模式大致有三类：
一是直连消息，A直接把消息发给B，适合明确上下游关系，比如调研智能体把结果发给执笔智能体。
二是共享黑板（blackboard）模式，大家在一个公共区读写信息。适合多角色并行协作，比如产品评审场景，产品、设计、开发智能体各自把自己的观点贴到同一个看板上，互相补充。这种模式的好处是解耦，短板是黑板内容混乱后难以收拾，最好配合结构化的数据格式。
三是消息总线/事件流模式，每个智能体订阅自己关心的主题，类似于发布-订阅系统。适合规模较大、异步性强的场景。
初学者最容易犯的错误是：让所有智能体都能给所有智能体发消息。通信无约束，很快就会出现信息轰炸、上下文爆炸。我的建议是：先明确通信拓扑，画一张简单的关系图，谁和谁必须通信、谁和谁禁止通信，再实现。好的通信设计应该像一支足球队：边路球员不需要直接联系门将，球通过明确路径传导。
2.3 任务分配：集中式、分布式还是市场机制
多智能体系统里，任务分配是决定系统行为风格的关键机制。
集中式：有一个“总指挥”智能体负责拆解任务、分配给其他智能体、收集结果。好处是全局可控、顺序清晰，适合流程稳定的场景。坏处是总指挥可能成为瓶颈，一旦它出问题整个系统停摆。
分布式：没有总指挥，各个智能体根据自己对全局的理解认领任务。好处是鲁棒性好、扩展性高，坏处是行为不可预知，可能会出现大家一起做同一件事或都没人做某件事的情况。
市场化机制：任务被“发布”出来，智能体根据自身能力和当前负载出价（bidding），协调者择优分配。这是分布式与集中式之间的一种折中，在资源调度型场景很实用，比如计算任务分配。
入门建议：优先选集中式。它最容易调试、最好解释、也最容易在早期发现任务分解这个环节的问题。等你对动态环境有明确需求时，再研究分布式和市场机制，否则很容易被调度问题淹没。
2.4 环境与记忆：智能体在哪里干活，记不记得之前的事
很多多智能体教学把重点放在智能体内部，却忽略了“环境”和“记忆”。
环境是多智能体活动的场所。它可以是一个模拟器（比如城市交通环境），也可以是一个共享工作区（同一个文档、同一个数据库）。环境决定了智能体能感知到什么、能改变什么。有的多智能体系统根本没有外部环境，智能体纯靠消息交换协作，这也是合法的，只是你需要明确这种设计。
记忆又分短期记忆和长期记忆。短期记忆一般指一个任务执行过程中保存的上下文，比如“我们正在讨论的新需求文档”；长期记忆指跨任务积累的经验、偏好、事实库，比如这个团队过去总结出的写作风格偏好。没有记忆的多智能体系统，每个智能体都像得了失忆症的病人，处理一次任务后一切清零，系统不会有任何能力增长。
设计记忆时建议用可查询的外部存储，而不是把所有历史都塞进Prompt。否则随着对话增长，模型注意力会被无关信息稀释，输出质量直线下滑。
3. 一个可直接上手的实操：三位写手的协作流水线
3.1 场景设定与角色拆解
我给的这份实操示例，不依赖任何特定厂商的API，核心是用一个极简的智能体骨架演示多智能体系统的协作逻辑。场景是：产出一篇“面向技术新手的智能体入门介绍文章”，要求有一定的知识密度和易读性，最终交付给一个真实读者阅读。
我拆了三个角色：
内容策划（规划者）：负责理解任务目标、拆解文章结构、确定每个章节的要点，产出写作大纲。
资料研究员（检索与总结者）：根据大纲中的每个章节，从内部知识库检索相关资料，完成要点整理和事实核对，输出结构化的参考资料卡。
撰稿人（写作者）：接收大纲和资料卡，逐章写出完整文章，确保语言流畅、衔接自然。
三个角色串成一个单向流水线：策划产生大纲，研究员补充资料，撰稿人写正文。为了演示多智能体最核心的协作价值，我还让策划在最后做一次“质量复核”，对照大纲检查正文有没漏掉关键点。这就形成了一个带反馈闭环的最小多智能体系统。
这里想强调一个设计细节：我没有一开始就加“审校智能体”“SEO优化智能体”“排版智能体”，而是先用三个角色跑通一条最短路径。系统能产出一个看得见摸得着的成果之后，再逐步加角色才有意义。否则你就是在一个没有地基的房子里砌墙。
3.2 用开源框架搭建还是手写骨架
现在确实有很多开源多智能体编排框架，它们把角色管理、消息传递、任务编排封装好，降低入门门槛。用框架的好处是启动快，坏处是很多框架自己还在快速演进，API不够稳定，你学到的东西可能几个月后就变了。
我个人的建议是：第一次跑通概念，用手写一个极简骨架；确认系统逻辑自己想清楚后，再根据需要迁移到框架上。原因很简单，手写骨架能逼你理解消息怎么传、角色怎么管理、循环怎么终止，这些是框架替你隐藏掉的复杂度。直接上框架，一旦出错，你会分不清是自己设计问题还是框架行为问题。
这份实操就用手写骨架，全代码大约几十行，足够跑通一个最小闭环。
3.3 核心代码与配置解析
我会用Python写一个非常精简的骨架。核心的LLM调用我抽象成一个generate函数，你可以替换成自己项目里实际使用的模型。
这里是我的骨架代码：
from dataclasses import dataclass, field from typing import Callable, List # 假设你有一个统一的模型调用后端 # def generate(user_prompt, system_prompt): return str @dataclass class Agent: name: str role_prompt: str # 角色系统提示词 generate: Callable[[str, str], str] = None outputs: List[str] = field(default_factory=list) def run(self, task: str) -> str: result = self.generate(self.role_prompt, task) self.outputs.append(result) return result # 多智能体编排：集中式流水线 + 反馈复核 def run_content_pipeline(task: str): planner = Agent(name="内容策划", role_prompt="你是内容策划，请输出结构清晰的文章大纲。") researcher = Agent(name="资料研究员", role_prompt="你负责检索资料、核对事实，输出结构化资料卡。") writer = Agent(name="撰稿人", role_prompt="你负责根据大纲和资料撰写流畅完整的正文。") outline = planner.run(f"任务：{task}。请给出大纲。") research = researcher.run(f"大纲：{outline}。请逐条补充资料。") draft = writer.run(f"大纲：{outline}。资料：{research}。请写完整正文。") # 审核环节：策划人复核 review = planner.run(f"大纲与正文都在下面，请核对是否漏掉关键点：大纲：{outline}，正文：{draft}") return draft, review这段代码虽然简陋，但它已经把多智能体系统的关键构件都体现出来了：
每个Agent是一个独立的决策单元，有自己的角色提示词，独立调用模型生成结果；
Agent之间通过返回值传递消息，形成明确的通信路径；
系统有一个集中的编排函数run_content_pipeline，负责决定调用顺序和消息路由；
末尾加入了一个复核步骤，让同一个“内容策划”智能体用更高维视角检查正文与大纲的偏差。这一步就是多智能体系统优于普通串联Prompt的关键差异化价值——你让一个Role以不同身份对同一成果做不同质量的审视，从而获得比一次性输出更可靠的交付物。
如果你的模型调用后端正则支持对话历史，只需要把role_prompt和task改成messages列表格式即可，逻辑不变。
3.4 跑通之后如何判断系统好坏
跑通是一个里程碑，但只证明“能跑”，不证明“好用”。我会用几个指标来评估一个多智能体系统：
任务完成率：最终产出是否符合最初任务目标，这是最硬性的指标。比如文章是否完整、有没有遗漏大纲里的章节。
协作有效率：消息在智能体之间流转了多少轮才完成。流转轮数越多，说明系统越啰嗦、低效，越需要精简通信。
角色一致性：每个智能体是否始终守在自己的职责边界内。如果研究员经常越权去改写文章结构，说明角色定义不够清晰，或系统提示词约束力不足。
错误传播链路：当最终结果出错时，你能否顺着消息链快速定位到底哪个智能体的输出引入了问题。一个设计良好的多智能体系统，每个环节产物都该能单独检验。
我习惯跑通后先做一次“故障演练”——故意在某个环节的输入里插入错误数据，看系统能不能发现、会不会被带偏。这个测试能快速暴露角色边界和审核机制的漏洞，比反复调Prompt效率高多了。
4. 跑起来之后才会踩到的坑：排查与心得
4.1 上下文污染与角色串台
多智能体系统最常见的翻车现场之一，就是角色串台：研究员开始写文章正文，撰稿人反过来给策划提修改建议，全员越权。
根因通常是两个。一是通信消息太自由，A的输出被直接甩给B，B拿到一堆和自己职责无关的信息，只好“全能化”地处理；二是角色提示词边界写得不够强硬，模型在长对话中逐渐遗忘自己的角色约束。
我建议的排查步骤：
先检查通信拓扑。是不是真有A必须给B发消息？如果只是“可能有用”，就砍掉。
再检查角色提示词。明确写“你的输出必须是对外提供的资料卡，不得包含全文撰写”比只写“你是研究员”有效得多。
最后检查上下文输入。给每个智能体的输入尽量精简，只给它完成任务最小集。输入里塞进整本书，它自然会忍不住什么都管。
4.2 死循环、任务空转与超时止损
多智能体系统天然有循环，比如“互相评审”的AB双方可能无限互相挑错，也可能长时间空转。
要设计好终止条件。终止条件有三种常见模式：
最大轮数：循环最多执行N轮，到达后强制终止并给出当前最优结果。
达成共识：通过检测两个连续结果是否一致或差异小于阈值，判定系统收敛。
超时/成本预算：设置了总调用次数或总时间预算，超出即降级输出。
三种模式我建议组合使用，尤其是“最大轮数+共识检测”。只靠共识检测可能欠收敛，只靠最大轮数又往往会在结果还没稳定时被硬切。多智能体系统上线后，永远要假设模型可能会在某个轮次失忆或突发奇想，止损机制就是你的安全网。
另外，日志要记得记录“每个智能体每次调用花费了多少时间、多少Token、输出了什么东西”。没有日志，你在系统出问题时会像没带手电筒走进黑隧道。
4.3 成本与响应时间的隐性膨胀
很多人忽略的一点是：多智能体系统会把一次任务的成本乘以智能体数量和通信轮数。原本单体模型一次3万Token的调用，换成5个智能体、每个调用2轮，总Token可能轻松超过30万，费用和延迟都会上一个数量级。
控制成本的思路：
第一，能不调用模型就不调用。如果任务分发、消息过滤这些逻辑能用规则代码实现，就不要让模型做。
第二，用便宜的模型做边缘角色，让最强模型只做关键决策。比如资料研究环节可以先用快速模型粗筛，再让强模型做最终的整合判断。
第三，控制上下文长度。每个智能体的输入输出都尽量结构化紧凑，不要整个对话历史原样透传。
我做过一次对比，同一批任务，加入上下文精简策略后，成本下降了一半多，而最终输出质量几乎没变化。多智能体系统里的智能不等于堆Token。
4.4 从Demo到可用系统的自查清单
最后给你一份自查清单，是我自己每上一个多智能体项目都会过一遍的：
角色是否足够少且职责互斥？有没有两个角色在做同一件事？
每个智能体的输入输出是否有明确格式？能不能直接用数据校验？
通信路径是否最简？有没有人可以不通信就不通信？
有没有覆盖三类终止条件？系统异常时会不会卡死？
日志是否完整？能否回放每一步消息流转？
有没有做错误注入测试（故意给错误输入）？
成本预估是否在可控范围？有没有把无关消息精简掉？
这份清单不花什么时间，却能筛掉大多数线上事故。多智能体系统比单体系统多了无数条出错路径，越早做约束，后面越省心。
最后聊两句个人体会。我接触多智能体系统之后最大的感受是：它不像算法竞赛，更像带团队。你设计的是角色、沟通规则、汇报链路和止损方案，而不是在哪一个Prompt里塞更多魔法词。这带来的好处是系统行为更可解释、更易维护；坏处是你要开始面对人的管理问题——只不过你的团队成员是模型。如果你现在正准备做第一个多智能体Demo，我的建议是最小化起步：两个角色，一条链路，一个复盘环节，先让它产出比单体更稳定的一件小作品，再逐周加复杂度。这个循序渐进的路子，我实测比一上来就搭八智能体大舞台要稳得多。
