Jev 团队公开 Coding Agent 设计草案每轮重新决定模型「该看什么」fast-jev-compaction 只是第一步【免费下载链接】fast-jev-compactionClaude Code plugin that replaces the compaction summary with Jev decisions: every tool call and result is scored in one fast request, stale ones are dropped or truncated, everything kept stays verbatim.项目地址: https://gitcode.com/gh_mirrors/fa/fast-jev-compaction2026 年 9 月中旬TypeSafe AI 发布了一款名为 Jev 的「System One Model」——它不生成文本只针对给定的材料输出 choice、score、noul 三类结构化答案每个问题耗时约 70–500 毫秒输出 token 免费。这则消息在 Hacker News 上一天内冲到 1863 分、491 条评论随后两周内带出了一个包含 28 个项目的开源生态。其中被讨论最多的是一个叫 fast-jev-compaction 的 Claude Code 插件它把/compact从「让模型写摘要」改成了「给旧工具调用逐项打分」实测可将约 18.8 万 token 的会话压到 3.3 万耗时约 1.4 秒。但比这个数字更值得注意的是 Jev 团队同步公开的一份 Coding Agent 设计草案。其核心表述可以浓缩为一句话每一轮都重新决定模型该看什么。fast-jev-compaction 正是这个理念的第一个工程化落地——而它暴露出的争议与边界恰好勾勒出下一代 Coding Agent 上下文管理的完整问题域。本文结合社区情报与仓库源码把这个「第一步」拆开看。一份「不写摘要」的草案每轮重看逐条判定传统上下文压缩的范式是「改写」让 LLM 把前面的对话重新写成一份短摘要。问题很直观——文件路径、精确报错、限制条件、已经试过的失败方案都可能在改写时消失而它们恰恰是长会话里最不能丢的工程证据。fast-jev-compaction 换了一个思路。它不生成任何一个字而是把「保留什么」变成逐条判断题把每个tool_use和对应的tool_result配成一组让 Jev 分别回答两个问题——「这个调用还需要保留吗」「它的结果还需要原样保留吗」Jev 不是聊天模型它接收一段状态和一组结构化问题返回概率让代码自己决定下一步。这正对应草案的核心每一轮压缩都不是「把已有上下文变短」而是基于当前任务目标重新决定哪些记录还该被模型看见。在仓库里这一理念落在三个层次上第一任务目标被显式建模。每次请求发送给 Jev 的 state 包含三部分一段固定的上下文说明context、当前任务描述goal和完整历史history。其中goal默认取最后三条用户提示——这是「当前正在做什么」的锚点见 src/state.ts 的goalFromMessages。Jev 就是对着「任务目标 完整历史」来做每一道判断题而不是按时间窗口一刀切。第二历史以「全量 占位」形态呈现。发送给 Jev 的 history 是整段对话、最旧在前但每条工具结果都被替换成一行短注记格式形如ok, 4213 chars (omitted)见resultNote。也就是说Jev 能看到调用了哪个工具、传了什么参数、结果有多长但看不到那 4213 个字符的正文。这个设计决策在后续社区回放测试中引发了最大的争议下文会详述。第三决策粒度是「单条调用」。对每条非钉住的工具调用Jev 收到两个noul问题src/compact.ts 的questionsForTool call t12 (Bash) should stay in the history: knowing this call was made, with its input, still matters for what the assistant does nextThe full output of tool call t12 (Bash, 4213 chars) should stay in the history verbatim: the assistant still needs its contents and re-running the tool would not do注意第二问的措辞它把「结果是否值得原样保留」与「重新运行工具是否可行」绑定在一起——这是对工程事实的尊重读文件可以重来但写文件、调外部 API、改变环境状态的调用其输出一旦删除就可能无法无损复现。从「压缩已有上下文」到「主动决定看什么」源码里的范式跃迁如果只把 fast-jev-compaction 当成「更好的压缩插件」就低估了它的位置。它是「判断与生成解耦」这条新路线的示范性实现上下文管理不再由生成模型负责有损、慢、贵而由决策模型负责无损、快、便宜。整套流程在源码里清晰可读核心是 src/compact.ts 的compact函数1. 配对与钉选。collectToolCalls按tool_use_id把每次工具调用与它的结果配对首条消息和最新的preserveRecentMessages默认 6条消息被钉住永不参与删除src/state.ts 的isPinned。这是「最近的工作记忆必须完整」的工程直觉。2. 状态分级收缩。完整历史要先塞进maxStateTokens默认 25k预算。fitState按序尝试一系列收缩阶段每一级只在上一级不够时生效src/state.ts工具输入先截到 1000、再 200、再 60 字符inputs1000/200/60长文本按「头 400 尾 150 字符 省略注记」缩写texts abridged最旧的非钉住消息优先旧的非钉住消息折叠为[… N chars omitted …]注记旧工具调用压缩为单行如t12 Read file_pathsrc/a.ts → ok 480ch旧的无调用消息直接剔除连续的工具调用消息合并。整个收缩过程没有 tokenizer——estimateTokens用「单词按每 6 个字母 1 token、数字半个、符号 0.9」的经验公式估算并针对 Jev 上报的用量做了校准。这是一套典型的低成本工程近似。3. 分批并发请求。问题被拆成多批每批的「完整 state 问题」不超过maxRequestTokens默认 30k低于 Jev 的 32k 请求上限。注意完整 state 会随每一批请求重复发送各批并发执行、答案合并。这个设计的代价请求越多重复发送越大在 README 的 Limitations 里被坦率承认。4. 阈值裁决。每条调用按keepThreshold默认 0.5三档处理src/compact.ts 的decideCallkeepResult ≥ 0.5→ 调用与结果都原样保留否则keepCall ≥ 0.5→ 保留调用结果截断到前truncateHeadChars默认 300字符加一行注记否则 → 调用连同结果一起删除。5. 逐字保真重建。applyDecisions重建消息列表被删调用的消息连同结果一起消失被截断的结果保留头部与注记完全未触碰的消息原对象返回——这意味着用户与助手的文本、顺序、逐字内容零改写。测试tests/fast-jev-compaction.test.ts甚至断言了「短结果消息连同其 handle 原样保留」这一行为。6. 双形态部署。仓库既是 npm 库src/入口 src/index.ts一行compactMessages即可接入又是一个 Claude Code function-hook 插件hooks/fast-jev.ts。插件的价值在于把决策嵌进 Agent 的日常节奏turn.complete钩子在上下文水位达到compactAtPercent默认 60%时自动触发压缩session.compact钩子把转录交给 Jev压缩率低于minReductionRatio默认 0.25或 Jev 失败时回退到 Claude Code 内置摘要。失败兜底 阈值护栏是这类「把判断外包给模型」的组件能上生产的关键设计。争议与盲区社区回放测试给出了诚实的反面证据这篇草案最值得参考的地方在于它的第一步落地同时暴露了「逐条判定」路线的真实盲区社区的回放测试给出了相当扎实的反面数据。知名开发者 Theot3.gg看过演示后写了一篇措辞很重的长评标题就叫Compaction isnt a filter压缩不是筛选。他的核心区分是整理任务状态和逐条过滤工具记录并不是一回事。模型做摘要时会利用整段对话重新整理当前目标、已确认事实、失败路径和下一步动作而逐条判定是局部判断可能保住一条「看起来有用」的记录却丢掉它与前后步骤的关系。他进一步指出了实现层面的硬伤为了把整段历史塞进 Jev 的状态上限插件不会把完整工具结果交给 Jev它看到的只是ok, 4213 chars (omitted)这样的占位——失败原因一旦被删Agent 就会忘记哪些方案已经试过进入「反复执行同一种失败操作」的 stupid loops。随后 GitHub issue #26 的真实会话回放几乎精确命中了他的担心测试者用 2 个项目的 16 段 Claude Code 会话在上下文达到 12 万 token 时触发压缩让 Jev 评估 256 个非固定工具调用。结果——256 个工具结果没有一个保留分数达到 0.5240 个结果被删除或截断字符数减少 87.7%。而一个永远回答「都不要保留」的假评分器字符数减少 88.5%两者几乎一样。另一组更激进的对比测试显示Jev 删掉了 98.7% 的上下文但在复杂会话里丢了 7 个关键测试与边界事实中的 6 个。这些数据说明三件事。其一当 Jev 看不见结果正文时它的「保留概率」会系统性偏低——占位信息ok, 4213 chars (omitted)里藏着的那 4213 个字符恰恰可能是最关键的报错堆栈。其二压缩率不是正确性的代理指标一个「全删」的假评分器在压缩率上几乎不输。其三逐条判定存在递减回报工具结果越删越少后续能释放的空间越小长会话最终仍需要真正的摘要或外部记忆兜底。此外还有一层成本视角提示词缓存依赖历史前缀不变。删掉历史中间的内容后面的消息可能都要重新写入缓存——在部分用户的账单里 cache write 曾超过总模型开销的 60%「用更贵的缓存写入换更小的上下文」未必划算。这也是为什么插件坚持「留下的内容保持原样、位置不变」——前缀稳定性本身就是保真的一部分。从第一步到下一步Coding Agent 的产品形态正在被改写把 fast-jev-compaction 放回整个 Jev 生态里看它的意义会清晰很多。社区两周内长出的 28 个项目里有一条高度一致的架构规律写和想归大模型判和选归 Jev执行权留在确定性代码里——网页操作 Agent 只让 Jev 选「下一步做什么、点哪个元素」交易系统只让 Jev 判断市场状态而绝不碰下单键代码审查工具让 Jev 打分、Agent 和人改代码。fast-jev-compaction 是这条规律在「上下文管理」这个最痛的工程环节上的示范。由此可以推导草案对 Coding Agent 产品形态的几点连锁影响上下文从「被动衰减」变成「主动选择」。传统 Agent 的上下文是「灌满 → 摘要 → 继续灌」的衰减循环摘要质量决定 Agent 的长期记忆。而「每轮重新决定该看什么」意味着上下文变成按当前目标动态组织的证据集每一轮根据任务goal判定哪些历史记录仍然相关不相关的删掉相关的逐字保留。保留的内容不再有「摘要改写」这一层失真Agent 看到的就是它当初看到过的原文。判断与生成的带宽分离。Jev 每问 70–500 毫秒、输出免费、可并发而生成式压缩要跑一次完整 LLM 推理且输出 token 收费。当「该保留什么」这类高频、窄域、可回退的判断从生成模型里剥离出来Agent 的每次迭代成本曲线会被显著压平——这正是草案想撬动的杠杆。「每轮」需要更细的编排。fast-jev-compaction 的turn.complete钩子已经演示了「每轮检查水位、触发决策」的节奏但真正面向生产还需要社区提出的三层保护让 Jev 看见工具结果的关键片段而非纯占位默认固定失败、编辑和不可重跑的输出用任务成功率与缓存成本评估效果而不是只看压缩率。作者在 issue 讨论中也用「厂商自己的上下文管理同样会清理工具结果Jev 想把这件事做得更有选择性」回应了「它只是在删 tool results」的批评——方向没错选择性还不够。回到开头那份草案。「每轮重新决定模型该看什么」在 fast-jev-compaction 里的实现只是第一步它证明了决策模型可以接管上下文管理中最危险的部分——决定什么可以被安全遗忘——并且做到留下的内容逐字保真。而 issue #26 的回放数据同时证明把「结果正文」从决策者的视野里拿掉是当前最大的盲区压缩率也不该是唯一的目标函数。对于正在设计下一代 Coding Agent 的工程团队这份草案给出的不是答案而是一组更准确的提问你的 Agent 每轮该看什么谁来做这个决定它看到的是全量证据还是占位符以及——你用什么指标判断它删对了【免费下载链接】fast-jev-compactionClaude Code plugin that replaces the compaction summary with Jev decisions: every tool call and result is scored in one fast request, stale ones are dropped or truncated, everything kept stays verbatim.项目地址: https://gitcode.com/gh_mirrors/fa/fast-jev-compaction创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考