语音转文本工作应由持久化队列管理，以有效处理速率限制。系统必须尊重 429 响应中的 Retry-After 头，并避免重试那些无法随时间自行恢复的错误。主要约束在于转录能力的可用性，而不仅仅是 HTTP 客户端。作业通过幂等键被接受，初始返回待处理（pending）状态，随后有界的工作进程调用提供商。仅 429 错误和瞬态服务器错误应触发重试，并正确解析 Retry-After 并添加抖动。队列可以吸收速率限制突发流量，但无法使不可用的自动语音识别（ASR）后端变为可用。对于开发者工具，将 Web 请求与转录处理分离至关重要，使管道能够真实地报告待处理、运行中、失败或完成等状态。429 响应表示服务暂时不可用，而其他 4xx 错误则表明永久性问题，需要立即记录日志且不应重试。在发送生产流量之前，系统必须通过发现数据验证后端就绪状态。批量提交不会改变后端就绪状态；“本地排队”和“被提供商接受”等状态应保持区分。重试多部分请求需要重新创建请求体，对于大文件，避免缓冲至关重要。幂等性对于防止重试导致的重复副作用至关重要。队列准入策略应涉及持久化对象、写入作业记录并返回 202 Accepted 状态。工作进程应强制执行全局和每个租户的并发限制。状态转换应清晰区分重试、永久失败和取消。语音转文本提供商的选择取决于集成方式、运营边界和就绪状态。最后，必须通过受控的服务器响应测试状态机，以确保重试逻辑正确无误。