条件边(Conditional Edge)：给 Agent 工作流装上智能分拣岔道

可视化演示

展示LangGraph条件边的路由机制、多步推理工作流及条件边与普通边的对比。通过状态图节点、路由函数和动态分支直观呈现非线性控制流。

条件边定义

快递分拣中心里最忙碌的岗位不是搬包裹的工人，而是站在岔道口的分拣员。传送带把包裹送到脚边，他只看一眼标签，就决定把包裹推向左边的滑槽还是右边的滑槽。这个“看一眼、推一下”的动作，让整条流水线从一条死板的直线变成了一张能自动分流的网。

在 LangGraph 状态图中，分拣员就是条件边。图里的“节点”是处理包裹的工作台，比如大模型调用、代码检查、数据库查询；图里的“边”是包裹走过的传送带。普通边是固定传送带，只要上一步结束，包裹必然去下一站。条件边则不同：它会在运行时调一个路由函数，把当前状态交过去，然后根据返回结果决定下一步走进哪个节点。

这个机制构成了 Agent 工作流中的非线性控制流：流程不再是一条直线，而是能分叉、能回头、能提前结束的网状结构。你可以把它理解成一个带传感器的道岔——包裹重了就送去加急线，轻了就送去普通线，一切都由“读状态”完成。

条件边并不神秘：它只是在节点与节点之间加了一道“读标签、选滑槽”的闸门。理解这一点，后面的状态字段、路由函数、END 终止符都会顺理成章。

状态字段路由

分拣员从来不会把整个包裹拆开检查，他只需要看标签上的目的地字段。在 LangGraph 里，条件边同样只看状态字典中的某个字段。这个字段可能是大模型刚刚写出的判断结果，比如一个节点用 LLM 判断用户意图后，把 "intent": "refund" 写进状态；下一个条件边就只读 state["intent"]，然后决定去退款流程还是人工客服。

这种“字段即标签”的设计让路由变得清晰：节点负责生产字段，条件边负责消费字段。生产字段的可以是 LLM，也可以是普通 Python 函数、工具返回结果、用户输入。关键是，字段必须先被写入状态，条件边才能读到它。如果上一个节点忘了写字段，路由函数就会像分拣员看到一张空白标签一样懵住，通常抛出一个 KeyError。

字段的值可以是字符串、布尔值，甚至数字。LangGraph 不关心你存了什么，它只负责把你给的字段交给路由函数。于是，中间结果驱动分支变成了现实：Agent 先做一次判断，把判断结果写进状态，再让条件边决定下一步是继续搜索、直接回答，还是换个工具重试。

字段路由让“模型判断结果”和“流程走向”解耦。模型只需要负责把一个判断写进状态，流程该往哪走，由条件边这张地图说了算。

路由函数编写

分拣员上岗前要背熟一套规则：看到“易碎”走慢速线，看到“加急”走快速线，看到“生鲜”走冷链线。这些规则就是路由函数。在 LangGraph 中，路由函数是一个普通的 Python 函数，输入是当前完整状态，输出是一个表示下一节点名称的字符串。

比如你可以写一个函数：如果状态里 category 是 "math"，就返回 "solve_math"；否则返回 "general_answer"。LangGraph 支持两种写法：一是让函数直接返回节点名字；二是让函数返回一个“路由键”，再用一个可选的映射表把键翻译成节点名字。第二种写法更适合当函数返回多个键、需要统一管理路由表的时候。

编写路由函数的核心原则是正确性：它必须对所有可能的状态值都有明确的去处。如果某天 category 变成了 "unknown"，而路由表里没有这个键，程序就会直接报错。所以成熟的路由函数通常会写一个默认分支，就像分拣员遇到不认识的地址时，会先把包裹送去“问题件处理区”。

路由函数不需要访问什么隐藏魔法，它就是纯逻辑：读状态、算结果、返回字符串。让它保持简单，工作流才容易调试，也容易测试。

