lhk229
3bae4cdbb0
澄清信封在整条回执通道上不再按自由文本盲切
上一轮只堵了通道末端，父 run 仍然停在 needs-reconciliation：子 Agent 输出
518 字符的合法问询，在源头 last_response 处就被切成 501 字符，剥掉信封首行后
正好 1120 字节，父 run 解析时在字符串中途 EOF。
信封是结构化协议载荷，只是恰好借用了「子 Agent 自由回复」这条文本通道。定界
本身要保的三件事——状态快照与只增审计日志不被自由文本撑爆、子 Agent 文本不无
限量灌进父 Agent 上下文、摘要行只占一行——对信封都已由问询 schema 逐字段硬性
校验保住，再叠一层盲切只会砍断 JSON。
改为共有一条上限规则 static_delegate_result_detail_max_chars：字面以信封首行
开头时取 schema 推导的上限，否则原样走各自的 500/600/240。通道上四处定界全部
接上——last_response、terminal_detail、回执发布、复用既有终态时的摘要，其中
后者把「给人看的摘要」和「给解析的明细」拆成两个值，不再让一行摘要的长度决定
结构化载荷能不能被解析。last_response 与 terminal_detail 必须同源，两者逐字
相等是 finalization 幂等校验的不变式。
非信封文本走的分支与改动前完全一致，做游戏链路（含 codex）不产出该信封，行为
不变。
回归用例覆盖源头与通道两端，并钉住「普通自由回复仍被截到 500 字符」。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-20 09:55:56 +00:00
..
2026-08-06 16:57:38 +08:00
2026-08-20 09:55:56 +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