LangGraph Time Travel 怎么用？如何从历史检查点重放或分叉执行？

知识点详解：从检查点继续，不是把录像倒放

先找到“决定发生之前”的状态

假设一个 Agent 的流程是：读取需求、选择方案、生成建议。

我们发现建议不合适，怀疑它在选择方案时用了错误的约束条件。那么有用的起点，是选择方案之前的检查点，而不一定是任务最后一条状态。

检查点除了状态值，还包含继续执行所需的信息。查看历史时，不能只看“这条记录的时间比较早”，还要确认它属于哪个线程、下一批待执行节点是什么。

如果选到最终检查点，已经没有后续节点，继续运行可能不会做任何事情。这不代表 Time Travel 失效，而是起点后面没有工作。官方重放说明

Replay：换一次执行，起点不换

先用一条简单路线理解：

原路线：读取需求 → 检查点 C → 选择方案 → 生成建议。

从 C 重放时，读取需求的已保存结果被保留；后面的选择方案和生成建议重新执行。

这不是把旧输出再展示一遍。模型可能给出另一种选择，工具查询也可能拿到更新后的数据。如果希望比较两次决策，就要同时记录模型配置、输入资料和工具返回内容，而不能只保存最终回答。

因此，“重放后结果不同”未必是框架出错。我们首先要问：哪些输入固定住了，哪些输入来自变化中的外部系统？

Fork：改起点，保留旧分支

还是检查点 C。这次我们把需求中的预算从一个假设值改成另一个值，再继续执行。

Fork 的过程是：选 C、应用状态更新、得到一个新检查点、从新检查点继续。原来的状态历史仍然保留，不是打开旧记录把预算字段直接覆盖。

这里还有一个容易漏掉的地方：状态更新会经过字段自己的合并规则。如果字段使用列表追加 Reducer，写入一个新列表，不一定意味着替换旧列表。

所以，调用更新接口前，先核对字段的更新含义。修改约束、补充资料和替换旧结论，可能需要不同的状态设计。检查点与状态说明

图能回去，邮件和付款回不去

假设“生成建议”后面还有一个“发送邮件”节点，旧分支已经把邮件发出。

现在从 C 重跑，发送节点可能再次执行。现实中就会收到第二封邮件，而不是第一封邮件先被撤回。

调试时比较稳妥的做法，是先用替身工具记录“准备发送什么”，不真正发送。确实要重新操作外部系统时，再检查动作是否幂等、幂等键是否对应同一次业务动作，以及授权是否仍然有效。

也不要为了避免重复，把所有新分支都强行复用旧业务键。如果新分支代表的是一个新的、被批准的动作，它与重试旧动作的处理方式就不同。需要先区分“再试一次”和“做另一件事”。

面试官继续追问

分叉以后，下一步一定从我指定的节点开始吗？

还需要看检查点的待执行节点，以及状态更新被视为哪个节点产生的更新。并行分支等情况下，框架可能不能自动推断，需要明确指定相应节点。不能把“改一个字段”理解为任意跳到任何代码位置。

之前已经通过人工确认，重放时还会暂停吗？

按照官方 Time Travel 行为，包含 interrupt 的节点重新执行时，会再次触发交互。即使业务保存了旧审批记录，也要核对新分支的动作、参数和授权，不能因为旧分支通过过，就批准所有新分支。

能从任意一个子图内部节点重放吗？

不一定。检查点粒度取决于子图的持久化配置。父图将子图视为整体时，父级历史不一定提供每个内部节点之间的检查点。应先检查实际保存了哪些状态，再判断可以从哪里开始。

面试速记卡

• 起点：选择明确的历史检查点，不只是找一个旧时间。
• Replay：保留起点前的结果，重新执行后续节点。
• Fork：更新历史状态后创建新检查点，原历史仍然保留。
• 非确定性：模型、工具和人工交互可能重新发生，结果可能变化。
• 副作用：Time Travel 不会自动撤销邮件、付款或数据库写入。