你让 AI 助手试着处理一封邮件，发现路线不对，于是点了撤销。界面上，那段尝试已经消失；但服务器可能还留着它的“草稿”。接下来，助手表面上从干净记录继续，实际仍会参考刚才被删掉的内容。
这篇论文研究的正是这道缝隙。KV cache——模型读过文字后保存的中间计算结果——可以避免反复处理整段历史，让连续对话更快。但如果应用只删除对话记录，没有同步恢复缓存，逻辑上的回滚就没有真正完成。论文把这种要求称为 rollback consistency，即“回滚一致性”：应用以为恢复到了哪里，模型实际看到的状态也必须恢复到那里。
这是单一研究团队给出的结果，尚无外部交叉验证。以下数字和结论均来自 Zhang 与 Yang 的论文及其发布材料。
被删掉的分支，怎样继续影响模型？
问题出现在“有状态服务会话”里。它指服务器会在多次请求之间保留内部数据，而不是每次从头计算。应用通常保存一份对话记录，推理服务则保存对应的 KV cache。两边各自工作正常，也可能在组合后出错。
设想一个 Agent 要把敏感材料发送给获准的 finance-desk。它先探索一条路线，期间从工具返回结果或检索文档里读到了攻击者指定的收件地址。应用随后否决这条路线，从对话记录中删除相关内容，再要求 Agent 完成发送。
如果旧缓存继续沿用，模型实际注意到的上下文仍包含那个地址。论文展示的后果是：材料可能被送往许可名单之外的端点。这里的关键不是“删除过的文字会不会留下痕迹”，而是应用层和推理层对“当前历史”产生了分歧。日志看起来已经回滚，模型的内部阅读进度却没有。
这是一种跨层正确性风险。就像游戏读档时，人物状态回到了昨天，地图却保留了今天打开的机关。人物系统和地图系统都没有单独报错，但这个存档已经不再自洽。
同样的输入，只换缓存
要证明结果来自缓存，而不是普通的提示注入，论文设计了 same-token/different-cache audit，可译为“同 token、不同缓存审计”。Token 是模型处理文字时使用的基本片段。
研究者准备两组决策过程。两组在最后一步收到完全相同的 token，区别只在缓存前缀：一组保留已撤销分支形成的旧缓存；另一组根据正式提交的对话记录重建缓存。这样，如果最终动作不同，差异就不能归因于本次请求里的文字，只能归因于缓存状态。
审计还逐项检查了两件事：攻击者 token 没有出现在实际送入最后决策步骤的请求中；旧缓存组与重建组收到的决策 token 完全一致。需要注意，这不代表攻击内容从未进入会话或缓存。它曾出现在后来被否决的分支里，只是没有出现在回滚后的 served request，也就是模型服务当次接收的请求中。
论文在 7 个开放权重模型家族上测试，参数规模从 3.8B 到 36B，共组成 63 个审计单元。仅仅保留旧 KV cache，就在其中 25 个单元里翻转了 typed protected effect——可理解为带明确类型、受到策略约束的操作，例如“向哪个收件人发送材料”。这里的 25/63 是审计单元数量，不是 25 次真实攻击，也不是 25 个模型。
结果因模型而异。Phi-3.5-mini 与 GLM-4-9B 在各自 9 个单元中全部翻转；Granite-3.3-8B 为 6 个，Qwen2.5-14B 为 1 个；DeepSeek-R1-Distill-Llama-8B、Phi-4 和 Seed-OSS-36B 在这组测试中没有出现动作翻转。易受影响程度也没有随参数规模单调变化。
论文因此区分了两层问题。第一层是状态完整性：只要缓存保留了已撤销分支，模型注意到的状态就与应用记录不一致。第二层是行为后果：模型是否真的据此改变动作。前者是缓存状态的结构性问题；后者随模型和测试条件变化。一个模型这次没有采取错误动作，并不等于两层状态已经一致。
不是实验室里手改张量才会发生
研究者先用 Hugging Face Transformers 的 DynamicCache 精确控制缓存，以隔离变量。随后又在更接近真实应用的路径中复现：应用删除探索分支，却继续使用原来的会话句柄或 past_key_values。这条路径不需要直接修改张量。
论文还测试了 LangGraph 的 time-travel。它是一种把 Agent 逻辑状态恢复到旧检查点的机制。研究者验证，攻击者内容确实从 LangGraph 保存的回滚后状态中消失了；但与之配合的模型缓存仍可能停留在旧状态。论文并未声称 LangGraph 违反自身承诺，因为它本来就不保证恢复独立推理服务持有的 KV cache。问题恰恰在于：框架正确恢复了自己管理的状态，却不足以保证整个系统完成回滚。
这也接上了本刊同日介绍的 AgentRewind：回滚不能只恢复对话，还要恢复外部环境。这篇论文又补上第三层——模型服务端真正用于生成的推理状态。对话、环境和缓存，必须指向同一个历史版本。
修复不必清空整台服务器
论文测试的有效做法，是 transaction-local cache restoration，即只恢复这次事务、这条会话的缓存。具体可以重新计算已提交对话的缓存，把旧缓存截断到提交边界，或者恢复回滚前保存的缓存快照。
在论文测试的 63 个审计单元里，根据已提交状态重建缓存后，问题全部消失。作者还报告，截断与快照恢复也关闭了所测通道。这个结论的范围是论文覆盖的模型、框架和审计设置，不能直接外推到所有推理系统。
这种局部恢复也比全局清空缓存更有针对性。全局 flush 或重启会影响其他会话；事务级恢复只处理发生回滚的那条分支。论文还发现，仅在提示词里要求模型“不要相信已拒绝内容”并不足够，因为缓存里的残留并没有被标记为“已拒绝”。模型看到的只是普通上下文。
为什么现在值得关注？
Agent 正在从一次性问答走向长时间运行、反复试错的系统。为了速度，服务端倾向于保留更多状态；为了可靠性，应用又需要撤销、重试和回到检查点。这两个合理设计一旦缺少共同的回滚协议，就会制造一种很难从日志发现的错误。
论文真正提出的提醒很朴素：不能用“界面上已经删掉”来证明模型已经忘掉。回滚应成为跨层契约。凡是模型随后还会注意到的状态，都要跟着事务一起恢复。
局限与未知
- 所有效果数字目前都来自同一研究团队。作者称主要结果采用确定性解码，并可由发布的 artifacts 重现，但本文未获得第三方复现。
- 验证范围集中在 retained-handle reuse，即跨回滚继续沿用会话或 KV 句柄。论文指出，按请求内容匹配前缀的自动缓存不会重新注入已删除 token；商业服务商隐藏的缓存实现则仍属未知。
- “typed protected effect”、cache-isolated MoE 以及各类事务级恢复的实现边界，不能仅凭摘要式结论推广到所有权限系统、模型架构和推理框架。