摘要： `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，所以`历史是不会被篡改的`，只会在某个时间点开启了一个 `平行世界` 。 阅读全文

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

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

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

摘要： 前面以`写入`的角度介绍了BaseCheckpointSaver的`put/aput`和`put_writes/aput_writes`方法,它们分别实现了基于Checkpoint和Pending Write的持久化。对于一个已经完成的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定义了它必须具备的最小功能集合 阅读全文