Evaluating AI agents: moving past the vibe check

Google Developers Blog

Google Developers Blog2026年10月15日

Evaluating AI agents: moving past the vibe check

8.5内容质量

TL;DR · AI 摘要

传统AI代理测试方法存在致命缺陷，Google提出结合人工审核与自动化工具的评估框架，可检测隐藏故障并提升可靠性。

核心要点

传统3-4个提示测试无法发现循环、幻觉等隐藏故障，导致云成本激增300%。
agent-eval工具包通过人工审核+自动化验证，可提前60%发现回归问题。
评估框架需从简单可重复检查起步，逐步演进至自动化体系。

结构提纲

按章节快速跳转。

§引言
传统AI代理测试方法存在致命缺陷，导致生产环境隐藏故障频发。
·隐藏故障影响
循环、幻觉等故障会引发云成本激增、API配额耗尽和用户信任崩塌。
›评估框架核心
人工监督与自动化工具结合是评估体系的两大支柱。
·实施路径
从定义关键用户旅程到部署agent-eval工具包的60分钟实践指南。
›工具链详解
开源agent-eval工具包支持手动审核与自动化验证的无缝集成。

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）

AI代理评估方法
- 传统测试缺陷
  - 表面正常但隐藏故障
- 评估框架
  - 人工监督
  - 自动化工具(agent-eval)
- 实施步骤
  - 定义CUJs
  - 部署工具包

金句 / Highlights

值得收藏与分享的关键句。

Your agent can loop, burn tokens, or give a completely hallucinated answer and still look fine. A vibe check won't catch that.
— 第2段
⬇︎ 下载 PNG 𝕏 分享到 X
It quietly spikes your cloud bill and token usage by up to 300% in production.
— 第3段
⬇︎ 下载 PNG 𝕏 分享到 X
The key is recognizing that evaluation is a progressive journey: any repeatable system is better than ad-hoc checks.
— 第4段
⬇︎ 下载 PNG 𝕏 分享到 X

#AI代理评估#自动化测试#Google#agent-eval

打开原文

评估 AI 代理：超越直觉检查 - Google 开发者博客

Google Tag Manager (noscript)

结束 Google Tag Manager (noscript)

HTML

评估 AI 代理：超越直觉检查

2026年10月15日

Hugo Selbie

客户与合作伙伴解决方案工程师

Dani Zamora

解决方案工程师

Jesse Carah

孵化负责人

Facebook

Twitter

LinkedIn

邮件

TL;DR

你的代理可能会陷入循环、消耗令牌或给出完全的幻觉回答，但仍可能看起来正常。直觉检查无法发现这些问题。本文是我们的 AI 代理诊所剧集《如何实际评估（任何）AI 代理：超越直觉检查》的幕后指南，其中我们展示了如何在 60 分钟内为 LangGraph 代理构建评估流水线。以下是内容概览：

评估 AI 代理：超越直觉检查

当团队开始构建 AI 代理时，测试通常看起来都差不多。你连接一个模型，给它几个工具，运行三四个终端提示，然后盯着输出结果。如果答案看起来合理，你就会部署它。

实际上，这种方法很快就会失效。你调整系统提示以修复某个工作流程中的边缘情况，突然间代理在另一个工作流程中停止调用必要的工具。

更糟糕的是，代理的失败方式与标准软件不同。一个代理可能会陷入重试循环，发出多个工具调用，但仍返回一个礼貌且看似合理的最终答案。

在生产环境中，这种隐藏的失败成本高昂：

它悄无声息地增加你的云账单和令牌使用量。
它耗尽下游 API 的速率限制和配额。
它让用户盯着加载指示器发呆。
它可能在外部系统中触发重复的副作用，同时在表面上看起来“正常”。
它会侵蚀用户信任，而第一印象很难重新赢得。

