Google AQuA：把悄悄发生的 AI 失败变成产品修复队列

10 月 8 日，Google 发布了 AQuA，也就是 Ambient Quality Agent 的参考实现，用来从生产环境的 agent 会话中发现反复出现的问题。它针对的是一种常见的产品失败：服务正常响应，客户的事情却没有办对。Google 官方介绍说明，这个诊断助手运行在应用旁边，不会自行修改 agent，也不会替团队批准发布。

如果你正在上线 AI 客服、预约产品或内部工作流应用，眼前的问题很具体：自动审查又列出一批问题后，哪一个值得团队花掉下一个下午？一项发现可能听起来合理、出现频繁，却仍然指向错误的修复方案。

本文提出一套围绕用户任务、证据强度和未解决后果组织的修复队列。你可以带走一张可直接复用的问题工作表、一套小团队审查会议的做法，以及判断修复何时可以扩大上线范围的方法。这些是产品建议，不是 YBuild 实验结论。本文没有测量客户效果、模型对比或生产成本节省。

1. 看清新变化，再判断自动质量承诺

值得关注的变化，是现在有了一套公开的诊断流程，可以把生产会话和产生这些会话的应用版本联系起来。AQuA 文档中的流程包括抽样、审阅、归类、核验候选问题组，以及跟踪保留下来的问题；进一步调查时，还可以查看部署时保存的源码快照。它的自动“已解决”状态表示问题十四天没有再次出现，不等于证明某次修复造成了改善。

公开参考实现有明确的接入前提，不能理解成任何无代码应用都能直接安装的质量保证。创始人在购买实施服务之前，应该先让开发者确认：必要的会话轨迹和部署记录是否已经存在？能下载的仓库，也不同于附带支持承诺的正式服务。

先解释三个术语，采购和沟通就容易得多。轨迹（trajectory）是一次任务中的消息和工具事件序列。问题发现（finding）是对某个具体行为偏离预期的判断。修复队列则是团队对这些判断作出的行动安排：调查、临时限制、修改、验收、延期或驳回。这里的修复队列是本文建议的工作方法，不是 AQuA 的官方功能名称。

即使你最终不安装 AQuA，这个变化也值得用来重新询问现有供应商。让分析工具供应商展示一个“基础设施正常、用户任务失败”的案例，再问产品负责人凭什么区分错误推荐、信息缺失、工具故障和有意拒绝。如果对方只能给出分数和一段模型生成的解释，那么在把诊断变成开发指令之前，仍有工作要做。

2. 先写清对用户的承诺，再配置审查者

只有先明确产品欠用户什么，AI 审查者才有可能判断行为对不对。“准确、有帮助”不能回答这些具体问题：预约助手可不可以替客户预订另一个时间？退款助手可不可以承诺款项已经退回？起草工具在什么情况下应该追问？

先用一句话描述可以观察的产品承诺。例如：“客户更换服务地点后，助手必须先查询新地点的可用时段，才能把某个预约说成有空位。”再补上满足承诺需要什么证据：所选地点和时间的最新查询结果，以及向客户显示的准确状态。

Google 的 ADK 评估指南把最终答复和产生答复的步骤分开，也要求先定义目标再选择指标。对产品负责人来说，这一区分很实用。语气友好的回答可能漏掉必要核查；措辞不够顺畅的回答，也可能对应正确的预约。先确定任务的关键要求，再给语气打分。

把例外写在承诺旁边。用户可能只是浏览选项，随后离开；客户也可能主动选择等待人工处理。这些不一定是失败。另一方面，拒绝一个无法确认的预约虽然保护了用户，也要让客户明白发生了什么，以及接下来怎样继续。

第一轮范围可以收窄为“变更预约”，不要让每次互动同时接受所有可能的质量标准审查。请产品负责人和处理客户升级投诉的人一起看例子。如果他们意见不同，这往往意味着产品规则尚未定下来。先解决规则，再让自动化审查按规模执行，否则队列只会不断制造团队尚无答案的争论。

3. 把服务健康、审查覆盖和用户成功分开报告

