Agent 账单拆解：为什么 prompt 越大，反而越便宜

翻一个 Agent 的运行日志，会看到一件反常识的事：每轮往上下文里塞 6.7 万 token 的 Agent，每轮账单两美分；每轮只塞 1.85 万 token 的 Agent，每轮六美分。小的那个贵了三倍。

这不是记账出错，是提示缓存（prompt caching）落地之后成本结构翻转的结果。而我们大多数人对「贵不贵」的直觉还停留在几年前：prompt 短就便宜。

这个直觉的代价正在变大。2026 年 10 月 16 日的 GitHub 趋势榜上，前八名里有六个项目在做同一件事：帮 Agent 省 token。xerj 用索引检索替代 grep，单日 1647 stars；caveman 号称砍掉 65% token；context-mode 把工具输出塞进沙箱；rtk 做 CLI 代理裁剪命令输出。同期上榜的还有 Anthropic 的官方插件目录和一堆 Agent Skills 库。

赛道确实起来了。但把账单拆开看，这些工具并不在同一个战场上工作，效果差着两个数量级。

账单到底长什么样

主流厂商的计价早就不是「输入加输出」两项了。Claude 系明码标价四类 token：

一个多轮 Agent 会话的成本形状是这样的：走到第 20 步，上下文很可能已经越过 5 万 token，输入输出比能到 100:1。你每一轮都在为「新的提问」和「重新处理整段增长中的历史」付钱。

arXiv 上那篇《How Do AI Agents Spend Your Money?》把这条曲线量化了：在 agentic coding 任务里，输入 token 才是成本大头，开了缓存也一样。更刺眼的是，缓存读取在每一个阶段都是最大的单项支出。输出 token 单价贵 80 倍，但总量太小，打不过缓存读取的量。

记住这句话：你以为在省的是输出，账单里最大的一块其实是缓存读取。

第一层：让模型少说话

caveman 是这个方向最出名的项目，单日 943 stars，靠「让 Agent 用原始人语气说活」出圈，README 首页写着砍掉 65% token。

但它仓库里那份 HONEST-NUMBERS.md 更值得读，写得相当实在：

• 这个 skill 只改变输出风格，对输入 token 的节省是 0%
• 规则本身要额外注入约 1,160 token 的输入
• 那个 65% 的对照基线是「默认啰嗦输出」；如果基线里已经写了「回答简洁」，中位数只剩 3%，换成 /ultracave 是 35%
• JetBrains 做的 86 个真实编码任务配对 A/B：输出 token 少 8.5%，质量没有统计上可测的差异（p = 0.82）
• 662 个 Claude Code 会话统计下来，输出 token 只占总 token 的 0.3%
• 有人（issue #550）在 Cursor 上做 A/B，开着 caveman 用了 430 万 token，关掉只用 100 万
• 按请求计费的产品（比如 GitHub Copilot 的 premium request），答案变短一分钱都省不下来

第 5 条解释了前几条为什么无关紧要。输出总共占 0.3%，你在这个千分之三的盘子上做到 65% 的降幅，等于省了千分之二。

Adobe Research 那篇引用这个仓库的 CAVEWOMAN 论文确实测出成本降了 1.4 到 2.4 倍，看它的实验设置：八种模型、五种数据集、纯输出层面的对比。它证明的是「话说得少就便宜」这个局部结论成立，不是「装个 skill 能省一半账单」。

那 caveman 的 943 个 star 是假的吗？不是。它解决的问题真实存在，只是不在账单上：Agent 输出一屏废话、每次都要重新解释一遍、review 一行得读三行。这些磨的是你的注意力，不是你的钱包。它被当成省钱工具传播，实际更像个体验工具。

这里有个可以复用的判据：看到优化工具报百分比，先问它的分母是什么。「输出减少 65%」和「总成本减少 65%」能差 200 倍。

顺带一提，caveman 自己也在往第二层搬家。v2 把赚钱的部分放到了输入压缩引擎和代理上：一个 40 条记录的 JSON 从 16,098 token 压到 1,091（93%），本地压缩、可恢复、字节安全；54 次 Claude Code 运行统计下来整场会话输入 token 少 33.2%。skill 保持 MIT，引擎换成 BSL-1.1。一个纯 skill 项目最后把商业重心移到输入侧，本身就说明钱在哪一层。

