摘要：Google在2026年10月8日开源AQuA参考实现，把“外循环”质量Agent放到生产Agent旁边，聚类失败对话、复核问题并把诊断锚定到部署源码。它没有让测试消失，反而把一个更难的问题摆到桌面：谁来定义这支质量Agent值得相信？
生产Agent每天处理成千上万段对话，返回码大多是200，传统监控没有红灯，但用户开始反复追问、绕开建议或转人工。过去，测试团队只能抽样翻日志；现在，另一支Agent可以持续聚类失败会话、验证异常，并把根因定位到当时部署的源码快照。
这不是虚构的组织故事。Google开发者博客在10月8日公开了AQuA（Ambient Quality Agent）参考实现，称其运行在生产Agent旁边，处理对话记录、失败聚类、验证与源码锚定。官方材料证明的是一种开放的工程方向，并不证明它已经替任何企业自动完成质量判断。
本文关心的不是安装命令，而是一次角色变化：当发现问题、归类问题、提出修复都能由Agent协助时，测试工程师还剩下什么？答案不在“会不会写更多自动化”，而在谁定义异常、谁校准证据、谁承担放行责任。
内循环解决“我知道要测什么”
传统回归属于内循环：需求已知、样本已知、断言已知。每次修改模型、提示词或工具，团队在合并前重跑金标集，检查能力有没有退化。这条链路很重要，但它只能验证团队已经想过的风险。
生产环境的问题恰恰来自未知组合。用户会省略信息、改变目标、混合多个任务；工具数据会漂移，权限与库存会变化；模型可能在某种长对话中突然走捷径。HTTP监控只能看到服务可用，无法判断“回复是否悄悄变差”。
外循环的意义，是从真实流量发现新模式：先用信号筛出异常会话，再聚类相似失败，抽取代表样本，复核是否真问题，随后定位到部署版本与源码，最后把确认过的样本送回内循环。它把线上问题从一次性工单变成可回归资产。
质量Agent不是新的真理机器
Google-AQuA旁路架构
把一支Agent放在另一支旁边，很容易形成“AI互相监督”的想象。但两者可能共享同一盲区：相似模型、相似提示词、同一日志缺口、同一业务定义。如果生产Agent把“已受理”理解成“已完成”，质量Agent也可能觉得措辞合理。
因此，外循环至少要防四类同源共错。
共错来源
表面现象
独立证据
相似模型偏差
两个Agent都认可同一错误解释
业务契约、人工金标
日志缺失
质检只能看到最终文本
工具Trace、权限审计
指标代理失真
低满意度被直接等同质量差
任务完成状态、用户后续行为
源码锚定错误
找到相关提交但不是根因
可复现实验、版本回放
测试团队不能把“质量Agent判断失败”直接写成缺陷，也不能把“没有发现聚类”当成没有风险。它更像一个高吞吐调查员，负责缩小范围；最终判定仍需独立规则、业务证据和可复现步骤。
AQuA测试责任闭环
测试岗位会从执行者变成证据架构师
第一项新工作是设计观察面。过去写用例关注输入与输出，未来还要决定哪些工具参数、状态变化、版本、用户后续行为值得留存。没有这些字段，质量Agent再聪明也只能对文本猜测。
第二项是校准异常。生产中“用户追问”可能意味着回答不清，也可能是用户改变需求；“转人工”可能是失败，也可能是正确的安全策略。测试工程师要为不同业务建立有条件的标签，而不是追求一套通用好坏分。
第三项是维护证据链。一条失败要能连接会话、工具调用、模型与提示词版本、部署源码、复现用例和修复提交。外循环自动化的价值，不是生成更多报告，而是缩短这条链从发现到验证的距离。
第四项是定义升级规则。涉及资金、权限、隐私和不可逆副作用的异常，不能等聚类规模变大才处理；低风险表达退化可以积累样本再排期。严重度必须来自业务影响，而不是出现次数。
怎样验证“检查AI的AI”
可以建立三套互相独立的测试。
第一套是植入已知故障。向脱敏流量副本加入十类已标注问题，包括答非所问、工具事实冲突、循环、越权尝试、遗漏确认和高成本路径。验证质量Agent的召回、误报和原因解释，但不把单一准确率作为全部结论。
第二套是盲审对照。让两名审阅者在不知道Agent判断的情况下标注同一批样本，计算一致性，分析争议类。若人之间都无法达成规则，就不应要求模型给出稳定答案；先修订Rubric。
第三套是根因回放。质量Agent提出某次部署导致异常后，在对应源码快照与前一版本上重放样本。如果问题无法随版本变化复现，诊断只能标成线索，不能写成确定根因。
这三套检查分别验证发现、判断和归因。只测其中一项，会让系统看起来聪明，却无法支持工程决策。
小团队如何采用，而不被平台工程拖住
不必先常驻一支复杂Agent。第一阶段每天对生产对话做脱敏抽样，用简单规则筛出高重试、高时延、用户否定和转人工会话；人工聚类并维护失败词典。第二阶段才让模型给候选标签和摘要，但所有新类别必须人工确认。
第三阶段把稳定类别变成离线回归。每条样本保留来源日期、脱敏方式、风险、适用版本和退出条件。第四阶段再连接源码与部署信息，缩短根因定位。如果团队连版本、Trace和业务结果都没打通，直接上“自治质量Agent”只会自动化猜测。
外循环还需要隐私边界。会话可能包含身份、地址和支付信息；聚类前应脱敏，访问要最小化，样本进入评测集要有保留周期。质量目的不能成为无限复制用户数据的理由。
流行叙事夸大了什么
第一种夸大是“线上质量可以全自动”。异常发现可以自动，规则仍由组织选择；资金损失与体验摩擦也不能由同一个分数换算。第二种夸大是“测试会被质量Agent替代”。重复抽样和初步分类会减少，但定义证据、处理争议、设计红线和承担签字责任反而更重要。
第三种夸大是“看到生产数据就能持续变好”。错误样本如果未经核验直接回流，可能把偶发噪声、攻击输入或错误业务反馈固化进评测集。飞轮不只需要流动，还需要阀门。
本文基于公开架构作出的判断是：未来6到18个月，Agent质量平台的差异不会只在评测器数量，而在能否连接真实业务结果、部署版本与可复现证据。值得观察的信号包括：是否公开错误聚类的校准方法，是否支持独立人工复核，是否能把根因定位回放出来，以及样本治理能否满足隐私要求。
测试工程师的位置不会因为多了一支AI团队而消失。它会从“执行已知检查”向“设计谁可以相信什么证据”迁移。工具可以发现异常、写诊断、提修复；但哪些失败必须阻断、哪些权衡可以接受、谁为边界负责，仍然需要独立的人类判断。
一场具体的外循环演练
可以用“航班改签助手”做一次桌面演练。先准备一百条脱敏会话，其中混入四类已知失败：没有确认费用就改签、使用过期航班信息、工具成功后仍说失败、用户拒绝后继续执行。再加入大量正常但表达不同的会话，避免质量Agent只凭关键词识别。
第一轮只看发现：它能否把相似问题聚在一起，是否把正常的人工转接误判为失败。第二轮看验证：它能否引用工具Trace、费用确认与真实订单状态，而不是复述用户情绪。第三轮看归因：把同一会话分别绑定正确版本和错误版本，观察它能否指出不同源码快照。第四轮看回流：未经人工确认的聚类不得直接进入发布门禁。
演练报告不追求一个漂亮总分，而是列出漏报、误报、证据不足和无法复现四类结果。漏掉资金与权限风险的严重度高于漏掉表达瑕疵；证据不足的诊断必须降级为线索。这样，团队才能知道质量Agent适合做什么、不适合做什么。
组织边界也要被设计
如果开发Agent、生产Agent和质量Agent都由同一团队配置，同源偏差会变成组织问题。更稳妥的做法是：业务负责人维护不可交换的结果定义，测试团队维护风险样本与独立门禁，平台团队维护运行与数据链路，安全团队管理权限与数据使用。各方可以共享工具，却不共享所有判断前提。
质量Agent提出修复时尤其要谨慎。它可以生成候选补丁和回归用例，但不能因为自己诊断、自己修改、自己评测就自动上线。至少保留一条与修复生成过程独立的验证路径；高风险变化还应保留人工签字。自动化越强，职责分离越不能只停留在流程文档里。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
