评测 AI 智能体：别再靠感觉检查

评测 AI 智能体：别再靠感觉检查

2026-10-15

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

Dani Zamora，解决方案工程师。

Jesse Carah，孵化负责人。

John DeMartino，客户与合作伙伴解决方案资深工程师。

太长不看

智能体可以空转、烧掉词元（token，按模型计费的文本单位），或者给出完全编造的答案，表面上看起来仍然正常。感觉检查（vibe check，只凭最后几句回答顺不顺眼来判断）抓不住这些。本文是 AI Agent Clinic 那一集《How to Actually Evaluate (Any) AI Agent: Beyond the Vibe Check》（https://youtu.be/wPdoZRbvaF4）背后的做法。那一集在 60 分钟里，给一个 LangGraph 智能体搭起评测流水线。下面是里面有什么。

图：一眼看清的要点图。原图未随本文分发。站点政策写明，除非页面另行注明，图片不在正文的 CC BY 4.0 许可内。

评测 AI 智能体：别再靠感觉检查

团队刚开始做 AI 智能体时，测试看起来都差不多。接上一个模型，交给它几个工具，在终端里跑三四条提示，然后用眼睛看输出。答案看起来还行，就发出去。

实际里，这很快就会垮。你改一条系统提示，想修好某个工作流里的边界情况，另一个工作流里智能体却突然不再调用必须调用的工具。

更糟的是，智能体的失败方式和普通软件不一样。它可以卡在重试循环里，发出多次工具调用，最后仍然返回一句礼貌、听起来像那么回事的答案。

在生产里，这种藏起来的失败很贵：

• 它会悄悄拉高云账单和词元用量。
• 它会耗尽下游 API 的速率限制和配额。
• 它让用户一直盯着加载中的转圈。
• 它可能在外部系统里触发重复的副作用，表面却看起来“没问题”。
• 它会侵蚀用户信任，第一印象很难再赢回来。

把一套可靠的评测放进开发生命周期，在最初做原型时看起来像额外负担，直到你一改系统提示就出现意料之外的破坏性变化。关键是承认评测是一条逐步走的路：任何可重复的评测（不管多简单）都好过临时抽查，也好过完全没有系统。第 0 天不需要一套精致的自动评分架构。先做简单、可重复的检查，再随着智能体的能力和生产要求变高，把评测演变成更复杂的自动框架。

把这些决定放进一个评测框架，建立可重复的评测会容易很多。要超出简单的主观检查，靠两根支柱：人的监督，和有针对性的工具。本文讲怎样用开源的 agent-eval 工具包（https://github.com/GoogleCloudPlatform/professional-services/tree/main/tools/agent-eval）搭评测框架。把人工看过的执行轨迹（trace，一次运行里的提示、中间步骤、工具参数和最终输出）和自动核验合在一起，可以在开发早期发现无声的回归，并在智能体进入生产后继续扩上去。

起步：高层的构件

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

写测试代码之前，要对“好的结果到底长什么样”有共同看法。把测试锚在关键用户旅程（CUJ，critical user journey，用户期望系统做成的一件事）上，而不是抽象基准。

一条 CUJ 写明用户期望系统达成什么，结构围绕人物、目标、约束和核验条件：

“作为一名运营分析师，我期望智能体读入一封交易对手方的交易差异邮件，找出有争议的那笔交易，在 30 秒内对照我们的内部账本核验交易经济条款，并起草回复，把我们的内部交易编号翻回经纪商的命名，全程不需要人插手。”

这句话里的每一个分句都变成一个评测点：智能体有没有解析出正确的交易编号？起草之前有没有查账本？有没有把内部编号映射回外部命名？

图：CUJ 的每一条款都变成一个评测点。原图未随本文分发。

事先写下这些期望，会迫使产品相关方、下游用户和工程师对“成功怎么量”达成一致。

2. 先用模拟用户，再过渡到真实流量

