KV Cache 未必是一次性的：可编辑、可组合的“笔记”

本节到此为止都建立在一条铁律上：前缀里改一个字节，后面的缓存就全废。这条铁律在今天的推理引擎里确实成立，但笔者想指出，它未必是**必然**的。松动它的出发点，是一个反直觉的观察\^ch2-2：在 prefill 阶段，模型其实在"做笔记"。当它读到上下文里的某个字段（比如"用户所在城市：北京"）时，并不是把这个字段原封不动地缓存下来，而是顺手把"这个字段意味着什么"的**结论**写进了后面每一层的 KV 状态里。测量发现，一个字段**自己**那几个 token 的 KV，对最终决策的贡献往往不到 1%------真正影响输出的，是它在下游留下的那些"读书笔记"。 这个发现打开了两种以前认为不可能的操作。其一是**编辑**（Editing）：既然结论已经写进了下游笔记，那么改掉一个字段后，只要模型有显式的思考链（CoT），就能让这处改动顺着已缓存的思考传播下去，用大约 1% 的算力得到与"整段重算"一致的结果（反过来，如果没有 CoT，孤立地改字段会被忽略------因为结论早已烘焙进下游状态、却没有一条思考路径去更新它，这是一条重要的边界）。其二是**组合**（Composition）：把一段预先算好的"技能"缓存，通过旋转位置编码（RoPE）挪到新的位置，直接拼接进另一段上下文，而不必重新计算注意力------于是"用模块化的缓存块拼出一个长上下文"从 O(L²) 的重算降到 O(L) 的拼接，质量却与完整重算无法区分。 打个比方：你读一份厚文档时，不会每改一个事实就从头重读，而是靠**页边笔记**------笔记里已经写着"所以这意味着 X"。KV Cache 即笔记的思路正是如此：模型的笔记已经记下了每个事实的**推论**，所以某个事实变了，只需修正那条笔记，它喂养的结论就跟着更新；又因为笔记是用一种可搬运的速记写成的，你还能把上次为别的问题记的一页笔记，重新编号后（这就是 RoPE 重定位）粘到新问题里复用。论文在 vLLM 上实现后，首 token 延迟（p90）最高有几十到几百倍的下降、前缀缓存命中率约 98.5%，而输出与逐字重算在决策上完全一致（跨 12 个模型，logit 余弦相似度 0.90--0.999）。 对 Agent 而言，这一点的意义在于：那个被反复重建的长上下文------换一批工具、更新一个记忆字段、注入一条新状态（正是下一节状态栏要做的事）------也许不必每轮都推倒重来。它指向一种"上下文可变、但缓存收益还在"的可能：把上下文的组装从 O(L²) 的重算，变成 O(L) 的"笔记拼接"。这仍属研究阶段，本节前面的三条实践结论在当前生产系统中依然是应当遵守的默认原则。 \^ch2-2: Li, Bojie. *Models Take Notes at Prefill: KV Cache Can Be Editable and Composable.* arXiv:2606.17107, 2026. 理解了缓存机制后，接下来的问题自然变成：既然我们知道了上下文是怎么被处理和缓存的，那该如何设计送进去的内容本身？接下来几节围绕"上下文里到底放什么、怎么组织"展开，可以分为三条相对独立的线索： - **提示工程、提示注入与动态提示词（Agent Skills）**：系统提示词该怎么写、写什么------这是上下文工程最直接的部分；工具定义（与系统提示词并列的另一个静态组成部分）的设计也直接影响 Agent 的工具使用准确性，本章给出核心原则，第四章将详细展开。紧随其后的是安全问题------提示注入：当外部内容试图劫持精心设计的上下文时，如何在上下文层面构筑防御。而当提示词越写越长、覆盖的场景越来越多时，把所有内容塞进一个系统提示词就不再可行了（既浪费 token，也会导致注意力被稀释），于是自然演化出 Agent Skills 的渐进式披露机制------按需加载，而非一次性塞满。 - **Agent 状态栏（Agent Status Bar）**：一种独立的机制，通过在上下文末尾注入动态的元信息（任务进度、环境状态、工具调用计数等），弥补模型无法主动归纳隐式状态的不足。就像手机屏幕顶部始终显示时间、电量、网络信号一样，Agent 状态栏让模型随时能"瞥一眼"就知道当前的运行状态。 - **上下文压缩策略**：解决上下文不断膨胀的问题------什么时候压缩、怎么压缩、压缩如何与 KV Cache 共存。