Jev 的压缩策略存在六大核心问题，不建议普通开发者使用

这是一种糟糕的压缩策略，从根本上就没有理解压缩和上下文管理的工作方式。很多人对此感到困惑，我们来逐一拆解分析。

第一，压缩不是过滤器。压缩的作用是整理历史记录，让AI代理保持专注，而不只是删除无用信息。它应该只在上下文过长时偶尔使用，而不是一直用来维持较小的上下文体积。

第二，Jev甚至不知道自己在决策什么。大模型会利用对话上下文来决定摘要中保留或删除哪些内容，但Jev的实现是按逐行（逐工具调用）决策保留或删除内容。这种方式下，拥有32k token上下文的模型对之前发生的事情所知甚少，甚至不知道工具调用的结果是什么。随机删除内容会让模型不知道自己已经尝试过哪些操作，最终会陷入“愚蠢循环”，反复尝试同一件事。

第三，你会彻底放弃推理过程。OpenAI、Anthropic、XAI和谷歌的前沿模型不会通过API分享推理轨迹，它们只会分享加密负载，Jev无法读取这些内容，通常还会直接丢弃。Anthropic在这方面要求更严格，它要求开发者保留全部历史记录才能获取推理数据。因此，在Claude Code中使用该策略一定会让模型表现得更迟钝。

第四，模型已经针对自身压缩流程做了调校。过去一年里，前沿实验室已经把压缩和长对话流程纳入训练过程，这些模型学到的压缩方法比任何初级解决方案都更有效。有个有意思的事实：如果你在Codex中切换模型并且需要压缩，压缩会在对话中之前使用的模型上运行。

第五，缓存写入比缓存读取成本更高。缓存写入是AI代理目前成本最高的环节。我个人在使用Claude Code和Codex时，缓存写入成本经常超过大语言模型总花费的60%。如果历史记录靠前的数据发生改动，缓存写入的成本会高得离谱，因为顶部内容改动会让旧缓存失效。任何一次历史编辑都需要重写该编辑之后所有数据的缓存。比如你的历史记录是「1,2,3,4,5,6」，删除「2」之后，你必须重写「3,4,5,6」，这比把「2」留在历史记录里成本更高。有意思的是，由于这个糟糕的压缩策略已经删掉了所有推理token，重写成本实际上不会太高——因为模型已经丢失了太多数据。

第六，该实现本身非常糟糕。策略里说「没保留的内容会被永久删除，但助手总能重新运行工具或重新读取文件」，实际根本做不到。需要明确的是，这是一个很酷的实验，我也确实觉得它很有意思。但如果你觉得这种基于概率阈值的无用过滤真的是一种合格的压缩策略，我强烈建议你直接使用Claude Code和Codex这类工具的默认设置，这样你出错的概率会低很多。

真正有意思的想法不是「更好的压缩」，更值得探讨的问题是「如果大语言模型不需要处理kv缓存会怎样？」，这正是Diogo在他的回复里暗示的方向。目前已经在缓存优化上投入了大量工作，不清楚这个方向能不能出成果，但至少它很有意思。

如果说要做更便宜、容纳更多数据的方案，我给出的实际答案是：速度和可靠性。可以说Jev是第一个在这两方面都做得足够好、能自然集成到代码中的项目。BAML这类工具之前已经探索过部分相关内容，但它们仍然和模型绑定过深，还经常带有模型的各种奇怪特性。Jev用起来更自然，就像调用代码库中的其他函数一样，它确实能实现一些新颖的用例，但目前我看到的大部分都只是很酷的演示。

更好的压缩只能提升成本的下限，不会提升上限。缓存增长的速度不会有任何变化，进一步降噪唯一的区别就是起始token数从2万降到了1万左右。大部分缓存相关成本都来自上下文窗口的尾部，而不是开头。此前Tibo画过一张图来纠正我在这个问题上的错误理解。