通用工具重复熔断缺失:acp_status 30× 字节级相同调用死循环(贪心模型,任何工具可成环;compress 熔断器覆盖不到)

[ranxianglei]

通用工具重复熔断缺失:acp_status 30× 字节级相同调用死循环 —— 贪心模型下任何工具都可成环,compress 熔断器覆盖不到

与 #250(compress 同参失败空转,已修)互补的形态:这次是永远成功的工具的重复循环。#250 的熔断器只统计 compress 失败,对此零计数。#269(模型无视 nudge)的另一变种。

环境

• 插件:billion-context-pi 0.1.54(~/.pi/agent/npm/node_modules/billion-context-pi)
• 宿主:pi coding agent,Linux
• 模型:qwen3.8-27b-w8a16,SGLang 0.5.17(:8199),贪心解码(模型目录 generation_config.json do_sample:false, temperature:0),thinking off
• 会话:01a071dc-e334-76ea-98a9-115e48061ac9(2026-09-05 13:58 → 09-06 11:23 UTC,21.5h,1066 条消息,61 次压缩,累计压缩 414K tokens)
• 证据:~/.pi/agent/sessions/--home-dog-projects-billion-context-pi--/2026-09-05T13-58-16-628Z_01a071dc-e334-76ea-98a9-115e48061ac9.jsonl + 同名 .acp.json sidecar + ~/.pi/acp.log

现象

2026-09-06 11:03:08–11:23:08 UTC,模型进入死循环,30 轮字节级完全相同:

• thinking md5 恒定、正文 md5 恒定(30 次全部一致)
• 每轮唯一工具调用:acp_status {"scope":"uncompressed","view":"ranges"},每次输出恰好 2635 tokens,~30s/轮
• 上下文每轮净增 ~2980 tokens,57K → 130K(有效上限 131072 = 262144 − maxOutput)
• 触发时序:11:01:07 nudge 注入一次 → 11:02:22 模型 compress 成功(27.8K→6.6K,blocks b58+b59)→ 11:03:08(下一轮)立即进入循环,thinking 声称 The user says "合并了 下一个" —— 该消息在全部 1069 条原始消息和所有压缩块中均不存在(幻觉,是两句真实用户口头禅的混合;turnKey 全程未变,证明无新用户输入)
• 用户打断两次(11:16:59、11:21:18):模型道歉 + compress 一次 → 下一轮立刻复发同 think hash
• 11:15:01 emergency nudge(96%)注入也未能打破吸引子

为什么现有防线全部失效

