Guides / 视频转图文攻略

Jev 上下文压缩实战：不用生成式摘要，直接剪枝 Agent 记忆

逐帧解读 fast-jev-compaction：Alex Hitt 这支 7 分钟动画演示了如何用 Jev 的类型化是非题剪枝取代有损的生成式自动压缩——锚定首尾、8 级渐进压缩、0.5 keepThreshold，最终砍掉 86% 的 token。

速览结论

Alex Hitt 这支 7 分钟动画视频（GitHub 上的 fast-jev-compaction 仓库）讲清了长会话编码 Agent 的真正短板——生成式自动压缩：上下文窗口写满时，Agent 暂停 30–60 秒等一个 LLM 重写自己的历史，而重写常常弄丢精确的文件路径、报错堆栈，以及「永远不要改这个自动生成目录」这类长期约束。替代方案是 Jev System One 并行采样驱动的非破坏性剪枝，分三步改造会话状态：开头的指令消息和最近的对话轮次被永久锚定，从不参与剪枝评估；未锚定的纯文本经 8 级渐进压缩算法持续收缩，直到低于静态的 maxStateTokens 上限（仓库默认 25,000），token 数用字符权重启发式估算（字母约 0.16、数字 0.50、符号 1.00），不必加载分词器；万一压不进去，流程安全回退到原生摘要。随后每条未锚定的工具调用都要并行回答两道类型化的 Noul 问题——问题 A：知道「这次调用发生过、参数是什么」还有相关性吗？问题 B：输出的精确文本是否必须逐字保留，还是以后重跑一次工具就够了？可配置的 keepThreshold（演示用 0.5）把概率对变成三向裁决：双双低于阈值 → 调用和结果一起删除；只有调用相关 → 保留日志行、截断大体积输出；结果仍必要 → 原文逐字保留。在密集 TypeScript 会话上的实测：模型把重复的 bash 输出判定为可删，token 削减 86%，超过 187,000 token 的会话数组 1.5 秒内剪完——输出 token 免费、请求并行路由，400 次同时工具调用评估总共只花 1.2 美分。

视频来源

Alex Hitt

7:00•Ph40aRc6jRg

访问频道观看原视频

分步图文攻略

1
先看问题有多严重：84,455 token 还在涨
一次连续的编码会话会堆积终端命令、grep 结果和文件读取，每一项都占用基础模型上下文窗口的一角。视频开头就是那个要命的计数器——上下文窗口冲过 84,455/128,000 token，底下堆着一摞摞工具日志文档。每个 Agent 用户都认识这一刻：会话即将触顶，而有什么东西马上要重写你的历史。
每条 bash 命令和 grep 结果都在窗口里占了永久座位——直到有什么东西出手干预。跳转至 0:26
2
对比两种架构：有损摘要 vs 逐字剪枝
行业对窗口写满的标准反应是生成式自压缩：暂停，让 LLM 读完整段对话，写一份浓缩叙事。流程图把它和 fast-jev-compaction 的 System One 剪枝放在一起对比。左边，自回归 LLM 把原始上下文（工具调用加用户约束）破坏性地压成有损摘要——摘要经常弄丢精确文件路径、堆栈跟踪和「永远不要改自动生成的目录」这类显式约束。右边，System One 并行采样器评估同样的原始上下文，给每条内容打 Noul 概率（图中 0.78、1.00），据此决定保留还是丢弃——用户约束完全绕过删除环节，一字不动。
生成是重写记忆，评估是给它打分——右边这条路从不改写任何约束。跳转至 2:36
3
锚定首尾，中部走 8 级压缩
在 Jev 评估任何东西之前，仓库先保护对话的两端：开头的指令消息（系统提示词和你一开始谈好的规则）与最近的对话轮次被永久锚定，剪枝不会碰它们。中间的部分交给 8 级渐进压缩算法——大段纯文本被数学化截断、工具输入被裁剪、消息合并成单块——直到整个状态低于静态的 maxStateTokens 上限。
压缩是分级的，不是一刀切——每过一遍就多买一段余量。跳转至 3:25
4
用字符权重估算 token，不加载分词器
只为决定「要不要剪」就加载一整套分词库本身就是税，所以仓库用字符计数启发式：约六个字母折一个 token，数字折半个，符号一个算一个。视频里的权重表给字母标价约 0.16 token、数字 0.50、特殊符号 1.00。如果粗估超过 25,000 的 maxStateTokens 上限，会先触发一轮激进缩减，再把状态送去评估——Jev 只把算力花在结构合规的状态上。
用便宜的算术顶替分词器——估算只需准到能守住请求闸门即可。跳转至 3:31
5
花钱之前先确认状态装得下
检查点帧展示的是顺利路径：压缩后状态以 18,500 token 对 25,000 上限通过「结构合规」认证。假如 8 级压缩没能压进上限，异常处理协议会中断压缩、安全回退到原生摘要机制——这是刻意留的逃生门，确定性管线绝不会把超限状态送去评估。
18,500 token 过检——评估器只见过关的状态。跳转至 3:42
6
每条未锚定工具调用回答两道类型化问题
每条未被锚定的工具调用都要过一次双问评估，这张矩阵就是整个系统的心脏。问题 A 评估调用本身的相关性：知道「这次调用发生过、参数是什么」还值得保留吗？问题 B 评估结果：输出的精确文本是否必须逐字保留，还是以后重跑工具就够？示例里读日志调用相关性 0.67、必要性只有 0.34，而一条通过校验的记录在结果侧保住 0.92——两个独立概率，代替一个含混的摘要裁决。
相关性和必要性是两个问题——管线分开问、并行问。跳转至 5:00
7
用一个 keepThreshold 把关删除
概率对通过一个可配置数字变成三向裁决。演示里一份文档以 0.87 对 0.5 的 keepThreshold 稳稳落在保留侧。完整策略：结果概率过线 → 原文逐字保留；只有调用本身相关 → 日志行留下、大体积输出截断；双双低于阈值 → 调用和结果按过时数据处理、永久删除——每条幸存记录的时序身份原样保留。
一个阈值、三种结局：逐字保留、留日志截断输出、或者直接删。跳转至 5:08
8
看结果：token 砍 86%，1.5 秒剪完
基准面板给出了这套策略的收益。在密集 TypeScript 会话里，把重复 bash 输出判定为可删后最多削减 86% 的 token——Terminal 1 只保留了约 15% 的会话，Desktop 约 20%。因为模型不是自回归的，整个评估非常快：超过 187,000 token 的会话数组 1.5 秒内剪完，而生成式摘要在两小时会话里要冻结 3–5 次、每次 30–60 秒。
每个会话的保留与剪除——重复的 bash 输出过不了这道闸。跳转至 5:58
9
算经济账：400 次工具调用评估 1.2 美分
API 成本表给持续评估循环定了价：40 次调用合 1 个请求花 $0.001，150 次 $0.005，400 次极限并发工具调用恰好 $0.012——1.2 美分——因为输出 token 免费、请求并行路由。视频的收尾论点：自主会话越长，把记忆管理交给确定性的非生成评估器，就能让 Agent 历史保持精确，而且再也不用付摘要税。
一整个 400 次调用的剪枝周期，还抵不上一次前沿模型摘要的零头。跳转至 6:18