[bug] compaction-basic 摘要请求漏传 reasoningEffort，导致 provider 前缀缓存整体 miss

[NothingToSay0031]

现象

@deepseek-ai/dsh-compaction-basic 的辅助摘要请求没有转发 reasoningEffort，导致它不再落在会话最后一个已路由请求的缓存命名空间里，回放前缀几乎全部按未命中计费。

这不是配置问题，是 summarizeWithLlm() 少带了一个字段。

定位

packages/compaction/compaction-basic/src/summarizer.ts 里 summarizeWithLlm() 构造的调用参数：

const latest = agent.session.requestHeader()?.config   // 已握有完整路由配置
...
const options: GenerateOptions = {
  provider: target.provider,
  model: target.model,
  messages,
  toolHistory: agent.session.toolHistory(),
  ...input.tools === undefined ? {} : { tools: [...input.tools] },
  maxTokens: config.maxTokens,
  sessionId: agent.session.id,
  purpose: 'compaction',
  ...signal === undefined ? {} : { signal },
}

provider / model / maxTokens 都转发了，唯独没有 reasoningEffort。已发布的 0.2.1-rc.5 与当前 master 源码一致。

为什么算 bug

1. reasoningEffort 属于调用配置的一等维度。 packages/llm/llm/src/call-config.ts 把它列在 LlmCallControls 里，并且同文件的配置相等性比较把它与 provider / model / maxTokens 并列：

if (
  a.provider !== b.provider
  || a.model !== b.model
  || a.reasoningEffort !== b.reasoningEffort   // 与 provider/model 同级
  || a.temperature !== b.temperature
  || a.maxTokens !== b.maxTokens
) return false

提供方按 reasoning_effort 分缓存命名空间（max 是独立的一份，high 与「不传」共用另一份），所以省略它等于把请求搬到了另一个命名空间。

2. 与包自己的文档承诺直接冲突。 packages/compaction/compaction-basic/README.zh.md「辅助摘要器请求 / KV Cache 影响」写着：

已回放系统提示词、工具与已遮蔽区域消息与会话最后一个已路由请求逐字匹配，因此提供方的热前缀 cache 可复用至尾随指令之前；只有该指令与摘要输出未缓存。

并且把「放弃复用」的原因只归为两类：路由到不同 provider/model、压缩非头部范围。漏传 reasoningEffort 是第三种、且未被声明的复用失效来源。

3. 修复所需的值已经在同一个函数里。 latest 就是 requestHeader()?.config，provider/model 从它取，reasoningEffort 也在同一个对象上。

实测证据

同一个自建网关、同样的消息前缀做 A/B，只看摘要请求的 usage.cacheReadTokens：

会话路由 effort	摘要请求是否带 effort	命中率
max	带 max	98.0%
max	不带（当前行为）	0%
high	不带	97.5%（high 与不传共用命名空间，所以侥幸命中）

也就是说只有会话本身跑在 high（或默认档）时才看不出问题；一旦用到独立命名空间的档位，摘要调用就整体退化成「只有头部命中」。

历史 109 次真实摘要调用合计 2,538 万输入 token，仅 134 万命中，整体命中率 5.0%；命中的块大小全是 10,368 / 6,272 这种「只有 system + 工具 schema」的量级，与「消息一个都没复用」的判断吻合。

建议改法

在 summarizeWithLlm() 里按 provider/model 的同一来源转发 effort，约三行：

• 走 latest（会话路由）时，把 latest.reasoningEffort 一并放进 options；
• 走 config.summarizationProvider / summarizationModel 时不要硬套会话的 effort——不同模型的 reasoning.efforts 取值集合不同，硬塞会撞上 UNSUPPORTED_REASONING_EFFORT；
• 该值最终仍会过 resolveCallWithInfo 的校验，所以只在与会话路由同源时转发是安全的。

如果希望更省事，也可以让压缩走一遍 agent/request 扩展点（现在为了跳过 agent-loop 专用扩展点而直连 ctx.llm.stream()，代价正是路由参数会漏）。

社区侧规避（供参考）

在上游修好之前，可以在更外层包一次 llm.stream()：只挑 purpose === 'compaction' 且自身未指定 reasoningEffort 的调用，从该 sessionId 的 requestHeader().config 补上路由用的值，其余调用原样透传。

补充一点给实现者参考：llm/stream waterfall 做不到这件事。它是框架正式给出的拦截点，但监听器签名只有 (options, next)，options 是闭包里同一个对象，next(...) 不会把新参数带给下游或内置实现——监听器只能整体替换返回的流，于是会跳过下游监听器和内置的失败包装。要「只补一个字段、其余全不动」，只能选更外层的入口。

环境

• @deepseek-ai/dsh / dsh-compaction-basic：0.2.1-rc.5（master 源码同样存在）
• 桌面端 profile，自动压缩与 /compact 两条路径都能复现

[lloydzhou]

补充一个可能需要排除的因素。我最近在实现外部压缩插件 dsh-smart-compaction，正好看了已发布版本这部分源码：compaction-basic 的自动压缩路径会先做工具结果裁剪，再判断是否需要生成摘要。

如果裁剪改写了历史中较早的 tool result，后续摘要请求回放的消息虽然与“裁剪后的 session”一致，却已经不再与上一次真实模型请求的消息前缀一致。缓存可能从第一个被改写的位置开始失效。因此，“只命中 system + 工具 schema 附近”以及历史摘要总体命中率偏低，也可能包含提前裁剪造成的影响，不一定都能归因于 reasoningEffort。

漏传 reasoningEffort 这个源码事实确实存在，但该参数是否改变缓存命名空间可能与提供商／网关实现有关。如果文中的 A/B 已严格固定实际发出的完整前缀，只改变 effort，并控制了预热和路由，那么它仍然支持 effort 在该网关环境下有影响；这里不是否定这组实验，只是建议把历史统计中的另一个变量单独排除。

可以做一个 2×2 对照：摘要前“原样保留／先裁剪工具结果”，各自再比较“保持 effort／省略 effort”，同时核对实际请求前缀和 usage。

我们插件目前采用的规避思路是：先试算裁剪是否足以降压，足够才提交；如果仍然必须生成摘要，就先用未改写的历史前缀生成摘要，之后才按需裁剪保留尾部。这是减少前缀变化的措施，并不保证缓存命中。供排查参考。

[NothingToSay0031]

https://zhuanlan.zhihu.com/p/2100569815186403400 具体可以参考这个，我已经测试过，关掉tool-result-pruner后长会话命中率92%->96%，修掉effort的问题后96%->98%。