【智能体测评-03】测评的四个层次：从单元测试到生产观测

为什么要分层

很多团队做 Agent 测评的方式是：攒几十条 case，跑一遍，数一下成功率，然后——没有然后了。成功率涨了高兴，跌了排查，仅此而已。

这种做法的问题是把所有质量问题混在一个数字里。一次端到端测试失败，可能是 prompt 改坏了规划逻辑，可能是某个工具的 API 变了，可能是模型版本升级后输出格式漂移，也可能就是这条 case 本身有歧义。一个 72% 的成功率告诉你“有问题”，但不告诉你问题在哪、该谁修、怎么修。

软件工程用了几十年解决这个问题，答案是分层测试金字塔：单元测试抓函数级错误，集成测试抓模块间接口，端到端测试抓用户路径。不同层用不同的成本、速度、覆盖范围去捕获不同类型的问题。

Agent 测评也需要类似的分层。但 Agent 比传统软件多了两个复杂因素：一是它的行为是非确定性的（同样输入可能产生不同轨迹），二是它的“模块”是模型推理而非确定函数。所以分层方式也不同。

我们把 Agent 测评分为四个层次：

graph TB
    L4["L4 生产观测层<br/>线上 trace · 用户反馈 · 成本时延"]
    L3["L3 任务测评层<br/>端到端成功率 · 任务质量 · 满意度"]
    L2["L2 轨迹测评层<br/>规划 · 工具调用 · 步数<br/>回溯 · 成本"]
    L1["L1 组件测评层<br/>单步规划 · 工具选择 · 信息抽取"]

    L1 --> L2 --> L3 --> L4

    style L4 fill:#e8f5e9,stroke:#2e7d32
    style L3 fill:#e3f2fd,stroke:#1565c0
    style L2 fill:#fff3e0,stroke:#e65100
    style L1 fill:#fce4ec,stroke:#c62828

从下到上：越往上越接近真实场景，信号越有说服力，但成本越高、反馈越慢、定位问题越难。四层不是互斥的，而是互补的——一个成熟的测评体系需要同时拥有四层，各自承担不同的职责。

下面逐层展开。

L1：组件测评层

测什么

L1 把 Agent 拆成最小的可测能力单元，逐个测试。它对应的是传统软件的单元测试。

需要测的组件取决于你的 Agent 架构，但通常包括：

• 单步规划：给定当前状态和目标，模型能不能产出合理的下一步动作
• 工具选择：给定任务描述和可用工具列表，能不能选对工具
• 参数构造：给定工具和任务上下文，能不能生成正确的参数
• 信息抽取：从一段网页/文档/API 返回中能不能提取出指定字段
• 输出格式化：能不能按约定的 schema 输出结构化结果
• 分类/路由：能不能正确判断用户意图、任务类型、是否需要人工介入

L1 的核心特征是：每个测试只验证一件事，输入和期望输出都是明确的。

怎么测

L1 最适合用“批量 case + 自动判分”的方式跑。每个组件准备一个测试集，数据来源可以是：

1. 从真实轨迹中截取的单步快照（把 Agent 历史执行到某一步的上下文存下来，验证这一步的决策是否正确）
2. 人工构造的边界 case（空输入、异常格式、歧义指令）
3. 对抗性 case（故意引导模型选错工具或参数）

判分方式以规则校验为主：

• 工具选择：选的工具名是否在期望集合中（精确匹配或模糊匹配）
• 参数构造：参数 JSON 是否符合 schema、关键字段值是否正确
• 信息抽取：抽取的字段与标注值的精确匹配率 / F1
• 输出格式：是否能被 JSON parser 正确解析、schema 校验是否通过

L1 不建议用 LLM-as-Judge——组件级的判断通常有客观标准，规则判分更快、更便宜、更稳定。

成本与速度

• 速度：极快。每个 case 一次模型调用，几百条 case 几分钟跑完。
• 成本：极低。通常只需要 input token，不需要多轮对话。
• 反馈周期：秒级到分钟级，可以放进 CI/CD，每次代码或 prompt 变更自动跑。

陷阱

陷阱一：mock 了一切，测了个寂寞。 L1 为了隔离组件，通常会 mock 掉工具返回和环境状态。但如果 mock 的数据和真实环境差异太大，L1 全绿不代表任何东西。建议从真实轨迹中采样 mock 数据，而不是凭空编造。

陷阱二：把 L1 当万能药。 单个组件都对，不代表组合起来对。两个组件的接口约定可能在多轮交互中漂移，上下文累积可能导致某个组件的输入分布和单测时完全不同。这需要 L2 来捕获。

陷阱三：测试集太小。 L1 是最适合大规模测试的层次，不要只用几十条 case。每个关键组件至少几百条，覆盖正常、边界、异常三类输入。

什么时候用

