Agent评测

阅读美团技术博客：

Agent评测是什么

为什么要评测， 就是说明Agent好不好，好在哪，哪里不足，从而为下一轮迭代指明方向。

Agent评测不能只停留在离线打榜，必须服务于真实业务中的研发、上线、回归、优化和规模化落地。

Agent研发公式：观测 + 评测 = 持续迭代

评测方法随着AI形态变化而变化，大致经历了三个阶段：

阶段	评测对象	核心问题	典型方法
机器学习模型评测	单模型	预测的准不准	准确率、召回率、AUC、RMSE等单点指标
大模型评测	基座模型能力	能力强不强	多维Benchmark，人评，机评
Agent评测	任务系统	任务能够完成	全链路观测、分层指标、过程评测、自动化回归、多维Benchmark、人评、机评

Agent评测的是：当模型被放进一个真实系统里，和Prompt, Skill, 工具链， 记忆，状态管理，业务流程耦合在一起后，能不能稳定交付好的结果。这就意味着Agent评测对象是模型 + 系统 + 工具 + 流程的复杂系统，评测不只是看结果，还要看行为和过程，因为可能存在两个Agent都得到最终一样的结果，但是行为过程不一样

因此Agent评测至少需要覆盖四层内容：

• 结果层
• 过程层：任务是否合理，步骤是否稳定
• 效率层：耗时，Token，工具调用次数是否可接受
• 风险层：是否越权，是否误操作，是否存在安全隐患

到现在的多功能长程Agent，Agent评测正从答案评测走向行为评测。

Agent的一次执行通常包含如下链路：

这样一个链路，如果只看到用户输入和结果输出，看不到中间过程，就几乎无法判断问题根因，正是基于“我想看Case却发现没打日志”这个朴素的问题，工业界发展出了Trace系统，将黑盒内部的逻辑推理过程进行全路径的披露，将所有影响模型输出的输入信息都记录下来。

所以Agentt评测本身既要关注结果Response也要关注过程

评测的核心方法论

评测的核心不是堆指标而是搭桥，这是因为模型能力指标与业务结果指标不能直接映射，存在差别，因此中间必须有一层面向任务系统的桥梁指标。因此提出分层思路，将这些层次串起来，才能真正回答为什么业务指标变差，以及模型能力提升为什么没带来业务收益。

Agent核心目标就是稳定交付好的结果。行业内Agent评测大量借鉴了大模型评测的方法论，总体上可以拆成客观评测和主观评测。

客观评测覆盖高频、结构化、可规则化的部分；
主观评测覆盖开放性、高价值、复杂业务场景；
用主观评测校准客观评测和AI评测，再把规模化部分交给自动化系统；

长程Agent和短程Agent区别在于如何处理时间跨度带来的复杂性。

长程Agent评测基建至少应该具备哪些能力，评测基础设施应至少包含：

• 全链路回放：复现一次任务从输入到结果的全过程
• Case管理：统一维护任务样本，上下文，约束和Rubric
• 执行沙箱
• AI评测引擎
• 报告与归因
• 回归机制
• 准入准出门禁

Agent评测白皮书系列01-Agent评测全览

要有这样的感知：搭建一个agent正在变得越来越容易

• 基座模型的能力持续进化
• agent框架的功能持续丰富：框架和协议层把这些抽象成标准组件

了解agent消失原因共性：

• 停在demo：没有真实流量，用户的问法、数据的脏乱、场景的边界远超预期，团队疲于打补丁，最后不了了之
• 卡在扩量：小范围使用还行，放量问题集中暴露
• 说不清业务价值

共同点就是团队缺少一套可靠的判断机制。做决策靠的是感觉和个别案例，感觉在复杂系统面前不可靠。

意识到评测认知的稀缺。没有评测，怎么能把agent做好呢。并且有限的评测认知面对发散的场景，同样力不从心。做好一个chatBot的经验，并不能无缝泛化到做一个长程agent身上。

本系列就是讲清楚先做什么后做什么，每一步的产出物长什么样，做到什么程度算达标，遇到常见的坑怎么处理。

评测是一门实践科学，需要结合业务特点做调整

完整的评测体系可以概括为四个模块、三种能力、两条Loop、一套资产。

一、完整的评测体系是什么样子

评测的核心：Agent好不好，到底哪里好，哪里不好。

之前提到评测是一套精密量具，这个类比其实包含两个隐喻：

• 量具要准（方差小才置信）：同一个样本，不同的人，不同的时间、人和机器，量出来的结果要一致
• 量具需要定期校准：业务扩量后用户画像变了，agent能力边界扩了、业务目标有变化了，原有的评测集和rubric就会逐渐失去代表性，对应评测体系自身的迭代能力

理想的评测体系是一套持续运转的系统，由两条loop构成，两者共享同一批线上真实样本，通过case挖掘与归因这个枢纽相互咬合。

评测迭代的过程中把团队对业务质量的隐性认知，转化为可量化、可复用、可传递、可自动执行的显性资产

将评测体系按模块拆分，得到四个模块：第四个模块是前三者的地基：

上述划分可以按照自己团队的组织方式重新切分，不漏掉任何一项职责即可。

这里举例一个贯穿全文的例子：商家经营分析Agent（对应了内部商家Claw类场景）

上述场景特点是典型的长程Agent：多步骤、多Skill调用、有中间产物、与环境频繁交互、没有唯一正确答案。

二、离线评测：变更的门控

离线评测的核心在于agent版本变更后的回测，可以作为上线前的门控，依赖固定评测集（固定样本和固定评测标准），尽可能贴近生产的固定执行环境

当agent harness的任何一个环节发生变化，例如模型升级、prompt调整、知识库更新、skill新增或下线都可以通过离线评测验证效果，避免不成熟的变更导致agent能力劣化。

注意是固定评测，能够控制变量对比。

评测集：广义评测集可由问题、参考答案、评价标准三元组构成，问题–参考答案称为评测样本

理解这样的趋势：agent评测从答案评测走向行为评测。评测要看agent走过的路径是否符合预期，以及最终环境状态是否达成目标。

在Anthropic《Demystifying evals for AI agent》对于长程Agent评测任务的定义是：具有明确的输入和成功标准的单个测试。

评测集的每一行三元组都可以看作一个Task：Task要有固定输入，例如Query / answer，或者prompt / expected behavior，评价部分由Metircs , Rubric构成，Rubric是最小粒度的评测标准

二元化Rubric思路就是，把这个ppt做的好不好这种模糊判断，下钻成一组可以回答是否的具体检查项，从而将模糊的问题尽可能量化，消除分歧。如下评测示例：

那到底如何判断agent是否达到标准了呢，可以参考三种方式：

• 程序规则判定
  • 是否产出.pptx文件，脚本检查工作目录有没有.pptx，甚至可用python-pptx打开验证能正常解析、页数 > 0
  • ppt中的投放金额是否与源数据一致
  • 耗时是否在规定时间内
  • 是否有未经确认的写操作或数据外发

这一类叫做code-based / programmatic evaluation，能覆盖的尽量用代码，别交给大模型

• LLM-as-Judge：适合主观、语义类难以写规则的
  • 是否包含同比或环比分析，
  • 幻觉检测

用大模型判断要注意，给裁判明确的评分标准和输出格式，提供源数据和待评产物全文，尽量成对比较而非绝对打分，抽样人工复核一致性，换模型或prompt后重新校准。

• 人工评估
  • 用于校准前两者，以及处理争议样本。通常不需要全量，抽10% - 20%复核