T2 蒸馏触发被系统性推迟:每次 T1 compress 重置 cadence 水位线 + 阈值随模型容量缩放失配(1M 模型需 50K 锚点质量才蒸馏)

[ranxianglei]

现象

一个连续运行 21 天的 hub 会话(glm-5.3,limit=1M,v1.14.x),Tier-2 蒸馏 21 天只发生 3 次,压缩锚点(compress anchor)常驻上下文 ~45K(57 个活跃块),是会话上下文底部单调上升(35K→252K)的主要成分之一。

对 session state(storage/plugin/acp/<session>.json,417 个块:414 T1 + 3 T2,360 个已失活 T1 中 157 个是被其他 T1 消费的、203 个被 3 个 T2 消费)做时间轴重建,发现两类问题:

问题 1:T2 触发被系统性推迟("应该触发而迟迟不触发")

tier-1 活跃摘要质量共 4 次越过 50K 阈值,其中两次 T2 滞后 12~22 小时才触发,期间 tier-1 质量持续 ≥50K:

越过 50K	T2 实际触发	滞后	期间发生的 T1 compress
08-20 01:40	08-20 23:51	22h	23 次
08-29 15:08	08-30 03:31	12h	25 次

根因在 lib/messages/inject/inject.ts:

1. :126-127 — 每次 compress(任意 tier)都重置 T2 cadence 水位线:

   state.nudges.lastTier2NudgeTokens = currentTokens
   state.nudges.lastTier3NudgeTokens = currentTokens

   (该重置的本意是避免"蒸馏→基线清空→立刻再触发"的循环,但它对普通 T1 compress 同样生效。)
2. T2 触发要求 currentTokens - lastTier2NudgeTokens >= growthFloor(1M 模型 = max(5K, 0.45×50K) = 22.5K)。每次 T1 compress 把水位线抬到当前值,上下文必须再净涨 22.5K,T2 的闸门才打开;而在压缩活跃的会话里,涨到 50K 时 T1 nudge 先触发并再次压缩、再次重置——T2 只能在"两次 T1 compress 之间恰好净涨 22.5K"的缝隙里溜进来。
3. :387 的 if (suffixMessage && !shouldInject) 在 T1 nudge 触发的轮次完全跳过 T2/T3 检查,进一步压缩了触发窗口。

问题 2:阈值随模型容量缩放,与锚点的绝对上下文成本失配

resolveAdaptiveNudgeGrowth = min(50K, max(6K, limit×5%))(context-compress-algorithms,chunk-BZYW3CH5.js)。T2 触发条件 tierUsage.tier1Tokens >= nudgeGrowthTokens(inject.ts:395-396)直接复用该值:

• 1M 模型 → 阈值 50K:需要 ~55 个活跃锚点(均重 ~0.9K)、上下文已经烧掉 ~50K 才允许回收;
• 200K 模型 → 阈值 10K:~13 个锚点即蒸馏。

锚点占用的上下文是绝对成本,不随模型容量缩放;结果是大上下文模型的蒸馏周期反而被拉长到 67 天(实测:08-23 蒸馏后,tier-1 质量在 4649K 徘徊了近 6 天才凑够 50K)。另外 T1 compress 互噬老锚点会把 tier-1 质量反复剃回阈值以下,让"T2 攒质量"更慢——两层回收在竞争同一个质量池。

建议修复

1. T2 触发与 nudgeGrowthTokens 解耦:改用绝对阈值(如 15~20K)或活跃锚点计数(≥12 个即蒸馏),或双阈值取先到;
2. :126 的水位线重置只针对真实 T2/T3 蒸馏生效,普通 T1 compress 不重置 lastTier2NudgeTokens(或重置为 currentTokens - growthFloor/2,保留半窗);
3. T1 nudge 触发的轮次不整体跳过 tier 检查——可在 T1 nudge 文本后附带 T2 trigger 指令;
4. (可选)被 T2 消费后的锚点 summary 参数缩略为指针,decompress 仍可回源,进一步降低锚点常驻成本。

数据来源

