1. 多智能体系统到底在解决什么问题第一次听到“多智能体系统”这个词很多人脑子里浮现的可能是科幻电影里一群机器人开会的画面。但如果你真正动手搭过几个AI应用就会发现一个很现实的问题单个智能体再强也有它搞不定的活儿。就像打游戏你一个人操作再秀遇到需要同时拉怪、输出、治疗、控场的副本还是得组队。我最初接触这个概念是在做一个制度条例学习助手的项目。当时想法很简单把制度文档喂给一个大模型用户提问它回答就完事了。结果上线测试第一天就翻车用户问“出差住宿标准是多少”模型回答得头头是道但引用的条款是三个月前已经废止的版本。问题出在哪单个智能体既要理解问题、又要检索文档、还要判断时效性、最后组织语言输出四个任务挤在一个推理链路里任何一个环节出错整体结果就崩了。这就是多智能体系统要解决的核心痛点把复杂任务拆解成多个专职角色让每个智能体只做自己最擅长的事通过协作完成单一个体无法可靠完成的工作。打个比方单智能体像是一个什么都懂一点但什么都不精的实习生多智能体则是一个分工明确的团队——有人负责查资料有人负责审核有人负责写报告有人负责校对。从技术演进的角度看多智能体系统的出现有三个推动力。第一是大模型能力边界的清晰化大家逐渐意识到让一个模型同时处理检索、推理、生成、验证是不现实的每个环节的误差会累积放大。第二是工程化落地的需求2026年被很多人称为工业智能体从概念演示走向工程化落地的分水岭企业要的不是能聊天的玩具而是能稳定输出可靠结果的系统。第三是成本考量用一个大模型反复调用解决复杂问题不如用多个小模型或专用模型各司其职来得经济。适合阅读这篇内容的人我大致分三类。第一类是有一定AI应用开发经验想从单智能体升级到多智能体架构的开发者。第二类是对智能体协作机制好奇想了解背后原理的产品经理或技术管理者。第三类是正在做智能体相关项目遇到了单智能体性能瓶颈想找解决方案的实践者。如果你完全没接触过AI应用开发建议先了解一下基本的提示词工程和大模型调用方式再来看这篇会更容易上手。2. 多智能体系统的核心架构与角色设计2.1 为什么不能把所有任务塞给一个智能体在展开架构细节之前我想先讲清楚一个设计原则智能体的职责边界越清晰系统的整体可靠性越高。这个结论是我踩了无数次坑之后总结出来的。早期我做智能体开发时喜欢写一个“万能提示词”把检索、推理、格式化输出全部塞进去。提示词越写越长从最初的200字膨胀到3000多字结果模型的指令遵循能力反而下降了。原因很简单大模型的注意力机制在处理超长指令时会出现“中间遗忘”现象提示词中段的约束条件经常被忽略。更麻烦的是当输出结果出错时你根本不知道是检索环节出了问题还是推理环节跑偏了还是格式化阶段出了bug排查成本极高。多智能体架构的核心思路就是关注点分离。每个智能体只负责一个明确的子任务拥有独立的系统提示词、独立的工具集、独立的输出格式约束。这样做的好处是每个环节可以单独测试、单独优化、单独替换。检索效果不好就调检索智能体推理逻辑有问题就改推理智能体的提示词互不干扰。2.2 典型的多智能体角色划分根据我做过的一些项目经验一个完整的多智能体系统通常包含以下几类角色。当然不是每个项目都需要全部角色具体要根据任务复杂度来裁剪。角色类型核心职责常用工具输出要求协调智能体任务拆解、路由分发、结果汇总任务规划器、路由表结构化任务列表检索智能体从知识库获取相关信息向量检索、关键词检索带来源的文本片段推理智能体基于检索结果进行逻辑分析思维链、推理框架分析结论与依据生成智能体组织语言输出最终结果模板引擎、格式化工具符合格式的最终答案审核智能体检查输出的事实性与合规性规则引擎、二次验证通过/不通过及原因记忆智能体管理对话历史与上下文向量数据库、缓存相关历史摘要拿制度条例学习助手这个项目举例我最终确定的角色划分是这样的协调智能体负责判断用户问题的类型是查询具体条款、还是询问流程、还是需要对比不同制度然后路由到对应的处理链路。检索智能体负责从制度库中找出相关条款这里有个关键设计——检索智能体不直接返回原文而是返回带时间戳和版本号的条款片段。推理智能体拿到检索结果后会判断条款是否现行有效如果发现多个版本冲突会标记出来交给审核智能体处理。生成智能体最后把确认有效的信息组织成自然语言回答。审核智能体做最后一道关检查回答中引用的条款编号是否真实存在、是否与检索结果一致。2.3 通信机制智能体之间怎么“说话”多智能体系统里智能体之间的通信方式直接决定了系统的灵活性和可靠性。我实践下来主要有三种模式各有适用场景。第一种是共享黑板模式。所有智能体读写同一个共享内存区域每个智能体把自己的输出写到黑板上也从黑板上读取自己需要的信息。这种模式实现简单适合智能体数量少、交互逻辑不复杂的场景。缺点是当智能体数量增多时黑板上的信息会变得混乱容易出现读写冲突。第二种是消息传递模式。智能体之间通过显式的消息进行通信每个消息包含发送者、接收者、消息类型和内容。这种模式结构清晰适合需要精确控制交互流程的场景。我在制度助手项目里用的就是这种模式协调智能体向检索智能体发送“检索请求”消息检索智能体返回“检索结果”消息消息格式用JSON Schema严格约束避免了解析歧义。第三种是图编排模式。用有向图定义智能体之间的依赖关系和执行顺序每个节点是一个智能体或一个处理步骤边表示数据流向。这种模式适合流程固定、需要可视化编排的场景。LangGraph就是这种模式的典型代表它把智能体工作流定义为一个状态图每个节点可以是一个智能体调用边可以带条件判断支持循环和分支。实操心得如果你的任务流程是线性的、步骤固定的优先考虑图编排模式调试起来最直观。如果任务需要动态决策、根据中间结果决定下一步走向消息传递模式更灵活。共享黑板模式我一般只在做快速原型验证时用正式项目不太推荐。3. 从零搭建一个多智能体系统的实操过程3.1 环境准备与技术选型动手之前先把工具链确定下来。我目前主力用的是Python生态核心依赖包括LangChain做智能体基础能力封装、LangGraph做工作流编排、Chroma或Milvus做向量存储、FastAPI做服务接口。如果你更习惯用现成的平台Dify和Coze也提供了多智能体编排能力适合快速验证想法但深度定制不如自己写代码灵活。环境配置这块我建议用conda建一个独立环境避免依赖冲突。Python版本选3.10或3.11太新的版本有些库还没适配。核心依赖的版本要锁死LangChain和LangGraph的API变动比较频繁不锁版本的话今天跑通的代码明天可能就报错了。conda create -n multi-agent python3.11 conda activate multi-agent pip install langchain0.3.7 langgraph0.2.45 langchain-openai0.2.8 chromadb0.5.18 fastapi0.115.0API Key的管理别图省事直接写在代码里用环境变量或者配置文件加载。我习惯用一个config.yaml存模型配置代码里通过环境变量指定配置文件路径这样本地开发和线上部署可以用不同的配置。3.2 定义智能体的基础结构每个智能体本质上是一个函数输入是消息列表和上下文输出是处理结果。但为了让多个智能体能够协同工作需要统一接口。我一般定义一个BaseAgent类包含name、description、system_prompt、tools四个核心属性以及一个async invoke方法。from abc import ABC, abstractmethod from typing import List, Dict, Any class BaseAgent(ABC): def __init__(self, name: str, description: str, system_prompt: str, tools: List None): self.name name self.description description self.system_prompt system_prompt self.tools tools or [] abstractmethod async def invoke(self, messages: List[Dict], context: Dict[str, Any]) - Dict[str, Any]: pass这个抽象类看起来简单但有几个设计细节值得注意。description字段不是给用户看的是给协调智能体看的协调智能体根据每个智能体的description来决定把任务路由给谁。所以description要写得精准说清楚这个智能体能做什么、不能做什么。system_prompt是这个智能体的行为准则要包含角色定义、输出格式要求、边界条件处理。tools是这个智能体可以调用的外部工具列表比如检索工具、计算工具、API调用工具。3.3 协调智能体的实现逻辑协调智能体是整个系统的大脑它的核心任务是理解用户意图然后把任务拆解并分发给合适的下游智能体。实现上我用了一个两阶段的设计先做意图分类再做任务规划。意图分类用一个轻量级的提示词让模型判断用户问题属于哪个类别。比如制度助手项目里类别包括“条款查询”“流程咨询”“制度对比”“时效性确认”四类。分类结果决定了后续走哪条处理链路。这一步用一个小模型就够了不需要上大模型响应快、成本低。任务规划阶段协调智能体根据意图分类结果生成一个任务列表每个任务包含目标智能体、输入参数、依赖关系。比如用户问“2025年出差住宿标准相比2024年有什么变化”协调智能体会生成三个任务第一个任务让检索智能体查2025年标准第二个任务让检索智能体查2024年标准第三个任务让推理智能体对比两个结果。第三个任务依赖前两个任务的输出所以要在依赖关系里标明。async def coordinate(self, user_query: str) - Dict: intent await self.classify_intent(user_query) if intent 条款查询: tasks [{agent: retriever, input: user_query, depends_on: []}] elif intent 制度对比: tasks [ {agent: retriever, input: f查询{self.extract_year(user_query, first)}年相关条款, depends_on: []}, {agent: retriever, input: f查询{self.extract_year(user_query, second)}年相关条款, depends_on: []}, {agent: reasoner, input: 对比上述两个检索结果, depends_on: [0, 1]} ] return {intent: intent, tasks: tasks}注意事项协调智能体的提示词里一定要加一条“如果无法确定用户意图返回澄清请求而不是猜测”。我早期版本没加这条结果用户问了一个模糊问题协调智能体强行分类导致后续所有智能体都在错误的方向上工作浪费了大量token。3.4 检索智能体的关键配置检索智能体负责从知识库中找出与问题相关的信息。这块的坑最多我展开讲。第一个坑是分块策略。制度文档不能简单地按固定字数切分因为一个条款可能跨越多段按字数切会把完整条款切碎。我的做法是按文档结构切分识别出“第X条”“第X章”这样的标记以条款为最小单位。如果单个条款超过500字再按语义切分。分块大小控制在300到800字之间太小了信息不完整太大了检索精度下降。第二个坑是检索方式的选择。纯向量检索对语义相似但用词不同的查询效果好但对精确匹配条款编号这种需求就力不从心。纯关键词检索反过来。我最终用的是混合检索先用关键词检索召回包含条款编号或特定术语的文档再用向量检索召回语义相关的文档两路结果合并去重后按相关性排序。第三个坑是元数据过滤。制度文档有版本和时效性检索时必须带上时间过滤条件。我在向量库的metadata里存了生效日期、失效日期、版本号三个字段检索时默认只返回当前生效的条款。如果用户明确要查历史版本才放开时间过滤。async def retrieve(self, query: str, include_expired: bool False) - List[Dict]: # 关键词检索 keyword_results self.keyword_search(query, top_k5) # 向量检索 vector_results self.vector_search(query, top_k5) # 合并去重 merged self.merge_results(keyword_results, vector_results) # 时效性过滤 if not include_expired: merged [r for r in merged if r[metadata][status] active] return merged[:8]3.5 推理智能体与审核智能体的配合推理智能体拿到检索结果后要做的是逻辑分析和结论推导。这里的关键是要求推理智能体输出推理链而不是直接给结论。推理链的价值在于可追溯当审核智能体发现结论有问题时可以定位到推理链的哪一步出了错。我用的提示词模板大致是这样的先让模型列出所有相关条款然后逐条分析条款的适用条件最后综合判断给出结论。每一步都要求引用具体的条款编号和原文片段。这样做的好处是如果检索结果里混入了不相关的条款推理智能体在分析阶段就会暴露出来而不是把错误信息带到最终结论里。审核智能体的职责是二次验证。它拿到推理智能体的输出后做三件事第一检查所有引用的条款编号是否在检索结果中存在第二检查推理链中是否有逻辑跳跃第三检查最终结论是否与推理链一致。任何一项不通过审核智能体就返回不通过标记和具体原因协调智能体根据原因决定是重新检索还是重新推理。这套机制听起来增加了复杂度但实际运行下来最终输出的准确率比单智能体方案提升了将近40个百分点。代价是响应时间增加了2到3倍token消耗增加了4到5倍。所以是否采用多智能体架构要根据业务对准确率和响应速度的权衡来决定。4. 多智能体系统的常见问题与排查技巧4.1 智能体之间“踢皮球”怎么办这是多智能体系统最典型的问题协调智能体把任务分给AA觉得这不是自己的活又推回给协调智能体协调智能体再分给BB又推回来形成死循环。我遇到过最夸张的一次两个智能体来回推了17次才停下来token账单直接爆炸。根因通常是智能体的职责边界定义模糊。比如检索智能体的description写的是“负责信息获取”推理智能体的description写的是“负责信息处理”那“从文档中提取特定字段”这个任务到底该谁做两个智能体都觉得该对方做。解决办法是在每个智能体的系统提示词里加一条明确的拒绝规则如果任务不属于你的职责范围直接返回“NOT_MY_JOB”标记和推荐的下游智能体名称不要尝试处理。同时在协调智能体侧加一个最大重试次数限制同一个任务被推回超过2次就强制指定一个智能体执行或者直接返回失败并记录日志。4.2 上下文膨胀导致性能下降多智能体系统里每个智能体都需要看到前序智能体的输出作为上下文。如果前序输出很长上下文会迅速膨胀。我做过一个测试一个5个智能体串联的流程每个智能体平均输出800字到最后一个智能体时上下文已经超过4000字模型的响应质量明显下降开始出现遗漏关键信息的情况。应对策略有三个。第一每个智能体的输出强制结构化用JSON格式而不是自然语言只保留下游需要的关键字段。第二引入摘要智能体在上下文传递给下游之前先做压缩把长文本压缩成关键要点。第三按需传递上下文不是每个智能体都需要看到全部前序输出只传递它真正需要的部分。我目前的做法是组合使用检索智能体的输出用结构化格式只保留条款编号、原文片段、生效日期三个字段推理智能体的输出保留推理链但限制在500字以内生成智能体只接收最终结论和引用来源不接收完整推理过程。4.3 输出格式不一致导致解析失败多智能体系统里智能体之间的通信依赖结构化输出。但大模型有个毛病你要求它输出JSON它有时候会在JSON前后加一段解释性文字有时候会把JSON的某个字段值写成自然语言有时候干脆忘了某个必填字段。我的解决方案是三层防护。第一层在提示词里用few-shot示例明确展示期望的输出格式示例要覆盖正常情况和边界情况。第二层在代码里做格式校验解析失败时自动触发重试重试时把解析错误信息反馈给模型让它修正。第三层如果重试两次仍然失败降级到人工处理队列同时记录失败样本用于后续优化提示词。async def invoke_with_retry(self, agent, messages, context, max_retries2): for attempt in range(max_retries 1): try: result await agent.invoke(messages, context) parsed self.parse_output(result) return parsed except ParseError as e: if attempt max_retries: messages.append({role: user, content: f上次输出格式有误{str(e)}请严格按照JSON Schema重新输出}) else: self.log_failure(agent.name, messages, str(e)) raise4.4 常见问题速查表问题现象可能原因排查方向解决措施智能体互相推诿职责边界模糊检查各智能体description和提示词加NOT_MY_JOB标记和最大重试限制响应越来越慢上下文膨胀统计各环节输入输出token数结构化输出、摘要压缩、按需传递解析频繁失败输出格式不稳定查看失败样本的原始输出加few-shot示例、格式校验、自动重试最终结果不准确检索环节召回不足检查检索结果的相关性混合检索、调整分块策略、加元数据过滤同一问题多次回答不一致推理路径不稳定对比多次运行的推理链降低temperature、固定随机种子、加推理模板token消耗过高冗余调用过多统计各智能体调用次数合并可并行的任务、缓存重复检索结果避坑技巧多智能体系统调试时一定要把每个智能体的输入输出完整记录下来。我习惯在每次调用时把agent_name、input_messages、output_raw、parsed_result、latency、token_usage写进日志。出问题时按trace_id串起来看能快速定位是哪个环节出了问题。这个日志习惯帮我省了至少几十个小时的排查时间。5. 多智能体系统的扩展方向与个人实践体会5.1 从固定流程到动态编排我目前做的多智能体系统工作流基本是预先定义好的协调智能体按照固定的规则做路由。这种方式稳定可控但灵活性有限。下一步我想尝试的是动态编排让协调智能体根据任务复杂度自动决定需要哪些智能体参与、以什么顺序执行、是否需要循环迭代。实现动态编排的关键是给协调智能体一个“智能体能力清单”包含每个智能体的能力描述、输入输出格式、调用成本。协调智能体根据任务需求从清单中选择合适的智能体组合生成执行计划。执行过程中如果遇到问题还可以动态调整计划比如增加一个审核智能体或者跳过某个非关键步骤。这种模式对协调智能体的规划能力要求很高目前我还在实验阶段用LangGraph的条件边和循环节点做原型验证。初步效果是对于简单任务动态编排能自动跳过不必要的智能体节省30%左右的token消耗对于复杂任务能自动增加审核环节提升输出可靠性。5.2 智能体评估与持续优化多智能体系统上线后怎么知道它表现好不好我建了一个评估集包含100个典型问题和对应的标准答案。每次修改提示词或调整流程后跑一遍评估集统计准确率、平均响应时间、平均token消耗三个指标。评估过程中我发现一个有意思的现象增加智能体数量并不总是提升准确率。当智能体数量从3个增加到5个时准确率提升了但从5个增加到7个时准确率反而下降了。原因是过多的智能体引入了更多的通信开销和误差累积机会。所以我现在遵循一个原则能用3个智能体解决的问题绝不用5个。另一个优化方向是缓存策略。很多用户问题其实是重复的或者高度相似的。我在检索智能体前面加了一层语义缓存如果新问题与缓存中的历史问题语义相似度超过阈值直接返回缓存结果跳过后续所有智能体。这个优化把平均响应时间从8秒降到了2秒以内token消耗降低了60%。5.3 我踩过的三个印象最深的坑第一个坑是过度依赖大模型做路由。早期我用大模型来判断用户意图结果发现大模型有时候会“想太多”把简单问题复杂化。比如用户问“出差住宿标准”大模型判断这是“制度对比”意图因为“标准”这个词让它联想到了“对比不同标准”。后来我改用小模型做意图分类准确率反而更高因为小模型更倾向于做表面模式匹配不会过度推理。第二个坑是忽略冷启动问题。系统刚上线时向量库里只有少量文档检索效果很差。我当时的做法是先用关键词检索兜底等向量库积累到一定规模后再启用向量检索。这个过渡策略帮我避免了上线初期的口碑崩塌。第三个坑是没有做降级方案。有一次模型API服务出现波动整个多智能体系统全部瘫痪。后来我加了一个降级链路如果主模型调用失败自动切换到备用模型如果所有模型都不可用降级到基于规则的简单问答。虽然降级后的回答质量下降但至少服务不中断。5.4 给准备入坑的朋友几句实在话多智能体系统不是银弹。它解决的是单智能体在复杂任务上可靠性不足的问题代价是更高的工程复杂度、更长的响应时间和更多的token消耗。如果你的任务用单智能体就能稳定完成没必要为了“技术先进”而强行上多智能体。入门的话我建议从两个智能体开始一个检索、一个生成。把这两个智能体的协作跑通理解消息传递、上下文管理、输出解析这些基础机制再逐步增加推理、审核等角色。不要一上来就搭五六个智能体的系统调试成本会让你怀疑人生。工具选择上LangGraph目前是我用过的最顺手的编排框架它的状态图模型很直观条件边和循环节点的支持也完善。Dify和Coze适合快速验证想法但深度定制受限。如果你团队有前端资源可以考虑自己基于FastAPI和WebSocket搭一套轻量级的编排引擎灵活性最高但开发成本也最大。最后说一个我最近在尝试的方向把多智能体系统用在代码生成场景。让一个智能体负责理解需求一个负责生成代码一个负责写测试用例一个负责运行测试并反馈结果。这个闭环目前跑通了简单场景复杂场景还在调优。等成熟了再单独写一篇分享。
多智能体系统实战：从单智能体瓶颈到工程化协作架构
1. 多智能体系统到底在解决什么问题第一次听到“多智能体系统”这个词很多人脑子里浮现的可能是科幻电影里一群机器人开会的画面。但如果你真正动手搭过几个AI应用就会发现一个很现实的问题单个智能体再强也有它搞不定的活儿。就像打游戏你一个人操作再秀遇到需要同时拉怪、输出、治疗、控场的副本还是得组队。我最初接触这个概念是在做一个制度条例学习助手的项目。当时想法很简单把制度文档喂给一个大模型用户提问它回答就完事了。结果上线测试第一天就翻车用户问“出差住宿标准是多少”模型回答得头头是道但引用的条款是三个月前已经废止的版本。问题出在哪单个智能体既要理解问题、又要检索文档、还要判断时效性、最后组织语言输出四个任务挤在一个推理链路里任何一个环节出错整体结果就崩了。这就是多智能体系统要解决的核心痛点把复杂任务拆解成多个专职角色让每个智能体只做自己最擅长的事通过协作完成单一个体无法可靠完成的工作。打个比方单智能体像是一个什么都懂一点但什么都不精的实习生多智能体则是一个分工明确的团队——有人负责查资料有人负责审核有人负责写报告有人负责校对。从技术演进的角度看多智能体系统的出现有三个推动力。第一是大模型能力边界的清晰化大家逐渐意识到让一个模型同时处理检索、推理、生成、验证是不现实的每个环节的误差会累积放大。第二是工程化落地的需求2026年被很多人称为工业智能体从概念演示走向工程化落地的分水岭企业要的不是能聊天的玩具而是能稳定输出可靠结果的系统。第三是成本考量用一个大模型反复调用解决复杂问题不如用多个小模型或专用模型各司其职来得经济。适合阅读这篇内容的人我大致分三类。第一类是有一定AI应用开发经验想从单智能体升级到多智能体架构的开发者。第二类是对智能体协作机制好奇想了解背后原理的产品经理或技术管理者。第三类是正在做智能体相关项目遇到了单智能体性能瓶颈想找解决方案的实践者。如果你完全没接触过AI应用开发建议先了解一下基本的提示词工程和大模型调用方式再来看这篇会更容易上手。2. 多智能体系统的核心架构与角色设计2.1 为什么不能把所有任务塞给一个智能体在展开架构细节之前我想先讲清楚一个设计原则智能体的职责边界越清晰系统的整体可靠性越高。这个结论是我踩了无数次坑之后总结出来的。早期我做智能体开发时喜欢写一个“万能提示词”把检索、推理、格式化输出全部塞进去。提示词越写越长从最初的200字膨胀到3000多字结果模型的指令遵循能力反而下降了。原因很简单大模型的注意力机制在处理超长指令时会出现“中间遗忘”现象提示词中段的约束条件经常被忽略。更麻烦的是当输出结果出错时你根本不知道是检索环节出了问题还是推理环节跑偏了还是格式化阶段出了bug排查成本极高。多智能体架构的核心思路就是关注点分离。每个智能体只负责一个明确的子任务拥有独立的系统提示词、独立的工具集、独立的输出格式约束。这样做的好处是每个环节可以单独测试、单独优化、单独替换。检索效果不好就调检索智能体推理逻辑有问题就改推理智能体的提示词互不干扰。2.2 典型的多智能体角色划分根据我做过的一些项目经验一个完整的多智能体系统通常包含以下几类角色。当然不是每个项目都需要全部角色具体要根据任务复杂度来裁剪。角色类型核心职责常用工具输出要求协调智能体任务拆解、路由分发、结果汇总任务规划器、路由表结构化任务列表检索智能体从知识库获取相关信息向量检索、关键词检索带来源的文本片段推理智能体基于检索结果进行逻辑分析思维链、推理框架分析结论与依据生成智能体组织语言输出最终结果模板引擎、格式化工具符合格式的最终答案审核智能体检查输出的事实性与合规性规则引擎、二次验证通过/不通过及原因记忆智能体管理对话历史与上下文向量数据库、缓存相关历史摘要拿制度条例学习助手这个项目举例我最终确定的角色划分是这样的协调智能体负责判断用户问题的类型是查询具体条款、还是询问流程、还是需要对比不同制度然后路由到对应的处理链路。检索智能体负责从制度库中找出相关条款这里有个关键设计——检索智能体不直接返回原文而是返回带时间戳和版本号的条款片段。推理智能体拿到检索结果后会判断条款是否现行有效如果发现多个版本冲突会标记出来交给审核智能体处理。生成智能体最后把确认有效的信息组织成自然语言回答。审核智能体做最后一道关检查回答中引用的条款编号是否真实存在、是否与检索结果一致。2.3 通信机制智能体之间怎么“说话”多智能体系统里智能体之间的通信方式直接决定了系统的灵活性和可靠性。我实践下来主要有三种模式各有适用场景。第一种是共享黑板模式。所有智能体读写同一个共享内存区域每个智能体把自己的输出写到黑板上也从黑板上读取自己需要的信息。这种模式实现简单适合智能体数量少、交互逻辑不复杂的场景。缺点是当智能体数量增多时黑板上的信息会变得混乱容易出现读写冲突。第二种是消息传递模式。智能体之间通过显式的消息进行通信每个消息包含发送者、接收者、消息类型和内容。这种模式结构清晰适合需要精确控制交互流程的场景。我在制度助手项目里用的就是这种模式协调智能体向检索智能体发送“检索请求”消息检索智能体返回“检索结果”消息消息格式用JSON Schema严格约束避免了解析歧义。第三种是图编排模式。用有向图定义智能体之间的依赖关系和执行顺序每个节点是一个智能体或一个处理步骤边表示数据流向。这种模式适合流程固定、需要可视化编排的场景。LangGraph就是这种模式的典型代表它把智能体工作流定义为一个状态图每个节点可以是一个智能体调用边可以带条件判断支持循环和分支。实操心得如果你的任务流程是线性的、步骤固定的优先考虑图编排模式调试起来最直观。如果任务需要动态决策、根据中间结果决定下一步走向消息传递模式更灵活。共享黑板模式我一般只在做快速原型验证时用正式项目不太推荐。3. 从零搭建一个多智能体系统的实操过程3.1 环境准备与技术选型动手之前先把工具链确定下来。我目前主力用的是Python生态核心依赖包括LangChain做智能体基础能力封装、LangGraph做工作流编排、Chroma或Milvus做向量存储、FastAPI做服务接口。如果你更习惯用现成的平台Dify和Coze也提供了多智能体编排能力适合快速验证想法但深度定制不如自己写代码灵活。环境配置这块我建议用conda建一个独立环境避免依赖冲突。Python版本选3.10或3.11太新的版本有些库还没适配。核心依赖的版本要锁死LangChain和LangGraph的API变动比较频繁不锁版本的话今天跑通的代码明天可能就报错了。conda create -n multi-agent python3.11 conda activate multi-agent pip install langchain0.3.7 langgraph0.2.45 langchain-openai0.2.8 chromadb0.5.18 fastapi0.115.0API Key的管理别图省事直接写在代码里用环境变量或者配置文件加载。我习惯用一个config.yaml存模型配置代码里通过环境变量指定配置文件路径这样本地开发和线上部署可以用不同的配置。3.2 定义智能体的基础结构每个智能体本质上是一个函数输入是消息列表和上下文输出是处理结果。但为了让多个智能体能够协同工作需要统一接口。我一般定义一个BaseAgent类包含name、description、system_prompt、tools四个核心属性以及一个async invoke方法。from abc import ABC, abstractmethod from typing import List, Dict, Any class BaseAgent(ABC): def __init__(self, name: str, description: str, system_prompt: str, tools: List None): self.name name self.description description self.system_prompt system_prompt self.tools tools or [] abstractmethod async def invoke(self, messages: List[Dict], context: Dict[str, Any]) - Dict[str, Any]: pass这个抽象类看起来简单但有几个设计细节值得注意。description字段不是给用户看的是给协调智能体看的协调智能体根据每个智能体的description来决定把任务路由给谁。所以description要写得精准说清楚这个智能体能做什么、不能做什么。system_prompt是这个智能体的行为准则要包含角色定义、输出格式要求、边界条件处理。tools是这个智能体可以调用的外部工具列表比如检索工具、计算工具、API调用工具。3.3 协调智能体的实现逻辑协调智能体是整个系统的大脑它的核心任务是理解用户意图然后把任务拆解并分发给合适的下游智能体。实现上我用了一个两阶段的设计先做意图分类再做任务规划。意图分类用一个轻量级的提示词让模型判断用户问题属于哪个类别。比如制度助手项目里类别包括“条款查询”“流程咨询”“制度对比”“时效性确认”四类。分类结果决定了后续走哪条处理链路。这一步用一个小模型就够了不需要上大模型响应快、成本低。任务规划阶段协调智能体根据意图分类结果生成一个任务列表每个任务包含目标智能体、输入参数、依赖关系。比如用户问“2025年出差住宿标准相比2024年有什么变化”协调智能体会生成三个任务第一个任务让检索智能体查2025年标准第二个任务让检索智能体查2024年标准第三个任务让推理智能体对比两个结果。第三个任务依赖前两个任务的输出所以要在依赖关系里标明。async def coordinate(self, user_query: str) - Dict: intent await self.classify_intent(user_query) if intent 条款查询: tasks [{agent: retriever, input: user_query, depends_on: []}] elif intent 制度对比: tasks [ {agent: retriever, input: f查询{self.extract_year(user_query, first)}年相关条款, depends_on: []}, {agent: retriever, input: f查询{self.extract_year(user_query, second)}年相关条款, depends_on: []}, {agent: reasoner, input: 对比上述两个检索结果, depends_on: [0, 1]} ] return {intent: intent, tasks: tasks}注意事项协调智能体的提示词里一定要加一条“如果无法确定用户意图返回澄清请求而不是猜测”。我早期版本没加这条结果用户问了一个模糊问题协调智能体强行分类导致后续所有智能体都在错误的方向上工作浪费了大量token。3.4 检索智能体的关键配置检索智能体负责从知识库中找出与问题相关的信息。这块的坑最多我展开讲。第一个坑是分块策略。制度文档不能简单地按固定字数切分因为一个条款可能跨越多段按字数切会把完整条款切碎。我的做法是按文档结构切分识别出“第X条”“第X章”这样的标记以条款为最小单位。如果单个条款超过500字再按语义切分。分块大小控制在300到800字之间太小了信息不完整太大了检索精度下降。第二个坑是检索方式的选择。纯向量检索对语义相似但用词不同的查询效果好但对精确匹配条款编号这种需求就力不从心。纯关键词检索反过来。我最终用的是混合检索先用关键词检索召回包含条款编号或特定术语的文档再用向量检索召回语义相关的文档两路结果合并去重后按相关性排序。第三个坑是元数据过滤。制度文档有版本和时效性检索时必须带上时间过滤条件。我在向量库的metadata里存了生效日期、失效日期、版本号三个字段检索时默认只返回当前生效的条款。如果用户明确要查历史版本才放开时间过滤。async def retrieve(self, query: str, include_expired: bool False) - List[Dict]: # 关键词检索 keyword_results self.keyword_search(query, top_k5) # 向量检索 vector_results self.vector_search(query, top_k5) # 合并去重 merged self.merge_results(keyword_results, vector_results) # 时效性过滤 if not include_expired: merged [r for r in merged if r[metadata][status] active] return merged[:8]3.5 推理智能体与审核智能体的配合推理智能体拿到检索结果后要做的是逻辑分析和结论推导。这里的关键是要求推理智能体输出推理链而不是直接给结论。推理链的价值在于可追溯当审核智能体发现结论有问题时可以定位到推理链的哪一步出了错。我用的提示词模板大致是这样的先让模型列出所有相关条款然后逐条分析条款的适用条件最后综合判断给出结论。每一步都要求引用具体的条款编号和原文片段。这样做的好处是如果检索结果里混入了不相关的条款推理智能体在分析阶段就会暴露出来而不是把错误信息带到最终结论里。审核智能体的职责是二次验证。它拿到推理智能体的输出后做三件事第一检查所有引用的条款编号是否在检索结果中存在第二检查推理链中是否有逻辑跳跃第三检查最终结论是否与推理链一致。任何一项不通过审核智能体就返回不通过标记和具体原因协调智能体根据原因决定是重新检索还是重新推理。这套机制听起来增加了复杂度但实际运行下来最终输出的准确率比单智能体方案提升了将近40个百分点。代价是响应时间增加了2到3倍token消耗增加了4到5倍。所以是否采用多智能体架构要根据业务对准确率和响应速度的权衡来决定。4. 多智能体系统的常见问题与排查技巧4.1 智能体之间“踢皮球”怎么办这是多智能体系统最典型的问题协调智能体把任务分给AA觉得这不是自己的活又推回给协调智能体协调智能体再分给BB又推回来形成死循环。我遇到过最夸张的一次两个智能体来回推了17次才停下来token账单直接爆炸。根因通常是智能体的职责边界定义模糊。比如检索智能体的description写的是“负责信息获取”推理智能体的description写的是“负责信息处理”那“从文档中提取特定字段”这个任务到底该谁做两个智能体都觉得该对方做。解决办法是在每个智能体的系统提示词里加一条明确的拒绝规则如果任务不属于你的职责范围直接返回“NOT_MY_JOB”标记和推荐的下游智能体名称不要尝试处理。同时在协调智能体侧加一个最大重试次数限制同一个任务被推回超过2次就强制指定一个智能体执行或者直接返回失败并记录日志。4.2 上下文膨胀导致性能下降多智能体系统里每个智能体都需要看到前序智能体的输出作为上下文。如果前序输出很长上下文会迅速膨胀。我做过一个测试一个5个智能体串联的流程每个智能体平均输出800字到最后一个智能体时上下文已经超过4000字模型的响应质量明显下降开始出现遗漏关键信息的情况。应对策略有三个。第一每个智能体的输出强制结构化用JSON格式而不是自然语言只保留下游需要的关键字段。第二引入摘要智能体在上下文传递给下游之前先做压缩把长文本压缩成关键要点。第三按需传递上下文不是每个智能体都需要看到全部前序输出只传递它真正需要的部分。我目前的做法是组合使用检索智能体的输出用结构化格式只保留条款编号、原文片段、生效日期三个字段推理智能体的输出保留推理链但限制在500字以内生成智能体只接收最终结论和引用来源不接收完整推理过程。4.3 输出格式不一致导致解析失败多智能体系统里智能体之间的通信依赖结构化输出。但大模型有个毛病你要求它输出JSON它有时候会在JSON前后加一段解释性文字有时候会把JSON的某个字段值写成自然语言有时候干脆忘了某个必填字段。我的解决方案是三层防护。第一层在提示词里用few-shot示例明确展示期望的输出格式示例要覆盖正常情况和边界情况。第二层在代码里做格式校验解析失败时自动触发重试重试时把解析错误信息反馈给模型让它修正。第三层如果重试两次仍然失败降级到人工处理队列同时记录失败样本用于后续优化提示词。async def invoke_with_retry(self, agent, messages, context, max_retries2): for attempt in range(max_retries 1): try: result await agent.invoke(messages, context) parsed self.parse_output(result) return parsed except ParseError as e: if attempt max_retries: messages.append({role: user, content: f上次输出格式有误{str(e)}请严格按照JSON Schema重新输出}) else: self.log_failure(agent.name, messages, str(e)) raise4.4 常见问题速查表问题现象可能原因排查方向解决措施智能体互相推诿职责边界模糊检查各智能体description和提示词加NOT_MY_JOB标记和最大重试限制响应越来越慢上下文膨胀统计各环节输入输出token数结构化输出、摘要压缩、按需传递解析频繁失败输出格式不稳定查看失败样本的原始输出加few-shot示例、格式校验、自动重试最终结果不准确检索环节召回不足检查检索结果的相关性混合检索、调整分块策略、加元数据过滤同一问题多次回答不一致推理路径不稳定对比多次运行的推理链降低temperature、固定随机种子、加推理模板token消耗过高冗余调用过多统计各智能体调用次数合并可并行的任务、缓存重复检索结果避坑技巧多智能体系统调试时一定要把每个智能体的输入输出完整记录下来。我习惯在每次调用时把agent_name、input_messages、output_raw、parsed_result、latency、token_usage写进日志。出问题时按trace_id串起来看能快速定位是哪个环节出了问题。这个日志习惯帮我省了至少几十个小时的排查时间。5. 多智能体系统的扩展方向与个人实践体会5.1 从固定流程到动态编排我目前做的多智能体系统工作流基本是预先定义好的协调智能体按照固定的规则做路由。这种方式稳定可控但灵活性有限。下一步我想尝试的是动态编排让协调智能体根据任务复杂度自动决定需要哪些智能体参与、以什么顺序执行、是否需要循环迭代。实现动态编排的关键是给协调智能体一个“智能体能力清单”包含每个智能体的能力描述、输入输出格式、调用成本。协调智能体根据任务需求从清单中选择合适的智能体组合生成执行计划。执行过程中如果遇到问题还可以动态调整计划比如增加一个审核智能体或者跳过某个非关键步骤。这种模式对协调智能体的规划能力要求很高目前我还在实验阶段用LangGraph的条件边和循环节点做原型验证。初步效果是对于简单任务动态编排能自动跳过不必要的智能体节省30%左右的token消耗对于复杂任务能自动增加审核环节提升输出可靠性。5.2 智能体评估与持续优化多智能体系统上线后怎么知道它表现好不好我建了一个评估集包含100个典型问题和对应的标准答案。每次修改提示词或调整流程后跑一遍评估集统计准确率、平均响应时间、平均token消耗三个指标。评估过程中我发现一个有意思的现象增加智能体数量并不总是提升准确率。当智能体数量从3个增加到5个时准确率提升了但从5个增加到7个时准确率反而下降了。原因是过多的智能体引入了更多的通信开销和误差累积机会。所以我现在遵循一个原则能用3个智能体解决的问题绝不用5个。另一个优化方向是缓存策略。很多用户问题其实是重复的或者高度相似的。我在检索智能体前面加了一层语义缓存如果新问题与缓存中的历史问题语义相似度超过阈值直接返回缓存结果跳过后续所有智能体。这个优化把平均响应时间从8秒降到了2秒以内token消耗降低了60%。5.3 我踩过的三个印象最深的坑第一个坑是过度依赖大模型做路由。早期我用大模型来判断用户意图结果发现大模型有时候会“想太多”把简单问题复杂化。比如用户问“出差住宿标准”大模型判断这是“制度对比”意图因为“标准”这个词让它联想到了“对比不同标准”。后来我改用小模型做意图分类准确率反而更高因为小模型更倾向于做表面模式匹配不会过度推理。第二个坑是忽略冷启动问题。系统刚上线时向量库里只有少量文档检索效果很差。我当时的做法是先用关键词检索兜底等向量库积累到一定规模后再启用向量检索。这个过渡策略帮我避免了上线初期的口碑崩塌。第三个坑是没有做降级方案。有一次模型API服务出现波动整个多智能体系统全部瘫痪。后来我加了一个降级链路如果主模型调用失败自动切换到备用模型如果所有模型都不可用降级到基于规则的简单问答。虽然降级后的回答质量下降但至少服务不中断。5.4 给准备入坑的朋友几句实在话多智能体系统不是银弹。它解决的是单智能体在复杂任务上可靠性不足的问题代价是更高的工程复杂度、更长的响应时间和更多的token消耗。如果你的任务用单智能体就能稳定完成没必要为了“技术先进”而强行上多智能体。入门的话我建议从两个智能体开始一个检索、一个生成。把这两个智能体的协作跑通理解消息传递、上下文管理、输出解析这些基础机制再逐步增加推理、审核等角色。不要一上来就搭五六个智能体的系统调试成本会让你怀疑人生。工具选择上LangGraph目前是我用过的最顺手的编排框架它的状态图模型很直观条件边和循环节点的支持也完善。Dify和Coze适合快速验证想法但深度定制受限。如果你团队有前端资源可以考虑自己基于FastAPI和WebSocket搭一套轻量级的编排引擎灵活性最高但开发成本也最大。最后说一个我最近在尝试的方向把多智能体系统用在代码生成场景。让一个智能体负责理解需求一个负责生成代码一个负责写测试用例一个负责运行测试并反馈结果。这个闭环目前跑通了简单场景复杂场景还在调优。等成熟了再单独写一篇分享。
![[分享好东西]用 TaoToken 统一 Key 打通 Godot 游戏开发流水线：harness 设计架构、AI 生成美术资源、编码测试到交付](http://pic.xiahunao.cn/yaotu/[分享好东西]用 TaoToken 统一 Key 打通 Godot 游戏开发流水线：harness 设计架构、AI 生成美术资源、编码测试到交付)
