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