LangGraph 是当前 Agent 开发领域里绕不开的一个框架。这篇文章不会按照官方文档的调子平铺直叙——它更像是一次认知上的"徒步穿越"，从最原始的 LLM 痛点出发，一路走到生产级的 Agent 系统。

这篇文章怎么读

建议按顺序阅读。每一章都在为下一章铺路，跳着看很容易在某个环节卡住——尤其是第二部分关于 LangGraph 核心机制的内容，那是后面所有设计模式的基石，值得多花点时间去消化。

读完你会带走什么：

• 真正理解增强型 LLM 的底层原理，而不仅仅是 API 调用
• 彻底搞懂 ReAct Agent 的本质——它到底在循环什么
• 掌握 LangGraph 的 State、Node、Edge 和执行引擎
• 拿到六大 Agent 设计模式的完整代码实现
• 知道面试时怎么把 Agent 架构讲出层次感
• 了解 LangGraph 的生产级特性：Memory、人在回路、Streaming、部署

第一部分：为什么需要 LangGraph

第一章：从普通 LLM 到增强型 LLM

1.1 裸调 LLM 的四个硬伤

输入一段字，输出一段字——这是最原始的 LLM 调用方式。看起来没什么问题？但在真实业务场景里，它有四个致命的短板：

1.2 第一重增强：结构化输出

先看一段代码：

很多人以为 Zod 直接"约束"了 LLM 的输出——这是一个常见的误解。整个流程其实是四步走：

1. 翻译：Zod 被 LangChain 内部的库转换成 JSON Schema。
2. 传递给 LLM API：这个 JSON Schema 被塞进 OpenAI 的 response_format 或 tools 参数——相当于给 LLM 发了一张"必须按此格式填写的答题卡"。
3. LLM 按 Schema 生成 JSON 字符串。
4. Zod 做运行时验证：字段全不全？类型对不对？不对就抛错误，阻止问题数据继续往下流。

值得注意的是代码里的 .describe() 非常关键——它会被翻译成 JSON Schema 里的 description 字段，LLM 会阅读这段描述来理解每个字段应该填什么内容。如果写成 z.string("描述")，Zod 会把 "描述" 当作默认值而不是提示词，LLM 根本看不到这个信息。

1.3 第二重增强：工具调用

结构化输出解决了"说出来的话格式对不对"的问题。但 LLM 还有一个更致命的局限——它什么也做不了。它只能给你一个"想法"，不能去执行任何实际操作。工具调用的本质，就是让 LLM 能够写"派工单"。

用个比喻来帮助理解：LLM 就像一个只会写派工单的经理，它不能自己去搬砖。工具就是下面的工人，派工单上写了"去干这个活儿"，工人真的去干，干完把结果拿回来交给经理。经理看了结果，再决定下一步是继续派工还是给客户交差。

这个比喻引出了一个自然而然的问题：谁来当"跑腿的"——负责"拿派工单→找工人→把结果送回经理→经理继续写派工单→..."这个循环？这个"跑腿的"，就是 Agent。而这个循环的编排，就是 LangGraph 要做的事。

第二章：从增强型 LLM 到 Agent

2.1 一个自然的演化

现在你已经学会两个增强手段：withStructuredOutput 让 LLM 的输出格式可控，bindTools 让 LLM 能写"派工单"。大脑会自动把它们串起来：用户提问→LLM 思考需要什么工具→写派工单→工人执行→结果反馈→LLM 继续思考→直到给出最终答案。这就是 Agent 循环。

学术上最早系统化这个模式的，是 2022 年 Google 和 Princeton 的 ReAct（Reasoning + Acting）论文。

2.2 ReAct：让 LLM"边想边做"

ReAct 的核心思想其实非常朴素：让 LLM 在思考的同时，可以调用外部工具来获取信息或执行操作，然后把结果带回到思考过程中。整个过程可以看作是一个"思考-行动-观察"的循环。

2.3 手写一个 ReAct 循环——看看有多容易崩

在 LangGraph 出现之前，这个循环只能靠手写。虽然看起来"能跑"，但实际上藏着五个你迟早会踩到的大坑：

2.4 我们需要一个什么样的框架

从上面的分析可以归纳出 Agent 框架的五个核心需求：

1. 状态管理：每一步的状态要结构化、可追踪、可持久化
2. 控制流编排：支持顺序、分支、循环，且能可视化
3. 错误恢复：某一步失败了，能从失败点重试，而不是从头来
4. 人在回路：能在任意步骤暂停，等人类审批后继续
5. 可观测性：能追踪每一步的执行状态、输入、输出、耗时

