Hermes集成Jev引擎：删掉75%上下文但一句人话都没丢
内容提要
Jev上下文引擎集成Hermes Agent，通过逐条判断工具调用及结果是否保留来替代传统摘要压缩。实测上下文减少约75%至82%，用户和助手消息原文不动，仅移除旧工具结果，并支持expand工具找回原文。代价是压缩越激进，Agent回头检索次数越多，误判率成为关键指标。
延伸解读
摘要压缩的隐藏成本：缓存失效与信息失真
文章指出，传统摘要压缩不仅可能丢失关键细节，还会破坏Anthropic提示缓存的前缀稳定性，导致后续对话无法享受缓存折扣，推高成本。Jev通过逐条判断工具调用去留，避免生成新文本，从而保持缓存前缀不变，但这也意味着它必须精确判断每条工具结果的价值，否则误删会导致Agent额外检索。
Jev的逐条评分机制：如何区分调用与结果
Jev对每条非钉住的工具调用分别评估调用本身和结果的重要性，使用Noul问题返回0到1的概率，默认阈值0.5。若两者均低于阈值则整体移除；若仅结果低于阈值，则保留调用但截断结果至前300字符。最近三次调用及短结果被钉住不评分。这种细粒度判断允许保留调用记录而丢弃冗长输出，但依赖Jev对完整对话的可见性。
expand工具与误判代价：从丢失到可恢复
awesome-jev-compaction引入冻结区和工作区，被移除的工具结果存入外部存储并留下指针，Agent可通过expand工具取回原始文本。这降低了误判的代价，但expand本身消耗上下文和回合。文章强调，压缩率并非核心指标，误判率才是关键：错误移除且未找回可能导致Agent基于不完整信息决策，而频繁expand则抵消压缩收益。
Jev的32k窗口限制：判断质量受限于适配压缩
Jev自身上下文窗口仅32k token，超出部分需经过适配压缩：工具输入截断至1000/200/60字符，长文本压缩为头尾，最老的非钉住消息折叠。这意味着Jev在判断时看到的并非完整历史，而是二次压缩后的版本。文章指出，一个自己都看不全上下文的模型，其删除决策的置信度缺乏公开数据验证，这是Jev路线尚未解决的缺口。
Q&A
Jev 上下文引擎和传统的摘要压缩方式有什么本质区别？
传统摘要压缩是用大模型把旧内容总结成一段话替换原文，而 Jev 完全不生成任何自由文本，只对每条工具调用和结果做是/否概率判断，根据概率决定删除、截断或保留。摘要可能编造或丢失关键细节，Jev 则保留原始文本，只移除旧工具结果。
Jev 在 Hermes 中具体是怎么判断一条工具调用该不该删的？
Jev 对每条非钉住的工具调用问两个问题：调用本身对当前任务是否重要，以及结果原文是否还必需、能否重跑替代。两个问题都用 Noul 返回 0 到 1 的概率，默认阈值 0.5。若两个概率都低于阈值，调用和结果一起移除；若结果概率低但调用概率高，则保留调用、把结果截断到前 300 字符加说明。最近三次工具调用和结果长度不超过 1500 字符的直接钉住。
Jev 压缩后如果 Agent 又需要被删掉的内容怎么办？
awesome-jev-compaction 项目把上下文分成冻结区和工作区，低分工具输出被移到外部存储，原位置留下指针，并给 Agent 一个 expand 工具。Agent 调用 expand 就能取回原始文本的逐字节副本，把误判代价从信息永久丢失降级为多跑一个工具调用。
Jev 集成到 Hermes 后实测的压缩效果和成本如何？
实测上下文平均减少 75%，对比标准摘要器的 55%；两个案例分别从 278,924 字符砍到 52,215 字符（削减 81%），从 277,078 砍到 50,695（削减 82%）。平均压缩耗时 5.6 秒，摘要器为 44.8 秒；选择模型成本每次压缩 0.002 美元。长任务中 token 用量减少 30% 到 40%，缓存 token 成本相应下降。
Jev 压缩越激进会带来什么代价？
压缩越激进，Agent 回头检索被移除内容的次数越多，误判率成为关键指标。一个调优实验显示：阈值 0.10 时节省 1092 token，Agent 回头找次数为零；阈值 0.35 时多节省 168 token，但回头找了三次。误判可能导致多花一到两个回合，甚至让 Agent 基于不完整信息做出错误决策。
Jev 在 Hermes 中有什么局限性或未解决的问题？
Jev 自身上下文窗口只有 32k token，超过这个窗口的会话它看到的是经过适配压缩后的版本，而非完整上下文，判断质量受适配质量影响。此外，外部引擎在 Hermes 里是黑箱，宿主只调用 should_compress() 和 compress()，不传递 max_tokens 等细节，插件开发者已提交 issue 请求增加压缩生命周期事件以构建审计追踪。