做最初的金标准数据集（golden dataset，调参期间保持不变的那一组测试）不需要六个月的生产日志。把每条 CUJ 拆成具体场景（scenario，既有顺利路径也有边界情况），送进一个用户模拟器（user simulator，按人物和约束替用户说话的大语言模型）。作者常用 ADK 用户模拟（https://adk.dev/evaluate/user-sim/）。给模拟器一个人物和行为约束，例如不耐烦、只给不完整工单号的分析师，或者一次问出好几段调试问题的开发者，它就会模仿真实用户那种凌乱的说法、错字和多轮复杂度。

图：ADK 用户模拟的示例场景。原图未随本文分发。

让智能体对着合成用户和接近真实的场景跑，可以在用户接触之前记下完整的执行轨迹，包括工具日志。这样就能对照发布标准，找出并补上表现缺口。真实流量开始进来之后，可以逐步用生产轨迹替换这些合成设置。

3. 按整栈来量

一个总分永远不会告诉你智能体为什么失败。要分开根因，叠四类检查：单元测试、确定性指标、用大语言模型当裁判（LLM-as-a-judge，让另一个模型按条目判断）的量表，以及集成测试。

图：四层检查，从单元测试到集成测试。原图未随本文分发。

四个常见陷阱

陷阱 1：把测试扔掉，基线就断了

定评测指标要试错。人会想删掉一条很吵的测试，或者在两次运行之间换掉样例问句。可是每加一条或删一条测试，基线就作废：你分不清分数变了，是因为智能体变好了，还是因为测试套件挪了位置。调某个功能时把金标准数据集冻住，一次只改一个变量。只有确定背后的要求已经变了，才退役一条测试。

图：删测试挪动的是基线，不是智能体。原图未随本文分发。

陷阱 2：依赖含糊的 1 到 5 分，而不是二元检查

大语言模型给定性的 1 到 5 分打分，出了名地不稳定。“3”和“4”的边界含糊，而且经常一次运行和另一次运行不一样。

只要可能，就把裁判量表写成二元（boolean，只有通过或失败）问题，而不是开放的评分刻度。不要问“这个回答有多有帮助，1 到 5 分？”，要问“智能体在调用退款工具之前，有没有核验账户编号？（是／否）”。作者常用自适应量表（Adaptive Rubrics，https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/evaluation-overview#adaptive-rubrics）。

陷阱 3：只评文字，不管运营账单

一条回答即使通过了所有质量检查，如果花了 40 秒、做了 12 次多余的工具调用、每条查询花 60 美分，在生产里仍然是失败。

始终评整个系统，而不只是最后的文本。把延迟、词元消耗（提示词元、推理词元和完成词元）、API 费用和工具调用次数，和质量分一起记。

陷阱 4：换一个智能体框架就重做一套评测流水线

切换编排框架，常常迫使团队扔掉并重写整套测试。大多数框架会发出 OpenTelemetry（记录一次运行里各步骤的开放遥测）轨迹，但它们对工具调用、步骤和词元并不使用同一套语义约定。把轨迹规范到 OpenInference（https://arize.com/glossary/openinference/，给工具调用、步骤和词元计数用的一种开放语义约定）这类开放规格上，可以把评测和编排框架拆开。agent-eval 工具包原生支持这一点，设置很少。

从第 0 天到第 2 天的落地

不必从零做一套可观测平台。用 agent-eval 这类开源工具，几小时就能把评测流水线立起来。它把 OpenTelemetry 轨迹采集和 Gemini 平台上的 Agent Evaluation 服务（以前叫 Vertex AI Evaluation）配在一起。但真正的评测策略需要更多思考。

第 0 天：场景、模拟，以及“红笔”

从小处开始，贴着原始数据：

1. 起草覆盖主要 CUJ 的场景，让它们穿过智能体做模拟。
2. 先别管汇总分。从上到下读真实的执行轨迹：提示、中间推理步骤、工具参数和最终输出。
3. 用红笔给轨迹打分，标出智能体犹豫、编造参数、选错工具或说个不停的每一处。