接口健康、审查流程在运行、用户任务成功，是三件不同的事。Google 的 agent 监控文档列出了请求量和延迟等运行指标。这些信号帮助运维人员判断服务是否在工作，却不能告诉创始人：所选预约是否真的有空位，客户修改后的要求是否得到执行。

产品报告至少分开列出三行。第一行是服务健康：请求是否完成，工具是否可用？第二行是审查覆盖：哪些符合条件的任务留下了可用证据，哪些实际接受了审查？第三行才是任务结果：在已审查的任务里，证据能够确认什么？

分母必须写清楚。假设一个应用在某个窗口有 200 次更换地点的任务，80 次有可用轨迹，40 次接受了审查。针对这 40 次得出的结论，只描述这 40 次。没有合理的抽样和估计方法，就不能把它当作全部 200 次任务的失败率。这些数字仅用于说明报告方法，不是真实流量或实验结果。

还要区分完整轨迹和只有最终答复的记录。后一种记录或许能确认助手对客户说了什么，却未必能证明没有出现可用时段事件，就意味着根本没做核查。没有记录和没有行为，表面上可能一样。把证据缺口放进队列，不要让模型替团队默认选择一种解释。

在线监测文档提供抽样比例和数量上限设置，也提醒我们：经过审查的流量是经过选择的流量。第一次接入时，应要求运行报告列出未覆盖工作流、不完整轨迹、评估错误，以及没有可用数据的时间段。空白图表应该意味着“目前不知道”，不能解读为“一切正常”。抽样策略变更也要记录，因为更换筛选条件就可能改变分数，即使产品本身毫无变化。

4. 用一个虚构案例走完从投诉到决策的过程

设想 SlotDesk 是一家小型服务商使用的预约助手。这个产品是虚构的。客户先要求周四到中心门店，后来改成北区门店。助手仍沿用原门店的可用时段结果，却把北区的预约描述成有空位。对话很流畅，请求正常返回，也没有工具报错。

队列中的问题应写得具体：“客户更换门店后，助手可能用旧门店的查询结果描述新门店的可用时段。”不要只写“agent 出现幻觉”，否则开发者不知道从哪里查起。附上用户更换地点的消息、旧查询结果对应的门店、界面显示的承诺，以及应用版本。规划案例必须标明虚构；真正实施时，应提供自己产品的记录。

接着检查其他解释。可能已经查询过北区门店，只是没有记录；可能展示的是明确标为未确认的草案；也可能商家允许门店互换，问题仅在表达不清。给模型或提示词定责之前，审查者要先核实产品规则和实际证据。

如果确实违反承诺，可以先临时限制功能，再处理深层原因。例如，SlotDesk 可把更换地点后的选项显示为“待确认”，并交由工作人员核查。这会牺牲便利性，也增加人工负担，但能在调查期间避免没有依据的承诺。这项取舍由创始人决定，诊断分数无法代劳。

最终修改可能涉及状态保存、工具路由、指令或界面。无论改哪里，验收目标应保持一致：地点变化后，产品要么取得适当的最新证据，要么解释确认仍在等待。开发者应演示这一行为，并展示一个相邻正常场景仍然可用，而不是只提交改动说明。本例用于规划，不是对 AQuA 的测试，也不代表任何真实预约产品存在这一缺陷。

5. 先看后果和证据，再考虑频率

常见的小烦恼，不应该自动排在罕见但没有依据的承诺之前。先问：问题不解决，会给谁造成什么后果？再问：附件里的证据是否真的支持这一判断？回答这两个问题后，出现频率和修复成本才适合参与排序。

NIST AI 风险管理框架核心内容建议结合影响、可能性和可用资源，对已记录风险确定优先级。下面把这一原则改写成适合小团队使用的产品队列。分类是本文提出的工作安排，不是法规风险分级，也不是厂商评分体系。

频率也要谨慎计算。统计不同的符合条件任务，不要把重复 span、重试或同一会话中的多项发现当成多个独立用户任务。一个大问题组里可能包含几个机制，需要不同负责人；如果预期结果或修改方式不同，就应拆开。

