宣传省 65%，实测 8.5%：Agent 的 token 账算错了地方

2026-11-07T22:19:55+08:00 | 6分钟阅读 | 更新于 2026-11-07T22:19:55+08:00

@ William Yi

一个 65%，一个 8.5%

GitHub 榜单上有个玩法很欢乐的技能，叫 caveman。口号是 why use many token when few do trick，让编程助手说话像原始人。README 摆了个例子：一段解释 React 重渲染的回答，正常版 63 个 token，caveman 版 20 个，修复方案一字不差。它宣称省 65% 输出 token，现在有 11 万星。

JetBrains 拿它做了正经的 A/B。86 道 SkillsBench 任务，Claude Code 2.1.200，claude-sonnet-5，推理强度调低，全程强制激活技能，三组重复，约 240 次计费试验，花了一百来美元。

结果：输出 token 从 592k 降到 542k，省 8.5%。质量没变差，82 对任务里 8 道变好、10 道变差、64 道打平，平均分 0.326 对 0.311，p 值 0.82。原始账单更有意思，装技能那组反而贵了 11.6%，40.60 美元对 36.39 美元。全部差异来自一道依赖审计任务，它撞过 20 万 token 的计费档，单次 8.29 美元，对面是 0.33。

JetBrains 还写了一段自我打脸的过程：先跑 10 道题，看到省 30%，以为捡到宝；样本加到 82 对，数字塌回 8.5%。他们的结论是，k=1 的实验在这个领域基本等于没做。

我关心的是另一件事：广告数字和真实账单之间，为什么能差七倍。

差异在哪：agent 的 token 流不是聊天记录

那个 63 变 20 的例子，来自一段纯解释性回答。真人跟 agent 干活时，输出里占大头的根本不是解释，是代码、diff、工具调用、报错原文。这些东西不能压，压了就是错。技能只压了工具调用之间的叙述，而叙述在一场真实会话里没多少。

所以 65% 不是假的，它属于聊天场景。它只是跟你的日常账单关系不大。

真正的大头在输入侧，而且是平方级

每次模型调用都要把上下文重新发一遍，这是计费的基本事实，也是大多数人忽略的部分。

手写 agent 最常见的写法是全量追加：历史一条不删，每轮整段重发。第 k 轮的输入差不多是 k·t 个 token，n 轮下来累计 t·n(n+1)/2，复杂度 O(n²)。而 agent 的活儿本来就是多轮的，几十轮很常见。

一篇讲 Agentic Context Management 的论文给了张对照表，假设每轮新增 500 token、预算压到 4000 token（示意值，不是实测）：

轮数	全量追加	固定预算	倍数
50	63.75 万	20 万	3.2
100	252.5 万	40 万	6.3
200	1005 万	80 万	12.6
500	6262.5 万	200 万	31.3

这些数没算缓存折扣，算上会好看一些，增长阶数不会变。

算一笔自己的账。一场 40 轮的会话，每轮新增 800 token，全量追加累计约 65.6 万 token；同样 40 轮，把上下文稳在 6000 token，累计 24 万，差 2.7 倍。一个月跑 20 场，差出来八百多万 token，乘上你手上的单价就是真金白银。

缓存能救一部分，但只救前面。多数厂商对命中的前缀缓存按标准输入价的一个零头收费，前提是前缀一字不变。所以顺序很关键：稳定的系统提示、规则、工具描述放最前面，每轮变化的对话和工具输出放后面。系统提示里塞个时间戳，或者每次拼一个随机 session id 在前面，后面的缓存全部作废。不少人抱怨缓存命中率上不去，问题就出在这里。

同一个技能，压在输出侧是个位数百分点，压在输入侧是几倍到几十倍。省 token 的主战场在哪，一目了然。

压缩不是免费的

把上下文压到固定预算，成本就变成线性，听起来问题解决。麻烦在于压什么。

同一篇论文引了个更早的实验：一次把 18282 token 的上下文压成 122 token，任务准确率从 66.7% 掉到 57.1%，比完全不给上下文还差。理由不复杂，摘要器不知道下游要用什么，就顺手把要用的扔了。

