nudge targetBlocks 与 acp_status 块列表一致性核查(#330 factor 4b,疑似 kernel 侧)

[ranxianglei]

来源: ranxianglei/billion-context-pi#331 分析 ranxianglei/billion-context-pi#330 01a07b3c 压缩循环语义级复发)时发现 —— PR #331 将本项列为 follow-up("suspected acp-kernel side"),但截至 09-08 未见已立 issue,故补立。

现象

session 01a07b3c 中,模型历史回复大量以"Nudge 列表再次与实际不符(活跃 T1 仅 b31/b32),跳过"开头——nudge 注入所引用的 targetBlocks 与 acp_status 展示的块列表不一致,且重复发生。两者理论上应出自同一数据源。

Why it matters

信任崩塌可能是后续连工具反馈都不信的起点:#330 中 5 轮循环的 thinking 零引用任何失败反馈。若 nudge 持续引用与实际不符的块,模型会学会跳过 nudge,削弱整个 pressure-band 机制。

建议排查

• 复现路径:nudge 注入时刻同时 dump targetBlocks 与同刻 status report 的块列表,逐条 diff,找出不一致的具体形态(旧块?缺块?编号错位?)
• 检查 nudge 决策与 status report 是否共享同一 blocks 快照,还是各自独立计算产生时序漂移(如 nudge 用旧快照、status 用新状态)
• 确认后修复:统一数据源,或在 nudge 文本生成时按当前活跃块过滤 targetBlocks

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

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 核查完成 —— 已定位到 kernel 侧的具体形态并修复:不是时序漂移,而是 status 侧的静默截断。PR: #222

验证了什么(代码级证据)

1. "同一数据源"假设成立 —— nudge 与 status 没有快照漂移。

• pipeline 顺序(src/compress.ts:466-481):syncBlocksNode → … → recommendNode → nudgeNode,nudge 决策在与 sync 之后的同一个 io.state 上计算;adapter 随后对 result.state 调 buildStatusReport,是同一个状态对象。
• decideNudge → pendingByTier(src/compress.ts:1095-1126)的 targetBlocks = activeBlocks(state).filter(tier === N);而 buildStatusReport(src/report.ts:125-127)用的是完全相同的谓词 state.blocks.filter(b => b.active)。activeBlocks 定义在 src/state.ts:41-43。

2. 不一致的真实形态:静默截断 + 排序错位。

• nudge 的 tier 目标列表 无上限,逐个列出全部活跃低层块(formatTierTargetBlocks,src/nudge-text.ts:39-49)。
• acp_status overview 的块列表 默认上限 30 条、按原始大小降序、跨 tier 混排(sorted.slice(0, limit),src/report.ts:201),且静默截断——没有 "...and N more" 行(另外两个 view 都有此提示)。头部数字仍是全量("N active"),所以模型看到的是"总数对得上、但列表里找不到 nudge 点名的块"。
• 这正好复现 01a07b3c:nudge 点名 b31..b41 共 11 个 T1 目标,而 41 块的 session 里 size-sorted top-30 中可见 T1 只有 b31/b32 → 模型判定"nudge 与实际不符",跳过蒸馏 → T1 继续堆积 → 下一轮 nudge 再触发。自增强循环:T2/T3 蒸馏 nudge 的触发条件本身就是低层块堆积超过 threshold,即活跃块数必然偏大,静默截断在 nudge 触发时几乎必然发生。

3. 回归测试先红后绿:fixture 按 01a07b3c 形态构造(41 活跃 = 35 T1 + 6 T2),修复前两个断言失败(列表确实静默丢了 11 个块),修复后全绿。

层次判断

issue 建议的两个方向都是 no-op:"统一数据源"——已经是统一的;"按当前活跃块过滤 targetBlocks"——pendingByTier 已经只含活跃块。病因不在数据流,在 status 渲染层:一个有上限、跨 tier 混排、且静默截断的视图,去对照一个无上限的单 tier 权威列表。跨 turn 的 nudge 文本过期是固有行为(nudge 是注入时刻的指令,apply 侧已有 stale-ref 拒绝兜底),不是复发主因。

修复(PR #222,最小改动,仅 src/report.ts +12/-1)

1. renderOverview 截断时显式声明:... and N more blocks not shown (scope:"compressed", limit:M for full list) —— 与另两个 view 对齐,模型能算出 shown + hidden == total,不再把"看不见"读成"不存在"。
2. tierBreakdown 增加每 tier 块计数(token 总量旁):T1: 12.3K (35 blocks) | T2: 45K (6 blocks) —— 即使个别行被 size-sort 藏掉,nudge 里的目标计数也能被直接核对。

未动 nudge 文本本身:它列出的就是完整权威目标集,加上 HOW TO COMPRESS 规则已足够执行;问题只是 status 侧让模型误以为它错了。(若后续想让 nudge 自带一句"本列表为完整权威集",属 prompt 文案层面,可另议。)

验证

• 新增 tests/report-truncation.test.ts(3 个测试,含"不截断时不误报"的控制组);全量 583 pass / 0 fail;tsc --noEmit 干净;build OK。
• 未改 version,commit 只含 src/report.ts + 新测试文件。

合并按惯例由人工操作。bcp#330 中"模型学会跳过 nudge"的信任崩塌,预期随本次修复消除误报源头;#331 的输入侧 counter-signal 与本修复正交,可叠加生效。