Agent 成本治理第一步：先装水表，再省水

AI Agent 变贵，很多团队第一反应是换模型、换套餐、换更长上下文。这个动作太早了。工程上应该先加一块“水表”：每次调用前，记录模型到底吃了多少输入，里面多少来自用户问题，多少来自工具输出，多少来自文件和 RAG。

内容自动化、代码审查、RAG 问答都有同一个隐性成本：任务本身很短，review、repair、search、summarize 这些中间步骤却会把草稿、审稿意见、修复提示、历史上下文一起塞给模型。建议先记录成这种格式：

{"caller":"quality-repair","provider":"opencode","prompt_tokens":5600,"completion_tokens":2800,"total_tokens":8400}
{"caller":"user-review","provider":"opencode","prompt_tokens":1450,"completion_tokens":380,"total_tokens":1830}

先把每次 LLM 调用记成一行结构化日志。caller 要按稳定业务阶段命名，比如 write-draft、quality-repair、user-review，不要带文件名、随机 ID、时间戳，否则第二天没法聚合比较。

每天跑一次分组排序，先找总输入最高的 caller：

jq -s 'group_by(.caller)|map({caller:.[0].caller,calls:length,prompt:(map(.prompt_tokens//0)|add),total:(map(.total_tokens//0)|add)})|sort_by(-.prompt)|.[:10][]|[.caller,.calls,.prompt,.total]|@tsv' calls.jsonl

输出四列：caller、调用次数、输入 token 总量、总 token。先盯第三列，谁最高先改谁。

第一眼只看三件事：哪个 caller 总输入最高；它长在用户任务、工具输出还是历史上下文；这个长输入有没有换来更高通过率。很多时候，最该优化的是某个工具：它把几百行日志、搜索结果、文件全文原样交给了模型。

等水表跑两天，再评估压缩层。比如 GitHub 项目 Headroom，它把自己定义为 AI agent 的 context compression layer，README 里的核心位置很清楚：tool outputs、logs、RAG chunks、files、conversation history 进入模型前，先做去重、裁剪、摘要和可回取缓存。

我的接入顺序会很保守：先处理重复日志和搜索结果；再处理重叠 RAG chunk；最后才碰文件全文和全局代理。每一步都看三个指标：输入 token 降幅、任务通过率、回取原文次数。只看省钱，很容易把证据也压没。

适合先动刀的地方：grep 搜索结果、重复堆栈、RAG 重复 chunk、长日志里的同类行。暂时别动的地方：patch 生成、配置审计、合同阅读、schema 修改。这些任务里，少一行原文就可能变成错误。

一周内能落地的版本：先不装任何压缩工具，只加调用日志，找出前三个 prompt_tokens 最大的 caller，把它们的工具输出做去重和截断。水表装上，才知道该省哪里。

参考资料：headroomlabs-ai/headroom GitHub README。