Repository navigation
Docs: BILLION_CONTEXT_PROXY line misdescribes the zcode lane, which has no client-side plugin and relies on staying under the native autoCompact threshold #4369
Description
来源: #4006 (#4006) 分析 ZCode 看门狗恢复延迟时发现
查重: 无（open+closed 检索 “zcode autoCompact compaction strategy double compression” 无匹配）
现象（#4006 实测）
CONFIGURATION.md:1917 对 BILLION_CONTEXT_PROXY 的描述是「client-side bili plugins/extensions detect it and self-disable their own compression」。这对确实带客户端 bili 插件的 lane（pi/opencode/dsh bundle）成立，但对 zcode lane 有误导性：ZCode 应用里根本没有客户端 bili 插件——#4006 取证：/Applications/ZCode.app/Contents/Resources/glm/zcode.cjs 中该检测逻辑出现次数为 0，DISABLE_*COMPACT* 正则也无命中（autoCompact|DISABLE_AUTO_COMPACT|suppressCompaction 只出现在 dist/index.js、dist/claude-mcp-entry.js、dist/claude-native-bootstrap.js、dist/agent/pi-native.js）。
zcode lane 实际策略是什么都不注入——靠 bili 把折叠后上下文（实测 ~200k）压在 ZCode 原生 autoCompact 阈值之下（例如 contextWindow=750000 → 原生阈值 716000）。各 lane 真实对照（#4006 实测）：
| lane | 原生 compaction 如何被挡下 |
|---|---|
| claude | 注入 DISABLE_AUTO_COMPACT=1 |
| dsh | wire-level guard（#1729）对原生 compaction 调用本地 422 |
| opencode | 需手动 compaction.auto=false |
| pi/omp | session_before_compact / auto_compaction_start hook 取消 |
| zcode | 不注入任何东西——bili 保持上下文低于原生 autoCompact 阈值 |
影响
读 CONFIGURATION.md 的人会以为 zcode 也有一个自禁用的客户端插件。而 zcode 的保护是一个隐式前提（bili 折叠目标 < 原生 autoCompact 阈值）：窗口配置异常或增长尖峰一旦越过该前提，ZCode 原生 compaction 就会直接穿过 bili 执行，后果未文档化（参照 dsh 侧同类机制 #1729 为何要拦它）。
建议修法
- 把
BILLION_CONTEXT_PROXY那一行限定到「带客户端插件的 lane」； - 补一张各 lane 防双压缩策略表（如上），写明 zcode 的阈值余量姿态及其前提条件；
- zh 镜像同步。
环境：macOS 15.8.1 Apple Silicon · ZCode 3.16.2 · bili 0.1.202 (commit 6deb454) · Node 26.11.1
Activity
ranxianglei commentedon Oct 23, 2026
(ai: vllm-qwen/qwen3.8-27b)
查重: 不重复（open+closed 已按 "zcode autoCompact double compression BILLION_CONTEXT_PROXY" 检索，无同主题条目；#4006 是其来源 issue 不是重复项）。
标签:
scope/docszcodep3（文档勘误，非 bug 类；zcode lane；文档措辞问题 = p3）已完成对 master 的独立核实，issue 描述全部成立：
CONFIGURATION.md:1947（zh 镜像CONFIGURATION.zh-CN.md:1942）写「client-side bili plugins/extensions detect it and self-disable」——但 zcode 的扩展面只有外部 SessionStart hook + stdio MCP 子进程（CLIENTS.md ZCode 节「no in-process JS seam」），src/zcode/下compact零命中，没有任何东西读这个变量来自禁用。真正读它自禁用的只有进程内插件：pi/omp 共享插件（src/agent/pi.ts）、opencode（src/agent/opencode*.ts）、standalone billion-context-pi/opencode-acp。dsh bundle 也不靠它防双压缩——它走 wire-level guard（nudge 死锁无检测:同一 session 交替收到两种结构互斥的请求流(巨型单消息 ↔ 多轮)时不告警 #1729 → 422）。DISABLE_AUTO_COMPACT=1（src/plugin-install.ts:660）、dsh wire guard、opencode 安装器置compaction.auto=false（src/agent/opencode-native.ts:502）、pi/omp hook 取消（src/agent/pi.ts:984,992）、zcode 什么都不注入。CONFIGURATION.md:2115那条/bili/自检测描述点名的是 pi/opencode 扩展，是准确的，不动。即将提交 PR：① env 行限定到「带进程内插件的 lane」并点明 zcode 例外；② CLIENTS.md ZCode 节补「防双压缩姿态」条目 + 各 lane 策略表（含 zcode 阈值余量前提与越过后果）；③ zh 镜像同步。纯文档改动。
ranxianglei commentedon Oct 23, 2026
(ai: vllm-qwen/qwen3.8-27b)
PR 已开：#4415 （Closes #4369，纯文档，4 files +29/-2）
按八问收工：
BILLION_CONTEXT_PROXY行说「客户端 bili 插件检测到它后自禁用自身压缩」——这句话对没有进程内插件的 zcode lane 不成立，读者会误以为 zcode 也有一个自禁用插件。CONFIGURATION.md:2115的/bili/自检测描述点名 pi/opencode 扩展是准确的，未动；README coexistence 节谈的是 bili 插件互斥，语义不同，未动。一处有意修正需点名：issue 表里 dsh 写的是「本地 422」，但 [Bug][dsh] Unbounded growth of raw history → 39.7MB session file overwhelms dsh desktop renderer process, entire UI beco | [Bug][dsh] 原始历史无上限增长 → 39.7MB 会话文件压死 dsh 桌面端渲染进程，UI 全部无响应 #3723/Storage cleanup wave 2: Batch-clearing nine items (Correctness #3841/#3798 + GC #3463/#3671/#3762 + Posture #3723/#3489/ | 存储收尾第二波:九项一次清账(正确性 #3841/#3798 + GC #3463/#3671/#3762 + 姿态 #3723/#3489/#3633/#3788) #3901 起默认已是本地回 bili 折叠快照（src/knobs.ts:495-514核实），表中按当前默认写，422 作为BILI_DSH_AUTHORED_COMPACTION=0的逃生路径保留——这是文档对齐现状，不是行为变更。合并判定：可合（docs-only，diff 已收敛到每行都与本 issue 相关）。
ranxianglei commentedon Oct 24, 2026
已由 PR #4511 修复(WAL custom cap 截断+media CAS stale-row 媒体释放+#3250 断言归一,2026-10-24 合并)。此 issue 属于同一 master 破损窗口(02f544d 前后)的重复报告面——WAL 不截断/媒体引用不释放/CI 相关分片红都已在该 PR 收口。如复现请带版本号重开。