1. 从单兵作战到团队协同为什么需要多智能体1.1 单智能体的天花板在哪里刚开始接触 Agent 开发的时候我和大多数人一样都是从单智能体入手的。一个 LLM 加上几个工具套一个 ReAct 循环能查天气、能搜网页、能算数学题感觉已经很厉害了。但真正把它放到稍微复杂一点的业务场景里跑问题就全暴露出来了。最典型的场景是“帮我调研一下某个行业然后写一份分析报告”。单智能体处理这个任务时它需要同时扮演调研员、分析师、写作者三个角色。结果就是上下文窗口被塞爆前面查到的资料到后面写报告时已经忘得差不多了工具调用开始混乱该搜索的时候它在写文件该写文件的时候它又在搜索最要命的是你没法对中间过程做精细控制它要么一口气跑完结果质量看运气要么在某个环节卡死然后整个流程崩溃。这不是模型能力的问题而是架构的问题。一个 Agent 的上下文窗口、工具集合、系统提示词都是有限的当你试图让它同时处理多个维度的任务时这些资源就会互相挤占。就像让一个人同时做产品经理、程序员和测试不是说他能力不够而是角色切换的成本太高而且没有一个角色能做到极致。1.2 多智能体到底解决了什么问题多智能体的核心思路其实很朴素既然一个 Agent 搞不定那就拆成多个 Agent每个 Agent 只负责一件事然后让它们协作完成整体任务。这个思路带来的好处是立竿见影的。每个 Agent 有自己独立的系统提示词可以专注于自己的角色有自己独立的工具集不需要在几十个工具里做选择有自己独立的上下文窗口不会被无关信息干扰。更重要的是你可以对每个 Agent 的输出做单独的校验和干预整个流程变得可控可观测。我拿一个实际项目举例。之前做过一个“技术文档自动生成”的系统单智能体版本的问题是它经常在生成 API 文档时混入架构设计的描述或者在写架构说明时又跑去列 API 参数。拆成多智能体之后我设计了四个角色需求解析 Agent 负责从用户输入中提取关键信息架构设计 Agent 负责生成系统架构API 文档 Agent 负责生成接口文档最后有一个审校 Agent 负责检查一致性和完整性。每个 Agent 各司其职最终输出的质量比单智能体版本高了不止一个档次。1.3 多智能体不是银弹什么时候该用什么时候不该用这里我必须泼一盆冷水。多智能体不是万能的它带来的复杂度也是实打实的。我见过不少团队明明一个单智能体加几个工具就能搞定的事情非要拆成五六个 Agent结果调试成本翻了好几倍效果还没提升多少。我的经验判断标准是这样的如果一个任务的子任务之间是线性依赖的而且每个子任务的输入输出都很明确那单智能体加工作流编排就够了没必要上多智能体。比如“先搜索再总结再翻译”这种流程用 LangGraph 的链式节点就能搞定。真正需要多智能体的情况是子任务之间需要动态协商或者需要多个视角的交叉验证或者子任务的执行顺序不是固定的而是根据中间结果动态决定的。比如“代码审查”场景你需要一个 Agent 从安全角度审查一个从性能角度审查一个从可读性角度审查最后还需要一个 Agent 来综合这些意见并做出最终判断。这种场景下多智能体的优势就非常明显了。注意不要为了用多智能体而用多智能体。我踩过最大的坑就是在一个简单的客服问答场景里上了多智能体结果延迟从 2 秒涨到了 15 秒用户流失率直接翻倍。后来改回单智能体加意图路由效果反而更好。2. 角色分工的设计方法论2.1 怎么拆角色从任务流到角色图角色分工是多智能体系统的地基地基没打好后面怎么调都是白搭。我总结了一套从任务流到角色图的拆解方法分三步走。第一步把整个任务流程画出来。不要管什么 Agent 不 Agent 的就用最原始的方式把用户输入到最终输出的每一步都写下来。比如“自动生成周报”这个任务流程是收集本周工作记录 → 分类整理 → 提取重点 → 生成周报文本 → 格式化输出。第二步识别哪些步骤需要“智能”。有些步骤是纯机械的比如格式化输出这种用代码做就行了不需要 Agent。真正需要 Agent 的是那些需要理解、判断、生成的步骤。在上面的例子里分类整理、提取重点、生成文本这三步需要 Agent。第三步把需要智能的步骤合并或拆分成角色。合并的原则是如果两个步骤用的是同一套上下文和同一套工具那就合并成一个 Agent。拆分的依据是如果两个步骤需要不同的系统提示词、不同的工具集或者需要独立校验那就拆成两个 Agent。按照这个方法“自动生成周报”最终的角色图是一个“信息整理 Agent”负责分类和提取重点一个“周报撰写 Agent”负责生成文本。两个 Agent 就够了不需要更多。2.2 角色定义的四个核心要素每个 Agent 的角色定义必须包含四个要素缺一不可。我用一个“代码审查 Agent”的例子来说明。角色名称和职责描述。名称要短职责描述要一句话说清楚。比如“安全审查员负责检查代码中的安全漏洞和风险点”。这个描述会直接进入系统提示词所以必须精准。输入输出规范。输入是什么格式输出是什么格式必须严格定义。安全审查员的输入是一段代码和相关的上下文信息输出是一个结构化的审查报告包含问题列表、严重等级、修复建议。这个规范不只是给开发者看的更要写进 Agent 的系统提示词里让它知道自己该接收什么、该产出什么。可用工具清单。每个 Agent 只给它完成自己任务所必需的工具。安全审查员需要的是代码解析工具、漏洞数据库查询工具不需要文件写入工具也不需要网页搜索工具。工具越少Agent 的决策越聚焦出错概率越低。行为约束和边界。这是最容易被忽略但最重要的一点。必须明确告诉 Agent 它不能做什么。比如安全审查员不能修改代码只能提出建议不能审查业务逻辑只关注安全层面。这些约束要写进系统提示词并且在代码层面做校验。2.3 角色之间的边界怎么划角色边界模糊是多智能体系统最常见的失败原因。两个 Agent 的职责有重叠结果要么互相推诿要么重复劳动要么产生冲突。我划边界的原则是每个决策点只能有一个 Agent 负责。如果一个决策需要多个 Agent 参与那就必须明确谁是最终决策者其他人只是提供输入。举个例子。在一个“产品需求分析”系统里有市场分析 Agent 和技术可行性 Agent。市场分析 Agent 说“这个功能很有市场”技术可行性 Agent 说“这个功能实现成本太高”。那到底做不做这个决策不能由这两个 Agent 中的任何一个来做必须有一个独立的“决策 Agent”来综合双方意见并做出判断。另一个原则是数据所有权要清晰。每个 Agent 只能修改自己负责的数据不能直接修改其他 Agent 的数据。如果 Agent A 需要修改 Agent B 的数据必须通过消息传递的方式请求 B 来修改。这样做的好处是数据变更可追溯出问题了容易定位。2.4 一个完整的角色分工案例我拿之前做过的一个“智能客服工单处理”系统来完整展示角色分工的设计。这个系统的任务是接收用户提交的工单自动分类、自动回复或转人工、自动归档。我设计了四个 Agent。分类 Agent职责是读取工单内容判断工单类型咨询、投诉、建议、故障报修和紧急程度。输入是工单文本输出是分类结果和置信度。工具只有一个分类模型 API。约束是置信度低于阈值时必须标记为“待人工确认”不能强行分类。知识检索 Agent职责是根据分类结果从知识库中检索相关的解决方案。输入是工单文本和分类结果输出是候选解决方案列表。工具是向量检索工具和知识库查询工具。约束是不能编造知识库中不存在的内容。回复生成 Agent职责是根据检索到的解决方案生成给用户的回复文本。输入是工单文本、分类结果、候选解决方案输出是回复文本。工具是文本生成工具和敏感词过滤工具。约束是回复必须包含解决方案不能只是安抚性话术。归档 Agent职责是工单处理完成后生成归档摘要并写入数据库。输入是完整的处理记录输出是归档摘要。工具是数据库写入工具和摘要生成工具。约束是归档摘要必须包含工单 ID、处理结果、处理时长。这四个 Agent 的边界非常清晰每个 Agent 的输入输出都是下一个 Agent 的输入形成了一条流水线。同时分类 Agent 的置信度机制和知识检索 Agent 的防编造机制保证了整个系统的可靠性。3. 协作机制的核心实现3.1 通信模式消息传递还是共享状态多智能体之间的通信有两种基本模式消息传递和共享状态。这两种模式各有优劣选错了会让整个系统变得难以维护。消息传递模式就像发邮件。Agent A 完成任务后把结果打包成消息发给 Agent BAgent B 收到消息后开始工作。这种模式的优点是解耦彻底每个 Agent 只需要知道自己的上游和下游是谁不需要关心整个系统的状态。缺点是消息格式需要严格定义而且消息丢失或格式错误会导致整个流程中断。共享状态模式就像白板。所有 Agent 都读写同一块状态区域Agent A 把结果写到状态里Agent B 从状态里读取。这种模式的优点是灵活Agent 可以随时获取全局信息。缺点是状态管理复杂多个 Agent 同时读写时容易产生竞态条件而且状态会越来越大最终变得不可维护。我的实践经验是主流程用消息传递辅助信息用共享状态。主流程的消息传递保证了流程的可靠性和可追溯性辅助信息的共享状态提供了必要的灵活性。在 LangGraph 里这两者可以很好地结合图的边传递消息图的状态State作为共享区域。3.2 用 LangGraph 搭建协作流程LangGraph 是目前搭建多智能体协作流程最顺手的框架之一。它的核心概念是“图”节点代表 Agent 或处理步骤边代表流转逻辑状态代表共享数据。我先说一下 LangGraph 和 LangChain 的区别因为很多人会搞混。LangChain 更偏向于“链式调用”适合线性的、确定性的流程。LangGraph 更偏向于“图计算”适合有分支、循环、条件跳转的复杂流程。多智能体系统天然就是图结构所以 LangGraph 是更合适的选择。下面是一个用 LangGraph 搭建多智能体协作流程的核心代码结构。我用一个“技术方案评审”的场景来举例包含三个 Agent方案撰写 Agent、技术评审 Agent、风险评估 Agent。from langgraph.graph import StateGraph, END from typing import TypedDict, Annotated import operator # 定义共享状态 class ReviewState(TypedDict): topic: str draft: str tech_review: str risk_review: str final_decision: str messages: Annotated[list, operator.add] # 定义各个 Agent 节点 def draft_agent(state: ReviewState): # 方案撰写 Agent 的逻辑 draft llm.invoke(f请撰写关于{state[topic]}的技术方案) return {draft: draft, messages: [(draft_agent, draft)]} def tech_review_agent(state: ReviewState): # 技术评审 Agent 的逻辑 review llm.invoke(f请从技术角度评审以下方案{state[draft]}) return {tech_review: review, messages: [(tech_review, review)]} def risk_review_agent(state: ReviewState): # 风险评估 Agent 的逻辑 review llm.invoke(f请从风险角度评审以下方案{state[draft]}) return {risk_review: review, messages: [(risk_review, review)]} def decision_agent(state: ReviewState): # 决策 Agent 的逻辑 decision llm.invoke( f综合以下评审意见做出最终决策\n f技术评审{state[tech_review]}\n f风险评估{state[risk_review]} ) return {final_decision: decision, messages: [(decision, decision)]} # 构建图 workflow StateGraph(ReviewState) workflow.add_node(draft, draft_agent) workflow.add_node(tech_review, tech_review_agent) workflow.add_node(risk_review, risk_review_agent) workflow.add_node(decision, decision_agent) # 定义边和流转逻辑 workflow.set_entry_point(draft) workflow.add_edge(draft, tech_review) workflow.add_edge(draft, risk_review) workflow.add_edge(tech_review, decision) workflow.add_edge(risk_review, decision) workflow.add_edge(decision, END) # 编译图 app workflow.compile()这段代码的关键点在于draft节点完成后同时触发tech_review和risk_review两个节点这两个节点并行执行都完成后才进入decision节点。这就是多智能体协作中典型的“扇出-扇入”模式。3.3 条件路由让流程根据中间结果动态调整上面的例子是确定性的流程但实际的多智能体系统往往需要根据中间结果动态决定下一步走哪条路。LangGraph 提供了条件边的机制来实现这个需求。我拿“智能客服工单处理”系统来举例。分类 Agent 完成分类后需要根据分类结果和置信度决定下一步如果置信度高且是咨询类走自动回复流程如果置信度低走人工确认流程如果是投诉类走升级流程。def route_after_classification(state: ReviewState): # 根据分类结果和置信度决定路由 if state[confidence] 0.7: return human_confirm elif state[category] complaint: return escalate else: return auto_reply workflow.add_conditional_edges( classify, route_after_classification, { human_confirm: human_confirm_node, escalate: escalate_node, auto_reply: auto_reply_node } )条件路由是多智能体系统实现“智能”的关键。没有条件路由多智能体就只是一条固定的流水线和传统的管道处理没有本质区别。有了条件路由系统才能根据实际情况做出不同的决策。3.4 循环与重试让 Agent 有机会修正错误多智能体系统里Agent 出错是常态。关键是要给 Agent 留出修正错误的机会。LangGraph 支持循环边可以让流程回到之前的节点重新执行。一个典型的场景是“代码生成-代码审查”循环。代码生成 Agent 生成代码后代码审查 Agent 进行审查。如果审查不通过流程回到代码生成 Agent让它根据审查意见修改代码。这个循环最多执行三次三次还不通过就转人工。def should_continue(state: ReviewState): if state[review_passed]: return end elif state[retry_count] 3: return human_intervention else: return regenerate workflow.add_conditional_edges( code_review, should_continue, { end: END, human_intervention: human_node, regenerate: code_gen } )这里有一个重要的经验循环必须有退出条件。我见过一个系统因为没有设置最大重试次数两个 Agent 互相认为对方有问题陷入了无限循环一晚上烧掉了几百美元的 API 费用。所以循环边一定要配一个计数器达到阈值就强制退出。3.5 Human-in-the-Loop什么时候需要人介入多智能体系统再智能也不能完全替代人。有些关键决策必须由人来做有些异常情况必须由人来处理。LangGraph 提供了 Human-in-the-Loop 的支持可以在流程中插入人工确认节点。需要人工介入的场景我总结为三类。第一类是高风险决策比如涉及资金、法律、安全的决策必须有人工确认。第二类是低置信度情况当 Agent 对自己的判断没有把握时应该转人工而不是强行决策。第三类是异常情况比如 Agent 连续失败、流程超时、数据异常等。实现 Human-in-the-Loop 的方式有两种。一种是同步阻塞流程暂停等待人工输入。这种方式适合实时性要求不高的场景。另一种是异步通知流程继续执行其他分支人工确认后再合并结果。这种方式适合实时性要求高的场景。from langgraph.checkpoint.sqlite import SqliteSaver # 使用检查点保存器支持中断和恢复 memory SqliteSaver.from_conn_string(:memory:) app workflow.compile( checkpointermemory, interrupt_before[human_confirm] ) # 执行到 human_confirm 节点前会暂停 # 人工确认后继续执行 app.invoke(None, config{configurable: {thread_id: 1}})提示Human-in-the-Loop 的节点设计要尽量轻量。我见过一个系统在每个 Agent 后面都加了人工确认结果整个流程变成了“人工为主、AI 为辅”完全失去了自动化的意义。人工确认应该只放在最关键的一两个节点上。4. 实战中的常见问题与排查技巧4.1 Agent 之间互相“踢皮球”怎么办这是多智能体系统最让人头疼的问题。Agent A 认为这件事该 Agent B 做Agent B 认为该 Agent A 做结果任务在两者之间来回传递永远得不到处理。根本原因通常是角色边界定义不清晰或者路由逻辑有漏洞。排查的时候我一般会先看消息日志找到任务在哪些 Agent 之间循环然后检查这些 Agent 的系统提示词看它们的职责描述是否有重叠或空白。解决方法有三个。第一在系统提示词里明确写“如果遇到不属于你职责范围的情况应该输出什么格式的转交请求”。第二在路由逻辑里加一个“最大转交次数”的限制超过次数就强制分配给某个 Agent 或转人工。第三在系统层面加一个“兜底 Agent”专门处理那些没有 Agent 愿意接的任务。4.2 上下文爆炸怎么控制每个 Agent 的输入长度多智能体系统里每个 Agent 的输入往往包含前序 Agent 的输出如果不加控制上下文会迅速膨胀。我见过一个系统到第五个 Agent 的时候输入已经超过 100K token 了成本和延迟都不可接受。控制上下文的核心原则是只传必要信息不传全部历史。每个 Agent 的输出应该是一个结构化的摘要而不是完整的对话记录。在 LangGraph 里可以通过自定义状态结构来实现这一点。具体做法是在状态里只保留每个 Agent 的关键输出字段不保留完整的消息历史。如果某个 Agent 确实需要历史信息就单独为它维护一个精简版的历史摘要。另外对于长文本输出可以在传给下一个 Agent 之前先做一次摘要压缩。4.3 一致性问题多个 Agent 的输出互相矛盾并行执行的 Agent 经常会产生矛盾的结果。比如技术评审 Agent 说“这个方案可行”风险评估 Agent 说“这个方案风险太高”。如果最后没有一个仲裁机制系统就不知道该怎么输出。解决这个问题的标准做法是引入一个“仲裁 Agent”或“决策 Agent”。这个 Agent 的职责不是重新做评审而是综合各方意见识别矛盾点然后做出最终判断。在系统提示词里要明确告诉仲裁 Agent你的任务是综合意见不是重新评审如果意见矛盾要分析矛盾的原因并给出你的判断依据。另一个技巧是让并行 Agent 的输出格式标准化。比如都输出“结论 置信度 关键理由”的三段式结构这样仲裁 Agent 在做综合时就有统一的输入格式处理起来更可靠。4.4 性能优化怎么让多智能体跑得更快多智能体系统的延迟通常是单智能体的数倍因为每个 Agent 都要调用一次 LLM。优化性能的核心思路是能并行的并行能缓存的缓存能跳过的跳过。并行的关键是识别哪些 Agent 之间没有依赖关系。比如“技术评审”和“风险评估”都只依赖“方案草稿”那它们就可以并行执行。在 LangGraph 里通过从同一个节点引出多条边来实现并行。缓存的关键是识别哪些 Agent 的输出是确定性的。比如“分类 Agent”对于相同的输入应该产生相同的输出那就可以加缓存。LangChain 提供了 LLM 缓存机制可以按提示词内容做缓存。跳过的关键是识别哪些 Agent 在当前情况下不需要执行。比如“知识检索 Agent”在分类结果是“投诉”时可能不需要执行因为投诉处理走的是另一条流程。通过条件路由来跳过不必要的 Agent可以显著降低延迟。4.5 常见问题速查表问题现象可能原因排查方法解决方案Agent 之间循环转交角色边界模糊查看消息日志中的转交记录明确职责描述加最大转交次数限制上下文超长传递了完整历史检查每个 Agent 的输入 token 数只传结构化摘要不传完整历史输出矛盾缺少仲裁机制对比并行 Agent 的输出引入仲裁 Agent标准化输出格式延迟过高串行执行过多分析各 Agent 的依赖关系并行化无依赖的 Agent加缓存Agent 卡死循环无退出条件检查循环边的退出逻辑加最大重试次数超限转人工输出格式错误提示词不够明确检查系统提示词中的格式要求在提示词中加输出示例代码层做校验4.6 我踩过的三个大坑第一个坑是过度设计。刚开始做多智能体的时候我恨不得把每个步骤都拆成一个 Agent结果一个简单的任务用了八个 Agent调试了两周才跑通效果还不如单智能体。后来我学乖了先用单智能体跑遇到瓶颈再拆每次只拆一个 Agent验证有效再继续拆。第二个坑是忽略错误处理。多智能体系统里任何一个 Agent 出错都会导致整个流程失败。我早期的一个系统没有做错误处理一个 Agent 的 API 调用超时整个流程就挂了。后来我在每个 Agent 节点都加了 try-catch出错时返回一个标准错误格式让路由逻辑决定是重试还是跳过。第三个坑是不做评估。多智能体系统的效果很难直观判断必须建立评估机制。我现在每个多智能体项目都会建一个测试集包含各种典型场景和边界情况每次修改后都跑一遍评估看通过率和输出质量的变化。没有评估优化就是盲人摸象。5. 从单智能体迁移到多智能体的实操路线5.1 迁移前的准备工作不要一上来就把单智能体拆成多智能体。迁移之前先做好三件事。第一建立评估基线。把当前单智能体版本在各种场景下的表现记录下来包括成功率、延迟、成本、输出质量评分。这是后续判断迁移是否有效的依据。第二梳理任务流程。把单智能体处理任务的过程拆解成清晰的步骤标注每一步的输入输出、所需工具、决策点。这个梳理结果就是后续角色分工的基础。第三识别瓶颈。分析单智能体版本在哪些环节最容易出错、最耗时、最不可控。这些瓶颈就是最需要拆分成独立 Agent 的地方。5.2 渐进式迁移的四个阶段我的迁移路线是渐进式的分四个阶段每个阶段都保证系统是可运行的。阶段一提取第一个 Agent。选择瓶颈最明显的一个环节把它从单智能体中拆出来变成一个独立的 Agent。其他部分保持不变。这个阶段的目标是验证多智能体架构的可行性同时积累经验。阶段二建立协作框架。引入 LangGraph 或其他编排框架把单智能体的剩余部分和第一个 Agent 连接起来。这个阶段的目标是跑通协作流程验证消息传递和状态管理是否可靠。阶段三逐步拆分剩余环节。按照优先级一个一个地把剩余环节拆成独立 Agent。每拆一个就做一次评估确保效果不下降。这个阶段可能会反复调整角色边界和路由逻辑。阶段四优化和调参。所有 Agent 都拆完之后开始做性能优化、错误处理、Human-in-the-Loop 等高级功能。这个阶段的目标是让系统达到生产可用的标准。5.3 迁移后的效果评估迁移完成后必须做一次全面的效果评估。评估的维度包括任务成功率、输出质量、延迟、成本、可维护性。我的经验是多智能体系统在任务成功率和输出质量上通常会有明显提升但延迟和成本也会增加。关键是要看提升是否值得增加的成本。如果成功率从 70% 提升到 90%但延迟从 3 秒增加到 10 秒那就要看业务场景是否能接受这个延迟。另外可维护性也是一个重要维度。多智能体系统的可维护性通常比单智能体好因为每个 Agent 的职责清晰修改一个 Agent 不会影响其他 Agent。但前提是角色边界定义得好否则可维护性反而会更差。5.4 一个真实的迁移案例最后分享一个我最近做的迁移案例。这是一个“合同审查”系统原来的单智能体版本需要审查合同的合规性、风险点、缺失条款。单智能体的问题是审查结果不稳定有时候漏掉重要风险点有时候又过度解读。迁移过程是这样的。首先我把审查任务拆成三个维度合规性审查、风险点识别、条款完整性检查。然后为每个维度设计一个独立的 Agent每个 Agent 有自己的系统提示词和检查清单。最后加了一个“综合报告 Agent”负责汇总三个维度的审查结果生成最终的审查报告。迁移后的效果风险点识别率从 65% 提升到 88%误报率从 20% 降低到 8%。延迟从 5 秒增加到 12 秒成本增加了约 2.5 倍。但考虑到合同审查的错误成本很高这个提升是完全值得的。这个案例让我深刻体会到多智能体的价值不在于技术本身有多先进而在于它能让每个环节都做到极致从而提升整体系统的可靠性。当你面对的是一个错误成本很高的任务时多智能体的投入产出比是非常可观的。