‹ 首页

failure-recovery

@owl-listener · 收录于 5 天前 · 上游提交 1 个月前

What happens when an agent fails — retry, fallback, escalate, or graceful degradation.

适合你,如果正在构建可靠的多步骤 agent 工作流

/ 通过 npx 安装 校验哈希
npx oh-my-skill add owl-listener/ai-design-skills/failure-recovery
/ 通过 bash 安装
curl -fsSL https://oh-my-skill.com/install.sh | bash -s -- owl-listener/ai-design-skills/failure-recovery
/ 已经装过?验证本机副本,不用重装
npx oh-my-skill verify owl-listener/ai-design-skills/failure-recovery
安装目标可用 --agent / --scope 或 --to 明确指定;省略时只会在唯一已存在的 agent 目录上自动选择,零命中或多命中会停止并提示。content_hash 缺失或不一致均拒装。
144GitHub stars
~589上下文体积 · 单文件
索引托管

怎么用

商店整理自技能原文 · 版本 f41b650 · 表述以原文为准
它做什么

装上后,Claude 在遇到网络超时、工具错误等失败时会自动尝试重试、改用备用方案、升级处理、输出部分结果或撤销已做工作,让失败变成优雅绕行。

什么时候触发

当单个智能体崩溃、超时或输出无效,或智能体间传递丢失上下文,或外部工具/API不可用,或一个失败导致下游失败时触发。

装好后可以这样说
触发透明恢复
触发参与式恢复
触发坦诚失败
技能原文 SKILL.md作者撰写 · MIT · f41b650

Failure Recovery

Agents fail. Networks time out, models hallucinate, tools error, and edge cases surprise. Failure recovery design determines whether a failure becomes a dead end or a graceful detour.

Failure Types in Multi-Agent Systems
  • Agent failure: A single agent crashes, times out, or produces invalid output
  • Handoff failure: Context is lost or corrupted during transfer between agents
  • Coordination failure: Agents conflict, deadlock, or produce inconsistent results
  • Resource failure: External tools, APIs, or data sources are unavailable
  • Cascading failure: One agent's failure causes downstream agents to fail
Recovery Strategies
  • Retry: Try the same operation again. Works for transient errors (network timeouts, rate limits). Set a retry limit to avoid infinite loops.
  • Fallback: Switch to an alternative approach. A different agent, a simpler method, or a cached result.
  • Escalation: Pass the problem to a more capable agent or to a human. Used when the failure is beyond the current agent's ability to resolve.
  • Graceful degradation: Deliver a partial result rather than nothing. Tell the user what worked and what didn't.
  • Compensation: Undo the effects of a partially completed workflow before retrying or escalating.
Designing Recovery Paths

For each point in the workflow where failure is possible:

  • What could fail? List the failure modes
  • What's the first recovery strategy? Usually retry for transient errors
  • What's the fallback? If retry fails, what's the alternative?
  • When do you escalate? After how many retries or what type of failure?
  • What does the user see? Transparent about the failure or silently recovered?
  • What's the worst case? If all recovery fails, what's the graceful degradation?
User Experience of Failures
  • Invisible recovery: The system retries or falls back without the user noticing. Best for minor, quickly resolved failures.
  • Transparent recovery: The system tells the user something went wrong and how it's handling it. "This is taking longer than usual — trying an alternative approach."
  • Participatory recovery: The system asks the user to help. "I couldn't access your calendar. Can you check the connection?"
  • Honest failure: The system tells the user it can't complete the task and explains why. Offers alternatives.
Design Artefacts
  • Failure mode inventory per agent and per handoff
  • Recovery strategy specifications (retry limits, fallback paths, escalation triggers)
  • Cascading failure analysis
  • User experience specifications for each failure scenario
  • Recovery testing protocols
按 MIT 许可原样转载,未经改动 · 在 GitHub 查看 →

评论

登录即可评论;带「已验证安装」的,是发布者名下有本店的安装或持有记录。