替换执行结果或恢复任务时，如何还原完整上下文，模型能看到摘要还是完整消息？

核心回答

模型看到摘要还是完整消息，取决于恢复后实际发给它的输入。 Checkpoint 恢复了任务状态，不代表数据库里的全部历史会自动进入模型上下文；摘要也不能无损还原已经丢失的原文。

我会分开保存和使用三类信息：

1. 执行状态：目标、计划进度、节点结果引用、待执行步骤和失败位置，用于继续调度。
2. 原始记录：消息、工具调用与结果、文件和证据，在授权与保留期内可按 ID 回查。
3. 本轮模型输入：稳定规则、当前目标、有效摘要、近期消息，以及本次判断需要补回的原文。

普通续跑可以用摘要加近期消息；需要替换某个执行结果时，先定位它对应的输入和证据，补回相关原文，再生成新的状态版本，并更新受影响的摘要与下游结论。不是每次恢复都回灌全部历史，也不能只凭一句摘要重做关键决定。

展开说明

1. 状态、原文与摘要怎样关联？

用会话、任务、节点和调用标识把计划、消息与工具产物关联起来。摘要记录覆盖的消息范围、版本和关键证据引用；大型结果可以保存为受限文件或对象，状态中保留位置、内容版本和必要摘要。

Checkpoint 保存图所定义的状态。如果状态中的消息已被摘要替换，读取最新 checkpoint 通常只会得到这份压缩后的状态。要回查原文，需有仍然可用的历史记录或独立原文存储，不能假定框架会替应用永久保留一切。

资料有权限或保留期限时，回读同样检查；原文已经删除、无法访问或从未保存，只能说明缺少细节、重新获取或补问，不能让模型从摘要“猜回”精确数字、代码和错误栈。

2. 恢复任务时怎样组装输入？

先定位正确任务和检查点，读取当前状态、待执行节点、失败或中断信息，以及对应代码和配置版本。确认仍待处理的动作和在途工具状态，再准备下一轮模型输入。

上下文通常保留当前目标与硬约束、计划和有效摘要、最近交互；若下一步涉及旧结果，就按引用加载其相关原文、调用参数和上下游证据。超过预算时分段读取或缩小问题范围，优先保留判断所需细节，而不是无差别回放整段历史。

如果目标是精确复现“当时模型看到了什么”，还需要保留当时实际组装的消息与材料版本。仅有聊天记录不一定足够，因为当时的检索资料、工具定义或动态规则可能已经变化。继续真实执行时，还要应用当前有效权限，不能用历史快照恢复已撤销的授权。

3. 替换执行结果后，哪些东西需要一起更新？

例如排障摘要只写“接口请求失败”，现在要判断应更换凭证还是重试。先按工具调用 ID 找到原请求与响应，补回状态码、错误信息、请求时间和运行环境；这些细节决定两种处理完全不同。

若确认原工具读错了环境，需要重新查询并保存新结果，而不是把旧结果无痕覆盖。新的结果关联原结果及更正原因，基于旧结果生成的摘要、计划判断和报告段落标记失效，重新计算受影响部分。原有工具调用与反馈保持对应；若改变了参数重新调用，就按新调用记录。

在 LangGraph 中，update_state 会创建新的 checkpoint，并按字段的 reducer 合并更新；它不直接修改原检查点，也不保证所有字段都是覆盖。继续执行前应选对更新字段和后续节点。只是改一个状态值，框架不会自动理解哪些业务结论因此过期，这些依赖要在应用里定义。

4. 怎样确认模型实际看到了所需信息？

在模型调用边界检查经过脱敏的最终消息或输入清单，确认摘要覆盖范围、补回原文、工具结果关联与当前任务版本。数据库中“已经保存”不能证明本次请求“已经发送”。

用跨窗口追问和结果更正案例验证：故意让摘要省略一个关键条件，检查能否找到原文并重新判断；再比较关键字段遗漏、结论正确性、恢复耗时和 Token 成本。需要的是足够的相关证据，而非历史输入越长越好。

常见追问

模型是否需要完整的历史消息？

不一定。理解当前目标、约束和结果已足够时，摘要加近期消息即可。精确代码、金额、版本、错误和用户原始约定影响下一步时，补回相应片段；涉及工具调用时保留必要的调用关系。完整原文可以存在系统中，只有被加载到本轮输入才对这次模型判断可见。

只存摘要还能恢复吗？

可以恢复摘要里保留的任务信息，但不能保证找回被省略的细节。任务要求精确回溯时，就应在设计阶段保留原始消息、产物及引用；无法取得时需重新获取，不能承诺从有损摘要恢复完整上下文。

从 checkpoint 重放会重新调用工具吗？

可能会。重放会重新执行所选检查点之后的节点，模型或外部接口可能给出新结果；已发生的副作用也不会自动回退。应区分读取历史证据和重新执行动作，写操作通过有效授权、业务幂等与回执判断处理。

使用 InMemorySaver，重启后是否仍能恢复？

它保存的是进程内检查点，重启后不能依靠它恢复。跨进程恢复需要持久化后端，并保证原文、产物引用和对应版本也仍可读取。

对应教程

参考资料