AI Agent 评估的八个维度：从最终输出到执行链路，为什么传统评测方法正在失效

原文：Machine Learning Mastery — “The Roadmap to Mastering AI Agent Evaluation” 原文作者：Bala Priya C 原文链接：machinelearningmastery.com/the-roadmap-to-mastering-ai-agent-evaluation/

一、Agent 评估正在成为一门独立的技术

Machine Learning Mastery 的这篇路线图文章，标题值得玩味：不是 “如何评测 AI Agent”，而是 “掌握 AI Agent 评估的路线图”——暗示了这是一个需要系统学习的技术领域，而不是随手就能搞定的副线任务。

这个判断本身就是一个重要的信号：

• 两年前，业界还在争论”LLM 需要什么样的评测”
• 一年前，开始有人意识到 Agent 评测和 LLM 评测不是一回事
• 现在，公认需要一套独立的方法论体系

为什么 Agent 评估需要从 LLM 评测中独立出来？根本原因在于：LLM 是生成系统，Agent 是执行系统。

这篇文章的价值在于：它把这套方法论拆成了可执行的步骤序列——从 “为什么 Agent 评估不一样” 开始，到生产监控收尾，每一层都有清晰的工程建议。

二、一个被忽视的前提：Agent 的失败点在推理层还是执行层？

文章提出了一个关键洞察：Agent 在推理层和执行层可能独立失败。

推理层做对了（正确选择工具），执行层可能出错（参数格式错误）。 执行层做对了，推理层可能选错了工具。

端到端的准确率检查会同时掩盖这两类失败。一个 “任务完成率 80%” 的数字无法告诉你：那 20% 的失败是因为规划错误、工具选择错误、参数错误，还是基础设施故障。

这是一个在传统软件测试中早已解决的问题——分层测试。但 Agent 系统的特殊之处在于，推理层和执行层是耦合的：推理层的输出直接决定执行层的输入。这让分层测试的切分变得不那么直观。

文章的建议是：用 step-level traces（步骤级轨迹日志） 来解开这个耦合——记录每个工具调用、参数、结果和后续模型决策。没有轨迹日志，生产环境出故障时只能靠猜。

这个建议在实操中遇到的最大挑战不是技术，而是成本。轨迹日志意味着每个 Agent 的执行过程都要被完整记录和存储——对于每天执行数万次任务的 Agent 来说，这会产生大量数据。要不要全量记录、保留多久、怎么压缩，都是需要权衡的工程决策。

三、代码检查 vs LLM Judge：两种评估哲学的碰撞

文章将评估方法分成两大类：

确定性评估（Code-Based Checks）

适用场景：工具调用验证、参数值检查、环境状态确认。

优势：速度快（毫秒级）、结果可复现、成本低。 劣势：脆弱——”confirmation_code”: “CONF-789” 的检查器会错过格式相同但内容不同的正确响应。

模型评估（LLM-as-a-Judge）

适用场景：输出质量、语气、忠实度、同理心——这些不能用代码精确描述的维度。

优势：灵活，能处理开放性输出。 劣势：非确定性、校准漂移、成本高、速度慢。

文章提出了三条实操建议：

1. 评分表（rubric）必须具体——”评估回答是否有帮助” 产生的是噪声，应该拆成多维度独立评分
2. 定期校准——LLM Judge 的准确性需要定期用人类专家的评分做对比验证
3. 部分得分——二值化的 pass/fail 无法反映真实情况，支持客服 Agent 在步骤 1-3 正确但步骤 4 失败的场景，比全失败的 Agent 更有价值

四、Agent 类型决定评估策略

文章按照 Agent 类型区分评估重心，这个分类非常有实操价值：

这个分类的核心逻辑是：不同的 Agent 类型有不同的失败模式，评估策略应该优先覆盖最可能发生的失败。

编码 Agent 的失败几乎总是能被编译器或测试捕获（确定性检查高效），而客服 Agent 的失败可能是语气不当，只能用 LLM Judge 去评估。不是每种 Agent 都需要昂贵的 LLM Judge，也不是每种 Agent 都能被代码检查覆盖。

五、非确定性的数学问题：pass@k 与 pass^k

这是文章中最具技术深度的一个部分。Agent 系统具有内在的非确定性——同一个任务、同一个输入、同一个 Agent，多次运行可能产生不同的工具选择和推理路径。单次运行的结果因此具有误导性。

文章用了一个简洁的数学说明：

单次成功率 75% 的 Agent，三次都成功的概率只有约 42%。