• 每次 prompt / 工具描述 / 模型版本变更后快速回归
• CI/CD 流水线的门槛检查
• 定位“具体是哪个能力组件退化了”

L2：轨迹测评层

测什么

L2 不只看 Agent 最后成没成，还看它怎么走的。它把一次完整的 Agent 执行视为一条轨迹（trajectory）——一系列“思考→行动→观察”循环——然后对整条轨迹的质量进行评估。

L2 关注的指标包括：

• 任务完成率：最终是否完成（这是 L3 也会看的，但 L2 同时看过程）
• 步数 / 轮次：完成任务用了多少步，是否存在明显的绕路
• 工具调用准确率：所有工具调用中，选对工具且参数正确的比例
• 有效动作率：所有动作中，对任务推进有实质贡献的比例（vs 无效重试、重复读取）
• 回溯次数：Agent 主动发现走错路并回退的次数（少量回溯是好的，频繁回溯说明规划差）
• 错误恢复率：遇到工具失败或环境异常后，成功恢复的比例
• Token / 成本消耗：完成任务花了多少 token、调用了多少次模型
• 端到端时延：从接收任务到输出结果的总耗时

怎么测

L2 的输入是一批完整任务，输出是每条轨迹的详细指标。跑的方式和 L3 类似（都是端到端跑任务），但分析方式不同。

判分方式有三种组合：

1. 自动指标提取：步数、工具调用次数、token 消耗、时延这些可以从 trace 中直接计算，不需要任何模型判断。
2. 步骤级规则校验：对轨迹中的关键步骤设置检查点。比如“必须在调用 book_flight 之前调用 search_flight”、“不能调用 delete_file 除非有备份确认”。这些可以用规则引擎自动检查。
3. 轨迹级 LLM-as-Judge：给评审模型看整条轨迹（或关键片段），让它按 rubric 打分。比如“规划合理性”、“工具使用效率”、“错误处理质量”这些维度很难用规则判断，适合用模型评审。

轨迹测评的一个关键实践是 A/B 轨迹对比：同一个任务跑两个版本的 Agent（旧版 vs 新版），把两条轨迹放在一起对比。很多时候单看一条轨迹说不上好坏，但两条一比就很清楚——新版少绕了 3 个弯、少调了 5 次工具、在同一个报错处恢复得更快。

成本与速度

• 速度：中等。取决于任务复杂度，简单任务几十秒，复杂研究类任务可能几十分钟。
• 成本：中等偏高。每条轨迹包含多轮模型调用，再加上 LLM judge 的评审调用，单条成本可能是 L1 的几十到几百倍。
• 反馈周期：分钟级到小时级。适合每次发版前跑，不适合每次 commit 都跑。

陷阱

陷阱一：只看成功率，不看过程。 这是 L2 最容易被浪费的方式。两个版本成功率都是 80%，但一个平均 5 步完成、另一个平均 20 步，后者的体验和成本都差得多。如果只统计成功率，这个差异完全被掩盖。

陷阱二：指标太多，没有重点。 L2 可以提取的指标很多，但不是每个都重要。建议根据场景选 3-5 个核心指标作为发布门槛，其他指标只做观测不做卡点。否则每次发版都要解释十几个指标的波动，精力会被稀释。

陷阱三：LLM judge 的偏见没校准。 轨迹评审的 rubric 如果设计不好，judge 模型会偏好“看起来更详细”的轨迹（更长的推理、更多的工具调用），而不是更高效的轨迹。这个问题第 5 篇会详细展开。

什么时候用

• 版本发布前的对比测评（新版 vs 旧版）
• 评估 prompt / 架构改动对效率和成本的影响
• 发现“成功但低效”的隐性问题
• 为失败归因提供轨迹证据

L3：任务测评层

测什么

L3 是最接近“Agent 到底好不好用”的测评：给它一个真实任务，看它能不能完成、完成质量如何。它对应传统软件的端到端测试，但评估标准更复杂。

L3 关注的核心问题：

• 任务成功率：给定一批有明确完成标准的任务，Agent 成功完成的比例
• 完成质量：成功完成的任务中，输出质量如何（不只是“做了”，还要“做得好”）
• 安全合规率：执行过程中是否触发了不安全操作、违反了政策约束
• 用户满意度（模拟）：在有人参与或模拟用户的场景中，任务结果是否满足用户期望

怎么测

L3 的关键是任务集的设计。一个好的 L3 任务集需要满足：

1. 真实性：任务来源于真实用户需求或生产日志，而不是测评设计者凭空想象
2. 分级难度：简单/中等/困难任务按比例混合，不要全是简单题（虚高成功率）也不要全是难题（打击信心且无法追踪进步）
3. 独立可验证：每个任务都要有明确的完成标准，最好能自动验证（检查数据库状态、验证文件内容、比对 API 调用记录）
4. 覆盖核心场景：覆盖你的 Agent 实际会遇到的主要任务类型，不要在边缘场景上投入过多
5. 定期更新：每季度审视一次，淘汰已经被“刷爆”的任务（成功率 95%+ 的任务区分度很低），补充新的失败 case

