大模型请求组装架构如何逼近前缀缓存上限

在多轮智能体（Agent）会话中，一次任务往往触发数十次模型调用，每次调用都携带完整的对话历史。服务端若能在两次请求间复用相同前缀对应的 KV 缓存，输入计费可下降一个数量级，首 token 延迟也会明显缩短。本文从源码与架构层面分析一种请求组装管道的设计，说明它如何在不引入任何显式缓存管理逻辑的前提下，让前缀缓存命中率稳定逼近理论上限。

一、前缀缓存：服务端优化与客户端责任

主流大模型 API 在服务端普遍实现了提示词前缀缓存（Prompt Prefix Caching）。其原理并不复杂：当两次请求的 token 序列从头部开始存在一段完全相同的连续前缀时，服务端可以复用该前缀已计算好的 KV 缓存，跳过重复的注意力计算，只对新增的尾部 token 做前向计算。

这一机制对 Agent 场景的价值被严重低估。一个典型的多轮会话结构如下：

• 固定不变的系统提示词（System Prompt）；
• 固定不变的工具定义（Tool Schemas）；
• 持续增长的消息历史（Message History）。

如果每次请求的 token 序列都是上一次请求的严格前缀扩展，那么服务端只需计算新增的尾部片段。响应体中通常会返回两个字段，分别表示命中缓存与未命中缓存的输入 token 数量。在实际运行中，除首次请求外，所有请求均可观测到命中 token 数大于零，命中率接近理论上限。

关键在于：缓存命中不是客户端”请求”来的，而是请求序列的几何性质决定的。 服务端只负责判断前缀是否相同，客户端负责让前缀保持相同。因此，前缀缓存的真正难点不在服务端，而在请求组装管道能否保证前缀的字节级稳定性。

二、设计哲学：稳定性是推论，不是补丁

该请求组装管道的架构笔记中有一段关键表述，大意是：前缀缓存的稳定性是第一条推论，而不是标题本身；一个只追加的日志，经由每节点纯函数投射，只要头部未变，产出的请求就必然是前序请求的追加扩展——稳定性是涌现出来的，不是被管理出来的。

这段话揭示了核心设计哲学：缓存命中率不是通过”缓存管理”实现的，而是架构的必然结果。展开来看，它包含三个可验证的命题：

1. 会话日志是只追加的（append-only）：历史消息一旦写入就不再修改、不再重排、不再删除。
2. 消息投射是纯函数（pure function）：给定相同的日志状态与相同的节点配置，投射出的请求逐字节相同，不依赖时间、随机数、外部状态。
3. 请求是前序请求的尾部扩展：当前请求的 token 序列等于上一次请求的 token 序列加上新增片段。

当这三条同时成立，前缀稳定性就是数学推论：若 $R{n-1}$ 是 $R{n-2}$ 的前缀扩展，$Rn$ 是 $R{n-1}$ 的前缀扩展，则由传递性，$Rn$ 以 $R{n-2}$ 为前缀。缓存命中率随之逼近上限。

反过来看，工程实践中绝大多数缓存失效都源于对上述命题的破坏：在历史中间插入一条修正消息、对早期消息做摘要压缩、动态调整系统提示词、按当前时间注入上下文、对工具定义做无序序列化。这些操作都会在 token 序列中部制造分叉，使此前的缓存全部作废。

三、请求的三区结构

序列化后发送给 API 的请求，其 token 序列可划分为三个区域：

┌────────────────┬────────────────┬──────────────────────────────┐
│  System Prompt │  Tool Schemas  │      Message History         │
│     (固定)      │     (固定)      │      (仅尾部追加)             │
└────────────────┴────────────────┴──────────────────────────────┘
        ▲                ▲                        ▲
        │                │                        │
    每步不变          每步不变              每步尾部追加新消息

三个区域各自承担不同的稳定性职责：

• System Prompt：在整个会话生命周期内保持不变。任何基于运行时状态（时间戳、用户等级、随机种子）的动态拼接都会破坏前缀。
• Tool Schemas：必须以确定性顺序序列化。键序、字段序、空白字符的任何抖动都会改变 token 序列。实践中应固定序列化器的输出格式，避免依赖哈希表的遍历顺序。
• Message History：只允许在尾部追加。这是三区中最容易被破坏的一环，也是架构设计的重点。

四、实现要点：让纯函数真正纯粹

要落地上述设计，需要在几个具体环节上做约束。

其一，日志与视图分离。 会话日志是事实来源，只追加；请求是日志在某一时刻的投射视图。视图可以重新计算，日志不可回改。这样即使需要修改历史（例如修正一条错误消息），也应通过追加一条新消息来表达，而非原地编辑。

其二，投射函数无副作用。 投射过程不得读取时钟、不得调用随机数、不得依赖进程内可变状态。工具定义的序列化应使用稳定排序：

def project_request(log, node_config):
    # 纯函数：相同输入必然产生相同输出
    system = node_config.system_prompt          # 会话内常量
    tools = stable_serialize(node_config.tools) # 固定键序与字段序
    messages = [
        {"role": e.role, "content": e.content}
        for e in log.entries                     # 仅遍历，不修改
    ]
    return {"system": system, "tools": tools, "messages": messages}

其三，压缩策略需谨慎。 当上下文接近窗口上限时，若采用”摘要早期消息”的策略，会在序列中部制造分叉，导致缓存整体失效。更稳妥的做法是将压缩放在会话边界，或接受一次性缓存重建的成本，并在设计上明确这是有意的权衡而非意外退化。

其四，可观测性。 应在每次请求后记录命中与未命中的 token 数量，并对命中率做趋势监控。若某次请求的命中 token 数骤降为零，通常意味着投射函数出现了非确定性，或日志被中途改写，这是最有价值的排障信号。

五、效果与适用边界

在只追加日志加纯函数投射的架构下，Agent 会话的输入计费与首 token 延迟可获得数量级的改善：除首轮外，每轮仅需为新增的尾部 token 付费，服务端也只需计算增量部分。这一收益随会话轮次增加而放大，对长会话、高频工具调用的场景尤为显著。

需要说明的是，该设计的适用边界在于”头部不变”这一前提。当业务确实需要动态系统提示词或中途重构历史时，缓存命中率下降是预期行为，应从架构层面评估是否可将动态部分下沉到消息尾部，而非在前缀区做文章。

总结来看，前缀缓存的高命中率并非靠缓存管理技巧堆砌，而是请求组装管道在架构上做出的承诺：只追加的日志、纯函数的投射、确定性的序列化，三者共同 guarantee 了请求序列的前缀单调性。把稳定性当作推论来设计，比把它当作补丁来维护，成本更低，效果也更接近理论上限。