尧图网站建设 
LangGraph 做 Multi-Agent其实没有你想的那么玄乎但也不是简单地调几个库就能搞定。最近我把几个真实的 Multi-Agent 项目用 LangGraph 重构了一遍踩了一圈坑之后想把这套框架的底层逻辑、典型案例和实操细节完整拆出来。这篇文章不端着直接以案例为主线从架构设计到踩坑记录给你一条可以照抄的落地路径。如果你是第一次接触 LangGraph 和 Multi-Agent或者已经写过几个 Agent 但总感觉协作逻辑拧巴那这篇应该能帮到你。LangGraph 本质上是一个基于图结构的 Agent 编排框架它把传统的 Agent 循环调用 LLM - 执行工具 - 再调用 LLM拆成节点、边和状态三个核心要素。多智能体Multi-Agent在这个框架里不再是简单地把多个 Agent 塞在一起而是通过图拓扑去定义它们之间的通信、路由和共享状态。这就解决了一个以前很头疼的问题多个 Agent 各自为战、互相抢上下文、数据流混乱。LangGraph 的好处在于它让你把“智能”交给 LLM但把“流程控制”牢牢握在自己手里这非常关键。因为生产环境里的多智能体系统最怕的就是失控。以下所有案例都能在 LangGraph 最新的 0.2.x 版本上跑通代码基于 Python我会标明每段代码的作用和关键参数。别急先从设计思路讲起。1. 整体设计为什么用 LangGraph 来搭 Multi-Agent1.1 先想清楚 Multi-Agent 不是“多个 Agent 的堆叠”很多人一听到 Multi-Agent第一反应是“我有多个任务所以我有多个 Agent每个 Agent 负责一个任务”。这个理解不能说错但很容易把系统做成接口调用而不是一个有机协作的团队。真正的 Multi-Agent 系统核心在于 Agent 之间需要共享上下文、需要路由决策、需要授权调用、需要异常回退、需要合并结果。这些需求在 LangGraph 里对应的就是节点、边、状态、条件分支和 checkpointer。举个我自己的例子。之前我做一个行业研究报告生成系统最初拆成了三个独立的 Agent数据采集 Agent、分析 Agent、写作 Agent。每个 Agent 通过 HTTP 调用串联后一个 Agent 拿前一个 Agent 的输出作为输入。跑起来就发现几个问题数据采集 Agent 返回的 JSON 结构不稳定分析 Agent 经常解析失败。分析 Agent 如果需要补查数据没法自己回头调用采集 Agent只能抛出异常让上层服务去协调。改写阶段没法看到中间推理过程出问题很难定位。换成 LangGraph 之后我把这三个“模型”变成了三个“节点”用图结构让分析 Agent 可以动态决定是否重新调用数据采集节点。整个系统的状态由一个统一的 State 对象管理每个节点读写 State 中的某个字段传输和解析的契约终于在同一个框架内收敛了。这就是 Multi-Agent 的“多”不是在数量上多而是在协作模式上多。1.2 LangGraph 与主流编排方案的选型对比现在市面上的 Agent 编排方案很多我简单拉一张表不是要否定谁而是为了让选型有依据。方案运行模型状态管理复杂流程支持LangChain 集成学习曲线典型场景LangGraph图结构 Pregel 风格显式 State Reducer支持循环、条件分支、并行、多 Agent原生集成中复杂业务流、生产级系统AutoGen对话驱动会话历史通过群聊、发言顺序控制需要额外适配中低多角色对话研究CrewAI角色 任务列表任务输出聚合任务依赖Pipeline 为主有但相对轻量低快速搭建、简单协作手写 Pipeline代码硬编无每次改动要改代码无高维护简单一次性脚本我当时选 LangGraph核心就看中两点第一它天然支持循环。多智能体系统里最常见的协作模式是“A 想了之后告诉 BB 缺信息再回头找 A”这种循环用 Pipeline 写要反复设计回调但在图里只是一条从 B 回到 A 的边。第二它的 State 可序列化且支持 Checkpointer这意味着每个 Agent 都能看到全局上下文而且能在任意节点断点恢复排障能力极强。如果你只是做一次性 demoCrewAI 确实更爽但要做到生产级可控LangGraph 的图模型在理论上更干净。2. 核心概念拆解StateGraph、State、Node、Edge2.1 State所有 Agent 的“共享白板”LangGraph 里最重要的概念是 State。它不是单纯的内存字典而是带 reducer 的状态模型。最简单的定义方式是使用 TypedDictfrom typing import Annotated, TypedDict from langgraph.graph import add_messages class AgentState(TypedDict): messages: Annotated[list, add_messages] # 消息列表自动追加 current_actor: str # 当前执行节点名称 research_results: dict # 数据库采集结果 draft: str # 写作中间产物 final_answer: str # 最终输出注意Annotated[list, add_messages]这种写法。add_messages是 LangGraph 内置的 reducer它定义了多个节点往同一个字段写值时如何合并。对于消息列表来说默认是追加而不是覆盖。这一点特别关键你想象多个 Agent 在同一块白板上写字如果每个人写到同一行最后只会留下最后一个人的字。用add_messages就相当于每个人在下一行接着写历史记录不丢。自定义 reducer 也是可以的。比如我需要把多个 Agent 返回的搜索结果合并成一个大列表就可以定义def merge_results(left: list, right: list) - list: return left right然后在 State 字段中写results: Annotated[list, merge_results]。实际开发中状态字段要精心设计不要什么都往里塞。我见过有人把大段文本直接放在 State 里导致每次状态更新都要序列化几十 KB 数据性能下降非常明显。State 里只存关键词级别的中间结果详细文档建议给引用 ID。2.2 Node 和 Edge状态转移的规则节点就是普通的 Python 函数也可以异步 async。输入是 State 的字典输出是 State 的部分更新Partial State。LangGraph 会自动把输出合并到全局状态。边则分为普通边和条件边用来决定从哪个节点走到哪个节点。from langgraph.graph import StateGraph, END def agent_a(state: AgentState): # 处理逻辑 return {draft: A 生成的内容} def agent_b(state: AgentState): # 处理逻辑 return {final_answer: state[draft] B 完善的内容}构建图graph StateGraph(AgentState) graph.add_node(A, agent_a) graph.add_node(B, agent_b) graph.set_entry_point(A) graph.add_edge(A, B) graph.add_edge(B, END)是不是很简单但一旦引入条件路由整个复杂度才真正体现出来def route_after_research(state: AgentState) - str: if not state[research_results]: return research # 回到采集节点 return writer # 进入写作节点这条条件边就是“返回需要跳转到的节点名称”非常直观。LangGraph 的一个设计哲学是所有决策都可以由 LLM 或自定义逻辑驱动。说白了条件边里你可以调用 GPT-4 判断下一步也可以写 if-else 硬编码甚至结合工具结果去判断。这就为 Multi-Agent 提供了“不稳定的智能决策”和“稳定的流程骨架”的结合点。2.3 Checkpointer让 Agent 拥有“记忆”和断点多智能体系统如果真的只有图定义那它只是静态流程。要支持人机交互、手动干预、故障恢复必须要有 Checkpointer。LangGraph 的 Checkpointer 可以保存每一步的状态快照并且支持从任意节点恢复执行。from langgraph.checkpoint.memory import MemorySaver saver MemorySaver() # 也可以换成 PostgresSaver、SqliteSaver 等 graph graph.compile(checkpointersaver)调用时传入thread_idconfig {configurable: {thread_id: case-41}} response graph.invoke({messages: []}, config)同一thread_id下的执行历史会被保留下次调用时会从上次中断的地方继续。这个机制在 Multi-Agent 中太有用了。比如用户在与多智能体系统交互的过程中写作 Agent 写了一半用户突然说“换个语气”就可以从 writing 节点继续而不需要重新跑一遍数据采集。另外生产级系统强烈建议用持久化 Checkpointer如PostgresSaver别用内存版的MemorySaver否则服务重启什么都丢了。3. 实操案例实现一个“研究顾问”多智能体系统3.1 业务场景与角色定义案例背景做一个研究顾问用户提出一个问题系统需要先搜索资料、整理关键信息、生成完整回答同时能够根据回答质量决定是否重写。三个角色分工如下主管Supervisor负责整体调度接收用户问题协调研究节点和写作节点判断结果是否满足要求。研究员Researcher通过知识库或搜索工具获取资料输出结构化要点。写作者Writer把研究要点扩展成用户友好的答案。这里不是简单的一条链路因为主管要动态判断研究员是否需要补充信息写作者写完可能要打回重写。这就是典型的多 Agent 协作模式。3.2 代码实现从节点定义到完整流程图我用 LangGraph 的StateGraph来实现。为了便于理解这里用 mock 的“工具”代替真实的数据库或 API。先定义状态和节点from typing import Annotated, TypedDict from langgraph.graph import StateGraph, END from langgraph.checkpoint.memory import MemorySaver class ResearchState(TypedDict): question: str # 用户问题 context: list[str] # 检索到的上下文 draft: str # 写作草稿 review_score: int # 主管评分 final_answer: str # 最终答案 # 模拟工具知识检索 def search_knowledge_base(query: str) - list[str]: # 这里替换为真实的向量检索 / API 调用 return [f{query} 的相关资料片段 {i} for i in range(3)] # 研究员节点 def researcher_node(state: ResearchState): query state[question] results search_knowledge_base(query) return {context: results} # 写作者节点 def writer_node(state: ResearchState): context \n.join(state.get(context, [])) draft f根据资料撰写答案\n上下文: {context} return {draft: draft} # 主管节点对草稿评分并决定后续路由 def supervisor_node(state: ResearchState): # 实际场景可以调用 LLM 评分这里模拟 if 重要客户 in state[question]: score 3 else: score 9 if score 8: return {review_score: score, final_answer: state[draft]} else: return {review_score: score, draft: state[draft] \n补充细节} def route_after_supervisor(state: ResearchState) - str: if state[review_score] 8: return writer # 回到写作者重写 return END # 完成构建图builder StateGraph(ResearchState) builder.add_node(researcher, researcher_node) builder.add_node(writer, writer_node) builder.add_node(supervisor, supervisor_node) builder.set_entry_point(researcher) builder.add_edge(researcher, writer) builder.add_edge(writer, supervisor) builder.add_conditional_edges( supervisor, route_after_supervisor, {writer: writer, END: END} ) graph builder.compile(checkpointerMemorySaver())调用config {configurable: {thread_id: research-case-5}} result graph.invoke( {question: 我们下个季度需要重点拓展哪些客户}, config ) print(result[final_answer])你可能会说这个案例太简单了每个节点都没用 LLM。是的为了展示框架结构我没让节点调用 LLM。真正生产环境里你可以把节点内部的逻辑换成任何 LLM 调用链。LangGraph 不会限制你在一个节点里是调用一次 LLM 还是调用十次工具。它只负责节点之间的流转。3.3 参数说明与状态流细节这个案例里几个我实际敲过的地方值得细说route_after_supervisor的条件边返回字符串必须映射到图中存在的节点名或END。如果你的返回键不在映射字典里会直接报错。记得检查add_conditional_edges第三个参数它就是一个从返回值到实际节点名的映射。每次invoke传的config里面包含thread_id这个 ID 用来标识一整个会话。不同会话的状态完全隔离这一点对于多用户场景非常重要。同一个线程内状态是累积的如果不同请求用同一线程 ID上一个请求的 State 会残留下来。一般我们会用用户 ID 会话 ID 组合一个唯一线程 ID。我用的MemorySaver只适合本地测试。用 Postgres 的话只需一行替换LangGraph 官方提供的 saver 接口都是一致的。后面要讲部署时再展开。3.4 加入 LLM 与工具调用的真实节点我们做一个升级版研究员节点内部会调用真实 LLM 并可能迭代多次工具调用直到收集足够信息。LangGraph 节点的自由度很高节点内部可以嵌套使用AgentExecutor或langchain.tools。但这里我想强调一种更地道的做法把工具调用也建模成子图。为了让文章更贴近实战我用 LangChain 的langchain_openai来做 LLM 调用from langchain_openai import ChatOpenAI from langchain_core.messages import HumanMessage, SystemMessage llm ChatOpenAI(modelgpt-4o-mini, temperature0.2) def researcher_node(state: ResearchState): prompt [ SystemMessage(content你是行业研究员请根据问题检索相关资料并总结3条关键要点。), HumanMessage(contentstate[question]) ] response llm.invoke(prompt) return {context: [response.content]}这样虽然节点内部只调用了 LLM没有调用外部工具但如果需要工具你完全可以在节点内部用tool_calls实现循环。LangGraph 并不强制你使用它内置的ToolNode你可以自己控制调用次数。不过内置的ToolNode配合create_react_agent非常省事前提是你愿意让 LangGraph 替你管理工具循环。以我的经验如果 Agent 内部的工具调用流程相对固定用内置ToolNode最稳如果工具调用逻辑特别复杂且有跨 Agent 共享需求那就自己写节点内部循环。3.5 多 Agent 之间的消息传递机制多智能体的本质是消息交换。LangGraph 里消息通常放在 State 的messages字段并且用add_messagesreducer 做追加。每个节点的输入是整个 State输出中如果包含messages字段就会追加到全局消息历史。这就像一群人开会每个人都在会议纪要里不断添加自己的发言。实际开发中我会定义额外的字段来存储“结构化消息”而不是全靠messages。因为 LLM 自然语言消息在跨 Agent 传递时会有解析成本。比如研究员返回给写作者的应该是结构化要点而不是一大段自然语言。所以我上面的ResearchState里安排了context: list[str]就是结构化中间产物。在节点内部messages是给 LLM 看的而context是给下游流程用的。两者共存不冲突。4. 经典 Multi-Agent 拓扑Supervisor / Hierarchical / Network4.1 三种拓扑对比与选择在 LangGraph 官方文档里多智能体结构大致分成三类我结合自己的项目讲讲适用范围。Supervisor主管-工人所有 Agent 都向主管汇报主管负责调度。适合上游有明确意图分类下游任务相对独立的场景。比如一个客服机器人主管先判断用户想退款还是想查物流然后分别派给退款专家或物流专家。优点是决策集中行为可控缺点是主管容易成为瓶颈。Hierarchical分层主管下面还有子主管子主管管理具体执行 Agent。适合任务层级很深、决策粒度从粗到细的场景。比如公司内部知识助手顶层主管判断是技术还是人事问题技术子主管再判断是后端还是前端问题最后交给具体代码 Agent。这种结构在 LangGraph 里嵌套子图来实现顶层图包含子图节点子图里再建更细的图。Network网络Agent 之间可以任意通信彼此不依赖主线。适合高度开放、需要动态协作的场景。但 Network 结构在 LangGraph 里实现起来要额外小心容易形成死循环和状态爆炸。我的建议是生产系统少用纯网络结构除非你对每个节点的终止条件做了非常严格的状态约束。下面这张表是我常用的粗略判断依据结构适用场景优点缺点Supervisor意图清晰、子任务独立易控制、易监控主管节点负载高Hierarchical任务复杂度高、层级分明模块化强、职责分明结构深度大、调试成本高Network探索型、需要多路径自由协作灵活性最强状态复杂、难收敛4.2 用 LangGraph 实现一个 Supervisor 多智能体我来完整展示一个常见 supervisor 实现。这里的关键点是主管节点里用一个 LLM 来决定下一步找哪个 Agent其他节点分别处理各自任务。假设系统里有三个执行 AgentResearcher、Summarizer、Critic。主管执行流程如下from typing import Literal from langgraph.graph import StateGraph, END # 角色消息 SYSTEM_PROMPT 你是一个主管根据用户需求选择下一步执行者 - researcher: 需要检索资料 - summarizer: 对已有内容进行总结 - critic: 批评和评估答复质量 只输出一个角色名。 def supervisor_router(state: ResearchState) - Literal[researcher, summarizer, critic]: # 这里简化调用 LLM然后返回决定 response llm.invoke([SystemMessage(contentSYSTEM_PROMPT), HumanMessage(contentstate[question])]) role response.content.strip().lower() if role not in (researcher, summarizer, critic): return researcher return role然后图结构builder.add_node(supervisor, supervisor_router) # 这里只是演示路由函数并不负责LLM内部执行 builder.add_node(researcher, researcher_node) builder.add_node(summarizer, summarizer_node) builder.add_node(critic, critic_node) builder.set_entry_point(supervisor) builder.add_conditional_edges( supervisor, supervisor_router, { researcher: researcher, summarizer: summarizer, critic: critic } ) builder.add_edge(researcher, supervisor) # 执行后回到主管 builder.add_edge(summarizer, supervisor) builder.add_edge(critic, supervisor)这里的图是无限循环的主管不断决定下一步执行者执行完又回到主管。必须在某处加终止条件。一种做法是在主管节点判断“如果回答满意就返回 END”def supervisor_router(state: ResearchState) - Literal[researcher, summarizer, critic, END]: if state.get(final_answer): return END # ... 其余逻辑注意supervisor_router被条件边当作路由函数调用但它也可以是一个实际节点。我通常会把“决策 LLM”放在条件边函数里这样图结构更清晰主管不是一个实际执行节点而是一个路由函数。但条件边函数不能修改状态。如果你需要主管既做决策又修改状态那就把它定义成节点节点返回后走条件边。4.3 子图与嵌套Hierarchical 的落地姿势如果你想实现层级结构LangGraph 允许把一个编译好的图作为另一个图的节点。比如我有一个“技术组”子图里面包含前后端两个 Agent然后将这个子图挂到总图的一个节点上tech_subgraph build_tech_subgraph() # 返回 StateGraph builder.add_node(tech_team, tech_subgraph.compile()) builder.add_edge(supervisor, tech_team)子图和父图之间通过状态传递数据。父图的 State 字段可以被子图读取、更新前提是字段名一致。这样就把需求层层拆分成嵌套图。这个模式极大提升了组织的复用性。我在实际项目里会把可复用的 Agent 团队封装成子图比如“搜索小组”“合同审核小组”然后父图通过 supervisor 路由到不同子图。需要留意的是子图编译后的invoke内部可能有自己的 checkpointer。如果父子图都配置了 checkpointer内部状态恢复时会比较绕。我的经验是子图不单独设置 checkpointer统一由顶层图管理。这样数据结构最简单避免多层嵌套的 checkpoint 冲突。5. 常见问题与排查技巧实录5.1 无限循环就是出不来怎么办多智能体图最常见的问题就是死循环。原因往往是条件边的路由总是满足回退条件。我遇到过写作者写出来的内容永远被主管评低分导致重复循环几十上百次。解决办法有三种加最大迭代次数。在状态里增加iteration_count字段路由函数判断超过阈值直接结束或强制降级。用 checkpointer 做时间旅行。如果你开了 checkpoint可以回溯到循环起始点检查每个节点的输出变化。把评价逻辑换成更严格的规则。比如限定评分子项不要仅凭一个 AI 评分就决定打回。在 LangGraph 里你可以直接给循环边设置add_conditional_edges在路由函数里用state[iteration_count] 3返回 END。这是最直接有效的。5.2 状态被覆盖或丢失如果你发现下游 Agent 拿到的是空值先确认你有没有在节点里返回对应字段。还有一个非常隐蔽的坑State 的 TypedDict 字段类型是list默认策略是整体覆盖。如果两个节点都往同一个 list 字段写值后写的会覆盖先写的。所以跨 Agent 的共享结果字段请务必用Annotated[list, add_messages]或自定义 reducer。另一种“丢失”发生在子图边界。子图里的节点只更新子图的 State不会自动同步到父图除非父图 State 和子图 State 定义完全一致的字段名并且子图的 super step 返回了这些字段。简单来说子图只能更新它自己 State 里定义的字段而这些字段必须与父图 State 同名字段兼容。建议把父子图共享的字段单独提取出来放在基类 TypedDict 里继承避免出现两边字段定义不一致的奇葩 bug。5.3 并发节点结果乱序LangGraph 支持并行执行多个节点。比如同时让研究员和数据分析员各自工作然后合并结果。默认执行顺序是并发的State 的 reducer 会按节点完成顺序合并。如果你的系统对顺序敏感要利用 reducer 或者给结果加入时间戳。我写并行节点时都会在 State 里定义results: Annotated[list, merge_results]然后把每个并行节点的结果都返回resultsreducer 负责合成。这里需要测试 reducer 的幂等性避免重复运行同一个并行节点时结果重复堆积。5.4 图可视化用画图的心态调试LangGraph 官方提供了get_graph().draw_mermaid_png()等方法。我强烈建议每个图在开发阶段都画出来看一眼。用 Mermaid 文本也能查看print(graph.get_graph().draw_mermaid())图像化能帮你立刻发现漏边、错边、没有回到主管的问题。不过注意如果图里有条件边Mermaid 只会显示分支不会显示分支条件的细节所以还是需要代码审计。5.5 日志与追踪给 Agent 加“探针”由于多智能体系统里每一步都是 LLM 调用你不知道黑盒里发生了什么。LangChain 生态有一个可选的 LANGCHAIN_TRACING 方式但我更喜欢纯手工方式在每个节点内加上日志记录 state 的关键字段。比如import logging logger logging.getLogger(agent) def researcher_node(state: ResearchState): logger.info(researcher starts, question%s, state[question]) ... logger.info(researcher got %d contexts, len(new_context))生产环境还会在关键路由决策时打印决策原因。LLM 调用时也在 prompt 里让它把决策理由附加到输出中这样排障时就能看到完整思路。相信我在多智能体系统里没有日志的 Agent 就是定时炸弹。6. 进阶经验性能优化与部署注意点6.1 避免输入历史无限膨胀多智能体协作时Agent 的 messages 数量会随迭代次数快速增长。参考对话上下文的add_messagesreducer每次新增一轮对话/协作都有大量历史积累。LLM 的上下文窗口有限费用也随 token 上升。解决办法是定期压缩提示词或裁剪消息。LangGraph 官方有langchain_core.messages里的消息裁剪工具。我实际用的是在当前节点调用 LLM 之前把历史消息中无用的工具输出浓缩成摘要。把这个摘要当做人设的一部分塞到 SystemMessage 里。6.2 选择合适的持久化后端之前说过 MemorySaver 仅适合测试。LangGraph 提供了PostgresSaver、SqliteSaver、RedisSaver等。生产环境我推荐 PostgresSaver因为它可以做真正的事务处理并且支持多进程并发。切换非常方便from langgraph.checkpoint.postgres import PostgresSaver saver PostgresSaver.from_conn_string(postgresql://user:passhost:port/db)注意PostgresSaver 使用时要先调用saver.setup()来建表。每个线程状态都会存在这张表里对多用户服务特别友好。缺点是需要维护数据库连接池但对一个正经后端系统这不算事。6.3 断点续跑与人工审核有些场景必须经过人工确认才放行。LangGraph 支持interrupt_before和interrupt_after参数来插入断点。典型用法是LLM 生成内容后在交付给用户前暂停等待人工编辑。我们可以编译时指定graph builder.compile( checkpointersaver, interrupt_before[publish_node] )然后外部服务在使用时检测graph.invoke返回的状态若处于中断状态则展示给人类审核。人类同意后再调用graph.invoke(None, configconfig)让它继续。这个功能让多智能体系统真正可以部署在“人机协同”的场景里而不是完全无人监督。6.4 我踩过的坑并行模型与同一线程冲突有一次我图里有两条并行分支都通过add_edge回到汇总节点。两个分支执行结束后汇总节点被调度了两次不对LangGraph 本身会等待所有并行分支完成后再执行下游节点。但我踩的坑是两个并行分支同时修改同一个字段而没有 reducer导致一侧结果被另一侧覆盖。这个问题排查了很久最后通过加日志发现两个节点输出的字段 key 相同。此后我在设计 State 时严格约束同一份数据只有一个人去写其他人只能读。如果必须多写请上 reducer。最后分享两个实际心得先说说选型倾向。LangGraph 的 Multi-Agent 模式不适合特别简单的一次性对话任务那样纯 Pipeline 就够。但一旦你要构建一个需要团队协作、具备长期记忆、可在任意环节支持人工干预的系统LangGraph 的图模型确实比手写回调靠谱得多。它并没有把多智能体问题直接变简单但它把“控制权”放回了开发者手里这在生产环境里是压倒性的优势。再说个实在的小技巧。开发阶段我给每个 Agent 节点都起一个“动作动词 对象”的名字比如research_customer_clues、write_solution_draft、validate_answer_quality。这不仅仅是命名习惯也是为了让 LangGraph 的可视化图、日志、模块化调试三者共用同一套语义。每次你看到路由结果里跳转到了write_solution_draft你就知道这一步在干什么。别小看这个习惯多智能体系统一旦有六个以上节点命名混乱带来的心理负担比代码本身难缠得多。最后留一个可扩展的方向。上面所有案例都是“静态图”——节点和边在编译前就定死了。LangGraph 也支持动态增加节点的能力但我们团队在实践中发现动态图对状态约束要求极高容易失控。我目前只在一个实验项目里用过生产系统还是尽量把流程显式画出来。图一旦动态排查问题的成本就指数级上升。所以除非你是纯粹做研究否则推荐先把静态图画得明明白白再去琢磨那些花活。 LangGraph多智能体实战：从图编排到踩坑记录
LangGraph 做 Multi-Agent其实没有你想的那么玄乎但也不是简单地调几个库就能搞定。最近我把几个真实的 Multi-Agent 项目用 LangGraph 重构了一遍踩了一圈坑之后想把这套框架的底层逻辑、典型案例和实操细节完整拆出来。这篇文章不端着直接以案例为主线从架构设计到踩坑记录给你一条可以照抄的落地路径。如果你是第一次接触 LangGraph 和 Multi-Agent或者已经写过几个 Agent 但总感觉协作逻辑拧巴那这篇应该能帮到你。LangGraph 本质上是一个基于图结构的 Agent 编排框架它把传统的 Agent 循环调用 LLM - 执行工具 - 再调用 LLM拆成节点、边和状态三个核心要素。多智能体Multi-Agent在这个框架里不再是简单地把多个 Agent 塞在一起而是通过图拓扑去定义它们之间的通信、路由和共享状态。这就解决了一个以前很头疼的问题多个 Agent 各自为战、互相抢上下文、数据流混乱。LangGraph 的好处在于它让你把“智能”交给 LLM但把“流程控制”牢牢握在自己手里这非常关键。因为生产环境里的多智能体系统最怕的就是失控。以下所有案例都能在 LangGraph 最新的 0.2.x 版本上跑通代码基于 Python我会标明每段代码的作用和关键参数。别急先从设计思路讲起。1. 整体设计为什么用 LangGraph 来搭 Multi-Agent1.1 先想清楚 Multi-Agent 不是“多个 Agent 的堆叠”很多人一听到 Multi-Agent第一反应是“我有多个任务所以我有多个 Agent每个 Agent 负责一个任务”。这个理解不能说错但很容易把系统做成接口调用而不是一个有机协作的团队。真正的 Multi-Agent 系统核心在于 Agent 之间需要共享上下文、需要路由决策、需要授权调用、需要异常回退、需要合并结果。这些需求在 LangGraph 里对应的就是节点、边、状态、条件分支和 checkpointer。举个我自己的例子。之前我做一个行业研究报告生成系统最初拆成了三个独立的 Agent数据采集 Agent、分析 Agent、写作 Agent。每个 Agent 通过 HTTP 调用串联后一个 Agent 拿前一个 Agent 的输出作为输入。跑起来就发现几个问题数据采集 Agent 返回的 JSON 结构不稳定分析 Agent 经常解析失败。分析 Agent 如果需要补查数据没法自己回头调用采集 Agent只能抛出异常让上层服务去协调。改写阶段没法看到中间推理过程出问题很难定位。换成 LangGraph 之后我把这三个“模型”变成了三个“节点”用图结构让分析 Agent 可以动态决定是否重新调用数据采集节点。整个系统的状态由一个统一的 State 对象管理每个节点读写 State 中的某个字段传输和解析的契约终于在同一个框架内收敛了。这就是 Multi-Agent 的“多”不是在数量上多而是在协作模式上多。1.2 LangGraph 与主流编排方案的选型对比现在市面上的 Agent 编排方案很多我简单拉一张表不是要否定谁而是为了让选型有依据。方案运行模型状态管理复杂流程支持LangChain 集成学习曲线典型场景LangGraph图结构 Pregel 风格显式 State Reducer支持循环、条件分支、并行、多 Agent原生集成中复杂业务流、生产级系统AutoGen对话驱动会话历史通过群聊、发言顺序控制需要额外适配中低多角色对话研究CrewAI角色 任务列表任务输出聚合任务依赖Pipeline 为主有但相对轻量低快速搭建、简单协作手写 Pipeline代码硬编无每次改动要改代码无高维护简单一次性脚本我当时选 LangGraph核心就看中两点第一它天然支持循环。多智能体系统里最常见的协作模式是“A 想了之后告诉 BB 缺信息再回头找 A”这种循环用 Pipeline 写要反复设计回调但在图里只是一条从 B 回到 A 的边。第二它的 State 可序列化且支持 Checkpointer这意味着每个 Agent 都能看到全局上下文而且能在任意节点断点恢复排障能力极强。如果你只是做一次性 demoCrewAI 确实更爽但要做到生产级可控LangGraph 的图模型在理论上更干净。2. 核心概念拆解StateGraph、State、Node、Edge2.1 State所有 Agent 的“共享白板”LangGraph 里最重要的概念是 State。它不是单纯的内存字典而是带 reducer 的状态模型。最简单的定义方式是使用 TypedDictfrom typing import Annotated, TypedDict from langgraph.graph import add_messages class AgentState(TypedDict): messages: Annotated[list, add_messages] # 消息列表自动追加 current_actor: str # 当前执行节点名称 research_results: dict # 数据库采集结果 draft: str # 写作中间产物 final_answer: str # 最终输出注意Annotated[list, add_messages]这种写法。add_messages是 LangGraph 内置的 reducer它定义了多个节点往同一个字段写值时如何合并。对于消息列表来说默认是追加而不是覆盖。这一点特别关键你想象多个 Agent 在同一块白板上写字如果每个人写到同一行最后只会留下最后一个人的字。用add_messages就相当于每个人在下一行接着写历史记录不丢。自定义 reducer 也是可以的。比如我需要把多个 Agent 返回的搜索结果合并成一个大列表就可以定义def merge_results(left: list, right: list) - list: return left right然后在 State 字段中写results: Annotated[list, merge_results]。实际开发中状态字段要精心设计不要什么都往里塞。我见过有人把大段文本直接放在 State 里导致每次状态更新都要序列化几十 KB 数据性能下降非常明显。State 里只存关键词级别的中间结果详细文档建议给引用 ID。2.2 Node 和 Edge状态转移的规则节点就是普通的 Python 函数也可以异步 async。输入是 State 的字典输出是 State 的部分更新Partial State。LangGraph 会自动把输出合并到全局状态。边则分为普通边和条件边用来决定从哪个节点走到哪个节点。from langgraph.graph import StateGraph, END def agent_a(state: AgentState): # 处理逻辑 return {draft: A 生成的内容} def agent_b(state: AgentState): # 处理逻辑 return {final_answer: state[draft] B 完善的内容}构建图graph StateGraph(AgentState) graph.add_node(A, agent_a) graph.add_node(B, agent_b) graph.set_entry_point(A) graph.add_edge(A, B) graph.add_edge(B, END)是不是很简单但一旦引入条件路由整个复杂度才真正体现出来def route_after_research(state: AgentState) - str: if not state[research_results]: return research # 回到采集节点 return writer # 进入写作节点这条条件边就是“返回需要跳转到的节点名称”非常直观。LangGraph 的一个设计哲学是所有决策都可以由 LLM 或自定义逻辑驱动。说白了条件边里你可以调用 GPT-4 判断下一步也可以写 if-else 硬编码甚至结合工具结果去判断。这就为 Multi-Agent 提供了“不稳定的智能决策”和“稳定的流程骨架”的结合点。2.3 Checkpointer让 Agent 拥有“记忆”和断点多智能体系统如果真的只有图定义那它只是静态流程。要支持人机交互、手动干预、故障恢复必须要有 Checkpointer。LangGraph 的 Checkpointer 可以保存每一步的状态快照并且支持从任意节点恢复执行。from langgraph.checkpoint.memory import MemorySaver saver MemorySaver() # 也可以换成 PostgresSaver、SqliteSaver 等 graph graph.compile(checkpointersaver)调用时传入thread_idconfig {configurable: {thread_id: case-41}} response graph.invoke({messages: []}, config)同一thread_id下的执行历史会被保留下次调用时会从上次中断的地方继续。这个机制在 Multi-Agent 中太有用了。比如用户在与多智能体系统交互的过程中写作 Agent 写了一半用户突然说“换个语气”就可以从 writing 节点继续而不需要重新跑一遍数据采集。另外生产级系统强烈建议用持久化 Checkpointer如PostgresSaver别用内存版的MemorySaver否则服务重启什么都丢了。3. 实操案例实现一个“研究顾问”多智能体系统3.1 业务场景与角色定义案例背景做一个研究顾问用户提出一个问题系统需要先搜索资料、整理关键信息、生成完整回答同时能够根据回答质量决定是否重写。三个角色分工如下主管Supervisor负责整体调度接收用户问题协调研究节点和写作节点判断结果是否满足要求。研究员Researcher通过知识库或搜索工具获取资料输出结构化要点。写作者Writer把研究要点扩展成用户友好的答案。这里不是简单的一条链路因为主管要动态判断研究员是否需要补充信息写作者写完可能要打回重写。这就是典型的多 Agent 协作模式。3.2 代码实现从节点定义到完整流程图我用 LangGraph 的StateGraph来实现。为了便于理解这里用 mock 的“工具”代替真实的数据库或 API。先定义状态和节点from typing import Annotated, TypedDict from langgraph.graph import StateGraph, END from langgraph.checkpoint.memory import MemorySaver class ResearchState(TypedDict): question: str # 用户问题 context: list[str] # 检索到的上下文 draft: str # 写作草稿 review_score: int # 主管评分 final_answer: str # 最终答案 # 模拟工具知识检索 def search_knowledge_base(query: str) - list[str]: # 这里替换为真实的向量检索 / API 调用 return [f{query} 的相关资料片段 {i} for i in range(3)] # 研究员节点 def researcher_node(state: ResearchState): query state[question] results search_knowledge_base(query) return {context: results} # 写作者节点 def writer_node(state: ResearchState): context \n.join(state.get(context, [])) draft f根据资料撰写答案\n上下文: {context} return {draft: draft} # 主管节点对草稿评分并决定后续路由 def supervisor_node(state: ResearchState): # 实际场景可以调用 LLM 评分这里模拟 if 重要客户 in state[question]: score 3 else: score 9 if score 8: return {review_score: score, final_answer: state[draft]} else: return {review_score: score, draft: state[draft] \n补充细节} def route_after_supervisor(state: ResearchState) - str: if state[review_score] 8: return writer # 回到写作者重写 return END # 完成构建图builder StateGraph(ResearchState) builder.add_node(researcher, researcher_node) builder.add_node(writer, writer_node) builder.add_node(supervisor, supervisor_node) builder.set_entry_point(researcher) builder.add_edge(researcher, writer) builder.add_edge(writer, supervisor) builder.add_conditional_edges( supervisor, route_after_supervisor, {writer: writer, END: END} ) graph builder.compile(checkpointerMemorySaver())调用config {configurable: {thread_id: research-case-5}} result graph.invoke( {question: 我们下个季度需要重点拓展哪些客户}, config ) print(result[final_answer])你可能会说这个案例太简单了每个节点都没用 LLM。是的为了展示框架结构我没让节点调用 LLM。真正生产环境里你可以把节点内部的逻辑换成任何 LLM 调用链。LangGraph 不会限制你在一个节点里是调用一次 LLM 还是调用十次工具。它只负责节点之间的流转。3.3 参数说明与状态流细节这个案例里几个我实际敲过的地方值得细说route_after_supervisor的条件边返回字符串必须映射到图中存在的节点名或END。如果你的返回键不在映射字典里会直接报错。记得检查add_conditional_edges第三个参数它就是一个从返回值到实际节点名的映射。每次invoke传的config里面包含thread_id这个 ID 用来标识一整个会话。不同会话的状态完全隔离这一点对于多用户场景非常重要。同一个线程内状态是累积的如果不同请求用同一线程 ID上一个请求的 State 会残留下来。一般我们会用用户 ID 会话 ID 组合一个唯一线程 ID。我用的MemorySaver只适合本地测试。用 Postgres 的话只需一行替换LangGraph 官方提供的 saver 接口都是一致的。后面要讲部署时再展开。3.4 加入 LLM 与工具调用的真实节点我们做一个升级版研究员节点内部会调用真实 LLM 并可能迭代多次工具调用直到收集足够信息。LangGraph 节点的自由度很高节点内部可以嵌套使用AgentExecutor或langchain.tools。但这里我想强调一种更地道的做法把工具调用也建模成子图。为了让文章更贴近实战我用 LangChain 的langchain_openai来做 LLM 调用from langchain_openai import ChatOpenAI from langchain_core.messages import HumanMessage, SystemMessage llm ChatOpenAI(modelgpt-4o-mini, temperature0.2) def researcher_node(state: ResearchState): prompt [ SystemMessage(content你是行业研究员请根据问题检索相关资料并总结3条关键要点。), HumanMessage(contentstate[question]) ] response llm.invoke(prompt) return {context: [response.content]}这样虽然节点内部只调用了 LLM没有调用外部工具但如果需要工具你完全可以在节点内部用tool_calls实现循环。LangGraph 并不强制你使用它内置的ToolNode你可以自己控制调用次数。不过内置的ToolNode配合create_react_agent非常省事前提是你愿意让 LangGraph 替你管理工具循环。以我的经验如果 Agent 内部的工具调用流程相对固定用内置ToolNode最稳如果工具调用逻辑特别复杂且有跨 Agent 共享需求那就自己写节点内部循环。3.5 多 Agent 之间的消息传递机制多智能体的本质是消息交换。LangGraph 里消息通常放在 State 的messages字段并且用add_messagesreducer 做追加。每个节点的输入是整个 State输出中如果包含messages字段就会追加到全局消息历史。这就像一群人开会每个人都在会议纪要里不断添加自己的发言。实际开发中我会定义额外的字段来存储“结构化消息”而不是全靠messages。因为 LLM 自然语言消息在跨 Agent 传递时会有解析成本。比如研究员返回给写作者的应该是结构化要点而不是一大段自然语言。所以我上面的ResearchState里安排了context: list[str]就是结构化中间产物。在节点内部messages是给 LLM 看的而context是给下游流程用的。两者共存不冲突。4. 经典 Multi-Agent 拓扑Supervisor / Hierarchical / Network4.1 三种拓扑对比与选择在 LangGraph 官方文档里多智能体结构大致分成三类我结合自己的项目讲讲适用范围。Supervisor主管-工人所有 Agent 都向主管汇报主管负责调度。适合上游有明确意图分类下游任务相对独立的场景。比如一个客服机器人主管先判断用户想退款还是想查物流然后分别派给退款专家或物流专家。优点是决策集中行为可控缺点是主管容易成为瓶颈。Hierarchical分层主管下面还有子主管子主管管理具体执行 Agent。适合任务层级很深、决策粒度从粗到细的场景。比如公司内部知识助手顶层主管判断是技术还是人事问题技术子主管再判断是后端还是前端问题最后交给具体代码 Agent。这种结构在 LangGraph 里嵌套子图来实现顶层图包含子图节点子图里再建更细的图。Network网络Agent 之间可以任意通信彼此不依赖主线。适合高度开放、需要动态协作的场景。但 Network 结构在 LangGraph 里实现起来要额外小心容易形成死循环和状态爆炸。我的建议是生产系统少用纯网络结构除非你对每个节点的终止条件做了非常严格的状态约束。下面这张表是我常用的粗略判断依据结构适用场景优点缺点Supervisor意图清晰、子任务独立易控制、易监控主管节点负载高Hierarchical任务复杂度高、层级分明模块化强、职责分明结构深度大、调试成本高Network探索型、需要多路径自由协作灵活性最强状态复杂、难收敛4.2 用 LangGraph 实现一个 Supervisor 多智能体我来完整展示一个常见 supervisor 实现。这里的关键点是主管节点里用一个 LLM 来决定下一步找哪个 Agent其他节点分别处理各自任务。假设系统里有三个执行 AgentResearcher、Summarizer、Critic。主管执行流程如下from typing import Literal from langgraph.graph import StateGraph, END # 角色消息 SYSTEM_PROMPT 你是一个主管根据用户需求选择下一步执行者 - researcher: 需要检索资料 - summarizer: 对已有内容进行总结 - critic: 批评和评估答复质量 只输出一个角色名。 def supervisor_router(state: ResearchState) - Literal[researcher, summarizer, critic]: # 这里简化调用 LLM然后返回决定 response llm.invoke([SystemMessage(contentSYSTEM_PROMPT), HumanMessage(contentstate[question])]) role response.content.strip().lower() if role not in (researcher, summarizer, critic): return researcher return role然后图结构builder.add_node(supervisor, supervisor_router) # 这里只是演示路由函数并不负责LLM内部执行 builder.add_node(researcher, researcher_node) builder.add_node(summarizer, summarizer_node) builder.add_node(critic, critic_node) builder.set_entry_point(supervisor) builder.add_conditional_edges( supervisor, supervisor_router, { researcher: researcher, summarizer: summarizer, critic: critic } ) builder.add_edge(researcher, supervisor) # 执行后回到主管 builder.add_edge(summarizer, supervisor) builder.add_edge(critic, supervisor)这里的图是无限循环的主管不断决定下一步执行者执行完又回到主管。必须在某处加终止条件。一种做法是在主管节点判断“如果回答满意就返回 END”def supervisor_router(state: ResearchState) - Literal[researcher, summarizer, critic, END]: if state.get(final_answer): return END # ... 其余逻辑注意supervisor_router被条件边当作路由函数调用但它也可以是一个实际节点。我通常会把“决策 LLM”放在条件边函数里这样图结构更清晰主管不是一个实际执行节点而是一个路由函数。但条件边函数不能修改状态。如果你需要主管既做决策又修改状态那就把它定义成节点节点返回后走条件边。4.3 子图与嵌套Hierarchical 的落地姿势如果你想实现层级结构LangGraph 允许把一个编译好的图作为另一个图的节点。比如我有一个“技术组”子图里面包含前后端两个 Agent然后将这个子图挂到总图的一个节点上tech_subgraph build_tech_subgraph() # 返回 StateGraph builder.add_node(tech_team, tech_subgraph.compile()) builder.add_edge(supervisor, tech_team)子图和父图之间通过状态传递数据。父图的 State 字段可以被子图读取、更新前提是字段名一致。这样就把需求层层拆分成嵌套图。这个模式极大提升了组织的复用性。我在实际项目里会把可复用的 Agent 团队封装成子图比如“搜索小组”“合同审核小组”然后父图通过 supervisor 路由到不同子图。需要留意的是子图编译后的invoke内部可能有自己的 checkpointer。如果父子图都配置了 checkpointer内部状态恢复时会比较绕。我的经验是子图不单独设置 checkpointer统一由顶层图管理。这样数据结构最简单避免多层嵌套的 checkpoint 冲突。5. 常见问题与排查技巧实录5.1 无限循环就是出不来怎么办多智能体图最常见的问题就是死循环。原因往往是条件边的路由总是满足回退条件。我遇到过写作者写出来的内容永远被主管评低分导致重复循环几十上百次。解决办法有三种加最大迭代次数。在状态里增加iteration_count字段路由函数判断超过阈值直接结束或强制降级。用 checkpointer 做时间旅行。如果你开了 checkpoint可以回溯到循环起始点检查每个节点的输出变化。把评价逻辑换成更严格的规则。比如限定评分子项不要仅凭一个 AI 评分就决定打回。在 LangGraph 里你可以直接给循环边设置add_conditional_edges在路由函数里用state[iteration_count] 3返回 END。这是最直接有效的。5.2 状态被覆盖或丢失如果你发现下游 Agent 拿到的是空值先确认你有没有在节点里返回对应字段。还有一个非常隐蔽的坑State 的 TypedDict 字段类型是list默认策略是整体覆盖。如果两个节点都往同一个 list 字段写值后写的会覆盖先写的。所以跨 Agent 的共享结果字段请务必用Annotated[list, add_messages]或自定义 reducer。另一种“丢失”发生在子图边界。子图里的节点只更新子图的 State不会自动同步到父图除非父图 State 和子图 State 定义完全一致的字段名并且子图的 super step 返回了这些字段。简单来说子图只能更新它自己 State 里定义的字段而这些字段必须与父图 State 同名字段兼容。建议把父子图共享的字段单独提取出来放在基类 TypedDict 里继承避免出现两边字段定义不一致的奇葩 bug。5.3 并发节点结果乱序LangGraph 支持并行执行多个节点。比如同时让研究员和数据分析员各自工作然后合并结果。默认执行顺序是并发的State 的 reducer 会按节点完成顺序合并。如果你的系统对顺序敏感要利用 reducer 或者给结果加入时间戳。我写并行节点时都会在 State 里定义results: Annotated[list, merge_results]然后把每个并行节点的结果都返回resultsreducer 负责合成。这里需要测试 reducer 的幂等性避免重复运行同一个并行节点时结果重复堆积。5.4 图可视化用画图的心态调试LangGraph 官方提供了get_graph().draw_mermaid_png()等方法。我强烈建议每个图在开发阶段都画出来看一眼。用 Mermaid 文本也能查看print(graph.get_graph().draw_mermaid())图像化能帮你立刻发现漏边、错边、没有回到主管的问题。不过注意如果图里有条件边Mermaid 只会显示分支不会显示分支条件的细节所以还是需要代码审计。5.5 日志与追踪给 Agent 加“探针”由于多智能体系统里每一步都是 LLM 调用你不知道黑盒里发生了什么。LangChain 生态有一个可选的 LANGCHAIN_TRACING 方式但我更喜欢纯手工方式在每个节点内加上日志记录 state 的关键字段。比如import logging logger logging.getLogger(agent) def researcher_node(state: ResearchState): logger.info(researcher starts, question%s, state[question]) ... logger.info(researcher got %d contexts, len(new_context))生产环境还会在关键路由决策时打印决策原因。LLM 调用时也在 prompt 里让它把决策理由附加到输出中这样排障时就能看到完整思路。相信我在多智能体系统里没有日志的 Agent 就是定时炸弹。6. 进阶经验性能优化与部署注意点6.1 避免输入历史无限膨胀多智能体协作时Agent 的 messages 数量会随迭代次数快速增长。参考对话上下文的add_messagesreducer每次新增一轮对话/协作都有大量历史积累。LLM 的上下文窗口有限费用也随 token 上升。解决办法是定期压缩提示词或裁剪消息。LangGraph 官方有langchain_core.messages里的消息裁剪工具。我实际用的是在当前节点调用 LLM 之前把历史消息中无用的工具输出浓缩成摘要。把这个摘要当做人设的一部分塞到 SystemMessage 里。6.2 选择合适的持久化后端之前说过 MemorySaver 仅适合测试。LangGraph 提供了PostgresSaver、SqliteSaver、RedisSaver等。生产环境我推荐 PostgresSaver因为它可以做真正的事务处理并且支持多进程并发。切换非常方便from langgraph.checkpoint.postgres import PostgresSaver saver PostgresSaver.from_conn_string(postgresql://user:passhost:port/db)注意PostgresSaver 使用时要先调用saver.setup()来建表。每个线程状态都会存在这张表里对多用户服务特别友好。缺点是需要维护数据库连接池但对一个正经后端系统这不算事。6.3 断点续跑与人工审核有些场景必须经过人工确认才放行。LangGraph 支持interrupt_before和interrupt_after参数来插入断点。典型用法是LLM 生成内容后在交付给用户前暂停等待人工编辑。我们可以编译时指定graph builder.compile( checkpointersaver, interrupt_before[publish_node] )然后外部服务在使用时检测graph.invoke返回的状态若处于中断状态则展示给人类审核。人类同意后再调用graph.invoke(None, configconfig)让它继续。这个功能让多智能体系统真正可以部署在“人机协同”的场景里而不是完全无人监督。6.4 我踩过的坑并行模型与同一线程冲突有一次我图里有两条并行分支都通过add_edge回到汇总节点。两个分支执行结束后汇总节点被调度了两次不对LangGraph 本身会等待所有并行分支完成后再执行下游节点。但我踩的坑是两个并行分支同时修改同一个字段而没有 reducer导致一侧结果被另一侧覆盖。这个问题排查了很久最后通过加日志发现两个节点输出的字段 key 相同。此后我在设计 State 时严格约束同一份数据只有一个人去写其他人只能读。如果必须多写请上 reducer。最后分享两个实际心得先说说选型倾向。LangGraph 的 Multi-Agent 模式不适合特别简单的一次性对话任务那样纯 Pipeline 就够。但一旦你要构建一个需要团队协作、具备长期记忆、可在任意环节支持人工干预的系统LangGraph 的图模型确实比手写回调靠谱得多。它并没有把多智能体问题直接变简单但它把“控制权”放回了开发者手里这在生产环境里是压倒性的优势。再说个实在的小技巧。开发阶段我给每个 Agent 节点都起一个“动作动词 对象”的名字比如research_customer_clues、write_solution_draft、validate_answer_quality。这不仅仅是命名习惯也是为了让 LangGraph 的可视化图、日志、模块化调试三者共用同一套语义。每次你看到路由结果里跳转到了write_solution_draft你就知道这一步在干什么。别小看这个习惯多智能体系统一旦有六个以上节点命名混乱带来的心理负担比代码本身难缠得多。最后留一个可扩展的方向。上面所有案例都是“静态图”——节点和边在编译前就定死了。LangGraph 也支持动态增加节点的能力但我们团队在实践中发现动态图对状态约束要求极高容易失控。我目前只在一个实验项目里用过生产系统还是尽量把流程显式画出来。图一旦动态排查问题的成本就指数级上升。所以除非你是纯粹做研究否则推荐先把静态图画得明明白白再去琢磨那些花活。