为多轮 Agent 建立持续评估流水线

你的 Agent 可能陷入循环、烧掉大量 token，或者给出完全凭空编造的答案，表面上却依然看不出问题。凭感觉检查，发现不了这些情况。本文是 AI Agent Clinic 节目《如何真正评估任意 AI Agent：超越凭感觉检查》背后的实操指南。在这期节目中，我们用 60 分钟为一个 LangGraph Agent 搭建了评估流水线。以下是具体内容。

评估 AI Agent：超越凭感觉检查

团队刚开始构建 AI Agent 时，测试方式通常都差不多：接上一个模型，给它配几个工具，在终端里跑三四条 prompt，然后目测输出。只要答案看着合理，就上线。

但在实际开发中，这种方式很快就会失效。你调整了一下 system prompt，修复某个工作流中的边界情况，结果另一个工作流里的 Agent 突然不再调用必需的工具了。

更麻烦的是，Agent 的失败方式和传统软件不同。Agent 可能卡在重试循环里，接连发起多次工具调用，最后却依然返回一个语气礼貌、听起来合情合理的答案。

在生产环境中，这些隐藏的故障代价不小：

• 悄悄推高云服务账单和 token 用量。
• 耗尽下游 API 的速率限制额度和配额。
• 让用户一直盯着加载中的转圈动画。
• 在外部系统中重复触发有副作用的操作，表面上却一切“正常”。
• 侵蚀用户信任，而糟糕的第一印象很难挽回。

在原型开发初期，把可靠的评估套件纳入开发生命周期，可能会让人觉得是额外负担。直到某次修改 system prompt，引发了意料之外的破坏性变化，你才会意识到它的价值。关键在于认识到：评估是一个逐步推进的过程。任何可重复执行的评估系统，无论多简单，都比临时抽查或完全没有评估系统更好。你不需要在 Day 0 就搭建一套复杂的自动评分架构。先从简单、可重复的检查开始，再随着 Agent 能力和生产需求的增长，逐步演进为更复杂的自动化评估框架。

把这些决策纳入评估框架，能显著降低建立可重复评估系统的难度。要超越简单的主观检查，需要两大支柱：人工监督和有针对性的工具。本文将介绍如何使用开源的 agent-eval toolkit 搭建评估框架。我们会展示，如何结合人工审阅的 trace 与自动验证，在开发早期发现隐性回归，并随着 Agent 进入生产环境顺畅扩展。

从哪里开始：整体构成

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

在编写测试代码之前，你需要先让团队对“好的结果究竟是什么”形成共识。测试应该围绕关键用户旅程（Critical User Journeys，CUJs）展开，而不是围绕抽象的 benchmark。

一个 CUJ 定义了用户期望系统完成什么，并围绕用户画像、目标、约束和验证条件组织起来：

这段描述中的每一个条件，都会成为一个评估点：Agent 是否找到了正确的交易 ID？是否在起草内容前检查了账本？是否把内部 ID 映射回了外部使用的命名？

提前明确这些预期，能促使产品相关方、下游用户和工程师就如何衡量“成功”达成一致。

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

构建最初的黄金数据集，并不需要先积累六个月的生产日志。你可以把每个 CUJ 拆成具体场景，包括正常流程和边界情况，再把它们交给用户模拟器 LLM，我们比较喜欢 ADK user simulations。为模拟器设定用户画像和行为约束，例如，一位不耐烦、只提供不完整工单编号的分析师，或者一位提出多部分调试问题的开发者，它就能模拟真实用户混乱的措辞、拼写错误，以及多轮交互的复杂性。

用合成用户和贴近实际的场景测试 Agent，可以在真实用户开始交互之前，记录完整的执行 trace，包括工具日志。这样，你就能准确定位并解决与发布标准之间的差距。真实流量开始进入后，再逐步用实际生产 trace 替换这些合成测试场景。

3. 覆盖整个技术栈进行衡量

单一的总分永远无法告诉你 Agent 为什么失败。要定位根因，需要分层使用四类检查：单元测试、确定性指标、LLM-as-a-judge 评分准则，以及集成测试。

四个常见陷阱

陷阱 1：随意删除测试，破坏评估基线

设置评估指标需要反复试验，你很容易想删掉噪声较大的测试，或者在两次运行之间替换示例查询。但每次增删测试，都会让基线失效：你无法判断分数变化究竟是因为 Agent 变好了，还是因为测试套件变了。调优某个功能时，要保持黄金数据集不变，一次只改一个变量；只有确定底层需求已经变化，才移除对应测试。

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

