用途：当用户要求“QA 一个 PR”“测试 PR 变更”“验证 PR 可用”“对变更做功能测试”，或自动化流程需要验证 PR 时使用。目标是像严谨的人工 QA 工程师那样实际使用软件，而不是只跑测试或读代码。
主要能力：按四个阶段推进。阶段一理解变更：阅读 PR 的 diff、标题与描述，确定目标，读取关联 issue，将改动文件分类为新功能、缺陷修复、重构、配置/CI/文档，并找出用户交互入口，形成假设。阶段二搭建环境：按仓库自身文档（AGENTS.md、README、Makefile、package.json、pyproject.toml、Cargo.toml 等）安装依赖并构建，查看 CI 状态但不自行重跑测试。阶段三实际运行变更行为：启动应用、CLI 或服务器，发真实 HTTP 请求、运行真实命令、打开真实浏览器页面；前端改动需启动开发服务器并用真实浏览器验证、截图与录制关键交互（优先 GIF），必要时做前后对比；CLI 改动用真实参数运行并捕获 stdout/stderr；API 改动验证状态码、响应体与副作用；缺陷修复做修复前后对比；库/SDK 改动写脚本调用；重构验证关键路径行为不变；配置/CI/文档做语法与构建校验。阶段四用 GitHub API 以 PR review 形式发布结构化报告，包含结论、状态表、可折叠证据块与问题列表。
限制与注意：不运行测试套件、linter、格式化或类型检查（属 CI 职责），不做代码审查式分析；--help、--dry-run、--version 不算功能验证；同一方法三次不同尝试失败后应换方法，两种根本不同方法都失败则放弃并在报告中说明；无法验证时须如实说明，不得伪造。前端媒体不要推送到 PR 分支，可存到运行产物目录（如 GitHub Action 中的 $GITHUB_WORKSPACE/output/）。结论取值包括 PASS、PASS WITH ISSUES、FAIL、PARTIAL。具体安装命令与平台支持等细节暂未提供。