[P2] 同参失败 ≥2 次后从 tools 列表临时移除 compress(#330 follow-up,可行性 TBD)

[ranxianglei]

来源: #331 分析 #330(压缩循环语义级复发,session 01a07b3c)时发现 —— PR #331 的 "Not addressed here" 列出本项并称 "follow-ups filed separately",但截至 09-08 两仓库均未见对应 issue,故补立。

背景

#330 循环末(call F,空参数 {}):现有 tool-side 熔断器(#6/#250/#308)只能拒绝执行、暂停 nudge,挡不住低 temp 吸引子下的模型继续生成 ~10K-token 的重复 compress turn。PR #331 已补 input-side counter-signals(首轮失败即抑制 nudge + [ACP:compress-loop] user-role 纠正消息),但 compress 本身始终留在 tools 列表里,模型仍可反复调用。

建议

同一 user turn 内同参 compress 失败 ≥2 次后,从当轮 tools 列表临时移除 compress(温和于硬拒绝;下条用户消息恢复)。

Open question(可行性 TBD)

Pi(host @earendil-works/pi-coding-agent)ExtensionAPI 的工具注册发生在 setup 阶段,mid-session 动态增删工具的 API 支持情况未核实。需先查 host API;若不支持,则维持现状(PR #331 的 input-side signals 已是当前可行边界)。

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

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 收到。已做重复筛查(两仓库按 "compress / tools list / dynamic" 等关键词检索):现有相关条目仅 #330(fix table P2 行)、#331(input-side 修复)、#278/#251(同参熔断,已修),无重复,本 issue 独立成立。

本项属功能类,按规范先评估可行性再动手——核心 open question 是 Pi host(@earendil-works/pi-coding-agent)ExtensionAPI 是否支持 mid-session 动态增删工具。正在核实 host API(拉 devDependency 源码检查 pi.registerTool 的运行时行为与是否有 unregister/setTools 一类的接口),结论出来后会带可行性判定 + 方案对比回复,由你拍板后再实现。

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

[bot] 🏷 可行性核实完毕:Pi host 支持 mid-session 动态增删工具,本项可行。 结论基于 pinned devDependency @earendil-works/pi-coding-agent@0.83.0 的源码与官方文档逐条验证(非猜测):

证据链(0.83.0)

1. API 存在且文档明示运行时可用:docs/extensions.md — "pi.registerTool() works both during extension load and after startup... New tools are refreshed immediately in the same session",并明确 "Use pi.setActiveTools() to enable or disable tools (including dynamically added tools) at runtime";配套 pi.getActiveTools(): string[]、pi.getAllTools(),官方示例 examples/extensions/dynamic-tools.ts。
2. 实现语义(dist/core/agent-session.js:631 setActiveToolsByName):只接受 registry 内工具名(未知名静默忽略,安全);设置 agent.state.tools 后同步重建 system prompt——即 "Available tools" 段也会摘掉 compress,等于额外多一条输入侧信号(模型不仅调不了,还"看不见");docstring 注明 "Changes take effect on the next agent turn"。
3. 当轮生效机制(agent-session.js:262 _installAgentNextTurnRefresh):host 对每次 agent-loop 迭代都通过 prepareNextTurnWithContext 重新快照 context.tools = this.agent.state.tools.slice()——所以同一 user turn 内禁用后,下一次 LLM 请求(同轮的第 N+1 次迭代)就不再携带 compress。正是本 issue 要的"从当轮 tools 列表临时移除"。
4. 兜底安全(pi-agent-core/dist/agent-loop.js:398 prepareToolCall):若模型在吸引子下仍生成 compress 调用(tool 已不在列表),loop 直接返回 error toolResult Tool compress not found(isError=true),不崩溃、不执行——比现在 ~10K-token 的重复生成便宜得多。

建议实现方案

• 触发点:复用现有 per-turn 计数——src/index.ts:414 的 context handler 里 runtime.noteCompressOutcomes(turnKey, ...) 已在算每轮失败数;新增阈值常量 COMPRESS_DISABLE_THRESHOLD = 2,outcome.count >= 2 且本轮未禁时执行 pi.setActiveTools(pi.getActiveTools().filter(n => n !== "compress")),记录 disabledTurnKey。
• 恢复:同一个 context handler 里,若 disabledTurnKey && turnKey !== disabledTurnKey(出现新的用户消息边界)→ setActiveTools 加回 compress 并清标记;session_start 兜底重置一次。turnKey 复用现有 lastUserMessageId(entries) ?? sid(src/index.ts:401),与 nudge 抑制/retry cap 的换轮自清语义完全一致。
• 只移除 compress,保留 decompress/search_context/acp_status——压缩循环语义级复发(temp0.1 在役):abort 悬空 toolCall 残留 + PAUSED 无自愈信息 + 中途 nudge 注入(01a07b3c) #330 P0 的自愈路径("正确剩余 ranges … 或先跑 acp_status")依赖它们在场,这也正是"温和于硬拒绝"的体现。
• 与现有熔断的层次关系:禁用发生在第 2 次失败,早于硬拒 cap(第 3 次,MAX_COMPRESS_ATTEMPTS=3);cap 保留作 backstop(覆盖失败 2 的结果落盘到下次请求快照之间的窗口,以及吸引子残留调用走 "Tool not found" 的路径)。与 PR fix: break semantic-level compress loops at low temp (#330) #331 的 [ACP:compress-loop] 纠正消息互补:纠正消息管"告诉模型停",本项管"结构上让它停不下来"。
• 测试:runtime 标志状态机单测 + 走真实 context handler 的端到端(mock pi.getActiveTools/setActiveTools,现有 nudge 注入测试已有同款 harness)。

一个待你拍板的设计点

issue 标题写"同参失败 ≥2",但现有计数器统计的是当轮任意失败/no-op 压缩次数,不是严格同参哈希。两个选项:

• (a) 当轮失败总数 ≥2 即禁(推荐):零新增状态,直接复用 noteCompressOutcomes;吸引子循环里失败本来就是同参重复,而即使两次失败针对不同 range,也说明该模型本轮压缩能力已不可信,继续烧 token 尝试不值得——反正下条用户消息全量恢复,误伤窗口 ≤ 一轮。
• (b) 严格同参:需按轮维护 args 归一化哈希表,更精确但多一套状态,收益边际(吸引子场景 (a)(b) 行为相同)。

我倾向 (a)。

排序依赖

PR #331(未合并)与本项改的是 src/index.ts 同一片区域(nudge 抑制/compress-loop 纠正),建议在 #331 合并后基于 master 实现,避免冲突返工;若你想并行,我可以先开分支但 CI 会等 #331。

方案如上,确认 (a)/(b) 与排序后我就开工。