做过 Agent 项目的朋友应该都清楚Token 用量很多时候不是靠“优化”省下来的而是靠“删掉旧消息”硬扛下来的。最近 Headroom 这个词在圈子里热度很高官方宣传口径相当夸张——能省 60%95% Token。我第一眼看到这个数字是带着警惕的如果这是真的长程 Agent 那种动不动几万 Token 的成本模型直接改写如果这是营销话术那又是一场 benchmark 定义游戏。所以我花了两周时间把公开基准的测算逻辑、几组独立 Agent 场景测试、以及社区里零零散散的真实实测都翻了一遍这篇就当作整理笔记聊聊 Headroom 到底省的是什么 Token、省完车值不值以及真实会话里你能拿到多少。Headroom 其实不是玄学它解决的是所有 LLM 应用都躲不开的“上下文堆积”问题。你只要在真实项目里调过接口就一定能感受到那个痛苦系统提示词几千 Token 躺在那里用户每轮输入几百 Token 进来工具返回结果动不动几十 KB消息列表像滚雪球一样越滚越大最后模型每回答一个问题都要先把几万字的历史读一遍。这种场景下Token 花费大头根本不是“新输入”而是“重复搬运”。Headroom 这类工具的定位就是在消息送进模型之前做一层自动化的上下文压缩和精简。但压缩是门手艺活压缩过头了模型会失忆压缩不到位Token 白省。官方说的 60%95%真实使用中到底能兑现多少这才是大家真正关心的问题。我把“宣传”“独立测试”“社区实测”三个口径放在一起对照了一下结论比宣传数字有意思得多。1. Headroom 在 Agent 链路里到底干了什么1.1 Agent 会话的 Token 消耗结构先拆开看要理解 Headroom 的价值得先明白 Token 在真实 Agent 会话里是怎么烧掉的。一次典型的 ReAct 式 Agent 循环每次模型调用输入由这几部分组成固定不动的系统提示、不断追加的用户消息、工具调用历史和返回结果还有之前若干轮的推理痕迹。假设一个简单的例子你的系统提示词 2000 Token平均每轮用户输入 500 Token再调用两个工具每个工具返回平均 1500 Token。那么单轮的工具结果就是 3000 Token用户输入 500历史痕迹约 1000一次调用的输入大概是 6500 Token 起步。如果这个会话跑 20 轮最大上下文里躺着 13 万 Token其中真正“新增”的只有最后那一轮的量剩下的大部分都是历史消息的重复搬运。这种结构里压缩空间大得吓人。工具返回是最容易产生冗余的地方——同一个 DB 查询五次五次返回几乎一样同一个日志片段被不同工具引用好几次用户重复问同一类问题历史里已经给出了答案模型还是要原封不动地再读一遍。Headroom 如果能把工具输出去重、把历史轮次合并成摘要把重复的上下文折叠掉省 50% 以上在理论上完全不难。1.2 Headroom 的几个核心压缩手段根据公开资料Headroom 的压缩思路大致可以总结成三类。第一类是消息合并。把相邻的、语义相近的多轮对话合并成一个更紧凑的表示比如连续几次工具调用和结果如果可以压成一个结构化摘要Token 量就能大幅下降。这个方式对“Agent 自己跑工具链”的场景尤其有效因为工具链过程本身没有用户参与保留过程信息主要是为了让模型知道“这步做完了、结果是什么”所以完全可以用摘要来代替全文。第二类是工具输出去重和裁剪。同一个工具在同一会话里被反复调用时返回结果往往高度相似。Headroom 会记录已经见过的内容特征对重复度高的输出做差分或直接剔除只保留新增的部分。这一步省下的 Token 非常可观在日志分析、API 轮询这类场景里工具输出可能占据总 Token 的 60% 以上去掉重复后输入量断崖式下降。第三类是软性记忆外置。不是把长历史直接塞回上下文而是转成一个更可检索的状态等到模型真的需要某段细节时再局部召回。这个思路和 RAG 很像区别在于 Headroom 更侧重于“对话过程本身的记忆管理”而不是外部知识库。1.3 短会话和长会话的压缩空间差异很多人的第一直觉是“压缩率越高越好”但实际要看会话形态。短会话里连续一两轮对话总共才几千 Token上下文基本没有冗余压缩率可能只有 5%10%甚至可能因为压缩规则本身的元信息反噬而变成负数。长会话、多工具、重复性任务里压缩空间才真正释放出来。这也解释了为什么官方宣传敢写 60%~95%——他们拿的场景一定是长上下文、高冗余的典型 Agent 负载而在这种负载下压缩确实可以做到很激进。问题是真实业务不全是这种场景。后面我会展开说真实会话的分布其实很宽。2. 官方“60%~95%”的测算口径拆开看看水有多深2.1 基线不同结果天差地别宣传数字里最值得较真的是“基线”。官方基准如果拿“一个完全不压缩、所有历史原样保留的 20 万 Token 会话”当成基线然后把压缩后的上下文算到 3 万那压缩率是 85%没问题。但问题在于真实项目里没人会把上下文裸放到 20 万 Token大部分人早就用了截断、滑动窗口或者摘要记忆。我做了个简单测算。假设你的会话原始 10 万 Token你原本已经用滑动窗口只保留最近 3 万 Token再上 Headroom 压缩成 1.5 万。如果拿 10 万作基线官方口径会说压了 85%但拿你已经优化过的 3 万作基线实际增量节省只有 50%。两个数字都是真的但对你的钱包意义完全不同。所以看宣传数字时第一件事要问清楚基线是被动全量还是一个已经做过基本优化的方案。2.2 那些“水分点”藏在哪官方基准常见的第二个套路是把所有可压缩空间全部算进收益却忽略压缩带来的语义损失。通常在公开演示里你会看到一段 5000 Token 的日志被压缩成 300 Token看起来省了很多但如果这个日志里恰好有模型后续步骤需要的错误码压缩时被一笔带过那省下的 token 最后会变成一次错误的工具调用、两次重试、额外的输出生成——兜兜转转钱一点没少花。另外公开基准通常选择熵比较低的任务来演示。什么叫低熵任务就是对话内容高度重复、工具结果高度相似、用户意图很少变化的任务。比如同一个 CSV 文件让 Agent 反复筛选不同条件工具返回的头部和元数据每次都一样这就是天然的压缩温床。而现实里的 Agent 会话往往高熵用户每轮提的问题都不一样工具返回的内容也完全独立可压缩空间自然就小。2.3 公开基准缺失的三个关键指标我还注意到宣传基准很少同时报告三样东西最终任务成功率、压缩失败时的回退机制、以及输出 Token 的变化。压缩只针对输入上下文但模型如果因为上下文精简导致理解偏差生成的输出质量会下降有时输出长度反而更长。如果只看输入侧的 Token 节省不看整体 API 成本就可能高估收益。我并不是说官方数字是假的而是说它描述的是一个理想边界。真实使用里你拿到的是“边界打个折扣”后的数字。折扣的大小取决于你的会话形态和压缩配置。3. 真实 Agent 场景能省多少三个决定性变量3.1 变量一会话中的 Token 构成比例我统计了好几个实际项目的会话日志发现 Token 构成大致分几种形态。一种是“工具主导型”工具返回占 60% 以上用户消息占比小。这种场景最适合 Headroom因为工具输出本来就是机器生成的去重和裁剪的空间很大而且压缩后的语义损失相对可控。实测这一类会话输入侧省 40%60% 比较常见如果工具结果里重复病多、噪声大省到 70% 以上也不难。一种是“人机对话主导型”用户消息占比高工具调用少。这种场景下真正能压缩的只有历史轮次的语义合并而用户的原话、意图、偏好往往需要逐字保留压不动。这类会话的压缩率一般就 10%25%和心理预期差很远。还有一种是“混合型”系统和工具各占一部分也是大多数真实 Agent 的形态。压缩率落在 20%45% 是比较常见的区间。所以如果硬要给一个诚实的数字我会说真实会话里别拿 95% 当目标能稳定拿到 30%50% 就已经是这个工具的正确打开方式了。3.2 变量二压缩后信息是否够用这个变量常常被忽略但我觉得比压缩率本身更关键。压缩率再高如果模型找不到关键信息任务失败的代价远超省下的那点 Token。举个例子。我有一个排查类 Agent 会话工具返回里有一长串服务日志上一次报错和这一次报错的完整调用链都在里面。如果压缩策略把“所有历史日志”都缩小成摘要只留最新一条那么当模型需要对比两次异常的时间线时信息就断了。这种情况下一路省下来 60% Token但整个任务废掉重跑反而多付了 3 倍费用。所以“有效压缩率”这个概念特别重要只在保留关键信息的前提下计算节省。这也意味着同一个工具同一套配置在不同项目里表现可能差异巨大。之前给一个客服工单分类的 Agent 做测试压缩后效果几乎无损节省 45%给一个文档审阅 Agent 试了压缩后漏了很多细节最后节省率勉强 15%还退化了。核心原因就是前者是分类任务只需要摘要级信息后者是细粒度阅读理解任务原文一个标点都不能丢。3.3 变量三模型本身对压缩的容忍度不同模型对上下文被压缩后的敏感度差异也很大。更强的模型在上下文被精简后仍然能靠残存线索脑补出完整语义因此容忍度高压缩可以开得激进一些。而弱一点的模型或者依赖长上下文推理的模型一旦中间信息被剪掉立刻就开始幻觉这时候压缩必须保守。另一个容易被忽略的点是模型对“消息历史格式”的依赖。有些模型在训练时对角色标签、分隔符的位置很敏感你强行把多轮消息合并成一段摘要文字即使信息都还在模型的指令跟随能力也可能下滑。所以在压测阶段一定要用实际要用的模型去测别拿别人的评估结果当成你的结论。4. 自己动手一套可复用的 Agent 压缩评测方案4.1 第一步构造可复现的测试样本集看完官方数据和社区分享我只能说一句别人的数字只能给个感觉真正要决策还是得自己压测。我这里提供一个我自己在用的最小评测方案不需要复杂平台照着写就能跑。第一步构造测试样本。从真实会话日志里抽 2030 个完整会话覆盖三种形态短会话15 轮、中等工具会话1020 轮、长任务会话30 轮以上。给每个会话标注一个“关键任务”比如“在对话最后问一个问题答案取决于第 12 轮工具返回的一个错误码”。这样后面就能验证压缩后模型还能不能答对。4.2 第二步用脚本统计 Token 变化然后写一个小的评估脚本分别记录“压缩前上下文 Token 数”“压缩后上下文 Token 数”“原始输出 Token 数”“压缩后输出 Token 数”。Token 统计可以直接用 tiktoken 这类包代码大概长这样import tiktoken enc tiktoken.get_encoding(cl100k_base) def count_tokens(messages: list[dict]) - int: text \n.join(m[content] for m in messages) return len(enc.encode(text)) # messages_original: 压缩前送入模型的完整消息 # messages_compressed: Headroom 压缩后送入模型的消息 before count_tokens(messages_original) after count_tokens(messages_compressed) print(f压缩前: {before}, 压缩后: {after}, 输入侧节省: {(1 - after / before) * 100:.1f}%)别只测输入还要把每次任务的成功率跑出来。同一组测试会话分别用“完全未压缩”和“开启压缩”跑一遍对比最终任务完成情况。如果压缩后的成功率掉了 5 个百分点以上那省下来的 Token 意义就要重新衡量了。4.3 第三步分场景记录结果别只看一个平均值我一开始压测时犯过一个典型错误只取一个整体平均值结果看着还不错但一细分就发现问题。建议按会话类型分开统计至少分成“短会话/中会话/长会话”和“工具主导/人机主导”两个维度最后输出一张类似下面这样的表会话类型平均原始 Token平均压缩后 Token输入节省率任务成功率变化短会话1~5 轮8,2007,4009.8%-1%中等工具会话10~20 轮45,00028,00037.8%-2%长任务会话30 轮以上120,00055,00054.2%-6%工具主导型66,00033,00050.0%-2%人机对话主导型30,00024,00020.0%-1%这张表比任何官方宣传都更说明问题压缩率上限在长会话和工具主导场景里确实能到 50% 以上但不到 95%短会话场景收益很低硬开压缩可能还要搭进去额外的处理耗时。成功率下降也要盯着尤其是长任务会话掉了 6 个百分点这时候就需要调整压缩策略或者关掉部分压缩规则。4.4 社区测试里被反复验证的三个规律我在整理社区反馈时发现几个规律被反复提到。第一越长的会话越省。所有报告高压缩率的同学会话长度基本都在 30 轮以上。第二工具输出重复度是最大的调节杠杆。如果工具返回里有大量重复字段、日志头尾、固定格式数据压缩效果立刻起飞如果工具返回的每条信息都是新信息压缩就很吃力。第三压缩配置不能全开。很多社区帖子反馈“开了最高档压缩后Agent 像失忆了一样”原因就是配置太激进把关键细节也给压掉了。5. 常见问题排查和避坑记录5.1 压缩后 Agent“变笨”了先检查什么如果你开启 Headroom 后明显感觉 Agent 回答质量下降先别急着怪工具按顺序排查几件事。先看工具输出是否被动过。最常见的情况是工具输出里的关键字段比如订单号、错误码、时间戳在压缩时被当成了冗余信息去掉。解决办法是在配置里把这类字段标记为“关键信息”强制保留。再看合并策略。如果你发现几轮历史被压缩成摘要后模型搞混了任务的执行顺序说明消息合并粒度太粗需要把更细的轮次边界保留下来。最后看模型本身。如果连未压缩的会话偶尔都完成任务不理想那压缩只是放大了原有问题不是根因。5.2 什么时候不建议开压缩我自己总结了几类不该强行压缩的场景。第一短会话。三五轮就结束的任务本身 Token 就几千压缩省不出多少还白增加一层延迟和错误风险。第二依赖原文细节的阅读理解型任务比如合同审查、日志精准对比、长文档问答。这类任务任何一个细节丢失都可能改变结论压缩的性价比极低。第三多 Agent 协同中Agent 间传递的中间结果如果被压缩下游 Agent 可能拿到不完整输入整个链路的正确性都会受影响。在这些场景里老老实实做滑动窗口或者直接加预算可能比压缩更稳。5.3 配置建议和最终落地思路如果你决定在真实项目里接入我的建议是从“只监控不开启”开始。先跑一周统计哪些会话 Token 消耗最大再用这些会话去压测看压缩率和成功率曲线。压测结果符合预期再逐步放量最好先从小流量的内部工具先开始别一上来就给核心生产链路开最高档压缩。另一个实用做法是给不同场景设置不同压缩档位。高频低成本场景可以开激进档比如日志过滤、定时巡检面向用户交互的客服、助手类场景开保守档保质量优先涉及财务、法务等准确率敏感的场景建议直接关掉压缩。注意压缩只影响输入 Token输出 Token 依旧按模型正常的输出长度计费所以最终费用节省大概是输入侧节省率打七到八折具体取决于你的输入和输出占比。如果你的场景输出本身就很长那么总账单的节省会比“输入压缩率”的数字低不少。最后再分享一个小技巧。如果你用的是支持函式调用的模型可以把工具返回结果里的结构化字段先做一次预裁剪只保留模型可能需要的字段再去交给 Headroom 做二次压缩。这是我在实际项目里实验下来最有效的一条两套机制叠加才能把 Token 真正压到接近官方宣传的水平——但前提是你确实通过压测确认了你自己的任务安全无事。别人说得再漂亮都不如你自己日志里跑出来的那串数字可信。
