为什么要引入
角色母版图生图和动作 i2v 已经在线上跑通。钱和故障都在这两条链路上。
当前聚合平台的调用写在 SufyImageProvider / SufyVideoProvider 里，429、52x、是否可能已计费和 HTTP 协议拼在一起。这会带来三类实际问题：
- 入口故障和上游故障分不清。 521/522 这类请求大概率没到上游，换模型名救不了，却可能误开第二单。520/524 可能已经计费，不该再打。
- 视频重复建单。 拿到
job_id 之后再 POST 一单会重复花钱；只有上游 failed / cancelled 才该换型号新开。
- 线上无法复盘。 一次 522 或 429，不能用
task_id 捞出这次试了哪个型号、有没有换模型、算不算已计费、重试了几次。
ai_engine 负责产线（预检、抽帧、抠图、成色闸），不该承担模型治理。业务侧继续只调 gen_image / i2v。
因此在 windup_framework 内做进程内 Gateway：adapter 只拼协议、拆响应；重试、同家族 Fallback、熔断和结构化 trace 放到 Gateway。积分扣费仍走现有 QUOTA_*，不在这次改。
不包含
- Chat
- 改积分扣费规则
- 改
ai_engine 的 Provider 方法签名
验收
线上一次 522 或 429，能用 task_id 或 request_id 看清：有没有换模型、算不算已计费、522 是否只重试了一次且没有错误换型号。成功路径仍返回 bytes。
为什么要引入
角色母版图生图和动作 i2v 已经在线上跑通。钱和故障都在这两条链路上。
当前聚合平台的调用写在
SufyImageProvider/SufyVideoProvider里，429、52x、是否可能已计费和 HTTP 协议拼在一起。这会带来三类实际问题：job_id之后再 POST 一单会重复花钱；只有上游failed/cancelled才该换型号新开。task_id捞出这次试了哪个型号、有没有换模型、算不算已计费、重试了几次。ai_engine负责产线（预检、抽帧、抠图、成色闸），不该承担模型治理。业务侧继续只调gen_image/i2v。因此在
windup_framework内做进程内 Gateway：adapter 只拼协议、拆响应；重试、同家族 Fallback、熔断和结构化 trace 放到 Gateway。积分扣费仍走现有QUOTA_*，不在这次改。不包含
ai_engine的 Provider 方法签名验收
线上一次 522 或 429，能用
task_id或request_id看清：有没有换模型、算不算已计费、522 是否只重试了一次且没有错误换型号。成功路径仍返回 bytes。