lhk229
aebdb7a948
Project CI / Repository checks (pull_request) Failing after 16s
Project CI / Backend tests (pull_request) Failing after 16s
Project CI / Native shell tests (pull_request) Has been cancelled
Project CI / Frontend tests (pull_request) Has been cancelled
坏信封在工具计划直出那一发就拦下，重取回路终于进得去
上一版重取回路装在 final-reply 请求路径上，而策划子 Agent 的澄清信封根本
不走那条路：main_loop.rs 里 stream=false 且 plan.response 非空时直接
`final_reply = Some(response)`，随后 `if let Some(reply) = final_reply`
整块跳过 else 分支——重取回路就在那个 else 里面。所以它是死代码。
证据在 response-streams：27 个历史 run 的 68 条信封全部落在
final-reply-loop-N 记录上且 finishReason 一律为 null（短路路径没有 provider
响应对象，标记无从填），而真正发过 final-reply 请求的那几条写着 "completed"。
7 条坏信封无一例外走的是短路。之前那个 mock harness 怎么调都不触发，
原因就是这个，不是 Ready(None) 的 outcome 分支。
改法：短路处不再无条件认领最终回复。策划子 Agent 且信封解析失败时，把解析
原因作为 observation 回灌，不设 final_reply，让流程落回真正的 final-reply
请求——重取回路在那边生效，总计 1 发初始 + 2 次重取，与原型
MAX_WASTED_TURNS=3 同口径。
两个注入点合用同一条整改正文（提取成 plan_envelope_repair_observation），
只有阶段名不同，否则模型会把它读成两种不同的失败。converged 仍为 true：
这一轮确实收束了，只是不认这条信封当交付。
作用域由 game_creator_agent_runtime_plan_envelope_parse_error 把住——非策划
Agent 一律返回 None，做游戏与做素材逐字保持既有行为。
plan_envelope_repair_tests 6/6（含一条现场退化尾巴不再烧重取额度）。
回归对照：tests::provider 143/143；tests::collaboration 与
tests::runtime_actions 改动前后失败集合逐条相同（4 条 / 1 条本机基线）。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 04:59:11 +00:00
..
2026-08-22 13:17:26 +08:00
2026-08-24 04:59:11 +00:00
2026-08-22 13:17:26 +08:00
2026-08-22 13:17:26 +08:00
2026-08-22 13:17:26 +08:00