用途：当用户询问某次测试或测试运行为何通过/失败、重复运行中某次结果为何不同、运行中使用了哪些流程或工具，或需要测试套件历史摘要时使用。目标是像解释对话一样解释测试运行：哪些流程被触发、调用了哪些工具、逐轮发生了什么。
接口与凭据：主机为 https://api.elevenlabs.io，请求头 xi-api-key: $API_KEY。工程师需提供 $API_KEY 和 $AGENT_ID。
调查顺序：先列出近期运行，获取最近的套件调用（可按 agent 过滤），定位目标调用并跨时间比较；对比近期调用可找出反复失败的“高频问题”测试。然后读取调用：GET /v1/convai/test-invocations/{suite_id} 返回 test_runs[]，每项含 status、condition_result.result 和 condition_result.rationale。多数“为何失败”问题看 rationale 即可，若已指出分歧点就到此为止。仅当 rationale 过于模糊时才读取完整逐轮记录，其中包含消息、工具调用（含流程启动调用）和工具错误。若套件测试多且 repeat_count 大于 1，载荷可能超出上下文，应先检查测试与运行数量；过多时不要全量输出，改为只看法失败测试的 rationale，或引导用户到 UI 的 Tests 标签页。需要确认断言内容时，读取测试定义中的 criteria、scenario 和 mocking 配置。对重复集，比较同一测试的通过运行与失败运行：若调用了不同流程，属路由问题；若流程与工具相同，属评估或非确定性问题。
回答方式：不要只说“未满足标准 X”，而要指出失败运行在哪一轮出现差异、具体做了什么，引用被违反的标准条款，首句给出结论，整体控制在约六行以内。配置与输入相同但结果不同时，直接说明这是 LLM 非确定性，而非配置缺陷，并给出可操作修复：收紧边界模糊的标准，或把必须保证的顺序移入确定性流程。汇总套件历史时，给出总体通过/失败计数、关键问题部分（关键测试常在标题中标记，否则据上下文推断）和反复失败部分，再诊断具体失败并建议修复。
限制与诚实：若读取报错、记录被截断（检查截断标志与总轮数）或套件过大无法完整获取，应说明哪次读取失败或哪些内容被截断，并建议用户查看 UI 的 Tests 标签页；不得编造无法读取的逐轮记录，也不得把评估器 rationale 当作逐轮记录呈现。