核心结论Webhook 负责低延迟通知，轮询负责最终收敛，状态机负责让两者不会互相打架。
长任务不能假装成同步请求
视频生成可能经历排队、执行、审核、上传和转码。让一个 HTTP 请求一直等待，不仅容易超过网关超时，也难以解释用户刷新页面后的状态。更清晰的接口是立即返回 request_id 和 pending 状态，再通过查询或回调推进。
定义单向状态机
建议使用 pending、running、succeeded、failed、canceled 这类有限状态，并明确允许的转换。终态不可被迟到的旧事件覆盖；相同事件可以重复处理；每次转换都保留来源、时间和供应商任务号。
- 提交时使用幂等键，防止网络重试创建第二个任务。
- Webhook 验证签名和时间戳，并保存原始事件摘要。
- 消费端先去重，再更新状态，最后触发下游工作。
- 下载结果后校验文件类型、大小和有效期。
Webhook 与轮询不是二选一
只依赖 Webhook 会受网络、配置和消费端故障影响；只依赖高频轮询则浪费配额并增加压力。ModelRush 推荐让 Webhook 成为主路径，同时用指数退避轮询做补偿。超过预期时长后降低频率，并进入告警或人工处理队列。
处理迟到与重复
分布式系统里，事件可能重复、乱序或迟到。状态更新应使用版本号或条件写入。一个已经 succeeded 的任务，不应被旧的 running 回调改回处理中；重复的 succeeded 事件也不应再次触发发布。
可靠性验收需要主动注入故障：丢弃一次回调、重复发送事件、延迟十分钟、让结果 URL 过期，并确认系统仍能最终收敛。
查看 API 文档
把文章中的架构和可靠性原则对应到请求、任务状态与错误处理。继续阅读
围绕相邻决策继续构建你的多模型技术栈。
