HT1072公开知识系统
返回列表总览 ↗
决决策档案2026-09-21 · 调研记录
2026-09-21 · DECISION TRACE

fast-jev-compaction 引用评估：能否用在 Hermes 自己身上

保留方案、指标、验证、复盘和治理判断，让结论能够追溯。

2026-09-21记录日期
调研记录记录类型
19章节数

fast-jev-compaction 引用评估：能否用在 Hermes 自己身上

调研日期：2026-09-21 | 框架：external-project-absorption-eval v1.0 引用目标：把该能力用在 Hermes 自身的上下文压缩上 证据：仓库源码全读 + 本地编译/测试 + 真实 Jev 通道端到端实测（Vercel AI Gateway）

结论

fast-jev-compaction 可以引用，且已完成真实端到端验证。它是一套无损上下文压缩算法：只按 Jev 的判定删除或截断过期的工具调用与工具结果，用户与助手的文本原样保留、从不重写。它本身是 MIT、零运行时依赖的 TypeScript 库，真正的硬依赖是 Jev；而 Hermes 昨天已经接通 Jev，所以唯一缺口是把这套算法从 Claude Code 插件形态移植成 Hermes 自己的 Python 压缩层。建议只吸算法、不引整包，作为 LCM 压缩引擎的一个可选无损剪枝 pass 落地，先影子后转正。

1. 项目定位

维度 事实
仓库 tamaratran/fast-jev-compaction
形态 npm 库（src/）+ Claude Code function-hook 插件（hooks/）
语言/规模 TypeScript，源码约 1,900 行
License MIT（可自由使用、修改、商用、再分发）
运行时依赖 0（仅 devDeps：typescript / vitest / tsx）
仓库元数据 创建 2026-09-17（约 4 天）、5,560★、301 fork、59 open issues
npm 发布状态 未发布（registry 404），README 里的 npm install 暂时装不到
硬依赖 TypeSafe Jev（System One 模型，经 Vercel AI Gateway 或官方 API）

它本质是什么：不是 agent 框架、不是记忆系统，而是一层上下文压缩策略——把「压缩=让 LLM 写摘要」换成「压缩=只删不再需要的工具调用/结果，其余原样」。属于控制层/上下文治理层的一个能力单元。

2. 与现有体系的关系

当前 Hermes 上下文压缩栈
  context.engine = lcm（默认）
    └─ LCMContextEngine：把旧对话压成摘要（有损）→ 需 lcm_expand 回捞
    └─ ContextCompressor（备用引擎）：threshold 0.72 / target_ratio 0.2

fast-jev-compaction 补的是
    └─ 同层的「无损剪枝」能力：不写摘要，只删/截断过期 tool call/result
  • 关系：补强，非替代。它不改写文本、不做推理，无法取代 LCM 的摘要角色，只能作为一个并行/可选的剪枝 pass。
  • 最像谁：最接近 Hermes 已有的 compression 机制，但换成了「结构化决策驱动、verbatim 保留」的路线。
  • 是否影响默认路由：否（先不动默认）。

3. 四层审计结论

3.1 宣称层

  • README 的机制描述与源码完全一致（逐条核对：配对、钉住、分级裁剪、两个 noul 问题、阈值决策、重建）。
  • 未夸大：明确写了限制（只压 tool call/result、token 是估算、概率不等于可删证明、state 每批重发）。

3.2 实现层

  • 可拆性极好：compact(messages, asker, options) 中 asker 只有一个 ask(state, questions) 方法，buildJevRequest / parseJevResponse 可单独用 → 可以不接 TypeSafe，换任意判定后端。
  • 零依赖：无外部运行时依赖，纯逻辑。
  • 本地实测：npm install 秒装；tsc --noEmit 通过；vitest run 29/29 全过。

3.3 运行层（本机真实接入）

  • 库默认打 api.typesafe.ai（需 waitlist key）；但我们不需要它——Hermes 已有 Vercel AI Gateway 的 Jev。
  • 端到端实测：自写一个 asker 把库的 noul 问题映射到网关的 boolean 类型，跑 compact()：
  • 结果：压缩率 59.6%，16 条消息 → 8 条；6 个候选调用中 4 个被删、2 个钉住保留；1 次请求、812ms、成本约 $0.00002。
  • 判定示例：过期的 Read/Bash/Edit 调用 keepCall 0.29–0.37、keepResult 0.15–0.19（低于 0.5 → 删除）；最新两条 Read 因钉住保留。
  • 说明：算法 + 我们的 Jev 通道可完整跑通，不是纸面可行。

3.4 检索与治理层

  • 不涉及 recall/检索，不侵入记忆栈。
  • 需治理的是：剪枝口径可追溯（每次 keep/drop 的概率、阈值、state 规模）——与现有 decision-trace / 审计体系同构，可直接落 run log。

4. 三个专项验证

4.1 静态面 vs 运行面一致性 ✅

源码与 README 逐条一致；本地编译、测试、真实调用三者行为一致。

4.2 精确回捞能力 ✅（关键）

  • 它不产生摘要，保留的内容是原对象（未改动消息原样返回）→ 不存在「摘要丢细节」问题。
  • 对 Hermes 现状是直接补强：LCM 摘要会丢原文细节、需 lcm_expand 回捞；这套方案从设计上就不丢被保留内容。

