开源fast-jev-compaction：Jev评分替代摘要压缩的Claude Code插件
内容提要
fast-jev-compaction 是 Claude Code 的 MIT 开源压缩插件，使用 Jev 模型为每个工具调用打分，仅删除无用调用与结果，保留内容逐字不改，避免摘要丢失文件路径、报错行号等细节。默认阈值 0.5，保留最近 6 条消息，压缩率不足时退回官方摘要。局限是只删工具结果、不删对话文本，且 Jev 看不到结果原文，可能误删。
延伸解读
逐字保留的代价：缓存与推理轨迹
fast-jev-compaction 承诺保留的用户和助手文本一字不改，但删除工具调用会改变历史序列。在 Claude Code 中，历史中间被删会导致后续缓存全部失效，缓存写入成本可能显著增加。此外，Claude Code 的推理数据以加密形式存在，Jev 看不到，删除历史可能连带丢失推理轨迹，影响模型后续表现。这些是采用前需要权衡的工程成本。
Jev 的盲区：看不到工具结果原文
Jev 在评分时，工具结果正文被替换为“ok, 4213 chars (omitted)”之类的占位符，因此它只能根据调用参数和对话文本判断结果是否重要。这意味着 Jev 可能误删包含关键错误信息或文件内容的结果。虽然助手可以重新运行工具，但对于耗时或有副作用的操作，重跑成本可能很高。
适用边界：工具结果膨胀而文本需保留的场景
该插件只删除工具调用和结果，不删用户和助手的文本消息。因此，它最适合工具结果体积巨大、而对话文本本身必须逐字保留的场景。如果对话文本本身已占满上下文，插件能节省的空间有限，最终仍可能退回官方摘要压缩。它并非取代默认压缩，而是特定场景的补充选项。
默认配置的保守取向：宁留勿删
keepThreshold 默认 0.5，preserveRecentMessages 默认 6，且首条消息固定。这些默认值表明作者倾向于保守：只要 Jev 认为有一半可能有用就保留，最近消息不参与评分。这降低了误删风险，但也限制了压缩率。如果追求更高压缩率，可以调整阈值，但需承担误删关键信息的风险。
Q&A
fast-jev-compaction 是什么？它和 Claude Code 默认的摘要压缩有什么本质区别？
fast-jev-compaction 是一个 MIT 开源的 Claude Code 上下文压缩插件，它用 Jev 模型对每个工具调用和结果进行逐条评分，只删除判定为不再需要的工具调用和结果，所有保留的内容（包括用户和助手的文本消息）都逐字不改。而 Claude Code 默认的摘要压缩会让 LLM 把旧对话总结成一段自然语言摘要，替换掉原始记录，这个过程是有损的，会丢失文件路径、报错行号、具体命令等精确信息。
fast-jev-compaction 具体是怎么工作的？压缩流程分哪几步？
压缩流程分四步：第一步，把每个工具调用和对应的结果按编号配对，第一条消息和最近几条消息里的调用被固定，永远不动；第二步，把整段对话打包成状态发给 Jev，工具结果在状态里被替换成简短说明（如“ok, 4213 chars (omitted)”），但工具输入和对话文本原样包含；第三步，对每个未固定的工具调用，Jev 回答两个问题——调用本身还要不要留、结果还要不要原文保留，每个问题返回 0 到 1 的概率；第四步，概率高于阈值 0.5 就全留，概率中等就保留调用、把结果截断到前 300 个字符，概率不够就整个删掉。用户和助手说过的每一句话一个字不删。
fast-jev-compaction 有哪些局限性或风险？
主要局限和风险包括：只处理工具调用和结果，不删除用户和助手的文本消息，因此如果对话文本本身占满上下文窗口，能节省的空间有限；Jev 看不到工具结果的原文，只知道结果被省略了，可能误删仍有用的内容；Jev 的评分只是概率启发式，不是安全删除的保证，助手可能无法或不愿重新运行工具；删除历史中间部分会导致后续缓存失效，增加缓存写入成本；如果对话长到连 Jev 的 32000 token 窗口都装不下，插件会抛错并退回默认摘要压缩，此时丢失的信息和从未使用该插件一样。
如何安装和启用 fast-jev-compaction？
安装前需要开启 Claude Code 2.1.274 引入的 early-access 函数钩子功能：在 ~/.claude/settings.json 中设置环境变量 CLAUDE_CODE_ENABLE_FUNCTION_HOOKS 为 1，并配置 TYPESAFE_API_KEY。然后通过命令 claude plugin marketplace add tamaratran/fast-jev-compaction 注册插件市场，再执行 claude plugin install fast-jev-compaction@fast-jev-compaction 安装，最后重启或执行 /reload-plugins。安装后按 /compact 触发压缩，提示会显示 fast-jev-compaction: kept N/M messages, no summary。
Jev 是什么模型？为什么它能快速处理大量判断？
Jev 是由 TypeSafe 公司提供的模型，默认模型名为 jev-latest，通过 https://api.typesafe.ai/v1/systemone 端点访问。它被设计为快速直觉判断模型（System One），不做深度推理，只回答结构化的 keep/drop 问题，因此不需要理解代码逻辑或生成自然语言，算力开销远低于让 GPT-4 写摘要。Jev 有 32k 的请求上限，适合大批量小问题场景。
fast-jev-compaction 的默认配置 keepThreshold=0.5 和 preserveRecentMessages=6 意味着什么？
keepThreshold=0.5 意味着只要 Jev 认为某个工具调用或结果有超过一半的概率还需要，就保留下来，这是一个相当宽松的阈值，宁可错留不可错删。preserveRecentMessages=6 意味着最新的 6 条消息（加上永远固定的第一条）不进入评分环节，直接保留，因为最近对话是否有用可能要到下一轮才能判断。这两个默认值体现了作者保守的产品价值观：宁可少压一点，也不要误删。
fast-jev-compaction 的 token 估算为什么不用 tokenizer？
插件刻意不使用真正的 tokenizer 库，而是用一套土公式估算 token 数量（每 6 个字母算一个词、每 2 个数字算一个 token、其他符号大约一个），并校准让估算结果略高于 Jev 实际返回的 token 数。这样只会保守估计，不会激进超限，代价是偶尔浪费一点空间，收益是估算几乎零开销且没有依赖包袱。对于延迟敏感的压缩操作，避免调用 tokenizer 带来的 500ms 卡顿是值得的。
网友对 fast-jev-compaction 的主要批评有哪些？这些批评合理吗？
主要批评包括：压缩不是过滤器，不应天天使用；Jev 看不到工具结果原文，逐条判断质量差，可能导致模型陷入重复试错的愚蠢循环；删除历史会丢掉加密的推理轨迹，使模型变笨；前沿模型已在自身压缩流程上训练过，粗糙方案效果更差；删除历史中间部分会导致后续缓存全部失效，缓存写入成本飙升；永久删除加重新运行工具对有副作用的工具是灾难。这些批评大方向正确，但语气偏激。第二、三、五点尤其成立；第一、四点有道理但偏绝对，因为插件定位是特定场景的补充而非取代默认压缩；第六点情绪化，对只读文件影响较小。结论是：不应把该插件当默认压缩方案，但可作为实验或特定场景的补充。