1. compress-retry-capped 熔断器只统计 compress 失败(src/index.ts:321,小模型（本地 27B 量化）compress 循环空转：同参数重复失败 + 幻觉 ref（0.1.52 完整日志证据） #250 的修复):本循环调的是 acp_status,永远成功 → 熔断器零计数、永不触发
2. nudge 去重按 turnKey:循环期间没有新用户消息,turnKey 恒定 → 76%→96% 全程 nudge-suppressed,emergency(≥96%)才注入,太晚
3. src/tool-guardrails.ts 只有 bash 输出上限 + timeout 检测,没有任何"连续相同调用"检测
4. 保护带保护了循环自己:循环产生的 ~60 条消息全在 recent/last-user zone,打断后的 compress 显示 Excluded 42 protected message(s),回收寥寥

复发性(本机 80 个近期会话扫描,3 个中招)

会话	模型	形态
01a071dc	qwen3.8-27b	24× acp_status + 打断后 2 次复发
01a02d90	同上 27B	7× compress(#250 形态)+ 17× 相同 bash(gitlab 命令)
01a06110	qwen3.8-flash W4A16	21× 相同 bash(sleep 轮询,17 分钟)

→ 任何工具都可成为吸引子;两代 qwen3.8(27B 与 flash)都有;贪心解码是共同条件。 循环是序列级的(上下文尾部 N 个相同 (assistant,toolResult) 对自我强化),token 级 penalties(presence/frequency/repetition)对跨轮重复完全无效。

修复建议(按优先级)

1. 通用重复指纹熔断(核心,挂 src/tool-guardrails.ts)

• 指纹 = sha1(toolName + 稳定序列化(args 键排序后的 JSON))
• 会话级滑动窗口记录最近指纹
• 连续 ≥3 次相同 → 在该次 toolResult 尾部注入强警告:你已连续 N 次发出完全相同的工具调用(name+参数逐字节一致)。禁止再次发出相同调用;必须改变策略、换参数,或停止并等待用户。
• 连续 ≥5 次相同 → 拒绝执行该调用(返回错误 toolResult)+ abort 当前 turn + 终端 echo(参照现有 bash timeout 的处理路径)
• 注意:只比对参数,不看结果 —— acp_status 结果里可见消息数会微变(24→26→28),但参数相同就算命中
• 阈值可配:acp.json { "repetitionGuard": { "warn": 3, "abort": 5 } },默认开启
• tests/ 增加:连续同参调用触发 warn(3 次)、触发 abort(5 次)、参数变化即重置计数的用例

2. 熔断器泛化(src/index.ts:321 一带)

per-turn cap 除 compress 失败外,同时计入"无进展工具调用"(acp_status/decompress/search_context 反复调用且 tokenCount 无下降),达到上限同样 no-progress-capped 告警。

3. nudge 去重放宽

同一 turnKey 内,若距上次注入后上下文相对增长 >10%,允许再注入一次(仍设每档位上限,防止重蹈 #223 无限追加)。

4. 循环消息可压缩

检测到重复指纹时,将循环产生的 assistant/toolResult 消息移出保护带(或显式标记为可压缩),让用户打断后的 compress 能真正回收它们(本例 60 条 × ~3K tokens 全被保护)。

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 收到，先给结论与计划。

审核（三步都核对了代码）

1. 复现/查证：问题真实存在。逐条核对了你列的四个失效点：
   • compress-retry-capped 熔断器只统计 compress 失败 —— collectCompressOutcomes（src/index.ts:569）里 m.toolName !== "compress" 直接 continue，acp_status 等成功工具对它零计数。✓
   • nudge 去重按 turnKey —— src/index.ts:317 turnKey = lastUserMessageId(entries) ?? sid，循环中无新用户消息则恒定，非 emergency 的 nudge 只注入一次（src/index.ts:358 alreadyShown），emergency(≥96%) 才绕过。✓
   • src/tool-guardrails.ts 只有 bash 输出上限 + timeout 检测，没有任何"连续相同调用"检测。✓
   • 保护带护住循环自身 —— 与 kernel 的 recent/last-user zone 行为一致（打断后 compress 显示 Excluded 42 protected message(s)）。✓
2. 层次判断：根因是序列级吸引子——贪心解码小模型把同一个 (assistant, toolResult) 对自我强化，token 级 penalties 对跨轮重复完全无效。现有防线全针对特定失败形态（compress 失败 / bash timeout / 输出超量），没有一个检测"任意工具的字节级重复调用"。你给的方案 1（通用重复指纹熔断）打到了核心。
3. 方案评估：方案 1 直接、可测、自包含，按它实现。

计划

• ✅ 方案 1（核心）：通用重复指纹熔断，挂 src/tool-guardrails.ts。指纹 = sha1(toolName + 键排序后的稳定序列化 args)，只比对参数不看结果；连续 ≥3 → 在该 toolResult 尾部注入强警告；连续 ≥5 → 拒绝执行（block + 错误 toolResult）+ abort 当前 turn + 终端 echo。参数一变即重置。阈值可配 acp.json { "repetitionGuard": { "enabled": true, "warn": 3, "abort": 5 } }，默认开启。新增 tests（warn@3 / abort@5 / 参数变化重置 / 禁用开关）。
• ⏸ 方案 2（熔断器泛化）：被方案 1 基本覆盖——acp_status/decompress/search_context 的字节级重复调用已被通用熔断抓住；"tokenCount 无下降"是更弱的旁证信号，先不单独做。
• ⏸ 方案 3（nudge 去重放宽）、方案 4（循环消息移出保护带）：分别涉及 nudge 注入路径（曾致 压缩失败后额外每轮追加失败提示导致永远压缩循环 #223 无限追加）和 kernel 保护带，风险高，而方案 1 已能硬停循环。拆成后续 issue，避免本 PR 面过大。

稍后贴 PR。

[ranxianglei]

🤖 ework agent · qwen3.8-27b

已修复核心问题（你的建议第 1 项）。PR: #311

审核结论（先审后做）

四条失效线全部对照代码核实为真：

1. compress-retry-capped 熔断只统计 compress 失败 —— src/index.ts 的 collectCompressOutcomes 对非 compress 的 toolResult 直接跳过，acp_status 永远成功 → 零计数、永不触发 ✅
2. nudge 去重按 turnKey（最后一条用户消息 id）—— 循环期无新用户输入，turnKey 恒定 → 非 emergency nudge 全程被抑制，只有 ≥96% emergency 才注入，太晚 ✅
3. src/tool-guardrails.ts 此前只有 bash 输出上限 + timeout 检测，没有任何"连续相同调用"检测 ✅
4. 保护带把循环产生的 ~60 条消息全圈进 recent/last-user zone，打断后的 compress 回收寥寥 ✅

层次判断：这是序列级吸引子，不是 token 级重复——模型逐轮重发同一条 (工具调用→工具返回) 对，重复跨越轮次边界，所以 presence/frequency/repetition penalty 对跨轮重复完全无效；也不是"某个工具写错了"，而是任何工具都可成环（你扫出的 3 个会话里 acp_status / bash-gitlab / bash-sleep 各成一例）。现有防线（#250 熔断、nudge 去重）针对的是另两类故障形态，对"永远成功的工具死循环"本就覆盖不到——不是它们有 bug，是缺一条通用防线。

方案：挂 src/tool-guardrails.ts 的通用连续调用指纹守卫

• 指纹 = sha1(toolName + 键排序 canonical JSON(args))，只比参数不比结果（结果里可见消息数 24→26→28 微变不影响命中）
• 会话内跟踪连续相同次数：达 warn(默认 3) 在该 toolResult 尾部追加强警告；达 abort(默认 5) 拦截该调用不执行 + 中止本轮 + 终端通知
• 参数变化 / 换工具 / 真实用户消息重置计数（扩展自发消息不重置）
• 配置 acp.json { "repetitionGuard": { enabled, warn, abort } }，默认开启，abort 自动钳制到 > warn

为何选它：字节级参数一致是唯一能可靠识别该循环的信号。warn 是软提示（对无视 nudge 的模型可能无效），abort 是硬熔断（保证打断），两级正好覆盖"先劝、劝不住就断"。

未纳入本 PR（有意拆出）

• release: v0.1.1 — version display, dev standards, CI #2 熔断泛化：基本被 fix: reconstruct parallel tool-call assistant message from split core messages #1 覆盖（通用守卫已能抓 acp_status/decompress/search_context 的同参重复），额外"tokenCount 不降"信号更弱、收益有限
• fix: release workflow grep lookbehind error #3 nudge 去重放宽：动的是当年引发 压缩失败后额外每轮追加失败提示导致永远压缩循环 #223（瞬态无限追加）的同一段注入路径，风险高，且 fix: reconstruct parallel tool-call assistant message from split core messages #1 已硬中断后必要性下降
• release: v0.1.2 — CI release test #4 循环消息移出保护带：属 kernel 侧保护带改动，复杂度/风险都高

需要的话我可以给这三项各开一个 follow-up issue。

测试：+22 用例，全套 484 pass / 0 fail（连跑多次稳定）。覆盖指纹纯函数、tracker 升级/重置、接线层 warn@3 不拦 / abort@5 拦截并中止 / 换参重置 / 用户消息重置而扩展消息不重置 / repetitionGuard:false 全关 / 自定义阈值。CONFIGURATION(.zh-CN).md + CHANGELOG.md 已同步。

小观察（仅报告，非本 PR 引入）：delegate/timer 相关有个别用实时计时器的用例偶发抖动（某次跑挂了 2 个，随后 4 次连跑全绿）；本次新增用例全是纯同步、无定时器，与该抖动无关。