视频生成可能耗时很久。如果一次前端请求要等到成片，用户切页、网络中断和请求超时都会让结果变得难以解释。先延长超时能缓解现象，但不能替代任务模型。
个人 AI 平台在迭代中将视频生成改成了持久化任务，并增加任务中心。我需要先确定任务、外部服务商和积分之间怎样关联，再推进前后端实现。
先定义用户看到的生命周期
提交成功应该表示“系统已受理”，不意味着视频已经生成。排队、提交中、服务商处理中、成功和失败，要有明确区别。
任务保留用户、模型、请求标识、参数、外部任务 ID、结果和错误信息。页面通过任务查询恢复进度，后端执行不再依赖某个页面一直等待。
提交和轮询是两种工作
提交阶段会产生新的外部动作，轮询只查询已有任务。项目将它们放在不同并发槽位中，并分别设置租约。
领取任务需要在数据库中确认状态和租约标识，写回时也要匹配当前身份。租约过期后，轮询可以重新被领取；任务完成后进入终态，不能被晚返回的处理逻辑随意覆盖。
调度器还区分文生视频与图生视频的并发，并对轮询加入逐步延长的间隔和抖动。这样并发限制能对应到真实资源，而不只是浏览器按钮是否禁用。
积分与素材跟着任务走
任务调用会关联交易，成功记录结果，失败按规则退款。相同任务的终结流程需要先检查状态，避免重复处理。
参考素材也有生命周期。浏览器里的本地引用不能直接供后台工作线程使用，需要在提交时转换成后端可用的暂存资产，并在终态或保留期结束后清理。
这要求前端、任务表、服务商客户端、积分服务和素材服务都遵守同一套契约。
本地任务表不能解决所有重复窗口
服务商已经受理，但本地还没保存外部任务 ID 时，进程仍可能退出。此时不能仅凭“本地没有 ID”就断定外部没有执行。
要缩小这段不确定性，需要服务商的幂等键、请求查询或人工核对能力。持久化任务提升了追踪和恢复能力，但不等于端到端恰好执行一次。
我更愿意把这类限制写清楚，避免把局部状态控制夸大成系统保证。
怎样验证这次改造
检查创建任务是否立即返回；关闭页面后后端是否继续处理；多次查询是否得到同一任务；租约失效是否能被接手；终态回写是否重复结算；素材是否按约定清理。
这些场景帮助我判断生成代码是否兑现了最初的产品目标，而不是只看任务表和接口是否都存在。
异步任务与任务中心分别对应 2026-07-23 的提交 5782aca21、fabc0cb8a；后续继续补充任务数量刷新与模型契约。