重测51遍：DeepSeek Harness省token插件用对省一半用错更贵

上期关于 DeepSeek Harness 三个省钱插件的测试被评论区批评“太简单”——只跑一个小任务、每种一两遍、模式也没分开。于是这次推倒重来：51 遍完整测试，三种插件单独安装、各自场景、标准模式与 PTC 模式分开对比。结论先行：三个插件各有各的用处，但省的不是同一种东西，用对场景能省一半多，用错反而更贵。

先搞懂两个基本概念

缓存命中：对话越长越便宜，改前文就变贵

DeepSeek^广告 每次请求都要把整段对话从头读一遍。如果读过的前文和上次一模一样，就算缓存命中，价格只有原价的五十分之一。所以对话越聊越长，看着要重读很多，其实大部分都命中缓存，花不了多少。反过来，只要前文被改动，后面就对不上缓存，要按原价重新算。这是理解后面所有结论的地基。

DeepSeek 的缓存机制属于前缀缓存（prefix caching）：服务端把每次请求的输入 token 序列按前缀做哈希，若本次请求的开头与历史某次请求完全一致，这段前缀的 KV 缓存可直接复用，无需重新做注意力计算。因此命中部分只按原价约 1/50 计费，而未命中部分按标准输入价计费。关键约束是“前缀必须逐 token 一致”——哪怕只在前文插入一个字，从该位置起的全部内容都会失效。这也是为什么系统提示词、工具定义、文件内容等放在对话最前面且很少变动的部分收益最大，而频繁改写早期消息（如压缩、编辑历史）会让缓存大面积失效。缓存有效期通常为几分钟到数十分钟，间隔太久再发请求也会失效。

标准模式 vs PTC 模式：工具结果往对话里塞多少

标准模式下，模型一次调用一个工具，结果原样塞回对话。PTC 模式下，模型先写一小段程序，一次调用好几个工具，在程序里筛选统计，只把结果带回对话——往对话里塞的东西天然更少。PTC 模式默认藏着，要在设置里打开“显示代码工作视图”，模式菜单里才会出现。

PTC 是 Programmatic Tool Calling（程序化工具调用） 的缩写，属于“代码执行型”工具调用范式：模型不再逐条返回 tool_call 再由外部执行、把结果回填，而是生成一段可执行代码（如 Python），由沙箱运行时批量调用工具、在代码内完成过滤、聚合、循环，最后只把精简后的结果作为一条消息返回给模型。相比标准模式，它的优势在于减少往返轮次和减少回填进上下文的原始数据量，从而降低输入 token 与缓存未命中成本；代价是模型需要具备写对代码的能力，复杂依赖场景下可能因反复调试而多花 token。这也解释了文中“查大日志省一半、修依赖代码反而更贵”的分化现象。

这次怎么测：51 遍、分模式、看真实账单

每个插件单独装、单独测，用当天能装到的最新版，按各自说明书安装。模型统一为 flash、思考强度 high、智能体团队关闭，也就是刚装好的默认设置。测试任务分两类：文件与日志类任务直接用插件自己仓库里的测试题，题目原文照抄、答案按它的规则判；长对话任务让模型在同一个对话里读完《红楼梦》前 40 回，再考它前面的细节。标准模式和 PTC 模式分开比，每种情况跑 2–4 遍。

花钱不看界面上的估算，而是从绘画记录里把每一次调用的输入、缓存和输出全加起来，按官方价格算。为什么必须多跑几遍？同样设置、同样任务，最贵的一遍是最便宜的 5 倍多——模型有时候会自己绕远路。所以规则在开跑前就写死：每一遍都比对照组便宜、答案也都对，才算省；否则就写“看不出差别”。

三个插件逐个看

Ops：不是省钱插件，是换了一套更紧凑的工具

Ops 读文件更紧凑，能读表格、Word 和 PDF，Windows 上还自带命令行环境。它自己的说明里没承诺能省多少，只说主要为 PTC 模式优化。标准模式下四个任务：一个省、一个更贵、两个看不出差别。切到 PTC 模式后，在 2000 多行的测试日志里找唯一失败的那一项，花的钱少了一半多；在 4000 多行的代码文件里找答案，省了三成多。但同样是 PTC 模式，修一串互相依赖的代码文件反而贵了两成。所以上期说它“反而更贵”，只在标准模式下成立，说太宽了。

Flash Presets：省钱靠规则，不靠 PTC