在初始原型设计阶段，将可靠的评估套件集成到开发生命周期中似乎像是额外的负担，直到修改系统提示导致意外的破坏性变更。关键在于认识到评估是一个渐进的过程：任何可重复的评估系统（无论多简单）都比依赖临时抽查或完全没有系统要好。你不需要在第 0 天就建立一个复杂的自动化评分架构。相反，从简单的、可重复的检查开始，随着代理能力的提升和生产需求的增长，逐步将评估演进为更复杂、自动化的框架。

通过将这些决策整合到评估框架中，建立可重复的评估系统会变得容易得多。超越简单的主观检查依赖于两个核心支柱：人工监督和针对性工具。在本文中，我们将探讨如何使用开源的 agent-eval 工具包设置评估框架。我们将演示如何通过将人工审核的追踪与自动化验证相结合，帮助在开发早期阶段检测到隐蔽的回归，并在代理过渡到生产时无缝扩展。

“作为一名运营分析师，我期望代理能够摄入一封关于交易对手交易差异的电子邮件，识别出存在争议的交易，30秒内验证交易经济数据是否与我们内部账本一致，并在无需人工干预的情况下，将内部交易ID反向转换为经纪人的术语，起草回复。”

该陈述中的每个条款都将成为评估点：代理是否解决了正确的交易ID？它在起草回复前是否检查了账本？它是否将内部ID映射回外部术语？

每个CUJ条款都会成为评估点。

提前定义这些期望，迫使产品负责人、下游用户和工程师达成一致，明确如何衡量“成功”。

2. 从模拟用户开始，逐步过渡到真实流量

你不需要六个月的生产日志来构建初始黄金数据集。相反，将每个CUJ分解为具体场景（包括正常流程和边界情况），并将其输入用户模拟LLM（我们推荐ADK用户模拟）。通过设定角色和行为约束（例如，一个不耐烦的分析师提供不完整的工单号，或一个开发者提出多步骤的调试问题），模拟器能够复现真实用户混乱的表述、拼写错误和多轮对话的复杂性。

ADK用户模拟的示例场景。

通过让代理针对合成用户和真实场景进行测试，你可以在用户交互前记录完整的执行轨迹（包括工具日志）。这使你能够精准定位并解决任何与发布标准的性能差距。随着真实流量开始涌入，你可以逐步用真实生产轨迹替换这些合成设置。

3. 全栈测量

单一的顶层评分永远无法告诉你代理为何失败。为了定位根本原因，需要分层四类检查：单元测试、确定性指标、LLM作为裁判的评分标准，以及集成测试。

从单元测试到集成测试的四层检查。

需要避免的四个常见陷阱

陷阱1：删除测试用例并破坏基准线

设置评估指标需要试错过程，删除嘈杂的测试用例或在不同运行之间替换样本查询的诱惑很大。但每次添加或删除测试用例时，你都会破坏基准线：你无法判断分数变化是由于代理性能提升，还是测试套件本身发生了变化。在调整功能时，保持黄金数据集冻结，每次只改变一个变量，只有在确定底层需求已改变时，才退役某个测试用例。

删除测试用例会移动基准线，而非代理本身。

陷阱2：依赖模糊的1-5分裁判评分，而非布尔检查

LLM在评估定性1-5分等级时 notoriously 不一致；“3”和“4”之间的界限模糊，且每次运行都可能变化。

尽可能将裁判评分标准转化为布尔（通过/失败）问题，而非开放式评分等级。不要问“这个回答从1到5的有用性如何？”，而应问“代理在调用退款工具前验证了账户ID吗？（是/否）”。（我们推荐Adaptive Rubrics）

陷阱3：评估文本内容时忽略运营成本

如果响应耗时40秒、进行了十二次冗余工具调用、每次查询成本60美分，即使通过所有质量检查，它仍然是生产环境中的失败案例。

始终评估整个系统，而不仅仅是最终文本。在评估答案质量的同时，要跟踪延迟、令牌消耗（提示、推理和完成令牌）、API 成本以及工具调用次数。

陷阱 4：为不同的智能体框架构建不同的评估流水线

