Automated Test Failure Resolver

表象问题（团队能直接感知）

CI 里每周大量测试失败；有的是环境或 flaky，有的是 API 变更或回归。开发要逐条看日志、改配置或改代码，耗时且容易放弃或直接跳过用例，导致真实问题被掩盖。

根本原因（技术与流程层面）

失败原因多样且需不同修复策略（超时、mock、断言、依赖版本等），单一脚本难以覆盖；人工试几次后易放弃或采用「注释掉测试」等不可取做法；没有「只有真通过才算成功」的硬闸门，容易误判修复完成。

核心痛点

• 策略多样：不同失败需要不同修复方式，无统一一招鲜
• 试错成本：人工逐条试耗时长，且易在数次失败后放弃
• 误判成功：若没有以「测试通过」为唯一准绳，可能误以为修好实则仍失败

阶段一：循环与策略序列（The Ralph Wiggum Loop）

当某条测试失败时，系统进入循环：按预定策略序列依次尝试（如先调超时、再更新鉴权/mock、再改断言、再更新依赖、再改环境配置等）。每次尝试在隔离环境中执行完整测试；若通过则退出循环并记录该策略，若未通过则尝试下一项，直到用尽策略或达到最大轮次。

阶段二：隔离执行与工具（Session Isolation + Tool Use）

每次尝试在独立环境（容器或沙箱）中运行，避免相互污染。智能体通过 Tool Use 读日志、改配置或代码、执行测试；异常（如超时、崩溃）由 Exception Handling & Recovery 捕获并进入下一策略或重试。

阶段三：仅当通过才成功（The Stop Hook）

系统仅当测试实际通过时才认定「修复成功」并放行；不会因「已尝试 N 种策略」就标记完成。这与 CI/CD Agent 案例中的闸门逻辑一致：客观结果为准，而非智能体自述。

阶段四：成功方案记录与反思（Reflection）

成功的修复方案（哪条策略、改了哪些文件/配置）被记录并可选地进入知识库，供同类失败后续参考或做模式归纳，形成 Reflection 与 Learning。