Google 官方博客：如何评测 AI 智能体，走出凭感觉检查

2026年10月15日

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

太长不看版

你的智能体可能会陷入循环、烧掉大量 token，或者给出一个完全凭空捏造的答案，但表面上看起来一切正常。凭感觉检查是发现不了这些问题的。本文是我们 AI Agent Clinic 节目 How to Actually Evaluate (Any) AI Agent: Beyond the Vibe Check 背后的实战手册，在节目中我们用 60 分钟为一个 LangGraph 智能体搭建了一套评估流水线。以下是内容概览：

评估 AI 智能体：告别凭感觉检查

当团队开始构建 AI 智能体时，测试方式通常都大同小异。你接上一个模型，给它几个工具，在终端里跑三四个提示词，然后凭肉眼看看输出。如果答案看起来还算合理，就直接上线了。

但在实践中，这种做法很快就会崩溃。你为了修复某个工作流中的一个边缘情况调整了系统提示词，结果智能体在另一个工作流中突然不再调用某个必需的工具了。

更糟的是，智能体的失败方式与标准软件不同。智能体可能卡在重试循环里，触发多次工具调用，却仍然返回一个礼貌、听起来很合理的最终答案。

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

• 它会悄悄推高你的云账单和 token 消耗。
• 它会耗尽下游 API 的速率限制和配额。
• 它会让用户盯着加载转圈干等。
• 它可能在外部系统中触发重复的副作用，而表面上一切看起来都“正常”。
• 它会侵蚀用户信任，而第一印象一旦失去就很难挽回。

在开发生命周期中集成一套可靠的评估套件，在最初原型阶段看起来像是额外的负担，直到你修改系统提示词引发了意料之外的破坏性变更，才会意识到它的价值。关键在于要认识到评估是一段渐进式的旅程：任何可重复的评估系统（无论多么简单）都比依赖临时的抽查或完全没有系统要好。你不需要在第 0 天就搭建一套精密的自动化评分架构。相反，从简单、可重复的检查开始，随着智能体能力和生产需求的增长，再将评估演进为更复杂、自动化的框架。

将这些决策集成到评估框架中，会大大简化建立可重复评估系统的过程。要超越简单的主观检查，需要依赖两大核心支柱：人工监督和针对性工具。在本文中，我们将探讨如何使用开源工具包 agent-eval 搭建评估框架。我们将演示如何将人工审查的追踪记录与自动化验证相结合，从而在开发早期发现那些悄无声息的回归问题，并随着智能体走向生产环境实现无缝扩展。

入门：高层构建模块

1. 用关键用户旅程定义成功

在编写测试代码之前，你需要对什么才算好的结果有一个共识。把你的测试锚定在关键用户旅程（CUJ）上，而不是抽象的基准测试。

CUJ 定义了用户期望系统达成的目标，围绕用户的角色、目标、约束条件和验证条件来构建：

^{“作为一名运营分析师，我希望智能体能够接收一封关于交易对手交易差异的邮件，识别出有争议的交易，在 30 秒内对照我们的内部账本核实交易经济条款，并在无需人工干预的情况下起草一封回复，将我们的内部交易 ID 反向翻译回经纪商的命名体系。”}

该陈述中的每一条款都成为一个评估点：智能体是否解析了正确的事务 ID？它在起草前是否检查了账本？它是否将内部 ID 映射回外部命名？

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

预先定义这些期望，迫使产品利益相关者、下游用户和工程师就如何衡量“成功”达成一致。

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

你不需要六个月的生成日志来构建初始黄金数据集。相反，将每个 CUJ 分解为具体的场景（包括正常路径和边缘情况），并将它们输入到用户模拟器 LLM中（我们喜欢 ADK 用户模拟）。在设定角色和行为约束（例如，一个不耐烦的分析师给出不完整的工单号，或一个开发者提出多部分调试问题）后，模拟器会模仿真实用户的杂乱措辞、拼写错误和多轮复杂性。

ADK 用户模拟的示例场景。

通过针对合成用户和现实场景测试你的智能体，你可以在用户交互之前记录全面的执行轨迹（包括工具日志）。这使你能够根据发布标准精确找出并解决任何性能差距。随着实时流量的开始，你可以逐步用真实的生产轨迹替换这些合成设置。

3. 在全栈范围内进行测量

单一的最高分永远无法告诉你智能体为什么失败。为了隔离根本原因，分层进行四种检查：单元测试、确定性指标、LLM 作为评判的评分标准以及集成测试。

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

四个常见陷阱要避免

陷阱 1：丢弃测试并破坏你的基线

