Jev 无损剪枝：引入收益 vs 风险评估（按「信息稳定传递」优先级）
2026-09-21｜评估人：小墨｜优先级锚点：信息稳定传递，不压缩掉重要内容 证据：6 段真实会话 × 2 模式对照跑批 + 628 条自动抽检 + 259 条被删条目定量画像
结论
坏处更大，不建议引入运行态。不是因为它做得不好，而是因为它的核心前提与「信息稳定传递」在架构上冲突：这套能力的本质是不可逆删除，而它的安全论证建立在「助手可以重跑工具」上——可重跑不等于可恢复。
一、收益侧（真实，但不是必需）
| 项 | 实测 |
|---|---|
| 成本 | 单次 $0.00014–$0.00695 |
| 延迟 | 0.6s–5.2s（records 形态；旧形态 14–35s） |
| 压缩率 | 48.1%–70.8%（工具密集会话）；文本密集会话仅 4.9% |
| 区分度 | score + records 形态有排序（0.09–1.03）；boolean 形态无（0.02–0.37 全删） |
二、风险侧（与你的优先级直接冲突）
1. 安全前提是「可重跑」，而可重跑 ≠ 可恢复 —— 这是根本问题
上游 README 自己写明：概率不是「可安全删除」的证明，理由是「助手总可以重跑工具」。
但下面这些内容重跑拿不回等价物：
- 报错原文：错误往往不可复现（状态已变），而报错恰恰是后文最常被精确引用的东西；
- 联网检索/外部 API 结果：重跑得到的是当下的新结果，不是当时的快照；
- 时间相关输出：日志、心跳、抓取时点；
- 有副作用的命令：重跑不是免费动作，可能改状态；
- 已变更/已删除的目标：文件被改写后重读拿到的是新版本。
对「稳定传递信息」这个目标，这一类正是最不该丢的。
2. 删了就回捞不了（与你现在的 LCM 是相反的设计）
| LCM（你当前在用） | 本方案 | |
|---|---|---|
| 上下文里的表示 | 摘要视图 | 原文（未删部分） |
| 原始内容 | 持久在库里，lcm_expand 可逐字回捞 |
真删除，无回捞路径 |
| 失败后果 | 需要多一步回捞 | 信息永久消失 |
drop_result 只留 300 字头 + 一行说明；drop_call 连调用一起消失。 这是净负的可靠性交换：用「省 token」换「不可逆的信息损失」。
3. 判定正确性未被证明，且默认倾向是「删」
- boolean 模式实测 6/6 会话保留率 0.0%：模型先验强烈偏向「不需要」；
- score 模式只所以没全删，是因为我强制加了 quantile 旋钮（前 25% 保留 + 再 25% 截断）， 即那个 50% 保留率是我们设的，不是 Jev 判出来的；
- 259 条被删/截断条目里，96% 触发了我过宽的安全怀疑标记；
- 16 条含「约束性表述」且未在保留内容中出现 —— 其中确有代码注释正则误报， 但没有人逐条确认过这 16 条。排位正确性（保留位选得对不对）至今未验证。
4. 本次样本对你的真实场景是失真的
这 6 段会话是 Hermes 本地开发/编码会话，被删内容 99% 来自本地可重取工具：
| 工具 | 被删条目 |
|---|---|
| terminal | 146 |
| search_files | 35 |
| read_file | 25 |
| todo / process | 20 / 18 |
| 非幂等（检索/外部） | 仅 2 |
| 错误输出 | 0 |
也就是：这次的「看起来安全」，恰恰是因为样本里没有你真正在意的场景（晨报、调研、飞书、跨系统状态——那些是联网/API 密集的）。 在那些会话里，「可重跑」的保障会大幅减弱，而信息损失代价更高。
5. 其他运行态代价
- 单次可能因网关 429/503 退化（实测耗时被推到 74s）；
- 会话内无回滚：删掉的内容当轮就无法恢复；
- 会话内 prompt 缓存会因内容变更失效（Hermes 视其为不变量，压缩是唯一豁免）。
三、两个方案对比（按你的优先级排序）
| 维度 | 本方案（删除式剪枝） | 现有 LCM | 「外置不删」方向 |
|---|---|---|---|
| 是否丢信息 | 会丢，且不可恢复 | 视图有损，原文可回捞 | 不丢，指针可回捞 |
| 是否符合你的优先级 | ❌ | ✅ | ✅ |
| 省上下文 | 强 | 中 | 中 |
| 依赖外部服务 | 是（Jev 网关） | 否 | 否 |
| 回滚 | 会话内不可逆 | 简单 | 简单 |
四、建议
- 停止 P3，不接入运行态。 两个脚本都未被生产调用，回滚零成本（删除即可）。
- 保持 LCM 不动。 它已经提供了「摘要视图 + 原文可回捞」，比删除式剪枝更贴合你的优先级。
- 本次研究产出（算法移植 + 实测数据 + 本反面结论）留作 reference，不浪费。
- 若将来仍想降低上下文压力，走与优先级一致的方向： 先外置、再留指针，而不是删除 —— 把旧工具结果搬进 LCM store / 落盘， 上下文只留一句指针 + 可回捞入口。这样既省上下文，又不会「压缩掉重要内容」。
- 唯一可能考虑删除的形态（若将来非要）： 纯确定性规则 + 删前先外置 —— 只处理「同一 target 的重复读取/重复执行」这类可自证幂等的旧结果， Jev 最多做兜底排序，不允许它单独决定删除。
五、诚实边界
- 本评估基于 6 段会话、单批数据；阈值/比例未按领域校准。
- 「保留位正确性」（V6 人工裁定）未做 —— 但即便做了且结果良好， 第 1、2 条（不可恢复 + 可重跑≠可恢复）仍然成立，故结论不受其影响。
- 本评估没有否定上游实现质量：代码干净、MIT、算法可拆，问题在语义取向，不在工程。