跳到正文

LangGraph 状态机与场景

LangGraph 状态图机制、典型场景与复杂工作流,补充适用边界与工程取舍

原题:LangGraph作为基于有向图的Agent编排框架,适用于哪些典型应用场景?其状态机机制如何支持复杂工作流建模?

Agent · 淘天真题

回答与解析

典型应用场景

LangGraph适合需要循环、条件分支和状态持久化的复杂Agent场景:

场景 为什么适合
多轮对话Agent 支持循环边实现"思考-行动-观察"的ReAct循环,状态持久化保留对话上下文
代码生成与调试 写代码→执行→报错→修复的循环工作流,需要回溯和重试机制
研究/搜索Agent 搜索→阅读→判断信息是否足够→决定继续搜索或终止的循环决策
审批工作流 多级审批、驳回重提、人工介入等复杂状态流转
多Agent协作 不同Agent节点间通过共享状态池通信,支持动态路由

状态机机制的核心设计

1. 持久化状态(State)

  • 定义TypedDict作为全局状态容器,所有节点读写同一状态对象
  • 支持checkpoint机制,可任意节点暂停/恢复,实现断点续传

2. 循环边与条件路由

# 核心:edges支持条件判断和循环
def router(state):
    if state["is_complete"]: 
        return END
    return "continue_node"  # 形成循环

graph.add_conditional_edges("process_node", router)

3. 与传统DAG的关键差异

  • Airflow/LCEL:DAG无环,适合ETL等线性流水线
  • LangGraph:显式支持环,天然适合Agent的"感知-决策-执行"闭环

一句话总结

LangGraph = 状态机 + 持久化 + 图结构,填补了"简单链式编排"到"复杂自主Agent"之间的工程空白。

学习建议

建议系统学习该知识点

口语版讲法(约4分钟)

  • 一句话定位:LangGraph本质是有环图的状态机,解决Agent闭环
  • 典型场景:多轮对话、代码调试、审批工作流
  • 状态机机制:全局状态+checkpoint+条件路由
  • 边界划分:与Airflow/LCEL的对比
  • 落地风险与收尾

这道题其实是在问,当你需要构建一个能自我循环、根据条件跳转、并且能记住中间状态的Agent时,该怎么编排。LangGraph的核心就一句话:它是一个有环图的状态机。说白了,传统DAG只能一条道走到黑,但Agent需要“想→做→看结果→再想”这种闭环,LangGraph就是专门干这个的。

我具体说一下几个典型场景。先看多轮对话Agent,比如客服。你问一句,它答一句,但中间可能需要查订单、查政策,甚至要用户确认,这些步骤不是线性的。LangGraph的循环边可以让它“思考→调用工具→观察结果→再思考”,状态持久化则记住了整个对话上下文,不会丢。接着说代码生成与调试,写代码、执行、报错、修复,这个循环天然适合有环图。再补充审批工作流,比如多级审批、驳回重提,状态机里的条件路由正好能处理这种“如果驳回就走回上一级”的逻辑。

再聊聊它的状态机机制。LangGraph里有一个全局状态,一般用TypedDict定义,所有节点都读写这个状态对象。你可以在任何节点设置checkpoint,这样就能暂停、恢复,甚至断点续传。举个例子,一个长流程跑了一半挂了,恢复后能从checkpoint继续,不用从头来。条件路由也很直观,比如你写个router函数,判断state里某个字段,如果任务完成就结束,否则跳回处理节点形成循环。

这里有个边界划分:传统框架比如Airflow或者LCEL,它们是无环图,适合ETL或者简单的链式调用。但Agent场景天然需要环,所以LangGraph填补了从简单编排到自主Agent之间的空白。真正落地时,我常常把LangGraph和别的方案混用,比如用LangGraph做控制流,但具体工具调用还是走Function Calling。

落地时有个前提:你的状态设计必须清晰,否则全局状态会变成一个大杂烩,节点之间耦合严重。常见失败场景就是状态里塞了太多临时变量,导致条件路由逻辑爆炸。我会特别关注状态的结构化,把持久化数据和临时数据分开。另外,checkpoint虽然好用,但写频繁了性能会下降,所以上线我会控制checkpoint的频率,只在关键节点做。

不过,LangGraph的循环边虽然灵活,但如果没有终止条件,很容易死循环。所以我会在router里加一个最大迭代次数,防止Agent无限循环。这其实引出一个问题:你怎么保证Agent不会在循环里出不来?

所以,我更倾向把LangGraph看作一个工程框架,它解决的是“怎么把Agent的闭环落地成代码”的问题,而不是一个魔法工具。选型时我会问自己:这个场景需要环吗?如果不需要,用LCEL就够了。如果需要,LangGraph是首选,但一定要把状态和终止条件设计好。

关键一句:LangGraph的循环边如果没有终止条件,容易死循环,需要在router里加最大迭代次数。

面试官还可能这样问

  1. 问法 1 · 场景切入

    假设你在做一个智能客服Agent,用户问“帮我查订单”,然后又说“改下地址”,接着问“退款多久到”。这种多步操作需要反复确认和跳转,你会怎么用LangGraph来编排这个流程?

  2. 问法 2 · 层层追问

    Agent工作流你一般怎么设计?……如果任务需要反复执行某个步骤,比如代码生成后运行报错再修复,你的框架怎么支持这种循环?……那状态怎么在循环间保持?

  3. 问法 3 · 直球架构

    LangGraph用有向图+状态机来编排Agent,请说一下它适合哪些场景?以及状态机机制具体怎么支持复杂工作流建模?

同模块相关题目