软件需要在生产环境中进行变更。新需求、错误修复和重构最终都会进入你的图代码。由于 LangGraph 使用最新部署的图来运行针对已持久化状态的现有线程,因此你发布的每个变更实际上都是针对现有检查点的向后兼容 API 变更。 与将运行固定在其启动时代码版本的工作流引擎不同,LangGraph 会立即将最新的图应用于每个线程,无论是新线程还是从检查点恢复的线程。这很方便:错误修复无需额外操作即可传播到进行中的对话和代理。这也意味着你必须考虑每个变更如何与在代码的先前版本下启动的运行进行交互。 有三类兼容性问题需要注意,大致按你遇到它们的顺序排列:Documentation Index
Fetch the complete documentation index at: https://cndoc-langchain.site/llms.txt
Use this file to discover all available pages before exploring further.
技术兼容性
技术兼容性相当于微服务中的 API 破坏性变更。这里的“API”是你的图代码与检查点存储器为现有线程持久化数据之间的契约。当线程恢复时,LangGraph 反序列化保存的状态,按名称将其分派到节点,并期望节点返回符合状态模式的值。 常见的技术性破坏:- 重命名或移除节点,而线程正暂停在该节点或即将进入该节点,例如在
interrupt处或通过仍路由到旧名称的检查点条件边。恢复时,LangGraph 无法按其保存的名称找到节点,运行失败。恢复运行的起点是执行停止的节点开头,因此缺失的节点无处可恢复。 - 重命名或移除状态键,而旧的检查点仍包含该键或下游节点仍在读取该键。
- 收紧状态字段,例如将
Optional字段设为必需、缩小类型或添加没有默认值的新必需字段。现有检查点将不满足新模式。
推荐模式
-
将新状态字段添加为
NotRequired(或Optional[...] = None),以便旧检查点仍然有效: - 将移除视为弃用。即使没有节点读取该字段,也至少在一个排空周期内保持该字段在状态上的定义,以便现有检查点继续加载。
- 通过先添加后移除进行重命名。在旧字段或节点旁边添加新字段或节点,在弃用窗口期内双写或同时路由到两者,然后在确认没有进行中的线程依赖它之后移除旧的。
-
保持节点函数对未知键具有容忍性。
TypedDict在运行时忽略额外的键,因此来自旧代码版本的剩余状态不会引发错误,除非节点显式读取缺失的键。 -
使用时间旅行和
graph.get_state在推出之前,在暂存部署中针对新代码抽查现有线程。
检测进行中的线程
在你移除节点、重命名状态键或进行其他旧线程无法容忍的变更之前,你需要知道是否有任何线程当前停留在你即将放弃的代码版本上。LangGraph 本身不维护线程状态的搜索索引,因此答案取决于你的图运行位置。 如果你部署到 LangSmith。 使用代理服务器的线程搜索按状态进行筛选。status 字段接受 idle、busy、interrupted 和 error,因此你可以批量查询 interrupted 或 busy 线程,并可选择使用元数据筛选器进行缩小。参阅按线程状态筛选和列出线程。
在任何 LangGraph 运行的地方。 使用 LangSmith 追踪来监控生产环境中哪些节点正在被进入和退出。这是节点或状态字段在任何活动代码路径中不再可达的最可靠信号。
当你已经拥有 thread_id 时。 直接检查该单个线程:
graph.get_state(config)返回最新的检查点,包括线程暂停在哪个节点以及任何待处理的中断。graph.get_state_history(config)返回该线程的完整时间顺序检查点列表。
业务兼容性
有时变更在技术上是有效的(每个现有检查点仍然加载,每个节点仍然解析),但新图的含义与旧图不同。新行为对于新线程是正确的,你不想将其追溯应用于在旧逻辑下启动的线程。 例如,假设你的图运行intake → triage → respond,你决定在 triage 和 respond 之间插入一个新的 policy_check 步骤:
- 已经通过
triage的线程应直接继续到respond(旧流程)。 - 新线程应运行完整的新流程。
triage 之后恢复的旧线程从其保存的状态中读取 flow_version(或回退到 v1 默认值)并跳过 policy_check。新线程从 intake 开始,被标记为 flow_version=2,并运行新路径。一旦所有 v1 线程完成,你就可以移除版本标志和条件边。
此模式仅在你在线程启动时(在任何需要版本控制的分支之前)设置版本时有效。稍后设置意味着现有线程在需要时将没有设置该值。
非确定性
此类别仅适用于函数式 API。图 API 在恢复时在节点边界处重新进入,因此节点代码不会像 Temporal 风格的工作流那样从函数开头“重放”。 相比之下,函数式 API 在运行恢复时从头开始重放@entrypoint 的主体,使用缓存的 @task 结果来跳过已完成的工作。两种变更会破坏此模型:
- 添加、移除或重新排序
@task调用或interrupt调用,这些调用位于恢复点之前。LangGraph 通过它们在重放中的位置将缓存结果和恢复值与调用匹配,因此移动该位置可能导致错误的缓存值被重放到不同的调用上。 - 在
@task之外引入非确定性操作,例如time.time()、random.random()或内联在入口点主体中的网络调用。在重放时,这些操作产生的值与首次运行时不同,这可能会改变控制流。
@entrypoint 进行重大代码变更,最安全的选项是:
- 让进行中的运行在部署变更之前排空。
- 将任何新逻辑包装在新的
@task中,以便其结果独立检查点。 - 在
langgraph.json中为新行为注册一个新的入口点,并将新线程路由到它。
将这些文档连接到 Claude、VSCode 等,通过 MCP 获取实时答案。