2.5 LCEL vs LangGraph

在深入 LangGraph 之前，先搞清楚一个问题：如果只是"链条"，为什么不用 LangChain 的 LCEL？核心区别在于：LCEL 适合线性串联的简单管道，而 LangGraph 的图结构适合有分支和循环的复杂场景。

简单来说：单次转换任务用 LCEL，多步骤工作流和 Agent 用 LangGraph。

第二部分：LangGraph 核心机制

第三章：State — Agent 的共享记忆

3.1 什么是 State

LangGraph 里，State 就是一张跟着数据一起跑的便签本。图上每个节点（Node）都能读这张便签，也能往上贴新内容。所有节点看到的 State 是同一份。它定义了便签本上有哪些字段、各自是什么类型，也为后面的 Node 函数里提供了完整的类型提示。

3.2 State 是"累积"的，不是"替换"的

这是新手最容易搞错的地方。每个 Node 返回的是一个"部分 State"，而不是完整的 State。LangGraph 会自动将部分 State 合并到当前的 State 对象中。默认情况下，同名字段是直接覆盖。如果你需要更复杂的合并逻辑，比如追加到数组而不是覆盖，可以用 reducer 来实现。

3.3 State 为什么是 LangGraph 最核心的设计

和手写 Agent 循环对比一下就清楚了：手写循环的状态散落在数组里，中间状态只能靠日志查看，无法从中间恢复，不同分支的状态容易互相污染。而 LangGraph 的 State 是一个结构化的对象，每个 checkpoint 都有完整的快照，可以从任意节点继续执行，每次调用都有独立的 State，调试时还可以通过 LangGraph Studio 可视化 State 的变化。

第四章：Node — Agent 的执行单元

4.1 Node 是什么

Node 是 LangGraph 里真正"干活"的地方。它的签名非常统一：接收完整的当前 State，执行一些操作，然后返回一个"部分 State"，LangGraph 会自动将其合并到全局 State 中。一个 Node 可以干任何事情：调用 LLM、调用工具或 API、读写数据库、执行纯计算逻辑，甚至只是记录日志。LangGraph 不在乎 Node 里面做什么，它只在乎入参和出参的格式。

4.2 Node 的返回值如何影响 State

Node 返回的部分 State 会与当前 State 合并：已有字段被覆盖，新字段被添加，未涉及的字段保持不变。

4.3 区分 Node 和路由函数

有一个常见的混淆点：Node 是消费 State、返回部分 State 的函数，用 .addNode() 注册。而路由函数是只读 State、返回目标节点名的函数，直接作为参数传给 .addConditionalEdges()。路由函数不往 State 里写任何东西，它只负责"指路"。

第五章：Edge — Agent 的控制流

5.1 两种边

LangGraph 里只有两种边：固定边和条件边。固定边是无条件的，A 执行完就去 B。条件边是在 A 执行完后，根据一个路由函数的返回值，决定去 B、C 还是 D。

5.2 起点和终点

每个图都有隐式的 __start__ 和 __end__ 节点。你用 .addEdge("__start__", "firstNode") 来定义图的入口，用 .addEdge("lastNode", "__end__") 来定义出口。规则很简单：每个图必须至少有一条从 __start__ 出发的边，每个最终会终止的分支必须有一条到 __end__ 的边。

5.3 Fan-out 和 Fan-in

当一个源节点有多条出边指向不同目标时，LangGraph 会自动并行执行这些目标节点，这就是 Fan-out。反过来，当多个源节点指向同一个目标节点时，目标节点会等待所有源节点完成后才启动，这就是 Fan-in。这两种行为都是引擎自动处理的，你不需要写任何额外的并行或等待代码。

第六章：Pregel 执行引擎 — 到底怎么"跑"的

6.1 图计算和 Pregel

LangGraph 的执行引擎基于 Google 2010 年发表的 Pregel 图计算模型。核心思想很简单——每个"超级步"（Superstep）里，找出所有"就该在这一步执行"的节点，并行执行它们，收集它们的输出更新全局状态，然后重复，直到没有更多节点需要执行。

6.2 完整执行追踪

通过一个"生成笑话"的例子可以看到一个完整的执行过程：从起点开始，经过笑话生成节点，条件边检查笑话质量，如果合格则进入优化节点，如果不合格则直接结束，优化后再经润色节点，最终到达终点。每一步 State 都在累积——初始用户输入、生成的笑话、优化后的版本、最终版本，一个都不少。

6.3 隐式屏障