第二层：让模型少读

真正在读进上下文这一层动手的项目，数字完全不同。

context-mode 走沙箱路线：用 hook 拦截工具调用，把 Bash、Read、WebFetch 这些吃上下文的操作重定向到隔离子进程里执行，只让 stdout 进对话。它的 benchmark 用的是真抓取下来的数据：

合计 315 KB 原始输出压到 5.4 KB，整体 98%。

它还有一个更狠的思路叫 Think in Code：与其让模型读 50 个文件去数函数，不如让模型写个脚本自己跑，只把结果打出来。一个脚本替代十次工具调用。

xerj 走的是另一条路，索引。它的判断是 grep 解决不了问题，因为 grep 只告诉你「在哪一行」，要判断那一行还是得把整个文件读进上下文。所以它先把语料用 tree-sitter 解析成 AST 索引，让 Agent 检索到的是「一个带签名和契约的函数」，而不是「一条待确认的行匹配」。

在 8 个任务、4 种语言、每种 16 次运行的对照实验里：

还有个更极端的例子：WordPress 核心的 PHP 代码约 520 万 token，等于 26 个完整上下文窗口，Agent 根本读不完。用索引检索跑一次 1,492 个文件的安全审计，总共花了约 26,000 token，大概是整棵代码树的 0.5%。

这一层降幅 90% 到 99%，比第一层高两个数量级。原因也简单：它动的是「什么东西有资格进入上下文」这个入口，第一层只在出口做文章。

但有两个真实的坑，项目方自己都写了。

第一个是收益依赖拦截的完整性。context-mode 承认：装好 hook 能省 98%，不装 hook 只能省 60%。因为一次没被拦住抓到的浏览器快照，就能把整场会话的节省吃回去。它甚至专门做了 FloodGuard，限制模型用大量小检索把上下文重新填满。

第二个是精度代价。ctx_execute_file 能做到 95% 到 100% 的压缩，靠的是把数据压成一两行摘要；而 ctx_index + ctx_search 的压缩率是 50% 到 93%，因为它返回完整代码块原文。前者那个「访问日志 100% 压缩」意味着你拿到的是统计数字，不是日志内容。真需要查那行报错的时候，摘要救不了你。

xerj 的约束更根本：它的价值取决于模型对这份代码有多不熟。第三方评测也点到这一层，收益大小跟「模型已经知道多少」直接相关。让模型查自己的老代码，索引带来的节省远不如让它查一个从没见过的 Rust 库。所以它主打 reference coding：先把相似的开源项目 clone 下来索引好，让模型抄同行的现有实现，而不是凭记忆硬写、编译失败、再进重试循环。

第三层：改成本结构本身

前两层都在减少 token 数量。第三层反过来：让 token 变便宜。

现在主流厂商都支持提示缓存，把 prompt 的稳定前缀在服务端存成 KV 状态，后续请求命中按大约十分之一的价格计费，延迟也能降 80% 左右。规则是前缀必须逐字节匹配，从第一个 token 开始比，前面改任何一点，后面的缓存全部作废。

Galileo 把 167 个真实会话日志跑了一遍，结果就是开头那张反直觉的表：

Claude Code 每轮 6.7 万 token，其中 6.3 万是 $0.30/百万的缓存读，只有 296 个是 $3/百万的新鲜 token，合起来两美分。OpenClaw 每轮只有 1.85 万 token，但只有 5.2K 命中缓存，剩下 1.33 万按全价算，合起来六美分。

小 prompt 贵，是因为里面没什么可缓存的。大 prompt 便宜，是因为它每一轮几乎是同一份前缀。

这个翻转直接推翻了一批「常识级」的优化。

