Default Interception Behavior Optimization | 默认拦截行为优化 #339

Activity

1. dust-to-dust commented on Aug 27, 2026

   

   dust-to-dust

   on Aug 27, 2026

   Author

   More actions

   不对，已经是批量指定目标块了，忽略第二点
2. ranxianglei commented on Aug 27, 2026

   

   ranxianglei

   on Aug 27, 2026

   Owner

   More actions

   ework 你参考 billion-context-pi 看是不是 acp 设计上的问题或者 bug
3. ranxianglei commented on Aug 27, 2026

   

   ranxianglei

   on Aug 27, 2026

   Owner

   More actions

   对比了 billion-context-pi（共享内核 acp-kernel）的源码，结论：dangerous 是 bug（清理不彻底的残留），acknowledgeRisk 是设计问题（ACP 特有机制，内核没有对应物）。

   1. dangerous — bug，不是设计问题

   v1.14.3（devlog 2026-07-27_soften-protected-zone）把 checkProtectedRange 硬拒绝改成了软过滤 filterProtectedRecentMessages（lib/compress/range.ts:154），当时 REQ 明确写了：

   dangerous parameter becomes a no-op: No hard-reject to bypass. Stays in schema for backward compat.

   但清理只做了一半，留下三处残留：

   1. 工具 schema 仍声明该参数，描述还是现在时（"Required when a range includes the tail of the conversation"）— lib/compress/range.ts:87-92
   2. nudge 文本仍在教模型传它："⚠️ NOT recommended unless you are certain. If you MUST compress this, pass dangerous: true." — lib/messages/inject/utils.ts:909, 978
   3. checkProtectedRange 成了死代码（全仓库无任何调用点，测试也没有）— lib/compress/pipeline.ts:420-454

   这就是"模型每次调用都带 dangerous=true"的直接原因：nudge 每轮都在指示它传，而参数实际什么都不做。

   billion-context-pi 侧（acp-kernel）已经处理干净了：

   • COMPRESS_TOOL schema（acp-kernel/src/compress-tools.ts:33-71）没有 dangerous 参数，只有 topic / content / summaryMaxChars
   • nudge 文本（acp-kernel/src/nudge-text.ts:111）只说 "⚠️ NOT recommended unless you are certain."，不指示模型传任何参数
   • dangerous 只作为 recommended range 的内部标记（尾部段标识，acp-kernel/src/recommend.ts:301），不暴露给模型

   修复方向：从工具 schema 移除 dangerous、nudge 文本删掉 "pass dangerous: true" 指示、删除 checkProtectedRange 死代码。与内核设计对齐，风险很低。

   2. acknowledgeRisk — 设计问题，不是 bug

   这个参数属于 ACP 的 pre-commit quality gate（config.qualityGate，默认 enabled: false，算法 rouge-recall-v1，现位于共享包 context-compress-algorithms）。acp-kernel 里完全没有对应机制（源码中无任何 ROUGE/quality gate）——pi 侧 compress 直接 apply，问题以 warnings 形式出现在结果面板里，所以这类摩擦在 pi 侧根本不存在。

   参数本身不是 bug——它是"摘要其实没问题但 gate 持续拒绝"时唯一的逃生口，直接删掉的话 gate 一旦误判，模型会陷进无法退出的拒绝循环。问题在于交互设计：

   • 拒绝消息（lib/compress/quality-gate/rejection.ts:70-72）要求模型做两件事：重写摘要 并且 加 acknowledgeRisk: true，还写着 "Without acknowledgeRisk: true, the compression will be rejected again" —— 这句其实有误导性：重写后的摘要如果过了 gate，不带 flag 也会被接受。
   • 所以观察到的行为（模型去掉参数重试）反而是正确路径：重写 → 重试 → 过 gate。flag 基本没被用到。
   • flag 的状态语义（仅 qualityGateRetryPending 时有效，lib/compress/range.ts:313-327）之前已经引发过 compress acknowledgeRisk failed #301/fix(compress): make preemptive acknowledgeRisk a no-op instead of an error [stable] #303 —— 代码注释原话是 "the model routinely carries acknowledgeRisk over from non-quality errors"。

   修复选项（按推荐顺序）：

   a. 改拒绝消息：只说"重写更完整的摘要后重试"（gate 会自动重新评估），acknowledgeRisk 降级为"同一范围连续被拒 2 次后的最后手段"
   b. 加 advisory 模式（拒绝改为警告，压缩照常执行）—— AGENTS.md 里 quality gate 一直描述为 "non-blocking, pluggable"，但 pre-commit 检查实际是 blocking 的，这里文档和行为也不一致
   c. 同一范围连续 N 次拒绝后系统自动 bypass（由系统决策，不依赖模型传参）

   3. README 配置出入（OP 第三点）

   快速核对了一下：

   • maxContextLimit/minContextLimit 默认值：README 写 "55%"/"45%"（README.md:327-331），代码默认是 两个都是 "80%"（lib/config.ts:199-200）—— 确认有出入
   • qualityGate.algorithm：合并逻辑本身是对的（lib/config.ts:475），README 也有文档（README.md:205-209）。但有一个真实的坑：algorithms 映射是浅合并（lib/config.ts:476），部分覆盖 algorithms["rouge-recall-v1"] 会丢掉其余默认阈值。如果你遇到"无法指定算法"，方便贴一下你的配置文件吗？
   • logLevel：代码里是接通的（index.ts:42 new Logger(config.debug, config.debug ? "debug" : config.logLevel)，lib/config.ts:505 合并），从代码看不应该无效，也需要你的配置来定位

   总结：dangerous 可以直接移除（内核已验证过这个方向）；acknowledgeRisk 建议保留参数、修交互（拒绝消息 + advisory 模式），不建议直接删。需要的话我可以起一个 PR 处理第 1 点和 README 默认值。

   _{🤖 ework agent · vllm-qwen/qwen3.8-27b}
4. ranxianglei

   changed the title [-]默认拦截行为优化[/-] [+]Default Interception Behavior Optimization | 默认拦截行为优化[/+] on Oct 16, 2026