xAI的Deferred Chat Completions让应用先提交任务、拿到request_id，再稍后查询结果。它适合研究报告、复杂推理和不要求用户停留在页面等待的任务。官方文档说明，结果在完成后通过独立端点获取，未就绪时返回202；结果只能获取一次，并且在二十四小时后丢弃。这些限制决定了生产系统必须认真处理状态、重试和保存。
一、同步请求为什么会失败
长任务如果一直保持HTTP连接，容易遇到网关超时、客户端断网和页面关闭。用户看到失败后再次提交，还可能产生重复费用和重复结果。延迟任务把提交与取结果分开：前端只需确认“任务已创建”，后端异步轮询。即使用户关闭页面，任务仍可继续，回来后根据业务任务ID查看状态。
二、提交时保存两个ID
向聊天接口提交deferred为true的请求后，会得到xAI的request_id。系统还应自己生成业务task_id，并建立二者映射。业务ID用于给用户查看，外部request_id只保存在服务端。数据库至少记录用户、模型、请求摘要、创建时间、当前状态、轮询次数和结果位置。不要把完整敏感提示写入普通日志。
三、正确理解202状态
查询端点返回202代表任务尚未准备好，不是错误。后端应等待后再查询，采用指数退避，例如先等两秒、四秒、八秒，再逐步延长，并设置最大间隔。固定每秒轮询会浪费配额并增加压力。遇到401、403等权限错误应立即停止；遇到429按限流信息延迟；遇到服务端临时错误可以有限次数重试。
四、结果只能领取一次怎么处理
这是最需要注意的约束。获取到200响应后，应在同一个可靠流程中保存原始结果，再把业务状态改为完成。如果先标记完成后保存失败，结果可能无法再次领取。可以先写入对象存储或数据库临时记录，确认成功后再提交状态。多个轮询进程必须用锁或原子状态抢占，保证只有一个工作进程真正领取。
五、二十四小时过期如何兜底
任务创建后应计算过期时间，并在接近期限前提高检查优先级。超过期限仍未保存结果，要把状态标记为过期并提示用户重新提交，不能一直显示处理中。系统监控应统计平均完成时间、超时率和过期率。如果大量任务接近过期，说明轮询队列、权限或服务状态存在问题。
六、前端应该展示什么
前端只展示排队、处理中、完成、失败、过期和已取消等业务状态，不要暴露外部接口细节。提交后立即返回任务页，允许用户稍后查看。长报告完成时可以发送站内通知。进度不能凭空显示百分比，如果接口没有真实进度，就用阶段状态和预计范围，避免假进度停在百分之九十九。
七、幂等与重复提交
用户双击按钮或网络重试时，后端应根据用户、任务参数摘要和短时间窗口识别重复请求。相同任务若仍在运行，直接返回已有task_id。真正需要重新执行时，由用户明确选择。取消操作也要区分“停止本地轮询”和“远端任务已取消”，不能给出能力之外的承诺。
八、生产上线检查表
上线前验证提交成功、202轮询、200保存、限流、鉴权失败、进程重启、重复消费者和结果过期。设置队列告警与死信处理，对高成本请求增加用户配额。Grok延迟完成并不是简单多写一个轮询循环，而是一次标准的异步任务设计。把状态机、唯一领取和持久化做好，才能真正提升长任务的可靠性。
资料来源：官方资料。本文依据官方信息独立整理与扩展，结合实际使用场景进行说明。
