博客 · 分析
最小 harness 如何做到 99.93% 缓存命中率
2026 年 8 月 14 日 · dshbase
跑 DeepSeek 最便宜的方式不只是便宜的模型——而是能复用模型已经算过的内容的 harness。开源 Agent Pi 的社区实测显示99.93% 前缀缓存命中率。这个数字不是模型属性——是 harness 属性，而它背后的杠杆是具体、可迁移的。
成本驱动因素
编码 Agent 每一步都要重发系统提示词、工具定义、历史对话和代码。自动前缀缓存在请求开头不变时复用已计算的前缀。缓存命中率就是复用的 token 占比——越高越便宜。按 token 付费时，每少重发一块都是省下来的钱，而最大的重发块正是 harness 能控制的那几样：系统提示词和工具 schema。
缓存为什么脆弱
加个时间戳、调换工具顺序、或重写前面内容，缓存就失效。缓存友好的 harness 会保持请求前缀稳定。大多数 harness 就在这里悄悄输了：它们每次调用都注入新时间戳、或打乱工具定义，命中率就崩了——哪怕任务本身什么都没变。
Pi 的做法
Pi 默认只给模型四个工具（读、写、改、跑），其余全按需开启；会话只追加不重写。由此引出两个结果：
- 工具越少 = 前缀越小、越稳定。工具 schema 是每个请求最前面的一块固定内容。四个工具是几乎不变的一小块；四十个工具是只要重排或开关一个就会变的一大块。
- 只追加 = 前面的内容永不改变。历史一旦重写，编辑点之后的所有内容都失去缓存；只追加时，前缀保持逐字节一致。
实测结果：约 99.93% 命中率，有缓存约每 10 亿 token ¥19，无缓存 ¥900+。这两个数字之间的落差，就是 harness 设计的全部意义。
7 倍差距
Composio 把 DeepSeek V4 Flash 接进 8 款 harness：Pi 每次成功任务约 $0.028（最低），Claude Code 约 $0.195（接近 7 倍）。同一个模型、不同 harness、账单天差地别。这是「缓存是 harness 属性、不是模型属性」的最强论据。
这对 DSH 意味着什么
DSH 站在同一条谱线里偏向缓存友好的一端，它的设计和 Pi 的两根杠杆直接对应：
- 极简模式只给模型两个工具——一个持久 Bash、一个文件编辑器——这是做基准测试时可能的最小稳定前缀（见模式指南）。
- PTC 模式把大量工具往返压进一次程序执行，让中间数据不进上下文。
- 只追加会话——轨迹日志就是一份只追加事件日志，同时也是一段稳定的请求前缀。
反面的警示是工具泛滥。标准模式自带很大的工具面，而更广的插件生态还会往上加——我们实测 101 个社区插件，就是看这个面能长得多快。你每加一个工具，都是每个请求最前面的一块内容，还可能是会变的一块。所以缓存打法是一种纪律，不是默认值：活动面最小化，其余全按需。
结论
- 最小工具集 + 只追加会话 = 缓存命中的最大杠杆。
- 同一模型在不同 harness 下 7 倍的成本差才是真正的成本故事——模型价格是一个输入，harness 的缓存行为是另一个。
- DSH 方向一致：小活动面、一切皆插件、PTC 把中间数据留在上下文外。
怎么自己测命中率
你不用把 Pi 的数字当成信仰——任何一次运行都能读出你自己的。API 的 usage 块会把缓存命中和未命中的输入 token 分开报，所以每次调用的命中率在响应里就能看到。它一掉，常见元凶就是工具 schema 被重排、或系统提示词里混进了时间戳——两者都是前缀问题，不是模型问题。这就是把前缀当成「要设计的东西」而不是「继承下来的东西」的实际回报。
FAQ
任何 harness 都能做到 99.93% 吗？只有保持小而稳定前缀、并且只追加不重写的 harness 才行。一个会打乱工具定义或注入时间戳的 harness 做不到，模型再便宜也没用。
为什么工具数量会影响缓存？工具 schema 是每个请求最前面的一块固定内容。工具越多，块越大，任何重排或开关都会让它失效。工具越少，前缀越小越稳定。
¥19 和 ¥900+ 的差距现实吗？它反映的是 DeepSeek 标价里缓存与不缓存的价格差——这个价差正是「harness 的缓存行为可能比模型底价更重要」的原因。
这只对 DeepSeek 有效吗？不是——自动前缀缓存是 provider 层的特性，但杠杆在 harness 层。最小工具集 + 只追加会话，在任何提供前缀缓存的 provider 上都能改善缓存表现。