推荐 pi-continue：解决 Pi 长任务中途不压缩的问题

SC 2026-07-12 19:04 1

发现一个解决 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 截断.

但是就我实际使用来看, 根本就没有生效.

pi-continue

pi-continue 无须配置, 插件的压缩阈值直接继承自 pi 的压缩配置, 也就是 ~/.pi/agent/settings.json 里面的(如果是全局配置):

"compaction": {

    "enabled": true,

    "reserveTokens": aaa,

    "keepRecentTokens": bbb

  },

最后, 如果有佬知道解决这个问题的方法可以踢我一下。

最新回复 (14)

邱埋葬 07-12 19:10

1楼

我目前的解决方式是直接移植OpenCode的DCP插件，每个turn_end后（而非agent_end）就视情况注入提示词引导LLM进行compress。保持上下文15w——这样基本所有内容都能被模型注意到。

链接就不发了。GLM5.2可以一遍过。
SC 楼主 07-12 19:13

2楼

npm:@pi-vault/pi-dcp

这我看到一个插件
pan iron 07-28 19:07

3楼

pi-continue今天第一次装上, 新会话遇到问题:

Error: Compaction failed: Already compacted

Error: automatic continuation: handoff failed: Continuation handoff failed

看起来好久没有更新了. 不知道有没有平替的, 找了一下也没有找到
apparition 07-28 19:09

4楼

这种恶性 bug 还能活那么久

说好的少做少错呢 ^-^

SC 楼主 07-29 10:00

5楼

这个原因是 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 iron 07-29 11:27

6楼

我发现站内昨天有一个新的插件来解决这个问题: leonfox28/pi-midrun-compact

已经装上试试了
Sisu 07-31 09:54

7楼

实测仍然不起作用，context 已爆
pan iron 07-31 09:59

8楼
佬配置了吗, 我在C:\Users\你的用户名\.pi\agent\extensions\pi-midrun-compact\config.json下面配置了
```
{

  "thresholdPercent": 85,

  "notify": true

}
```
这两天用下来没有问题
Sisu 07-31 10:18

9楼

还要配置啊，还以为安装即可，谢谢佬提醒
pan iron 07-31 10:24

10楼

我没有试过不配置是不是可以, 我看默认是75%, 感觉有点低了, 所以就直接改了配置了来进行使用
pigzzz 08-21 14:10

11楼

这么奇葩明显的bug，竟然到现在还没修复，我还以为我使用姿势问题，导致我上下文超限双倍扣费了。艹
botwo 08-21 15:23

12楼

看了好多方案，倒是没有太折腾。可能跟我流程有关，通常都是提前计划好，按照合适的粒度拆分批次，然后每个批次派发独立的herdr worktree 中的 pi session 落地。

还在使用官方的 compact，现在的方案是，支持1M ctx的gpt-5.6，在models.json中设置为500k，现在基本上很顺畅 ^-^

既解决了一轮agent run直接超出ctx window的情况，又能缓解 long ctx 下的注意力跑偏
Google 08-21 15:24

13楼

和 magic-content 有什么差异吗，magic也是无感
msputup 08-21 15:26

14楼

之前确实遇到过，不过我一般都是看上下文，看着差不多就主动压缩了。很少用自动压缩。