切换编排框架通常会迫使团队重新编写整个测试套件。虽然大多数框架都会生成 OpenTelemetry 追踪记录，但它们在工具调用、步骤和令牌的语义约定上并不一致。通过围绕开放规范（如 OpenInference）标准化追踪记录，可以将评估与编排框架解耦，从而解决这一问题。像 agent-eval 工具包这样的工具原生支持这一点，只需极少的配置即可实现。

从 Day 0 到 Day 2 的实际部署流程

你无需从零开始构建一个可观测性平台。可以使用开源工具（如 agent-eval 工具包）在几小时内搭建评估流水线，该工具包将 OpenTelemetry 追踪捕获与 Gemini 平台（原 Vertex AI 评估）上的智能体评估服务相结合。但构建实际的评估策略需要更多思考。

Day 0：场景、模拟和“红笔”

从小处着手，贴近原始数据：

撰写涵盖主要 CUJs（关键用户场景）的场景，并通过智能体运行模拟。

忽略聚合分数，从上到下阅读实际执行追踪记录：提示、中间推理步骤、工具参数和最终输出。

用红笔对追踪记录进行评分，标记智能体犹豫、幻觉参数、选择错误工具或啰嗦的每一个位置。

一张用红笔评分的智能体追踪记录。

为什么红笔很重要：与自动生成图表相比，手动阅读二十条追踪记录似乎很慢，但它能节省数天的无效努力。与其猜测假设的失败模式并编写遗漏重点的通用评分标准，用一小时红笔评分能让你看到系统在现实中实际如何失效。将这些笔记汇总后，你会得到一份高信号的精确确定性断言和布尔判断检查列表，这些是下一步需要构建的内容。

Day 1：节奏、信号和测试框架

一旦你有了初始检查列表，agent-eval 工具包等工具将接管繁重工作并标准化执行。帮助你完成以下任务：

搭建和执行：搭建你的黄金数据集，并通过 HTTP（--base-url）或离线方式对智能体执行多轮场景。

与框架无关的追踪数据摄入：无论你使用 Google ADK、LangGraph 还是自定义运行时，都能获取结构化 OpenTelemetry 追踪记录，遵循 OpenInference 规范。

智能体评估集成：将这些追踪记录路由到 Gemini 平台的智能体评估服务，无需自定义 API 代码即可运行确定性检查和布尔判断评分标准。

为评估流水线建立定期执行节奏：

每次更改都运行：每当调整提示、更换模型或编辑工具文档字符串时，执行相同的测试套件并对比基线的差异。

agent-eval HTML 报告中随时间变化的指标。

用追踪记录验证评分标准：不要盲目信任新的 LLM 作为评分者的指标。将自动生成的评分与 Day 0 手动评分的追踪记录进行对比。如果评分者对你用红笔标记的追踪记录给出通过评分，需收紧评分提示，直到自动化信号与你的工程判断一致。

调优循环：50至60次旋钮调整，而非重写

一旦你的第1天框架投入运行，优化将变成一种有纪律的机械循环：

对示例代理进行一次调优循环。

在实际部署中，达到生产质量通常需要50到60次小幅迭代。你不是每天早上重写整个系统提示；而是逐步调整个别参数。一次调整澄清了工具参数描述。下一次添加了负向约束。再下一次调整了JSON输出模式。

例如，每次评估运行完成后，agent-eval框架会生成一个交互式的综合HTML报告。该报告将通过/失败布尔指标与关键运营指标（包括延迟、令牌使用量、API支出、缓存利用率和详细的工具调用执行路径）并列展示。此外，它还会整合Gemini自动根本原因分析，针对失败的对话轮次定位触发故障的具体提示指令或参数设置，以指导你的下一次调整。

这些数据取代了直觉。在手动抽查中，一个提示更改可能看起来非常聪明，但测试套件却可能显示延迟翻倍，工具调用幻觉增加了15%。

对构建代理的团队的启示：小而谨慎的更改永远胜过大规模重写。

第2天：合并门控与共享仪表盘

