- sc2026-07-12
发现一个解决 pi coding agent 压缩问题的 Pi 插件：pi-continue。
之前使用 Pi Coding Agent 跑 GPT-5.* 的 272K 上下文模型时经常遇到一个问题： 一个 agent turn 过长，上下文就可能一路涨到 100% 以上，有时甚至超过 130%，但 auto compact 迟迟没有触发。
同样类型的任务放到 Codex CLI 里完全不会遇到这个问题。
阅读 doc 发现是 pi 的压缩机制问题。
pi 的压缩机制
Auto-compaction triggers when:```
contextTokens > contextWindow - reserveTokens
```文档里面说, pi 的 compaction 会在一个 agent turn 结束后进行, 一个 agent turn 指的是从用户请求开始, 直到下一个用户请求之前, 这意味着中途 agent 可以不断地 ass, tool, ass, tool, … 如果是这样的话, 出现超过 100% 的情况也不奇怪了.虽然官方文档里面自己又说会在 mid-turn 截断.
但是就我实际使用来看, 根本就没有生效.
相关 GitHub Issues
下面是我让 gpt 找的相关 issue, 看起来这个问题还没有修复。
五月
- #1796：Auto-compaction threshold only fires on successful turns：维护者确认 mid-turn compaction gap 是一个独立问题，需要 agent loop 中的 stop/check hook。
六月
- #5512：Auto-compaction has no mid-turn context guard：维护者明确回复：
this will be fixed once the refactor lands.
七月
- #6339：Auto-compaction threshold is never evaluated during an agentic run：重构落地后，又有人在 Pi
0.80.3和当时的main上复现了同一个问题，最终以not planned关闭。pi-continue
pi-continue 无须配置, 插件的压缩阈值直接继承自 pi 的压缩配置, 也就是 ~/.pi/agent/settings.json 里面的(如果是全局配置):```
"compaction": {
"enabled": true,
"reserveTokens": aaa,
"keepRecentTokens": bbb
},
```最后, 如果有佬知道解决这个问题的方法可以踢我一下。主楼 - 邱埋葬2026-07-12
我目前的解决方式是直接移植OpenCode的DCP插件，每个
turn_end后（而非agent_end）就视情况注入提示词引导LLM进行compress。保持上下文15w——这样基本所有内容都能被模型注意到。链接就不发了。GLM5.2可以一遍过。
- sc2026-07-12
- pan_iron2026-07-28
pi-continue今天第一次装上, 新会话遇到问题:
Error: Compaction failed: Already compacted
Error: automatic continuation: handoff failed: Continuation handoff failed
看起来好久没有更新了. 不知道有没有平替的, 找了一下也没有找到
- apparition2026-07-28
- sc2026-07-29
这个原因是 pi 原生压缩和 pi-continue 都触发了```
try {
ctx.compact({
customInstructions,
onComplete: () => {
if (!claimCompactionCallback()) return;
runtime.compactionRunning = false;
runtime.guardFailureKey = undefined;
if (options.continueAfterComplete) {
markContinuationCompactionComplete(ctx, runtime, event.id);
return;
}
finishContinuationEvent(runtime, event.id, "completed", undefined);
settleWorkingVisuals(ctx, runtime, event.id);
notify(ctx,${label}: handoff saved., "info");
},
onError: () => {
if (!claimCompactionCallback()) return;
failCompaction(compactionFailureReason(runtime, event.id));
},
});
} catch {
failCompaction(compactionFailureReason(runtime, event.id));
return false;
}
return true;
```但是 pi 先压缩完, session 里面加上了一个 compact entry然后 pi-continue 调用的压缩 api 一看 session 最后有个 entry, 后面又没东西, 说明已经没东西可以压缩了, 就 error: already compacted
最后 pi-continue 在 onError 还在监听压缩是否成功, 发现失败了, 就报错 automatic continuation
- pan_iron2026-07-29
- Sisu2026-07-31
实测仍然不起作用，context 已爆
- pan_iron2026-07-31
佬配置了吗, 我在
C:\Users\你的用户名\.pi\agent\extensions\pi-midrun-compact\config.json下面配置了```
{
"thresholdPercent": 85,
"notify": true
} - Sisu2026-07-31
还要配置啊，还以为安装即可，谢谢佬提醒
- pan_iron2026-07-31
我没有试过不配置是不是可以, 我看默认是75%, 感觉有点低了, 所以就直接改了配置了来进行使用
- pigzzz2026-08-21
这么奇葩明显的bug，竟然到现在还没修复，我还以为我使用姿势问题，导致我上下文超限双倍扣费了。艹
- botwo2026-08-21
看了好多方案，倒是没有太折腾。可能跟我流程有关，通常都是提前计划好，按照合适的粒度拆分批次，然后每个批次派发独立的herdr worktree 中的 pi session 落地。
还在使用官方的 compact，现在的方案是，支持1M ctx的gpt-5.6，在models.json中设置为500k，现在基本上很顺畅 ^-^
既解决了一轮agent run直接超出ctx window的情况，又能缓解 long ctx 下的注意力跑偏
- Google2026-08-21
和 magic-content 有什么差异吗，magic也是无感
- msputup2026-08-21
之前确实遇到过，不过我一般都是看上下文，看着差不多就主动压缩了。很少用自动压缩。