智能体在支付授权时超时，结果可能已经提交、已被拒绝，或仍然未知。恢复流程必须先查明真实状态，再决定是否继续操作，以及应该怎样告诉用户。

为什么需要这个 Skill

智能体工作流会串联工具、服务和用户通知。某一步可能已经写入状态，后续步骤却还没完成。智能体故障恢复测试 Skill 帮团队记录并核对这段流程中的证据，再决定重试、对账、补偿、升级或停止。

Skill 能帮助你做什么

根据项目实际提供的证据建立故障矩阵：

故障已确认的写入状态是否可重试恢复动作恢复后状态与证据
暂态故障，且确认未写入权威来源和完整查询范围确认没有已提交副作用仍需符合策略使用原操作身份重试或轮询核对最终副作用和用户通知
永久拒绝已确认拒绝不应原样重复停止并说明情况或升级保留拒绝记录与交接信息
超时导致结果不明尚未确认是否提交不能假设安全重放按操作 ID 或幂等键查询，再遵循契约对账完成前保持未决
工作流部分成功部分步骤已提交取决于其余步骤对账已完成和待完成步骤；只有协议允许时才补偿核对每一步以及补偿结果

每项发现用 AFR-## 编号，并关联故障点、证据、恢复选择、用户可见结果、负责人和关闭条件。矩阵可用于复核或设计测试，不能证明运行时已完成恢复。Awesome QA Skills: https://github.com/naodeng/awesome-qa-skills 按语言和测试阶段组织 Skill。系列总览：https://inaodeng.com/zh-cn/blog/ai-testing/introduction_of_awesome_qa_skills/ 介绍通用安装方式。

范围与限制

本 Skill 不规定通用的重试次数、超时、回退或补偿策略。超时不能证明写入未发生，也不能据此授权退款或回滚；缺少日志时更不能声称恢复成功。具体策略由系统负责人确认，运行时结论则需要运行记录和状态证据。

应检查哪些恢复问题

恢复问题要核对的证据支持的决策
故障确定性操作被拒绝、从未发出、已接受，还是结果不明？分类为暂态、永久或未知
已完成写入故障前有哪些步骤已经提交？避免重复已完成的副作用
重试安全性按契约能否复用原操作 ID 或幂等键？决定重试、轮询或暂缓并对账
补偿条件是否有获批协议允许撤销已完成步骤？仅在获得授权时补偿，否则升级
用户沟通系统能向用户证明哪种状态？只有证据支持时才说处理中、已完成、失败或复核中
恢复证据日志、状态迁移、尝试次数和用户通知是否一致？决定验证关闭还是保留证据缺口

不能只凭“重试成功”就判定恢复完成。还要比较操作前后的状态、尝试次数、副作用、资源和用户看到的结果。

设计恢复测试前先审计输入

所需材料复核用途缺失时的处理
工作流步骤与故障注入点找出可能部分完成的位置只围绕已知步骤界定场景
操作 ID、请求 ID 或幂等键找回首次尝试和已提交副作用契约没有安全路径时，不重放状态不明的写入
重试、回退与补偿策略判断哪些恢复动作被允许交给策略负责人确认，不自行选择
状态来源与用户消息对比系统真实状态和智能体报告缺日志或状态时标为未验证
停止条件与升级负责人避免无限重试和未授权修复记录谁接管以及继续前的阻塞条件

分别记录事实、假设、冲突、过期记录和范围外步骤。证据不足会限制结论，但本身不能证明产品存在故障。

案例：订单智能体在支付授权时超时

以下是设计示例，未实际执行支付测试：智能体发出一次授权请求后超时，尚未收到结果，订单状态仍为 pending。

