10 月 8 日，Google 在开发者博客开源了 AQuA（Ambient Quality Agent）参考实现。它的定位一句话说清：一个跑在你生产环境智能体旁边的质量智能体，在你合上笔记本之后继续值班，把上线后的生产失败做聚类、核验，并给出锚定到具体源码行的根因。
它盯的不是崩溃和超时这类吵闹的故障。官方举的例子是：智能体答得自信，步骤读起来也顺，却悄悄把用户真正想要的事做偏了——把 3A 座确认成已选，却从没问过选座子智能体 3A 是否空闲；给一个档案写着纯素食的旅客推荐佛罗伦萨牛排馆。没有告警，没有工单，指标曲线还很好看。这种故障通常靠用户投诉才浮出来，而大多数用户嫌麻烦，直接走了。
为什么上线后的 20% 比前 80% 难
Google 把智能体质量工程切成两个环。上线前的内循环——离线评测集、编码智能体、跑评改比的紧循环——今天要走到已知场景的任务成功率并不难，通常几天就能做到。难的是上线之后：地面在移动。用户摸清能力边界后用法变了，真实流量不再像初始评测集；同时底下的东西也在变，升级模型、换 harness、改工具或技能之后，一切照常运行，健康检查照旧全绿，但对话质量与任务成功率可能已经变了，而标准部署流水线不会为这件事报警。
更麻烦的是定位。一次失败的会话，往往需要把几层外观几乎相同的东西分开：模型可能编了一个说法，或丢掉了三轮之前的某个约束；编排层可能路由到了错误的子智能体，或在轮次之间丢了状态；工具契约可能因为取值范围从没写进 schema 而拒绝了一个合法输入；也可能只是指令或技能里缺一条谁都没想到要写的规则。这几层的责任人和修法完全不同。
而原始轨迹记录的是「接下来发生了什么」，不是「是什么导致了什么」。要分清这几层，得把失败轨迹和产生它的那一版代码放在一起读。线上评测看板能告诉你分数动了，编码智能体在知道要看哪里的前提下能查一条 trace——但生产量级下，没人能手工读完每一段对话。
五道工序，以及刻意设置的各个上限
AQuA 的每一轮排查走五步，每一步都设了上限，好让单轮成本可预期。
抽样：从 Cloud Trace、Cloud Logging 或 BigQuery 里随机取最多 1000 条近期会话。评审：对着九项常见故障清单逐条打分，覆盖流程走偏、工具选择与参数出错、grounding 不足、任务未完成等类别，判断时能看到智能体的指令、工具清单以及可选的 goal.md；不通过就写下一条结构化的 actual / expected 记录。聚类：把失败机制相同的记录归成候选问题簇。核验：换另一个模型拿最多三条完整 transcript 顶一遍，证据撑不住的簇直接丢弃，单轮最多核验 50 个簇。跟踪：把活下来的簇与 BigQuery 里未关闭的 insight 对上，标成 NEW、RECURRING，14 天没再出现就自动标成 RESOLVED。
想把这些工序带到自己领域，可以写一份纯英文的 goal.md，它会附加到每次评审的提示词后面；也可以在 eval_config.yaml 里放几个确定性的 Python 指标跟着跑，用来看通过率趋势。官方给的示例里，goal.md 明确要求关注「会话中途变更」与「跨子智能体交接时的上下文丢失」，并明确要求忽略语气、问好这类风格噪声。
根因分析：锚到部署那一刻的快照
当一个 insight 值得深挖时，可以从面板的 Chat 或 agents-cli aqua run 触发根因分析。AQuA 会把失败轨迹和部署时刻抓下来的不可变源码快照放在一起读：缺陷在仓库里，就引用成 路径:起始行-结束行，并给一段锚在快照行上的编辑建议；问题在代码之外（上游依赖、交接、检索到的内容），就把失败归因到轨迹里的那一步，不提代码改动。它自己从不改代码，也不自动开 PR。
可信度是怎么设计的：三处很克制的取舍
一个会诊断别人的智能体，本身也会出错。官方对这点不回避，处理方式是把「未验证的假设」和「已验证的发现」在数据结构上彻底隔开。
其一，问题簇在被完整 transcript 验证之前只是主张。官方在 87 条 trace 的内部基准上，核验环节从 24 个候选簇里拒掉了 4 个；而簇的 trace 数量只用来给出粗略的优先级排序，不代表每个成员会话都被逐条验证。其二，insight 的可信度来自它的引用，而不是一个自报的分值——数据结构里压根没有 confidence 字段，每一次出现都链到 Cloud Trace 的会话 ID，每一个根因都引用 路径:行区间，服务端会拿这一版快照去校验，指到不存在的文件或行会被直接拒掉。其三，跳过与失败的工作会显式记在运行记录上：被拒的簇、超过 50 簇上限没核的、rubric 报错的、遥测窗口空或没采到的，都记为「未完成」而不是「干净」。
另外，被人工 Dismiss 过的发现，之后的排查不会当 NEW 重新打开。
把成本摊开算
官方给了两组真实开销数字，可以直接换算到自己的会话量级。
案例一是 96 条会话的单智能体排查，每条约 5 到 6 个 span，评审加聚类加核验合计花费 0.70 美元，约合每条会话 0.007 美元；输入 220,841 token、输出 48,736 token，由两款不同模型分担。案例二是 32 条会话的多智能体排查，牵涉主智能体与各子智能体共 1,583 个 span，约合每条会话 50 个 span，评审与聚类合计 3.76 美元，约合每条会话 0.12 美元，另有 9 次问题簇核验。按需触发的根因分析是整条链路里最贵的一步，每个待查 insight 0.33 到 2.47 美元，取决于它需要拉进多少条完整轨迹。
官方自陈的三道难题，比产品介绍更值得读
其一，规模上该读哪些会话。深度评估一条多轮轨迹的成本远高于查一个 HTTP 状态码，所以这个参考实现每轮随机抽样最多 1000 条。加一层便宜的结构性预筛选（重试、延迟尖刺、轮次异常、用户点踩）是很自然的下一步，但官方自己指出，只按异常过滤往往只会捞出一百份同一个超时——真正难的是那种关键流程里悄悄坏了 1% 的回归，所有结构信号看上去都正常，却不能对每天 5 万条会话全跑一遍深度裁判。
其二，通用清单与领域目标之间的校准。goal.md 和自定义指标能把评审往领域规则上带，但让模型裁判与领域专家达成一致，仍是实打实的工程活。
其三，有界核验与可预期的运行成本。每轮最多 50 个簇、每簇最多 3 条 transcript，随着轨迹深度增长才能保住成本可预期。
还有一层观察比列出的难题更根本：Google 自家智能体上的实操经验显示，低层原语（轨迹与反馈接入、核心评测器、数据集管理）复用得很干净，而外循环工作流往往是每个产品特有的——它取决于这个产品的工具、领域不变量、数据管道和编排方式。作为底层模型与智能体读轨迹、读代码能力不断变强的那部分，单次评分与根因推理会自动跟着变强；周边平台不会自己长出来。
怎么试，以及它适合谁
想在本地看看面板，不需要云项目、不需要凭据、也不产生模型调用，官方给的是一条 make demo 命令，在合成数据上把整套面板跑起来。要接到自己 Google Cloud 项目里的智能体上，则要用 agents-cli 做基础设施配置与部署，遥测、源码快照与 BigQuery 表都留在你自己的项目边界内、你的服务账号后面、由 IAP 保护。部署时会按 revision 写一份不可变源码快照到 Cloud Storage——这正是后面根因分析能锚定行号的前提。想让编码智能体直接驱动两个环，还可以装 agents-cli-aqua 这个 skill。
官方在文末列了三个想问社区的问题，其中两个特别实在：并排跑一个质量智能体是否契合你的架构、哪部分要留在自己仓库里；以及由谁来分诊头一条 insight、在哪个界面做。这两个问题的答案基本决定了 AQuA 这类工具在你团队里能不能真正长起来——因为它产出的不是仪表盘，而是一堆需要有人认领的线索。