为 SPKE 创作的 AI 生成原创编辑插画。画面是概念隐喻，并非工程图或实测结果。
丢失的回执
设想一个虚构的客服助手正在安排补发商品。应用发出了已经获准的发货请求，但连接在回执到达前断开。恢复程序切换到另一个模型，把对话交给它，要求继续完成任务。备用模型没有看到成功消息，于是又提出一次发货。
第一次发货可能已经成立。一条流畅的恢复消息，可能掩盖重复操作。危险之处在于应用决定再次执行，而不是两个模型分别来自哪个国家。
对同时使用美国和中国 AI 服务的团队，这提供了一个有用的验收问题：故障切换之后，系统能不能查清实际发生了什么？第二家供应商增加了一条生成路径，却不会自动保住整个工作流的状态。
比较行为，而不只是请求格式
三份一手资料有助于看清边界。当前 OpenAI Python SDK 文档说明，对某些请求失败默认自动重试两次，重试设置可以调整；读取过程中中断的流不会自动重试。官方 SDK
DeepSeek 文档说明了账号级并发限制，以及等待期间使用空行或 SSE 注释维持连接的机制。其中十分钟后关闭连接的条件是推理尚未开始，并非适用于所有任务的统一截止时间。限速与隔离
AWS 关于幂等 API 的文章解释了背后的分布式系统问题：没有收到响应，可能意味着完成状态仍不确定；安全重试需要服务接口的明确约定。让重试安全的设计
这些是截至 2026 年 10 月 26 日核对的文档事实，不是新发生的故障报道，也不是可靠性对比测试。它们分别描述 SDK 行为、供应商的连接处理和业务服务语义。任何一项都不能证明任意 AI 工具可以安全地重复执行。
搭配供应商之前，应记录具体端点、模型和 SDK 版本，支持的输入与工具格式、重试配置、超时行为，以及数据处理许可。请求格式看起来熟悉还不够。还应确认备用服务是否可以接收同样的文档；更换供应商不能悄悄扩大机密数据的接收范围。
把请求尝试与业务操作分开
我们建议从两类记录开始设计恢复流程。请求尝试记录一次具体的模型请求，包括供应商、模型、开始时间、结果以及可获得的请求标识。业务操作记录用户已授权的动作，包括目的、准确的已批准参数、状态和完成证据。多次请求尝试可以服务于同一项业务操作。
在虚构的发货案例中，换一个模型接手，不应改变原业务操作的身份。新生成的工具调用标识，不能被当成创建第二次发货的许可。反过来，分别获得授权的两次相同发货，也必须能够区分。
业务状态应保存在对话之外。模型可以概述记录，但执行器应在行动前检查记录。检查和取得执行权应作为原子操作完成，防止主、备工作进程同时放行。最小状态集可以包括：已计划、已提交、已确认、已拒绝和结果未知。未知是需要负责人和解决路径的真实状态，不能因为重试循环更容易编写，就把它改成失败。
如果目标服务提供幂等机制，应遵守其文档约定的适用范围、参数规则和保留窗口。仅有本地标识，并不能让远端操作自动具备幂等性。如果缺少足够的服务约定，也无法可靠核对结果，就应把结果不明的写操作暂缓并交由复核，而不是承诺“恰好执行一次”。
在真正失败的边界恢复
应区分三条恢复路径。
仅生成内容。 如果失败步骤只是起草文本，尚未提交任何业务操作，可以在获准的时间和成本预算内让另一个模型重新生成。把部分输出与替代结果分开，不要悄悄把两个不兼容的回答拼成看似连续的结果。
已知被拒绝。 如果权威证据确认业务服务拒绝了操作且没有执行，应在下一次获准尝试之前解决原因。目标地址无效或缺少权限，不能靠换一个更愿意配合的模型来修复。
写入结果不明。 如果动作已提交但回执丢失，应在可用时查询目标系统的权威操作记录。确认已完成，就复用已有结果；仍未查明，就报告不确定性，并停止对这一操作自动写入。如果查询可见性存在延迟，搜索结果为空也未必证明没有执行。
备用模型可以解释哪些事项仍待确认，也可以准备供人复核的草稿。它不应编造成功确认、重新解释授权，或自行认定那次结果未知的发货从未发生。
给恢复过程一个共同预算
重试有用，但不同层各自重试，次数可能相乘。在一个假设配置中，应用尝试三次，每次允许 SDK 尝试三次，那么在进一步切换供应商之前，就可能发出九次请求。这只是给定配置下的算术，不是实测 SDK 轨迹，也不是普遍适用的上限。
指定一个组件负责总截止时间、尝试次数预算和升级处理规则。统计实际下游尝试，而不只是最上层任务。遵守服务方的重试指引，采用适当退避，避免把过载队列立即原样重放给备用服务。不要通过更换凭据规避账号级限制。
分别衡量获得可用答案的时间，以及确认业务动作完成的时间。保活信号证明连接仍有活动，不证明任务取得了进展。同样，面向用户的超时也不能证明远端操作已被取消。恢复流程应处理迟到结果，而不是任由它们再次触发执行。
在真实客户遇到之前，先测回执丢失
使用模拟外部动作的沙箱，测试前先写好预期结果。至少覆盖这些情况：
- 生成请求失败，尚未提交任何业务操作。
- 目标系统已执行动作，但响应丢失。
- 备用模型已经给出答案，主模型才完成。
- 部分文本已经显示，流随后中断。
- 备用模型对已批准操作提出了不同参数。
- 一项操作暂时无法通过目标系统的读取接口查到。
- 恢复发生之前，目标系统的去重窗口已经到期。
每个案例都要检查外部实际结果和业务操作记录，而不只是助手最后一句话。在回执丢失的案例里，可接受结果可能是确认只执行了一次，也可能是明确标记为尚未解决、暂缓处理。第二次发货不能算恢复成功，虚假的成功消息也不能。
同时报告重复执行的结果、未解决操作和恢复耗时，以及完成率。分母应保留为原始用户任务；重试是请求尝试，不是新增的成功任务。还要记录复核工作量和供应商成本，避免让一个把一切都暂缓的设计，看起来像毫不费力的自动化。
第二家供应商应该带来什么
有用的备用方案应保留原任务的约束，同时提供另一次完成机会。对起草任务，这可能意味着替代答案；对会改变外部系统的工作流，这可能意味着可信地说明：哪些已确认，哪些仍未知，下一步必须做什么。
先选一项后果重要的动作，做一次受控的回执丢失测试。如果系统无法在不重复执行、不编造确定性的前提下恢复，那么增加模型只是先让路由图变得更丰富，还没有让工作流更可靠。
本文是 SPKE 结合所链接一手资料所作的原创工程分析。发货场景、建议的状态模型和测试方案均为说明性设计。我们没有运行供应商基准测试，没有在生产系统注入故障，也没有测量可靠性提升。部署前应核实最新文档，以及实际使用工具的接口约定。