Agent QA 失败结果分类Triage基于证据的 Agent QA 运行故障研判指南【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,115 agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址: https://gitcode.com/gh_mirrors/an/agentic-awesome-skills在 Agentic Awesome SkillsAAS仓库的 testing 类技能体系中agent-qa-result-triage是连接「证据采集」与「定位修复」的关键一环它解决的是「一次失败的 Agent QA 运行到底应该归因到哪一类问题、该由谁负责、下一步做什么」。本文基于 plugins/agentic-awesome-skills-claude/skills/agent-qa-result-triage/SKILL.md 及配套分类参考 references/triage-categories.md 展开并结合仓库中相邻的 authoring / debug-fix 技能与数据目录中的元数据给出可直接落地的研判流程。读完本文你将掌握如何从运行记录run、制品artifacts、步骤结果与日志中提取证据如何从八个固定分类中「只选一个」给出结论如何声明置信度、所有权归属与下一步行动以及何时移交到修复阶段。技能定位用证据代替猜测agent-qa-result-triage的核心主张非常明确对一次失败的 Agent QA 运行进行分类必须基于其记录的证据而不是靠直觉猜测。技能的元描述frontmatter 中的description将其概括为通过 MCP 证据、制品、日志、固定的失败分类、置信度与可执行的下一步行动对失败的 Agent QA 运行进行分流Triage。在 data/catalog.json 的技能目录条目中该技能被标记为category: testing、risk: safe触发词triggers覆盖testing、qa、triage、mcp、failed runs、evidence、artifacts、logs等说明它面向的是 QA 运行失败后的第一道研判工序且属于不修改任何代码/配置的低风险操作。它适用的场景包括四类典型情况正在调查一次失败或中断的 Agent QA 运行需要检查运行制品、步骤结果或执行日志需要对比近期相关运行识别反复出现的失败模式需要决策一次失败究竟属于test测试、product产品、hook钩子、browser/mobile runtime浏览器/移动端运行时还是 infrastructure基础设施的所有者。证据优先的六步工作流技能给出了严格按证据采集顺序推进的研判流程任何一步的省略都会降低结论的可信度从运行入口开始调用agent_qa_get_run获取运行状态、套件子上下文suite child context、步骤与重试次数attempts。先采集证据再下结论至少从以下四个 MCP 工具中获取证据agent_qa_get_run_artifact—— 读取运行制品截图、DOM/无障碍上下文、设备日志等agent_qa_get_run_steps—— 读取逐步执行结果agent_qa_get_run_logs—— 读取常规运行日志agent_qa_get_run_execution_logs—— 读取执行层日志含 stderr、运行时错误。调用分类器并以此为默认结论调用agent_qa_classify_failure将其输出的类别作为默认分类除非有更强的证据与之矛盾。横向对比近期运行当分类器输出中带有近期相关运行记录时进行对比识别复发模式。输出精简的分流结论包含 类别category、置信度confidence、证据evidence、可能的修复面likely fix area、下一步行动next action五个要素。交接修复阶段如果需要修改代码在分流完成后切换到 agent-qa-debug-fix。从该技能与 agent-qa-debug-fix/SKILL.md 的分工可以看到完整闭环agent-qa-result-triage的职责止步于「证据化分类与移交」而agent-qa-debug-fix负责「把分类器当作假设hypothesis而非判决检查相关本地源码做最小改动并验证」。因此分流阶段严禁越过边界直接改测试或产品代码。八大失败分类及其判定依据技能明确要求只从references/triage-categories.md中选取恰好一个分类。八个分类并非平行罗列而是按照「先运行时、后应用层、再环境层」的思路组织的证据判据。下表为分类参考文件的完整内容附上每类的首选检查点First Checks分类适用情形Use When首选检查点First Checkstimeout运行或某步骤超过超时时间运行失败摘要、步骤耗时、日志appium_startupAppium 启动失败或未能获取移动端会话失败摘要、执行日志、制品中的运行时错误browser_disconnect浏览器、页面或上下文意外关闭包含browser closed或target closed的错误日志element_not_found定位器、元素、选择器或 UI 描述不可用失败步骤错误、观察记录、截图、DOM/无障碍上下文assertion_failure应用可达但期望的内容或状态不匹配失败的断言/验证步骤、观察记录、截图hook_failure设置setup、清理teardown或钩子执行阻塞了运行钩子日志、钩子制品区段、钩子注册表错误infrastructure网络、Docker、farm、设备、文件系统或服务依赖失败执行日志、stderr、制品中的运行时错误unknown_failure证据不足以支持更强的分类缺失的区段与下一步需要采集的证据这个分类体系的价值在于可操作性每个分类都对应明确的证据来源。例如browser_disconnect不应仅凭「页面打不开」就下结论而必须看到含browser closed/target closed的日志element_not_found则需要失败步骤错误、观察记录、截图或 DOM/无障碍上下文中的至少一项infrastructure则需要执行日志、stderr 或制品运行时错误中的环境层证据。当证据不足以支撑任何更强分类时如实选择unknown_failure并在结论中明确「缺失了哪些证据区段、下一步应采集什么」。注意分类标识的是最可能的失败面failure surface而非已证明的根因root cause。这在技能 Limitations 中被明确强调。证据规则可引用的边界与脱敏义务为了让分类结论可复核、可追溯技能对证据的使用划定了硬性边界引用或概括真实证据必须引用或概括具体的制品、日志或步骤证据而不是空泛描述诚实声明证据缺口当制品区段缺失、影响置信度时必须在结论中点名禁止虚构证据不得编造 MCP 未返回的截图、视频、日志或记忆上下文回退路径当 MCP 不可用时允许改用仪表盘 REST API 或 Agent QA CLI 输出作为回退并明确声明哪些证据不可用脱敏义务必须从报告中移除凭据、会话令牌、个人数据以及与主题无关的应用内容。这条规则与该技能risk: safe的定位一致——它只读取和研判不产生变更因此证据的「可采信度」完全取决于上述纪律。相比之下下游的agent-qa-debug-fix因涉及修改代码与重跑测试在目录中被标记为risk: critical其证据纪律更严格不得仅凭制品推断补丁、必须直接检查相关本地文件、修复前优先调用agent_qa_validate_test/agent_qa_validate_suite/agent_qa_validate_definition验证 YAML。输出示例一次element_not_found的标准分流技能提供了一个 JSON 形式的分流结果模板用于保证输出结构的稳定与可机器解析{ category: element_not_found, confidence: high, evidence: [Step 4 could not resolve the described checkout button], likely_fix_area: test definition or changed product UI, next_action: Inspect the captured UI context, then compare the current checkout screen }拆解这个示例可以看到分流的产出标准category恰好一个分类此处为element_not_foundconfidence显式声明置信度等级high/medium/low等——当截图、DOM/无障碍上下文、设备日志或历史运行缺失时必须下调置信度evidence指向具体可复核的制品证据此处为第 4 步的失败事实likely_fix_area指出最可能的修复归属面如「测试定义或产品 UI 变更」next_action给出证据支撑的下一步行动例如「检查捕获的 UI 上下文再对比当前结账页面」。局限性置信度与边界的诚实声明技能明确列出四类限制这些限制也是使用者判断结论可靠性的标尺结论上限取决于证据留存分类的可靠性不会超过保留下的运行制品与日志类别≠根因失败类别只锁定最可能的失败面不能证明根因证据缺失必须降级截图、DOM/无障碍上下文、设备日志或历史运行的缺失都必须降低置信度只读边界本技能不修改测试或应用代码授权修复需切换到agent-qa-debug-fix。在技能体系中的衔接从作者到分流到修复要正确使用该技能需要理解它在 AAS testing 类技能中的位置。以 agent-qa-authoring/SKILL.md 为代表的「上游」负责创建合法的测试/套件/钩子定义其配套契约文件 agent-qa-contracts.json 定义了 ID 生成规则t_/s_/h_/r_/obs_前缀 10 个 id-agent 词以及测试/套件/钩子的必填与可选键——这保证了失败运行中的 run ID、test ID 都是可校验的规范标识agent-qa-result-triage位于「中游」消费这些 ID 对应的证据并产出分类agent-qa-debug-fix位于「下游」仅在授权范围内对likely_fix_area指向的本地定义或代码做最小修复并重跑最窄范围的验证。从仓库文件结构看三个技能在同一skills/目录下以独立技能包形式组织各含SKILL.md与可选的references/目录共享同一套 MCP 工具命名agent_qa_get_run、agent_qa_classify_failure、agent_qa_validate_*等与分类假设传递语义triage 把分类器输出当作默认结论debug-fix 则把它当作待验证的假设。理解这一差异是避免「分类即定案」误用的关键。落地建议把分流做成可审计的环节综合技能文档与仓库元数据在实际 Agent QA 工作流中落地该技能时建议固化证据采集顺序先agent_qa_get_run拿到运行骨架再按 artifact → steps → logs → execution_logs 的顺序补齐证据最后才允许agent_qa_classify_failure参与结论强制单分类输出遵循triage-categories.md的「恰好一个分类」约束避免「既是超时又是元素未找到」这类无法执行的模糊结论把置信度与证据缺口绑定在分流报告中显式列出缺失的证据区段无截图、无 DOM 上下文、无历史运行等并在这些情况下主动下调置信度明确交接触发条件结论中likely_fix_area指向代码或 YAML 时按流程移交 agent-qa-debug-fix只有unknown_failure时下一步行动应为「补充证据采集」而非「盲目修复」全程遵守只读与脱敏该技能只读不改报告中不留凭据与敏感应用数据这一边界是它被标记为risk: safe的前提也是分流环节可以放心自动化执行的基础。【免费下载链接】agentic-awesome-skillsAAS Core is the local, agent-first control plane for complete catalog discovery, agent-owned selection, stack validation, and planning, backed by 2,115 agentic skills. Includes CLI, local MCP, catalog, plugins, and Workbench.项目地址: https://gitcode.com/gh_mirrors/an/agentic-awesome-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考