默认拦截行为优化

[dust-to-dust]

dangerous 参数似乎并没有实际的作用，模型每次调用都携带dangerous = true；
acknowledgeRisk 参数的拦截的唯一结果就是模型去掉acknowledgeRisk参数再调用一次压缩；
是否考虑移除这两个参数？

建议让模型可以批量指定目标块而不是串行调用

此外，readme里的配置和实际代码出入很大，能否更新一下(qualityGate 无法指定算法/logLevel 无效/maxContextLimit minContextLimit 默认值不一样)

[dust-to-dust]

不对，已经是批量指定目标块了，忽略第二点

[ranxianglei]

ework 你参考 billion-context-pi 看是不是 acp 设计上的问题或者 bug

[ranxianglei]

对比了 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}