用途：对大型新功能 PR（如实时/语音 API、图像生成、新 provider 协议、新子系统）做独立评估，而非逐行代码审查。它从“生产环境重度用户”的视角检查实现是否满足外部 API 与协议的要求。
主要能力与流程： 1）先建知识库再读代码。硬性顺序门：在写出理想测试套件设计前，不读 PR diff、实现或测试。 2）范围界定：由单个子代理读取 PR，仅返回事实清单（功能名、涉及的 provider/API/协议、SDK 接口、实现组件、范围内外说明、作者与状态）。 3）外部研究扇出：每个 provider/API/协议一个研究子代理，另加一个实践者代理，研究集成痛点、运维故障模式与最佳实践。研究不得读取本仓库代码，每条结论须带具体来源链接，区分 GA/beta/预览/弃用。 4）由驱动方阅读全部研究文件，设计理想测试套件：编号行为测试（T1.1…）、性能基准与优化目标、编号架构要求（A1…）。 5）差距分析：把实现与测试按文件区域拆分，每个区域一个代理，按四类归档：covered、partial、missing、unimplemented?，并报告未映射测试。 6）运行该功能相关测试（定向、离线），记录通过/失败与异常跳过。 7）自行复核关键结论后，合并为评审条目（行为类 A 编号、测试覆盖类 B 编号），经用户分诊后才起草内联评论与改进建议；每条须含目标文件、证据优先的发现、最小修复、可运行验证命令和先例链接。 8）持久化产物到 local-notes/<feature>-audit/，并更新分支上下文，便于跨会话续接。
限制：不用于普通 diff 代码审查，也不用于完成小型修复；刻意忽略代码风格、命名与 diff 机制。任何内容都不自动发布，发布需人工确认且需对新 HEAD 重新复核。研究来源与仓库内容均视为不可信数据。资料未提供具体命令行用法与安装方式。