ARTICLE · 1304441
AI不是变笨了,是被工具输出撑笨的:一个78K星＂滤网＂砍掉70%成本
AI不是变笨了，是被工具输出撑笨的：一个78K星"滤网"砍掉70%成本
一万 token 的日志压到 1260，藏在第 67 行的 FATAL 报错一个没丢，4 道题全对——这不是新模型，是一个跑在你本地的"滤网"。
先看一组数字。100 条生产日志，关键错误藏在第 67 条，原始输入 10,144 token，过一遍 Headroom 之后只剩 1,260 token——少了 87.6%，4 道问答题全对（此为项目方自报 benchmark，尚未独立复现）。同样的答案，八分之一的账单。
这不是个例。过去一个月，GitHub 上冒出一整批干同一件事的项目：Headroom（78K+ stars，单月涨 1.4 万）、rtk（85K stars）、context-mode（33K stars）、OpenViking（41K stars）……"上下文压缩层"正在从一种写作手艺，变成一个基础设施品类。
这篇文章讲清楚三件事：你的钱到底烧在哪、这层滤网的原理是什么、以及怎么在 5 分钟内给自己接上。
一、账单到底烧在哪？不是你的问题，是喂进去的噪音
很多 AI 编程工具的问题不是不会回答，而是上下文越来越臃肿。你让 Agent 搜一轮代码，工具输出可能几万 token；再让它读 issue、看测试日志、查构建错误，窗口很快塞满。模型不是突然变笨，是被低密度信息拖住了。
两个佐证：
第一，大头是工具输出，不是你的提示词。 Headroom 官网有一句话：Agent 每次工具调用、数据库查询、文件读取和 RAG 检索的结果里，70%–95% 是样板噪音——重复的 JSON 字段、日志里成千上万行 "INFO ok"、代码里没被改动的上下文行。
第二，厂商自己都在给你的"重复部分"打折。 Anthropic 对命中 KV 缓存的前缀读入给约 90% 折扣，OpenAI 的缓存定价类似。这些折扣的存在本身就说明：账单的大头是重复注入的上下文，而不是你每次新问的那句话。
还有一个更隐蔽的损失：经典研究 "Lost in the Middle" 表明，关键信息放在长上下文中间时，模型准确率明显下降。也就是说，噪音不只是烧钱，还在挤占关键信息的注意力。
所以结论是反直觉的：在换更强模型之前，先清理你喂给模型的东西，可能收益更大。
二、Headroom 的两段流水线：先对齐缓存，再按内容类型压缩
Headroom 是目前这个赛道最完整的项目：Apache 2.0 协议开源、79K stars（Repository Radar 第三方口径，官方页写 77.9K，各家统计略有出入）、PyPI 周下载 12.6 万次。它对每个请求跑两段流水线：
第一段：CacheAligner（缓存对齐器）。 稳定消息前缀，让厂商的 KV 缓存真正命中。Claude 对缓存前缀给 90% 读折扣，但前提是前缀逐字节一致——很多应用因为时间戳、随机排序字段把缓存打穿，CacheAligner 干的就是这个。
第二段：ContentRouter（内容路由器）。 自动识别内容类型，路由到 7 种专用压缩器：
两个设计值得划重点：
1. 只压"活区"。 Headroom 只压缩最新的用户消息和工具结果，系统提示词、工具定义、历史对话这些缓存热区一个字节不动——所以 prompt caching 继续生效，压缩和缓存打折可以叠加。
2. 压缩可逆。 被压掉的原文存在本地 CCR 存储（Compress-Cache-Retrieve），模型拿到一个 headroom_retrieve 工具，需要细节时可以自己取回全文。原文永远不出你的机器——压缩本地执行，这对有合规要求的团队是硬需求。
效果上（项目自报、未独立复现）：代码搜索 92% 节省、SRE 排障 92%、GitHub issue 分诊 73%、陌生代码库探索 47%；GSM8K 数学题准确率零变化，TruthfulQA 甚至略升。注意探索陌生代码库只有 47%——代码库本身信息密度高，能压的空间天然小，这个诚实的数字反而可信。
三、不是一款工具，是一个品类在爆发
把最近一个月上榜的同类项目摆在一起，能看到清晰的分工：
几个观察：
第一，赛道已经分层。 有做单点压缩的（rtk 只管命令输出）、有做全家桶的（Headroom）、有换范式的（OpenViking 干脆不要向量库，让 Agent 像逛文件系统一样逛自己的上下文）。这是基础设施品类的典型演化路径。
第二，口径打架的地方要摊开说。 Headroom 的省 token 幅度，官网首页写"87% 平均缩减"，benchmark 页写 60–95%，早期的介绍文章写 20–95%——三个口径都没错，差别在内容类型：JSON 能压 90%+，纯文本压得少。另外它的开源协议，官方站点和 Repository Radar 都标 Apache 2.0，但部分第三方目录标的是 MIT，以仓库 LICENSE 文件为准。Star 数各家快照也从 77.9K 到 79K 不等。这种"每家一个数"的情况在快速上升的项目上很常见，看趋势比看单点数字更有意义。
第三，独立第三方视角。 Repository Radar 的数据：Headroom 月增约 1.4 万星（+253%/月）、周更版本、359 名贡献者；但bus factor 只有 3——一半以上提交集中在少数维护者手里。热度和工程健壮性之间还有距离，生产环境要留一手。
四、5 分钟接入：三种姿势，选一种就够
Headroom 提供 wrap（包裹现有 Agent）、proxy（本地代理）、SDK/MCP 四种接入方式。最省事的是前两种：
姿势一：直接包裹你正在用的 Agent（零改动）
姿势二：本地代理（适合自己的脚本和应用，代码零改动）
姿势三：代码里显式控制（Python）
接入后跑 headroom perf 看节省统计，headroom dashboard 有实时面板，headroom doctor 做健康检查。如果你更喜欢"给 Agent 发工具"而不是"在前面拦"，headroom mcp install 会把 headroomcompress / headroomretrieve / headroom_stats 三个工具注册给 Claude Code 或 Cursor。
建议的验证方法：接入前后各跑一遍你日常最重的任务（比如让它通读一个仓库找 bug），对比 headroom perf 里的 token 数字和最终答案质量。别信任何人的 benchmark，包括项目方自己的——用你自己的任务量一遍。
五、三种情况，先别急着压
1. 纯推理任务慎用激进压缩。 数学证明、事实问答这类任务，上下文里每句话都可能被引用，压掉的部分可能正是需要的。Headroom 在 GSM8K 上零损耗（自报），但那是它的测试集，不是你的任务。
2. 缓存热区别手动碰。 自己写脚本压缩历史消息时，很容易顺手改了系统提示词或旧对话，把 KV 缓存全部打穿，反而更贵。"只压活区"这条纪律比压缩本身更重要。
3. 合规场景注意数据流向。 Headroom 压缩在本地跑、原文不外发，这点是对的；但如果你的 Agent 本身调云端模型，被压缩后的内容照样会发给模型服务商——压缩层解决的是"少发"，不是"不发"。
···
📌 今日技能卡片
核心技能：给 AI 编码 Agent 加一层本地上下文压缩，用 1/3 的账单干同样的活。
工具/资源：
• Headroom：uv tool install --python 3.13 "headroom-ai[all]"（Apache 2.0，GitHub 搜 headroomlabs-ai）
• 备选：rtk（只要压命令输出）、OpenViking（要给 Agent 建上下文文件系统）
实操步骤：
1. 安装后执行 headroom wrap claude（或 codex/cursor）包裹现有 Agent
2. 用你最重的日常任务跑一轮，记录 headroom perf 里的 token 基线
3. 对比压缩后同样的任务：token 数、答案质量、耗时
4. 效果稳了之后，把 headroom proxy --port 8787 写进 shell 配置常驻
5. 每周看一次 dashboard，留意压缩率异常下降（通常是内容类型变了）
时间投入：安装接入 5 分钟，验证 1 个任务 15 分钟，形成习惯约一周。
···
写在最后
2025 年我们卷 prompt 怎么写，2026 年上半年卷 RAG 怎么检索，现在轮到了第三层：在 token 进入模型之前的那道闸门。
模型价格还在降，但 Agent 的工作量涨得更快——账单的胜负手不在单价，而在你每个任务喂进去多少垃圾。省 token 的最高境界不是用便宜的模型，而是让贵的模型只看值得看的东西。
互动时间：你的 AI 编码账单一个月多少钱？接入压缩层之后省了多少？评论区报个数——如果你已经在用 rtk 或 context-mode，也来说说和 Headroom 的实际对比。
下期（周三）大概率切回 AI 编码实战：周末 OpenAI 和 Anthropic 的下一代旗舰被扒得沸沸扬扬，等官宣落地后，我会结合 Codex 的底层重构讲讲"Agent 自己拉起子进程连续工作几小时"对编码工作流意味着什么。
本文所有压缩率数据除特别标注外均为项目方自报、尚未独立复现，请以自己任务的实测为准。