评分机制通常是三层组合：

• 规则校验（自动）：有客观完成标准的任务用规则判断。比如“创建了一条记录且字段 X=Y”、“发送了邮件且收件人正确”。
• LLM-as-Judge（半自动）：开放性任务（写报告、做调研、生成建议）用模型按 rubric 打分，重点维度包括完整性、准确性、有用性。
• 人工抽检（人工）：从 LLM judge 的结果中抽样 10-20% 人工复核，校准 judge 的准确性；对争议 case 做最终裁定。

L3 还有一个重要变种：交互式测评。不是给 Agent 一个静态任务描述就不管了，而是用一个“用户模拟器”或真人在过程中回应 Agent 的提问、提供补充信息、甚至临时改变需求。这比静态任务更接近真实使用场景，但成本也更高。τ-bench 就是这种模式的代表，第 9 篇会详细讲。

成本与速度

• 速度：慢。一批 100-500 个任务，每个任务几分钟到几十分钟，整体可能需要几小时。
• 成本：高。每个任务多轮模型调用 + judge 调用 + 可能的人工评审，单条成本从几毛到几块钱不等，批量跑一次可能几百到几千块。
• 反馈周期：小时级到天级。适合版本发布前的完整回归，不适合快速迭代。

陷阱

陷阱一：任务集太小且不更新。 20 条 case 跑出来的成功率置信区间极宽（±20% 都不奇怪），而且 Agent 很快会对这 20 条 case 过拟合——prompt 越调越像在“做题”而非“解决问题”。建议 L3 任务集至少 100 条起步，核心场景 300+，并且持续从生产环境回采新 case。

陷阱二：只看平均成功率，不看分布。 80% 成功率可能意味着“100 个任务成了 80 个”，也可能意味着“简单任务全成、困难任务全败”。后者说明 Agent 的能力边界非常窄，但平均数字掩盖了这一点。一定要按任务类型、难度、场景分别统计成功率。

陷阱三：测试环境和生产环境差异太大。 测试用的工具是 mock 的、数据是脱敏的、网络是通畅的、用户是配合的——到了生产环境全反过来了。L3 要尽量在仿真环境（staging）中跑，使用真实的工具 API 和尽可能接近真实的测试数据。

陷阱四：把 L3 当唯一指标。 L3 成功率是最终结果指标，但它不能告诉你为什么失败。一个版本的成功率从 85% 跌到 80%，你需要回到 L2 看轨迹、回到 L1 看组件，才能定位原因。四层是联动的。

什么时候用

• 版本发布前的最终质量门禁
• 不同模型 / 框架 / 架构的横向对比
• 向团队或管理层汇报 Agent 质量水平
• 定期（每周/每双周）的完整回归测试

L4：生产观测层

测什么

L1-L3 都是在发布前跑的，不管多仿真，都是“考试”。L4 是 Agent 在真实环境中服务真实用户时的持续观测——它是“实战”。

L4 关注的不是“考试分数”，而是“生产表现”：

• 线上任务成功率：真实用户请求的任务完成比例（需要用户反馈或后验验证）
• 用户行为信号：用户是否采纳了 Agent 的输出、是否重试、是否中途放弃、是否请求人工
• 失败分布：线上失败 case 按失败类型（第 2 篇的 26 种）的分布和趋势
• 成本与时延：P50/P95/P99 时延、平均 token 消耗、单任务成本
• 安全事件：越权操作、数据泄露、违规内容输出的发生次数和严重程度
• 退化检测：某个能力维度的指标在没有发版的情况下突然变化（通常意味着上游模型 API 漂移或环境变化）

怎么测

L4 不是“跑测试”，而是“建系统”。它需要一套完整的可观测性基础设施：

1. 全链路 Trace：每次 Agent 执行都记录完整的轨迹——每一步的输入、输出、工具调用、时延、token 消耗。用 OpenTelemetry 或 LangSmith / Braintrust 这类工具。没有 trace，线上问题就是黑盒。
2. 用户反馈采集：在 Agent 输出后提供简单的反馈入口（赞/踩、重试、修改），以及隐式信号（用户是否复制了输出、是否在 X 秒后重新提问了类似问题）。
3. 自动告警：对关键指标设置阈值和异常检测。比如“工具调用错误率超过 5% 告警”、“P95 时延比 7 天均值涨了 30% 告警”、“某类失败类型的日发生量翻倍告警”。
4. 失败 case 回采：自动把线上失败或低评分的轨迹存入测评集，经过脱敏和标注后进入 L2/L3 的回归测试集。这是测评闭环最关键的一环——生产环境发现的问题变成测试用例，防止下次再犯。
5. 金丝雀发布：新版本先放 5-10% 流量，对比新旧版本的线上指标，确认没有退化后再全量。L4 的金丝雀对比比 L3 的离线测评更有说服力，因为它面对的是真实流量。

