这条工作流把一条视频从原始画幅真实扩展到目标画幅（如 9:16 → 16:9）——不是加黑边，也不是把原片贴在生成背景中间。一路上有三道 Gemini 质检门把关，任何一道用尽重试仍不过，整单失败，不交付缺陷片。
重试 5 次 + 9 小时的版本（v39）验证过参数上限的价值（13 单失败挽回 10 单），但那是修复验证期的配置；常态回到 2 次重试 + 3 小时——快速失败，失败单用 retry_segments 定向补跑失败窗口，比整单泡 9 小时便宜。
整条流水线里 agent 自己从不判画质——所有"过不过"都由 Gemini 说了算，agent 只负责把媒体喂给门、按门的证据改提示词重试。这样每次失败都留下机器可查的证据（outputs/qa/*.json），事后能还原每一次判定。
| 门 | 时机 | 查什么 | 不过怎么办 |
|---|---|---|---|
| Gate 1 锚点图 |
每张场景扩图完成后（Step 4b） | 把原帧和扩图后的帧并排给 Gemini：原内容有没有被改动、新画的两侧是不是自然延伸、有没有画框感/文字乱码 | 带着门的原话（what_you_see）重画，gpt-2-edit 连挂可换 nano-banana 兜底；每场景最多 2 次 |
| Gate 2 接缝/跟动 |
每个窗口视频生成后（Step 5b） | 盯着新旧画面交界线看整段：有没有亮度/纹理断层、镜头动时新画的两侧是否跟着动（冻结的两侧即使没缝也算挂） | 任一门挂 → 只重生成这一个窗口，把失败时间点和证据写进新提示词；每窗口最多 2 次，用尽即整单失败 |
| Gate 3 内容保真 |
同上，与 Gate 2 分开调用 | 只看中心原始区域：角色/物体外观、动作时序、镜头运动、文字 UI 有没有被生成过程改掉 | |
| Gate 4 成片终检 |
拼接完、交付前（Step 6.7） | 把 Gate 2+3 原样对最终成片再跑一遍，专抓拼接边界缺陷和漏检窗口 | 若窗口全过但成片挂，说明问题出在拼接环节，修拼接后重检 |
Gate 2 和 Gate 3 是两次独立调用、两份独立 JSON 判决，不许合并成一个 bool。7 月 27 日那批失败里最典型的两类——"两侧冻结不跟镜头"和"卡片文字变乱码"——正好分别被这两道门拦住。
| 层级 | 参数 | 值 | 说明 |
|---|---|---|---|
| 整单 | timeout_seconds | 10800s = 3h | 超过即 run 被平台杀掉、任务 failed。retry 2 次下常规单跑不满 3h；曾为 retry5 临时放到 9h，回到 2 次后收紧 |
| 整单 | stall_seconds | 2400s = 40min | agent 40 分钟毫无动静（不汇报进度）判定卡死 |
| 单次生成 | poll_max（视频） | 2400s = 40min | 等一个 seedance-omni 窗口生成的轮询上限。视频慢，给宽 |
| 单次生成 | poll_max（默认/图） | 1200s = 20min | gpt-2-edit 扩图等图类调用的默认等待 |
| 单次质检 | Gemini 门一次调用 | 约 15s | google/gemini-3.6-flash，temperature=0；便宜（约 $0.01/次），所以成片终检即使内容没变也照跑 |
retry_segments 只重跑失败窗口，不必从头再来| 项 | v35（上周 prod） | v39（验证期） | v43（现 prod） |
|---|---|---|---|
| 每窗口质检重试 | 2 次 | 5 次 | 2 次 |
| 生成分辨率 | 默认 | 1080p | 1080p |
| 整单超时 | 4.5h | 9h | 3h |
| 卡死判定 | 40min | 60min | 40min |
v39 是修复验证期的放宽配置（13 单挽回 10 单证明了 1080p 的价值）；v43 保留 1080p，重试和超时回到常态——retry 2 次下 3h 足够，真救不回的 case（密集卡片文字、开场快切）重试多少次结局都一样。