它不带任何工具，只是一套预设：切到 PTC 模式，再加 13 条规则，比如做完检查就交活、对话提前压缩。装上不会自动生效，每开一个新对话都要在模式菜单里手动选 V3，装完还要重启。这次三遍都比不装便宜大约两成，答案全对。原本以为它省钱是因为用了 PTC 模式，于是又测了只切 PTC 不装它——在这个任务上并不省。省钱靠的是那套规则：调用模型的次数少了三分之一，代价是少了自查。上期有一遍总结里把一个百分比写错了，所以重要数字还是自己再看一眼。

Billion Context：压缩是真的，省钱是假的

它让模型自己决定什么时候把前面的对话折叠成摘要，说 100K 上下文就够用，还能省 5 倍 Token。它要等对话再涨 5 万 Token 左右才开始第一次压缩，所以上期那种小任务它根本没机会出手，只多了一份开销。这次换成读完 40 回红楼梦，对话涨到 30 万 Token，它每遍压缩了 4 到 11 次，对话最大只有 7 万到 14 万，最后四道细节题装和不装都全对，记忆没丢。但花的钱：四遍和不装看不出差别，两遍便宜、两遍更贵。

上下文压缩（context compaction） 指当对话接近模型窗口上限时，由模型把较早的若干轮消息改写成一段摘要，再用摘要替换原文，从而腾出空间继续对话。它解决的是“装不下”的问题，而非“更便宜”的问题：被替换掉的历史原本大多处于缓存命中状态、单价极低，压缩后摘要本身是新增输出（按输出价计费），且改写位置之后的前缀全部失效，需要按原价重算。因此压缩的经济性取决于“节省的缓存读取量”与“新增摘要输出 + 缓存失效损失”的对比，在缓存单价极低的定价体系下往往不划算。它更适合超长会话、必须突破窗口限制的场景。

它们为什么省，又为什么不省

回到绘画记录看细节。Ops 在 PTC 模式下查日志，没有把整份日志塞进对话，没命中缓存的输入少了八成；修多个文件那一项调用次数差不多，但新读进对话的内容反而多了三成，具体原因从记录里还看不清。Flash Presets 是让模型少走几轮——每多一轮都要把前文再读一遍。Billion Context 确实把要重读的缓存砍掉了一大半，可缓存本来只要五十分之一的价，砍掉的是最便宜的那部分；而压缩改写了前文，后面没命中缓存的输入变多，写摘要也要花输出的钱，一进一出就抵掉了。所以它省的是上下文空间，让超长对话装得下，不是在 DeepSeek 上省钱。

普通人怎么选

第一步先看插件页的智能体团队开关：开着的话，同一件小事的账单是三倍；平时关着，大任务想让它多查一遍再打开。这一步比装哪个插件都管用。日常办公想省一点，装 Flash Presets，每次选 V3，关键数字自己核一下。写代码、看大文件、查日志，装 Ops，一定要切到 PTC 模式。经常一个对话聊很久、怕装不下，再装 Billion Context，但别指望它省钱。只是偶尔问几句，什么都不用装。

几个坑：回复下面的“本轮费用”不包括子智能体，看全部要去设置里的费用页；费用插件显示的是估算价，比官方价高一点，对账以余额为准；别信“装了能省百分之多少”这种单个数字，自己连续看几次账单才算数。几个插件一起装会怎样，这次没测，别默认叠加更省。

文中反复提到的“智能体团队”对应 Harness 的多智能体/子智能体（sub-agent）机制：主模型可以把子任务派发给独立上下文的子智能体执行，子智能体有自己的对话历史与工具调用，结果再汇总回主线。好处是并行、隔离上下文、让子任务多查一遍；代价是每个子智能体都要独立支付输入与输出费用，且其开销通常不计入界面上“本轮费用”的统计口径。这就是为什么“同一件小事的账单是三倍”——小事本身不需要拆分，却额外付出了多份系统提示词与往返成本。理解这一点，就能明白为何开关它比选插件更影响账单。

这次没测到的地方

只测了 Flash 模型、Windows 和这一个版本的 Harness，插件更新很快，新版可能不一样；每种情况只跑 2–4 遍，几分钱的差别仍可能是波动；插件仓库里的测试题只测了一半；长对话测的是读书，不是写代码，长时间写代码的大项目这次没有测。装插件之前，先对一下自己是哪种用法。