LLM 在按 1 到 5 分的定性量表打分时，一贯缺乏一致性。“3 分”和“4 分”的界限很模糊，而且经常随运行而变化。

只要有可能，就把评分准则改成布尔问题，也就是通过或失败，而不是开放式评分量表。与其问“这个答案有多大帮助，请打 1 到 5 分”，不如问“Agent 是否在调用退款工具前验证了账户 ID？（Yes/No）”。我们比较喜欢 Adaptive Rubrics。

陷阱 3：只评估文字，忽略运行账单

一个回答即使通过了所有质量检查，如果它耗时 40 秒、进行了 12 次冗余工具调用，而且每次查询花费 0.60 美元，在生产环境中仍然算失败。

始终评估整个系统，而不只是最终文本。在衡量答案质量的同时，也要跟踪延迟、token 消耗，包括 prompt、reasoning 和 completion tokens，以及 API 成本和工具调用次数。

陷阱 4：每换一个 Agent 框架，就重建一条评估流水线

切换编排框架，往往迫使团队废弃并重写整套测试。虽然大多数框架都会输出 OpenTelemetry trace，但它们对工具调用、步骤和 token 使用的语义约定并不相同。按照 OpenInference 这样的开放规范统一 trace，可以把评估与编排框架解耦，解决这个问题。agent-eval toolkit 等工具原生支持这种方式，只需少量配置。

从 Day 0 到 Day 2 的落地步骤

你不需要从头构建一个可观测性平台。使用 agent-eval toolkit 这样的开源工具，几个小时就能搭起评估流水线。它将 OpenTelemetry trace 采集与 Gemini 平台上的 Agent Evaluation 服务结合起来，后者的前身是 Vertex AI Evaluation。不过，真正制定评估策略，还需要更深入的思考。

Day 0：场景、模拟与“红笔批改”

从小处着手，直接查看原始数据：

• 编写覆盖主要 CUJs 的场景，并让模拟用户与 Agent 交互。
• 先别管汇总分数，从头到尾阅读实际执行 trace：prompt、中间推理步骤、工具参数，以及最终输出。
• 拿起“红笔”批改 trace，标出 Agent 犹豫不决、编造参数、选错工具或啰嗦跑题的每一处。

为什么红笔批改很重要：与自动生成一张图表相比，手动阅读 20 条 trace 看起来很慢，却能节省数天的无用功。与其猜测假想的失败模式，编写一堆抓不住问题的通用评分准则，不如花一个小时拿红笔批改，看看系统在实际运行中究竟会怎样出错。把这些批注汇总起来，你就能得到一份高价值清单，明确接下来需要编写哪些确定性断言和布尔评判检查。

Day 1：运行节奏、有效信号与测试框架

有了最初的检查清单后，agent-eval toolkit 这样的工具就可以接手繁重工作，并统一执行方式。它能帮你完成这些事情：

• **初始化与执行：**搭建黄金数据集的初始结构，通过 HTTP（--base-url）或离线方式，针对 Agent 执行多轮场景。
• **与框架无关的 trace 接入：**无论你使用 Google ADK、LangGraph，还是自定义运行时，都能获取遵循 OpenInference 约定的结构化 OpenTelemetry trace。
• **集成 Agent Evaluation：**将这些 trace 发送到 Gemini 平台上的 Agent Evaluation 服务，运行确定性检查和布尔评分准则，无需专门编写 API 对接代码。

让评估流水线按固定节奏运行：

• **每次变更都运行：**无论是调整 prompt、更换模型，还是修改工具的 docstring，都执行完全相同的一组测试，并与基线比较差异。
• **用人工审阅过的 trace 验证评判模型：**不要盲目信任新的 LLM-as-a-judge 指标。把自动评分与 Day 0 手工批改的 trace 对照。如果评判模型让一条被你用红笔标出问题的 trace 通过，就收紧评分 prompt，直到自动评估信号与你的工程判断一致。

调优循环：做 50 到 60 次小幅调整，而不是重写

Day 1 的框架投入运行后，优化就变成了一套严谨、可重复执行的循环：

在真实部署中，达到生产质量往往需要 50 到 60 次小幅迭代。你不必每天早上都重写整份 system prompt，而是逐项微调。一次修改把工具参数描述写得更清楚，下一次增加一条禁止性约束，再下一次调整 JSON 输出 schema。

例如，每次评估运行结束后，agent-eval 框架都会生成一份交互式的一体化 HTML 报告。报告把通过或失败的布尔指标与关键运行指标并排展示，包括延迟、token 用量、API 支出、缓存利用率，以及详细的工具调用执行路径。此外，报告还包含 Gemini 自动生成的失败对话轮次根因分析，指出究竟是哪条 prompt 指令或哪个参数设置触发了失败，为下一步调整提供依据。