4.3 降级与回退路径 ✅

  • Jev 不可用 → 库直接 throw，调用方回退；Hermes 已有的「Jev 不可用 → LLM 兜底」降级矩阵可直接复用。
  • 作为可选 pass，摘掉即回到现状，零主链侵入。

5. 与本机体系的真实映射

硬依赖已满足： - Hermes 已接通 Jev：~/.hermes/scripts/jev_client.py（Vercel AI Gateway typesafe-ai/jev，key 在 ~/.hermes/.env 的 AI_GATEWAY_API_KEY）。 - 库的 noul（0–1 概率）↔ 网关 boolean.probability 一一对应，映射已实测。

唯一缺口：库是 TS + Claude-Code 插件形态；Hermes 是 Python + 自带 context engine。需要一次算法移植，而不是装依赖。

落地位置建议：Hermes 的上下文压缩层（context.engine: lcm 同层），作为一个可选的 verbatim 剪枝 pass / 新模式，而非替换 LCM。

6. 主要收益

  1. 不丢关键信息：文件路径、报错原文、约束、命令原样保留——正好补 LCM 摘要的有损短板。
  2. 决策可编程、极便宜：每批问题一次 Jev 调用，实测 ~800ms、成本 $0.00002 量级。
  3. 与现有 Jev 资产复用：不用申 TypeSafe key、不装 SDK，直接用已打通的网关。
  4. 可回退：可选 pass，出问题摘掉即恢复。

7. 主要风险

风险 严重度 说明
state 上限 32k 中 长会话需分级裁剪 state（库已内置分级策略，但要验证够用）
成本随历史放大 中 完整 state 每批重发，历史接近上限时请求数上升
token 为估算 低-中 启发式，非 tokenizer，需按实测校准
只压 tool call/result 低 文本永不删/缩短（设计如此），纯聊天场景收益低
缓存/交替不变量 中 Hermes 视「对话内 prompt 缓存」为神圣；压缩是唯一例外，但改造须不破坏角色交替与 system prompt 字节稳定
仓库过新 低-中 4 天、59 open issues、大量 AI 机器人提交；当生产依赖需谨慎，故建议「吸算法」而非「引整包」

8. 建议吸收清单

P0 — 吸算法骨架（不引整包） - 用 Python 移植核心：tool call/result 配对、钉住规则、分级 state 裁剪、两个判定问题、阈值决策、重建。 - 判定后端复用 jev_client.py（Vercel 网关，boolean）。

P1 — 接成 LCM 的可选无损剪枝 pass - 挂在一个可选模式下，先影子（只记录会剪什么、不真剪），再转正。 - 落 run log：每次 keep/drop 概率、阈值、state 规模、压缩率。

P2 — 生态跟踪 - 盯 npm 是否正式发布、仓库 issue 收敛情况；若上游稳定再考虑对齐。

不吸：不装 npm 依赖 / 不引 TS 运行时；不引 Claude Code function-hook 壳；不替换 LCM 默认；不动 agent 主循环与 system prompt。

9. 最终判断

Partial Absorb（L3 局部能力吸收）—— 吸算法，不引整包；落点：Hermes 上下文压缩层

理由链： 1. 能力真实、可拆、已端到端验证（59.6% 压缩 / 4 删 2 留 / 1 请求 / 812ms）。 2. 硬依赖（Jev）Hermes 已满足，唯一成本是一次 Python 移植。 3. 语言与宿主不匹配（TS↔Python、Claude-Code↔Hermes），引整包得不偿失。 4. 与 LCM 是互补（无损 vs 有损），适合做可选 pass 而非替换。 5. 仓库过新，移植算法比绑依赖更稳。

为什么不是 Sidecar：它不是常驻服务，是一段可内联的算法，没有独立进程形态。 为什么不是 Core Merge：不替换 LCM、不进主循环，只做可选增强层。

10. 下一步动作（最多 3 条）

  1. 写 Python 移植版（~/.hermes/scripts/jev_verbatim_compact.py），复用 jev_client.py，先跑离线样本对齐 TS 版行为。
  2. 影子验证：在真实长会话上只记录「会剪什么」，对比 LCM 摘要路径，确认不误删。
  3. 可选接入：作为 LCM 的一个模式开关接上，保留一键回退。

附：证据来源

  • 仓库：https://github.com/tamaratran/fast-jev-compaction（MIT，0 运行时依赖）
  • 源码全读：src/compact.ts、src/state.ts、src/types.ts、src/request.ts、src/client.ts、hooks/fast-jev.ts
  • 本地：npm install / tsc --noEmit / vitest run（29/29）
  • 真实接入：自写 asker → Vercel AI Gateway typesafe-ai/jev，compact() 实测压缩率 59.6%
  • 本机 Jev 资产：~/.hermes/scripts/jev_client.py、AI_GATEWAY_API_KEY（~/.hermes/.env）
  • 既有评估：~/llm-wikis/knowledge-ops/queries/jev-typesafe-absorption-eval-2026-09-20.md