评估Agent性能：从打分到测绘

我们评估AI Agent的方式，本质上还停留在给小学生打分的阶段：一个固定的benchmark，跑出一个分数，然后宣布“通过了”。但一个及格分是最没用的信息，它完全掩盖了Agent的能力边界在哪里，离失败有多近，以及下一步该往哪个方向优化。对于数据Agent来说，这个问题尤其致命。当用户用模糊的自然语言提问，Agent需要从成千上万的表中找到正确的数据集时，一个“通过”的分数毫无意义。真正有价值的问题是：问题可以模糊到什么程度，Agent才会彻底崩溃？ 传统的pass/fail评估完全无法回答这个问题，它只告诉你地面是平的，却看不到悬崖在哪里。我们需要的是Agent能力的“地图”，而不是一张“成绩单”。

Google Data Cloud团队提出的解法，核心思路是把评估从“定性”变成“定量”。他们构建了一个叫 Discovery Bench 的元基准框架，核心机制是“基于信息论的惊异度（surprisal）”。简单说，一个查询词如果很罕见、指向性极强（比如卫星数据里的“TLE”），它的信息量就大，惊异度就高。反过来，去掉这个词，查询就变得模糊，惊异度就低。他们利用这个原理，对同一个问题生成“高模糊度”、“中模糊度”、“低模糊度”三个版本，然后看Agent在不同模糊度下的表现曲线。这就像给Agent做了一次“视力检查”，不是问它“看得见吗？”，而是问“视力表上第几行开始看不清？”。这个曲线能暴露出传统评估完全看不到的东西：比如一个在标准测试中得满分的Agent，一旦问题稍微模糊一点，性能就断崖式下跌（F1从1.0直接掉到0.0）。传统评估告诉你“地面是平的”，而这张地图告诉你“这里有个悬崖”。

这个思路的启发是巨大的。它把Agent评估从“考试”变成了“测绘”。核心价值在于，它提供了一种可工程化的方法论，去量化Agent能力的“脆弱边界”。对于任何正在构建AI Agent的团队，这篇文章给出了一个非常具体的行动指南：不要只盯着一个分数，要去“评估你的评估”。具体来说，就是去读你的ground truth数据，看看它是不是本身就是错的；把难度当成一个可测量的量，而不是一个标签，去扫描你的Agent在不同模糊度下的表现曲线，找到那个“悬崖”和“最佳甜蜜点”。这不仅仅是评估方法的改进，它直接改变了我们优化Agent的方式——从盲目地堆数据、调参数，变成了有方向地针对具体的失败模式（比如时间分片表、上下文爆炸）进行定点突破。文章最后那个“评估你的评估”的递归警告尤其值得深思：当LLM本身被用来生成评估用例时，我们如何确保这把尺子本身是准的？他们发现，用纯LLM猜测和用TF-IDF惊异度生成的评估结果差异巨大，这提醒我们，评估工具本身也是一个需要被审视的工件。对于任何认真做Agent的团队来说，这篇文章不是一篇可选的阅读，而是一份必须执行的行动清单。