背景与痛点长会话里那些“食之无味”的历史工具输出在使用 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-compactionmain第二步配置 Jev API Key插件使用官方 TypeSafe Jev 服务做快速决策判定。在启动 Pi 的终端环境中配置环境变量exportTYPESAFE_API_KEYyour-typesafe-key可选参数# 自定义单次 Jev 判定超时毫秒默认 1500015秒exportPI_FAST_JEV_TIMEOUT_MS15000第三步体验重启 Pi 即可。平时写代码完全不需要改变任何使用习惯不管是上下文占满触发自动压缩还是手动输入 /compact控制台都会打印出清晰的精炼记录[jev] 12 call(s) reviewed: dropped 8, shortened 2 · 850ms; Pi will create the native summary.无需干预原有的臃肿调用已被精准卸下留给 Pi 的是一个干净、轻量、高信息密度的待摘要上下文。开源与致谢这是我的 github 仓库也欢迎在 Pi Package 市场下载使用GitHubJul1en-Lin/pi-jev-compaction核心决策逻辑源自 Tamara Tran 的 fast-jev-compaction 及 aleksvega 的分支。欢迎试用、提 Issue 或 Star 支持