终止条件END

一条分拣线如果永远没有出口，包裹就会在传送带上打转，最后堆积成山。为了避免这种情况，分拣中心一定会有一个“装车出口”。在 LangGraph 中，这个出口就是 END。

条件边负责分流，但也必须负责喊停。当你希望流程走完时，就让路由函数返回字符串 "END"。LangGraph 识别到这个特殊节点名后，会立即停止当前图的执行，把最终状态返回给调用方。这个设计让循环成为可能：一个工作流可以不断回到某个节点重试，但只要条件边里有分支通向 END，流程最终就能收敛。

如果没有 END，一个循环图就会永远运行下去，就像分拣员不停把包裹送回同一道传送带，却永远不装车。所以在设计循环时必须反复确认：所有可能的路径上，是否至少有一个条件分支最终指向 END。这相当于给工作流装了一个安全出口。

掌握 END，你才真正掌握了循环图的“刹车片”。条件边负责灵活，END 负责收场，两者配合才能构建可靠的工作流。

动态分支构建

真实的快递分拣中心不是只有一个岔道口。包裹可能先被分到“同城线”和“跨城线”，同城线内又被分成“文件类”和“包裹类”，遇到地址不清的还会被送回人工复核台。这种层层分岔、甚至循环回头的结构，就是动态分支构建。

在 LangGraph 中，你可以把多个条件边像积木一样拼起来：节点 A 读完状态后指向 B 或 C；B 处理完后又可能通过条件边回到 A，或者走向 END。这样就能构造出“重试三次仍失败则转人工”的循环，也能构造出“先生成草稿，再判断是否安全，不安全就重新生成”的审核循环。每一步的判断都基于当时的实时状态，因此每个循环都是动态的。

这就是非线性控制流的真正威力：流程不再是写死在代码里的线性 Chain，而是由状态驱动的行为网络。同一个图，面对不同输入，会走出完全不同的路径。复杂工作流由此诞生：可以拆解问题、并行处理、反思重试、逐步验证。

动态分支是把 Agent 从“单线程背台词”升级为“随机应变的现场调度”的关键。多分支、嵌套路由、循环回溯，归根结底都是同一个条件边机制的组合应用。

普通边对比

分拣中心里有一种永远不变的传送带：从供包台到扫描仪，再从上包口到下包口，所有包裹都走同一条路。这是最可靠的路径，也是普通边。普通边适合那些不管输入是什么都必须执行的步骤，比如加载配置文件、调用基础模型、记录日志。

普通边的特点是编译时就固定了：A 的下一个节点永远是 B，不存在第二种可能。条件边则把选择推迟到运行时，让“包裹到了那个路口再看标签决定去向”。二者互补，共同构成了完整的状态图。一味的普通边会让工作流僵化成线性链，一味的条件边则会让图复杂到难以维护。

用图论的语言看，一张状态图是节点和两类边的集合：普通边提供骨架，条件边提供灵活。普通边保证主干稳定，条件边在关键位置打开岔道口，让 Agent 能根据中间结果随机应变。这张混合图既能像流水线一样稳定执行必要步骤，又能像智能交通系统一样动态调度车流。

普通边和条件边不是对立关系，而是分工关系。最好的工作流不会全用普通边，也不会全用条件边，而是在“必须做”和“看情况做”之间找到平衡。

调试技巧

当分拣员把本该去上海的包裹推去了广州，主管第一件事不是骂人，而是查看当时包裹的标签和分拣员看到的路由表。调试条件边也是一样：你要同时看到“状态”和“路由结果”，才能知道问题出在输入还是判断逻辑。

最直接的技巧是在条件边执行前后打印状态快照。比如在节点 A 结束时打印 state，再打印路由函数返回的下一节点名。如果状态里 intent 是 "refund"，路由却返回了 "technical"，那问题大概率在路由函数或映射表；如果 intent 本身就是 None，那问题在产生字段的上游节点。

