建议：DeepSeek 前缀缓存命中率偏低（~95%），优化空间巨大

## 描述

在使用 QwenPaw 接入 DeepSeek 系列模型（如 DeepSeek-V4-Flash、DeepSeek-V4-Pro）时，DeepSeek 的**前缀缓存（Prefix Cache）命中率偏低**，实测仅约 **95%** 左右。

DeepSeek 的计费体系中，缓存命中（Cache Hit）与未命中（Cache Miss）价格差异巨大：
- 缓存命中：¥0.5/百万 token（Pro）/ ¥0.1/百万 token（Flash）
- 缓存未命中：¥2/百万 token（Pro）/ ¥1/百万 token（Flash）

**95% 的缓存命中率意味着约 5% 的输入 token 未能命中缓存，直接按高价计费。** 对于高频调用场景（如 7×24 运行的 Agent），这会导致可观的额外成本。

## 影响

假设每天调用 500 万输入 token，缓存命中率从 95% 提升到 99%：
- 当前成本：500万 × (95%×¥0.5 + 5%×¥2) = ¥28.75/天
- 优化后：500万 × (99%×¥0.5 + 1%×¥2) = ¥17.75/天
- **每天节省 ¥11，全年 ~¥4000**

对于大量使用 DeepSeek 的用户，这是一笔不可忽视的成本。

## 可能的原因

作为 QwenPaw Agent 用户，推测可能影响缓存命中的因素：

1. **动态系统提示（System Prompt）**：如果 system prompt 中插入了会话级变量（时间、用户信息、随机 ID 等），会导致每次请求的前缀不同，缓存失效
2. **工具定义顺序变化**：如果多个工具（Skills）的注册顺序或描述在运行中发生变化，工具定义的序列化输出会变，缓存前缀会偏移
3. **消息历史中的微小差异**：多轮对话中，assistant 回复的微小差异会打断后续请求的缓存前缀

## 建议

1. **将静态提示与动态提示分离**：把 System Prompt 中不变的静态部分（角色定义、工具描述签名）与动态部分（会话上下文、临时变量）分开，确保静态前缀尽可能长且稳定
2. **工具定义缓存**：对工具/Skills 描述的序列化输出做确定性排序，确保同样的工具集合产生完全相同的 JSON Schema
3. **配置化缓存感知**：在 provider 配置中增加 `prompt_prefix_cache_optimize` 等选项，允许用户根据模型特点调整请求组装策略
4. **缓存命中率可观测性**：在 QwenPaw 的日志或指标中输出每次 DeepSeek 请求的缓存命中信息（从 API 响应头 `x-ds-cache-status` 可获取），方便用户排查

## 环境

- QwenPaw 版本：最新
- 模型：DeepSeek-V4-Flash / DeepSeek-V4-Pro
- API：DeepSeek 官方 API

## 补充

DeepSeek 官方文档中提到了前缀缓存的工作原理，缓存匹配基于**请求前缀的精确匹配**，因此 QwenPaw 在构建请求时确保前缀的稳定性非常关键。