当多条边的目标指向同一个 Node 时，LangGraph 自动形成隐式屏障。引擎会统计每个节点的入度（指向它的边的数量），然后在运行时维护一个计数器。只有当计数器等于入度时，这个节点才被激活执行。这是 Pregel 模型的原生语义。

6.4 并行执行

反过来，当多条边从同一个节点发出、指向不同目标时，LangGraph 会在同一超级步内同时启动所有就绪的节点。Node 之间的执行顺序是不确定的，它们的执行结果会按顺序合并到 State 中。

6.5 编译和调用

.compile() 会验证图的结构合法性，预计算每个节点的入度，返回一个编译后的实例。.invoke() 会创建初始 State，然后进入 Pregel 执行循环，直到所有路径都到达终点，最后返回最终 State。

第三部分：六大 Agent 设计模式

第七章：Prompt Chaining（提示链）

什么时候用

当任务可以拆成明确的、有先后顺序的步骤，上一步的输出是下一步的输入时，Prompt Chaining 是最自然的选择。典型场景包括：写一篇文章（生成大纲→撰写正文→润色→翻译）、代码审查（读取代码→分析问题→生成修复建议→验证修复）、数据分析（提取数据→清洗→分析→生成报告）。

核心思路

这是一个直线型的流程图：每一步都聚焦一个子任务，前一步的输出作为后一步的输入。与单次 LLM 调用相比，每一步都可以检查、修改和缓存中间结果，质量更高，可控性更强，虽然延迟会增加，但调试起来也更容易。

第八章：Routing（路由）

什么时候用

当输入的类型差异很大，需要先"分类"再交给不同的处理器处理时，Routing 是最合适的选择。和 Prompt Chaining 的关键区别在于：Chaining 是一条线，所有节点都执行；Routing 是分叉树，根据条件只选一条路走。典型场景包括：客服系统、内容平台审核、代码助手等。

核心思路

先有一个分类器节点，判断输入属于什么类型，然后路由函数根据分类结果决定下一步走哪条分支。分类器通常使用 withStructuredOutput 强制 LLM 只返回预定义的类别值，保证路由函数不会收到"不存在的节点名"。只有被选中的分支节点会被执行，其他分支从未启动。

第九章：Parallelization（并行化）

什么时候用

当多个子任务互相独立——彼此没有依赖——可以同时执行，最后汇总结果时，Parallelization 是理想选择。和 Routing 的关键区别：Routing 是选一条路，Parallelization 是所有路一起走，然后在终点等齐了再汇总。典型场景包括：同一主题同时生成多种内容、多维度分析、多源搜索、多模型投票。

核心思路

通过 Fan-out 实现自动并行，所有 Worker 节点同时启动。通过 Fan-in 实现自动等待，聚合节点会等待所有 Worker 都完成后才启动。总耗时等于最慢的 Worker 耗时加上聚合节点的耗时，相比串行执行有明显的加速效果。

第十章：Evaluator-Optimizer（评估器-优化器）

什么时候用

当你有一个"生成"节点和一个"评估"节点，生成的结果如果不达标，就带着评估反馈回到生成节点重新来，直到达标为止。和 Parallelization 的关键区别：Parallelization 是一次性并行，Evaluator-Optimizer 是迭代式串行循环——可能跑 1 轮就过，也可能跑 5 轮。典型场景：内容生成、代码测试、翻译质量优化。

核心思路

这是一个循环结构：生成节点产生结果，评估节点对结果打分并提供反馈，质量门根据评分和迭代次数决定是结束、继续还是强制结束。关键是要有双重保护：质量保护（评分达标直接通过）和兜底保护（达到迭代上限强制结束），避免无限循环。

第十一章：Agent / ReAct 循环

什么时候用

当你有一个 LLM 和一堆工具，需要 LLM 自己决定"什么时候调工具、调哪个工具、调几次、调完工具后结果是否满意、要不要再调一次"时，这就是最经典的 Agent 模式。你在 ChatGPT 里用的联网搜索、代码执行，底层就是这个循环。和 Evaluator-Optimizer 的关键区别：Evaluator-Optimizer 的循环路径是固定的，而 Agent 循环的路径是 LLM 动态决定的。

核心思路

Agent 节点调用 LLM，LLM 可能返回最终答案，也可能返回工具调用请求。如果是工具调用，ToolNode（LangGraph 的预置组件）自动执行所有工具，把结果作为 ToolMessage 追加到消息列表中，然后回到 Agent 节点继续。这个循环何时结束完全由 LLM 自己决定。ToolNode 免去了手动编写遍历工具调用、执行工具、返回结果等重复代码的工作。