所以真实的选择不是压不压，是压完怎么知道没压坏。这是记忆系统真正的工程难点，也是大部分开源方案绕过去的地方：它们只保证长度，不保证保真。

一条记忆是一份长期订阅

自己搭记忆很便宜，一个 markdown 文件，每次调用全塞进系统提示就行。条目少的时候看不出问题。

mem0 有篇自测（厂商自己跑的，看趋势别看绝对值）给了几个数：24 条记忆全量注入，每次调用 594 个 prompt token；换成检索 top-5，166 个，省 72%。200 条全量注入约 3200 token，500 条约 8000。他们的观察是持续运行的 agent 两三周就会涨到 8 万到 12 万 token 的上下文。

一条记忆写下来可能只有二十来个字，但它每轮都要付费。写进记忆的那一刻，等于签了份按调用次数结算的订阅。这个账在设计阶段很少人算，等发现的时候账单已经涨了两三倍。

有效的做法长什么样

把几个真实系统摆一起，共同点很清楚。

会话开始只给索引。claude-mem 用生命周期钩子抓工具调用，旁边跑第二个 agent 写观察记录，新会话注入最近 10 个会话的摘要，要细节再查（SQLite FTS5 加 Chroma 的混合检索）。它管这叫渐进披露，界面上还标着 token 成本。

工具结果落盘，只给路径。LangChain 的 deep agents 在工具返回超过约 2 万 token 时，把全量写进 /large_tool_results/，agent 只拿到路径加首尾预览，要读哪段自己带 offset 读。

工具和规则按需加载。Claude Code 的 rules 和 skills 就是这个路子，常驻的只有一行描述，具体指令触发时才进上下文。

检索替代注入。Azure 的 Foundry IQ 报的数字是 BrowseComp-Plus 上证据召回最多提升 54%，检索 token 成本降 34%；工具箱方案对大型工具库平均输入 token 降约 97%。厂商数字，打个折看。

有代价的收益要说清楚。ContextSniper 在 SWE-bench Lite 上把 OpenClaw 的总 token 用量从 136 万降到 66 万，成本降 36.4%，但解决率从 26.0% 掉到 24.0%；换成 Claude Code，token 降 38.9%，成本降 27.3%，解决率从 32.0% 掉到 30.0%。省了钱掉两个点，这种数字比“省 50%”有信息量得多。

我的判断

上下文是有价格的预算，不是仓库。围绕这个区别，设计时得回答三个问题：

这条信息每一轮都要付钱吗，值不值这个价。
它什么时候会被用到，用不到就别让它进上下文。
用的时候能不能只取一部分，能拆成索引加详情的就拆。

评价一个记忆系统，别看它记得多全，看它在给定预算下的召回质量。能在 4000 token 里拿到关键事实的系统，强过塞 4 万 token 还漏掉关键事实的系统。这个判断跟模型多强没关系，纯是工程问题。

明天就能改的几件事

常驻内容和按需内容分开。系统提示只放规则和索引，事实、案例、历史走检索。
工具输出先落盘。定位用 grep 比语义搜索便宜得多，能精确匹配就别向量检索。
写入时就结构化。写入质量决定检索上限，存一句“用户提过定价方案”，以后永远检索不到“用户 4 月 3 日从 Starter 升到 Pro”。
压缩后做回放验证。拿历史任务重跑一遍，比对关键事实还在不在。没验证的压缩比不压缩更危险，它会自信地给出错误答案。
建 token 基线告警。记每次调用的用量，超过基线 1.5 倍就查。突然的尖峰通常是检索有 bug，或者某个工具吐了超大数据，不是你真的用多了。

最后

榜单上的百分比是营销指标，账单上的百分比是工程指标。这两个数差七倍这件事，本身就值得记一下。

下次再看到“省 65%”的技能，先问它省的是哪一段 token，再算那段在你的会话里占多少。大部分情况下答案是：不多。

参考来源

上一页 📊 GitHub 趋势日报 — 2026-11-07

下一页把 7440 亿参数塞进 25GB 内存：MoE 流式卸载的账本