成本与速度

• 速度：实时。数据持续产生，监控大盘实时更新。
• 成本：持续投入。Trace 存储、监控系统、人工标注/抽检都需要长期成本。但这是必须花的钱——没有 L4 的团队等于在裸奔。
• 反馈周期：实时告警（秒级到分钟级）+ 周期性复盘（天级/周级）。

陷阱

陷阱一：只监控系统指标，不监控任务质量。 CPU、内存、API 延迟这些系统指标正常不代表 Agent 表现正常。Agent 可能在 200ms 内返回了一个完全错误的答案，系统监控看起来一切绿色。必须有任务维度的质量监控。

陷阱二：采集了 trace 但没人看。 Trace 数据是给人排查问题用的，如果没有好的检索和可视化，它就是一堆昂贵的日志。确保团队有定期复盘线上失败 case 的机制，而不是 trace 存完就完事。

陷阱三：线上失败不回灌测试集。 这是最常见的断裂——线上发现了问题，临时修了，但没有把这个 case 加到回归测试里。几个月后类似问题再次出现，所有人都忘了之前踩过这个坑。每一个线上事故都应该变成至少一个测试用例。

陷阱四：隐私和合规。 生产 trace 里可能包含用户的敏感信息。在存储、标注、用于模型训练之前，必须有脱敏机制和合规审查。这不是技术问题，是红线问题。

什么时候用

• 始终运行，从 Agent 上线第一天起
• 版本金丝雀发布期间的对比观测
• 每周/每双周的质量复盘
• 线上事故的根因分析

四层的关系：不是替代，是互补

四层之间最常见的误解是“我们有 L3 端到端测试就够了”或者“等上线了看 L4 就行”。不对。四层各自捕获不同类型的问题，缺了任何一层都会有盲区：

一个健康的测评体系，四层的投入比例大致是：L1 占 50%（大量快速测试，覆盖核心组件），L2 占 25%（每次发版前跑轨迹对比），L3 占 15%（定期完整回归），L4 占 10%（持续运维，但这 10% 的长期投入是保障）。

这个比例不是固定的——在 Agent 开发早期，L1 和 L2 的比重应该更高，因为基础能力还不稳定；当 Agent 上线后，L4 的比重需要逐步加大。

另外，四层之间应该有联动机制：

• L4 发现线上失败 → 归因到具体失败类型 → 在 L2/L1 构造定向回归 case
• L3 发现成功率下降 → 查看 L2 轨迹定位是哪个环节的问题 → 回到 L1 验证组件
• L1 发现某个组件退化 → 先修，修完后跑 L2/L3 确认修复没有引入新问题
• L2 发现某类轨迹异常 → 检查 L4 是否在线上也有同类问题

四层联动，才是总纲里说的“持续闭环”。

你的团队现在在哪一层

一个快速自检：

• 只有 L3（甚至连 L3 都没有，靠人工试用）：你还处于“手工作坊”阶段，每次改 prompt 都提心吊胆，不知道会弄坏什么。建议先补 L1——把核心工具调用和输出格式测试建起来。
• 有 L1 和 L3，没有 L2：你能知道“成没成”和“单个组件对不对”，但不知道中间发生了什么。失败了要靠人工读日志排查。建议补 L2 的轨迹指标采集。
• 有 L1/L2/L3，没有 L4：发布前质量有保障，但上线后是黑盒。建议尽快接入 trace 和用户反馈，至少做到“线上出问题能查到”。
• 四层都有：你已经超过了大多数团队。接下来的优化方向是让四层之间的联动更自动化——线上失败自动回灌、L1 测试自动从轨迹生成、版本对比全自动出报告。

小结

这篇我们展开了 Agent 测评的四层框架：

• L1 组件测评：快、便宜、精准，测单个能力，放 CI 里
• L2 轨迹测评：看过程不只是结果，测效率和路径质量，版本对比用
• L3 任务测评：端到端真实任务，测整体能力，发布门禁用
• L4 生产观测：真实环境持续监控，形成闭环，线上质量的最后防线

四层不是金字塔（不是说 L1 要最多、L4 最少），而是一个从离线到在线、从确定到模糊、从快速到慢速的光谱。每一层都有不可替代的价值，也都有自己的陷阱。

下一篇《主流 Agent Benchmark 全景拆解》，我们会把目光投向外部：GAIA、SWE-bench、WebArena、τ-bench、BrowseComp 这些公开 benchmark 到底在测什么、怎么评分的、有哪些已知漏洞、它们分别落在四层框架的什么位置。