caveman：以洞人口吻压缩 AI 编程代理的 token 成本

技术背景与问题定义

编程代理按 token 计费。每个 token 都要花钱，而代理既要写，也要读。写的部分是它的回复。读的部分是日志、测试输出、JSON、diff 和搜索结果。两头都会累积成账单。 caveman 把问题拆成两个方向。第一个方向是“说”：让模型用更短的口语回答，去掉客套话和铺垫。第二个方向是“读”：在模型看到工具输出之前先压缩一遍，同时保留原文，方便随时取回。

这个项目的问题定义很直接。多数代理写得像求职信，读得像消防水管。作者的判断是，输出端和输入端都值得压缩。 项目 README 的标题写着“cuts 65% of tokens”。这个数字来自宣传语，并不是测出来的结果。下文会逐一核对可测量的数字。

核心架构与原理解析

caveman 由三个相互独立的组件构成。 第一是 skill。它本质上是一份规则文件，告诉代理用“洞人式”口吻回答。README 称它支持 30 多种代理，包括 Claude Code、Codex、Gemini CLI、Cursor 和 Windsurf。安装命令是 `npx skills add JuliusBrussee/caveman -g`。规则只影响模型自己写的文字。

第二是 proxy。它运行在本机，位于代理和模型服务商之间。请求发出前，它压缩工具结果，例如日志、JSON、diff 和测试输出。压缩前的原文以字节级精确的形式存入本地 SQLite，并附上一个恢复句柄。模型需要原文时，可以调用 `caveman_retrieve` 工具取回。 第三是 middleware。它面向开发者自己的应用。开发者在 LangChain、Vercel AI SDK、OpenAI 或 Anthropic 的调用外面包一层。大体积工具结果在发给模型前被替换成短版本，完整历史仍保留原文。 这种分层的设计意图很清楚。skill 管输出，proxy 管输入，middleware 把同样的输入压缩带进别人的代码。三者共用同一个原则：压缩必须可以还原。

关键功能与实战评估

这里要区分三组数字，因为它们测的东西不同。 JetBrains 在 86 个真实编程任务上做了配对 A/B 测试，只测了 skill，没有 proxy。结果是输出 token 减少 8.5%，成本约降 10%。质量方面，符号检验的 p 值为 0.82，平均任务分数从基线的 0.326 变为 0.311，差值 -0.015。按这份测试，质量没有可测量的下降，但输出省下的部分很小。 Adobe Research 的 CAVEWOMAN 论文是 README 引用的第二个来源。论文报告，输出端的洞人式风格在部分模型上把实际成本降到原来的 1.4 到 2.4 倍，最好情况下达到 3 倍。这份结论来自论文，本文没有在仓库里复现它。 第三组数字来自仓库自己的测试。在一套 54 次运行的 Claude Code 基准中，proxy 把输入 token 减少了 33.2%，18 项答案检查全部通过，区间为 14.6% 到 48.5%。但 README 也承认，原始 harness 产物不在仓库里，所以这是一份固定报告，不是公开的复现。测试由项目方自己完成，读者要带着这层关系来看。

隐私方面也有一点要注意。CLI 默认开启遥测，上报随机安装 ID 和 IP。用 `caveman telemetry off` 可以关闭。单独使用 skill 时不会上报。 什么时候该跳过？如果任务依赖措辞的精确度，例如法律文本、面向用户的文档或安全警告，那么洞人式输出的收益不值得承担风险。README 自己也说，安全警告和“你确定吗”之类的确认会恢复成完整句子。 实际落地时，建议先跑一次 `caveman trial`。它会让同一个会话分别在开启和关闭 caveman 的情况下运行，再用报告给出差异。README 明确指出，这样得到的 A/B 结果比页面上的任何数字都更可靠。原因很简单：工作负载差异很大。日志多、测试输出长的仓库，代理节省的比例会高；以写代码为主、工具输出很短的会话，节省就有限。一个百分比只能说明它出现的那个场景。 还有一个工程细节值得注意。proxy 把原文保存在本地 SQLite 中，这意味着磁盘上会累积原始内容，其中可能包含源代码、路径和密钥类字符串。团队在启用前应当确认这些数据的保留期限，以及本地磁盘的访问权限。这一点在 README 中没有展开，需要自己核对。

行业影响与未来演进

caveman 的影响主要不在技术深度，而在它把一个问题讲清楚了。账单按 token 计，而 token 有两个方向。多数团队只盯着输出，忽略了读取。 proxy 的思路与同类工具形成竞争。README 对比了 Headroom 和 RTK，并引用 JetBrains 的数据，称 RTK 在低推理强度下每任务中位成本上升 7.6%。这是对方的测量，不是本项目的测量。

对开发者的启示有三点。第一，先测量自己的工作负载，再相信任何百分比。README 的 `caveman trial` 命令就是为此设计的 A/B 方式。第二，压缩必须可逆。原文无法恢复的压缩，等于替模型做了无法撤销的决定。第三，质量指标要和成本指标一起看。 未来的关键问题是：读取端压缩能否在更长的任务、更多工具和更复杂的代码库上保持正确率。现有数据还不足以回答。项目采用 Apache-2.0 许可证，从 3.0.0 版本起覆盖全仓库，这有利于第三方独立验证。