多智能体协作四大架构模式：Subagents/Skills/Handoffs/Router完全指南

← 上一篇AI大模型3月终局商业化转向、智能体崛起与安全红线→ 下一篇大模型推理加速2026从500ms到80ms的完整优化路径摘要当单个 AI Agent 无法高效处理复杂任务时多智能体系统Multi-Agent System, MAS成为解决方案。2026 年以 LangGraph 为代表的框架已将四种核心架构模式标准化Subagents中央编排、Skills按需加载、Handoffs状态移交、Router并行分发。本文基于最新工程实践eastondev.com2026-03-25深度解析四种模式的原理、代码实现与生产级优化策略帮助开发者做出准确的架构决策。核心结论多智能体架构的本质是对任务空间进行合理分解而非堆砌 Agent 数量。正确选型可使 Token 消耗降低 67%错误选型则会引入协调税Coordination Tax——管理 Agent 的成本超过任务本身。控制 Agent 数量在 5 个以内是当前生产环境的最佳实践。什么是多智能体系统MAS多智能体系统Multi-Agent SystemMAS是指由多个具备感知、推理、行动能力的 AI Agent 组成的协作网络。每个 Agent 负责完成特定的子任务通过消息传递、状态共享或工具移交与其他 Agent 协作共同解决单个 Agent 难以处理的复杂问题。区别于单体模型直接调用MAS 在任务分解、并行执行和角色专业化方面具有显著优势。一、架构模式总览在深入每种模式之前先从全局视角了解四种模式的差异模式核心机制并行能力Token 消耗适用场景Subagents子代理主 Agent 协调多个专业子 Agent高高多领域独立任务并行处理Skills技能单 Agent 按需切换提示词技能中低单线程多阶段顺序任务Handoffs移交多 Agent 顺序接力状态无中多阶段对话流程需保留上下文Router路由路由 Agent 并行分发综合结果高高多数据源聚合查询二、Subagents 模式中央编排2.1 架构原理Subagents 是最常见的多智能体架构核心思想是主 Agent 作为协调者多个专业子 Agent 作为工具执行。用户请求 ↓ 主 Agent协调者 ├── 订单 Agent处理订单相关 ├── 退款 Agent处理退款申请 └── 投诉 Agent处理用户投诉2.2 LangGraph 代码实现fromlanggraph.prebuiltimportcreate_react_agentfromlangchain_anthropicimportChatAnthropic llmChatAnthropic(modelclaude-3-5-sonnet-20241022)# Step 1定义专业子 Agentorder_agentcreate_react_agent(modelllm,tools[query_order,update_order],prompt你是订单专家只处理订单查询和修改相关问题。)refund_agentcreate_react_agent(modelllm,tools[check_refund_policy,process_refund],prompt你是退款专家只处理退款申请和政策查询。)complaint_agentcreate_react_agent(modelllm,tools[log_complaint,escalate_issue],prompt你是投诉处理专家负责记录和升级用户投诉。)# Step 2主 Agent 将子 Agent 作为工具main_agentcreate_react_agent(modelllm,tools[order_agent,refund_agent,complaint_agent],prompt你是客服总管根据用户问题类型分发给合适的专家 - 订单问题 → order_agent - 退款问题 → refund_agent - 投诉问题 → complaint_agent )# Step 3执行responsemain_agent.invoke({messages:[{role:user,content:我的订单 ORD-001 还没到我要退款}]})2.3 适用场景与注意事项最佳场景客服系统、多领域知识问答、复杂工作流自动化关键风险子 Agent 数量超过 5 个时主 Agent 的路由决策准确率下降且 Token 消耗线性增长。建议严格限制子 Agent 数量。三、Skills 模式按需加载3.1 架构原理Skills 模式的核心是单一 Agent 通过动态加载不同的提示词技能文件来实现多角色功能本质上是提示工程的工程化管理。用户请求写一个函数并生成文档 ↓ 单一 Agent ├── 加载 code_review.md → 完成代码审查 ├── 切换 doc_writer.md → 生成文档 └── 切换 security_audit.md → 安全审计3.2 实现代码importosfrompathlibimportPath# Skills 目录结构# skills/# ├── code_review.md # 代码审查提示词# ├── doc_writer.md # 文档生成提示词# └── security_audit.md # 安全审计提示词defload_skill(skill_name:str)-str:动态加载技能提示词skill_pathPath(fskills/{skill_name}.md)ifnotskill_path.exists():raiseValueError(fSkill {skill_name} not found)returnskill_path.read_text(encodingutf-8)defcreate_skilled_agent(skill_name:str):创建具备特定技能的 Agentskill_promptload_skill(skill_name)returncreate_react_agent(modelllm,tools[read_file,write_file,run_tests],promptskill_prompt)# 使用示例多阶段代码处理流水线defprocess_code(code:str):stages[code_review,doc_writer,security_audit]results{}forstageinstages:agentcreate_skilled_agent(stage)resultagent.invoke({messages:[{role:user,content:code}]})results[stage]resultreturnresults3.3 优势与局限核心优势Token 消耗最低比 Subagents 节省约 67%适合需要用户直接交互的对话场景。核心局限无法真正并行执行各阶段必须顺序完成适合流水线而非并发任务。四、Handoffs 模式状态移交4.1 架构原理Handoffs 是专为多阶段对话流程设计的模式每个 Agent 负责一个阶段完成后将完整的状态移交给下一个 Agent。这种模式最适合需要保留完整对话上下文的客服、咨询类场景。问题分拣 Agent → 诊断专家 Agent → 方案制定 Agent → 确认回访 Agent 收集信息 分析根因 提供解决方案 确认解决4.2 代码实现fromlangchain_core.toolsimporttoolfromlanggraph.graphimportStateGraph,MessagesState,ENDtooldefhandoff_to_diagnosis(issue_summary:str)-str:将收集到的问题移交给诊断专家。 Args: issue_summary: 问题摘要包含用户描述和初步分类 returnf[移交给诊断专家] 接收问题{issue_summary}tooldefhandoff_to_solution(diagnosis_result:str)-str:将诊断结果移交给方案制定专家。 Args: diagnosis_result: 诊断结果包含根本原因分析 returnf[移交给方案专家] 诊断结果{diagnosis_result}tooldefhandoff_to_callback(solution:str)-str:将解决方案移交给回访专员确认问题是否解决。returnf[移交给回访专员] 已提供方案{solution}# 定义各阶段 Agenttriage_agentcreate_react_agent(modelllm,tools[handoff_to_diagnosis],prompt你是问题分拣员收集用户问题详情整理摘要后移交诊断专家。)diagnosis_agentcreate_react_agent(modelllm,tools[search_knowledge_base,handoff_to_solution],prompt你是诊断专家分析问题根本原因制定诊断报告后移交方案专家。)solution_agentcreate_react_agent(modelllm,tools[get_solutions,handoff_to_callback],prompt你是方案专家根据诊断结果提供具体解决方案移交回访专员跟进。)4.3 状态保持的关键技巧Handoffs 模式的核心挑战是在 Agent 切换时完整保留对话历史。推荐使用MessagesState统一管理状态而非在工具参数中手工传递上下文否则容易造成信息丢失。五、Router 模式并行分发5.1 架构原理Router 是四种模式中并行化能力最强的适合需要同时查询多个数据源并综合结果的场景。用户查询 ↓ Router Agent解析意图 ├──→ 内部文档 Agent并行 ├──→ 外部 API Agent并行 └──→ 数据库 Agent并行 ↓ Synthesize Agent综合三路结果 ↓ 最终回答5.2 LangGraph 并行图实现fromtypingimportTypedDict,Annotated,Listfromlanggraph.graphimportStateGraph,ENDimportasyncioclassRouterState(TypedDict):query:strinternal_results:List[str]external_results:List[str]db_results:List[str]final_answer:strasyncdefroute_query(state:RouterState)-dict:路由分析解析查询意图不做过滤让并行节点各自处理return{query:state[query]}asyncdefquery_internal_docs(state:RouterState)-dict:查询内部知识库resultsawaitinternal_search(state[query])return{internal_results:results}asyncdefquery_external_api(state:RouterState)-dict:调用外部 API 获取实时数据resultsawaitexternal_api_call(state[query])return{external_results:results}asyncdefquery_database(state:RouterState)-dict:查询业务数据库resultsawaitdb_query(state[query])return{db_results:results}asyncdefsynthesize_results(state:RouterState)-dict:综合三路结果生成最终回答all_data{内部文档:state.get(internal_results,[]),外部数据:state.get(external_results,[]),数据库:state.get(db_results,[]),}synthesis_promptf 用户问题{state[query]}可用数据来源{all_data}请综合以上数据源给出准确、完整的回答。 responseawaitllm.ainvoke(synthesis_prompt)return{final_answer:response.content}# 构建并行执行图graphStateGraph(RouterState)graph.add_node(router,route_query)graph.add_node(internal,query_internal_docs)graph.add_node(external,query_external_api)graph.add_node(database,query_database)graph.add_node(synthesize,synthesize_results)# 设置路由到三路并行graph.set_entry_point(router)graph.add_edge(router,internal)graph.add_edge(router,external)graph.add_edge(router,database)# 三路并行后汇聚到综合节点graph.add_edge(internal,synthesize)graph.add_edge(external,synthesize)graph.add_edge(database,synthesize)graph.add_edge(synthesize,END)appgraph.compile()# 执行查询resultawaitapp.ainvoke({query:最近30天销售额及行业趋势分析,internal_results:[],external_results:[],db_results:[],final_answer:})六、生产级优化避免三类常见陷阱陷阱 1状态竞态条件问题多个 Agent 并行写入同一状态键时后写入的会覆盖先写入的结果。解决方案为每个 Agent 分配专属状态键。classSafeMultiAgentState(MessagesState):# 每个 Agent 有专属状态键避免互相覆盖security_result:str# 安全 Agent 专用style_result:str# 风格 Agent 专用perf_result:str# 性能 Agent 专用asyncdefsecurity_agent(state:SafeMultiAgentState):resultawaitanalyze_security(state[messages])return{security_result:result}# 只写自己的键asyncdefstyle_agent(state:SafeMultiAgentState):resultawaitcheck_style(state[messages])return{style_result:result}# 只写自己的键陷阱 2无限循环问题Agent 之间相互调用产生循环消耗大量 Token。解决方案强制设置迭代上限。# LangGraph 全局迭代限制appgraph.compile()resultawaitapp.ainvoke(input_state,config{recursion_limit:10}# 最多 10 次迭代)# 或在 Agent 级别设置agentcreate_react_agent(modelllm,toolstools,max_iterations3# 单个 Agent 最多 3 次工具调用)陷阱 3协调税过高问题Agent 数量太多主 Agent 花费大量 Token 在协调和路由决策上反而降低效率。解决方案控制 Agent 数量用 Subagents 数量与 Token 消耗的关系图指导决策。Agent 数量协调 Token 占比推荐场景1-210%简单任务Skills/Handoffs 足够3-510-25%最佳范围各模式均可6-1025-50%高并行需求须评估成本1050%不推荐考虑任务重新分解七、架构选型决策树任务是否需要多角色分工 ├── 否 → 单 Agent 足够无需 MAS └── 是 ↓ 角色之间是否需要并行执行 ├── 否顺序执行 │ ├── 需要保留完整对话上下文 │ │ ├── 是 → Handoffs 模式 │ │ └── 否 → Skills 模式 └── 是并行执行 ├── 有一个明确的主控 Agent │ ├── 是 → Subagents 模式 │ └── 否需要合并多路结果→ Router 模式FAQQ1多智能体系统一定比单 Agent 更好吗A不是。多智能体系统引入了额外的协调成本Token 消耗增加、延迟增加、调试难度上升。只有当任务确实可以被分解为多个独立子任务且并行或专业化执行能带来明显收益时才值得使用 MAS。Q2LangGraph 和 AutoGen 的多智能体框架该选哪个ALangGraph 以其细粒度的状态管理和可视化调试能力在工程实践中更受欢迎适合生产环境。AutoGen 在研究场景下更灵活但生产级控制能力较弱。2026 年主流选择是 LangGraph。Q3如何测试多智能体系统的可靠性A推荐三层测试策略1单 Agent 单元测试验证每个 Agent 的专业能力2双 Agent 集成测试验证移交和通信正确3全链路端到端测试使用模拟的外部工具响应验证整体行为符合预期。Q4Router 模式的并行 Agent 超时怎么处理A设置单 Agent 超时限制超时后返回空结果并标记来源让 Synthesize Agent 在数据不完整的情况下仍能生成有用的回答。不要因单路失败而阻塞整体流程。← 上一篇AI大模型3月终局商业化转向、智能体崛起与安全红线→ 下一篇大模型推理加速2026从500ms到80ms的完整优化路径参考资料eastondev.com,《多智能体协作实战4种架构模式选择指南》, 2026-03-25LangGraph 官方文档,《Multi-Agent Systems》, LangChain, 2026微信公众号程序员说,《Agent智能体之2026 一文掌握 AI Agent全部技术栈》, 2026-03-02n1n.ai,《2026年开发者必须掌握的5种AI Agent设计模式》, 2026-03-21中科算网,《2026年AI Agent智能体技术发展报告》85页, 2026-02qubittool.com,《多智能体系统完全指南2026》, 2026-02-21