lhk229
07ab58d2b9
Project CI / Repository checks (pull_request) Failing after 15s
Project CI / Backend tests (pull_request) Failing after 15s
Project CI / Frontend tests (pull_request) Successful in 4m15s
Project CI / Native shell tests (pull_request) Failing after 12m29s
立项策划链路关掉循环窗口记账，做游戏链路原样保留
窗口机制的用途是长 run 的进度 checkpoint 与停滞检测。立项策划链路两样都够不着：
策划子 Run 最多五轮左右，窗口是 AGENT_RUNTIME_BACKGROUND_LOOP_LIMIT，边界一次都
不会越过，checkpoint 和停滞判定永远不产出。它在这条链路上唯一还能产出的是失败——
windowCompletedLoops 跨暂停由 continuation 携带，nextLoopIndex 却从 pending 重读，
澄清应答恢复时两者分岔，context bundle 校验器把这个分岔变成整根 run 硬失败
（线上symptom：windowCompletedLoops=6 max=5）。一个在某条链路上无法产出收益的机制，
也不该有能力向它收费。
做法是给 tracker 加 window_disabled，构造时按 agent_runtime_context_window_applies
判定：source 为 project-supervisor-plan 的策划根、agentId 为 project-planning 的
策划子，两者关掉。complete_loop 命中标志即返回 Continue，计数恒为 0，于是持久化
bundle 在任何 nextLoopIndex 下都落在校验器的允许区间内，分岔不再有落点。
from_continuation 增加 &AgentRuntimeState 参数，让编译器强制 5 个生产构造点和 4 个
测试构造点都显式表态，而不是靠默认值静默选边。字段默认 false，未标记的 tracker
保持完整记账。
做游戏链路是这套机制真正的受益方（run 跨几十轮），一行不改：window_disabled 为
false 时 complete_loop 逐字未变。autonomous 相关 309 条测试全绿。
新增两条测试，都做过 A/B：
- 窗口分档：做游戏链路仍在窗口边界产出 checkpoint；策划根与策划子跑满两个窗口
长度也只返回 Continue。
- 恢复偏移：continuation 逐轮接力，复现「计数携带、序号重读」的真实形状，断言每个
nextLoopIndex 下 bundle 都能通过窗口校验。撤掉修复后此测试报
「窗口轮次无效：windowCompletedLoops=1 max=0」，与线上同一条校验。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-22 11:33:17 +00:00
..
2026-08-06 16:57:38 +08:00
2026-08-22 11:33:17 +00:00
2026-08-05 19:15:46 +08:00
2026-07-17 16:56:46 +08:00
2026-08-17 12:42:29 +08:00