Hermes 靠记忆系统、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-compaction长会话 Agent 最贵的不是 API 账单而是记忆错位模型忘了自己改过哪个文件、丢了一段报错堆栈、把src/generated的禁改约束在摘要里优化掉。2026 年围绕上下文管理出现了两条针锋相对的技术路线——以 Nous Research Hermes Agent 为代表的记忆/检索体系先记住再按需召回和以 TypeSafe AI 的 Jev 决策模型为底座、由 fast-jev-compaction 工程化的逐条决策压缩不生成一个字只做选择题按需删除。前者试图把上下文变成外挂硬盘后者试图把压缩变成法官判决。本文将以 fast-jev-compaction 仓库源码为第一手证据对比两条路线的骨架、工程成本与适用场景并讨论它们是否会殊途同归。一、两条路线的骨架把上下文记住还是裁掉记忆/检索体系上下文是资产值得长期持有Hermes Agent 走的是记忆系统路线会话历史被结构化地存入长期记忆通过向量检索与分层归档按需召回配合上下文压缩与 MCP 工具集成让 Agent 在长任务中不丢事。这套体系的核心假设是——过去的对话是有价值的资产值得被索引、被持久化、被重新读取。它的代价也很明确需要维护记忆的写入与召回策略需要向量库或数据库做状态持久化本质上是用存储 检索换上下文窗口。决策压缩上下文是消耗品该删就删fast-jev-compaction 走了完全相反的路。项目 README 的第一句话就划清了边界This library never rewrites anything. It only deletes tool calls and tool results Jev says are no longer needed.README.md——它不重写任何内容只删除 Jev 判定为不再需要的工具调用与工具结果用户和助手的文本逐字逐句、原序保留。这套机制的核心假设是——大多数历史工具调用是消耗品Read过 30 个文件、跑过 20 次测试真正需要留给模型的只有最近几步。与其把历史压缩成一段漂亮话不如逐条问一个不写字的模型这条调用还重要吗这个结果还必须原样留着吗源码里的决策流水线打开 src/compact.tscompact()的主流程清晰可见配对 → 钉选 → 拟合状态 → 分批提问 → 概率决策 → 重建消息。配对collectToolCallssrc/state.ts按tool_use_id把每条tool_use与其tool_result配对没有结果的调用根本不是候选——还没有可删的东西。钉选isPinned()规定index 0 || index total - preserveRecentMessages——首条消息和最近preserveRecentMessages默认 6条消息永不触碰。逐条提问对每个非钉选调用构造两个noul问题src/compact.ts 的questionsForcall_xx问知道这条调用被做出、且其输入仍然重要吗result_xx问完整输出是否仍需逐字保留重跑工具不可行。概率裁决decideCall把两个概率压到三个动作上——keepResult ≥ keepThreshold则整条保留否则keepCall ≥ keepThreshold则保留调用、把结果截断否则连调用带结果一起删。无损重建applyDecisions重建消息列表内容全失的消息整体移除未触碰的消息原对象返回任何结果都不会脱离其调用而存在。这套流水线最反直觉的地方在于给 Jev 看的是省略版历史删的却是原版历史。决策模型看到的状态fitState产物里工具结果一律被替换成一行注释ok, 4213 chars (omitted)而真正从会话中删除的是未经任何改写、逐字逐句的原始消息。二、工程对比实现复杂度、模型依赖与成本模型依赖生成式 LLM vs 不生成文本的哑巴模型记忆系统路线的压缩环节通常依赖通用 LLM 做摘要而摘要恰恰是上下文管理里最不可控的一环——它会把变量名写丢、把逻辑平滑、把约束条件吞掉且每次压缩都是新的幻觉风险源。社区对 Jev 的讨论几乎都围绕这一点展开它是System One Model不生成文本只输出封闭空间内的结构化判断noul概率、choice、score官方口径是速度快 193 倍、成本低 444 倍、输出 Token 免费。在 src/types.ts 里可以直观看到这种哑巴的代价Jev 的答案类型只有三种——NoulAnswer一个概率、ChoiceAnswer一个选择 置信度、ScoreAnswer一个分数仅此而已。从工程视角看这带来一个显著红利响应可校验。src/request.ts 的parseJevResponse对响应做了严格的结构化校验——非 2xx 抛错、非法 JSON 抛错、缺answers抛错、noul缺失或非有限数抛错。生成式摘要的输出根本无法这样硬校验而决策模型的输出天然是机器可消费的。实现复杂度规则层把智能降级为工程记忆系统需要设计记忆 schema、写入时机、召回排序、过期策略复杂度分布在系统各处。fast-jev-compaction 则把复杂度收敛进了三个可调试的规则层其一无 tokenizer 的 token 估算。src/state.ts 的estimateTokens用正则把文本切成词/数字/符号按单词每 6 字母 1 token、数字半 token、符号 0.9计价并明确校准到比 Jev 实际报告值高出 2–18%——注释里写着纯字符比会低估 JSON 密集状态最多 40%。这避免了引入 tokenizer 依赖换来的是可预期的预算余量。其二分级状态拟合。同一个文件里的fitState定义了七级瘦身阶梯逐级施加、命中最先返回工具输入截断至 1000 → 200 → 60 字符 → 长文本头尾摘录[… N chars omitted …]→ 旧消息折叠 → 旧调用压成单行t12 Read file_pathsrc/a.ts → ok 480ch→ 无调用的旧消息剔除 → 连续调用行合并全部用尽仍超预算则直接抛错。每一级都返回stage标签inputs200、texts abridged、old calls compacted…压缩究竟发生在哪一步一目了然。其三分批并发请求。batchCalls用maxRequestTokens默认 30k压在 Jev 32k 请求上限之下减去状态与 20 token 请求开销算出预算把问题拆成多批每批都重发同一份完整状态Promise.all并发执行后合并答案src/compact.ts。成本账毫秒级、零生成、可回退决策路线的成本结构几乎全是判断成本每批请求只输出几十个概率数字没有生成文本的 token 费用也没有二次摘要的级联开销。社区实测口径如Jev 不生成一个字却干掉了 Agent 90% 的上下文、91.5% 压缩率、压缩耗时 5–20ms虽来自不同作者、数字口径不一但方向一致决策压缩的成本与延迟都低一个数量级。fast-jev-compaction 还做了一层工程保险压缩收益不足则回退。hooks/fast-jev.ts 中minReductionRatio默认 0.25——若 Jev 裁掉的字符不足 25%插件 toast 提示fallback to built-in summary把session.compact事件交给 Claude Code 内置摘要Jev 请求失败、响应畸形、缺 API key、历史装不进状态预算同样触发回退。决策路线因此不是孤注一掷而是能删则删、删不动就退。三、场景对比长会话编程、RAG、多工具编排各适合谁长会话编程决策路线的主场fast-jev-compaction 从设计上就是为 Coding Agent 的长会话定制的README 里那句a file path, exact error, constraint, or command can disappear even when it matters later直指编程场景的死穴。几个源码细节都为此服务钉选保护首条消息与最近 6 条永远不删用户的初始约束Never edit src/generated和正在进行的操作链不会误伤只删工具调用不碰文本README 的 Limitations 明确写着Only tool calls and results are candidates; text messages are never removed or shortened in the output——人类语言的语义完整性由规则保证模型判断只作用于工具层截断留痕结果被删时保留前 300 字符并追加[fast-jev-compaction truncated N chars…; re-run the tool if needed]src/compact.ts报错堆栈的头部、CLI 参数的签名都能留在视线里重跑兜底决策指令中明说whatever is not kept is deleted permanently, but the assistant can always re-run a tool or re-read a file——编程 Agent 的工具具有可重入性删错了代价有限这正是决策路线敢删的底气。RAG记忆/检索体系的主场决策路线在 RAG 场景几乎无用武之地。RAG 的核心矛盾是语料在窗口之外需要的是把知识索引、持久化、按查询召回——这是 Hermes 式记忆系统的能力圈。决策压缩解决的是窗口之内的垃圾而 RAG 解决的是窗口之外的宝藏两者解决的问题根本不同。想用删调用的思路管理知识库等于用剪刀修水管。多工具编排中间地带多工具编排里决策路线的优势是证据链完整——社区情报中反复出现的 K/Q/VKey/Query/Value三元组描述在源码里的对应物是STATE_CONTEXT与goalsrc/state.tsgoal默认取最近三条用户指令context明确告诉 Jev这是一段编码助手对话正在被压缩工具输出已替换为简短注释。也就是说Jev 是在知道任务目标 看到全量历史骨架的前提下逐条裁决的这比无目标地批量摘要要精准得多。但代价也在 README 的 Limitations 里写着完整状态随每个请求重复发送历史接近状态上限时一个问题批次就是一次完整重传——调用密度极高时请求数与 token 消耗会同步上升。四、融合猜想记忆 决策会不会是终局两条路线各自承认的边界值得注意的细节是fast-jev-compaction 自己并不声称无损——README 的 Limitations 写得很克制Calibration is at the request level; a probability is not a proof that a result is safe to delete.概率不是删除安全的证明。这与社区里 Redis 之父对 Jev 狂热的质疑绝大多数开发者其实不需要它遥相呼应决策模型擅长高频、窄域、可回退的判断但这条历史值不值得留在语义深处仍是一个生成问题只是被工程手段降格成了判断问题。每轮重新决定模型该看什么社区情报中有一条值得玩味的线索Jev 团队公开的 Coding Agent 设计草案提出每轮重新决定模型该看什么——这本质上已经不是压缩历史而是动态选择视野。把这条思路外推决策模型完全可以嵌入记忆系统的召回环节不是由规则或向量相似度决定召回什么而是由决策模型对当前任务 × 候选记忆逐条裁决。届时记忆系统负责存得住决策模型负责看得准压缩从一次性的会话整理变成每轮推理前的实时视野管理。终局可能是分工而非取代回到标题的问题两条路线谁走得更远从工程事实看它们不是同一场比赛。决策路线把上下文管理从昂贵的生成变成廉价的判断在长会话编程这种高频率、可重入、证据敏感的场景里成本和确定性优势是结构性的记忆/检索路线则在知识持久化、跨会话复用场景里拥有不可替代的位置。真正的终局更可能是一种分工记忆系统决定什么值得长期拥有决策模型决定此刻该看什么——一个管存量一个管流量。fast-jev-compaction 已经把决策路线的工程范式钉选、分级拟合、概率裁决、可回退打磨成了可复用的开源积木src/index.ts 导出了compactMessages、buildJevRequest、fitState、decideCall等全套构件下一步被接进记忆检索链路几乎是顺理成章的事。上下文管理的下半场赢家不会是只记住或只删除的一方而是能把记忆的广度和决策的锋利组合起来的一方。【免费下载链接】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），仅供参考