HFL AI Agent Lab

Appearance

LangGraph 状态机 ​

这一节解决什么问题 ​

普通的 Agent Loop 是"模型驱动"的——每一步都由模型决定下一步做什么。这种方式在简单场景下很好用，但在复杂业务流程中会出现问题：流程不可控、难以调试、无法暂停、没有回溯能力。

LangGraph 用状态机的方式编排 Agent 流程，把"模型自由生成"变成"在预定义的流程中执行"。这让多步骤任务有了明确的流转规则，提升了可控性和可维护性。

本节会系统讲解 LangGraph 的核心概念、设计模式、适用场景和工程化要点。

核心概念 ​

State（状态） ​

状态是整个图的数据载体，所有节点共享同一个状态对象。状态在节点之间传递，每个节点读取状态、处理后将结果写回状态。

状态通常包含：

  • 用户输入
  • 任务计划或意图
  • 工具调用结果
  • 中间决策记录
  • 最终输出
  • 错误信息

状态设计是 LangGraph 的核心。好的状态设计应该只包含必要的字段，字段含义清晰，避免冗余和歧义。

Node（节点） ​

节点是执行单元，每个节点完成一个具体任务后将结果写入状态。

节点可以是：

  • 一个 Agent（调用大模型进行推理）
  • 一个工具调用（执行外部操作）
  • 一个数据处理步骤（格式转换、校验）
  • 一个人工审核点（暂停等待人工输入）

节点应该是"原子"的——每个节点只做一件事。如果一个节点做了太多事情，应该拆分成多个节点。

Edge（边） ​

边定义了节点之间的流转关系。LangGraph 有两种边：

  • 普通边：A 完成后直接到 B，无条件流转
  • 条件边：根据状态中的某个字段决定下一步去哪

条件边是 LangGraph 的核心能力之一。它让流程可以根据执行结果动态分支，比如"如果工具调用成功就继续，失败就进入错误处理"。

Conditional Edge（条件边） ​

条件边通过一个函数判断当前状态，返回下一个节点的名称。这个函数可以检查任何状态字段，实现复杂的分支逻辑。

text
节点 A → 条件判断 → (状态.成功) → 节点 B
                   → (状态.失败) → 节点 C
                   → (状态.需要人工) → 节点 D

Checkpoint（检查点） ​

Checkpoint 用于保存图执行过程中的中间状态。它的价值在于：

  • 断点恢复：执行中断后可以从最近的检查点恢复，而不是从头开始
  • 流程回溯：可以查看任意时刻的状态快照，方便调试
  • Human-in-the-loop：在检查点暂停，等待人工输入后继续

Checkpoint 是 LangGraph 区别于普通 Agent Loop 的关键特性之一。

Human-in-the-loop ​

LangGraph 支持在特定节点暂停执行，等待人工输入后继续。这在需要人工确认、人工审批或人工补充信息的场景中非常重要。

暂停点通常是高风险操作之前（如发送消息、修改数据、执行支付），人工确认后再继续执行。

为什么重要 ​

LangGraph 解决了 Agent 系统在复杂场景下的可控性问题。

首先，流程可控。普通 Agent Loop 的每一步都由模型决定，流程不可预测。LangGraph 把流程显式定义为状态机，每一步的流转规则都是确定的，只有节点内部的推理由模型完成。

其次，可调试。状态机的每个节点都有明确的输入输出，状态在节点间传递，任何一步出了问题都可以精确定位。普通 Agent Loop 出了问题很难知道是哪一步出错的。

再次，可暂停和可恢复。通过 Checkpoint 和 Human-in-the-loop，LangGraph 可以在任意节点暂停、等待人工输入、从断点恢复。这是企业级 Agent 系统的必备能力。

最后，可测试。状态机的每个节点可以独立测试，条件边的逻辑可以单独验证。这比测试一个完全由模型驱动的 Agent Loop 容易得多。

工程化理解 ​

从工程角度看，LangGraph 不是"更好的 Agent"，而是"更可控的流程编排工具"。

状态设计：状态是整个图的核心数据结构。设计时要考虑：哪些信息需要在节点间传递？状态字段会不会膨胀？如何避免状态冲突？好的状态设计应该精简、清晰、有明确的更新规则。

节点粒度：节点太大会失去状态机的优势（调试困难），节点太小会增加流转开销。一般的原则是：每个节点对应一个独立的能力单元（一次推理、一次工具调用、一次人工确认）。

条件边设计：条件边是流程灵活性的来源，但也是复杂性的来源。条件过多会导致流程难以理解和维护。建议每个条件边的判断逻辑不超过 3 个分支。

错误处理：状态机中的错误处理比 Agent Loop 更规范。可以在条件边中检测错误状态，路由到专门的错误处理节点。错误处理节点可以重试、降级或记录失败。

Checkpoint 策略：不是每个节点都需要 Checkpoint。一般在关键节点（工具调用后、人工确认后、状态重大变化后）保存 Checkpoint。

常见误区 ​

误区一：LangGraph 能替代 Agent 推理

LangGraph 是流程编排工具，不是推理引擎。节点内部的推理仍然由大模型完成，LangGraph 只是控制节点之间的流转顺序。不要期望 LangGraph 能让模型"更聪明"。

误区二：状态字段越多越好

状态字段过多会导致状态膨胀、节点间耦合过紧、调试困难。每个节点应该只读取它需要的字段，只写入它负责的字段。

误区三：所有场景都适合用状态机

简单的问答、单轮对话、不需要流程控制的场景，用普通 Agent Loop 就够了。状态机适合多步骤、有分支、需要人工介入、需要可追溯的复杂流程。

误区四：条件边越多越灵活

条件边过多会让状态图变成"意大利面条"，难以理解和维护。建议控制条件边数量，复杂的判断逻辑可以封装到节点内部。

误区五：Checkpoint 会自动解决所有问题

Checkpoint 只是保存状态快照，恢复时需要确保外部工具的状态也是一致的。如果工具调用已经执行但 Checkpoint 没有记录，恢复后可能会重复执行。

和项目的关系 ​

LangGraph 是多 Agent 系统编排的核心工具。后续在项目 B 中会用到这一能力，但当前阶段只做知识准备，不展开具体项目实现。

理解 LangGraph 的 State / Node / Edge / Checkpoint / Human-in-the-loop 等核心概念，是设计可控 Agent 流程的基础。

面试表达 ​

可以这样表达：

> 我用 LangGraph 把 Agent 的执行过程显式建模为状态机。每个节点是一个处理单元——可以是 Agent 推理、工具调用或人工确认。边定义流转条件，状态在节点间传递。这样做的好处是流程可控、可调试、可暂停。相比让模型自由生成多步推理，状态机的方式更适合有明确业务流程的场景。另外，LangGraph 的 Checkpoint 机制支持断点恢复和 Human-in-the-loop，这对于需要人工审批的高风险操作非常重要。

相关链接 ​