最近好几个朋友拿着LangGraph的教程来问我同一个问题图我也会画节点也会写但为什么我的Agent永远只会“一条道走到黑”其实根源就落在分支执行逻辑上。LangGraph把Agent工作流抽象成一张有向图这里的“分支”绝不只是画图时多画几条线而是运行时基于状态动态决定“下一步去哪”的决策中枢。这篇文章把条件边、路由函数、并行分支、循环退出和人工介入全部拆开讲配合可直接跑的代码示例和踩坑记录。不管你是刚接触LangGraph的新手还是已经在做Agent落地的开发者这篇都值得花几分钟吃透。1. 分支执行逻辑到底在解决什么问题1.1 把“下一步去哪”从代码写死变成运行时决策先说一个最基本的观念转换。写传统后端流程时一个请求进来先校验参数、再查库、再调接口、再返回这套顺序是我们用if-else在代码里写死的。但Agent不一样它面对的是用户的自然语言输入而语言模型本身就是概率输出同一个问题今天答这个、明天答那个。你不可能也没必要在代码里穷举所有可能路径你需要的是一套“边走边看”的执行框架每个节点执行完之后不要急着决定下一个节点而是把决策这件事交给一个专门的路由环节。LangGraph的分支执行逻辑核心就是这个“专门的路由环节”。它对应源码里的条件边Conditional Edge机制。我记得第一次看LangGraph文档的时候被它那堆图和术语绕晕了后来我自己用了一个交通系统的类比才彻底想通。你把整张图想象成一张城市路网节点是目的地边是路而条件边就是十字路口的交警。普通边意味着“这条路是固定的”你从A出发必定到B条件边则是交警根据当前路况也就是state状态告诉你“左转去B右转去C直行去D”。车怎么开、开去哪不由修路的人事先定死而是由交警这个“运行时决策”来定。那这个决策靠什么来定靠状态。LangGraph是一套典型的“状态驱动”框架整个图的执行共享一个全局状态对象每个节点都可以读取并更新它。分支路由函数要做的就是从这个状态里读出关键字段比如意图分类结果、工具执行返回值、循环步数计数、用户确认结果然后用这些字段算出一个字符串再去映射到下一个节点的名字。这才是LangGraph分支逻辑的正确打开方式不是散落的if-else而是集中式的、可测试的、由状态驱动的动态路由。1.2 分支能力决定Agent能有多“能干”很多学LangGraph的人一开始只把它当做一个“画流程图的工具”觉得图结构比LangChain的链式调用好看仅此而已。但等你把分支执行逻辑吃透了你会发现它其实是Agent架构能力的核心天花板。怎么理解这个“天花板”我们可以看一个Agent能力演进的路径。第一阶段是单轮问答模型输入输出没有流程第二阶段是顺序调用工具比如先搜索、再总结、再回答这用普通边就够了第三阶段是动态路由Agent执行到一半根据LLM的输出决定下一步是调工具还是直接回答这就是条件边最典型的应用场景到了第四阶段是多工具并行、多Agent协作、人工介入审批、循环迭代等这些能力几乎全部要依赖分支逻辑去承载。所以热词里那句“让AI真的下地干活”点到的正是这个痛处。一个Agent如果只会走固定流程那本质上就是个套了层AI壳的自动化脚本价值有限。真正“下地干活”的Agent必须能应对真实业务里的不确定性用户的问题可能属于不同类别需要走到不同处理链路某个关键操作可能触发风险需要停下来让人审批一次查询可能需要同时检索多个知识库。这些业务规则最后都会转化为一条条分支逻辑。分支执行逻辑写得越好Agent能承担的流程就越复杂这个项目的上限也就越高。2. 核心机制条件边与路由函数的工作原理2.1 条件边的完整拆解入点、路由函数、映射表LangGraph中定义条件边的接口是add_conditional_edges。以当前稳定版本0.2.x/0.3.x为例最经典、也最稳妥的写法是三要素版本source条件边的起始节点也就是这个节点执行完之后进入路由判断。path_func路由函数接收状态对象返回一个字符串。path_map映射字典把路由函数返回的字符串映射到目标节点名。一个最小的三路分流例子是这样的def route_by_intent(state: AgentState) - str: intent state.get(intent, unknown) if intent query: return search if intent transfer: return human return respond graph.add_conditional_edges( classify, # 前提classify节点执行完 route_by_intent, # 路由函数读取state.intent { search: search_db, human: transfer_to_human, respond: default_respond, }, )执行器看到这段代码之后流程是这样的图跑到classify节点执行完并不会立刻跳到某个固定节点而是先调用route_by_intent传入当前状态对象路由函数从状态里读出intent字段返回一个字符串key执行器拿这个key去查path_map这个映射表拿到真实节点名然后把执行指针交给那个节点。整个过程发生在图的“两步之间”对外表现为一个完整的超步superstep。这里补充一个版本差异的坑。新一点的LangGraph版本0.3.x的一部分允许路由函数直接返回目标节点名而不用写path_map映射表比如return search_db。这种写法更直白但它对你的代码规范要求更高节点名必须完全正确否则运行时报错。老版本则严格要求先返回一个自定义key再通过映射表解析。我第一次用的时候因为在两个版本之间反复横跳踩过不少“key not in path_map”的坑。如果你看的教程和自己安装的版本API对不上先去看langgraph版本号别盲目照抄。2.2 路由函数的三个关键设计原则路由函数的代码通常很短三五行的样子但它却是整张图里最容易翻车的地方。我自己做了几个项目之后总结了三个必须遵守的设计原则。第一个原则是“路由函数必须是无副作用的纯函数”。什么意思只读状态、计算字符串、返回结果不要在路由函数里去改状态、调外部API、写日志文件、或者做随机抽样。原因是LangGraph的执行器带有重放机制尤其是在配合checkpointer做断点续跑时已经走过的路径可能会被重新计算。如果路由函数里有随机因素或者外部副作用恢复执行时路由结果可能和原来不一致你会看到明明上次走A分支恢复后却走了B分支这种诡异情况。正确做法是把路由函数当作一个查询它只是从状态里摘取决策依据并给出结论。第二个原则是“必须有兜底分支”。LLM是概率系统你的意图分类模型可能返回预料之外的标签路由函数必须能处理“不知道往哪走”的情况。我通常会在映射字典里放一个兜底节点或者在路由函数里把未识别意图统一导向一个“clarify”节点让Agent去问用户澄清而不是让执行器抛异常。一个靠谱的生产级路由函数应该保证无论入参多离谱都能返回一个合法key。第三个原则是“路由函数的结果必须幂等可重放”。这其实和第一个原则有重叠但更侧重一个场景当你用interrupt暂停、恢复、或者做人工审核重放时系统要能精确复现原先的执行路径。所以路由函数里不要依赖当前时间、不要依赖外部API返回、不要依赖局部变量缓存一切决策依据都从state里拿。如果你的分支规则本身需要用到外部数据比如查数据库判断用户等级那请先把外部数据查出来、写到state里再由路由函数读取state字段而不是直接在路由函数里查数据库。2.3 多条件边一个节点同时分出多个分支前面的例子是一个节点、一个路由函数、多条去向这是最常见的一维分叉。但LangGraph还支持一个进阶玩法一个源节点上挂多条条件边每条条件边独立做一次路由判断从而实现“一个节点执行完同时触发多个分支”的效果。举个例子。一个“解析器”节点执行完之后既需要判断是否调用外部工具又需要判断该任务是否需要人工审核。这两个判断互不相关可以拆成两条独立条件边graph.add_conditional_edges(parser, decide_call_tool, {call: tool_node, skip: respond}) graph.add_conditional_edges(parser, decide_need_review, {review: human_node, direct: respond})当parser执行完LangGraph会分别评估这两条条件边每一条边都独立决定自己的下一步。如果一条边指向tool_node另一条边指向respond最终执行器会同时启动这两个节点。这里要特别说明这里的“并行”不是python多线程那种意义上的并行而是LangGraph执行器在超步层面同时调度这两个分支的执行从开发者视角看它们确实是并发推进的。这带来的一个直接好处是如果你的Agent需要同一个阶段同时干几件事比如解析完成后既要查知识库、又要查库存接口通过多条件边或者后面要讲的Send一条图定义就能描述清楚不需要人为串行。多条件边在概念上很爽但有一个副作用你必须提前想好就是状态合并。多个分支并行执行各自都会往全局state里写东西。如果大家都往同一个字段写后写覆盖先写那你的结果就会莫名其妙丢失或在分支间串扰。这个问题会在第5章专门展开这里先记住一个词channel的写入冲突。3. 常用分支模式与代码实现3.1 三路分流意图识别后的路由分派先写一个最简单、但也是最高频使用的分支模式意图三路分流。做客服类Agent的时候用户进来一句话不管多少字先让LLM做个意图分类然后根据分类结果各自走不同的处理链路。下面这个例子保持最小可运行重点展示条件边的代码组织方式。from typing import TypedDict from langgraph.graph import StateGraph, START, END class AgentState(TypedDict): user_input: str intent: str result: str def classify(state: AgentState) - AgentState: # 实际项目里这里是LLM调用为了精简我们直接模拟结果 return {**state, intent: query} def search_db(state: AgentState) - AgentState: return {**state, result: 查到数据库答案} def transfer_human(state: AgentState) - AgentState: return {**state, result: 已转入人工客服} def default_respond(state: AgentState) - AgentState: return {**state, result: 默认兜底回答你能再说一遍吗} def route_by_intent(state: AgentState) - str: return state.get(intent, unknown) graph StateGraph(AgentState) graph.add_node(classify, classify) graph.add_node(search_db, search_db) graph.add_node(transfer_human, transfer_human) graph.add_node(respond, default_respond) graph.add_edge(START, classify) graph.add_conditional_edges( classify, route_by_intent, { query: search_db, transfer: transfer_human, unknown: respond, }, ) graph.add_edge(search_db, END) graph.add_edge(transfer_human, END) graph.add_edge(respond, END) app graph.compile()当你调用app.invoke({user_input: 帮我查一下订单号})时执行器先把初始状态传给classify节点classify返回的intent被写进状态接着路由函数从状态里取出intent返回其中一个字符串执行器根据映射表把流程导向对应的处理节点。整个过程清晰、可控而且每个节点都是独立的想加一个“退款”意图只需要在三个地方加代码分类节点多返回一个值、路由函数多一个判断、映射表多一个条目。这种可扩展性正是分支结构带来的。3.2 循环与退出Agent工作流最常见形态如果说三路分流是条件边的入门题那循环就是条件边真正的高频考点。很多Agent项目的核心循环长这样模型思考 → 决定调用某个工具 → 工具返回结果 → 模型再思考 → 可能再调工具 → 直到模型认为可以回答用户为止。这个循环在LangGraph里怎么表达答案很简单条件边的目标节点可以指向它自己或者指回上游节点。def should_continue(state: AgentState) - str: if state.get(iterations, 0) 5 or state.get(finished): return finish return continue graph.add_node(agent, agent_node) graph.add_node(tools, tool_node) graph.add_node(final, final_node) graph.add_edge(START, agent) graph.add_conditional_edges( agent, should_continue, { continue: tools, # 需要下次agent再评估所以tools结束后回到agent finish: final, }, ) graph.add_edge(tools, agent)这段代码直接揭示了循环的本质条件边不是只能往“后面”走它可以让执行流跳回前面的节点。agent节点执行完如果判断还没做完就去调工具工具调完边又回到agent继续出下一次结果。每次循环我建议你在state里放一个计数器比如iterations每轮自增一次路由函数检查这个值来决定是否退出。别小看这个计数器它是防止死循环最重要的保险丝。我曾经见过一个漏了退出条件的Agent在测试环境里连续调了几十次工具把API额度打光才被我们发现。生产环境里你的循环退出条件至少要有两个一是业务规则判断比如LLM返回了“FINISH”标志位或者工具结果符合某种条件二是硬上限最大迭代次数。前者保证Agent足够聪明后者保证系统足够健壮。这两个条件一硬一软缺一不可。3.3 并行分支用Send让多个工具同时开工串行调用工具的痛点是慢。比如用户问“帮我对比一下A产品和B产品”理想做法是同时搜A的资料和B的资料而不是先搜A再搜B。LangGraph提供的SendAPI就是为了动态创建多个并行执行实例。from langgraph.types import Send def dispatch_searches(state: AgentState): queries state[queries] # 假设: [A产品评测, B产品评测] return [Send(run_search, {query: q}) for q in queries] graph.add_conditional_edges(planner, dispatch_searches) graph.add_node(run_search, run_search) graph.add_edge(run_search, aggregator)这里的语义要仔细体会。dispatch_searches不是一个普通的路由函数因为它返回的不是一个字符串而是一个Send对象列表。每个Send相当于执行器收到一个“指令”创建一次run_search节点的执行实例并给它一个独立的输入{query: ...}。如果你有两条query执行器就会启动两个并行的run_search实例各自跑完各自的任务再汇聚到aggregator节点做结果汇总。这里最容易被忽视的是状态合并。run_search实例跑完之后要往全局state里写结果。如果每个实例都直接state[search_results] result那就坏事了两个实例同时写同一个字段最终只有一个结果活下来。正确做法是在定义状态时给这个字段加上reducer告诉LangGraph“这是一个累加型字段支持多次写入”import operator from typing import Annotated, TypedDict class AgentState(TypedDict): queries: list[str] search_results: Annotated[list, operator.add]Annotated[list, operator.add]的意思是每次有分支往search_results写新值不是覆盖而是把新旧列表相加。这样每个并行搜索实例的结果都会被保留下来等所有分支执行完aggregator节点看到的search_results就是所有搜索结果的合集。这个reducer机制是LangGraph并行分支能正常运行的基石后面第5章我们再回头聊它的坑。3.4 人工介入分支interrupt实现审批暂停与恢复真实业务里很多Agent不能完全无人值守。比如订单助手要执行退款操作或者AI面试官要给出最终评分这些节点需要人确认。这时候分支逻辑的“分叉点”不只存在于图内部还存在Agent和外部世界之间。LangGraph用interrupt机制实现了这种“图-人-图”的回路。from langgraph.types import interrupt def refund_node(state: AgentState) - AgentState: # 执行到这一行时图会暂停值确认退款吗会暴露给外部调用方 decision interrupt({message: 确认退款吗}) if decision confirm: return {**state, refund_status: done} return {**state, refund_status: rejected}当图执行到interrupt这一行执行器会暂停并持久化当前状态然后把控制权交还给外部代码。外部系统比如FastAPI接口、后台管理页面拿到这个挂起任务后让人填写“同意”或“拒绝”再通过Command恢复这个线程的执行from langgraph.types import Command thread {configurable: {thread_id: order-123}} # 外部触发恢复执行传入人工决策结果 app.invoke( Command(resumeconfirm), configthread, )恢复之后interrupt那一行会返回传入的confirm节点继续往下走。也就是说interrupt在一个节点内部人为制造了一个暂停点执行到哪里暂停、恢复后往哪走完全由外部输入决定。从分支逻辑的角度看interrupt也是分支的一种只不过这个分支的决策者从“图内部的路由函数”变成了“外部的人”。凡是涉及钱、权限、隐私、高风险操作的Agent我都强烈建议在关键节点上挂一个类似的人工审批分支这是Agent能“下地干活”而不会“闯祸”的重要保障。4. 手把手搭建一个能分流的Agent4.1 场景与状态设计前面讲了不少模式这一章合起来做一个能跑的完整案例。我选一个比较有代表性的售前支持Agent用户发来问题先做意图分类如果是商品咨询并行走两个工具节点查询知识库和库存如果是退换货进入人工确认分支如果意图不清晰就直接要走clarify兜底。为什么选这个场景因为它把三路分流、并行Send、interrupt三种分支模式全涵盖进去了而且业务逻辑是大家都看得懂的电商场景。等你把这个案例跑通了再回到自己的项目里套用分支结构会顺手很多。状态设计我用一个TypedDictfrom typing import TypedDict, Annotated, Literal import operator class SupportState(TypedDict): user_input: str intent: Literal[product, refund, unknown] kb_results: Annotated[list, operator.add] stock_results: Annotated[list, operator.add] approval: str final_answer: str这里kb_results和stock_results都用Annotated[list, operator.add]是因为后面会用Send并行跑知识库查询和库存查询必须让分支的写入结果可以累加而不是互相覆盖。approval字段用来存人工介入结果。设计状态的第一个原则是把每个分支要用到的字段想清楚特别是并行分支写入的字段一开始就要加上reducer别等跑挂了再回头改。4.2 图定义、路由函数、并行节点配置接下来是图的骨架和节点函数。为了让你能直接复现我保留了完整的结构模型调用部分用注释占位核心看分支怎么写。from langgraph.graph import StateGraph, START, END from langgraph.types import Send, interrupt from langgraph.checkpoint.memory import MemorySaver # 1. 分类节点 def classify(state: SupportState) - SupportState: # 实际项目这里换成LLM调用比如prompt要求只输出product/refund/unknown text state[user_input].lower() if 退 in text or 换 in text: intent refund elif 商品 in text or 库存 in text: intent product else: intent unknown return {**state, intent: intent} # 2. 分类后的路由 def route_after_classify(state: SupportState) - str: return state.get(intent, unknown) # 3. 并行分发的路由函数返回Send列表 def dispatch_parallel(state: SupportState) - list[Send]: return [ Send(search_kb, {query: state[user_input]}), Send(search_stock, {query: state[user_input]}), ] # 4. 三个业务节点 def search_kb(state) - SupportState: return {kb_results: [知识库检索结果这个商品支持7天无理由退货]} def search_stock(state) - SupportState: return {stock_results: [库存查询结果近三日有库存可正常下单]} def human_approval(state) - SupportState: decision interrupt({message: 用户申请退换货是否需要人工审批}) return {**state, approval: decision} def clarify(state) - SupportState: return {**state, final_answer: 抱歉没理解你的意思可以再说得具体一些吗} def build_answer(state) - SupportState: answer .join(state.get(kb_results, []) state.get(stock_results, [])) return {**state, final_answer: answer or 未找到相关信息} def final_node(state) - SupportState: return state # 5. 构图 graph StateGraph(SupportState) graph.add_node(classify, classify) graph.add_node(search_kb, search_kb) graph.add_node(search_stock, search_stock) graph.add_node(human_approval, human_approval) graph.add_node(clarify, clarify) graph.add_node(build_answer, build_answer) graph.add_node(final, final_node) graph.add_edge(START, classify) graph.add_conditional_edges( classify, route_after_classify, { product: search_kb, # 这里其实会被Send覆盖下面说明 refund: human_approval, unknown: clarify, }, ) graph.add_edge(clarify, final) graph.add_edge(human_approval, build_answer) graph.add_edge(build_answer, final) app graph.compile(checkpointerMemorySaver())我故意在上面的route_after_classify映射里保留了product直接指向search_kb但因为search_kb需要并行执行所以我们还是要让product分支走dispatch_parallel。你可能会问那为什么不直接在route_after_classify里给product返回dispatch_parallel因为dispatch_parallel返回的不是字符串而是Send列表它不是条件边的标准返回类型。正确的做法是单独设置一个dispatch_parallel节点让classify之后的路由先把product引到它再由它做Send分发。修正后的映射应该这样graph.add_conditional_edges( classify, route_after_classify, { product: dispatch_parallel, refund: human_approval, unknown: clarify, }, ) graph.add_node(dispatch_parallel, dispatch_parallel) graph.add_edge(dispatch_parallel, build_answer)等一下这里有个细节要被说清楚dispatch_parallel返回的是Send列表它会把执行流“拆开”分别送进search_kb和search_stock。这两个并行节点执行完之后LangGraph执行器会在它们的公共下游节点build_answer处汇合。所以dispatch_parallel之后必须要有一个人为设计的“汇合点”否则并行分支的结果没有地方收集。这也是LangGraph构图里一个很容易犯的错误只顾着分叉忘了汇合。4.3 编译与执行结果日志这个Agent带有人工介入节点所以要跑起来必须用checkpointer原因很简单interrupt需要把线程状态持久化否则无法恢复。MemorySaver是内存版checkpointer只适合测试生产环境请换数据库后端的实现比如langgraph-checkpoint-postgres或langgraph-checkpoint-sqlite。跑一次商品咨询分支输入“这个商品还有库存吗”你会看到好几种不同的执行路径日志。下面是一次模拟运行的关键日志我整理成了易于理解的执行轨迹invoke传入初始状态{user_input: 这个商品还有库存吗}classify节点执行模拟LLM分类state更新为{intent: product}条件边评估route_after_classify返回product映射到dispatch_paralleldispatch_parallel执行返回两个Send指向search_kb和search_stock两个并行实例同时执行。search_kb写入kb_resultssearch_stock写入stock_resultsbuild_answer节点执行此时state里两个字段都已有值拼接成最终答案如果你输入“我要退款”执行轨迹则是classify返回refund条件边指向human_approval执行到interrupt时停下并保存状态外部程序拿到用户确认后调用app.invoke(Command(resumeconfirm), configthread)图从断点恢复human_approval返回走到build_answer汇总答案。这个过程我用日志验证过很多次每次看到interrupt把执行完完整整地“冻住”再原封不动地“解冻”都会觉得LangGraph在状态管理上确实做得很扎实。写到这里你会发现这个例子里我们其实已经用上了全部三种分支能力条件边做意图分流、Send做并行分发、interrupt做人工介入。把这三个能力组合好大部分真实的Agent业务场景都能表达了。5. 常见问题与排查技巧实录5.1 路由不生效、节点找不到的坑新手最常见的报错是Key not found in mapping或者Node not found。第一次看到这个报错我第一反应是代码写错了但排查来排查去发现每一种都对应一个不同的坑。第一类路由函数返回值没有出现在映射表里。比如路由函数可能返回refund但映射表里写的是returnskey对不上执行器直接抛异常。解决办法很简单先打印路由函数的返回值对比映射表。我个人的习惯是在路由函数里加一行临时的print或者通过日志记录跑一次之后立刻能定位。第二类节点名写错。add_node的时候用的名字和add_conditional_edges映射表里的目标名字不一致。这种情况通常在compile()的时候不会报错运行到条件边那一层才会炸。因此我建议你依赖graph.get_graph().draw_ascii()或者app.get_graph()打印整张图的结构一眼就能看出节点的实际名称。第三类在compile()之后又调用了add_conditional_edges。LangGraph的图定义和编译是两阶段编译之后图结构就固化了你再追加条件边不会生效有时候甚至不报错只是静默忽略。这是最隐蔽的一种。排查这类问题把compile()调用放到整个图定义的最后一行不要随手在中间编译。5.2 分支并行导致的状态写入冲突并行分支带来的状态写入冲突我愿称之为LangGraph新手第一杀手。现象是这样的你写了Send并行分发跑完之后汇总节点看到的结果只有最后一条明明两条并行任务都执行了但结果丢失了一个。原因前面提过并行实例同时往同一个state字段写入默认行为是“最后一次写入覆盖前一次”所以其中一个分支的结果被另一个盖掉了。解决方式就是Annotated[list, operator.add]这种reducer声明。它告诉LangGraph每次写入不是整体覆盖而是走一次合并函数这里是列表相加。如果你需要更复杂的合并逻辑比如按key去重可以自定义一个函数Annotated[list, merge_list]把merge_list换成你自己的合并函数就行。再补充一个更隐蔽的变体并行分支往不同字段写入一般不会冲突但如果某个字段是复合结构比如state[task][key] value这种嵌套写入在reducer层面很难处理。我的建议是并行分支尽量写扁平字段一个分支一个专属字段汇总节点再做整合不要试图让多个分支分别改同一个嵌套对象的不同部分。5.3 条件边与断点恢复的边界情况用上checkpointer之后条件边会有一个新玩法也有一个新坑。新玩法是断点调试你可以在任意节点前设置中断比如compile(checkpointermemory, interrupt_before[human_approval])让图跑到该节点前停下来你检查状态、修改状态、再恢复执行。这在调试分支逻辑时非常有用相当于给流程加了临时观察窗口。新坑是路由函数的确定性。LangGraph恢复执行时会从checkpoint恢复已跑过的节点状态已经执行过的条件边评估结果会被保留不会重新执行。但如果你在路由函数里用了随机数、当前时间、或者读外部API那么一旦因为某种原因需要重放路由结果就可能不一致。我曾经踩过的坑是路由函数里读了一个外部AB测试开关开关状态变了恢复执行后走了一条和暂停前完全不同的路。所以条件边相关的最佳实践依然是所有决策依据都进state路由函数只做纯计算。5.4 调试分支逻辑的几个有效技巧最后分享几个我自己在项目里反复使用的调试技巧它们比看文档高效得多。技巧一给state加一个路由日志字段。我通常会在每个路由函数里把本次的“来源节点、决策key、目标节点”追加进一个route_log列表这样一次运行结束后直接检查route_log就能看到整张图的路径无需打断点。技巧二把路由函数抽成独立纯函数写在图定义文件外面用单元测试覆盖每个分支。这个做法的价值在于分支逻辑可以脱离LangGraph单独验证。比如你问“intent是refund时会走到human_approval吗”一个单测就能回答。条件边本身很薄容易犯的错误基本都在路由函数里而路由函数可以被当成普通函数来测试。技巧三用graph.get_graph().draw_ascii()打印ASCII图。这个功能能让你直观看到节点和边的连接关系特别适合检查“循环是否正确闭合”“并行节点是否有汇合点”这类结构性问题。技巧四编译时临时把checkpointer关掉或者在小图里复现问题。很多分支bug是“加了checkpointer才出现”的说明问题大概率出在重放或状态序列化上这时候先把checkpointer摘掉跑一遍能快速缩小排查范围。我在实际项目中最离不开的反而是第一条“路由日志”。几乎每一个分支bug最后都是靠日志定位的。如果你准备在一个复杂Agent里大范围使用分支逻辑别吝啬这几行日志代码——它会在你排查问题时省下好几个小时。先把state设计清楚再把路由函数一个分支一个分支测好LangGraph的分支执行逻辑才会真正成为你手里的“决策中枢”而不是让你头疼的折腾源。