lhk229
15c0d6f028
修通澄清信封被收束门禁拦死的活锁，并给最终回复重试加兜底
策划子 Agent 每轮都在正确地吐 AGC_NEEDS_USER_INPUT_V1 信封（header 带主题、
三选项齐全），却被拒了 26 次，一条生产 run 空转 65 轮直到人工介入。
信封是通过 respond_to_user 交付的，走最终回复通道，于是撞上两道「计划必须全部
完成」的判据：
- runtime_state.rs 收束链首位的 structured_plan_completion_blocker
- runtime_protocol/finalization.rs 上「finalization 必须绑定已全部完成的计划
快照」这条 journal 持久不变量（第二道，是上面那条测试逼出来的）
而计划里「按用户决定收敛并提交」那一步在用户答之前永远不可能 completed：想问
用户就得先 respond_to_user，问不出去就答不了。对任何含「答完之后再做 X」步骤的
计划，这条判据都不可满足。
以前没炸靠两件偶然：策划子 Agent 不提交结构化计划（判据第一行就跳过），或者
提交了之后肯把没做的步骤标成 completed。翻了同机全部历史 run：4 条没提交计划、
2 条首版 3/4 改成 4/4 放行、这条首版 1/4 之后再没改过——就死了。
修法是判据豁免而不是代填步骤状态：澄清信封是本 run 挂起等用户答，剩余步骤归
用户答复后的 continuation run，把它们标成 completed 是伪造进度。豁免只放行
「计划未完成」这一件事，快照自身的结构合法性仍然逐项校验，其余 blocker 照常。
第二件：最终回复被拦下后 run 原地续跑重试，此前没有任何上限。空转闸只认裸
update_agent_plan，而这里模型每轮都在认真调 respond_to_user，没有任何计数器会
累加。新增 stale_finalization_rounds（持久 Runtime state，与
plan_submit_gdd_rejection_count / plan_update_idle_rounds 同一模式，重启不能把
活锁洗成新的无限 Provider 开销），上限 32——刻意留在两道软闸之上，让自愈路径
先有机会起作用。真实推进后清零。
守门两条：
- 同一份未完成计划，普通交付收束必须被拦（blocker.tool=runtime.plan_update）、
澄清信封必须放行。两半都实测非空转：撤掉任一处豁免，对应那半立刻红。
- 兜底额度必须高于两道软闸，防止有人把它调到软闸以下抢跑自愈。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-26 10:08:44 +00:00
..
2026-08-22 13:17:26 +08:00
2026-08-26 10:08:44 +00:00
2026-08-24 16:27:33 +08:00
2026-08-24 16:27:33 +08:00
2026-08-22 13:17:26 +08:00