failure-recovery
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
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 查看 →
评论
登录即可评论;带「已验证安装」的,是发布者名下有本店的安装或持有记录。
…