比如「动态挑工具，少放几个能省 token」。工具定义是塞在 system prompt 里的，算输入 token。看一组真实的前缀哈希记录：一个稳定挂 32 个工具的 Agent，第 2 步命中了 41,800 个缓存 token；改成每步按需挑 6 到 9 个工具之后，每步的前缀哈希都不一样，命中量掉到 900 到 1,200。纸面上 prompt 短了，日志里每步都在重建缓存。按 $5/百万输入、5 万 token 上下文算，一次缓存未命中是 25 美分，命中是 2.5 美分，每步差 22 美分，二十步下来差 4 到 5 美元。

Anthropic 的文档把缓存失效描述成一条级联：工具，系统提示，消息。你在第 5 步动了工具列表，动的不是请求的尾巴，是整条链。

顺着缓存重排一遍，设计规则就变了：

• 稳定的大块放最前面（system prompt、工具定义、长期指令），写一次反复命中
• 每个 token 都在变的东西（当前时间、随机 ID、用户临时数据）往后放，别污染前缀
• 对话历史是天然递增的前缀，不要重排它
• 想省 token，第一件事是测缓存命中率，不是删 prompt

LMCache 分析过 Claude Code 的真实流量：92 次调用、约 200 万输入 token、前缀复用率 92%。省 token 最大的一笔钱花在哪里，这就是答案。

三种打法会互相打架

把三层放在一起看，它们并不叠加，甚至互相消耗。

caveman 的 skill 自身要注入 1,160 token 的规则文本，这是净增的输入。context-mode 每次 MCP 返回也有几百 B 到 2KB 的开销。xerj 要常驻一个 61.6MB 的二进制进程。所有压缩本质上都是拿一笔固定成本换边际收益，会话越短，固定成本越摊不平。这也解释了为什么 caveman 的 issue 里会有人测出净亏损。

更要命的是缓存：任何「每轮动态变化」的压缩策略，只要它改了 prompt 前部，就会把缓存命中打掉。省下来的 token 量和丢掉的缓存折扣，很可能不在一个量级上。

所以选型顺序应该是这样：

1. 先看计费模型。按请求计费的（Copilot 的 premium request 这类），任何输出压缩和输入压缩都不产生直接收益。
2. 再测自己的账单形状。输出、新鲜输入、缓存读取各占多少。662 个 Claude Code 会话里输出占 0.3%，如果你的数字也是这个量级，就别在输出上花时间。
3. 然后按层选工具。输出层的问题用输出层工具，顺带解决可读性；输入层的问题用沙箱或索引；成本结构的问题回去整理前缀。
4. 最后自己 A/B。caveman 仓库里那句话值得抄下来贴墙上：在你的 A/B 上是负的，就关掉它。

一点判断

这一波项目扎堆出现，说明 Agent 已经从「能不能跑」进入了「跑一次多少钱」的阶段。账单一清楚，工具选型才有依据，这是好事。

但别被百分比带着走。榜单上那些「省 65%」「少 40 倍」的数字，分母各不相同：有的分母是输出 token，有的分母是单个文件，有的分母是特定测试集上的理想条件。它们都可能是真的，又都跟你的月度账单没什么关系。

真正值钱的动作只有两个：搞清楚自己的 token 花在哪一类，以及别做那种会打断缓存前缀的「优化」。前者需要你去看 usage 数据，后者需要你放弃一部分动态拼装的灵活性。两件事都不难，但都比装一个 skill 麻烦。

参考来源

• XERJ 项目主页与案例研究：https://github.com/xerj-org/xerj
• Caveman HONEST-NUMBERS（作者自己公开的实测数字）：https://github.com/JuliusBrussee/caveman/blob/main/docs/HONEST-NUMBERS.md
• Context Mode 与 benchmark：https://github.com/mksglu/context-mode
• The 2026 Caching Playbook for Agents：https://galileo.ai/blog/the-2026-caching-playbook-for-agents-bigger-prompts-smaller-bills
• How Do AI Agents Spend Your Money?：https://arxiv.org/html/2604.22750v2
• Prompt Caching for AI Agents: Architecture Patterns：https://zylos.ai/en/research/2026-02-24-prompt-caching-ai-agents-architecture
• 当日榜单：https://curvesoft.net/posts/github-trending/2026-10-16/