Jev 上下文压缩：判断智能体必须保留哪些轮次

这个检查打的是什么分

上面的示例是一个编程智能体会话中的四轮对话。智能体报告迁移脚本跑完后 40 张表里有 3 张因外键报错；用户顺口说猫打翻了咖啡；智能体提议临时删掉约束；用户说生产环境里绝不能删约束，要先补齐缺失的客户数据。Jev 对整段对话回答两个问题：

这段对话把整个会话里最重要的一句和最无关紧要的一句放在了一起。摘要可能记住了"先补数据"，却丢了"生产环境绝不删约束"；Jev 不改写任何一句，只告诉你这段对话整体上该不该留、有多该留。这也是这个示例想说明的：如果你想删掉咖啡那句、留下约束那句，就要一轮一轮地分别打分。

怎样写出好用的压缩问题

问将来，不问过去。 "这一轮相关吗？"几乎对什么都成立。"智能体决定下一步时还需要它吗？"才能把仍在起作用的上下文和纯粹的历史分开。

写清楚为什么删掉是安全的。 fast-jev-compaction 插件在问"某个工具的完整输出是否应逐字保留"时，附带的判断标准是重新运行这个工具也替代不了。这就是全部依据：智能体能重新获取的结果删掉代价很小，用户说过的约束则不行。

把目标放进 state。 一轮对话重不重要取决于任务。在历史记录旁边附上最近几条用户提示词，或流水线自己的任务描述。

要缩短而不是删除时，用 Score。 Noul 只给出留或删。五级 Score 可以让你逐字保留 High 和 Must keep、截短 Medium、删掉其余。

更多写法见 设计 Jev 能回答的问题。

从一次检查到一个压缩步骤

Claude Code 插件 fast-jev-compaction 是把这个检查变成流水线步骤的现成例子：

1. 固定。 第一条消息和最新 6 条消息里的工具调用不经提问直接保留。
2. 构建一个小的 state。 每个工具结果都换成一行说明（比如它的大小），工具输入和消息文本保留。不做任何摘要。
3. 对其余每个工具调用问两个问题：这个调用该不该留，它的完整输出该不该留。问题分批，让每次请求都低于 token 上限，并行发送。
4. 按阈值决定，默认 0.5：两者都留；只留调用，输出截取前 300 个字符并附一条"需要时重新运行工具"的说明；或者两者都删。
5. 只有划算时才替换历史。 压缩幅度不到 25%，或 Jev 调用失败时，插件交回给 Claude Code 内置的摘要压缩。

完整设计，包括会话太长、Jev 看不下时如何逐级缩小 state，见深度解读：fast-jev-compaction：不写摘要的上下文压缩（英文）。同样的问题也可以在任何 harness 里通过 System One API 调用。

先验证，再信任

• 看决策，不只看省了多少。 把每个概率和对应动作一起记下来。落在阈值附近的条目，就是调参的地方。
• 回放真实会话。 找一些智能体后来需要用到早期内容的对话记录，压缩一遍，检查那些内容还在不在。
• 记录模型版本。 每次响应都带有 model 字段（例如 jev-1.13.0）。把它和每条判定一起记下，版本变化时重新校验阈值——JevStation 在部署层固定模型，不需要你在请求里指定。
• 让 state 保持聚焦。 TypeSafe 把"state 很大且充满无关细节"列为已知弱点。先在代码里过滤，按小块打分，而不是塞进一大段对话。

Jev 不适合的情况

• 会话长是因为聊天多，而不是工具输出多。 删除整个工具调用容易做到安全，删减正文则不然，所以那个插件从不缩短文本消息。
• 你需要一份给人看的摘要。 Jev 不写摘要。
• 保留与否取决于日期或数量，比如"早于昨天的都删"。TypeSafe 把日期比较和算术列为弱点，这些放在代码里做。
• 上下文不能离开你的基础设施。 state 会发送到 API。

在 试验台 里用你自己的对话记录试一试，或者在 定价页 看看给每一轮打分要花多少。