用途：针对某个具体失败的测试做持久化、多步骤的根因调查，并记录“为什么”。它属于执行层，解决具体失败；不负责验证测试策略或架构，也不生成 QA 交付物。
主要能力：先复现与分诊，判定失败是偶发、确定性缺陷还是不可复现（分类是调查得出的结论，不是前提）；再收集日志、堆栈、截图、trace、重试次数、依赖活动与耗时等证据；随后提出并检验假设，确认根因；接着决定修复方案（测试侧或产品侧）并重复运行验证稳定性；最后确定预防复发措施。方法不绑定具体测试框架，web、API、移动、嵌入式、单元、负载测试均可套用。
使用方式：在项目根目录创建调查文件，按投入程度分级——高价值/阻塞用 plan + findings + progress 三个文件；中等用 plan + findings；低价值/外观类偶发只用 findings。核心规则包括：先创建计划；每两次读取或搜索操作后把关键发现写入 qa_investigation_findings.md；重大决策前重读计划；行动后更新阶段状态并记录错误；所有错误都记录尝试次数与解决方式；不重复失败动作；复现后再分类。敏感数据（令牌、Cookie、凭据、邮箱、PII）须脱敏后再以文字形式持久化，不要原样写入截图、trace、日志或网络抓包。
适用场景：失败偶发或确定性出现且需要根因；调查跨多次工具调用、多轮运行或多个会话；需要留存发现、决策与理由的持久记录。
限制：不用于从零编写测试、设计框架或覆盖策略、少于约 5 次工具调用的简单查询，以及非测试生产代码的常规评审。若在有限次尝试后仍无法复现，不要强行贴标签，应记录为不可复现并附部分证据、说明疑似性质（基础设施、应用逻辑或测试侧时序），再升级或标记观察。具体模板与流程细节见其 Flow、Templates、Examples 参考。