直接回答
async task API 是一种先创建任务、再查询状态、最后获取结果的接口形态。它常用于执行时间更长、成本更高、失败恢复更复杂的模型能力，尤其适合视频和其他长时生成工作流。
展开说明
把这个问题拆成三个更容易判断的部分。
答案页不追求大而全，而是先给直接回答，再把为什么重要、为什么不能简化、35m.ai 怎么处理这件事拆开讲清楚。
为什么视频接口通常走异步
视频任务天然更长、更贵，也更容易受到排队、超时和重试影响。同步等待经常既慢又难解释。
- 异步任务更适合把创建、等待、完成拆成更稳定的三个阶段。
- 轮询状态比一直卡着一个连接更容易被客户端管理。
一个好的 async task API 该长什么样
异步接口的关键不是“有任务 id”而已，而是状态是否稳定、语义是否清楚、结果何时可以被安全消费。
- 创建任务时立即返回任务 id 和初始状态。
- 状态查询接口保持统一语义，而不是每个模型各说各话。
35m.ai 里的任务型能力
35m.ai 把异步任务视为统一工作流的一部分，而不是某个视频模型的私有行为。这样页面、目录和接口说明才能一起解释同一件事。
- 视频模型的首页示例会先强调任务链路，而不是假装它和文本调用完全一样。
- 状态查询和结果下载继续通过统一任务接口承接。
常见问题
继续把常见误解讲清楚。
如果用户已经理解主答案，这一组问题通常就是他们下一步会继续确认的边界。
异步任务只适合视频吗？
不只适合视频，但视频是最典型的场景。任何执行时间更长、更贵或需要状态管理的任务都可能适合异步。
轮询状态是不是很笨？
不一定。对很多团队来说，统一且可控的轮询反而比零散 webhook 更容易落地。
相关问题
继续看这些相关问题。
把主题做成彼此可连接的答案页，会比把所有解释塞回首页更利于理解和搜索发现。