8.0
热点
AI SCORE
编程提效2026-08-21 01:26
JFrog Boost工程笔记：如何量化Agent的Token优化效果
dev.to · AI#Agent#Token优化#工程度量
Editor brief · 编辑速览
详细披露JFrog Boost如何度量AI Agent的token节省效果，包括方法论设计、基准对比框架，以及「削减84%输出」与「提升会话质量」之间如何区分。
By Shay Dahan, JFrog Boost Co-Founder Yahav Ohana, JFrog Boost Co-Founder August 20, 2026
这篇文章献给那些好奇究竟如何构建一个 harness 优化器的人——更重要的是，如何验证它是否有效。
当我们将 JFrog Boost 推向公开预览时，讲述了那张让我们入不敷出的账单，以及在 JFrog 研发团队中夺回的 1000 亿 token。但那篇文章没有覆盖的是：我们在工程上花费最多时间的问题——如何衡量这一切？
因为事实证明，"我们削减了 84% 的输出"和"我们让你的会话体验更好了"是两个完全不同的声明，而且只有其中一个容易放上仪表盘。
这是系列文章的第一篇，揭示 JFrog Boost 如何自我衡量，然后对比团队已在运行的 token 节省工具进行基准测试。下一篇文章将深入探讨 RTK：它的方法哪些做对了类别，哪些在衡量上有所欠缺。以下内容正是这些基准测试所基于的方法论。
Join Token Saving Slack Community
我们要弥合的差距。输入上下文现在是 Agent 编程账单中的主要项目——按照 Cursor 自己的估算External link.，大约占 70%。你的 Agent 不是在为思考付费。它在为重新读取一个四轮前就已经理解的 pytest 日志付费。浪费是真实存在的，规模巨大，而且几乎完全在会话内部不可见。
为什么明显的解决方案不起作用。一旦你开始观察，就会发现架子上摆满了一堆承诺削减 60–90% 的工具。我们试过它们，借鉴过它们，但始终遇到同样的三个问题：
它们衡量了错误的边界。 在管道中错误的位置进行压缩，会让数字看起来很漂亮。以下会有更多讨论——这是该领域最微妙的问题。
它们在静默优化。 Agent 不知道自己收到的是摘要。所以当它需要你丢弃的那部分时，它无法请求。它只能猜测，或者重新运行命令，或者陷入螺旋。
它们没有运行时反馈循环。 基准测试告诉你一个过滤器在你所想到要测试的任务上是安全的。它什么都告诉不了你——关于周二下午第 400 个会话，在一个团队中没人打开过的代码库里会发生什么。
我们的方法，四项承诺：
准确性是约束条件；节省是目标。 目标从来不是最少的 token。而是使用更少 token 的准确 Agent。如果一个过滤器节省了 90% 但牺牲了一个正确答案，它就是一个糟糕的过滤器。
最后优化。 Boost 是输出进入上下文窗口前的最后一个阶段——而不是更早的阶段。这是一个衡量决策，同样也是一个架构决策。
告诉 Agent 发生了什么。 每个优化后的输出都带有一个标记和一条返回的路。Agent 理解优化层，而不是被它悄悄操控。
将每次恢复视为数据。 当 Agent 请求原始内容时，那不是要隐藏的失败。它是系统中信号最高的事件。
以下所有内容就是这些承诺在实现过程中让我们付出的代价。
我们出发时并不是要建立一个衡量栈。我们是要建立过滤器。
把我们引上这条路的是一段数字开始变得不合常理的时期。我们仪表盘上显示的节省百分比看起来非常棒。与此同时，会话并没有感觉到相应程度的改善。开发者并没有反映他们停止遇到压缩了。一些报告最大的胜利来自那些当我们坐下来阅读实际输出时，其实并没有那么多内容可削减的命令。
有什么不对劲，而"图表向上向右走"对于一个我们即将推向一千名工程师的工具来说，并不是一个可以接受的答案。
顺着这个线索深挖，我们发现一个指标下纠缠着两个独立的问题：
它们需要完全不同的工具。
第一条规则是，我们的任何外部干预都不应该让 Agent 变差——变慢、变笨或卡住。这就提出了一个尴尬的问题：如何在运行时、在每天数千个真实会话中检测到一个困惑的 Agent？
你无法对开发者真实的日常工作进行 A/B 测试。你无法读取对话——Boost 只收集高级遥测数据，如 token 计数和宏观错误；我们从不查看、存储或传输代码或对话，而且我们也不打算开始。而且困惑不会抛出异常。它看起来像一个 Agent 安静地运行了六次 ls 来重新确认自己在哪里。
所以我们需要 Agent 本身来告诉我们。带内地。
The Boost suffix. 每个优化后的输出都以一个短标记结束：
[Boost filtered 84% of the original output, get original content with boost retrieve 123]
The awareness rule. 如果 Agent 不知道如何处理这个标记，它就毫无用处。所以 Boost 附带了一个捆绑的 skill——一个最小的系统提示，告诉 Agent 优化层是什么，以及完整输出只需一个命令就能获取。
The signal. 现在到了有趣的部分。当 Agent 调用 boost retrieve 时，它是在告诉我们，在我们应用的过滤器中，它需要的东西被移除了。那是一个让 Agent 失去注意力而不是获得注意力的过滤器。
我们对每一次 retrieve 发出遥测数据。在会话间聚合后，它成为我们自身最差过滤器的排名列表——按命令、按代码库类型、按语言。一个在过滤器变更后飙升的 retrieve 率就是一次回归，我们像对待回归一样处理它。
这就是飞轮：系统自我暴露失败，按频率排名，并提出在哪里放松。接近自我改进——但每次变更在发布前都有人类审核。我们在优化别人的上下文窗口。那不是一个适合完全自动驾驶的地方。
The offline half. 运行时信号告诉我们在哪里伤害了真实用户；它无法告诉我们整体质量是否发生了漂移。为此我们运行 Terminal-Bench 2.0：相同的任务通过率，成本降低约 12%。相同的答案，更少的钱。这就是标准——一个带有通过率的节省数字，否则就不发布。
我们的大部分 CLI 和 MCP 噪声过滤都受到了 RTK 的启发，RTK 是一个真正巧妙的开源项目，值得为它将这个问题摆上台面而点赞。但在这个想法上构建，暴露了一个我们认为在整个类别中被低估的衡量陷阱。
Where you stand in the pipeline determines what you can honestly claim.
一个基于前缀的优化器包装命令：
rtk git log | grep ABC-123
仔细读一下 shell。优化器压缩了 git log 的输出——然后 grep 运行了。无论 grep 原本要丢弃什么，优化器已经声称 credited for discarding 了。它报告节省的 token 从来就不会到达上下文窗口。如果你在一个 grep 过滤器之前拦截输出，然后把 grep 本来会削减的东西算作自己的功劳，那不是节省。是算术。
站在上游还有第二个代价：你在开发者实际设计的管道完成之前就重写了输出，而这恰恰是你最有可能切掉下游需要的东西的时候。
所以我们选择了另一端：
(git log | grep ABC-123) | boost
Boost 最后运行。它看到的是精确地本来会落入上下文窗口的内容，逐字节一致。它报告的每一个 token 都是一个真正本来要进入的 token。
然后乘以轮数。这是大多数节省估算完全忽略的部分。
每当用户在现有会话中发送新消息时，所有之前的 token 都会再次发送。直到会话触发压缩，每个 CLI 命令、每个输出、每个 MCP 请求和响应都留在窗口中——你在每一轮都要为它们付费。
所以削减命令输出的价值不是你削减的 token 数量。它是你削减的 token 数量，乘以那个输出本会待在上下文中的轮数。一个在第 4 轮被移除的 3000 token 日志不是一个 3000 token 的节省。我们的每会话估算考虑了这种驻留，这就是为什么我们的数字是计算出来的，而不是从压缩比推算出来的。
这就是为什么节省在两个方向上复利：每轮更少的 token 意味着更便宜的一轮，更多轮数才触发压缩，更少的压缩——每一次压缩都让你损失真实的上下文保真度。
如果你也在做这种事，这里有四件事我们会交给刚开始这条路的人：
在选择过滤器之前先选择你的衡量边界。 它决定了你之后产生的每个数字是否真实。
给 Agent 一个与你不同意的途径。 一个 Agent 无法覆盖的优化器是一个你无法调试的优化器。
为恢复路径埋点，而不只是为节省路径埋点。 你的 retrieve 率是一个比你压缩比更诚实的质量指标。
永远不要在没有正确性数字旁边的情况下报告节省数字。 没有通过率的压缩是一个声明，不是一个结果。Boost 是免费的，处于公开预览阶段。在 boost.jfrog.com 试用。——如果你发现一个过滤器让你的 Agent 变笨了，boost retrieve 会比我们更早知道。
这是系列文章的第一篇，将 JFrog Boost 背后的方法论与团队已在生产中运行的 token 节省工具进行基准测试。下一篇：更深入地看 RTK，它的衡量边界如何在真实 Agent 会话中崩溃，并与 JFrog Boost 进行正面基准测试对比。
For further actions, you may consider blocking this person and/or reporting abuse