【智能体测评-00】我们的智能体测评体系：总纲

从一次版本发布说起

假设你负责一个 Agent 产品，今天改了两行 prompt：把系统提示词里的“请仔细思考”改成了“请一步一步仔细思考并在必要时使用工具”。跑了一遍测评集，成功率从 72% 涨到了 75%。你准备发布。

但上线后你发现：

• 平均任务耗时从 40 秒变成了 90 秒
• 单次任务 token 消耗翻了一倍
• 客服群里有人反馈“它现在话特别多，还老调一些没用的工具”
• 但同时，另一批用户说“比以前靠谱了，终于能一次办成了”

那么，这个版本到底是变好还是变坏了？

这是我们做 Agent 测评时最先撞上的墙：单一指标无法描述一个智能体的质量。 成功率涨了 3%，但成本翻倍、时延翻倍、用户体验两极分化——你需要一个体系来回答这个问题，而不是一个数字。

这个系列，就是我们搭建这套体系的完整记录。

我们的三条测评观

在谈具体方法之前，先摆立场。我们怎么看待 Agent 测评，决定了我们会搭出什么样的体系。

原则一：任务导向，而非知识导向

传统大模型测评——MMLU、GPQA、MMLU-Pro——测的是模型“知道什么”。给一道题，选一个答案，判对错。这是闭卷考试的逻辑。

但智能体面对的不是考题，是任务。“帮我查一下最近三个月深圳南山区合租公寓的价格走势，对比一下自如和贝壳的报价，给我一个建议”——这个任务没有标准答案，需要搜索、抓取、对比、推理，还要在信息不全时做判断。模型可能知识渊博但不会用工具，也可能知识一般但规划能力极强、特别会调用外部能力。

所以我们的测评从第一天起就不问“你知不知道”，只问**“你能不能把这件事做成”**。

原则二：过程与结果并重

只看结果会漏掉很多东西。

一个 Agent 用了 30 步、调了 12 次工具、花了 200K token，最后把任务做成了；另一个 Agent 用了 5 步、3 次工具、20K token，也做成了。它们的成功率都是 100%，但显然不是同一个水平的智能体。

反过来，一个 Agent 失败了，但它在第三步就意识到“这个任务我需要一个我没有的权限”，然后诚实告诉用户做不到；另一个 Agent 失败了，是因为它绕了一大圈、编了一个不存在的 API、最后给了一个看起来很像那么回事但全错的答案。前者的失败比后者的“成功”更有价值。

所以我们既看结果（成没成），也看过程（怎么走的），还看失败的姿态（是不是败得体面）。

原则三：持续闭环，而非一次跑分

在大模型时代，大家习惯了“刷榜”思维：模型发布，跑个 benchmark，发个分数，完事。

Agent 不是这样。Agent 是活在生产环境里的系统，它面对的任务在变、对接的 API 在变、用户的行为模式在变、底层模型也在变。你三个月前测的 85% 成功率，今天可能因为某个上游 API 返回格式变了就掉到 60%。

所以测评不是发布前的一道闸门，是一个从开发到生产再回到开发的持续回路：线上数据反哺测评集，测评集守护版本质量，新版本带着新能力上线，再产生新的数据。

体系全景：三个维度

基于这三条原则，我们搭出了一个三维框架。这个系列后面所有文章，都能在这张图上找到位置。

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

    subgraph 能力维度
        C1["感知"]
        C2["规划"]
        C3["工具"]
        C4["记忆"]
        C5["执行"]
        C6["反思"]
    end

    subgraph 场景维度
        S1["Coding"]
        S2["客服"]
        S3["深度研究"]
        S4["..."]
    end

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

维度一：层次（L1–L4）

从下到上，越往上越接近真实，但越慢、越贵、越难定位问题。

• L1 组件层：把 Agent 拆开测。单独测一次工具调用选得对不对、一次规划输出的步骤合不合理、一次信息抽取准不准。快、便宜、容易定位，但回答不了“整体好不好用”。
• L2 轨迹层：看完整的行动序列（trajectory）。一个任务从开始到结束，Agent 走了多少步、每步调了什么工具、有没有回溯、有没有死循环。这一层最能区分“聪明”和“笨拙”的 Agent。
• L3 任务层：端到端跑真实任务，只看输入和最终输出。最接近用户体验，但失败了很难知道是哪一步出的问题。
• L4 生产层：不跑模拟任务了，直接看真实用户产生的数据。成功率、客诉率、成本、时延、用户留存，都是这一层的指标。

