lhk229
7df033fcde
修复澄清回执通道容不下一次正常问询
子 Agent 的澄清信封走的是 error 文本通道，两处把它当普通错误消息处理：
一是中转通道的字符上限写死 500，而它承载的问询 schema 允许 3 个问题、每题 400
字符、每题 2-3 个选项（label 60 + description 240）——单个 schema 合法的问题光内
容就有 1376 字符，通道连一个满格的合法问题都装不下。现场一问三选的正常中文问询
501 字符，正好被拒收。改成由 schema 自己的上限推导，推导常量放在 schema 所在的
user_input.rs；顺带把内联的 options.len() < 2 || > 3 换成具名常量，让推导有据。
二是父 run 认领回执时按错误消息截到 500 字符再补省略号。现场子 Agent 的真实输出
521 字符，截断后 501 字符，JSON 拦腰断在末尾，父 run 解析失败停在
needs-reconciliation。只放宽上限治不了这一处：载荷在到达解析器之前就已经被切了。
识别信封前缀时按信封通道上限放行，其余错误消息仍是 500。
两处都得对，少一处这条链路就断。上限是沿用 master 的（82957fe1d，2026-08-12），
本分支没改过；做游戏链路的专业 Agent 很少提带选项的澄清，所以此前没暴露，而 M1
策划把"先问清楚再出 GDD"做成了必经步骤。
放宽上限不会让原本通过的载荷失败，逐字段复核仍在
parse_game_creator_agent_user_input_questions。新增三条用例：schema 允许的最大合法
问询必须能过通道、现场那条普通中文问询必须能过、同一条信封被截断后必然解析失败。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 08:49:12 +00:00
..
2026-08-06 16:57:38 +08:00
2026-08-20 08:49:12 +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