Google 工程师讲解如何系统评测 AI 智能体，告别 vibe check

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 秒、进行了十二次冗余的工具调用，并且每次查询花费六十美分，那它仍然是生产环境中的失败。

始终评估整个系统，而不仅仅是最终文本。在关注答案质量的同时，跟踪延迟、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 报告中的指标随时间变化。

• 用你的 trace 验证 judge： 永远不要盲目信任一个新的 LLM-as-a-judge 指标。把自动评分与你在 Day 0 手工评分的 trace 进行对比。如果 judge 给一条你标了红笔的 trace 打了通过分，就收紧评分 prompt，直到自动信号与你的工程判断一致。

调优循环：50 到 60 次拧旋钮，而不是重写

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

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

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

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

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

构建 agent 的团队应吸取的教训：小而可度量的改动每次都胜过大规模重写。

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

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

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

• 共享仪表盘与集中式存储： 配置你的评估流程，将运行产物——包括原始 trace JSONL、prompt 哈希、模型版本、延迟画像和评分卡摘要——导出到 BigQuery 或 Cloud Storage 之类的中央数据仓库。把这些指标发布到团队共享仪表盘，让每个人都能看到各版本的准确率、延迟百分位和 token 预算。

上线后，真实生产 trace 会回流到黄金数据集。

实际效果演示

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

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

常见问题

对 AI 智能体进行人工“感觉检查”存在哪些问题？

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

如何从零开始评估一个 AI 智能体？

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

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

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

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

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

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

我的智能体部署到生产环境后会发生什么？

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

上一页

下一页