这些数据取代了直觉。一次 prompt 修改，在人工抽查时可能显得聪明了许多，但完整测试却可能发现，延迟翻了一倍，工具调用中的幻觉增加了 15%。

对构建 Agent 的团队来说，经验很明确：小幅、可衡量的修改，总比大规模重写更有效。

Day 2：合并门禁与共享仪表盘

当你开始信任评估流水线输出的信号，就可以把它变成长期防范回归的安全网：

**通过无界面 CLI 设置 CI/CD pull request 门禁：**在 Cloud Build 或 GitHub Actions 等构建流水线中，以无界面模式执行 agent-eval 之类的工具。每个 pull request 都运行黄金数据集，并强制执行两条合并规则：

• **全局通过阈值：**测试套件必须达到最低通过标准，例如布尔检查成功率达到 95%。
• **核心评估指标零回归：**即使总分保持稳定，只要任何一个之前通过的指标出现回归，构建就失败。这能防止开发者为了改善一个次要边界情况，无意中牺牲关键能力。

**共享仪表盘与集中存储：**配置评估流程，将运行产物导出到 BigQuery 或 Cloud Storage 等集中存储中，包括原始 trace JSONL、prompt 哈希、模型版本、延迟分布，以及评分卡摘要。把这些指标发布到团队共享仪表盘，让所有人都能看到不同版本的准确性、延迟百分位数和 token 预算。

**观看演示：**查看配套视频《如何真正评估任意 AI Agent：超越凭感觉检查》。我们在视频中，以一个真实的 LangGraph Agent 为例，用 60 分钟现场搭建了整条流水线。

**获取代码：**从 GitHub 克隆开源的 agent-eval toolkit，即可开箱即用地搭建数据集、采集 trace，并生成诊断用 HTML 报告。

The Outer Loop，洞察优先：一个为生产环境 Agent 诊断问题的常驻质量 Agent。

常见问题

人工“凭感觉检查”AI Agent 有什么问题？

在终端里运行三四条 prompt，只能看到最终的文本回答。Agent 可能陷入重试循环、编造工具参数、烧光 token 预算，或重复触发有副作用的操作，最后却仍然给出一个礼貌的回答。自动化 trace 评估会在检查答案质量的同时，检查中间工具调用、状态转换、延迟百分位数和 API 成本，避免隐性回归被带上线。

如何从零开始评估 AI Agent？

把评估看作从 Day 0 到 Day 2 逐步落地的过程，而不是一次非做不可、非全不可的跨越。Day 0 时，把关键用户旅程（CUJs）拆成少量测试场景，通过 ADK user simulations 运行。拿“红笔”阅读最初的 5 到 20 条执行 trace，看看 Agent 在哪里犹豫、选错工具或啰嗦跑题。

Day 1 时，把这些红笔批注转成自动检查，让你能够一次只调一个变量。通过率稳定后，在 Day 2 把这些检查固化为 CI/CD pull request 门禁。

为什么 LLM-as-a-judge 应使用布尔检查，而不是 1 到 5 分评分？

LLM 评判模型无法稳定地按 1 到 5 分评分，因为“3 分”和“4 分”的界限会随着每次运行变化。借助 Adaptive Rubrics，你可以把宽泛的质量目标拆成严格的 Yes/No 问题，例如“Agent 是否在退款前验证了账户 ID？”再把这些布尔评分准则与针对工具参数和参考信息核验的确定性计算指标结合起来，同时使用 trace 断言检查延迟和 token 预算。

LangGraph、Google ADK 和自定义 Agent 框架能共用一条评估流水线吗？

可以，前提是按照 OpenInference 语义约定统一 OpenTelemetry trace，让评估流水线与 Agent 框架解耦。开源的 agent-eval toolkit 会把这些 trace 直接发送到 Gemini 平台上的 Agent Evaluation 服务，其前身是 Vertex AI Evaluation。这样，切换编排框架时就不必重写评分代码。

Agent 部署到生产环境之后，还要做什么？

当 Day 2 流水线开始向 BigQuery 或 Cloud Storage 导出 trace 和评分卡后，你就可以把真实流量与上线前的基线进行比较。当用户遇到初始场景未覆盖的边界情况时，The Outer Loop 这样的常驻质量 Agent 可以帮助诊断这些失败的生产 trace。之后，你可以直接把这些真实 trace 纳入 Day 0 的黄金数据集，让测试套件随着实际使用持续演进。