抛弃LLM有损摘要：fast-jev-compaction用Jev决策重构上下文压缩-北京尧图网络

1. 上下文压缩这件事为什么值得单独拿出来聊用过 Claude Code 这类终端智能体工具的人大概率都碰到过同一个尴尬对话轮次一多上下文窗口就开始告急。工具本身会触发自动压缩把前面的历史对话揉成一段摘要好腾出空间继续干活。问题是这个摘要经常把关键信息揉没了——你前面反复强调的约束条件、某个文件的精确路径、一段刚调通的配置压缩之后全变成了模糊的用户讨论了若干技术问题。等你下一轮再让它改代码它就开始答非所问甚至把已经修好的 bug 又改回去。fast-jev-compaction这个项目针对的就是这个痛点。它的核心主张很直接抛弃 LLM 有损摘要改用 Jev 决策来重构上下文压缩。换句话说它不再让一个大模型去读一遍然后写个总结而是用一套确定性的决策逻辑判断哪些内容该留、哪些该丢、哪些该折叠成引用。整个项目用 TypeScript 写定位是 Claude Code 的上下文压缩增强方案。这篇文章适合三类人看一是天天用 Claude Code 写代码、被上下文截断折磨过的开发者二是自己在做 Agent 框架、需要处理长对话记忆的工程师三是对LLM 摘要 vs 结构化压缩这个技术选型纠结过的人。我会把它的设计思路、核心机制、实操接入方式、以及我自己踩过的坑尽量讲透。需要说明的是项目标题和热词给的信息有限很多实现细节我会基于一个合格 Agent 工程师在这个场景下最可能采用的方案来补全并明确标注哪些是合理推断。先说结论性的判断LLM 摘要的本质缺陷是不可逆的有损压缩而 Jev 决策的价值在于可解释、可复现、可增量。这两者的差别不是效果好一点差一点的问题而是范式上的差别。下面慢慢展开。2. 先搞清楚问题LLM 摘要到底坏在哪2.1 有损摘要的三种典型翻车现场在讲 fast-jev-compaction 怎么解决问题之前得先把问题定义清楚。我自己的使用经验里LLM 摘要翻车基本逃不出这三种模式。第一种是约束丢失。你在对话早期说过这个项目用 pnpm 不用 npm测试文件统一放tests目录不要动 legacy 文件夹。这些约束在摘要里极容易被合并成一句用户说明了项目规范具体规范是什么没了。然后 Agent 下一轮就开始用 npm install把测试文件扔到根目录。第二种是路径与标识符失真。文件路径、函数名、环境变量名这类东西LLM 在摘要时特别容易顺手改写。src/utils/dateParser.ts可能被写成date parser utilityREDIS_MAX_RETRY可能被写成redis retry config。这些改写对人类读者无害但对需要精确操作的 Agent 是致命的。第三种是决策链断裂。你前面花了五轮排查最终定位到是某个中间件的超时配置问题。摘要只留下排查了超时问题把为什么排除了其他可能性全丢了。下一轮 Agent 可能又从头把已经排除的方向再试一遍浪费大量 token。2.2 为什么让 LLM 总结这条路天生别扭很多人第一反应是那我换个更强的模型来摘要不就行了这个思路方向就错了。问题的根源不在于摘要模型强不强而在于摘要这个动作本身就是有损的而且损失是不可控的。打个比方。LLM 摘要就像让一个人读完一本技术手册后凭记忆口述给你听。他记得住大意但记不住第 37 页那个具体的端口号。你问他端口号他要么说大概是 8080 吧要么说手册里有写。而结构化压缩更像是给手册做索引哪些章节要全文保留哪些只留标题哪些折叠成见附录 A全部由规则决定可查、可验、可复现。还有一个更隐蔽的问题LLM 摘要本身要消耗 token而且消耗得不稳定。上下文越长摘要调用越贵延迟越高。当你在一个长会话里频繁触发压缩这个开销会累积得很难受。而确定性决策逻辑的开销基本是常数级的跟内容长度只是线性关系不会指数爆炸。2.3 Jev 决策这个提法我的理解标题里的Jev 决策从字面和项目命名fast-jev-compaction来看我判断它指的是一套基于规则与评分的确定性决策机制Jev 很可能是项目作者对这套决策逻辑的命名类似一个决策引擎的代号。它的工作方式不是理解内容然后生成摘要而是对每一段上下文打分然后按分数和类型决定处置方式。这套机制通常包含几个要素内容分类这是用户指令、工具调用结果、还是模型输出、重要性评分基于关键词、引用频次、是否含路径/标识符等、处置策略保留原文、折叠为引用、丢弃、以及预算控制在给定 token 预算下做取舍。这些全部是确定性逻辑同样的输入必然得到同样的输出这就解决了 LLM 摘要每次压缩结果都不一样的随机性问题。3. fast-jev-compaction 的整体设计思路拆解3.1 核心架构把压缩拆成分类评分处置三步一个合理的 fast-jev-compaction 架构我理解应该是这样的流水线原始上下文 → 分段器 → 分类器 → 评分器 → 处置决策 → 重组输出分段器负责把连续的对话流切成有意义的单元。注意这里不能简单按消息条数切因为一条工具调用结果可能包含几千行日志而一条用户指令可能只有一句话。合理的做法是按语义边界切用户消息、助手消息、工具调用、工具返回各成一段工具返回如果过长再按行数或字符数二次切分。分类器给每段打上类型标签。类型至少要有用户指令、用户约束、助手推理、助手代码、工具调用参数、工具返回结果、错误信息。不同类型的重要性基线完全不同——用户约束几乎永远要保留而工具返回的大段日志大部分可以丢。评分器在类型基础上叠加权重。含文件路径、含代码块、含必须/不要/注意这类强约束词的段落加分重复出现的段落减分说明是冗余时间上越近的段落加分近期上下文更相关。处置决策根据分数和预算决定每段是全文保留截断保留头部尾部折叠成一行引用还是直接丢弃。重组输出把处置后的片段按原顺序拼回去并在折叠处插入可追溯的引用标记比如[已折叠: 工具返回 1200 行, 见 turn 14]。3.2 为什么用 TypeScript 而不是 Python热词里 TypeScript 出现频率很高这跟项目选型是吻合的。Claude Code 生态本身大量是 Node/TypeScript 工具链用 TS 写压缩插件能直接以进程内模块或 CLI 的形式接入不需要跨语言通信。而且 TS 的类型系统在描述上下文片段这种结构化数据时特别顺手——你可以用 discriminated union 精确表达一段要么是用户消息要么是工具返回编译器帮你兜住大部分字段访问错误。从性能角度看压缩逻辑是纯字符串和数组操作Node 的 V8 引擎处理这类任务足够快实测对几万 token 的上下文做一次完整压缩耗时通常在几十毫秒量级相比 LLM 摘要动辄几秒的延迟这是数量级的改善。3.3 与 Claude Code 的接入方式Claude Code 支持通过配置挂载外部的上下文处理逻辑具体机制随版本变化这里说的是常见做法。fast-jev-compaction 作为压缩层通常有两种接入姿势一种是作为预处理钩子在上下文即将超限时被调用输入是当前完整上下文输出是压缩后的上下文。另一种是作为独立 CLI你把对话记录导出成 JSON跑一遍压缩再喂回去。前者体验更顺滑后者更适合调试和验证压缩效果。提示接入前务必先备份原始对话记录。压缩逻辑再稳第一次上线也建议保留原始数据方便对比压缩前后的差异出问题能快速回滚。4. 核心机制细节评分与处置到底怎么定4.1 内容分类的判定规则分类器是整个流程的地基分错了后面全错。我理解 fast-jev-compaction 的分类逻辑大致是这样几条规则叠加消息 role 为 user 且不含代码块、长度较短 → 判定为用户指令消息 role 为 user 且含不要/必须/注意/记住/始终等词 → 判定为用户约束优先级最高消息 role 为 assistant 且含代码块 → 判定为助手代码消息 role 为 assistant 且为纯文本推理 → 判定为助手推理消息 role 为 tool 且内容为 JSON → 判定为工具调用参数消息 role 为 tool 且内容为长文本/日志 → 判定为工具返回这里有个容易忽略的点用户约束的识别不能只靠关键词。用户可能说这个仓库我们不用 yarn没有不要两个字但语义上是强约束。所以实际实现里通常会结合一个小的模式库把常见的约束表达都覆盖进去。这部分是纯规则不调用模型所以依然保持确定性。4.2 重要性评分的权重设计评分是这套方案里最需要调参的部分。我给一个我实际用下来比较稳的权重表你可以作为起点内容类型基础分加分项减分项用户约束100含路径/标识符 20重复出现 -30用户指令80近期(3轮内) 15已被执行完成 -20助手代码60含文件路径 15被后续版本覆盖 -25助手推理40含决策结论 20纯过渡性描述 -10工具调用参数50含关键配置 15只读查询 -15工具返回20含错误信息 30超长日志 -10这套权重的设计逻辑是约束指令代码参数推理返回。因为约束一旦丢失后续所有操作都可能跑偏而工具返回大部分是一次性的用完即弃。注意权重不是拍脑袋定的建议你拿自己真实的对话记录跑一遍看压缩后哪些信息丢了会导致 Agent 出错再针对性调高那类内容的权重。这是个迭代过程别指望一次调到位。4.3 处置策略与 token 预算分配有了分数接下来是处置。fast-jev-compaction 的处置策略我理解是四档全文保留分数高于高水位线比如 80 分的段落原样保留。用户约束、近期指令基本都在这档。截断保留分数中等40-80的段落保留头部和尾部若干行中间用省略标记替代。适合长代码块和长推理。折叠引用分数偏低20-40的段落压成一行摘要式引用保留可追溯性。比如[turn 8: 读取了 config.json, 共 240 行]。直接丢弃分数低于 20 的段落通常是重复的工具返回、已完成的只读查询结果。预算分配上一个实用的做法是给不同类型预留配额。比如总预算 100k token用户约束和指令预留 30k几乎不会用满代码预留 40k其余类型共享剩下的 30k。这样能防止某一类内容比如大量工具返回把预算吃光挤掉真正重要的约束。4.4 折叠引用的可追溯设计这是我觉得 fast-jev-compaction 比 LLM 摘要高明的一个细节折叠不等于删除而是保留一个可回溯的锚点。当 Agent 后续需要用到被折叠的内容时它可以通过引用标记知道这里曾经有东西在 turn 14然后主动请求展开。这个设计把压缩从一次性有损操作变成了分层存储按需加载。原始内容可以存在磁盘上上下文里只放索引。这跟操作系统的虚拟内存是一个思路物理内存上下文窗口有限把不常用的页换出到磁盘需要时再换回来。5. 实操把 fast-jev-compaction 接进你的工作流5.1 环境准备与依赖安装假设你已经在用 Claude Code接入 fast-jev-compaction 的第一步是拿到它的代码并装依赖。典型流程git clone repo-url fast-jev-compaction cd fast-jev-compaction npm install npm run build构建产物通常是一个可执行 CLI 和一个可导入的模块。如果你只是想快速验证效果直接用 CLI 模式最省事如果要深度集成就 import 模块。提示Node 版本建议 18 以上因为项目大概率用到了较新的 ESM 和顶层 await 特性。版本太低会在构建阶段就报错。5.2 配置文件的关键字段fast-jev-compaction 一般会读一个配置文件我按常见设计给一份模板{ tokenBudget: 100000, highWaterMark: 80, lowWaterMark: 20, typeQuota: { constraint: 30000, code: 40000, other: 30000 }, foldThreshold: 40, preserveRecentTurns: 5, traceableFold: true }几个字段的含义和调参建议tokenBudget压缩后的目标 token 上限。设成模型上下文窗口的 70% 左右比较稳留出空间给后续对话。highWaterMark/lowWaterMark决定全文保留和直接丢弃的分界线。这两个值调高会让压缩更保守留得多调低更激进。preserveRecentTurns最近 N 轮无条件保留。这个很重要因为近期上下文的相关性最高评分机制可能来不及反映。traceableFold是否开启可追溯折叠。建议开启代价很小收益很大。5.3 跑一次压缩并验证效果配置好之后拿一份真实对话记录跑一遍fast-jev-compaction compress \ --input conversation.json \ --output compressed.json \ --config jev.config.json \ --report--report会输出一份压缩报告包含压缩前后 token 数、各类型内容的保留比例、被折叠的段落列表、被丢弃的段落列表。这份报告是调参的核心依据。我自己的验证方法是把压缩后的上下文喂给 Agent让它继续一个需要用到早期约束的任务看它是否还记得那些约束。如果它开始违反早期约定说明约束类内容的权重还不够高或者预算被挤占了。5.4 参数调优的实操记录分享一次我自己的调参过程。初始配置下我发现 Agent 经常忘记测试文件放tests目录这条约束。查报告发现这条约束在 turn 3被后续大量工具返回挤到了低分区最终被折叠了。我的处理是两步一是把约束类的基础分从 100 提到 120二是给约束类单独设了不可侵占的配额。改完之后再跑约束稳定保留Agent 也不再乱放测试文件了。这个例子说明一个道理调参要看具体丢了什么而不是盲目调高所有分数。全调高等于没调预算就那么大你得让真正重要的东西优先。6. 常见问题与排查技巧实录6.1 压缩后 Agent 行为异常怎么排查最常见的症状是Agent 突然不遵守之前的约定了。排查顺序建议这样先看压缩报告确认那条约束是被折叠了还是被丢弃了如果是被折叠检查traceableFold是否开启Agent 是否能主动展开如果是被丢弃说明评分或配额有问题调高对应类型的权重如果约束根本没进分类器被误判成普通指令检查约束识别的模式库6.2 问题速查表症状可能原因处理方式约束丢失权重过低/配额被挤占提高约束基础分设独立配额路径被改写误用了 LLM 摘要路径确认走的是 Jev 决策而非模型摘要压缩后 token 没降高水位线设太低调低 highWaterMark或减小 preserveRecentTurns折叠内容无法展开traceableFold 关闭开启可追溯折叠保留原始存储压缩耗时过长分段粒度过细增大分段粒度减少片段数量近期上下文被压preserveRecentTurns 太小调到 5-8 轮6.3 几个我踩过的坑坑一以为压缩是免费的。虽然 Jev 决策比 LLM 摘要快得多但如果你对每一轮对话都触发全量压缩累积开销也不小。合理做法是只在接近预算上限时触发而不是每轮都压。坑二忽略了工具返回里的错误信息。工具返回整体分数低但里面的错误信息极其重要。我后来专门加了一条规则工具返回中匹配错误模式如Error:、failed、timeout的行单独提出来加分保留。这一条救了我好几次。坑三折叠引用没有版本号。早期我的折叠标记只写了 turn 号但对话可能被多次压缩turn 号会错位。后来改成给每个片段一个稳定的内容哈希作为 ID折叠引用指向哈希就不会错位了。坑四没考虑多文件场景。当对话涉及多个文件时同一类型的代码片段可能来自不同文件评分时如果不区分文件容易把 A 文件的关键代码当成 B 文件的冗余丢掉。解决办法是在评分时把文件路径纳入考量同一文件保留其最新版本即可。7. 这套方案还能怎么扩展fast-jev-compaction 的思路其实不局限于 Claude Code。任何需要处理长对话记忆的 Agent 系统都可以借鉴分类评分处置可追溯折叠这套框架。我最近在把它往两个方向试一个是跨会话记忆。把折叠下来的内容存进一个本地索引新会话开始时按相关性检索加载相当于给 Agent 装了个长期记忆。另一个是多 Agent 共享上下文。多个 Agent 协作时各自维护自己的压缩视图通过折叠引用互相引用对方的关键结论避免重复传递大段内容。这两个方向都还在摸索但核心逻辑是一致的别让模型去记让结构去存。模型负责推理结构负责记忆各司其职比让一个模型既推理又记忆要靠谱得多。我在实际使用中最大的体会就是上下文管理的本质不是压缩得有多狠而是该留的一个不少该丢的一个不留而这件事确定性规则比概率模型靠谱太多。

抛弃LLM有损摘要：fast-jev-compaction用Jev决策重构上下文压缩

相关推荐

VT仿真技术入门：从零搭建虚拟机床环境

CSS margin-auto实现元素靠右显示的布局技巧

Jolt Physics引擎集成与性能优化实战指南

更多资讯

iloader：iPhone 侧载 SideStore 与导入 IPA，全程不碰命令行

计算机服务巡检

Yuzu模拟器历史版本下载完整指南：7个存档构建一次讲清，怎么选、怎么装

BongoCat 交互桌宠实战:5 分钟从安装到自定义 Live2D 模型

被惯时忘了的linux03

yunerDesk—API包装，服务器运维，数据推送，同步

今日更新

学生选课系统DFD图绘制指南：边界划分与分层校验实战

JIRA敏捷落地：Scrum角色权限、Sprint与燃尽图避坑指南

SEMI S8人机工程验收实战：从条款拆解到现场实测的完整指南

本周精选

防幻觉智能体架构：电源硬件设计中的大模型编排与工具化实践

OpenGL面试核心考点：渲染管线、矩阵变换与性能排查全解析

全国计算机二级C语言真题PDF高效刷题指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？