图：一条智能体轨迹，用红笔打过分。原图未随本文分发。

红笔为什么要紧：比起自动出一张图，亲手读二十条轨迹显得慢，但它能省下好几天白做的功夫。与其猜假设的失败模式、写出打不中要害的通用量表，不如用一小时红笔看系统在现实里到底怎么坏。把这些笔记汇总起来，就得到下一轮要建的、信号很高的清单：该写哪些确定性断言，以及哪些二元裁判检查。

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

有了那份初始检查清单之后，agent-eval 这类工具接过重活，并把执行标准化。它帮你做这些事：

• 脚手架和执行：搭起金标准数据集，通过 HTTP（--base-url）或离线，对智能体跑多轮场景。
• 与框架无关的轨迹接入：无论用 Google ADK、LangGraph 还是自定义运行时，都得到带 OpenInference 约定的结构化 OpenTelemetry 轨迹。
• 接入 Agent Evaluation：把这些轨迹送进 Gemini 平台上的 Agent Evaluation 服务，跑确定性检查和二元裁判量表，不必另写 API 代码。

给评测流水线定一个固定的运行节奏：

• 每次改动都跑：只要调整提示、更换模型或修改工具的说明文字，就执行同一套测试，并和基线比差值。

图：agent-eval 的 HTML 报告里，指标随时间的变化。原图未随本文分发。

• 用你的轨迹校验裁判：绝不要盲目相信一条新的、用大语言模型当裁判的指标。把自动分数和第 0 天亲手打过的轨迹比较。如果裁判给一条你用红笔标过的轨迹打了通过，就收紧评分提示，直到自动信号和工程判断一致。

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

第 1 天的框架运转之后，优化变成一条有纪律的机械循环。

图：在一个示例智能体上，调参循环转一圈。原图未随本文分发。

在真实部署里，达到生产质量常常要 50 到 60 次小迭代。不是每天早上重写整段系统提示，而是逐渐拧单个旋钮。一次改动说清某个工具参数的描述。下一次加上一条否定约束。再下一次调整 JSON 输出模式。

例如，每次评测跑完，agent-eval 框架会做一份交互式的、合在一起的 HTML 报告。这份报告把通过／失败的二元指标和关键运营指标对齐，包括延迟、词元用量、API 支出、缓存利用，以及详细的工具调用路径。它还对失败的对话轮次放入 Gemini 的自动根因分析，指出是哪一条提示指令或哪一个参数设置触发了失败，用来指导下一次调整。

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

给做智能体的团队的教训是：小而量过的改动，每一次都胜过大重写。

第 2 天：合并门禁和共享看板

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

图：合并门禁。原图未随本文分发。

• 用无界面命令行做 CI/CD（持续集成与持续部署，把检查嵌进每次合并）拉取请求门禁：在构建流水线里无界面地跑 agent-eval 这类工具，例如 Cloud Build 或 GitHub Actions。每个拉取请求上，它跑金标准数据集，并执行两条合并规则：

1. 全局通过阈值：整套必须达到最低通过线（例如二元成功 95%）。
2. 核心评测指标零回归：即使总分稳住，只要任何先前通过的指标退步，构建就失败。这防止开发者用一项关键能力，去换一个次要边界情况的改进。

• 共享看板和集中存储：把评测过程配置成导出运行产物，包括原始轨迹 JSONL、提示哈希、模型版本、延迟剖面和记分卡摘要，放进 BigQuery 或 Cloud Storage 这类集中数据仓库。把这些指标发到团队共享看板上，让所有人看见各次发布的准确率、延迟分位数和词元预算。

图：上线之后，真实的生产轨迹流回金标准数据集。原图未随本文分发。

看它怎么做

配套视频是 Google Cloud Tech 的《Why Your AI Agent Fails in Production (And How to Catch It)》，地址 https://www.youtube.com/watch?v=wPdoZRbvaF4 。页面上的播放器在没有 JavaScript 时只显示链接。

