resilient-execution

概述

resilient-execution 技能通过强制要求至少尝试 3 种确实不同的方法，然后才向用户升级处理，避免过早失败。它提供结构化的错误分类系统、方法级联方法，以及对每次尝试的透明记录。没有这项技能时，Agent 会过早放弃；有了它，Agent 就能系统地穷尽各种替代方案，并且只在掌握完整证据后才升级处理。

开始时声明：“我正在使用 resilient-execution 技能——在升级处理之前，我会尝试多种方法。”

---

阶段 1：错误分类

一种方法失败时，应立即对错误进行分类，然后再重试：

错误类型	定义	指标	正确响应
瞬时错误	临时基础设施故障	网络超时、速率限制、503 错误、锁争用	短暂等待，然后使用相同方法重试
环境错误	依赖项缺失或配置错误	找不到模块、版本错误、缺少环境变量、权限被拒绝	修复环境，然后使用相同方法重试
逻辑错误	方法错误或假设不正确	输出错误、行为异常、类型不匹配、API 使用错误	彻底重新考虑方法
根本性问题	使用现有工具确实无法实现	API 不存在、硬件限制、缺少能力	提供证据并向用户升级处理

在告知用户某事无法完成之前，你必须至少尝试 3 种不同的方法。没有证据证明你以有实质差异的策略进行了 3 次真正的尝试，就不能只说“我试过了，但没成功”。

停止：选择下一种方法前，先对错误进行分类。错误分类会导致无谓的重试。

---

阶段 2：方法级联

系统地执行级联流程。每次尝试都必须采用确实不同的策略。

Attempt 1: Primary approach (most direct solution)
    | fails
    v
Classify error -> Can same approach work with a fix?
    | YES -> Fix and retry (does NOT count as a new attempt)
    | NO  -> Proceed to Attempt 2
    v
Attempt 2: Alternative approach 1 (different technique)
    | fails
    v
Classify error -> Is this fundamentally blocked?
    | YES -> Proceed directly to escalation
    | NO  -> Proceed to Attempt 3
    v
Attempt 3: Alternative approach 2 (different path entirely)
    | fails
    v
Circuit breaker -> Present findings to user with full evidence

每次尝试都要记录：

### Attempt N: [Approach Name]
**Strategy:** [what makes this different from previous attempts]
**What I tried:** [specific description with commands/code]
**What happened:** [exact error or unexpected result]
**Why it failed:** [root cause analysis]
**Classification:** [Transient / Environmental / Logical / Fundamental]
**What to try next:** [reasoning for next approach]

停止：进行下一次尝试前，记录每一次尝试。不要跳过记录——这些记录是升级报告的证据。

---

阶段 3：选择替代方法

主要方法失败时，使用此决策表选择下一种方法：

失败类型	策略 1	策略 2	策略 3
库/API 无法正常工作	使用其他库	直接实现（不使用库）	Shell 命令/外部工具
算法产生错误结果	使用其他算法	拆分为更小的步骤	简化约束，解决较容易的版本
权限/访问被拒绝	使用其他访问方法	提供手动步骤并升级处理	通过替代路径绕过
工具限制	使用其他工具	组合使用多个工具	提供手动说明
集成失败	模拟依赖项	使用替代接口	单独隔离并测试组件
性能问题	使用其他数据结构	批处理/流处理	使用近似解

替代策略优先级

按以下优先顺序尝试：

1. 使用其他工具 — 改用其他库、API 或命令
2. 使用其他算法 — 以不同方式解决同一问题
3. 拆分问题 — 将问题拆分为更小、可解决的部分
4. 简化问题 — 移除约束，先解决更简单的版本
5. 绕过问题 — 完全通过其他路径实现目标
6. 手动步骤 — 提供用户可自行遵循的明确说明

---

阶段 4：升级报告

使用不同方法进行了 3 次真正的尝试后，生成此报告：

## Execution Report

I tried 3 different approaches to [goal]:

### Attempt 1: [Approach Name]
**Strategy:** [description]
**Result:** Failed because [specific reason]
**Error:** [exact error message or unexpected output]

### Attempt 2: [Approach Name]
**Strategy:** [description]
**Result:** Failed because [specific reason]
**Error:** [exact error message or unexpected output]

### Attempt 3: [Approach Name]
**Strategy:** [description]
**Result:** Failed because [specific reason]
**Error:** [exact error message or unexpected output]

### Root Cause Analysis
[Why all three approaches failed — identify the common blocker]

### Recommended Next Steps
- **Option A:** [what the user could try]
- **Option B:** [alternative path]
- **Option C:** [if applicable]

### What I Need From You to Proceed
[Specific ask — access, information, permission, or decision]