设置评估指标涉及试错，很容易在运行之间删除一个嘈杂的测试或替换样本查询。然而，每次添加或删除测试时，你都会使基线失效：你无法判断分数变化是因为智能体变好了，还是因为测试套件变了。在调整功能时保持黄金数据集冻结，一次只改变一个变量，并且只有在确定底层需求已改变时才淘汰测试。

删除测试会移动基线，而不是智能体。

陷阱 2：依赖模糊的 1 到 5 评判分数，而不是布尔检查

LLM 在评定定性 1 到 5 分制时出了名的不一致；“3”和“4”之间的界限模糊，并且经常在运行之间发生变化。

尽可能将你的评判标准转化为布尔（通过/失败）问题，而不是开放式评分量表。与其问“这个答案从 1 到 5 有多有帮助？”，不如问“智能体在调用退款工具之前是否验证了账户 ID？（是/否）”。（我们喜欢 自适应评分标准）

陷阱 3：评估文本而忽略运营成本

一个通过所有质量检查的响应，如果耗时 40 秒、进行了十二次冗余工具调用，并且每次查询花费 60 美分，仍然是一个生产故障。

始终评估整个系统，而不仅仅是最终文本。在关注答案质量的同时，跟踪延迟、token 消耗（提示词、推理和补全 token）、API 成本和工具调用次数。

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

切换编排框架往往迫使团队废弃并重写整个测试套件。虽然大多数框架都会输出 OpenTelemetry 追踪，但它们在工具调用、步骤和 token 上并不使用相同的语义约定。围绕像 OpenInference 这样的开放规范来标准化你的追踪，就能通过将评估与编排框架解耦来解决这个问题。像 agent-eval toolkit 这样的工具原生支持这一点，且只需极少的配置。

从 Day 0 到 Day 2 的实用落地路线

你不需要从零开始构建一个可观测性平台。你可以使用像 agent-eval toolkit 这样的开源工具，在几个小时内搭建起评估流水线，它将 OpenTelemetry 追踪采集与 Gemini 平台上的 Agent Evaluation 服务（原 Vertex AI Evaluation）配对使用。但构建真正的评估策略需要更多的思考。

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

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

1. 起草覆盖你主要 CUJ 的场景，并通过你的智能体运行模拟。
2. 忽略聚合分数，从头到尾阅读实际的执行追踪：提示词、中间推理步骤、工具参数和最终输出。
3. 用红笔批改这些追踪，标记出智能体每一次犹豫、编造参数、选错工具或啰嗦的地方。

一条智能体追踪，用红笔批改。

为什么红笔很重要：与自动生成图表相比，手动阅读二十条追踪显得很慢，但它能节省数天的无用功。与其猜测假设性的失败模式并编写偏离目标的通用评分标准，不如花一小时用红笔批改，看清你的系统在现实中究竟是如何出错的。把这些笔记汇总起来，你就能得到一份高信号量的清单，列出接下来需要构建的确切确定性断言和布尔评判检查。

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

一旦你有了这份初步的检查清单，像 agent-eval toolkit 这样的工具就会接手繁重的工作并标准化执行流程。在以下方面为你提供帮助：

• 脚手架与执行：为你的黄金数据集搭建脚手架，并通过 HTTP（--base-url）或离线方式针对你的智能体执行多轮场景。
• 框架无关的追踪摄取：无论你是用 Google ADK、LangGraph 还是自定义运行时构建，都能获得符合 OpenInference 约定的结构化 OpenTelemetry 追踪。
• Agent Evaluation 集成：将这些追踪路由到 Gemini 平台上的 Agent Evaluation 服务，无需编写定制的 API 代码即可运行你的确定性检查和布尔评判评分标准。

用你的评估流水线建立规律的运行节奏：

• 每次变更都运行：每当你调整提示词、更换模型或编辑工具文档字符串时，都执行完全相同的测试组合，并将差异与你的基线进行比较。

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

• 用你的追踪数据验证评判器：永远不要盲目信任一个新的 LLM-as-a-judge 指标。将自动评分与你在第 0 天手工评分的追踪数据进行对比。如果评判器给你用红笔标记过的追踪数据打了通过分，就收紧评分提示词，直到自动信号与你的工程判断一致。

调优循环：50 到 60 次拧旋钮的迭代，而非重写

一旦你的第 1 天框架开始运行，优化就变成一个有条不紊、机械化的循环：

在示例 agent 上进行一轮调优循环。

在实际部署中，达到生产质量通常需要 50 到 60 次小迭代。你不是每天早上重写整个系统提示词，而是在逐步拧动一个个旋钮。一次微调澄清某个工具参数的描述。下一次添加一条负面约束。再下一次调整 JSON 输出 schema。

