JaydenAI的博客

PendingWrite三元组的第二部分表示写入的Channel，但是对于一些特殊的场景，比如出错、无写入、中断和恢复，它们的值不再是一个普通的Channel名称

在“Agent状态是如何被写入通道的？”中，我们探讨了组成的Agent的节点在完成了自身操作后，如何将执行结果通过写入相应的通道，进而更新Agent的状态。本篇文章则讨论这个问题的另一面：Agent的节点如何通过读取通道得到Agent的状态的。

根据"梳理Agent的执行流程"中针对Pregel执行流程的介绍，我们知道在每个Superstep的最后阶段，引擎会根据节点针对通道的订阅以及“__pregel_tasks”这个通道存储的`Send`对象，确定下一步应该执行的节点，并为它们创建代表执行任务的`PregelExecutableTask`。节点在执行过程中不能直接更新通道，它只能创建如下三种类型的对象来表示针对通道的写入意图。在默认情况下，这些对象承载的通道写入意图由`ChannelWrite`对象提交给引擎，后者在Superstep进入同步屏

Pregel的Checkpointer采用基于Checkpoint的持久化记录下一个以Thread ID标识的对话历史，这种基于会话的持久化属于短期存储。复杂的流程在运行的时候还需要跨越多个对话的长期甚至永久存储，这类存储被抽象成一个`BaseStore`类型，采用内存存储的`InMemoryStore`它的常用实现。

`invoke/ainvoke`方法看起来是采用简单的请求/回复消息交换模式，客户端需等待整个流程执行完毕后才能得到结果，其实方法背后还是会调用`stream/astream`方法以流的方式进行交互。如果我们直接调用调用这两个方法，并采用相应的流模式，我们就能有效解决客户端长时间无响应的问题，实时地得到对方的反馈。

目前针对`update_state`方法的调用都是针对最终状态，如果针对某个过去的历史节点调用此方法，就会在对应的地方开启了一个新的分支。除此之外，我们还可以利用`bulk_update_state/abulk_update_state`方法实现批量状态更新。

Pregel还提供了如下所示的`update_state/aupdate_state`和`bulk_update_state/abulk_update_state`方法，我们可以调用它们以增量的方式修改部分状态。有一点需要明确的是，这些方法并非直接修改某个持久化的Checkpoint，而是在此基础上创建一个子Checkpoint，所以`历史是不会被篡改的`，只会在某个时间点开启了一个 `平行世界` 。创建的Checkpoint的标识会存储返回的RunnableConfig配置中。

到目前为止，我们已经大体了解Pregel的`invoke/ainvoke`方法在背后都做了什么。接下来我们分两种情况简单梳理一下Pregel对象的执行的大体流程，这也是我们创建的Agent的执行流程。具体执行场景分两种， 一种是指定输入从头开始的常规调用，另一种是针对某个Checkpoint的恢复调用。

当我们在调用Pregel对象的`invoke`方法的时候，可以利用参数（durability）指定采用的持久化模式，它决定了在Superstep N成功结束之后，针对Checkpoint的持久化与开始Superstep N+1之间的关系。

成的Superstep来说，对应 Checkpoint就代表了它的状态；但是对于一个因中断尚未完成的Superstep，某个时刻的状态由上一Superstep的Checkpoint和当前Superstep的所有Pending Write来描述。如果真的需要恢复到中断时的状态，需要在Checkpoint固化状态基础上按序重放所有的Pending Write（实际上只需要重放代表成功执行任务的Pending Write）就可以了。

Pregel基于Checkpoint的持久化机制是实现Agent应用`高可用性`和`长期记忆`的基础，它本质上是将 不断向前推进的图在“Superstep”之间将其状态固化的过程。和很多数据库持久化类似，Pregel采用`基于全量数据的状态快照+基于增量更新的操作日志`的持久化策略。

在 Pregel 模型中，静态上下文是一个专门设计的依赖注入容器。它的出现是为了解决在复杂的图计算中，如何优雅地处理“不属于图状态，但Node运行又必须依赖的外部环境信息”这一痛点。这些数据具有一个共同的性质，那就是在整个运行生命周期内只读且固定。

Pregel是对`PregelProtocol`协议的实现，后者的引入标志着 LangGraph 从一个单一的库进化为了一个可插拔的图计算框架。图可以视为“LangGraph 执行体”，而PregelProtocol定义了它必须具备的最小功能集合。

一个Pregel由Node和Channel构建而成，后者保持状态并以Pub/Sub的方式驱动Node执行，Pregel中的Node是一个PregelNode对象，是一个完全无状态的功能节点。

我们一直在强调Pregel对象的状态是通过Channel维护和传递的，其实承载传递状态功能的组件除了Channel，还有 ManagedValue。我们可以将ManagedValue视为虚拟Channel，Node不仅采用与读取Channel完全一样的方式读取ManagedValue，而且注册的ManagedValue也直接存放在Pregel的channels字段中。

除了我们显式声明的用于存储业务数据或驱动信号的Channel之外，Pregel自身也会维护一些系统Channel，其中最重要的莫过于一个名为“__pregel_tasks”的Channel，是它成就了基于“PUSH”的节点任务执行方式。

Pregel由Node和Channel这两个核心部件组成，Channel不仅维护了整个图的状态，还是驱动Node执行的 “原力” 。

作为执行引擎，Pregel是整个LangChain/LangGraph体系最核心的部分，也可能大家最陌生的部分。新版本的LangGraph采用全新的设计重写了Pregel，目前社区基本上没有系统介绍Pregel的资料，我希望这个系列的文章能够弥补这一空白。