边界值测试同样重要。路由函数可能对 "yes" 返回正常，但遇到 True 或 1 就崩溃。你应该像测试普通函数一样，为路由函数准备典型值、空值、异常值。可视化追踪也是工程利器：画出图，标出每一次实际走过的边，像快递物流轨迹一样回放流程，很快就能定位到是哪一道岔打错了方向。

条件边本身是个确定性函数，所以它出的问题通常都能通过“看输入、看输出”定位。学会给每次分流留痕，你就能从“玄学调参”走向“工程化调试”。

应用场景

当一家快递公司把分拣员从“凭感觉扔包裹”升级成“扫码读标签、系统自动分路”，整体效率会立刻上升。条件边对 AI 工作流的意义也是如此：它让 Agent 根据任务的实际状态，走到最合适的处理分支上。

在客服场景中，用户消息先经过意图识别节点，把结果写进 state["intent"]，条件边再决定走退款、售后、技术还是人工客服。在多步推理场景中，Agent 先判断任务需要计算还是需要查资料，条件边把它路由到计算器工具或搜索工具，避免让一个 LLM 硬扛所有事。在安全审核场景中，生成内容先过审核节点，条件边根据审核结果决定直接返回还是进入重写流程，这比生成后一刀切拦截可靠得多。

条件边带来的不仅是功能，更是质量与可靠性。每个任务都被送到最适合它的下一站，而不是被迫走一条固定路线。就像包裹被准确送入对应城市线路，Agent 的成功率会在一次次正确路由中稳步上升。

应用场景千变万化，底层的分拣逻辑始终一致：读状态、选分支、走下去。条件边是最朴素也最强大的流程决策机制，把 Agent 从一个“死板执行者”变成了“会看路的智能工作者”。

AI 应用场景

Python 演示

class TinyGraph:    def __init__(self):        self.nodes = {}        self.conditional_edges = {}     def add_node(self, name, fn):        self.nodes[name] = fn     def add_conditional_edges(self, source, router, mapping):        self.conditional_edges[source] = (router, mapping)     def run(self, start, state):        current = start        while current != "END":            state = self.nodes[current](state)            if current in self.conditional_edges:                router, mapping = self.conditional_edges[current]                key = router(state)                current = mapping[key]            else:                raise RuntimeError("no conditional edge from " + current)        return state  def classify(state):    text = state["query"].lower()    if any(c in text for c in "1234567890"):        state["category"] = "math"    else:        state["category"] = "general"    return state  def solve_math(state):    state["answer"] = "need calculator tool"    return state  def answer_general(state):    state["answer"] = "search knowledge base"    return state  def route_after_classify(state):    return state["category"]  def main():    graph = TinyGraph()    graph.add_node("classify", classify)    graph.add_node("solve_math", solve_math)    graph.add_node("answer_general", answer_general)    graph.add_conditional_edges(        "classify",        route_after_classify,        {"math": "solve_math", "general": "answer_general"},    )    result = graph.run("classify", {"query": "calculate 3*4"})    print(result["category"], "->", result["answer"])  if __name__ == "__main__":    main()

1. def add_conditional_edges(self, source, router, mapping):在图上登记一条条件边：从哪个节点出发、用哪个路由函数、映射到哪些下一节点。
2. state = self.nodes[current](state)执行当前节点，节点接收状态并返回更新后的状态。
3. key = router(state)模拟 LangGraph 执行阶段：把当前状态交给路由函数，得到分支键。
4. current = mapping[key]拿着分支键查路由表，得到真正的下一个节点名；如果键不存在会抛 KeyError。
5. state["category"] = "math"节点把模型判断结果写进状态字段，供后续条件边读取。
6. graph.add_conditional_edges("classify", route_after_classify, ...)组装图：从 classify 节点出发，按 state["category"] 选择下一站。

常见误区

面试题