跳到主要内容

LangGraph：为什么 Agent 需要图式编排

如果说 LangChain 更像“把 Agent 快速搭起来”的上层框架，那么 LangGraph 更像“把 Agent 运行过程真正管起来”的底层编排层。它的核心价值不是让你多调用几次模型，而是：让复杂、长流程、有状态的 Agent 工作流可以被明确建模、恢复、干预和观测。

0. 面试速答（30 秒版 TL;DR）​

  • LangGraph 是面向 Agent 的低层编排框架和运行时。
  • 它的核心抽象是：State + Node + Edge。
  • 它特别适合：
    • 多步骤决策
    • 条件分支
    • 长流程任务
    • 需要 checkpoint、恢复、人工介入的系统
  • 和普通“链式调用”相比，图模型更适合表达循环、回退、并行和多路路由。
  • 一句话：LangGraph 解决的不是“能不能做 Agent”，而是“复杂 Agent 能不能稳定跑”。

1. 为什么 Agent 场景里，链不够、图更合适？​

简单链路通常长这样：

  • 检索
  • 生成
  • 返回

但 Agent 一复杂，很快就会出现：

  • 先规划，再执行
  • 执行失败后重试
  • 根据结果决定下一步走哪条分支
  • 中途等待人工确认
  • 某一步需要长期挂起，稍后恢复

这时如果还用“线性链条”思维，代码会越来越像：

  • 一堆 if / else
  • 一堆循环和状态变量
  • 一堆散落的重试与恢复逻辑

LangGraph 的思路是：

  • 把流程显式建成图

也就是：

  • 节点表示一步动作
  • 边表示流转关系
  • 状态表示整个流程共享的数据

2. LangGraph 的三个核心抽象​

2.1 State​

State 是整张图运行时共享和传递的数据容器。

可以理解成：

  • 当前消息历史
  • 中间推理结果
  • 检索结果
  • 是否需要人工审批
  • 当前任务进度

为什么 State 很关键？

因为 Agent 不是单次函数调用，而是一个逐步演化的过程。没有显式 State，复杂流程会很难维护。

2.2 Node​

Node 就是一段执行逻辑。

例如：

  • 分类问题
  • 调工具
  • 做检索
  • 生成总结
  • 等待人工批准

注意：

  • Node 不一定都是模型调用
  • 也可以是纯业务逻辑或外部系统调用

2.3 Edge​

Edge 决定流程从哪个节点走向哪个节点。

它可以是：

  • 固定边
  • 条件边
  • 循环边

图式建模真正比链强的地方就在这里：

  • 路由关系被显式表达出来了。

3. 一张典型的 LangGraph 流程图​

这张图体现了 LangGraph 最常见的几个能力：

  • 循环
  • 条件路由
  • 人工介入
  • 最终汇总

4. 为什么说 LangGraph 更适合“生产级 Agent”​

4.1 它强调持久化和恢复​

真实 Agent 工作流经常不是几秒内完成的。

例如：

  • 审批流要等人点确认
  • 长任务要跨进程恢复
  • 某一步调用第三方系统可能失败

如果运行状态不能保存，你就只能：

  • 从头再跑
  • 或自己手写一套状态恢复机制

LangGraph 的价值就在于：

  • 把“工作流能不能恢复”作为一等公民来设计。

4.2 它强调可观测性​

复杂 Agent 最难的问题通常不是“写不出来”，而是：

  • 为什么走了这条路径？
  • 为什么重复调用同一个工具？
  • 为什么在某个节点卡住？

图式编排天然更适合做：

  • 节点级 tracing
  • 状态快照
  • 路由调试

4.3 它更适合混合工作流​

很多真实场景不是纯 Agent，也不是纯规则流。

而是：

  • 某些步骤完全确定
  • 某些步骤交给模型判断

例如：

  • 先做固定鉴权
  • 再让模型分类
  • 分类后走不同业务分支

这类“确定性 + 非确定性”的混合工作流，用图来表达会比纯 Prompt 循环清晰得多。

5. 一个简化示例​

type AgentState = {
  question: string;
  category?: "faq" | "search";
  docs?: string[];
  answer?: string;
};

function classify(state: AgentState): Partial<AgentState> {
  return { category: state.question.includes("文档") ? "search" : "faq" };
}

function retrieve(state: AgentState): Partial<AgentState> {
  return { docs: ["文档片段 A", "文档片段 B"] };
}

function respond(state: AgentState): Partial<AgentState> {
  if (state.category === "search") {
    return { answer: `基于资料回答: ${state.docs?.join(" / ")}` };
  }
  return { answer: "这是一个 FAQ 类问题的直接回答" };
}

这个例子虽然没写完整 LangGraph API，但足够说明建模思想：

  • State 保存全局上下文
  • classify、retrieve、respond 是节点
  • 根据 category 决定是否需要检索，就是条件边

6. LangGraph 和 LangChain 怎么选？​

可以直接用这套答法：

问题更适合 LangChain更适合 LangGraph
想快速起一个工具型 Agent是不一定
需要复杂状态流转一般是
需要人工介入一般是
需要长流程恢复一般是
希望底层路径完全可控一般是

一句话总结：

  • 先要效率，偏 LangChain
  • 先要控制力，偏 LangGraph

7. 典型面试题​

7.1 为什么 Agent 编排更适合图，不适合简单链？​

标准答法：

因为 Agent 往往存在循环、条件分支、失败重试、人工介入和长期挂起。链更适合固定顺序流程，而图更适合表达复杂路由关系和状态流转。

7.2 LangGraph 的状态有什么意义？​

标准答法：

状态是整个 Agent 运行过程的共享数据面。没有显式状态，复杂流程只能靠散落变量和嵌套逻辑维持，后续做恢复、观测和调试都会变得很困难。

7.3 LangGraph 是不是只能配合 LangChain 使用？​

标准答法：

不是。LangGraph 关注的是 Agent 编排和运行时，可以和 LangChain 组件配合，但不依赖它的高层抽象才能使用。

8. 常见误区​

  • 误区一：以为图只是“画出来更好看”。 实际上图是运行模型，不只是展示模型。
  • 误区二：把每一步都交给模型。 很多节点本该是确定性逻辑，没必要让模型参与。
  • 误区三：有图就等于稳定。 如果状态设计混乱、边界条件没定义清楚，图同样会失控。
  • 误区四：忽视终止条件。 Agent 图如果没有明确退出策略，很容易进入无效循环。

9. 速记要点​

  • LangGraph 是 低层 Agent 编排框架
  • 核心抽象：State / Node / Edge
  • 适合 长流程、有状态、可恢复、可干预
  • 比链更适合表达 循环、分支、重试、人工介入
  • 和 LangChain 的关系是 底层可控编排层