Title: Context never auto-compresses when the model ignores the nudge — climbs 75%→95%+ on long agentic tasks (no enforcement path)

[ranxianglei]

Summary

billion-context-pi only ever TRIGGERS compression by injecting an advisory
nudge prompt; the actual compression requires the model to call the compress
tool itself. There is no enforcement / auto-compress path. When the model is
mid-way through a long agentic task and ignores the nudge, context grows
unbounded past the 75% OVER-LIMIT threshold all the way to 95%+ (EMERGENCY),
and EMERGENCY is also only a stronger label + output-headroom shrink
(262144→245760) + tool-output truncation — it still never force-compresses.

What 0.1.55 fixed (works)

The METER / detection: tokenCount = max(estimate, providerReal), so the
OVER-LIMIT nudge now fires at true 75% usage. Confirmed in acp.log —
session 01a01e31 on 0.1.55 logs nudge=active nudgeReason=OVER-LIMIT T1, usage 77% on EVERY turn from 77% up to 87% for 20+ consecutive turns.

What is still broken (the ask)

1. No enforcement. Over 20 consecutive OVER-LIMIT turns the model did not
   call compress (only one earlier compliant compress: 184K→112K). There is no
   fallback that compresses server-side when the model keeps ignoring.
2. Tiny compressible headroom during active work. At 87% usage the log shows
   max effective pending 16296 (est) — most of the context is either in the
   protected recent/current-step zone or already in 71 blocks, so even a
   compliant compress only reclaims 16K (87%→80%) and the running task
   regrows it within ~30 min. The protected "recent/last-user zone" may be too
   large for long single-step agentic runs.

Suggested fix

