哪些看似合理的上下文管理会破坏缓存？
| 模式 | 做法 | 主要危害 |
|---|
| 动态系统提示词 | 每轮把时间戳、变量注入 system 消息 | 整段后缀缓存失效，延迟与成本翻倍 |
| 动态用户配置 | 每轮在上下文里更新余额、剩余调用次数 | 同上；应改为按需的状态管理机制 |
| 工具定义动态排序 | 按使用频率调整 tools 顺序 | 工具定义篇幅大，首个变动工具起全部缓存失效 |
| 滑动窗口 | 只保留最近若干条消息 | 破坏前缀一致性并丢失关键工具结果 |
| 文本格式化 | 把 role-content 结构压成纯文本流 | 偏离训练格式，损害模型核心能力 |
- 效果对比: 实验表明保持工具固定顺序对模型选择工具的能力几乎没有影响，对性能的提升却很显著;
- 共同解法: 都收敛回 对缓存友好的三条核心原则;
滑动窗口为什么会引发重复工具调用？
- 机制: 窗口大小设为 10 时，第 11 条消息进来会丢弃最早一条;
- 问题一: 破坏上下文前缀一致性，KV Cache 失效;
- 问题二: 丢失关键的工具调用结果;
- 实例: 第 2 轮调用文件读取工具拿到关键内容，第 15 轮仍需引用，但原始结果已滑出窗口，模型只能依赖被截断的对话推断;
- 观察: 使用滑动窗口的 Agent 经常陷入循环，反复执行相同工具调用，因为它“忘记”了之前已获得的结果;
- 结论: 错误率显著上升，代价远超省下的 token;
为什么文本格式化破坏性最大？
- 做法: 把结构化的 role-content 消息转换为 “USER: ... ASSISTANT: ...” 纯文本流;
- 关键区别: 问题不在缓存，而在偏离模型训练时使用的标准消息格式;
- 训练背景: 模型在训练阶段接触大量基于角色的对话数据，已学会解析这种结构化格式;
- 额外负担: 消息变成纯文本后，模型需额外消耗注意力去推断角色边界与对话结构;
- 症状: 重复执行已完成操作、忽略工具调用结果、该调用工具时却生成文本响应、格式解析错误;
- 原因: 模型提供商为标准接口做了大量优化，偏离标准格式往往是在给自己挖坑;
应遵循哪些上下文管理纪律？
- 静态前缀只在设计期确定，运行期不做任何改写;
- 动态信息一律以新消息追加到轨迹末尾;
- 工具定义顺序与内容保持字节级稳定;
- 需要控制长度时使用有损但有原则的 上下文压缩，而不是按条数截断;
- 全程使用标准角色消息，不自行拼接字符串;