21 天 hub 会话 state 文件时间轴重建(块创建/消费事件模拟,终态与文件 ground truth 一致:54 个活跃 T1 = 36,189 tok);两次饥饿窗口内 T1 compress 创建次数直接取自块的 createdAt。自 08-30 最后一次蒸馏以来 tier-1 峰值仅 36.2K(<50K),按规则未漏触发——本文报告的是阈值达到后的 12~22h 触发延迟,以及阈值/重置机制造成的系统性蒸馏饥饿。

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 审核结论(先查证后动手)

我把 issue 里两类问题逐条对照当前 master(v1.14.26)代码核实了一遍。结论:问题 1 是真实存在的活 bug,根因定位准确,可以直接修;问题 2 的"阈值随模型容量缩放"机制在 v1.14.15(PR #327,2026-08-20)已被移除,当前是固定 50K——但问题 2 背后的"T2 触发阈值与 T1 增长旋钮复用同一常量、锚点绝对成本不随窗口缩放"这个设计隐患仍然成立,值得解耦。

---

问题 1:T2 触发被系统性推迟 —— ✅ 确认,活 bug

三处代码证据(lib/messages/inject/inject.ts,行号以当前 master 为准):

1. :139-140 —— 每次处理到一个**新的 compress 消息(任意 tier)**都会重置水位线:

state.nudges.lastTier2NudgeTokens = currentTokens
state.nudges.lastTier3NudgeTokens = currentTokens

这段逻辑来自 #235(commit aa3b8ff,"preserve cadence baseline after compress attempt"),本意是把基线设为 currentTokens(而非 undefined)以避免"T2 触发→压缩→立即再触发"的循环。但它对普通 T1 capture 压缩同样生效——而 T1 capture 恰恰是增加 tier-1 摘要质量的操作,却同时把 T2 闸门复位,双重推迟了本该清理 tier-1 池子的 T2 蒸馏。

2. :438-442 —— T2 触发的 cadence 门:currentTokens - lastNudge >= growthFloor。默认 nudgeGrowthTokens=50K,growthFloor = max(5000, 0.45×50000)= 22.5K。每次 T1 compress 把水位线抬到当前值,上下文必须再净涨 22.5K,T2 才可能开闸;在压缩活跃的会话里,T1 nudge 先触发并再次压缩、再次复位——T2 只能在缝隙里溜进来。与你实测的 12~22h 延迟吻合。

3. :430 —— if (suffixMessage && !shouldInject) 在 T1 nudge 触发的轮次整体跳过 T2/T3 检查,进一步收窄窗口。

问题 2:阈值随模型容量缩放 —— ⚠️ 部分过时,但设计隐患仍在

• 已过时部分:你引用的 resolveAdaptiveNudgeGrowth = min(50K, max(6K, limit×5%)) 自适应公式,已在 v1.14.15(PR fix: nudgeGrowthTokens fixed default 50K — removes window-percentage scaling #327,2026-08-20)被移除,替换为固定 DEFAULT_NUDGE_GROWTH_TOKENS = 50_000(config override 是唯一旋钮)。这是你当时亲自拍板的设计决策(devlog 2026-08-20_fixed-nudge-growth:"growth threshold must be a fixed value, not a percentage")。当前 master 所有模型统一 50K。
• 对你的 1M 会话而言:自适应公式对 1M 本来就是 min(50K, 1M×5%)=50K,固定也是 50K——所以你的观测里阈值自始至终都是 50K,"随容量缩放"在你的案例中并未真正体现(它只影响小窗口模型)。
• 仍然成立的部分:T2/T3 tier 触发(inject.ts:439 tc.tokens < nudgeGrowthTokens)复用了 nudgeGrowthTokens 这个常量,而它的本意是 T1 增长速率旋钮(距上次 nudge 原始上下文净增多少才再 nudge)。用它当 T2 存量门槛(累计多少 tier-1 摘要质量才蒸馏)属于两个不同度量共用一个常量。锚点占用是绝对成本,50K(~55 个锚点)才允许蒸馏确实偏高。

与其他 issue 的关系(非重复,但有张力)

• Feature: Support percentage-based nudgeGrowthTokens for cross-model portability #300(OPEN,yangyaofei):要求 nudgeGrowthTokens 支持百分比字符串做跨模型可移植——针对的是 T1 增长速率旋钮。与本 issue 的 T2 存量门槛是两个不同度量。我下面的解耦方案恰好能同时照顾两者:T1 保留自己的旋钮(Feature: Support percentage-based nudgeGrowthTokens for cross-model portability #300 的百分比可移植性可以加在 T1 上),T2 用独立的低门槛。两者不是重复,建议在同一场设计讨论里一起定。
• fix: T2/T3 nudge loop — preserve cadence baseline after compress #235:水位线复位逻辑的来源(循环防护)。
• fix: nudgeGrowthTokens fixed default 50K — removes window-percentage scaling #327:移除自适应缩放的 PR。

修复方案评估与建议

你的建议	评估
#1 T2 触发与 nudgeGrowthTokens 解耦(绝对阈值 15~20K 或锚点数 ≥12,或双阈值取先到)	✅ 推荐。消除两度量共用一常量的设计异味,也顺带给 #300 留出空间。具体取值走 config(如新增 compress.tierTriggerTokens,默认 ~20K),不硬编码
#2 水位线复位只对真实 T2/T3 蒸馏生效(T1 capture 不复位 lastTier2NudgeTokens)	✅ 核心修复。按最后一个 compress 消息的边界类型判定 tier:mNNNNN→T1 capture(不动任何 tier 基线);消费 tier-1 块的 bN→T2 蒸馏(仅复位 lastTier2NudgeTokens);消费 tier-2 块→T3(仅复位 lastTier3NudgeTokens)。保留真实蒸馏的循环防护
#3 T1 nudge 轮次不整体跳过 tier 检查	⚠️ 可选,优先级低于 #2。#2 修好后大部分饥饿已解决,#3 作为进一步放宽窗口的手段
#4 被 T2 消费的锚点 summary 缩略为指针	⏸️ 较大改动,建议另开 issue

我的计划

1. 先落地 Add CI workflow for testing and building #2(tier-aware 复位) —— 问题 1 的根因、风险最低、收益最直接。
2. 同时落地 feat: expand message ref format from 4-digit to 5-digit (9999→99999) #1(解耦 T2/T3 阈值) —— 引入独立 config 字段,默认绝对阈值(倾向 ~20K,兼顾 1M 与小窗口);保留锚点计数口径待你和 Feature: Support percentage-based nudgeGrowthTokens for cross-model portability #300 一起定。
3. 补 §5.7 要求的测试(多轮、副作用断言、生产配置 preserveRecentMessages>0、完整 growth cycle),并验证"回退修复则测试失败"。
4. 出 PR,走双 agent review。

需要你拍板的一点(#1 的默认值)

T2 独立阈值默认值取哪种?

• (a) 纯绝对 token(我倾向 20K),或
• (b) 纯锚点计数(≥12),或
• (c) 双阈值取先到(20K 或 ≥12 个活跃 T1 块)?

我倾向 (c) 双阈值取先到(20K 为主 + 锚点计数兜底):既避免小窗口模型因绝对 token 门槛过高而蒸馏过慢,又不让大窗口模型在低质量时过早蒸馏。但这会影响小窗口模型的蒸馏频率,想先听你的意见再定默认值。#2 不依赖这个决定,我会先行实现。

我这就开始动手,进展会持续回帖。

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 状态:修复 #2 部分落地,后续步骤被阻塞(工作卷磁盘满)。

已完成

• 审核/定位见上一条回复。P1 是活 bug,根 cause = lib/messages/inject.ts:139-140 对任意 compress 重置 tier 水位线。
• 修复 Add CI workflow for testing and building #2 核心已部分实现:在 lib/messages/query.ts 新增纯函数 isCaptureOnlyCompress(+ extractCompressBoundaryIds),按 compress 调用边界前缀分类 —— m 前缀 = 原始消息 T1 capture,b 前缀 = T2/T3 蒸馏/浓缩(沿用既有约定 lib/compress/state.ts:81-83)。
  • 语义:仅当边界可解析且全部为 m 前缀才返回 true(capture);任何 b 前缀或不可解析 → false(保守,保留 fix: T2/T3 nudge loop — preserve cadence baseline after compress #235 的循环防护重置)。
  • 兼容性:现有 #235 回归测试的 compress 用 input:{} → 落入保守 false 分支 → 重置仍发生 → 该测试保持绿。

待完成(当前阻塞)

1. inject.ts:139-140 接入守卫(capture 时跳过 tier 水位线重置);
2. §5.7 强制测试(多轮 + 副作用断述 lastTier2NudgeTokens + preserveRecentMessages>0 + growth cycle,并"有 bug 时 FAIL"验证);
3. typecheck / build / 全量测试;devlog + PR。

阻塞原因

工作卷文件系统 100% 满(ENOSPC: no space left on device)—— 无法写入 inject.ts 改动、无法运行 typecheck/build/test、无法提交或推送。已改的 lib/messages/query.ts 与 npm install 产生的 package-lock.json 仍在工作区未提交。按平台约定我不擅自清理或改动宿机卷内容 —— 请释放空间后我立即继续(改动已暂存在工作区)。

仍待拍板(#1,未阻塞 #2)

上一条回复的开放问题仍待答复:T2 独立触发阈值用 (a) 绝对 ~20K / (b) 活跃锚点计数 ≥12 / (c) 双阈值先到?倾向 (c)。#1 的默认值等你拍板;#2 不依赖它。

关于 #1 与 #300

compress.nudgeGrowthTokens 是同一个常量驱动 T1 增长节奏与 T2/T3 提升,抬高/降低它无法独立调节两者(团队已在 devlog/2026-08-28_min-gate-growth-nudges/REQ.md:14 记录此耦合)。解耦为独立字段(tierTriggerTokens)是拟方案,但涉及 ~8 文件配置面 + 全局默认值变更,保留默认(50K,行为不变)还是降低(如 20K)是你的拍板,所以 #1 拆成后续 PR。

[ranxianglei]

🤖 ework agent · qwen3.8-27b

[bot] 🏷 PR ready: #365

Landed (issue P1 / 建议修复 #2 — tier-aware cadence reset):

• lib/messages/query.ts: new isCaptureOnlyCompress — classifies the just-processed compress call by its range-boundary prefix, the convention already documented in lib/compress/state.ts:81-83 (m-prefix = raw T1 capture; b-prefix = T2+ distillation). Conservative: unparsable input → treated as distillation, so the fix: T2/T3 nudge loop — preserve cadence baseline after compress #235 loop-prevention invariant is never weakened.
• lib/messages/inject/inject.ts: the lastTier2NudgeTokens/lastTier3NudgeTokens = currentTokens reset now runs only for non-capture compresses. T1 captures no longer re-arm the 22.5K growthFloor wait → the 12~22h starvation windows close.
• Tests: +11 unit (tests/query-pure.test.ts) + 3 integration (tests/inject.test.ts) per §5.7 — multi-turn with production preserve-recent knobs asserting baselines unchanged after captures (side-effect assertion), distill-reset contrast (fix: T2/T3 nudge loop — preserve cadence baseline after compress #235 lock), full cadence cycle capture→baseline-held→growth→T2-fires. §5.7.3 verified: fix disabled → capture+cycle tests FAIL, all legacy green.
• Full suite 1091/1091, typecheck + build green, scripts/ci/check-pr.sh all pass. Rebased onto current master (v1.14.27).

Still open (as discussed above):

• feat: expand message ref format from 4-digit to 5-digit (9999→99999) #1 threshold decoupling — awaiting your call on the default: absolute ~20K, anchor-count ≥12, or dual whichever-first (my lean: dual). Will fast-follow once you rule.
• docs: Test suite development summary (346→350 tests, 5-tier coverage) #3 tier checks on T1-nudge turns — residual delay after this fix is one turn, not hours; optional.
• docs: add devlog system for development iteration tracking #4 pointer-izing consumed anchors — separate issue if you want it.

Per project rules I can't merge — please review and merge PR #365 yourself. Dual-agent review (§5.3/§5.6) is being run now; I'll report the outcome here.

[ranxianglei]

🤖 ework agent · qwen3.8-flash-next-w4a16-p294

[bot] 🏷 PR 就绪，CI 全绿：#365

落地内容（问题 1 的修复）

• lib/messages/query.ts：新增 isCaptureOnlyCompress 分类器 — 读最后 compress 消息的 tool part 边界，按既有约定（lib/compress/state.ts:81-83：m 前界 = T1 捕获，b 前界 = T2+ 蒸馏）判定。任何 b 边界或不可解析 → 保守 false（重置照常发生，fix: T2/T3 nudge loop — preserve cadence baseline after compress #235 防循环不变量保留）。
• lib/messages/inject/inject.ts:139：重置包在 if (!captureOnly) — T1 捕获不再重置 lastTier2/3NudgeTokens，蒸馏/保守路径仍重置。
• 测试：tests/query-pure.test.ts +11 单测；tests/inject.test.ts +3 集成测（多轮、断言 lastTier2NudgeTokens 副作用、生产配置 preserveRecentMessages=5、完整 growth→nudge→compress→baseline 循环）；按 §5.7.3 验证修复存在时测试失败（临时 captureOnly=false → 捕获/循环测红、蒸馏对比测绿，随后重新应用）。全套 1091/1091，tsc/tsup 干净。
• 效果：T2 的 growthFloor（默认 22.5K）等待计时从真实蒸馏或基线缺失，不再被中间 T1 捕获反复重启。issue 观测的 12~22h 延迟场景（阈值越 50K + 中间 T1 compress）现在触发在越点后的首个评估轮。

E2E 说明（CI 两轮红→绿的历程）

• 第一轮红：e2e: tier2BaselineSet === true — got null — 场景 11 的旧断点锁定了旧无条件重置行为（fake LLM 只能发出 m-ref，无法发出 b-ref），而新正确行为是捕获不设置基线 → 场景内容重新定作用域：断点改为 tier2BaselineSet: false（捕获期间基线保持 unset）；fix: T2/T3 nudge loop — preserve cadence baseline after compress #235 不变量（蒸馏后基线 never-undefined）由单元测试锁定（phase 1-3 + b 前界对比测）；fake LLM 的 b-ref 发射限制已在 scripts/e2e/README Known Limitation 1，蒸馏路径的 E2E 覆盖待 fake LLM 支持 b-ref。
• 第二轮红：ENOENT — 我改名场景文件但 .github/workflows/ci.yml 的 e2e 作业传硬编码场景路径，漏更新；改 ci.yml 被 GitHub 拒绝（bot PAT 无 workflow scope，无法推送触碰 .github/workflows/）→ 最终方案：文件名保留原名（ci.yml:59 引用），仅内容重新定作用域。文件名现在是轻微误名，cosmetic 重命名（文件+ci.yml 一并）留给人类后续。
• 最终 head e6fd6f3：e2e / build / test (22) / test (24) / pr-validation 全部 success。

双评审（§5.3+§5.6，两个独立 agent）

代码评审与测试评审均 APPROVE，仅非阻塞小项（已记录，未改码）：垃圾 id（如 "block5"）计为消息边界 → 失败的垃圾 T2 尝试分类为捕获（跳过重置；缓解：真实 T2 触发时 inject.ts:535 仍设基线）；同轮多 compress 只分类最后一个（保守方向）；分类器忽略 tool status（失败的 m 前界 compress 也跳过重置 — 无害，未测）。

未在本 PR（按设计）

• 修复 feat: expand message ref format from 4-digit to 5-digit (9999→99999) #1（T2 阈值与 nudgeGrowthTokens 解耦）待拍板：绝对 ~20K / 活跃锚点计数 ≥12 / 双阈值取先到（我倾向后者）；与 Feature: Support percentage-based nudgeGrowthTokens for cross-model portability #300（按模型百分比移植）的张力已在 issue 说明。拍板后快速跟进 PR。
• 建议 docs: Test suite development summary (346→350 tests, 5-tier coverage) #3（T1 nudge 轮附带 T2 指令）：重置修复后大部分 moot（T2 评估不再被重置推迟叠加；:430 跳过仍存在但可在 feat: expand message ref format from 4-digit to 5-digit (9999→99999) #1 一并评估）。
• 建议 docs: add devlog system for development iteration tracking #4（T2 消费后锚点变指针）：独立后续 issue。

PR 合并是人类操作（AGENTS.md §5.1.1.2）— 请自行合并：#365