当单个 AI Agent 的能力边界开始显现,多智能体协作成为突破瓶颈的关键路径。LangGraph 作为 LangChain 生态中构建复杂 Agent 工作流的核心框架,提供了一套基于状态机的多智能体编排方案。本文将深入解析三种主流的多智能体协作模式,并探讨如何在实际项目中做出技术选型。
一、为什么需要多智能体架构 1.1 单 Agent 的能力瓶颈 在实际工程中,单个 Agent 面临的典型困境包括:
工具选择的认知负荷
当可用工具超过 15-20 个时,Agent 的工具选择准确率会显著下降。模型需要在每一步从庞大的工具集中做出决策,这不仅增加了延迟,还提高了错误调用的概率。
提示词复杂度的边际递减
试图在单个系统提示词中覆盖所有场景,往往导致指令互相干扰。开发者不断追加边界情况和示例,反而让模型更难抓住核心逻辑。
故障定位的困难
单 Agent 架构中,一次失败可能源于提示词、工具实现、模型能力或上下文管理的任何一个环节,排查成本极高。
1.2 多智能体的核心优势 LangGraph 团队总结的实践经验表明,多智能体设计在以下方面具有显著优势:
维度
单 Agent
多智能体
工具管理
集中式,选择复杂
分布式,各司其职
提示词设计
大而全,容易冲突
小而精,目标明确
故障隔离
牵一发而动全身
局部问题局部修复
可测试性
端到端黑盒
单元化可独立验证
扩展性
追加成本高
新增 Agent 低侵入
关键洞察在于:多智能体不是为了让更多 Agent 参与工作,而是为了让每个 Agent 专注于更少的事情 。
二、LangGraph 多智能体的三种架构模式 LangGraph 将多智能体工作流抽象为图结构:Agent 是节点,连接关系是边,共享状态是图的载体。基于这种抽象,衍生出三种典型的协作模式。
2.1 模式一:协作式多智能体(Collaboration) 这是最简单的多智能体形态,核心特征是共享记忆空间 。
架构设计 1 2 3 4 5 6 7 8 9 10 11 12 ┌─────────────────────────────────────────┐ │ Shared State (Messages) │ │ ┌─────────┐ ┌─────────┐ │ │ │ Agent A │◄──►│ Agent B │ │ │ │ (Coder) │ │(Reviewer)│ │ │ └────┬────┘ └────┬────┘ │ │ │ │ │ │ └──────┬───────┘ │ │ ▼ │ │ Router Node │ │ (Decide next agent) │ └─────────────────────────────────────────┘
两个或多个 Agent 操作同一个消息列表(scratchpad),每个 Agent 的思考和输出对其他 Agent 完全可见。
典型场景
结对编程 :Coder Agent 写代码,Reviewer Agent 实时审查
文档协作 :Writer Agent 起草,Editor Agent 润色
头脑风暴 :多个角色从不同角度分析同一问题
代码骨架 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 from langgraph.graph import StateGraph, MessagesStatefrom langchain_core.messages import SystemMessagecoder_prompt = """你是一个资深 Python 工程师。根据需求编写代码, 如果代码已完成,请回复 FINAL ANSWER。""" reviewer_prompt = """你是一个代码审查专家。检查代码的质量和潜在问题, 如果代码合格,请回复 FINAL ANSWER。""" def coder_node (state: MessagesState ): """Coder Agent 节点""" messages = state["messages" ] full_messages = [SystemMessage(content=coder_prompt)] + messages response = llm.invoke(full_messages) return {"messages" : [response]} def reviewer_node (state: MessagesState ): """Reviewer Agent 节点""" messages = state["messages" ] full_messages = [SystemMessage(content=reviewer_prompt)] + messages response = llm.invoke(full_messages) return {"messages" : [response]} def router (state: MessagesState ): """路由决策:根据最后一条消息决定下一步""" last_message = state["messages" ][-1 ].content if "FINAL ANSWER" in last_message: return END elif state["messages" ][-1 ].name == "coder" : return "reviewer" else : return "coder" builder = StateGraph(MessagesState) builder.add_node("coder" , coder_node) builder.add_node("reviewer" , reviewer_node) builder.add_conditional_edges("coder" , router) builder.add_conditional_edges("reviewer" , router) builder.set_entry_point("coder" ) graph = builder.compile ()
优缺点分析 优点 :
实现简单,无需复杂的状态同步机制
信息透明,便于调试和追踪
缺点 :
上下文膨胀:所有历史消息被反复传递
缺乏隐私性:Agent 无法拥有”内部思考”空间
扩展性受限:Agent 数量增加后状态管理混乱
2.2 模式二:Supervisor 模式 Supervisor 模式引入了一个中央协调者,核心特征是独立工作空间 + 统一调度 。
架构设计 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 ┌─────────────────┐ │ Supervisor │ │ (Router Agent) │ └────────┬────────┘ │ ┌────────────────────┼────────────────────┐ │ │ │ ▼ ▼ ▼ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │ Research │ │ Writer │ │ Coder │ │ Agent │ │ Agent │ │ Agent │ │ │ │ │ │ │ │ Own scratchpad│ │ Own scratchpad│ │ Own scratchpad│ │ Own tools │ │ Own tools │ │ Own tools │ └───────┬───────┘ └───────┬───────┘ └───────┬───────┘ │ │ │ └────────────────────┼────────────────────┘ ▼ ┌─────────────────┐ │ Shared State │ │ (Final outputs) │ └─────────────────┘
每个 Worker Agent 拥有独立的提示词、工具和内部状态,仅将最终输出提交到共享空间。Supervisor 负责决策下一个由哪个 Agent 执行。
Supervisor 的本质 Supervisor 本身也是一个 Agent,只是它的”工具”是其他 Agent。这种设计体现了分层抽象的思想:
1 2 3 4 5 6 7 8 9 10 11 worker_tools = [ Tool(name="research" , func=research_agent.invoke, description="搜索和整理信息" ), Tool(name="write" , func=writer_agent.invoke, description="撰写和编辑内容" ), Tool(name="code" , func=coder_agent.invoke, description="编写和测试代码" ) ] supervisor = create_react_agent(llm, worker_tools)
典型场景
内容生产流水线 :Research → Write → Edit → Publish
软件开发流程 :PM → Architect → Coder → Reviewer → Tester
客户服务 : triage → technical → billing → escalation
代码实现要点 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 from typing import TypedDict, Annotatedfrom langgraph.graph import StateGraphfrom langgraph.graph.message import add_messagesclass TeamState (TypedDict ): """团队共享状态""" messages: Annotated[list , add_messages] next_agent: str task_count: int def supervisor_node (state: TeamState ): """Supervisor Agent 决定下一步""" members = ["researcher" , "writer" , "coder" ] system_prompt = f"""你是团队主管,负责协调以下成员:{members} 。 根据当前任务状态,选择最合适的成员执行下一步工作。 如果任务完成,回复 FINISH。""" messages = [SystemMessage(content=system_prompt)] + state["messages" ] response = llm.with_structured_output(RouterDecision).invoke(messages) return {"next_agent" : response.next } def agent_node (state: TeamState, agent_name: str , agent_runnable ): """通用 Agent 节点包装器""" agent_output = agent_runnable.invoke(state["messages" ]) return { "messages" : [{ "role" : "assistant" , "content" : agent_output, "name" : agent_name }], "task_count" : state.get("task_count" , 0 ) + 1 } builder = StateGraph(TeamState) builder.add_node("supervisor" , supervisor_node) builder.add_node("researcher" , lambda s: agent_node(s, "researcher" , research_agent)) builder.add_node("writer" , lambda s: agent_node(s, "writer" , writer_agent)) builder.add_node("coder" , lambda s: agent_node(s, "coder" , coder_agent)) builder.add_conditional_edges( "supervisor" , lambda x: x["next_agent" ], {"researcher" : "researcher" , "writer" : "writer" , "coder" : "coder" , "FINISH" : END} ) for worker in ["researcher" , "writer" , "coder" ]: builder.add_edge(worker, "supervisor" ) builder.set_entry_point("supervisor" )
优缺点分析 优点 :
清晰的职责边界,每个 Agent 专注特定领域
可独立优化和测试每个 Agent
Supervisor 可以基于任务状态做智能决策
缺点 :
需要设计 Supervisor 的决策逻辑
Worker Agent 之间缺乏直接通信
可能存在 Supervisor 单点瓶颈
2.3 模式三:层级化团队(Hierarchical Teams) 层级化团队是 Supervisor 模式的扩展,支持嵌套子图 和递归委托 。
架构设计 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 ┌─────────────────────────────────────────┐ │ Top-Level Supervisor │ │ (Strategic Coordinator) │ └─────────────────┬───────────────────────┘ │ ┌─────────────┼─────────────┐ │ │ │ ▼ ▼ ▼ ┌────────┐ ┌────────────┐ ┌──────────┐ │ Data │ │ Writing │ │ Coding │ │ Team │ │ Team │ │ Team │ │ (Graph)│ │ (Graph) │ │ (Graph) │ └────┬───┘ └─────┬──────┘ └────┬─────┘ │ │ │ ┌──┴──┐ ┌────┴────┐ ┌────┴────┐ │W1 W2│ │ W1 W2 │ │ W1 W2 │ └─────┘ └─────────┘ └─────────┘
每个”团队”本身就是一个完整的 LangGraph,拥有自己的 Supervisor 和 Workers。顶层 Supervisor 不需要关心子团队的内部实现。
核心创新:子图作为节点 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 from langgraph.graph import StateGraphwriting_builder = StateGraph(TeamState) writing_builder.add_node("writer" , writer_agent) writing_builder.add_node("editor" , editor_agent) writing_builder.add_node("proofreader" , proofreader_agent) writing_team = writing_builder.compile () coding_builder = StateGraph(TeamState) coding_builder.add_node("architect" , architect_agent) coding_builder.add_node("coder" , coder_agent) coding_builder.add_node("tester" , tester_agent) coding_team = coding_builder.compile () top_builder = StateGraph(State) top_builder.add_node("orchestrator" , orchestrator_node) top_builder.add_node("writing_team" , writing_team) top_builder.add_node("coding_team" , coding_team) top_builder.add_conditional_edges( "orchestrator" , route_to_team, {"writing" : "writing_team" , "coding" : "coding_team" , "FINISH" : END} )
典型场景
大型项目交付 :每个职能团队(产品、设计、开发、测试)是一个子图
多领域研究 :科学计算、文献调研、实验设计各自由专业团队处理
企业自动化 :HR、财务、IT 等部门作为独立子图,由中央协调
层级化的价值
复杂性封装 :顶层只需要知道”写作团队能产出文档”,无需了解内部流程
递归委托 :子团队的 Supervisor 可以继续向下委托
独立演进 :子团队可以独立优化,不影响其他团队
可复用性 :写作团队可以被多个上层流程复用
三、模式选型决策框架 3.1 决策树 1 2 3 4 5 6 7 8 9 10 11 12 13 开始 │ ├─ Agent 数量 ≤ 2,且需要紧密协作? │ └─ YES → 协作式(Collaboration) │ ├─ 任务有明确的阶段划分? │ └─ YES → Supervisor 模式 │ ├─ 涉及多个专业领域,需要领域专家? │ └─ YES → 层级化团队(Hierarchical) │ └─ 小规模 PoC,快速验证? └─ YES → 协作式
3.2 量化评估指标
评估维度
协作式
Supervisor
层级化
实现复杂度
⭐⭐
⭐⭐⭐
⭐⭐⭐⭐⭐
可扩展性
⭐⭐
⭐⭐⭐⭐
⭐⭐⭐⭐⭐
调试难度
⭐⭐⭐
⭐⭐
⭐⭐⭐
团队并行度
⭐⭐⭐⭐
⭐⭐⭐
⭐⭐⭐⭐⭐
容错能力
⭐⭐
⭐⭐⭐
⭐⭐⭐⭐
3.3 实际选型建议 选择协作式模式当 :
快速原型验证
Agent 之间确实需要高频信息交换
上下文长度可控(<4K tokens)
选择 Supervisor 模式当 :
任务流程相对固定
需要清晰的阶段边界
团队规模 3-5 个 Agent
选择层级化团队当 :
涉及多个专业领域
需要团队级别的复用
项目规模大,需要分层治理
四、工程实践要点 4.1 状态设计最佳实践 多智能体系统的状态设计是关键架构决策:
1 2 3 4 5 6 7 8 9 10 11 12 class GlobalState (TypedDict ): """全局共享状态""" messages: Annotated[list , add_messages] task_history: list final_output: str class AgentInternalState (TypedDict ): """Agent 内部状态(不共享)""" scratchpad: list tool_calls: list retry_count: int
4.2 循环控制与终止条件 多智能体系统容易产生无限循环,必须设计可靠的终止机制:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 from langgraph.graph import ENDdef check_termination (state: State ): """多重终止条件检查""" if state.get("is_complete" ): return END if state.get("iteration_count" , 0 ) > 10 : state["termination_reason" ] = "MAX_ITERATION" return END if detect_no_progress(state): state["termination_reason" ] = "NO_PROGRESS" return END return "continue"
4.3 错误处理与降级策略 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 class AgentExecutionError (Exception ): """Agent 执行错误""" pass def agent_node_with_fallback (state: State, agent_name: str ): """带降级策略的 Agent 节点""" try : result = agent_runnable.invoke(state) return {"messages" : [result], "error" : None } except ToolExecutionError as e: return { "messages" : [], "error" : {"type" : "tool_error" , "agent" : agent_name, "detail" : str (e)} } except LLMRateLimitError as e: return { "messages" : [], "error" : {"type" : "rate_limit" , "retry_after" : e.retry_after} } except Exception as e: logger.error(f"Agent {agent_name} failed: {e} " ) return { "messages" : [{"role" : "assistant" , "content" : "任务执行遇到技术问题,请稍后重试。" }], "error" : {"type" : "unknown" , "detail" : str (e)} }
4.4 可观测性设计 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 from langsmith import traceable@traceable(name="multi_agent_orchestrator" ) def run_multi_agent_workflow (input_query: str ): """可追踪的多智能体工作流执行""" logger.info(f"Starting workflow for: {input_query} " ) initial_state = {"messages" : [{"role" : "user" , "content" : input_query}]} for event in graph.stream(initial_state): node_name = list (event.keys())[0 ] node_output = event[node_name] logger.info(f"Node {node_name} completed" , extra={ "node" : node_name, "output_length" : len (str (node_output)), "timestamp" : time.time() }) if node_name == "critical_decision" : human_approval = request_human_approval(node_output) if not human_approval: break return event
五、从理论到实践:完整示例 以下是一个基于 Supervisor 模式的完整研究助手实现:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 """ 多智能体研究助手:Researcher + Writer + FactChecker """ from typing import TypedDict, Annotated, Literal from langgraph.graph import StateGraph, ENDfrom langgraph.graph.message import add_messagesfrom langchain_core.messages import SystemMessage, HumanMessagefrom langchain_openai import ChatOpenAIfrom langchain_community.tools import DuckDuckGoSearchRunclass ResearchState (TypedDict ): messages: Annotated[list , add_messages] research_notes: str draft: str final_report: str next : Literal ["researcher" , "writer" , "fact_checker" , "FINISH" ] search_tool = DuckDuckGoSearchRun() llm = ChatOpenAI(model="gpt-4" ) def researcher_node (state: ResearchState ): """研究 Agent:搜索并整理信息""" prompt = """你是一个专业的研究助理。根据用户的问题,搜索相关信息并整理成结构化的笔记。 重点关注:核心事实、数据来源、不同观点。 使用搜索工具获取最新信息。""" messages = [SystemMessage(content=prompt)] + state["messages" ] research_llm = llm.bind_tools([search_tool]) response = research_llm.invoke(messages) if response.tool_calls: search_results = search_tool.invoke(response.tool_calls[0 ]["args" ]) summary_prompt = f"基于以下搜索结果,整理研究笔记:\n{search_results} " summary = llm.invoke([HumanMessage(content=summary_prompt)]) return { "research_notes" : summary.content, "messages" : [{"role" : "assistant" , "content" : summary.content}], "next" : "writer" } return { "research_notes" : response.content, "messages" : [response], "next" : "writer" } def writer_node (state: ResearchState ): """写作 Agent:基于研究结果撰写报告""" prompt = f"""你是一个技术报告撰写专家。基于以下研究笔记,撰写一份清晰的分析报告。 研究笔记: {state.get('research_notes' , '' )} 要求: - 结构清晰(背景、分析、结论) - 语言简洁专业 - 保持客观中立""" messages = [SystemMessage(content=prompt)] + state["messages" ] response = llm.invoke(messages) return { "draft" : response.content, "messages" : [response], "next" : "fact_checker" } def fact_checker_node (state: ResearchState ): """事实核查 Agent:检查报告中的事实准确性""" prompt = f"""你是一个严谨的事实核查员。检查以下报告中的关键事实声明, 标记任何需要验证或存疑的内容。 报告内容: {state.get('draft' , '' )} 如果发现重大问题,回复 "NEEDS_REVISION:<具体问题>"; 如果基本准确,回复 "APPROVED"。""" response = llm.invoke([HumanMessage(content=prompt)]) content = response.content if content.startswith("NEEDS_REVISION" ): return { "messages" : [response], "next" : "writer" } else : return { "final_report" : state["draft" ], "messages" : [response], "next" : "FINISH" } def supervisor_node (state: ResearchState ): """Supervisor:简单路由,实际可由 LLM 决策""" return {"next" : state.get("next" , "researcher" )} builder = StateGraph(ResearchState) builder.add_node("supervisor" , supervisor_node) builder.add_node("researcher" , researcher_node) builder.add_node("writer" , writer_node) builder.add_node("fact_checker" , fact_checker_node) builder.add_conditional_edges( "supervisor" , lambda x: x["next" ], { "researcher" : "researcher" , "writer" : "writer" , "fact_checker" : "fact_checker" , "FINISH" : END } ) builder.add_edge("researcher" , "supervisor" ) builder.add_edge("writer" , "supervisor" ) builder.add_edge("fact_checker" , "supervisor" ) builder.set_entry_point("supervisor" ) app = builder.compile () if __name__ == "__main__" : result = app.invoke({ "messages" : [{"role" : "user" , "content" : "分析 LangGraph 在多智能体系统中的应用场景" }], "research_notes" : "" , "draft" : "" , "final_report" : "" }) print ("=== 最终报告 ===" ) print (result["final_report" ])
六、与上午主题的呼应:从安全到协作 上午的《AI Agent 安全沙箱》关注的是”如何让 Agent 安全运行”,本文探讨的是”如何让多个 Agent 高效协作”——两者共同构成了企业级 Agent 系统的两大支柱。
安全沙箱 决定了 Agent 的能力边界 (能做什么、不能做什么),多智能体架构 决定了 Agent 系统的复杂度上限 (能解决多复杂的问题)。
在实践中,两者必须结合考虑:
权限分层 :Supervisor 和 Worker 应该有不同的权限级别
通信安全 :Agent 间的状态传递需要加密和校验
审计追踪 :多智能体系统的决策路径必须可审计
隔离边界 :层级化团队天然提供了故障隔离边界
七、总结与展望 LangGraph 提供的三种多智能体模式——协作式、Supervisor、层级化团队——覆盖了从简单任务到复杂系统的全场景需求。选型时应当遵循”从简单开始,按需演进”的原则:
先验证单 Agent 边界 :确认问题确实需要多智能体
从协作式开始 :快速验证核心价值
演进为 Supervisor :引入清晰的流程控制
最终走向层级化 :支持大规模复杂系统
随着 Agent 技术的成熟,多智能体系统将从一个技术概念演变为企业软件的标准架构模式。掌握 LangGraph 的设计思想,就是在为未来的软件工程范式做准备。
参考资源 :
研究收获 :
多智能体的核心价值在于”分工”而非”人多力量大”
三种模式的选择应基于任务特性而非技术偏好
层级化团队是未来大规模 Agent 系统的标准架构
可观测性和错误处理是多智能体系统的关键工程挑战