分享一套很好用的美团Agent评测体系

如果一个Agent最后生成了正确答案，你会让它通过吗？

先别急。假设你给Agent一个任务：

从测试环境提取本周缺陷数据，生成质量周报，并保存到指定目录。

但当你打开执行记录，却发现它先连错了数据库，又连续调用了十几次工具，中间尝试读取生产表，最后碰巧拿到了正确数据。

这还能算通过吗？显然不能。

可很多团队现在做Agent评测，依然沿用传统大模型的思路：准备一批问题，运行一次，检查答案，再算一个准确率。

这套方法测聊天机器人或许够用，测Agent却远远不够。

因为大模型交付的是一个答案，Agent交付的是一次行动。

只盯最终答案，会漏掉最危险的问题

美团Agent评测体系，其中一个判断很关键：

Agent被放进真实系统后，评测对象就不再是单一模型，而是由模型、Prompt、Skill、工具、记忆、状态和业务流程共同组成的复杂系统。

两个Agent可能都完成了任务，工程价值却完全不同。

一个选择了正确工具，参数准确，路径清晰，耗时和成本都可控。

另一个反复试错，调用链混乱，靠偶然结果过关，第二次运行可能马上失败。

如果只检查最终答案，这两种Agent会得到相同的分数。

一旦进入生产环境，差别就暴露了。

它可能读错数据、重复发消息、绕过审批、修改了不该修改的状态。更麻烦的是，页面上还会显示一句："任务已成功完成。"

这类问题，我更愿意叫它"带着正确答案的失败"。

所以，Agent评测至少要回答两类问题：

• Response Evaluation：
  最终交付物对不对？
• Trajectory Evaluation：
  它是怎么完成的？

结果决定任务有没有完成，轨迹决定这套能力能不能稳定上线。

一条Agent用例，应该怎么设计？

还是用"生成质量周报"这个场景。

传统用例可能只有两项：

• 输入：生成本周质量周报
• 预期结果：报告内容正确

Agent用例不能这么简单。至少要补齐五类信息。

1. 初始状态

Agent运行前，系统处于什么状态？

测试数据库里有哪些缺陷数据？目标目录里是否已经存在同名文件？用户拥有哪些权限？这些信息不固定，后面的结果就无法比较。

2. 任务目标

目标不是"回答一个问题"，而是完成一个可检查的任务。

例如：

• 读取指定测试库；
• 统计缺陷数量和等级分布；
• 按模板生成报告；
• 保存到指定目录；
• 不得发送到外部系统。

3. 允许和禁止的行为

Agent可以调用哪些工具？哪些动作必须审批？哪些状态绝对不能改变？

例如允许只读查询测试库，禁止访问生产库；允许生成文件，禁止覆盖历史报告；允许输出发送建议，但不能自动发送。

这一层不能用平均分糊过去。

越权、泄露、删除、资金操作和绕过审批，应该设置为硬门槛。其他指标再高，只要碰到红线，这次任务就应该失败。

4. 执行轨迹

记录Agent实际选择了什么工具、传入什么参数、经历了多少次重试、在哪里改变了策略。

轨迹能够回答一些最终答案解释不了的问题：

• 它选对工具了吗？
• 参数是否准确？
• 是否出现无效调用和循环？
• 工具失败后有没有恢复？
• 信息不足时，它是主动澄清，还是直接猜测？

OpenAI在官方Agent评测文档中也把Trace Grading作为定位工作流问题的重要方式。Trace会记录模型调用、工具调用、护栏和交接过程，帮助团队找到失败到底发生在哪一步。

5. 系统终态

任务执行结束后，不能只检查聊天窗口。

还要检查：

• 报告文件是否真实存在；
• 文件内容是否符合Schema；
• 数据库是否出现异常写入；
• 历史文件是否被覆盖；
• 是否产生重复消息或其他副作用。

能够用文件Diff、数据库终态、单元测试和策略规则判断的内容，优先交给确定性程序，不要全部交给另一个大模型打分。

因为"LLM Judge说可以"，不等于系统真的没有被改坏。

评分标准，比评分模型更重要

Agent输出经常带有开放性，很难只靠完全匹配判断。

这时可以使用Rubric，也就是把"好不好"拆成可执行的评分规则。

例如，"质量周报写得专业"太模糊，可以拆成：

• 是否包含缺陷总量；
• 是否区分严重等级；
• 是否标出环比变化；
• 是否说明数据范围；
• 是否出现没有证据支持的原因判断；
• 是否泄露敏感字段。

其中能用代码判断的，就用代码。

确实需要主观判断的，再让人工或LLM Judge参与。

但LLM Judge上线前，必须先与人工标准对齐。最实用的办法不是追求一个听起来很高级的评分模型，而是抽样复核它的判断：

人工之间是否一致？人工和机器是否一致？分歧集中在哪些规则？Rubric是不是写得太模糊？

真正决定AI评测上限的，往往不是Judge模型有多强，而是团队有没有把"什么叫好"说清楚。

别一上来就建设庞大的评测平台

Agent评测很容易走向另一个极端。

团队还没有多少真实Case，就开始设计几十个指标，建设复杂平台，最后每个分数都能展示，却没人知道该改哪里。

更有效的起点，是先找10到30个高频核心任务。

每条任务至少保存：

• Prompt和初始状态；
• 允许使用的工具与权限；
• 预期行为和禁止行为；
• 预期终态；
• 实际Trace；
• 判定规则；
• 失败归因。

运行后，把真实Bad Case沉淀进回归集。修复Prompt、Skill、工具或流程后，再自动重跑。

这时评测才形成闭环：

发现问题，沉淀Case，明确Rubric，修复系统，自动回归，控制发布。

如果评测结束后只剩下一张分数表，它还只是一次检查。

如果历史失败可以自动重放，版本升级会触发回归，风险操作有准入门槛，结果能够定位到规划、工具、环境或Skill，评测才开始成为基础设施。

测试人的机会，可能就在这里

很多人担心，Agent越来越强以后，测试工作会不会被替代。

但Agent越能行动，系统就越需要有人定义：

• 什么状态算任务完成；
• 哪些路径可以接受；
• 哪些副作用绝对不能发生；
• 什么情况下必须转人工；
• 一个版本是否有资格进入生产。

这不是多写几条提示词能解决的。

它需要测试设计、风险分析、数据构造、自动化校验、故障注入和质量决策。恰好都是测试人的老本行，只是对象从页面和接口，变成了会规划、会调用工具、还会改变系统状态的Agent。

下一次再评测Agent，先别只问它答对了没有。打开它的Trace，检查系统终态，再问一句：如果把同一个任务交给它100次，我还敢让它自己执行吗？这可能才是Agent真正的及格线。

留言区或后台私信【Agent评测】，即可领取相关资料。