LangGraph：用「状态图」驯服失控的 LLM 应用 来源 : 华清远见     2026-09-04

相信不少同学用 LangChain 写过复杂对话机器人：几个 Chain 串起来，再加点 Memory 和 Tool，看着挺美好。可一旦流程里出现条件分支、循环重试、人工介入，代码就迅速膨胀成一座"if-else 迷宫"——调试两小时，报错两行泪。这并非你水平不行，而是 Chain 的线性执行模型天然不适合表达复杂工作流。而 LangGraph 的出现，正是为了解决这个问题。

图1 · LangGraph 总体架构：以共享 State 为中心的节点图

一、核心思想：把 LLM 应用建模为「状态图」

LangGraph 由 LangChain 团队推出，它的核心思想极为直观：将整个应用抽象为一张有向图（Directed Graph）。每个节点（Node）是一个处理步骤——可以是调用 LLM、执行工具或纯 Python 函数；边（Edge）决定执行顺序，还支持条件边实现动态路由和循环。

💡 一个比喻：

把 State 想象成一块"共享白板"，每个节点干完活就在白板上写下结果，下一个节点读白板、干活、再写回去。谁来擦黑板、谁先谁后，都由图的结构说了算。

与 LangChain 的 Chain 模式对比，差异一目了然：

图2 · 共享白板：各节点读写同一份 State，条件边决定路由走向

二、实战：构建一个「客服工单处理 Agent」

下面用约 40 行代码实现一个带人工审核的工单处理流程：

from typing import Annotated, TypedDict

from langgraph.graph import StateGraph, START, END

# 1. 定义共享状态：整块"白板"的字段结构

class TicketState(TypedDict):

    content: str                  # 工单内容

    category: str                 # 分类结果

    draft: str                    # AI 生成的回复草稿

    approved: bool                # 人工审核结果

# 2. 定义节点：每个节点读 State、返回要更新的字段

def classify(state: TicketState):

    # 调用小模型做分类（省 token，快）

    category = llm_classify(state["content"])

    return {"category": category}

def draft_reply(state: TicketState):

    # 大模型根据分类生成回复草稿

    draft = llm_generate(state["content"], state["category"])

    return {"draft": draft}

def human_review(state: TicketState):

    # 中断点：暂停等待人工审批（interrupt_before 触发）

    return {"approved": wait_for_approval(state["draft"])}

# 3. 组装图：节点 + 条件边

graph = StateGraph(TicketState)

graph.add_node("classify", classify)        # 节点1：分类

graph.add_node("draft", draft_reply)        # 节点2：起草回复

graph.add_node("review", human_review)      # 节点3：人工审核

graph.add_edge(START, "classify")           # 入口 → 分类

graph.add_edge("classify", "draft")       # 分类 → 起草

graph.add_edge("draft", "review")         # 起草 → 审核

# 4. 条件边：审核不通过则打回重写（循环！Chain 做不到）

graph.add_conditional_edges("review",

    lambda s: "draft" if not s["approved"] else END)

app = graph.compile()                  # 编译并运行

result = app.invoke({"content": "无法登录账号，验证码收不到"})

注意最后那个条件边：审核不通过就回到 draft 节点重写。这种"打回重做"的循环，在 Chain 模式里得靠递归和异常处理硬造，而在 LangGraph 中只是图的一条边而已。

三、企业级落地：三个绕不开的坑

1状态持久化：Agent 服务一旦重启，内存中的对话状态全部蒸发，正在等待审批的工单直接"失忆"。必须启用 LangGraph 的 Checkpointer，将 State 落到 PostgreSQL 或 Redis，实现断点续跑与全链路回溯。

2人在回路（Human-in-the-loop）：在合同审批、退款处理等高风险环节，用 interrupt_before 参数在关键节点前暂停，推送通知给人工，审批通过后从检查点恢复执行——注意这是异步中断，不是简单弹个确认框。

3Token 成本黑洞：循环每转一圈都会携带全部历史上下文重新调用 LLM，4 轮循环的实际开销可达单次调用的 5-8 倍。优化思路：分类、路由等简单决策交给小模型，大模型只负责真正的推理与生成。

图3 · 人在回路：Agent 在高风险节点暂停，等待人工确认后继续

结语

LangGraph 的本质，是把 LLM 应用从"提示词堆叠"拉回软件工程的正轨：显式的状态定义、清晰的流转图、可持久化的检查点。如果你的 Agent 已经复杂到需要分支、循环和人工介入，是时候放下 Chain，画一张自己的"状态图"了。