• 看一遍走查：配套视频《How to Actually Evaluate (Any) AI Agent: Beyond the Vibe Check》（https://youtu.be/wPdoZRbvaF4）在一个真实的 LangGraph 智能体上，用 60 分钟现场搭起整条流水线。
• 拿走代码：克隆开源的 agent-eval 工具包（https://github.com/GoogleCloudPlatform/professional-services/tree/main/tools/agent-eval），用来搭数据集、采集轨迹，并直接生成诊断用的 HTML 报告。
• 相关文章：The Outer Loop, Insights First: An Ambient Quality Agent That Diagnoses Your Production Agent（https://developers.googleblog.com/the-outer-loop-insights-first-an-ambient-quality-agent-that-diagnoses-your-production-agent/）。

常见问题

对 AI 智能体做手工“感觉检查”有什么问题？

在终端里跑三四条提示，只让你看见最后的文本回答。智能体可以在重试上空转、编造工具参数、烧光词元预算，或触发重复的副作用，同时仍然返回一句礼貌的回答。自动的轨迹评测会在答案质量之外，检查中间的工具调用、状态转移、延迟分位数和 API 费用，使无声的回归不会被发出去。

怎样从零评测一个 AI 智能体？

把评测当成从第 0 天到第 2 天的逐步落地，而不是一步到位。第 0 天，把关键用户旅程拆成少量测试场景，用 ADK 用户模拟（https://adk.dev/evaluate/user-sim/）跑它们。用“红笔”读最初的 5 到 20 条执行轨迹，看智能体在哪里犹豫、选错工具或说个不停。

第 1 天，把红笔笔记变成自动检查，以便一次只调一个变量。通过率稳住之后，把这些检查锁进第 2 天的 CI/CD 拉取请求门禁。

为什么用大语言模型当裁判时，要用二元（通过／失败）检查，而不是 1 到 5 的评分刻度？

裁判模型对 1 到 5 分并不稳定，因为“3”和“4”的边界每次运行都会挪。用自适应量表（https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/evaluation-overview#adaptive-rubrics），把宽泛的质量目标拆成严格的是／否问题，例如“智能体在退款之前有没有核验账户编号？”把这些二元量表，和用于工具参数与参照检查的确定性计算指标（https://docs.cloud.google.com/gemini-enterprise-agent-platform/models/determine-eval#computation-metrics），以及针对延迟和词元预算的轨迹断言配在一起。

同一条评测流水线能不能用于 LangGraph、Google ADK 和自定义智能体框架？

可以，只要用 OpenInference 语义约定把 OpenTelemetry 轨迹标准化，把评测流水线和智能体框架拆开。开源的 agent-eval 工具包把这些轨迹直接送到 Gemini 平台上的 Agent Evaluation 服务（以前叫 Vertex AI Evaluation）。切换编排框架时，不必重写评分代码。

智能体部署到生产之后会发生什么？

第 2 天的流水线把轨迹和记分卡导出到 BigQuery 或 Cloud Storage 之后，就可以把线上流量和上线前的基线比较。用户撞上最初场景没覆盖的边界情况时，像 The Outer Loop 这样的环境质量智能体（https://developers.googleblog.com/the-outer-loop-insights-first-an-ambient-quality-agent-that-diagnoses-your-production-agent/）帮助诊断那些失败的生产轨迹。然后可以把这些真实轨迹直接晋升进第 0 天的金标准数据集，让测试套件跟着真实使用一起演变。

出处：Hugo Selbie，Dani Zamora，Jesse Carah，John DeMartino，Evaluating AI agents: moving past the vibe check，2026-10-15，https://developers.googleblog.com/evaluating-ai-agents-moving-past-the-vibe-check，CC BY 4.0。Portions of this page are modifications based on work created and shared by Google and used according to terms described in the Creative Commons 4.0 Attribution License.