“追加不破坏缓存”只在单次注入时成立。状态是会变的——下一轮 TODO 完成了一项、工具计数加了一次，状态消息就过时了。如何更新它，存在两种实现，各有明确的缓存代价：
**实现一：每轮替换**。每次 API 调用前，从消息列表中移除上一轮的状态消息，在末尾追加最新状态。这保证了上下文中只有一份状态、永远是最新的。但代价是：移除旧状态会使其位置之后的所有缓存失效——这与本章批评的“动态时间戳”是同一个失效机制，区别只在于状态消息位于上下文末尾，失效范围仅限于最近几轮消息，而不是整个前缀。
**实现二：持久追加**。状态消息一旦注入就永久留在轨迹中，每轮只在末尾追加新的状态。Claude Code 的 `<system-reminder>` 采用的就是这种方式——历史状态消息保留在会话记录（transcript）中，从不删改。这种方式对缓存完全友好：所有消息只追加、不修改，前缀始终稳定。代价是陈旧的状态会在上下文中累积——既占用 token，也要求模型自己关注“最新一条”状态而忽略已过时的旧状态。
取舍的经验法则是：**状态更新频繁且轨迹很长时，选择实现二**——每轮替换带来的缓存失效会在长轨迹上反复累积，代价远超陈旧状态占用的 token；**轨迹较短或单条状态消息很大**（如完整的 TODO 列表加环境快照）**时，选择实现一**——末尾几轮的缓存失效本来就便宜，换来的是上下文的整洁和无歧义。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/lj1109053360/article/details/169942042
