想换一个中间决定再生成，LangGraph 可以从旧状态分出新路线

一条生成流程前半段已经找好主题，后半段写出的内容不满意。你想试另一个方向，却不想丢掉原来的结果，也不想重新做所有准备。LangGraph 的 time travel 给这类工作提供了具体接口：找到旧检查点，保留前面的状态，再重跑或分出后续路线。

这不是简单地翻看历史回答。检查点记录工作流状态；选择一个位置继续，后面的节点会真正再次执行。对于正在开发多步骤 AI 应用的人，它让“哪里开始换一种做法”成为可以操作的选择。

先看官方的两个节点

官方文档用一个小例子解释：generate_topic 先产生主题，write_joke 再根据主题写笑话。状态包含 topic 与 joke，工作流使用 checkpointer 保存进度。

运行之后，通过 get_state_history 找到下一步是 write_joke 的检查点。以这个配置再次 invoke，写笑话会重新执行，生成主题则不再执行，因为它的结果已经保存在此前状态里。

这个例子刻意小，却把边界讲清了。把它换成教学情境中的“检索材料，再写摘要”，同样的问题就是：能否固定已选材料，只重新生成后半段？是否值得这样做，取决于你想比较的是写法，还是前面的材料本身。

如果想改掉中间决定，文档使用 update_state，在写笑话前把 topic 换为 chickens，再从新状态继续。原来关于袜子的执行历史仍然保留，新路线则基于鸡的主题运行。

因此，Fork 不是把原线程擦回过去，而是在旧位置创建新的分支状态。你可以保留两条路径用于比较，而不是只留下最后一次尝试，忘记最初为什么不满意。

更复杂的流程还需要关注状态由哪个节点写入，以及从谁的后继节点继续。官方为并发分支、没有历史的测试状态等情况提供 as_node；它决定从哪里接续，不只是给修改加一个标签。

文档特别强调，Replay 会再次运行节点，不是读取一份缓存答案。后续的模型请求、外部 API 与 interrupt 都可能重新发生，也可能得到不同内容。最终检查点如果没有下一节点，继续它则不会再产生工作。

这意味着调用成本仍然存在；如果后半段会发邮件、写数据库，也要处理重复执行的后果。检查点只能决定流程从哪里继续，不能撤销外部世界已经发生的动作。

LangGraph README将持久运行、记忆与人在流程中的介入列为核心能力，并说明它可以不依赖 LangChain 使用。代码采用 MIT，模型和存储需自行配置。

对于要反复打磨生成策略的人，time travel 最有用的成果是保留一组可解释的对照：前面哪些状态相同，中间改了什么，后面怎样变化。这样调试就能围绕一个决定展开，而不是不断从头发送“再来一次”。