恢复步骤

  1. 保留原操作 ID、幂等键、超时记录和尝试次数。
  2. 再次写入前，在获准的访问范围内使用这些标识查询支付服务商和内部账本。
  3. 如果确认已授权，就对账订单状态并按流程文档继续确认。不要为了让订单看起来完整而再次扣款。
  4. 如果服务商查不到操作，按契约使用原身份决定是否重试。若数据源有延迟或不完整，暂时没有查询结果并不能证明操作失败。
  5. 如果记录冲突或仍无法判断，就停止自动重放，附上双方记录并升级处理。
  6. 用户通知只陈述证据支持的内容，例如支付状态核验期间订单仍在确认中。

如果工作流只完成了一部分，分别列出已经完成和待处理的步骤。退款等补偿需要获批协议与有权负责人；记录补偿结果，若补偿失败则升级。

示例发现

以下字段用于演示记录方式，并非真实故障或运行结果：

字段示例
编号与场景AFR-01 —— 支付授权超时，订单智能体尚未收到结果
已确认写入状态服务商与内部记录完成对账前为 UNKNOWN
是否可重试与恢复动作UNASSESSED；任何重放前先查询原操作
用户影响与优先级写明证据支持的影响；应用项目标准前为 NOT_SCORED
负责人和停止条件指定支付或工作流负责人；提交状态不明时停止自动重放
关闭条件尝试历史、支付和订单状态、恢复动作及用户通知相互一致且可复核

示例和建议不能写成已确认的故障或成功恢复；缺少日志时也应保留证据缺口。

交接给下一阶段

交接字段应包含内容
故障记录故障点、分类、操作身份、时间戳和尝试次数
写入状态已确认完成、已确认未发生、部分完成或仍不确定，并链接来源
恢复决策重试、轮询、对账、补偿、升级或停止，以及对应策略依据
用户结果实际显示的通知，以及支持该通知的证据
发现AFR-##、影响依据、负责人、停止条件和关闭条件
验证前后状态、副作用数量、日志，以及适用时的补偿结果

只有系统状态和用户看到的结果都与证据一致，才能将恢复标为已验证。若存在差异，应交接问题并保持未关闭。

相关 Skill

容易踩的坑

  1. 把超时当成没有写入的证明。
  2. 没查首次尝试的副作用就重放。
  3. 对永久拒绝的操作原样重试。
  4. 没有协议和负责人授权就建议补偿。
  5. 只确认工作流的一步，就告诉用户任务已经完成。

安装与调用

安装单个 Skill，并提供工作流契约和真实证据来源：

npx skills add https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh --skill agent-failure-recovery-testing

请求复核时，按源提示词提供故障矩阵和发现字段：

请使用 agent-failure-recovery-testing Skill。

任务：评估支付授权期间超时的订单智能体
输入：[工作流契约、操作 ID、服务商响应、日志、状态查询]
范围：[纳入或排除的步骤与副作用]
未知项：[缺失的策略、证据来源、权限或负责人]
期望输出：[按风险排序的 AFR-## 发现、恢复矩阵、证据状态和下一步动作]

区分已确认写入和假设。不要把建议写成已经执行的恢复。

常见问题

没有服务商日志还能开始做恢复测试吗？

可以先做范围受限的设计复核，列出判断未写入、已写入、部分完成或状态不明所需的材料。拿到记录前，运行时恢复仍未验证。

什么时候重试不安全？

首次写入可能已提交，而契约又没有安全重放路径时。先检查原操作，再按重试策略处理或升级。

部分失败都应该补偿吗？

不应该。补偿可能再产生一种业务副作用；只有获批协议和有权负责人允许时才执行，并单独核验结果。

参考

源 Skill 与执行契约

智能体故障恢复测试提示词：https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/agent-failure-recovery-testing/prompts/agent-failure-recovery-testing.md；定义了工作流程和输出契约。源目录：https://github.com/naodeng/awesome-qa-skills/tree/main/skills/zh/testing-types/agent-failure-recovery-testing；包含入口文件与配套材料。

安全测试白盒测试背靠背测试本地化测试边界测试
分享