prependContext + showInjected 导致 OpenAI-compatible provider 前缀缓存命中率退化 / Prompt cache hit rate regression

[Enominera]

问题描述 / Problem

启用 memory-tencentdb 插件后，OpenAI-compatible 提供商（DeepSeek、MiMo）的 prompt 缓存命中率出现显著退化。

环境 / Environment

• OpenClaw 2026.5.28（5 月 30 日从 2026.5.19 升级）
• 提供商：DeepSeek V4 Pro、MiMo V2.5 Pro（均为 openai-completions API，依赖 prefix-matching 缓存）
• memory-tencentdb 插件于 5 月 30 日上线

现象 / Symptoms

日期	OpenClaw	TencentDB	MiMo 命中率	DeepSeek 命中率
5/29	5.19	❌ 未上线	91.1%	95.7%
5/31	5.28	✅ 全量	63.5%	83.3%

根因分析 / Root Cause

主因：prependContext → 上下文膨胀 → 前缀缓存失效

1. TencentDB 每轮向用户消息开头注入 prependContext（召回的记忆，约 500-1700 tokens）。当 showInjected=true 时，这些内容被冻结写入对话历史中。
2. 多轮对话后，上下文快速膨胀。膨胀触发更频繁的 tool result truncation。
3. truncation 的截断量每轮不同（基于 token budget 动态计算），导致对话历史前缀不一致 → prefix-matching 缓存失效。

次要：appendSystemContext 放置位置不当

composeSystemPromptWithHookContext 将 persona + 场景导航（~4000 字符）直接拼接到系统提示的 CACHE_BOUNDARY 之后，未调用已有的 prependSystemPromptAdditionAfterCacheBoundary。稳定内容每轮被当做新 token 计费。

建议 / Suggestions

1. 稳定 persona 内容应放在 CACHE_BOUNDARY 之前参与缓存
2. 评估 showInjected 对对话历史膨胀的长期影响
3. 考虑 session 级稳定系统提示追加内容的去重

---

Problem

Prompt cache hit rates for OpenAI-compatible providers (DeepSeek, MiMo) degraded significantly after enabling the memory-tencentdb plugin, combined with the OpenClaw 5.19 → 5.28 upgrade.

Environment

• OpenClaw 2026.5.28 (upgraded from 2026.5.19 on May 30)
• Providers: DeepSeek V4 Pro, MiMo V2.5 Pro (both openai-completions API, prefix-matching cache)
• memory-tencentdb plugin deployed on May 30

Cache Hit Rate Comparison

Date	OpenClaw	TencentDB	MiMo Hit Rate	DeepSeek Hit Rate
May 29	5.19	❌ Off	91.1%	95.7%
May 31	5.28	✅ On	63.5%	83.3%

Root Cause

Primary: prependContext → context bloat → prefix cache invalidation

1. TencentDB prepends prependContext (recalled memories, ~500-1700 tokens) to each user message. With showInjected=true, this content is frozen into conversation history.
2. Context bloat triggers more frequent tool result truncation over multiple turns.
3. Variable truncation amounts per turn (dynamic token budget) → conversation history prefix inconsistent → prefix-matching cache invalidated.

Secondary: appendSystemContext placed after CACHE_BOUNDARY

composeSystemPromptWithHookContext appends persona + scene navigation (~4000 chars) after the CACHE_BOUNDARY marker without using the existing prependSystemPromptAdditionAfterCacheBoundary. Stable content re-sent as fresh tokens every turn.

Suggestions

1. Place stable persona content before CACHE_BOUNDARY for caching
2. Evaluate long-term impact of showInjected on conversation history growth
3. Consider session-level dedup of stable system prompt additions

[Enominera]

验证结果 / Verification Result — 2026-06-01

关闭 TencentDB 后缓存命中率恢复

在 5/31 23:27 关闭 TencentDB 插件后，6/1 全天数据确认缓存命中率显著恢复：

日期	OpenClaw	TencentDB	DeepSeek 命中率	变化
5/29	5.19	❌	95.7%	基准
5/30	5.28	✅ v0.3.6原版	89.5%	-6.2pp
5/31	5.28	✅ 补丁版	83.3%	-12.4pp
6/1	5.28	❌ 关闭	93.2%	+9.9pp

6/1 具体数据

• DeepSeek 总输入 token：3150 万
• 未命中缓存 token：212 万
• 缓存命中率：93.2%

基本恢复到 5/29 正常水平（95.7%），确认根因就是 TencentDB 的 appendSystemContext + RECALL_VISIBILITY_REMINDER 动态注入破坏了 prompt 前缀缓存。

关键确认

1. 根因成立：动态 prependContext 每次请求包含不同记忆内容 → prompt 哈希变化 → prefix-matching 缓存失效
2. RECALL_VISIBILITY_REMINDER 加剧问题：5/31 01:12 加入的 55-token 标记本质上是一个二进制状态开关（有记忆/无记忆），导致同一 session 的任何有/无记忆切换都会改变前缀
3. 关闭即恢复：不需要改任何代码，关掉 TencentDB 就恢复正常，说明问题完全在 TencentDB 的注入机制上

建议

修复方向：要么让 prependContext 不参与 prefix 计算（放在 CACHE_BOUNDARY 之后），要么改用 session 级稳定的去重注入，避免每轮动态变化。

[Maxwell-Code07]

感谢您给出的详尽分析，我们内部会评估prependContext 放置位置和 showInjected 策略，您提出的命中率退化这个问题对我们而言很重要，感谢您的关注！

[Enominera]

Correction — 2026-06-02

After further investigation, the cache hit rate regression was NOT caused by TencentDB. The real root cause is a bug in OpenClaw v2026.5.28 where webchat creates a new embedded agent run per message, destroying provider prompt-cache prefix stability.

What actually happened

• The 5/29→5/30 cache hit rate drop (95.7% → 89.5%) coincided with the OpenClaw 5.19→5.28 upgrade, NOT TencentDB enablement
• The additional drop to 83.3% on 5/31 was caused by switching between Feishu and webchat channels on the new Mac, which exposed the webchat bug
• After disabling TencentDB, Feishu returned to 93.2%, but webchat remained at 29%

Hello Test Proof

Two identical messages sent in webchat vs Feishu:

Channel	Req 1 Hit%	Req 2 Hit%
webchat	85.8%	31.4% ⚠️
Feishu	98.1%	98.5% ✅

OpenClaw issue tracking the real root cause: openclaw/openclaw#89139

Apologies for the incorrect attribution. The prependContext / RECALL_VISIBILITY_REMINDER mechanism may still warrant optimization, but it was not the cause of the 29% cache degradation observed.