前言¶
在 DeepSeek Harness（dsh）裏跑長會話時，系統提示、工具列表和上下文開頭一旦能被前綴緩存命中，後續輪次會按緩存價計費。反過來，只要前綴被改寫，整段前綴會重新按未緩存全價重計——這是省 token 費用的關鍵約束。
單看 usage 裏的 inputTokens（未緩存輸入）變高，無法區分「正常變長」（例如大工具結果、長粘貼）和「前綴真被重寫」。前者 cacheRead 往往仍高；後者未緩存暴漲的同時，cacheRead 會相對自身基線塌陷。下面介紹維護者 121212165 的插件 dsh-plugin-cache-guard：監聽 usage 流，用三閘門把兩類形狀分開，估算重寫多付的 token，並在出現新的前綴重寫時向模型注入一次診斷提示。
這是什麼¶
dsh-plugin-cache-guard 是 dsh 生態下的 admin-security 類插件，當前版本 0.2.0（MIT 許可證）。它不負責改模型行爲，只做前綴緩存健康診斷：區分「前綴重寫（rewrite）」與「變長（growth）」，並給出命中率、判定檔位與多付合計。
與同系列的 price-aware（花了多少）、cost-ledger（臺賬）互補——本插件回答 爲什麼多花。
目錄頁：SkillHub - dsh-plugin-cache-guard
源碼：GitHub - 121212165/dsh-plugin-cache-guard
核心功能¶
三閘門尖峯判定¶
只有同時滿足下面三步，才記一次 前綴重寫：
- 未緩存輸入超過滑動基線帶（大小閘）；
- 該步
cacheRead相對自身基線塌陷（形狀閘）； - 重計的量約等於上一步整個 prompt（歸因閘）。
只過大小的步（大工具結果、長粘貼：未緩存暴漲但前綴仍命中）記爲 變長（growth），不算抖動、不計入浪費。
dsh 的 usage 三桶互斥（@deepseek-ai/dsh-llm 的 TokenUsage：inputTokens 僅爲 uncached input；計費輸入 = inputTokens + cacheReadTokens + cacheWriteTokens）。真重寫時 cacheRead 常塌到 128（塊粒度殘值，不是 0），因此判定用比值塌陷，而不是 cacheRead === 0。
/cache 與 cache_status¶
/cache：展示命中率、判定（穩定 / 觀察 / 不穩定）、重寫明細（含塌陷前後與上一步 prompt）、變長步數、多付合計。cache_status工具：供 agent 在會話中自查緩存健康。
adviseModel（默認開啓）¶
出現 新的 前綴重寫時，通過 tools/post-execute 向上下文注入插件提示（與 price-aware 同一條注入路徑）。同一次斷裂只提醒一次，避免後續每一步重複刷屏。v0.2.0 使用 session format v4 的 plugin:<name> 來源 kind，修復 v0.1.0 在 dsh 0.1.7 上因舊 source 包裝導致會話中斷的問題。
配置項¶
在 profile 中按需覆蓋下列字段（默認值來自 README）：
| 字段 | 默認 | 說明 |
|---|---|---|
window |
8 | 基線滑動窗口（同時也是「最近」的跨度） |
factor |
2.5 | 大小閘：未緩存基線倍數 |
floorTokens |
1500 | 大小閘：絕對地板（正常增長不誤報） |
collapseRatio |
0.25 | 形狀閘：cacheRead 低於自身基線該比例算塌陷 |
collapseMinBaseline |
2000 | 形狀閘：基線低於此值不判塌陷 |
rebillShare |
0.6 | 歸因閘：重計量需達到上一步 prompt 的該比例 |
adviseModel |
true |
上下文內提醒 |
前 window 步不參與判定（滑動窗口未填滿），冷啓動階段的塌陷不會被報。
安裝與啓用¶
README 給出的方式是：克隆或 npm 安裝到 profile 的 node_modules；從源碼安裝需先在插件目錄執行 npm install（prepare 會自動構建）。
運行環境要求 Node.js >= 22.18。插件通過 cordis.patch.yml 掛載到 Cordis 事件面（session/event → tools/post-execute 注入）。資料中未給出統一的 dsh plugin add … 一行命令，安裝前請對照倉庫 README 與 profile 的插件加載方式。
本地校驗可執行：
npm run check
包含 typecheck、13 個 node --test 單測與 build。真實 usage 回放：
npm run replay
在 test/replay-corpus.json（39 個會話 / 206 條 assistant/message 記錄，僅 token 分桶與 turn/step）上，舊單閘規則 17 次「指控」中 6 次被三閘門降級爲變長，11 次真重寫全部保留。
典型用法¶
- 將插件按上述方式裝入當前 dsh profile 並啓用。
- 在長會話中觀察 usage：若懷疑前綴被反覆改寫，在客戶端執行
/cache查看判定與重寫明細。 - 若希望模型主動排查，在工具列表可用時調用
cache_status（實跑日誌中可見模型連續調用，輸出形如「緩存命中率 … · … 步 · 判定: ✅ 前綴穩定」一類摘要）。
出現新的前綴重寫且 adviseModel 爲 true 時，插件會注入一次診斷，無需人工每步盯 inputTokens。
適用場景與注意¶
適合誰：依賴 DeepSeek 前綴緩存、上下文較長、工具結果或粘貼頻繁變長的 dsh 用戶；需要區分「真重寫浪費」與「正常變長」時。
權限與安全：插件以當前 dsh 進程的權限運行，會讀取會話 usage 流並在重寫時注入上下文。安裝前應閱讀 源碼倉庫 與 MIT 許可證，確認符合你的環境策略。SkillHub 目錄爲社區站點，與 DeepSeek / 幻方無官方從屬關係。
已知邊界（README 原文要點）：
- 判定只看 usage 流，無法區分「頭部被重渲染」與「緩存 TTL 過期」——計費形狀相同，提示只標輪次/步驟邊界。
cacheWriteTokens參與 prompt 與命中率口徑，不參與重寫判定（部分 relay 不返回該字段）。- 持續斷裂會被滑動基線吸收：同一會話裏若每一步都在塌，可能只報開頭幾次，之後計數靜默；此時應看命中率與逐步
cacheRead明細，而不只看重寫次數。
結尾¶
dsh-plugin-cache-guard 把前綴緩存從「未緩存數字變高就慌」變成可解釋的三閘門診斷，並用 /cache、cache_status 和一次性 adviseModel 提醒，幫助在長會話裏盯住前綴是否穩定。