一旦你信任评估流水线输出的信号，将其转化为永久的回归安全网：

带无头CLI的CI/CD拉取请求门控：在构建流水线（如Cloud Build或GitHub Actions）中以无头模式运行agent-eval等工具。每次拉取请求时，它会运行你的黄金数据集并强制执行两个合并规则：

全局通过阈值：套件必须达到最低通过标准（例如95%布尔成功率）。

核心评估指标零回归：即使总体评分保持稳定，如果任何先前通过的指标出现退化，构建也会失败。这可防止开发人员无意中用一个次要的边缘情况改进换取关键能力的丧失。

共享仪表盘与集中式存储：配置评估流程将运行工件（包括原始追踪JSONL、提示哈希、模型版本、延迟分布和评分卡摘要）导出到BigQuery或Cloud Storage等中央数据仓库。将这些指标发布到共享团队仪表盘，使每个人都能跨版本查看准确性、延迟百分位数和令牌预算。

发布后，真实的生产追踪会流回黄金数据集。

实际操作演示

配套的AI代理诊所剧集。生产团队：在此嵌入YouTube播放器，并使用此卡片作为缩略图或备用图。

观看操作演示：查看我们的配套视频《如何实际评估（任何）AI代理：超越氛围检查》，我们在60分钟内实时演示如何在真实的LangGraph代理上构建整个流水线。

获取代码：在GitHub上克隆开源的agent-eval工具包，用于构建数据集、收集追踪并直接生成诊断HTML报告。

外层循环，优先洞察：一个可诊断生产代理的环境质量代理。

常见问题

手动“氛围检查”对AI代理有哪些问题？

在终端中运行三到四个提示信息只会显示最终的文本响应。一个代理可能会在重试时循环，编造工具参数，消耗令牌预算，或触发重复的副作用，同时仍然返回礼貌的回答。自动化跟踪评估会检查中间工具调用、状态转换、延迟百分位数和API成本，同时与回答质量一起评估，以防止静默回归被部署。

我如何从零开始评估一个AI代理？

将评估视为从第0天到第2天的渐进式部署，而不是一次性的全部实施。在第0天，将您的关键用户旅程（CUJs）分解为几个测试场景，并通过ADK用户模拟运行这些场景。用“红笔”阅读前5到20个执行跟踪，查看代理在哪些地方犹豫不决、选择了错误的工具或喋喋不休。

在第1天，将这些红笔注释转化为自动化检查，以便一次调整一个变量。一旦通过率稳定，将这些检查锁定为第2天CI/CD拉取请求的门禁。

为什么使用布尔（通过/失败）检查而不是1到5的评分量表来评估LLM作为裁判？

LLM裁判无法一致地对1到5的评分量表进行评分，因为“3”和“4”之间的界限会随着每次运行而变化。通过自适应评分标准，您可以将广泛的质量目标拆分为严格的“是/否”问题，例如“代理在退款前是否验证了账户ID？”将这些布尔评分标准与工具参数和参考检查的确定性计算指标结合使用，并辅以延迟和令牌预算的跟踪断言。

我能否在LangGraph、Google ADK和自定义代理框架之间使用相同的评估管道？

是的，如果您通过标准化OpenInference语义约定的OpenTelemetry跟踪，将评估管道与代理框架解耦。开源的agent-eval工具包会将这些跟踪直接路由到Gemini平台（原Vertex AI评估）上的Agent评估服务。在切换编排框架时，您无需重写评分代码。

我的代理部署到生产环境后会发生什么？

一旦第2天的管道将跟踪和评分卡导出到BigQuery或Cloud Storage，您就可以将实时流量与预生产基线进行比较。当用户遇到初始场景未覆盖的边缘情况时，像The Outer Loop这样的环境质量代理可以帮助您诊断这些失败的生产跟踪。然后，您可以将这些真实跟踪直接提升到第0天的黄金数据集中，使测试套件随着实时使用情况而演变。

posted in:

AI

Cloud

Best Practices

Industry Trends

Solutions

Learn

Solve