多 Agent 的 State 与 Checkpoint 机制如何实现？

核心回答

State 是工作流当前的数据；Checkpoint 是为了继续执行而保存的状态快照及执行信息；Checkpointer 是读写这些快照的组件。

多 Agent 协作时，先定义状态中有哪些任务目标、分支结果、错误和产物引用，再让节点返回局部更新，按字段规则合并。以 LangGraph 为例，运行时在 super-step 边界形成检查点，记录状态值及接下来要执行的节点等信息，并通过 checkpointer 保存。

恢复时用同一条 thread_id 定位对应执行，加载已保存状态继续处理；具体能恢复到哪里，取决于保存边界、后端和写入时机。InMemorySaver 只保存在当前进程内；要支持重启恢复，需要合适的持久化后端。外部业务动作的幂等与结果核对仍需另外处理。

展开说明

1. 先设计 State：存什么、由谁更新

State 是节点之间的数据契约，可以包含当前任务、必要消息、计划版本、各子任务结果和状态、失败原因及产物引用。大文件或完整网页可以保存在外部，状态里留可取回引用；模型客户端、数据库连接等运行资源不宜混进业务状态。

每个节点读取当前状态，返回自己负责字段的更新。单值结果可以覆盖，集合或消息使用适合的 Reducer；消息还可能按 ID 更新，不能一律当普通列表拼接。节点之间传递的是框架管理的更新，而不是所有 Agent 任意修改同一个全局变量。

主图与子图可以使用不同的数据契约，通过明确输入输出映射交换必要字段。子图检查点的命名空间和生命周期则要按框架配置管理；它与模型消息隔离、工具权限是不同问题。

2. 再设计 Checkpoint：不仅保存一份聊天记录

LangGraph 的状态快照除了 values，还包含 next、执行配置、元数据及任务相关信息。values 回答“目前知道什么”，next 回答“接下来运行什么”；线程、检查点命名空间和检查点标识则帮助定位是哪一条执行链、哪一个图和哪一次保存。

检查点以 super-step 为边界。顺序节点通常处在不同步骤，同一步可包含多个并行节点；完整状态在该步骤完成后形成相应快照。运行时还可以保存步内已完成节点的输出，用于某个并行节点失败后的恢复。节点输出写入与一个完整快照是两个层次，不能据此认为任意一行 Python 代码都能原地续跑。

存储实现负责序列化、写入、读取和历史查询。使用现成 checkpointer 时，通常配置后端并在编译图时接入，再为调用提供稳定的 thread_id；不需要自己另写一套框架内部检查点表。应用可以另外记录业务版本和产物位置，保证恢复时还能找到兼容的依赖。

3. 用并行取数后一支失败的场景理解

以报告工作流为设计示例：主节点分派网络检索和数据库查询，两个分支分别提交结果，之后由汇总节点生成报告。

假设网络检索已经完成，数据库查询报错。如果网络节点输出已经作为对应步骤的写入成功保存，LangGraph 恢复该步骤时可以复用它，继续处理未完成分支；不必从入口重新检索。两边完成并合并后，完整快照记录可供汇总使用的状态及后续节点。

若进程在写入保存前崩溃，则可能需要重新执行尚未保存的工作。即使使用数据库后端，同步保存、异步保存及只在退出时保存的策略，可恢复范围也不同。应按任务允许的损失和性能要求选择，而不是看到“持久化”就默认每一步已经落盘。

若某节点已经发送通知或创建业务记录，但本地尚未保存成功，恢复时还应查询外部结果，或使用稳定业务幂等键避免重复提交。检查点保存的是图的执行信息，不会自动撤销远程系统，也不能单独保证业务动作只发生一次。

4. 多 Agent 并行时，谁负责保持状态正确？

先让各分支写自己负责的结果字段，汇总节点写最终结果；确实需要多方更新同一字段时，定义适当的合并规则。LangGraph 同一步内对无合并规则字段的多次写入可能报并发更新错误，不能默认后写覆盖就算处理完成。具体方案可见共享上下文同步管理。

Checkpoint 负责保存运行时管理后的状态，不替应用判断哪条业务结论更可信，也不自动协调多个外部 Worker 对同一任务的所有权。应明确会话与运行的归属，以及谁有权推进状态；隔离问题可结合上下文与状态隔离说明。

5. 参考项目怎样使用？

研搜参考实现通过 Deep Agents 接入 LangGraph 运行时，配置 InMemorySaver，并以会话 ID 作为 thread_id。这支持同一进程内同一会话继续使用已保存状态。

若要支持服务重启后的恢复，可以改用满足部署需求的持久化 checkpointer，同时验证工具结果、文件产物和业务版本仍可取得。恢复机制与文件保存要一起设计：只留下一个已失效的本地路径，状态即使加载成功也无法继续完成任务。

常见追问

State 与 Checkpoint 是两份业务数据吗？

它们是当前数据与保存版本的关系。State 表达运行中的业务值；Checkpoint 固定某个执行边界的值及恢复信息，形成可追踪的历史。不能只更新一份外部“状态 JSON”，却不让运行时知道下一步从哪里继续。

保存到 Redis 就等于实现 Checkpoint 了吗？

不等于。存储只是载体，还要按框架契约保存状态值、版本关联、待执行信息和必要的节点写入，正确处理序列化及恢复。若采用成熟实现，重点是选好后端并验证其持久性、兼容性和恢复行为。

有检查点，所有节点就都不会重复执行了吗？

不会。未保存的工作、失败节点以及从旧检查点重新执行的节点都可能再运行；重放还会重新触发后续模型和 API 调用。对外部写操作仍需幂等和结果查询，不能靠本地快照推断远端是否成功。

Checkpoint 能替代长期记忆吗？

通常不能。它主要保存某条执行线程的运行状态；跨会话使用的偏好、事实和知识，应按相应作用域存入长期存储，再按需读取。两者可以配合。

对应教程

参考资料