这个数字背后的含义是：如果你的 Agent 需要可靠地完成连续任务，仅靠提高单次准确率是不够的——你需要在系统层面设计容错和重试机制。

关键度量衡的取舍：

• pass@k：k 次尝试中至少一次成功——用于可以接受重试的场景
• pass^k：k 次尝试全部成功——用于每次交互都必须可靠的场景

这不是一个纯技术决策，而是产品决策。如果 Agent 是辅助性的（”帮我找资料”），pass@k 就够了——用户不介意重试。如果 Agent 是自主性的（”处理我的退款”），pass^k 才是正确的度量——用户不能接受 25% 的失败率。

这实际上解释了为什么低风险场景的 Agent 部署更为激进，而高风险场景的 Agent 几乎无法放心上线——目前的 Agent 系统在 pass^k 指标上的表现决定了它只能做”可以重试”的事情。

六、能力评估 vs 回归测试：两条进化曲线

文章区分了两种评估套件的不同目标，这是一个常被忽视但至关重要的设计原则：

能力评估（Capability Evals）

• 回答：”这个 Agent 能做什么之前不能做的事？”
• 初始通过率应该很低（任务刚刚超出当前能力）
• 当通过率达到 90%+ 时，说明该任务已不再是衡量能力的好尺度

回归套件（Regression Suites）

• 回答：”Agent 还能保持之前已有的能力吗？”
• 通过率应接近 100%
• 分数下降即信号——有什么被破坏了

逻辑演进：能力评估通过 → 任务变简单 → 提升到回归套件 → 引入更难的新任务进入能力评估。

这个循环设计隐含了一个重要的工程原则：Agent 评测不是一次性的，而是需要持续维护的。 评测套件需要随着 Agent 能力的提升而不断升级——新任务持续加入能力评估，已有任务升级到回归套件。

这与传统机器学习评测有根本不同。在监督学习中，测试集是静态的——模型能力的提升通过在固定测试集上分数的增加来体现。在 Agent 评估中，测试集本身需要是动态的，因为 Agent 的能力提升可能改写评测标准。

七、生产监控是评估的最后一块拼图

文章将评估延伸到生产环境——这是 Agent 评估区别于 LLM 评测的另一个关键点。

四个互补的信号源：

它们形成了一条完整的反馈链：离线评测抓到已知的 → 生产指标暴露未知的 → 用户反馈提示被忽略的 → 人工审查解释为什么。

但前提是轨迹日志的基础设施已经建好。 没有 step-level traces，这四个信号源之间就是断开的——无法把用户反馈的某个问题映射到具体的执行轨迹上。

八、当前的最大瓶颈

读完这篇文章，最核心的感受是：Agent 评估的理论框架已经相当完整，但工程落地还差得很远。

几个现实障碍：

1. 轨迹日志的成本——全量记录所有 Agent 执行轨迹，对于大规模生产的 Agent 来说，存储和查询开销不小。有多少团队愿意为”可评估性”付出这个基础设施成本？

2. LLM Judge 的可靠性——用 LLM 评估 LLM 存在自指问题。模型 A 评估模型 B 的输出，评估者可能喜欢模型 B 的写作风格而不自知。文章提到”定期校准”，但校准本身需要人工，成本不低。

3. 评测套件的维护成本——动态评测意味着需要有人不断设计新的能力评估任务。谁来做？多久做一次？评测套件本身的质量如何评测？

4. pass^k 指标的残酷性——即使单次准确率达到 95%，如果需要连续 5 步操作都正确，成功率只有 77%。这个数学不等式是 Agent 自主性的根本限制。

九、结论

Machine Learning Mastery 的这篇路线图标志着 AI Agent 评估正在从”经验主义”走向”工程化”。8 个步骤覆盖了从评估目标定义、分级方法、非确定性度量到生产监控的全链路。

但路线图只是地图，不是路本身。对于正在把 Agent 投入生产的团队来说，最现实的起点可能是：

1. 先建轨迹日志（没有它就什么都做不了）
2. 从代码检查开始（确定性的总是比非确定性的好）
3. 用 pass@k 过渡（在 pass^k 还做不到的时候）
4. 逐步迭代（不要试图一步到位）

Agent 评估的终极挑战不是一个技术问题，而是一个经济问题——你愿意为”知道 Agent 表现如何”付出多少基础设施和人力成本？

那篇英文原题是：The Roadmap to Mastering AI Agent Evaluation.

参考来源：

1. Machine Learning Mastery — “The Roadmap to Mastering AI Agent Evaluation”（2026-06-18）
2. Anthropic — “Demystifying evals for AI agents”