Hermes Agent 的公开评测把 Jev 放进上下文压缩流程后，单次调用更快、更便宜，但保留了更多上下文。
78.9%
现有方案召回率。
75.5%
Jev 默认召回率。
2.1×
Jev 保留上下文。
图：Hermes Agent 的评测信息图比较了现有压缩方案与 Jev 的召回率、保留上下文和单次压缩成本。
01 Jev 压缩的对象，是旧工具调用。
AI Agent 长时间工作时，聊天记录里会堆积大量工具调用：读文件、跑命令、查网页、写入结果。上下文窗口越来越满，系统就要压缩旧记录，给后续任务腾空间。
Jev 的做法是给旧工具调用逐个评分，再决定保留调用、截断结果，还是直接丢弃。引用帖展示的正是这个过程：工具调用记录被筛选，旧结果从会话中退出。
工具调用本身通常占据大量上下文。程序化清理可以绕开一次完整的摘要生成，降低单次压缩成本和耗时。
02 评测数字把“便宜”放回上下文账单。
NousResearch 在 Hermes Agent 的 PR #116246 中给出了三条 500K 级别会话的评测。现有方案加一次 session_search 恢复，召回率为 78.9%，压缩后保留约 55K token。Jev 默认方案的召回率为 75.5%，保留约 115K token。
Jev 每次压缩约需 1.4 秒，成本约 0.007 美元。现有摘要路径约需 36.9 秒，成本约 0.061 美元。单看一次压缩，Jev 的成本约为现有路径的九分之一，速度约快 25 倍。
另一组数字改变了这笔账：Jev 每轮保留的上下文约是 2.1 倍。后续每一轮请求都要继续携带这些文本，输入 token 的基线随之上升。缓存命中也取决于前缀是否稳定，压缩过程改写会话后，原有前缀缓存会失效。
这也是为什么“单次压缩便宜”不能直接等同于“长期运行便宜”。
动图：引用帖中的 Jev 演示展示了工具调用记录被筛选和清理的过程。
03 重复压缩后，释放空间会逐轮变少。
如果压缩只处理工具调用，用户和助手之间的文字会持续留在会话里。每轮能删除的旧工具结果越来越少，文本占据的底线却越来越高。
PR 中的重复压缩模拟记录了这条变化。不同会话和窗口设置下，单轮释放比例分别从 89% 降到 55%、从 76% 降到 20%，还有一组从 63% 降到 8%。在 200K 窗口的一个文本密集型会话里，系统在完成约 0.42M token 的工作后进入卡住状态，后续压缩释放量降为 0%。
关键帧：引用视频中的工具调用界面，画面显示压缩过程的操作结果。
在 160K 窗口的一组模拟中，Jev 约每 14 行就要压缩一次。压缩频率越高，缓存被打断的次数越多，保留上下文又会继续推高每轮输入量。
这组结果把上下文压缩从一次性“删多少”变成了一个连续系统问题：删得快，是否能持续腾出空间；保留得多，后续请求是否承受得起；会话被重写后，缓存还能否继续工作。
这也是 Jev 评测最有价值的部分。它没有停在单次速度和价格，而是把压缩放进长会话里反复运行。
关键帧：引用视频后段的工具调用界面，作为视频内容的补充取证。
04 Jev 仍有位置，但评测把位置划得更窄。
PR 的结论是暂不采用 Jev 作为 Hermes 的主要压缩路径。原因集中在三点：默认评测的召回率低于现有方案；保留上下文约为 2.1 倍；重复运行后释放空间递减，并持续触发缓存重建。
PR 仍把 Jev 留在一个更窄的组合位置。它可以作为前置筛选，先处理明显过时的工具结果，再交给摘要或其他压缩路径完成长期整理。对于这种组合用法，需要补测前置筛选减少了多少摘要输入、是否保住关键调用，以及后续压缩频率是否下降。
评测给开发者留下的判断标准很具体：看任务召回率，也看压缩后每轮保留多少 token；看单次成本，也看重复压缩后的释放比例和缓存命中。上下文管理器最终服务的是整条会话，而非某一次清理动作。
SOURCES。
来源：Teknium 的 X Note Tweet 与配图。
来源：NousResearch/hermes-agent PR #116246，评测结果与重复压缩模拟。
来源：Hermes Agent 官方上下文压缩与缓存文档。