任务中心
异步请求不会在创建时立即给出最终结果。任务中心把“平台是否收到、执行到哪一步、结果为什么没有返回”变成可查询的状态。
先区分调用方式： 同步请求在当前连接中返回结果；流式响应在同一连接中持续输出；异步任务先返回任务标识，再由客户端查询或在控制台跟踪。
一条异步任务如何推进
不同页面可能使用不同状态名称，应以当前控制台和接口返回为准。关键不是记住所有枚举值，而是判断任务仍会继续推进，还是已经进入终态。
查找任务前准备四项信息
- 时间范围： 尽量精确到任务创建前后几分钟，并说明时区
- 任务 ID： 创建接口返回的唯一标识，应由业务侧持久化
- 模型与能力： 例如图片生成或其他耗时任务
- 调用来源： 使用的应用、环境和 Key 名称，不要提供完整密钥
如果缺少任务 ID，先用创建时间、模型和调用来源缩小范围。只说“刚才有个任务没结果”，通常不足以定位。
“没有结果”时怎么排查
确认任务是否创建成功
先在任务中心搜索对应时间和模型。如果没有记录，回到客户端检查创建请求是否真正成功、是否发往当前环境。
判断它仍在执行还是已经终止
排队或执行中通常意味着继续等待和查询；失败或取消则需要记录状态与错误后再处理。不要把所有非成功状态都直接当作“超时”。
对照客户端轮询逻辑
控制台已经显示完成，但用户仍没有结果时，重点检查客户端是否保存了任务 ID、是否继续查询、是否读取了正确的结果字段，以及轮询是否过早停止。
对照模型、用量与错误信息
任务集中失败时，确认模型当前是否可用；需要判断是否形成消耗时，再对照同一时间段的用量记录和接口错误。
决定是否重试
只有在错误原因允许、业务能够去重并且重试不会产生不可接受的重复结果或费用时才重试。重试后保存新的任务 ID，不要继续混用旧记录。
常见现象与定位方向
业务接入必须保存什么
- 创建请求的请求 ID 与任务 ID
- 创建时间、模型名称和调用环境
- 当前状态、最近一次查询时间和最终结果位置
- 失败时的错误码与可安全记录的错误摘要
这组数据让控制台、接口日志和用户反馈能够互相对应。完整 API Key 与敏感输入不应进入普通日志。