KEEP_LAST_ORPHANED orphan-hiding 吞掉可操作的 compress 拒绝诊断(#330 factor 3)

[ranxianglei]

来源: ranxianglei/billion-context-pi#331 分析 ranxianglei/billion-context-pi#330 01a07b3c 压缩循环语义级复发)时发现 —— PR #331 判定本项 "By-design kernel orphan-hiding; changing it risks context bloat",Deferred → follow-up,但截至 09-08 未见已立 issue,故补立。

现象

#330 时间线:call B/C/D 各自收到 exactly-once 拒绝诊断(内含正确的剩余 range 诊断 m00597–m00630 / m00643–m00655 + 快照)。到用户介入轮(01:56:13)重建模型实际所见,这些诊断已全部被 orphan-hiding(KEEP_LAST_ORPHANED=2)隐藏,只剩无路可走的 PAUSED 文本——最具行动价值的自纠抓手恰是被藏掉的部分。

张力

orphan-hiding 是 by-design(防上下文膨胀),直接放宽常量有 bloat 风险。需要设计讨论而非改数字。候选方向:

1. 对"含剩余 ranges 的可操作拒绝诊断"豁免 orphan-hiding(每类保留最近一条);
2. 用户介入轮检测到本轮存在失败/悬空 compress 时,重新 surface 最后一条 actionable 诊断;
3. acp_status 输出固定携带"最近一次 compress 拒绝原因 + 正确 ranges"字段,让模型总有抓手。

Impact

低 temp 吸引子场景下模型失去自纠通道,只能依赖 adapter 侧 input-side signals(bcp PR #331)。

优先级:P1(源自 #330 fix table)

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷

查重

无重复。按 keyword(orphan hiding / KEEP_LAST_ORPHANED / compress rejection diagnostic)检索 tracker 无命中;关联的 #221 是 factor 4b(nudge targetBlocks 一致性),主题不同。

验证(机制核实,基于 master @ 04bd5ed)

• 复现链确认:01a07b3c 中 call A 成功(b36–b41),B–F 全部是 orphan(无 block)。src/hide-consumed.ts:11 KEEP_LAST_ORPHANED=2,:72-79 从消息尾部反向扫描只保留最近 2 个 orphan compress call+result 对 → 01:56:13 用户介入时只剩 E(adapter 侧 PAUSED 文本)+ F(悬空)可见,B/C/D 的 actionable 诊断被隐藏。与 issue 描述一致 ✓
• 层次判断:这是载体/可见性问题,不是生成问题。kernel 侧诊断本身完整且 exactly-once:src/compress.ts applyCompression 的 minCompressRange gate(:276-346)各变体已含 "Run acp_status … CURRENT compressible ranges",applySingleRange(:854)同样自带 acp_status 指引。被吞掉的是诊断所在的 tool-result 历史——它恰好落在 eviction zone 里。所以修法是"让最近一次可操作拒绝持久可见",而不是"全局多留几个 orphan"。
• 为何不直接放宽常量:src/hide-consumed.ts:3-10 注释引用了 bcp#9(KEEP_LAST_ORPHANED=0 下 3,849 次相同调用、5h13m 固定点)。2→4 能救那个 session,但救不了长循环(fix: defaultCountTokens no longer drops digits/symbols to zero #9 场景下前 3845 次仍全隐藏),且每多留一对,后续每一轮都付 token 成本。定向豁免 > 全局放宽。

候选方向评估

方向 1(豁免 actionable 诊断,每类保留一条)— 方向正确,但需要一个关键修正:
"actionable" 判定不能靠解析 result 文本:adapter 会包装/截断 kernel 错误("▣ ACP | …"),PAUSED/cap 文本更是 adapter 侧生成的,内核无法可靠分类自由文本。稳健变体是状态结构化关联——内核本来就知道哪次 tool-call 产生了拒绝:CompressRangeSpec.compressCallId(src/types.ts:190,由 parse-compress-input.ts:236 / compress-tools.ts:121 写入,block 落库走 compress.ts:889)。具体:

1. CompressionState 加可选字段 lastCompressionFailure?: { callId: string; reason: string }(同 absorbed? 模式,旧持久化状态向后兼容,rebuild/fork 恢复默认 undefined);
2. applyCompression 在 blocksCreated===0 && errors.length>0 时记录(reason 取第一条 error),成功时清除;
3. hideConsumedCompressCalls 把该 callId 并入 keepCallIds(:81)→ 对应 call+result 对保持可见。

已验证无副作用:rewriteCompressText 只对有 live block 的调用改写参数(hide-consumed.ts:120 liveKeys.size > 0 条件),orphan 调用原样保留——被豁免的对会完整显示"原始请求参数 + 拒绝诊断"。边界情况都优雅退化:exempted 消息若已被 emergency truncate 裁掉 → 豁免 no-op;host 未传 callId → 退化到现状。

• 有界成本:最多比现状多 +1 对,且仅在"失败未闭环"期间存在;下一次拒绝覆盖它、任何一次成功清除它,不累积。
• "每类保留一条"不必要:观测到的循环里所有失败同类,且更旧诊断里的 ranges 本来就是过期的(更新的拒绝携带更新 ranges)。single-latest 足够。
• 在 01a07b3c 的效果:D 的诊断(含正确剩余 ranges)在用户介入轮与 E/F 一起保持可见。即使 adapter guardrail 短路 E/F 不走 kernel,lastCompressionFailure 仍指向 D 的信息直到成功闭环——两种 adapter 行为下都成立。

方向 2(用户介入轮重新 surface)— 最弱,不推荐。 内核目前没有跨轮失败计数(那是 bcp runtime.ts 的 guardrail 状态),需要新增注入面(synthetic message/nudge slot),内容与历史重复,且时机依赖(只在用户轮生效;循环内场景已被 bcp PR #331 的 [ACP:reject] sentinel 覆盖)。更多活动部件,更少结构价值。

方向 3(acp_status 固定字段)— 便宜且互补,但单独不够。 它是被动通道:模型得主动调 acp_status 才有抓手,而低 temp 吸引子下恰恰不会调(01a07b3c 五轮循环 thinking 零引用任何失败反馈)。另外 status 已经 live 计算 compressible ranges(report.ts renderUncompressedRanges),真正新增的信息只有拒绝原因一项。作为兜底行可以,作为主修复不行。

建议(待拍板)

主修复 = 方向 1 的状态化变体,三处小改动:types.ts 字段 + applyCompression 记录/清除 + hide-consumed.ts 豁免。有界(+1 对)、定向、直接补上 01a07b3c 的洞,同时保住 #9 确立的"residue 有界"不变量。
可选配套(同 PR 或 follow-up):buildStatusReport overview(report.ts renderOverview)加一行 Last compress rejection: <reason>,覆盖被豁免对被 truncate/fork 恢复丢失的边角。
方向 2 放弃;放宽常量放弃。

你确认后我实现 + 测试(node --test,纯函数测试),开 PR。