不要把随意设定的严重度、置信度和频率数字相乘，制造一个看起来精确的分数。如果团队解释不了为何某项问题排在另一项前面，公式没有解决决策。简短理由往往更有用：“先限制更换地点后的确认功能，因为不可靠时段会形成对外承诺；问候语重复稍后处理，因为用户仍能完成任务。”

6. 用一张交给开发者后仍然有用的工作表

下面是一份可复用的问题记录。可以复制到任务管理工具或表格里，每种失败机制维护一份。使用受限证据链接，不要把整段客户会话粘贴到所有人都能访问的工单。SlotDesk 的记录应明确范围是“更换门店后的可用时段”，预期结果是“对所选门店进行确认”。

这张表刻意把诊断和验收分开。发现足以启动调查时，原因仍可能不确定；修改完成后可以进入测试，产品却未必适合全面上线。用团队容易理解的状态：调查中、已临时限制、待测试、有限上线、在声明范围内验收通过、已延期。

要求开发者把交付证据放回同一份记录。“修改了提示词”描述实施过程；“北区门店请求现在获得北区查询结果，无空位时会显示待确认”描述可以审查的行为。两者都有价值，但后者才直接回应产品承诺。

验收后，仍然保留没有解决的观察。如果某个变体仍失败，就记录排除范围和继续执行的限制。关闭一个范围明确的修复项，不应该抹掉相邻风险，也不应该悄悄把风险改名为成功。下个月另一位同事查看这张表，应能理解当时的决策，而不用让原作者从聊天记录里重建来龙去脉。

7. 在与结论相匹配的环境中验证修复

先安全地重现相关偏离，再比较修改前后的行为。查看结果之前，就固定产品规则、条件和预期输出。保留原始案例作为回归场景，同时加入变化，避免一个很窄的补丁只是识别了原来的措辞。

对 SlotDesk，可以考虑连续更换两次门店、更换门店后再改日期、所选时段无空位，以及工具无法返回结果。再加一个地点从未变化的相邻场景。这些只是建议案例，不是经过验证的最低数量，也不是统计保证。

重放会话文字，不等于重建当时的世界。库存会变，客户记录会改，工具可能给出不同答案。第一轮比较可以使用可丢弃测试数据或受控工具响应，并要求开发者说明：哪些条件已重建，哪些作了简化。不要为了获取一张截图，把真实预约或付款重新执行到生产系统。

检查有意义的结果，不要求所有内部步骤都完全相同。助手正确地追问缺失信息，可能是直接回答之外的合格方案。提前约定这些替代路径。如果用户体验有多个合理形式，人工审查尤其有帮助。

扩大生产范围时，应把修改版与适当的对照比较，单独观察受影响工作流。Google 的 灰度发布指南解释了整体指标为什么可能掩盖小范围新版的问题，也指出了有状态测试需要注意的事项。产品可以把“观察到任何没有依据的确认”设为停止条件，但仍需按约定核实证据。在有界试点里没有出现这种案例，只能说明该试点的结果，不能证明所有场景下的发生概率都是零。

8. 保护证据，同时保留调查价值

生产会话审查增加了一个能读取客户对话的地方。启用之前，先明确审查者需要什么数据、哪些人能访问、数据会进入哪些系统。工具在自己的云项目里运行，也仍然需要适当的采集目的、权限、保留规则和运营负责人。

OpenTelemetry 的敏感数据指南建议尽量减少采集，并介绍删除和脱敏办法，也提醒哈希处理的局限。把姓名替换成固定哈希值，并不自动让包含大量细节的对话成为匿名数据。

一般规划使用虚构的 SlotDesk 案例。真正的客户记录只让调查该问题所需人员访问。开发者通常可以拿到包含门店标识和预期结果的合成复现，而由指定审查者保留原始证据访问权。如果脱敏移除了诊断所需事实，就要明确说明。脱敏记录未必是完整记录。

轨迹存储、导出的问题详情、截图和测试数据，可能各有不同的保留路径。列一个简短副本清单，为每种副本指定责任人。除非实际数据流支持，不要承诺删除客服工单就会同时删除所有诊断副本。

