深入浅出 LangGraph：它在 LLM Agent 开发中扮演什么角色？

随着大语言模型（LLM）从简单的“单轮问答”走向复杂的“自主 Agent（智能体）”，传统的线性流水线（Chains）逐渐显得力不从心。我们需要 Agent 能够进行自我反思、纠错、调用外部工具，并进行多轮迭代。

在这样的背景下，LangGraph 应运而生。作为 LangChain 生态的重要延伸，LangGraph 究竟是什么？它的核心作用是什么？本文将用通俗的语言为您深度剖析。

一、 为什么需要 LangGraph？

在理解 LangGraph 的作用之前，我们需要先看看传统的 LLM 编排框架（如 LangChain 的 LCEL）遇到了什么瓶颈。

1. 传统 LCEL：单向无环图 (DAG)

传统的 LangChain 链（Chains）本质上是单向的。数据像流水一样从节点 A 流向节点 B，再流向节点 C，最后输出。 这在数学上被称为 DAG（有向无环图，Directed Acyclic Graph）。对于简单的问答、文本翻译、文档总结等流程，这种结构非常高效。

2. 真实 Agent 需求：循环 (Loops) 与状态 (State)

然而，一个真正实用的 AI Agent 通常需要非线性的、包含循环（Cycles）的复杂工作流。例如： * ReAct 模式：LLM 思考 -> 决定调用工具 -> 执行工具 -> 观察工具输出 -> 返回 LLM 再次思考。 * 翻译与自检：生成初稿 -> 审核节点检查 -> 如果不合格，退回生成节点重写 -> 合格则输出。

传统的 DAG 框架很难优雅地表达这种“返回上一步”或“不断循环直至满足条件”的逻辑。强行在普通 Chain 中写入循环会导致代码极其混乱、状态难以追踪。

LangGraph 的核心使命，就是为了解决 LLM 应用中的“循环”与“状态管理”问题。

二、 LangGraph 的三大核心作用

1. 原生支持“循环（Cycles）”工作流

LangGraph 允许开发者将 Agent 的执行过程定义为一张“图（Graph）”。在这张图里，边（Edges）不仅可以指向下一个节点，还可以指向之前的节点，从而天然地形成循环。 这使得构建以下模式变得极其简单： * Self-Correction（自我纠错）：当代码生成 Agent 写的代码运行报错时，自动把错误信息带回生成节点，让其重新编写，直到编译通过。 * Iterative Refinement（迭代优化）：撰写文章时，写作节点与评审节点之间可以循环对齐，直至打分达标。

2. 集中式的“状态管理（State Management）”

在 LangGraph 中，所有的节点都围绕着一个统一的 State（状态对象） 进行读写。 * 状态流转：当图中的某个节点被执行时，它会输出一些更新，这些更新会被自动合并（Reduce）到全局 State 中。下一个节点读取这个最新的 State 继续执行。 * 好处：这避免了在节点之间繁琐地传递局部变量，每个节点只需要关注它要读取什么状态、修改什么状态，大大解耦了业务逻辑。

3. 内置的“持久化与时间旅行（Persistence & Time Travel）”

由于 LangGraph 记录了每一次状态变更，它原生支持了许多企业级的复杂交互特性： * Human-in-the-loop（人机协同）：可以在某个敏感节点（如发邮件、扣款）前暂停图的执行，等待人类用户审批（Approve/Reject）。审批通过后，图从暂停的状态继续向下执行。 * Time Travel（时间旅行）：开发者或用户可以查看 Agent 历史执行中的任何一步状态，甚至可以“回滚”到过去的某个状态，修改参数后重新沿着另一条路线运行。

三、 LangGraph 的核心概念

要使用 LangGraph，只需要理解以下三个核心组件：

1. State (状态)：定义了图的“共享内存”。它是一个数据结构（如 Python 的 TypedDict），规定了图在运行过程中需要维护哪些数据（例如：聊天记录、当前提取的参数、报错信息等）。
2. Nodes (节点)：图的动作执行者。每个节点通常是一个 Python 函数，它接收当前的 State 作为输入，执行一些操作（例如调用 LLM、执行数据库查询），并返回更新后的 State。
3. Edges (边)：定义了节点之间的连接规则。
4. 普通边（Normal Edges）：硬编码的流转路径（如：节点 A 执行完必须去节点 B）。
5. 条件边（Conditional Edges）：根据当前 State 中的数据，动态决定下一步去哪里（例如：如果 LLM 判断任务已完成，则走向 END 节点；如果需要调用工具，则走向 Tools 节点）。

四、 一个直观的代码逻辑对比

如果我们想用伪代码表达一个“带工具调用的 Agent 循环”：

不使用 LangGraph（纯代码逻辑控制）：

你需要写一个复杂的 while True 循环，并在循环内部手动管理 LLM 的状态和工具的输出，一旦业务逻辑变复杂（比如多 Agent 协作），代码将难以维护：

state = {"messages": [user_input]}
while True:
    response = llm.call(state["messages"])
    state["messages"].append(response)

    if not response.tool_calls:
        break # 结束

    for tool_call in response.tool_calls:
        tool_result = execute_tool(tool_call)
        state["messages"].append(tool_result)
    # 继续循环...

使用 LangGraph：

你可以像画流程图一样，将每个模块清晰定义，由引擎自动调度状态和循环：

from langgraph.graph import StateGraph, END

# 1. 定义状态和图
workflow = StateGraph(AgentState)

# 2. 添加节点
workflow.add_node("agent", call_model)
workflow.add_node("action", call_tool)

# 3. 设置起点
workflow.set_entry_point("agent")

# 4. 添加条件边：如果需要调工具，去 action 节点；否则结束
workflow.add_conditional_edges(
    "agent",
    should_continue, # 判断函数
    {
        "continue": "action",
        "end": END
    }
)

# 5. 从 action 节点循环回到 agent 节点
workflow.add_edge("action", "agent")

# 6. 编译运行
app = workflow.compile()

五、 总结

简单来说，LangGraph 的定位不是要替代 LangChain，而是为其提供更高级的“大网调度能力”。

• 如果你的应用是线性的（如：读取 PDF -> 向量检索 -> 提问回答），LangChain 就足够简单好用。
• 如果你的应用是复杂的、包含循环的、多 Agent 协同的（如：编写代码 -> 运行报错 -> 自动修复 -> 重试；或者需要人类干预审批），那么 LangGraph 是目前最优雅、最强大的解决方案。