Add an enforcement path: after N consecutive ignored OVER-LIMIT/EMERGENCY
nudges (or hard at 0.95), the extension should auto-compress the largest
compressible ranges itself (server-side), independent of the model. Also
consider bounding the protected recent-zone by TIME/TOKENS (not "since last
user message") so long agentic steps don't pin ~all context as non-compressible.

Repro / evidence

• pi 0.83.6, billion-context-pi 0.1.55, local sglang Qwen3.8-27B
  (window 262144→245760), CJK-heavy.
• acp.log [turn] for sid 01a01e31, 07:57–08:06Z:
  nudge=active nudgeReason=OVER-LIMIT T1: max effective pending 16296, usage 87% blocks=71 activeBlocks=17 (repeated; no [compress] events).
• One compliant compress at 07:25Z: applied ranges=3 tokensCompressed=29775 beforeTokens=37660 afterTokens=9148 then regrew 112K→212K in ~30 min.

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 Implemented the server-side enforcement path. PR: #270

What it does — when the model ignores the nudges, the extension now compresses the largest compressible ranges itself, independent of the model:

• Streak — after afterIgnores (default 3) consecutive over-limit turns with no model compress, it auto-compresses.
• Hard threshold — at hardThreshold (default 95%) it fires immediately, regardless of the streak.

This directly addresses the log you shared: 20+ consecutive OVER-LIMIT turns with no [compress] event now get a server-side fallback instead of climbing toward overflow.

Design notes

• Runs in the context transform right after processTurn, before nudge injection — so the model sees the post-compression context and the nudge reflects the new (lower) usage.
• pickAutoRanges greedily picks viable ranges (largest first) until projected usage drops below targetPct (default 80%), capped by maxRanges (default 5).
• Auto-compressed ranges get an honest, labeled mechanical summary — the block is fully restorable via decompress, so nothing is fabricated as a model-quality summary.
• A successful model-driven compress resets the streak; it never fires below targetPct; a once-per-turn gate prevents same-turn spam.
• compress.autoCompress defaults to true (it's the fix) and is disable-able via false or an object (afterIgnores / hardThreshold / targetPct / maxRanges).

No acp-kernel change was needed — applyCompression, processTurn, nudge.compressibleRanges, and viableRanges all already exist in 0.0.48.

On the second point in the issue (bounding the protected recent-zone by time/tokens so long single-step agentic runs don't pin ~all context as non-compressible): I scoped this PR to the enforcement path only. The kernel already protects by preserveRecentTokens (5000) + preserveRecentMessages (5) + the current turn, which leaves a compressible range in the scenario you logged — that's what the enforcement consumes. If you'd like the protected-zone bounding as a separate change, I can follow up on it (it's a kernel-side tuning knob, so it'd land in acp-kernel first). Flagging it here rather than silently expanding scope.

Tests: 12 new (unit + e2e: streak / hard / disabled). Full suite 474 pass / 0 fail / 3 skipped; typecheck clean; build succeeds. Docs updated in CONFIGURATION.md (+zh-CN), README, and CHANGELOG.

PR is ready for review — merge is yours to do.

[ranxianglei]

Root cause and fix-shape review (code read of v0.1.55 + acp-kernel)

Confirmed the diagnosis above. Adding two findings the issue understates.

Three-layer root cause

Surface — no enforcement path.
The only compression trigger is "nudge text → model reads → model calls compress". In acp-kernel/src/compress.ts:670 (nudgeNode) the kernel only stamps shouldInject, lastPerMessageNudgeTokens, lastShownByTier and renders UI text. No sibling pipeline node synthesizes a server-side compress effect at usage ≥ emergencyThresholdPct or after N ignored nudges. The label EMERGENCY vs OVER-LIMIT (compress.ts:1183-1261) selects the nudge voice only.

Mid — both fallbacks miss this regime.

• emergencyTruncateNode (compress.ts:729 + truncate-tools.ts) — tool-output truncation + output-headroom shrink. Bounded recovery, no compress.
• Extension src/overflow-selfheal.ts reacts only to real 400 overflow errors matched by OVERFLOW_MARKER. When usage climbs to 95% but the configured window still admits the API call, no provider-side 400 fires, no self-heal arms. Even armed, effect is "next turn forces usage≥95%" — louder voice, still no compress.

Deep — protection model is chat-shaped, not agentic-shaped.
src/compress.ts:181 "soft-protected zone (recent-N + last user message)" pins everything from the last user message onward. Agentic workflows = one user msg + 20+ tool/observation cycles → most of the context becomes non-compressible. The issue's own data is the proof: at 87% usage across 71 blocks, max effective pending 16296 (~16K out of 200K). The model's "ignore" is the correct decision: nudge offers to recover 16K at 87% full, model reasonably declines. Even a compliant compress only takes 87%→80%.

So "no enforcement" is a symptom; oversized protected zone is the cause. With most content protected, no compressor — model-side or server-side — has enough to reclaim.

The naive fix risks over-injection → context growth

If we add auto-compress at 0.95 without guardrails, deep-compression regime introduces a feedback loop where the meta-overhead it adds outpaces the content it removes. Per enforce fire:

Δctx = + noticeTokens + placeholderSummary − originals
     ≈ +200 + 0.3X − X = +200 − 0.7X

When largest pending X shrinks (precisely the deep-compressed regime), Δctx goes positive. Three additive vectors:

• V1 placeholder accumulation. Each fire replaces originals with stubs. Stubs are non-recompressable permanent assets.
• V2 UI notice accumulation. Per fire ~+200 tokens permanent. Re-fire on same range after cooldown adds more.
• V3 model-react churn. If we tell the model "enforced, refine via decompress+recompress", it reacts → decompress + compress tool call + tool response text added permanently.

Concretely at the issue's own data point (16K max pending), a single naive enforce fire adds ≈5.2K permanent overhead and saves 11K content — net −5.8K the first time. But across 5 cycles of refire-and-churn, context rises. The naive fix can regress on the empirical case.

This converts a recoverable failure mode ("stuck at 95% but content intact, user can /acp or /compact on idle") into a silent-quality-loss failure mode ("context grew from meta-pollution, original content already destroyed by low-fidelity templates"). The first is annoying; the second is unrecoverable.

Required fix shape

A. Bound protected zone by TOKENS first. preserveRecentTokens already exists at src/protected.ts:11. Investigate why it isn't binding in long single-step agentic sessions — likely the "last user message" anchor at compress.ts:181 always wins over the tokens bound. Tighten to max(recentN_msgs, lastUser_anchor, recentTokens_budget). Zero new injection. Replay session 01a01e31 with tightened bound and measure.

B. Enforce auto-compress — only if A still leaves usage climbing. Five mandatory guardrails, all cheap:

Guard	Why	Where
projectedNetGain check pre-fire	Skip when X − Y − notice < minEnforceNetGain (e.g. 5K). Prevents the V1/V2 reversal.	New state.enforce; computed at fire site
perRangeOnce enforced flag	Range once server-compressed never re-enforced this session unless model explicitly decompresses it.	Per-blockId marker in state.enforce.perRangeOnce
Session enforceBudget K (e.g., 5)	Meta-overhead is monotone in fire count even with the above. Hard cap.	state.enforce.fireCount
Hide enforcement from model's prompt view	V3 churn trigger is the "enforced, you may refine" text. UI-notify humans only; in the next prompt the placeholder is indistinguishable from a model-driven summary.	summarySource stays internal; nudge text unchanged
Long cooldown	enforceShownByTier + cooldown ≥ 5× nudge.growthFloor so notice+churn overhead doesn't outpace compressible content between fires.	Mirror existing lastShownByTier pattern

Plus reuse the model-driven entry: enforcement fires through parse-compress-input.ts → compress-tools.ts so boundaries.ts, reasoning-pairs.ts, tool-pairs.ts invariants come for free. Skipping this is the most common way enforcement implementations introduce corruption bugs.

Suggested sequencing

1. Bound first. A is zero-injection and probably sufficient. Verify against 01a01e31 empirically.
2. Enforce second, with the five guardrails. Likely fires rarely once A is in place — but is the cheap safety net for the case where the model legitimately refuses to act.

Implementation pointers

Pipeline changes go in acp-kernel/src/compress.ts (new enforce-compress node between nudge-inject and emergency-truncate), src/state.ts (extend state.nudge with enforce sub-state), src/types.ts (config keys: enforceAfterN, enforceAtUsage, minEnforceNetGain, enforceBudget). The extension billion-context-pi/src/config.ts:178-237 propagates them through the model/provider/global three-tier as emergencyThresholdPercent already does; src/index.ts:389 mirrors a UI notification for enforcement events.

One thing not in scope of the issue

compress.ts:1311 already suppresses the nudge when "no tier has effective compressible content" — exactly the regime in the data. The current behavior is therefore "nudge suppressed, no action, context stays at 87% forever". That's actually correct anti-thrashing. The fix shouldn't reintroduce a fire in that same regime — hence the projectedNetGain guard, which is the same predicate already used to suppress the nudge. Good news: the predicate exists, just needs reuse.

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 Thanks for the thorough review. I cloned and read acp-kernel to verify the "deep cause" claim before implementing — here's where I landed.

On the "deep cause" (protection model is chat-shaped): I don't think it holds up

I read protected.ts and recommend.ts:

• The soft-protected recent zone is bounded and agentic-aware, not "everything from the last user message onward":
  • NEVER_PRESERVE_RECENT_TOOLS = ["decompress","search_context","read","bash"] (protected.ts:29) — the big agentic tool outputs are explicitly excluded from the protected zone, so they can be compressed.
  • computeProtectedRefs (recommend.ts:70) protects only: the last 5 visible messages (preserveRecentMessages=5) + the last 5000 tokens of visible content (preserveRecentTokens=5000) + the single last user message (the loop breaks after one).
• So the protected zone is capped at ~5 messages / 5000 tokens / 1 user message — not a whole agentic step.

I think the misread comes from compress.ts:181, which is a comment — "Default to the soft-protected zone (recent-N + last user message)" — that is imprecise: it omits the token bound and overstates "last user message" (a single message, not a zone). Happy to fix that comment in acp-kernel.

So why is only ~16K pending at 87%? Not an oversized protected zone — most of the content is already in blocks (summaries accumulated over 71 compressions). That's exactly your V1 (summary/placeholder accumulation), and you're right that it's the real driver: once the raw compressible content is mostly converted to summaries, the remaining raw "pending" is small, and the nudge correctly suppresses ("no tier has effective compressible content").

Where I fully agree

• The naive-fix over-injection risk is real: Δctx = +notice + 0.3X − X = +200 − 0.7X goes positive as X shrinks, and V1/V2/V3 are the right vectors. This is exactly why enforcement must not fire in the deep-compressed regime.
• "Reuse the model-driven entry" is already how it works — enforcement calls applyCompression (the same entry the model's compress tool uses), so the boundaries / reasoning-pairs / tool-pairs invariants come for free.

What I implemented (PR #270, updated)

All five of your guardrails, in billion-context-pi (my repo — I can't cut an acp-kernel release from here):

1. minEnforceNetGain (default 5000) — skip a pass unless the picked ranges save ≥ that after subtracting summary overhead. This is your projectedNetGain guard, and it reuses the same "is there effective compressible content" predicate the nudge uses to suppress.
2. Per-range once — a range enforced this session is never re-enforced.
3. enforceBudget (default 5) — hard cap on passes per session.
4. Invisible to the model — enforcement writes a neutral mechanical summary indistinguishable from a model-driven one; only the host UI is notified. No "enforced, you may refine" text, so no V3 decompress/recompress churn.
5. Cooldown — non-hard passes require cooldownGrowth × nudge.minGrowthFloor (default 5×) of new content since the last pass; the hard threshold bypasses it.

Plus two decisions worth flagging:

• Removed the same-turn gate from the first version — an agentic session is one user turn spanning many context events, so that gate limited enforcement to one fire per agentic session. The cooldown is the correct gate.
• Model-driven wins — when the model itself completes a successful compress, enforcement skips that turn (it would only stomp on the model's own work). Failed/no-op compresses do not suppress enforcement — that's exactly when it's needed.

On your fix A (bound the protected zone by tokens)

It's already satisfied: preserveRecentTokens=5000 already bounds the zone by tokens, and the bash/read outputs are already excluded from protection. So I didn't change the protection model. If you'd like, I can still do the "replay session 01a01e31 and measure" to confirm empirically — but the code says the zone is already bounded.

Follow-ups I can't do from here (offer)

• Move enforcement to an acp-kernel pipeline node (your preferred shape) — needs an acp-kernel release, which I can't cut from this repo. Happy to draft the kernel PR if you want.
• Fix the imprecise compress.ts:181 comment in acp-kernel.

Tests: 478 pass / 0 fail / 3 skipped, typecheck clean, build OK. PR #270 is updated with the guardrails: #270

[ranxianglei]

这个强制压缩实现原理是什么

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 强制压缩(enforcement)的实现原理,按数据流拆开讲:

1. 挂载点:在 context transform 里、processTurn 之后

每次 Pi 发 context 事件,src/index.ts 的 wireContextTransform 先调 runtime.core.processTurn(...)(内核产出 nudge 决策),紧接着调 maybeAutoCompress(...)。如果它返回新 turn,就替换掉 turn——这样下游的 nudge 注入、消息重建都基于压缩后的视图。整个逻辑在 src/auto-compress.ts,不改动内核。

2. 触发条件(两个,满足其一)

maybeAutoCompress 里:

• usage = tokenCount / limit
• overLimit = 内核 nudge.breakdown.overLimit===1 || emergencyOverride===1(即 usage ≥ 75% 或 ≥ 95%)
• hasContent = nudge.shouldInject===true(内核认为"确实有有效可压缩内容",否则不触发——这正是你 review 里说的"无有效内容时 nudge 被抑制"那个谓词,我复用了它)
• anySuccess = 本轮模型自己成功 compress 了 → 直接跳过(模型驱动优先,不覆盖模型自己的压缩)
• streak:overLimit 且有内容且模型没成功压缩 → +1,否则清零
• hard:usage >= hardThreshold(默认 95%)
• 触发:(hard || streak >= afterIgnores) && hasContent && usage > targetPct

3. 护栏(触发前逐道检查,任一不过就跳过)

1. 预算 fireCount >= enforceBudget(默认 5)→ 跳过
2. 冷却:非 hard 且自上次触发以来新增 token < cooldownGrowth × nudge.minGrowthFloor(默认 5×5000)→ 跳过;hard 绕过
3. 选范围 pickAutoRanges:从 nudge.compressibleRanges 里取 viable(tokens ≥ 200)的,按 token 从大到小贪心,直到 projected usage < targetPct(默认 80%)或到 maxRanges(默认 5)个
4. 净收益 范围tokens − 摘要tokens < minEnforceNetGain(默认 5000)→ 跳过(防深度压缩区间"越压越多")
5. 每范围仅一次:过滤掉本会话已强制过的范围

4. 压缩执行:复用模型驱动的入口

• buildHeuristicSummary 生成一份中性机械摘要(和模型自己 compress 产出的无法区分,不写"enforced/call decompress"字样,避免模型 decompress/recompress 抖动)
• 调 runtime.core.applyCompression({ ranges, messages, state, config }) —— 这就是模型 compress 工具用的同一个入口,所以 boundaries / reasoning-pairs / tool-pairs 那些不变量自动成立
• blocksCreated === 0 → 视为 no-op(只记录、不计入预算)
• 否则:save(state) 持久化 → 重跑 processTurn 得到压缩后的消息视图返回

5. 状态跟踪:每会话一个 AutoCompressEpisode

{ streak, fireCount, enforcedRanges: Set, lastEnforcedTokenCount },存在 runtime 的 per-session Map 里,session_start 重置、session_shutdown 清理。

一句话:内核负责"判断该不该压"(nudge 决策 + 可压缩范围),扩展负责"模型不压我就替它压"(触发 + 护栏 + 复用 applyCompression + 重渲染),全程对模型不可见、有预算和冷却,只在真正 over-limit 且模型不作为时兜底。

代码在 src/auto-compress.ts(约 300 行),测试在 tests/auto-compress.test.ts(streak / hard / 禁用 / 净收益 / 预算 / 冷却各有 e2e 用例)。

[ranxianglei]

我的意思是他怎么压缩 谁压缩 还是注入压缩吗

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 直接回答你三个问题:

谁压缩?—— 扩展的服务端代码,不是模型

强制压缩不是模型(LLM)在压。是 src/auto-compress.ts 里的代码在服务端直接压:

• 摘要文本由 buildHeuristicSummary() 生成 —— 这是机械/启发式摘要,不是 LLM 写的。它就是把范围内的原始消息按 [role/tool名] 片段 一行行拼起来(每条截 200 字符),加个中性头部。
• 真正"把消息换成块"的动作是内核的 applyCompression() 完成的。

对比一下正常路径:模型驱动压缩时,是模型自己调 compress 工具、由 LLM 写出摘要;而强制压缩时,模型根本没参与,摘要由扩展代码机械生成。

怎么压缩?—— 选范围 → 机械摘要 → 替换成块

1. 从内核给的 nudge.compressibleRanges 里挑出可压缩范围(按 token 从大到小);
2. 对每个范围用 buildHeuristicSummary() 生成机械摘要;
3. 调 applyCompression({ ranges, ... }) —— 内核把这一串原始消息在上下文里替换成一个 block(摘要 + 占位标签),并记下 effectiveMessageIds 映射,这样以后 decompress 能把原文恢复回来。

省 token 的本质:摘要比原始消息小得多,替换后上下文就变小了。

还是"注入压缩"吗?—— 不是

这里要区分两条路:

• nudge(注入):内核注入一段建议性文本,提示模型"该压缩了"。这依赖模型自己去调 compress —— 模型可以无视,这就是 issue 里的问题。
• enforcement(强制):模型连续无视 nudge 后,扩展直接替它压 —— 不等模型、不靠模型,服务端自己完成上面的"选范围→摘要→替换"。

所以强制压缩不是"注入一段压缩指令等模型执行",而是服务端直接把压缩做掉了。而且它对模型不可见:摘要写成和模型自己压的一模一样的中性样式,只通知宿主 UI,模型不知道发生了强制压缩(避免它去 decompress/recompress 抖回来)。

一句话:nudge 是"劝模型压",enforcement 是"模型不压我就替它压"——后者由扩展代码直接执行,摘要机械生成,不经过 LLM。

[ranxianglei]

是pi的压缩还是我们的compress工具在压缩

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 都不是 Pi 的原生压缩,是 acp-kernel 的压缩——也就是我们 compress 工具背后那一套。先把三层分清:

三层

1. Pi(宿主):跑 agent 循环、提供 context transform 钩子、session manager、工具注册。Pi 自己有一套原生 compaction(上下文快满时的兜底),但 ACP 不走它。
2. billion-context-pi(本扩展,就是我们):把 acp-kernel 接进 Pi,注册 compress/decompress/search_context/acp_status 工具 + nudge 注入 + 这次的强制压缩。
3. acp-kernel:真正的压缩引擎 —— processTurn(nudge 决策、token 计数)、applyCompression(把消息换成块、管状态)、block 管理。

强制压缩用的是哪一层?

用的是 acp-kernel 的 applyCompression(runtime.core.applyCompression(...),runtime.core 就是 acp-kernel 的 CompressionCore)。不是 Pi 的原生 compaction。

那和我们 compress 工具是什么关系?

同一个引擎,两个入口,区别只在"谁触发 + 摘要谁写":

	触发者	摘要谁写	底层调用
compress 工具	模型(LLM)自己调	模型(LLM)写	applyCompression(acp-kernel)
强制压缩	扩展服务端代码	扩展代码机械生成	applyCompression(acp-kernel)

两者最终都调 acp-kernel 的 applyCompression,所以产出的 block 结构、decompress 还原、boundaries/reasoning-pairs/tool-pairs 不变量完全一致。区别只是:

• compress 工具是模型面向的接口——模型调它,工具 handler 再去调 applyCompression;
• 强制压缩不调那个工具(模型没在调),扩展代码直接调 applyCompression 把压缩做掉。

所以准确说:是 acp-kernel(我们这套 ACP 压缩)在压,不是 Pi 的原生压缩;它和我们 compress 工具共用同一个 applyCompression 引擎,只是触发方和摘要来源不同。

[ranxianglei]

发送给上游的是什么?是全部文本 还是部分文本

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 发送给上游(LLM)的是部分文本——准确说是"压缩视图":未压缩的部分发完整原文,已压缩的部分只发摘要(block),不发原文。

机制

1. 会话日志(磁盘上)存的是全部消息(完整历史,一条不丢)。
2. 每次 context 事件,扩展构建"发送视图" = 会话日志里把已压缩范围替换成 block,其余保持原样。
3. 这个发送视图才发给 LLM。

所以 LLM 看到的是:

[未压缩的近期/受保护消息 —— 完整原文]
[已压缩范围 —— 每个变成一个 block:摘要 + 占位标签,原文不在此处]
[最近的几条 —— 完整原文]

关键点

• 已压缩范围的原文不会发给 LLM,只发它的摘要。这就是省 token 的来源——摘要比原文小得多。
• 未压缩范围(尤其近期、受保护的)发完整原文,模型对最近的工作有完整上下文。
• 有损但可恢复:压缩是"原文 → 摘要"的有损替换,但 block 里记了 effectiveMessageIds 映射,原文还在磁盘会话日志里,模型调 decompress 就能把某段原文完整恢复回来。
• 模型从 system prompt 知道"压缩块可以用 decompress 还原",所以它可以在需要某段细节时主动去恢复。

和前面问题的关系

无论模型驱动压缩还是强制压缩,发给上游的都是这种"压缩视图"——区别只在摘要是谁写的(模型 LLM 写 vs 扩展机械生成),block 替换原文、发送视图的机制完全一样。

一句话:上游拿到的是"近期完整 + 旧内容摘要"的压缩视图,不是全部原文;旧内容的原文留在磁盘,可 decompress 还原。

[ranxianglei]

这个不对.应该发送全部上下文.保持上下文连贯性.

所以你这个方案思想是对的,但是实现是错误的.
麻烦关闭pr重新搞.

现在应该要做的是

1.调查为啥模型在紧急时刻忽略压缩
2.如何避免这个情况
3.兜底,是,发送全部上下文,要保证99%命中cache的情况下,发生一次强制压缩.

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 收到,这个反馈很关键。我已把 PR #270 关掉(commit 都保留在分支 2026-09-01_auto-compress-enforcement 上,没丢),先确认我理解对了再重做,避免又跑偏。

我理解你的核心点

我之前跳过了根因、直接做了兜底,而且兜底用的是增量式原地压缩(把最大的可压缩范围替换成摘要 block)。这有两个问题:

1. 破坏上下文连贯性——模型看不到被压范围的原文,只剩有损摘要;
2. 破坏前缀缓存——在上下文中间替换内容 → 前缀变化 → 后续请求 cache miss、重新计费(ACP 本身就有 61k re-bill 这类前缀缓存失效的已知问题)。

所以正确顺序应该是你说的:先查根因(模型为何在紧急时刻忽略压缩)→ 再想办法避免(让模型不忽略)→ 最后才是兜底,且兜底要 cache-aware、保连贯、只压一次。我认同这个判断。

需要你确认的(尤其第 3 条,直接读有张力)

"发送全部上下文 + 99% 命中 cache + 发生一次强制压缩"——发全部上下文本身就不省 token,所以我想确认具体机制:

1. "发送全部上下文" 是指:
   • (a) 触发强制压缩的那一轮先发完整上下文(保证这轮响应连贯),然后为下一轮做压缩?还是
   • (b) 不做原地压缩,而是像 Pi 原生 compaction 那样一次性重置——把旧上下文总结成新起点,从那里继续?
2. 99% 命中 cache 怎么保证?前缀缓存吃的是开头,压最旧的消息会破坏前缀。你设想的 cache-aware 策略是什么(只在边界压 / 保留稳定前缀 / 其他)?
3. "发生一次强制压缩" = 每会话只强制压一次(不反复增量压)?

我现在就开始第 1 条

"调查为啥模型在紧急时刻忽略压缩"——我先从代码层查 nudge 的注入机制(文本内容、注入位置、何时被抑制),形成"模型为何忽略"的假设。我只能基于代码 + 日志推断,看不到模型内部推理;如果你能给 session 01a01e31 的日志片段(或指个重点段),我能查得更准。

你确认上面 1–3 的机制后我按新方向重做;第 1 条调查我现在就推进,有初步结论会贴回来。

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 第 1 条调查的初步结论(代码层,基于 nudge 注入机制 + 文本)。先说最关键的发现:

关键发现:nudge 是一条 user 消息,不是 system 指令

src/index.ts:610 的 nudgeMessage() 返回 role: "user"——nudge 被当成一条用户消息追加到上下文末尾发给模型。这有两个直接后果:

1. 它和用户的真实指令抢注意力——模型看到末尾一条"user 消息"说"该压缩了",但它真正要完成的是用户之前的任务。模型会理性地优先任务、忽略这条"看起来像用户消息"的 nudge。
2. 权重低于 system 指令——system prompt 里的指令比一条 user 消息权重高得多。nudge 用 user 消息承载,天然弱。

nudge 文本本身的问题

emergency 文本(nudge-text.ts:159)是:

⚠️ Context limit reached — compress now. Prioritize consumed tool outputs.
{compressPhilosophy}
Context breakdown: ...
{howToCompressRules}
{ "topic": "...", "content": [{ "startId": "<ID>", ... }] }
Only use IDs from visible messages above. Compress older work first.
Compressible ranges (N, oldest first): ...

它告诉模型做什么,但不告诉不做的后果——没有一句"如果不压缩,上下文会溢出、会话会被截断、你将无法继续"。模型不知道 stakes,自然不紧迫。

另外两点:

• emergency nudge 每次 LLM 调用都重注入(index.ts:360 绕过 per-turn dedup)——同一条 nudge 反复出现,模型会脱敏/当没看见(重复无变化)。
• gentle nudge(75%)明确弱化紧迫性:"This is an efficiency nudge... not an overflow warning"——直接告诉模型"这不紧急"。

模型为何忽略(假设,按可能性排序)

• H1(最可能):nudge 是 user 消息,和真实任务抢注意力 + 权重低 → 模型优先任务。
• H2:不传达后果 → 模型不知道不压缩会溢出/截断,不觉得紧迫。
• H3:反复重注入 → 脱敏 → 模型当没看见。
• H4:模型"回应"而非"执行" → 把 nudge 当要回应的 user 消息,而不是要调 compress 工具的动作。

第 2 条的初步方向(如何避免)

• P1:把 nudge 从 user 消息改成 system 指令(或 pi 支持的更高权重通道)——和真实任务分离、权重更高。需确认 pi 是否支持在 context transform 里注入 system 消息。
• P2:传达后果——加一句"不压缩 → 溢出 → 会话截断 → 无法继续",让 stakes 明确。
• P3:不反复重注入同一条,改为升级式——第一次 gentle、第二次更强、第三次 critical,避免脱敏。
• P4:给一个可直接执行的 compress 调用(现在已有 example,但可以更突出、更具体)。

我需要你提供的

session 01a01e31 的日志片段(或指个重点段)——我想看模型看到 emergency nudge 后的实际反应:是根本没理?还是回应了但没调工具?还是调了但失败?这能区分 H1/H4(没理/回应不执行)和"调了但失败"(那是另一个问题)。有日志我能把假设收敛到一两个。

第 3 条(兜底机制)等你确认上一条回复里那 3 个问题,我再动手。