第十二章：Coordinator / Supervisor（多 Agent 协作）

什么时候用

当一个 Agent 不够用——任务太复杂，需要多个不同专业的 Agent 协同工作时——就需要一个"总指挥"（Supervisor）负责分析任务、分配给合适的子 Agent、评估结果、决定是继续分配还是汇总结束。这是最复杂的模式，本质上是 Routing、Agent 循环和 Evaluator 的组合。典型场景：全栈开发助手、科研助手、企业决策支持。

核心思路

Supervisor 节点分析任务后，决定下一个应该由哪个专业 Agent 处理。被选中的 Agent 执行完任务后，将结果写入共享 State，然后总是回到 Supervisor。Supervisor 再次评估：信息够了吗？需要换一个专家吗？还是可以汇总了？直到决定"FINISH"，才进入汇总报告阶段。子 Agent 之间不直接通信，所有信息通过共享 State 传递。

第四部分：生产级特性

第十三章：Memory & Checkpointer — 状态持久化

为什么需要持久化

试想一下：Agent 已经跑了 5 轮，调了多次搜索和计算，花了几块钱的 API 费，结果第 6 轮超时了。如果没有持久化——钱花了，结果全丢了。Checkpointer 是 LangGraph 的答案：每一步执行后自动保存 State 快照。

开发与生产

开发环境可以使用内存存储，零配置但重启会丢失。生产环境则使用 SQLite 或 PostgreSQL，支持分布式部署。LangGraph 用 thread_id 隔离不同用户或会话的 State，同一个图实例可以同时服务数千个用户，每个用户的 State 完全独立。

断点恢复

这是很强大的能力。如果 Agent 在某个步骤崩溃了，不需要重新开始。直接再次调用，传入 null 作为输入，LangGraph 会自动从最后一个 checkpoint 恢复 State 并继续执行未完成的步骤。这在长任务中非常关键。

第十四章：Human-in-the-Loop — 人在回路

什么时候需要

不是所有操作都能让 Agent 自己决定。发送重要邮件、执行数据库变更、大额交易、敏感内容发布等场景，都需要人工审批。interrupt() 可以让图在任意节点暂停，等待外部输入。

交互方式

第一次调用时，图会在 interrupt() 处暂停，返回当前 State。人类审核后，通过 Command 发送审批结果，图从暂停点继续执行。关键在于，State 已经被 Checkpointer 持久化了，审核人不需要立刻审批——几分钟后、几小时后都可以，State 不会丢。

第十五章：Streaming 与部署

三种 Streaming 模式

LangGraph 提供三种流式输出模式：values 模式在每个 Node 完成后推送一次完整 State，适合状态面板；updates 模式只推送本次 Node 的增量更新，适合步骤进度条；messages 模式按 LLM 输出的 token 逐字推送，适合打字机效果。三种模式可以组合使用。

部署

通过 CLI 一行命令即可部署到 LangGraph Platform，自动获得 REST API 端点、内置 Streaming、Checkpointer 管理、并发处理、监控和日志等能力。

第五部分：面试指南

第十六章：面试语术体系

经典开场问题

错误答法是上来就讲技术细节，面试官跟不上。正确的答法应该按四个层次递进：从问题出发，展示你理解 LLM 的局限；讲 Agent 循环的本质，展示你理解底层运行方式；介绍 LangGraph 的解决方案，展示你对执行模型有深入理解；最后讲具体模式和选型，展示你知道什么时候用什么模式。

常见追问

面试官可能会问：LangGraph 的 Fan-in 是怎么知道要等的？如果 Agent 一直在循环不停止怎么办？多个子 Agent 之间怎么通信？LangGraph 和其他框架有什么区别？这些问题都需要基于对执行引擎、终止策略、通信模型和框架设计的深入理解来回答。

第六部分：附录

第十七章：学习路径建议

推荐的学习路径：从裸调 LLM API 开始，理解其局限性；然后学习结构化输出和工具调用两个增强手段；接着手写一个 ReAct 循环，感受痛点；再用 LangGraph 重写，理解图结构的好处；按顺序实现六大设计模式；最后加上 Checkpointer、人在回路、Streaming 等生产级特性。

第十八章：参考资源

• LangGraph 官方文档 — 最权威的参考
• Anthropic: Building Effective Agents — Agent 模式总结的经典文章
• ReAct 论文 — Reasoning + Acting 的原始论文
• Google Pregel 论文 — LangGraph 执行引擎的理论基础
• LangGraph GitHub — 源码和示例