还要把客户沟通与内部推测分开。“我们正在核查预约确认问题，会由工作人员确认您的时段”是可执行的运营信息。把模型生成的根因猜测当成既定事实发给客户，只会增加混乱。说明当前状态、安全的下一步，以及客户应依赖什么。隐私审查的目标是减少不必要暴露，同时保留足以支撑和审计修复决策的证据。

9. 让短会以决策结束

小团队不必每天围绕每一条生成式洞察开会。按任务量和潜在后果安排审查频率，同时为严重事件保留立即处理通道。定期会议应包括产品负责人、负责修改的开发者，以及熟悉客户实际结果的人。

带一份简短队列，提前准备好可以打开的证据。每项回答四个问题：违反了什么承诺？什么证据支持判断？现在该做什么？获得什么信息会让我们改变决策？如果证据不可访问，就分配获取证据的任务，不要争论模型摘要。如果规则有分歧，就分配产品决策，不要假装它纯属技术问题。

Google 的 SRE 监控章节强调可行动的信号，并提醒告警噪声的代价。会议也可以遵循这一原则：新问题组不自动值得发紧急告警。紧急客户损害进入事件处理；反复出现、影响较低的摩擦进入计划队列。

除了确认的缺陷，也记录调查最终被驳回的判断花了多少时间。这样审查噪声就会变得可见。同时关注无人负责的问题和反复延期。更多诊断输出只有在改善决策、又没有耗尽团队修复能力时，才真正有用。

每项结束时都要明确负责人、动作和下次检查条件。同一问题回来，用新证据重启原记录，不要新建毫不关联的工单。如果修改了审查规则，就在趋势中标记，避免把问题数量下降误读成产品改善。看板变安静，可能因为行为变好、审查变窄，或采集流程坏了。会议要判断证据支持哪种解释。

10. 判断现在是否值得加入这套质量外环

当你已有上线 agent、可访问轨迹、可识别应用版本、反复发生的工作流问题，以及能处理发现的人，AQuA 才最有相关性。基于 ADK 的团队可能把参考实现作为起点。其他技术栈也能借用这套运营方法，同时选择不同的采集和审查工具。

如果只有少量试用对话，对照清楚的任务承诺进行人工审阅可能已经足够。如果无法识别部署版本，先补好版本记录。如果没人负责客户升级问题，先指定负责人，再扩大诊断输出。如果关键动作需要实时授权，必须把控制放在动作执行路径；事后审查无法阻止已经作出的承诺。

从一个工作流和有界试点开始，成功条件应是实际运营能力：团队能否区分有证据支持的缺陷和证据缺口，安排合理动作，再审查修改是否改善了目标任务？记录软件费用、审查投入、修复投入，以及剩余不确定性。用同一套产品规则，把这些负担与人工流程比较。安装诊断 agent，并不自然带来普遍的节省。

能长期留下的交付物，是填完整的问题记录，而不是看板上的洞察数量。对 SlotDesk，创始人应该能说明改了什么、检查了哪些案例、哪些范围仍未覆盖，以及没有依据的确认再次出现时由谁处理。这足以支持今天的有限决策，也让下一次决策继续接受证据修正。

参考资料

1. Google Developers Blog：AQuA 官方介绍，2026 年 10 月 8 日。原始产品介绍；其中的演示不是 YBuild 测试。
2. Google ADK recipes：Ambient Quality Agent。实现与接入前提；与官方介绍属于相关材料，不是独立验证。
3. ADK：为什么评估 agent。目标、轨迹和最终答复评估。
4. Google Cloud：监控 agent。运行监控信号。
5. Google Cloud：使用在线监测进行持续评估。抽样与评估监控。
6. NIST：AI 风险管理框架核心内容。风险优先级、测量和部署后管理。
7. Google SRE Workbook：灰度发布。版本比较与有状态测试的限制。
8. OpenTelemetry：敏感数据处理。数据最小化与脱敏局限。
9. Google SRE Book：分布式系统监控。可行动监控与告警噪声。