四层不是替代关系，是互补关系。L1 给你快速反馈，L4 给你真实信号，中间两层做桥梁。

维度二：能力

我们把一个 Agent 的能力拆成六个正交面：

• 感知：能不能准确理解用户意图、读懂环境状态、识别异常
• 规划：能不能把一个复杂任务拆成合理的执行步骤，并根据情况动态调整
• 工具：能不能选对工具、传对参数、读懂工具返回、在工具失败时正确处理
• 记忆：能不能记住长程任务中的关键信息、记住用户偏好、不重复犯错
• 执行：能不能稳定地把规划落地，不半途而废、不漂移目标
• 反思：能不能意识到自己错了、能不能从失败中恢复、能不能诚实承认能力边界

每一层测评（L1–L4）都可以针对这六个能力分别设计指标。比如 L2 轨迹层，“规划”能力看步数合理性和回溯率，“工具”能力看工具选择准确率和参数正确率，“反思”能力看错误自检出率。

维度三：场景

不同场景的 Agent，测评重点完全不同。一个 Coding Agent 和一个客服 Agent，“成功”的定义都不一样：

• Coding Agent 的成功是 patch 合入、测试通过，是有客观验收标准的
• 客服 Agent 的成功是用户问题解决、政策合规、用户满意，带主观性
• 深度研究 Agent 的成功是信息覆盖全面、引用准确、推理有洞察，最难量化

我们会在系列里选三类典型场景各写一篇，给出具体的测评方案和评分表模板。场景维度提醒我们：没有通用的 Agent 测评标尺，只有适配场景的测评方案。

测评集与评分：体系的两块基石

三维框架是骨架，还需要两块基石才能立起来。

测评集：分三层管理

我们不维护一个大而全的测评集，而是分成三套，各有分工：

• 黄金集：100–300 条，精心标注、覆盖核心能力，跑一次几分钟。每次代码提交都跑，作为 CI 门槛，掉点就拦住。
• 回归集：1000–5000 条，覆盖面广，包含历史上所有出过问题的 case。每个版本发布前跑，用于版本对比。
• 探索集：持续从生产流量和对抗性构造中补充新 case，用于发现未知问题。定期把探索集里稳定的 case 晋升到回归集。

这个分层的逻辑是：跑得快的负责守门，跑得全的负责对比，跑得野的负责发现。

评分：规则 + LLM + 人工三层判定

怎么判一个任务做得好不好？我们不押注单一方式：

• 规则校验：有客观答案的部分（HTTP 状态码、JSON 字段、文件是否生成），用代码判，又快又准。
• LLM-as-Judge：需要语义判断的部分（回答是否切题、推理是否合理、语气是否合适），用大模型当裁判。但 LLM 当裁判有一堆已知偏见，我们会用专门一篇来讲怎么校准。
• 人工抽检：LLM 裁判没把握的、争议大的、高风险场景的，交给人。人不判全部，只判模型判不准的那部分。

三层组合，兼顾成本、速度和可靠性。

这个系列会写什么

下面是完整路线图。每一篇对应体系里的一个模块，建议按顺序读，但也可以挑感兴趣的直接跳。

我们会尽量在每一篇里带上真实案例、具体数据和可复用的工具或模板，而不是停留在概念层面。如果某篇文章里的观点你不同意，欢迎拍砖——我们对这个体系也在持续迭代，很多结论会随着实践被推翻、被修正。

写在最后

Agent 测评没有银弹。

公开 benchmark 会持续被污染，模型能力会持续变强，应用场景会持续变复杂，任何一套“标准答案”都会很快过时。真正有长期价值的不是某个 benchmark 的分数，也不是某套测评模板，而是一个团队持续、系统地认识自己 Agent 质量的能力。

这个系列，就是我们构建这种能力的过程记录。

下一篇，我们从最根本的问题开始：为什么从大模型测评走到智能体测评，是一次范式上的断裂，而不是平滑的延伸。

本系列持续更新中，欢迎追更。