LangGraph 入门：从 Agent 痛点到底层编排原理

很多人用 LangChain 的 Agent 处理多步骤任务时都遇到过这样的场景：明明在提示词里写清楚了五个步骤的执行顺序，跑到第三步 Agent 就开始"忘事"——该调用的工具没调，不该走的流程乱走。这不是模型能力问题，而是架构层面的缺陷。LangGraph 正是为解决这类问题而生的底层编排框架。

为什么 Agent 搞不定固定流程？

LangChain 的 Agent 本质上是一个由大模型自主决策的执行体：用户输入问题，模型判断是否需要调用工具、调用几次、何时返回结果。这套机制在开放式对话中表现优异，但面对固定流程时就会暴露短板。

举个例子，假设你需要完成这样一条任务链：爬取指定网页 → 大模型总结内容 → 按模板生成 Markdown 文档 → 与历史文档做对比 → 将对比结果发送邮件。用 Agent 当然能跑，但你必须把这五个步骤的全部细节塞进提示词里。问题在于，随着对话轮次增加，上下文不断膨胀，最初那段提示词的权重会被逐渐稀释。结果就是模型在中途"断片"，漏掉关键环节。

这个问题的根源在于：Agent 把流程控制的权力完全交给了大模型，而大模型在长上下文中的注意力衰减是客观存在的。流程越复杂、步骤越多，失控的概率就越高。

大模型注意力衰减指的是随着输入上下文变长，模型对早期 token 的关注度逐步下降的现象。Transformer 架构的自注意力机制计算复杂度随序列长度呈二次增长，当上下文扩展到数千甚至数万 token 时，提示词开头的指令信息容易被后续内容'淹没'。这不是模型 bug，而是当前主流架构的固有特征。实践中表现为：系统提示里强调的规则、工具说明、执行顺序，在中途几轮工具调用后被模型忽略。缓解手段包括把关键指令重复放在提示词末尾、使用结构化格式（如 XML 标签）、缩减无关历史消息，但都无法从根本上消除。这也是需要外部编排框架来接管流程控制的核心原因。

LangGraph 的核心定位：只管编排，不管模型

LangGraph 的设计哲学非常清晰——它不关心你用什么模型、什么工具，它只负责一件事：编排。你可以把它理解为一个低层级的执行引擎，靠近底层基础设施，精确控制每一步该走什么路径。

这意味着在 LangGraph 里，你既可以调用大模型处理某个步骤，也可以调用外部工具，甚至可以插入纯业务逻辑代码作为一个节点。每一步做什么、下一步走哪里，全部由你显式定义，而不是让模型"猜"。

官方对它的定位是"编排框架 + 运行时管理"，由 LangChain 团队开发。它提供的能力包括检查点机制、人工介入、流式输出、条件分支、并行执行、容错重试以及动态子图。所谓子图，可以理解为流程中的一个分支模块，主图和子图配合完成复杂逻辑。

这里有个关键事实值得注意：LangChain 的 Agent 底层实现本身就是用 LangGraph 构建的。换句话说，你之前用的 Agent 只是 LangGraph 的一层上层封装。

检查点机制（Checkpoint） 是 LangGraph 运行时管理的核心能力之一。它会在每个节点执行后把完整的状态快照持久化下来，包括当前变量、已走过路径、待执行节点等。这带来三个直接好处：其一，流程中断后可从中断点恢复，无需从头重跑，节省 token 与时间成本；其二，支持人工介入（Human-in-the-loop），在敏感步骤暂停等待人工确认后再继续；其三，便于调试和回放，开发者能逐步检视每次状态变化。检查点通常存储在内存、SQLite、Postgres 等后端，生产环境中建议使用持久化数据库以保证可靠性。

LangGraph 在技术栈中的位置

理解 LangGraph 需要把它放进整个 LangChain 生态的技术栈中来看。从下往上的层级关系是：LangGraph → LangChain Agent → Deep Agent。

LangGraph 处于最底层，封装最少，灵活性最高。LangChain 在它之上做了一层封装，让你快速搭建 Agent——组装模型、工具、提示词即可运行。Deep Agent 则封装程度最高，开箱即用，支持操作文件系统、沙箱后端、虚拟文件系统、长期记忆、任务规划、子 Agent 调度和中件库等能力。

越往上用起来越省事，但灵活性越低；越往下越自由，但代码量越大、需要自己处理的细节越多。

以 Deep Agent 中的 skill 能力为例，它本质上就是基于 LangChain 的动态提示词做了一层高层封装，让用户能描述步骤化的技能。但在底层实现上，这些能力依然依赖 LangGraph 的执行引擎。

子图（Subgraph） 是 LangGraph 支持模块化复用的重要机制。一个子图本身就是一个独立的图结构，拥有自己的状态定义和节点集合，可以作为节点被主图调用。它解决了两个典型问题：一是逻辑复用，例如'文档审核'流程在多个主流程中重复出现，抽成子图后只需维护一份；二是状态隔离，子图可以定义自己的私有状态字段，与父图状态通过输入输出映射进行交互，避免字段污染。设计复杂系统时，通常把稳定、通用的步骤封装为子图，把变化频繁的部分放在主图，从而降低整体维护成本。

三者各自的适用场景

了解了层级关系后，选型就变得清晰了。

Deep Agent 适合快速交付标准化场景。功能齐全、拿来就能跑，省去了大量搭建工作。

LangChain Agent 适合定制化程度不高的场景。通过组合模型和工具，处理一些非流程化的、由模型自主决策的任务。

LangGraph 适合复杂流程和精准控制的场景。当你需要严格控制执行顺序、需要人工介入敏感步骤、需要条件分支和并行处理时，LangGraph 是唯一能给你足够控制力的选择。

即使 Deep Agent 已经覆盖了大部分日常需求，理解 LangGraph 依然有价值。一方面能帮你理解上层框架的工作原理，另一方面在需要深度定制流程的场景下，你仍然需要回到 LangGraph 这一层来实现。

生态中的监控工具：LangSmith

除了 LangGraph、LangChain 和 Deep Agent，生态中还有一个重要工具：LangSmith。它负责对整个执行过程进行追踪、评估和监控。你可以把 LangGraph 构建的流程图部署到 LangSmith 上，实时观察 Agent 每一步的执行情况，也可以基于 LangSmith 对外暴露接口，供 Web 应用调用。

对于生产环境的 AI 应用来说，可观测性和执行控制同样重要——LangGraph 解决前者，LangSmith 解决后者。

可观测性（Observability） 在 AI 应用中包含三个层面：追踪（Tracing）、评估（Evaluation）与监控（Monitoring）。追踪记录单次运行的完整调用链，包括每次模型请求、工具调用、状态变更及耗时；评估通过数据集和评分器批量检验输出质量，用于回归测试和版本对比；监控则关注线上指标，如成功率、延迟分布、token 消耗和异常告警。LangGraph 负责'怎么执行'，LangSmith 负责'执行得怎么样'，二者互为补充。生产环境中若缺少可观测层，一旦 Agent 输出异常往往难以定位是提示词、工具还是流程本身的问题。

小结

LangGraph 的价值不在于替代 Agent，而在于补足 Agent 在固定流程场景下的控制力短板。它把流程编排的权力从大模型手中拿回来，交给开发者显式定义。当你面对多步骤、强流程、需要精准控制的 AI 应用时，LangGraph 提供的底层编排能力是上层框架无法替代的。