背景与痛点
长会话里那些“食之无味”的历史工具输出
在使用 AI 进行较复杂的重构或排查任务时，都会遇到上下文过多压缩的情况。
在 Pi 中虽然说有压缩命令，但我们可以看看他具体压缩了些什么。
如果你用 Pi 跑过时间稍长的任务，大概清楚那个感觉：上下文里堆着几十轮的工具输出，read 读了几百行源码的结果、bash 吐出来的长串依赖树、反复试错时留下的废弃命令……这些东西凑在一起，等到上下文快满、准备压缩时，它们依然原封不动地躺在那儿，等着被一口气扔进去做摘要。
问题是，把这些早就过期的内容全都喂给大模型，虽然模型可能从摘要里能留下什么有效信息，但是执行效率和还有准确性肯定是差了一点点。
所以我做了这个插件，想先在压缩前把真正没用的东西挑出来。把这些早无时效性的大段工具文本全部直接塞给大模型做压缩摘要，不仅消耗大量总结耗时和 token 成本，还可能因为无关噪音过多而稀释真正关键的上下文记忆。
解决思路
在原生压缩前，先来一次修剪
借鉴了 Tamara Tran 在 Claude Code 生态下的出色工作 fast-jev-compaction，我做了一个面向 Pi 的原生适配插件：@lienat/pi-jev-compaction。它只做原生压缩前的“减负预处理”。
Pi 触发压缩（自动阈值 或 手动 /compact） ↓ 触发 session_before_compact 扩展钩子 ↓ Jev 秒级评估待摘要区间的工具调用与结果 │ ├─ 评估成功：仅精简冗余的工具调用和截短大文本结果 │ ↓ │ Pi 原生 compact() 生成结构化摘要与元数据 │ └─ 超时 / 异常 / 用户取消：完全保持原始消息数组不变 ↓ 安全回退至 Pi 原生普通压缩核心亮点
- 只做减法
- 精准裁剪：通过 TypeSafe Jev 模型在毫秒级内裁定历史工具调用是“保留”、“删除”还是“截短”。
- 绝对保护原生信息：User 提示词、Assistant 思考过程（thinking blocks）、图片内容、近期保留消息以及不完整的工具对完全不动。
- 只替换输入数组：会话的 firstKeptEntryId、fileOps 文件操作追踪、分支元数据依然 100% 由 Pi 自己管理。
- 极致的安全回退
- 设定了默认 15 秒超时时限（可通过环境变量调节）。
- 一旦网络抖动、Key 未配置、请求超时或用户主动中断，插件会默默跳过，Pi 会平滑回退到原生压缩，绝不中断会话流程。
30 秒极速安装体验
第一步：安装插件
直接通过 Pi 的包管理器安装（推荐）：
piinstallnpm:@lienat/pi-jev-compaction也可以直接从 GitHub 安装：
piinstallgit:github.com/Jul1en-Lin/pi-jev-compaction@main第二步：配置 Jev API Key
插件使用官方 TypeSafe Jev 服务做快速决策判定。在启动 Pi 的终端环境中配置环境变量：
exportTYPESAFE_API_KEY='your-typesafe-key'可选参数：
# 自定义单次 Jev 判定超时（毫秒），默认 15000（15秒）exportPI_FAST_JEV_TIMEOUT_MS=15000第三步：体验
重启 Pi 即可。平时写代码完全不需要改变任何使用习惯，不管是上下文占满触发自动压缩，还是手动输入 /compact，控制台都会打印出清晰的精炼记录：
[jev] 12 call(s) reviewed: dropped 8, shortened 2 · 850ms; Pi will create the native summary.无需干预，原有的臃肿调用已被精准卸下，留给 Pi 的是一个干净、轻量、高信息密度的待摘要上下文。
开源与致谢
这是我的 github 仓库，也欢迎在 Pi Package 市场下载使用
- GitHub：Jul1en-Lin/pi-jev-compaction
- 核心决策逻辑源自 Tamara Tran 的 fast-jev-compaction 及 aleksvega 的分支。
欢迎试用、提 Issue 或 Star 支持！
