Repository navigation
decision request: #4521 Compression boundary status line (statusLine) injected into the wire after crossing the threshol | decision request: #4521 压缩边界状态行(statusLine)在 plugin 模式跨阈值后注入 wire——PR #5253 未披露,需拍板门控或文档化 #5350
Description
来源: #5341 (v0.1.209→master 全窗回归审查空载体 PR) 分析 全窗回归审查(v0.1.209 → master,451 commits / 324 files)时发现
查重: 无(按 statusLine / plugin mode boundary line / dshTimeContextPath 检索 open+closed issue 与 PR,无同机制条目)
发现 1(需拍板):#4521 statusLine 边界行在 plugin 模式(dsh/opencode/pi/omp 车道)跨压缩阈值后注入 wire,PR #5253 未披露
现象:plugin 模式会话跨过压缩阈值(tier !== null)后,每个 nudge cadence 未投放横幅的回合,wire 尾部会被注入一条 ephemeral user 消息:
[ACP status: highest allocated ref mNNNNN — refs above it are not minted yet, never guess them; compressible now: ...]
机制链(origin/master 485c5ea 逐行核实):
kernel/src/compress.ts:937-961:nudge plan 存在 && !shouldInject && (tier !== null || bannerShown) && ranges > 0 → 产出 statusLine;kernel 注释自述 "hosts append it as an ephemeral trailing user message (same carrier as the nudge, same cache safety)"。src/server/prepare-anthropic.ts:569/prepare-openai.ts:435/prepare-google.ts:378/prepare-responses.ts:556:四条 lane 均为if (turn.statusLine)无条件追加,没有 compressSurfaceOn/pluginMode 门。- plugin 模式下
compressSurfaceOn恒 false(src/server/lane-decisions.ts:279,compressReachable = !input.pluginMode || declaredTools.has("compress") || ...),nudge 横幅永不投放 → bannerShown 恒 false,但 tier 跨阈值后恒非 null → statusLine 每回合产出并被注入。 - PR [PR] Compression always failing and requiring many retries? Changed collapsed/protected region intervals to successful no-op | 压缩总是失败要重试很多次?已折叠/保护区区间改为成功 no-op 收据,并刷新 armed-but-silent 窗口的 ref 指针 (#4521) #5253 正文只说"四条 lane",未提 plugin mode;KDD#7 的原则是 plugin 模式代理抑制 tool+nudge 注入、agent 视图不渲染 kernel 产物。kernel 侧测试(issue4521-retry-livelock)只钉了 emit 条件,无 plugin-mode 负例。
影响评估:advisory-only(纯提示,不改任何执行路径);缓存安全(trailing ephemeral,不入客户端历史,前缀不分叉);不改压缩所有权(agent 仍本地执行 compress)。大概率无害甚至有益(plugin agent 少猜号),但属「修 A 顺带改变 plugin 模式语义」的高危模式且未在 PR 披露——需要你定性。
选项:
- A 加门:四条 prepare lane 的 statusLine 注入改走
compressSurfaceOn(plugin 模式静默)。代价:plugin agent 失去 ref 刷新提示(回到 Compression conflict banner (bili v0.1.205, node v24.19.0, win32-x64) #4521 要修的猜号问题;不过 plugin 车道 agent 自己持有账本视图,猜号面本来就小);约 4 行改动 + 负例测试。 - B 文档化:确认 statusLine 是有意的跨模式 advisory,KDD#7 / TECHNICAL-NOTES 补一句 + [PR] Compression always failing and requiring many retries? Changed collapsed/protected region intervals to successful no-op | 压缩总是失败要重试很多次?已折叠/保护区区间改为成功 no-op 收据,并刷新 armed-but-silent 窗口的 ref 指针 (#4521) #5253 披露补记;零代码改动。
- 推荐 B:行为本身良性且与 nudge 同载体、同缓存语义;若后续观察到 plugin 宿主(dsh/opencode/pi)对尾部 user 消息敏感,再走 A。
发现 2(p3,一行可修):dshTimeContextPath 注释与代码事实不符
src/durable-message-guards.ts 中 dshTimeContextPath 的 doc comment 声称该前缀 "stays OUT of dshDurableToolPath",但代码实际把它加进了 dshDurableToolPath(?? dshTimeContextPath(msg))。它返回的是 oneshot/* 路径,不命中 durable/* 保护模式,功能安全——纯注释与代码不符。一行注释修复,随本 issue 或任何触及该文件的 PR 顺手修即可。
Activity
[-]decision request: #4521 压缩边界状态行(statusLine)在 plugin 模式跨阈值后注入 wire——PR #5253 未披露,需拍板门控或文档化[/-][+]decision request: #4521 Compression boundary status line (statusLine) injected into the wire after crossing the threshol | decision request: #4521 压缩边界状态行(statusLine)在 plugin 模式跨阈值后注入 wire——PR #5253 未披露,需拍板门控或文档化[/+]ranxianglei commentedon Oct 31, 2026
(ai: vllm-qwen/qwen3.8-27b)
查重:不重复。按
statusLine/ plugin-mode boundary line /dshTimeContextPath在 open+closed issue 与 PR 复核(含近期 7 天),无同机制条目;与本 issue 自带的「查重:无」一致。标签:
bug(暂定——发现 1 属未披露的行为漂移,若你拍板 B/有意则摘掉)+dshopencodepiomp(四条受影响的 plugin 车道)+scope/wiring(请求管道 / wire 注入,nudge 家族)+p3(advisory-only、缓存安全、无执行影响)。独立复核(origin/master f9cec9f 逐处核实,比 issue 引用的 485c5ea 新;没照抄原分析):
发现 1 —— 机制成立,四处代码全对上:
kernel/src/compress.ts:937–961,条件if (nudge && !nudge.shouldInject && (nudge.tier !== null || bannerShown) && ranges > 0)→ 产出[ACP status: highest allocated ref … never guess them; compressible now: …];注释自述「hosts append it as an ephemeral trailing user message」。src/server/prepare-anthropic.ts:569、prepare-openai.ts:435、prepare-google.ts:378、prepare-responses.ts:556,全是裸if (turn.statusLine)。prepare-anthropic.ts:407nudge 横幅由nudgeEligible = … && laneDecisions.compressSurfaceOn && …门控,statusLine(:569)不受该门约束。plugin 模式无 compress 工具时compressSurfaceOn=false(lane-decisions.ts:~279),横幅恒抑制 → bannerShown 恒 false,但 tier 跨阈值后恒非 null → statusLine 每个 armed-but-silent 回合漏出。kernel/tests/issue4521-retry-livelock.test.ts:169只钉了 shouldInject=true→无行 / false→出行(且 kernel 层本就不感知 pluginMode);host 侧无任何 prepare lane 的 plugin/proxy 负例(auto-restart/graceful-close/mitm/ws-upgrade 里的statusLine是 HTTP CONNECT 响应行,无关)。发现 2 —— 注释确与代码不符,纯文档问题:
dshTimeContextPathdoc comment 声称「stays OUT of dshDurableToolPath」,但dshDurableToolPath(src/durable-message-guards.ts:246)实际?? dshTimeContextPath(msg)(:252)纳入了它。功能安全——它返回oneshot/time-context,misswithDurableProtection加的durable/*latest-per-identity 保护,所以确实可折叠/不被 pin。已在 PR #5353 修好(comment-only,零行为变更,已推 CI):#5353下面是发现 1 的决策部分(八问体例):
1. 是什么问题:plugin 模式(dsh/opencode/pi/omp)会话跨过压缩阈值后,每个未投放 nudge 横幅的回合,wire 尾部被塞一条
[ACP status: highest allocated ref mNNNNN …]proxy 生成的压缩 advisory——#5253 加四条 lane 时没披露它会进 plugin 车道。2. 什么原因导致的:根因是 #5253 把 statusLine 注入铺到四条 prepare lane 时,漏给 statusLine 上 nudge 横幅已有的
compressSurfaceOn门——nudge 被门控抑制了,它这个"兄弟产物"没被同一道门管住,于是 plugin 模式漏出。属「修 #4521 顺带改了 plugin 模式 wire 语义」且未在 PR 披露的高危模式。3. 影响范围与严重程度(按选项):
4. 怎么修复的(推荐 A 的思路):让 statusLine 复用每条 lane 已有的"压缩面是否激活"信号(nudge 横幅用的那道门),使两者按构造不可能再分叉。最小形态各 lane 一处
if (turn.statusLine && <surface-on>);proxy 模式完全不变,plugin 模式(surface off)静默。配一条 host 侧负例测试(plugin 模式跨阈值 → statusLine 不进 wire),保留现有 kernel emit 正例。约 4–8 行 + 1 个负例测试。5. 是否有回归风险(按选项):
6. 是否破坏缓存:两选项都不破坏。statusLine 是 trailing ephemeral(追加在缓存前缀之后),不入客户端历史、不分叉前缀、不入持久化——与 nudge 同载体同缓存语义。A 只是少追一条尾行,前缀更短更稳。
7. 是否改设计方向:A 回归 KDD#7 既有方向(plugin 模式 proxy 不出压缩 advisory/tool/acp_summary)= 收敛;B 等于承认 KDD#7 之外存在一个跨模式 advisory 通道 = 放宽一条既有边界。
8. 是否引入新配置:两选项都不引入新 env/config/默认值。A 复用既有
compressSurfaceOn判定,不加旋钮。选项对比
我的建议:A。核心理由:nudge 横幅在 plugin 模式已被同一道门抑制,statusLine 是同载体兄弟产物,一抑一放是不一致而非设计;plugin agent 自己持有账本不需要这条提示;#4521 猜号是 proxy 模式的病,plugin 车道治不到点子上等于留着冗余。B 是合法的低成本替代,仅当你明确想保留这条提示、或希望零行为变更时选 B。
当前状态:发现 2 已修(PR #5353,comment-only,已推 CI 待跑)。发现 1 等你的 A/B 拍板——定了我就在同一分支/PR 上补齐对应改动(A=四 lane 加门 + 负例测试;B=KDD#7/TECHNICAL-NOTES 补句 + #5253 披露补记),合并判定随后给出。
请你拍板:A 还是 B?