例如，每次评估运行完成后，agent-eval 框架会构建一份交互式、一体化的 HTML 报告。这份报告将通过/失败的布尔指标与关键运营指标并列呈现，包括延迟、token 用量、API 支出、缓存利用率以及详细的工具调用执行路径。此外，它还集成了针对失败对话轮次的自动化 Gemini 根因分析，精确定位触发失败的具体提示词指令或参数设置，以指导你的下一次调整。

这些数据取代了直觉。一次提示词改动在人工抽查时可能感觉聪明得多，结果测试集却显示延迟翻倍、工具调用幻觉上升了 15%。

对构建 agent 的团队来说，教训是：小而可度量的改动每次都胜过大规模重写。

一旦你信任评估流水线输出的信号，就把它变成永久的回归安全网：

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

1. 全局通过阈值：测试套件必须达到最低通过标准（例如 95% 布尔成功率）。
2. 核心评估指标零回归：即使总体分数保持稳定，只要任何此前通过的指标出现回归，构建就会失败。这可以防止开发者意外地用一项关键能力去换取某个边缘场景的小改进。

• 共享仪表盘与集中式存储：配置你的评估流程，将运行产物——包括原始追踪 JSONL、提示词哈希、模型版本、延迟概况和评分卡摘要——导出到 BigQuery 或 Cloud Storage 等中央数据仓库。将这些指标发布到团队共享仪表盘，让所有人都能了解各版本间的准确率、延迟百分位数和 token 预算。

上线后，真实的生产追踪数据会回流到黄金数据集中。

实际效果演示

配套的 AI Agent Clinic 节目。制作团队：在此处嵌入 YouTube 播放器，并使用此卡片作为缩略图或后备内容。

• 观看演示：查看我们的配套视频 How to Actually Evaluate (Any) AI Agent: Beyond the Vibe Check，我们在其中用 60 分钟在一个真实的 LangGraph agent 上现场构建整套流水线。
• 获取代码：克隆 GitHub 上的开源 agent-eval 工具包，即可开箱即用地搭建数据集、收集 trace 并生成诊断 HTML 报告。
• 外循环，洞察优先：一个能诊断你生产环境 Agent 的环境质量 Agent。

常见问题

对 AI Agent 进行手动“感觉检查”存在哪些问题？

在终端里跑三四个提示词只能看到最终的文本回复。Agent 可能在重试上循环、幻觉出工具参数、烧掉 token 预算，或触发重复的副作用，同时仍然返回一个礼貌的答案。自动化 trace 评估会检查中间工具调用、状态转换、延迟百分位数和 API 成本，以及答案质量，从而避免静默回归被发布出去。

如何从零开始评估一个 AI Agent？

把评估看作从第 0 天到第 2 天的渐进式推进，而不是全有或全无的跳跃。在第 0 天，把你的关键用户旅程（CUJ）拆分成少量测试场景，并通过 ADK 用户模拟运行它们。用“红笔”阅读最初的 5 到 20 条执行 trace，看看 Agent 在哪里犹豫、选错工具或啰嗦。

在第 1 天，把这些红笔批注转化为自动化检查，这样你就可以一次只调一个变量。一旦通过率稳定下来，就把这些检查锁定为第 2 天的 CI/CD 拉取请求门禁。

为什么在 LLM-as-a-judge 中使用布尔（通过/失败）检查，而不是 1 到 5 分的评分量表？

LLM 评判者无法一致地对 1 到 5 分量表进行评分，因为“3”和“4”之间的边界会因运行而异。使用 自适应评分标准，你可以把宽泛的质量目标拆分成严格的 Yes/No 问题，比如“Agent 在退款前是否验证了账户 ID？”把这些布尔评分标准与针对工具参数和引用检查的确定性计算指标，以及针对延迟和 token 预算的 trace 断言搭配使用。

我可以在 LangGraph、Google ADK 和自定义 Agent 框架之间使用同一套评估流水线吗？

可以，只要你通过将 OpenTelemetry trace 标准化为 OpenInference 语义约定，把评估流水线与 Agent 框架解耦。开源 agent-eval 工具包会把这些 trace 直接路由到 Gemini 平台（原 Vertex AI Evaluation）上的 Agent Evaluation 服务。切换编排框架时，你不必重写评分代码。

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

一旦你的第 2 天流水线把 trace 和记分卡导出到 BigQuery 或 Cloud Storage，你就可以把实时流量与生产前基线进行比较。当用户遇到你最初场景遗漏的边缘情况时，像 The Outer Loop 这样的环境质量 Agent可以帮助你诊断那些失败的生产 trace。然后你可以把这些真实 trace 直接提升到你的第 0 天黄金数据集中，让你的测试套件随实时使用而演进。

上一页

下一页