智能体内省调试 是做什么的？
当智能体运行反复失败、消耗Tokens却无进展、在相同工具上循环、或偏离预期任务时，请使用此技能。
这是一个工作流技能，而非隐藏运行时。它教会智能体在升级给人处理之前，先系统性地自我调试。
何时激活
- 达到最大工具调用/循环限制失败
- 重复重试却毫无前进
- 上下文膨胀或提示漂移导致输出质量下降
- 文件系统或环境状态与预期不匹配
- 可通过诊断和小范围纠正行动恢复的工具故障
范围边界
激活此技能用于：
- 在盲目重试前捕获失败状态
- 诊断常见的智能体特定故障模式
- 执行受控的恢复操作
- 生成结构化的、可人工阅读的调试报告
不要将此技能用作以下方面的主要来源：
- 代码变更后的功能验证；请使用
verification-loop - 当已存在更具体的ECC技能时的框架特有调试
- 当前 harness 无法自动强制执行的运行时承诺
四阶段循环
阶段 1：故障捕获
在尝试恢复之前，精确记录故障。
捕获：
- 错误类型、消息和堆栈跟踪（如有）
- 最后有意义的工具调用序列
- 智能体当时试图做什么
- 当前上下文压力：重复的提示、过大的粘贴日志、重复的计划或失控的笔记
- 当前环境假设：cwd、分支、相关服务状态、期望的文件
最小捕获模板：
## 故障捕获
- 会话/任务：
- 进行中的目标：
- 错误：
- 最后成功步骤：
- 最后失败的工具/命令：
- 观察到的重复模式：
- 需验证的环境假设：
阶段 2：根因诊断
在改变任何东西之前，将故障与已知模式匹配。
| 模式 | 可能原因 | 检查项 |
|---|---|---|
| 达到最大工具调用/重复相同命令 | 循环或无退出观察路径 | 检查最近的N次工具调用是否重复 |
| 上下文溢出/推理退化 | 无限制的笔记、重复的计划、过大的日志 | 检查近期上下文中的重复和低信号批量内容 |
ECONNREFUSED / 超时 | 服务不可用或端口错误 | 验证服务健康状态、URL和端口假设 |
429 / 配额耗尽 | 重试风暴或缺少退避策略 | 计算重复调用次数并检查重试间隔 |
| 写入后文件丢失/陈旧差异 | 竞态、错误的cwd或分支漂移 | 重新检查路径、cwd、git状态和文件实际存在性 |
| “修复”后测试仍失败 | 错误假设 | 隔离确切失败的测试并重新推导bug |
诊断问题：
- 这是逻辑失败、状态失败、环境失败还是策略失败？
- 智能体是否失去了真实目标，转而优化错误的子任务？
- 故障是确定性的还是瞬时的？
- 能够验证诊断的最小可逆操作是什么？
阶段 3：可控恢复
以改变诊断面的最小操作进行恢复。
安全恢复操作：
- 停止重复重试，重新陈述假设
- 修剪低信号上下文，仅保留活跃目标、阻碍因素和证据
- 重新检查实际的文件系统/分支/进程状态
- 将任务缩小到一个失败的命令、一个文件或一个测试
- 从推测性推理切换到直接观察
- 当故障高风险或外部阻塞时，升级给人处理
不要声称未经支持的自愈操作，如“重置智能体状态”或“更新 harness 配置”，除非你在当前环境中通过真实工具实际执行了这些操作。
可控恢复检查清单：
## 恢复操作
- 选择的诊断：
- 采取的最小操作：
- 为什么这是安全的：
- 什么证据可以证明修复生效：
阶段 4：内省报告
以报告结束，让下一个智能体或人类能够理解恢复过程。
## 智能体自调试报告
- 会话/任务：
- 故障：
- 根因：
- 恢复操作：
- 结果：成功 | 部分成功 | 受阻
- Token/时间燃烧风险：
- 需要后续跟进：
- 稍后要编码的预防性变更：
恢复启发式
优先按以下顺序进行干预：
- 用一句话重新陈述真实目标。
- 验证世界状态而非相信记忆。
- 缩小失败范围。
- 运行一次区分性检查。
- 然后才重试。
不良模式：
- 以略微不同的措辞重试同一操作三次
良好模式：
- 捕获故障
- 分类模式
- 运行一次直接检查
- 仅当检查支持时才更改计划
与ECC集成
- 如果恢复后代码发生变更，请使用
verification-loop。 - 当故障模式值得转化为本能或后续技能时，请使用
continuous-learning-v2。 - 如果问题不是技术故障而是决策模糊，请使用
council。 - 如果故障源自冲突的本地状态或仓库漂移，请使用
workspace-surface-audit。
输出标准
当此技能激活时，不要仅以“我修复了它”结束。
始终提供：
- 故障模式
- 根因假设
- 恢复操作
- 证明情况现已改善或仍受阻的证据