Agent 的工具没变，SGLang 缓存为什么没命中？

一个客服 Agent 每次调用模型，都带着同一套业务规则和工具说明。你期待第二轮能少算一些，可观察请求时发现，输入依然处理了很久。

先别急着加显存或改调度参数。把发往模型的两份输入并排打开，找最早变化的位置。工具说明可能确实没变，但它前面的时间戳每轮都在变。

文中的布局是作者示意，没有本地命中率或提速数据。

下面是同一套模板的两轮输入示意。为了看清差异，这里用文字块表示内容，并非某个 API 的真实请求，也不是分词器输出：

text 复制代码

第一轮：当前时间 10:00 → 固定规则 → 固定工具说明 → 用户问题
第二轮：当前时间 10:01 → 固定规则 → 固定工具说明 → 用户问题

前缀缓存从开头匹配，公共部分到最早不同的 token 为止。后面两大段工具说明即使一模一样，也不能跳过前面的差异，把它们当作同一段公共开头。

可以尝试让真正稳定的内容靠前，让必须变化的信息靠后：

text 复制代码

固定规则 → 固定工具说明 → 当前请求需要的时间 → 用户问题

这里的"靠前"不是让你把 system 消息移到 user，也不是把检索出来的网页塞进高优先级规则。角色和顺序会影响模型理解。只有在保持指令层级、语义和回答质量的前提下，这个布局才值得比较。

图注：SGLang Quickstart / Launch a Server，2026-09-06 检查。原始页面说明服务器默认使用 Hugging Face tokenizer 的聊天模板。截图保留原文像素。

客户端的 JSON 还会经过聊天模板处理。因此，业务代码中两个字典"看着差不多"不够；应比较同一模板和分词器实际形成的输入。依据见 SGLang Quickstart。

工具名称、参数定义通常不必每轮改变，可以保持确定的输出顺序与序列化方式。今天先列查订单、明天先列查库存，两套能力相同，输入的 token 顺序却可能不同。

但工具返回值不是工具定义。订单刚发货、库存刚售罄、用户权限刚被撤销，这些变化就应该进入本轮判断。为了命中率保留上轮结果，会让用户收到旧答案。

纯追踪用途的 request ID 也可以留在日志里，前提是模型不需要它完成任务。如果它是用户正在查询的订单编号，就不能删。性能优化应去掉无用的变化，而不是去掉有效信息。

两轮都检索到 A、B、C 三份资料，并不代表输入相同。第一轮是 A→B→C，第二轮是 C→A→B，最前面的材料已经变了。

这不意味着应当强行按文档 ID 排序。检索系统把 C 排第一，可能正是因为它最相关。如果固定排序让回答更差，节省的输入计算就不能算净收益。

围绕同一份资料连续提问更适合观察复用：资料版本和正文保持不变，问题放在后面。但仍须每次检查访问权限。同一个文档 ID 不代表正文和权限一直相同；更不能为缓存复用，把不可信材料提升成系统指令。

多个模型副本各自持有缓存时，第二轮需要到达拥有那份可用缓存的副本，才能利用它。第一轮在 worker A 预热，第二轮去了 worker B，这时没命中不能直接归咎于模板。即使命中增加，排队也可能让首 token 继续等很久。

图注：SGLang Model Gateway / Load Balancing Policies，2026-09-06 检查。原文将 cache_aware 描述为同时考虑缓存局部性和负载均衡；截图保留原始像素。

Model Gateway 文档提供缓存感知路由。它需要兼顾负载：把用户一直绑在已经排长队的机器上，并不保证用户更早看到回答。排查记录里保留实际 worker，比只写"命中／未命中"更有用。

拿一小组脱敏的真实请求，先只稳定工具说明的序列化；再单独比较是否适合移动纯动态元信息。别在同一轮同时升级模型、更换分词器和增加并发，否则很难知道差异从哪来。

缓存量和等待时间按当前版本的指标定义读取。整个服务的平均命中率，不能单独证明某一条请求用了缓存。

把上表填完再决定是否保留改动。如果输入复用改善了，回答或工具选择却变差，就撤回那项模板调整。