停止：没有此报告，不要升级处理。用户需要看到 3 次真正尝试的证据。

---

决策表：何时重试才算“真正尝试”

算作真正尝试	不算
使用不同的库或工具	使用同一库，只是更换导入方式
使用不同的算法或数据结构	使用同一算法，只调整参数
采用不同的架构方案	使用同一方案，只做少量代码修改
使用手动变通方案，而非自动化方案	使用同一自动化方案，只添加重试循环
将问题拆分为多个子问题	使用同一整体方案，只添加日志
使用完全不同的 API	使用同一 API，只更换身份验证方式（除非错误由身份验证引起）

---

反模式／常见错误

不要这样做	这样做为何会失败	应该怎么做
用同一方案重试 3 次，并称之为“3 次尝试”	同一方案会导致同一失败。这不是真正的替代方案。	每次尝试都必须采用有实质区别的策略
失败 1 次后就放弃	错过 2 种或更多可行方案	始终尝试至少 3 种真正不同的方案
跳过错误分类	不分类就会重试错误的事项	在选择下一种方案之前先分类
向用户隐瞒失败的尝试	缺少背景信息，用户无法提供帮助	记录并透明地报告每次尝试
未尝试手动变通方案就升级处理	许多自动化操作失败的事项，手动操作却能成功	始终将手动步骤作为方案 3 加以考虑
未经调查就归咎于平台	“平台限制”往往是错误判断	宣布无法实现之前，先搜索变通方案
修复环境问题后将其算作新尝试	修复环境后重试同一方案，仍只算 1 次尝试	只统计真正不同的策略
跳过中间尝试的日志记录	会丢失证据链，无法生成升级报告	立即记录每次尝试

---

防止自我合理化的提醒

想法	事实
“这真的无法实现”	你尝试过 3 种不同方案了吗？很可能没有。
“错误很明确，我知道问题出在哪”	明确的错误也可能有隐藏的根本原因。请调查。
“我已经试过所有办法了”	列出你尝试过的办法。总还有其他选择。
“用户应该自己解决这个问题”	提供手动操作路径，但先尝试 3 种方案。
“这是平台限制”	限制往往有变通方案。请搜索一下。
“同样的错误一直出现”	不同方案出现同样的错误，可能意味着根本原因不同。请分类。
“这花的时间太长了”	如果用户必须从头开始，放弃会花更长时间。
“更简单的版本没有用”	能正常运行的简单版本，胜过无法运行的复杂版本。

未进行 3 次真正尝试，不要升级处理。绝不例外。

---

集成点

技能	关系
circuit-breaker	在 resilient-execution 用尽循环级重试后激活
task-management	任务步骤失败时调用 resilient-execution
self-learning	记录失败模式，以避免在后续会话中重复犯错
planning	利用失败历史选择更稳健的方案
auto-improvement	跟踪重试成功率和方案有效性
verification-before-completion	验证失败时调用 resilient-execution

---

具体示例

示例：文件解析失败

Attempt 1: JSON.parse() on the file
  Result: SyntaxError — file contains comments (JSONC format)
  Classification: Logical — wrong parser for this format

Attempt 2: Strip comments with regex, then JSON.parse()
  Result: Failed — nested block comments not handled
  Classification: Logical — regex too simple for comment stripping

Attempt 3: Use `jsonc-parser` library (handles JSONC natively)
  Result: Success — file parsed correctly

示例：API 集成失败

Attempt 1: Direct HTTP request to API endpoint
  Result: 403 Forbidden — authentication required
  Classification: Environmental — missing auth config

  Fix: Add API key from .env
  Result: 429 Too Many Requests — rate limited
  Classification: Transient — wait and retry
  Result: 200 OK but response format changed from docs
  Classification: Logical — API version mismatch

Attempt 2: Use official SDK instead of raw HTTP
  Result: SDK throws "unsupported region" error
  Classification: Environmental — region config needed

Attempt 3: Use GraphQL endpoint instead of REST
  Result: Success — GraphQL endpoint supports all regions

---

核心原则

• 绝不默默放弃——始终展示尝试过的方案
• 真正的替代方案——每次尝试都必须采用有实质区别的方案，而不是只对同一方案做少量调整
• 根本原因分析——尝试下一种方案之前，先弄清楚原因
• 从失败中学习——将哪些方法无效及其原因更新到记忆中
• 保持透明——在每一步都向用户展示你的推理
• 先分类——错误类型决定是重试同一方案还是尝试新方案

---

技能类型

RIGID — 至少尝试 3 次是硬性门槛。每次重试前都必须进行错误分类。必须严格遵循升级报告格式。无论任务看起来多简单，都不得放宽这些要求。