做Agent评估框架这几年我最大的感悟是这个方向看起来像是给模型打个分那么简单一旦真上手你会发现它横跨了数据工程、系统架构和评测方法论三个领域。市面上开源的框架有不少但你拿回来直接跑出来的分数往往没法解释因为评估体系不是框架自带的而是你得自己设计出来的。这篇东西不打算写成文档式的说明就想把我在某跨平台智能体项目里搭评估框架的全过程拆开聊一聊。你会看到为什么Agent评估和传统模型评测完全两回事、维度怎么定、数据怎么造、框架怎么跑、打分怎么控以及一堆跑完才发现的坑。如果你正准备给自己手上的Agent搭一套能用的评估体系或者已经在用某些开源框架但觉得结果说服不了人这篇应该能给你一些直接可参考的思路。1. Agent评估为什么这么难1.1 从模型评测到Agent评估差的不是一点点传统模型评测的逻辑是给模型一个输入模型给一个输出拿输出和标准答案比对然后算准确率。这个范式稳定高效因为输入和输出的空间都是相对可控的。但Agent完全不是这样。Agent面对的是一个开放式的目标它要自己拆解任务、调度工具、处理不确定性然后在多轮交互中逐步逼近结果。同一句指令跑十次可能会有十条完全不同的路径最后结果可能一样也可能不一样。这就导致静态比对的方式根本没法用。我在做某跨平台系统的时候就深有体会。早先我们直接拿一堆问答对去测Agent的智力结果分数特别高。但一放到真实业务场景里Agent经常在工具调用环节出错参数填错、链路上某一步卡死、遇到异常不会恢复。问题在哪在于问答对只能测模型本身的知识和推理能力完全测不到Agent与工具链协作的过程质量。所以Agent评估框架必须覆盖从指令理解、任务规划、工具执行到结果整合的整条链路。它不像模型评测那样只有一个终点对错而是要同时看终点的结果和走过的路径。这意味着评估数据的结构、评分标准的设计、运行环境的搭建全都要换一套思路。1.2 框架解决的不只是打分问题很多人听到评估框架四个字第一反应是找个现成的工具跑一通自动化评测出个分数就往汇报材料里放。这个想法会让后面的工作走很大的弯路。一个真正能用的Agent评估框架至少要承载四件事任务集管理评估样本的格式、组织、版本迭代。运行执行器把Agent“放”到可控环境里去跑记录完整轨迹。结果评判器对Agent的表现给出可解释的评分和诊断。归因与报表告诉你这个版本为什么好/为什么差差在哪里。这四个部分缺一个评估就转不起来。比如只做任务集和打分器但没有执行器你就得手工逐条跑任务效率极低有执行器但没有归因模块分数出来了也不知道下一步往哪儿改。另外要注意的是框架解决的是可重复评估的问题解决不了评估得准不准的问题。准不准取决于任务设计、标注质量和评分策略这些框架本身不提供需要你自己搭。在团队里我经常说一句话评估框架这东西20%的精力花在选型或者搭建上80%的精力要花在跑数据、修标准、调偏见上。2. 评估维度设计先想清楚要测什么2.1 任务完成度结果到底对不对评估维度里最基础的就是任务完成度也就是Agent最后到底有没有把用户的目标办成。听起来很直观实际落地时有两个大坑。第一个坑是完成的定义。每个任务必须写成可验证的结果断言。比如一个任务目标是整理一份本周项目进度报告并保存为指定格式我会把完成拆成这样几个检查点输出文件存在且文件名符合规范。内容包含所有指定项目的进度更新。每个项目的状态字段非空。文件保存路径正确。每个检查点可以设权重。最终完成度分数是所有通过检查点的加权和。为什么要这么做因为可解释性强。分数不对的时候你能立刻指出是哪个断言没通过而不是看着一个总分猜原因。第二个坑是部分成功怎么算。Agent有可能做了80%的工作最后一步环境出问题失败了。这时候给0分不合理给100分更不合理。我的做法是引入里程碑分把任务的关键节点拆成链路上的若干个里程碑Agent每到达一个里程碑就给对应比例的分。这样能区分完全没做和做了但没收尾更贴近真实质量。2.2 过程质量不看结果也要看路径结果分只告诉你终点在哪过程分告诉你Agent是怎么走到那里的。在很多生产场景里过程比结果更值得关注。我一般从三个角度评估过程质量效率解决同一个任务A版本用5轮完成B版本用15轮结果完全相同。效率维度上A就是更好。步数多往往意味着无效探索多不仅耗时还浪费模型调用成本。合规有没有做不该做的事。某Agent在处理用户请求时可能会顺手调用不该访问的敏感查询接口或者绕过用户确认直接执行写操作。这些在结果上看不出来但在过程轨迹里能明确抓到。可解释性每一步的动作和上一步的推理是否对齐。我之前遇到过一种情况Agent会连续调用同一个工具三次拿回几乎相同的结果然后在推理里写我确认一下信息。这在自动评估里很难识别但人工一眼就能看出来是冗余行为。过程质量的自动评估最实用做法是先给轨迹打标。把每一步分为有效步骤、冗余步骤、违规步骤。之后统计每类占比输出成独立指标。我通常会把无效步骤比例和违规动作次数单独列出来不混进总分因为这两个指标指向的是不同的优化方向。2.3 鲁棒性与安全性出错了怎么办Agent不可能永远在顺境里运行所以评估框架必须覆盖异常场景。鲁棒性测试我分成三类。第一是输入扰动指令换个说法、参数顺序打乱、信息里混入无关内容看Agent还能不能正确理解目标。第二是环境异常工具返回超时、返回格式异常、上游接口报错看Agent能不能识别异常并合理处理。第三是中间干扰多轮交互里用户突然改需求或纠正方向看Agent能不能更新计划。安全性的样本也很重要而且经常被忽略。我见过一个挺典型的案例某Agent查询订单时工具返回了一段看似正常、实则在末尾藏着恶意指令的内容结果Agent真照着工具输出去调用了退款接口。这种问题如果评估集里没有设计安全样本就永远测不出来。所以我会专门准备一批红线案例目标本身没问题但执行路径上会触及越权操作、敏感信息读取、或者工具输出里附带指令注入。这部分样本不需要多但必须覆盖核心风险场景。3. 评估集构建数据从哪里来3.1 先梳理任务谱系别急着攒样本好多评估集做得差不是样本质量的问题而是结构缺失。上来就攒几百条任务跑完发现样本高度集中在某类简单任务上复杂场景一个没有这种评估结果当然没参考价值。我习惯先画一个任务矩阵横轴是任务类型纵轴是复杂度级别。任务类型可以是单步查询、多步操作、需要外部协作、跨系统整合等。复杂度不只看步骤多少还要看工具调用数量、状态流转深度、决策分支多少、对记忆能力的依赖程度。综合这几个维度把每个任务样本放进去。有了矩阵你就有一张覆盖度检查表。构建评估集的过程其实就是往每个格子里填样本的过程。前期给自己定的目标是大部分格子至少要有5到10个样本重点场景要多一些。跑完第一批评估还可以根据失败集中度来反向补充某些格子的样本数量。这样评估结果才不会被某一种任务形态带偏。3.2 单个样本的构造不止是一句指令一个Agent评估样本和模型评测的一条数据结构上差别很大。我的样本格式包含三个部分任务描述也就是给Agent的目标指令。这里要注意别写成教科书式命令要尽量接近真实用户的口吻和表达习惯因为线上输入往往带有口语化、信息冗余和隐含需求。初始环境配置提供确定的初始状态。比如有哪些待处理项、哪些工具有权限、当前系统时间、数据状态。这个非常关键初始环境不固定同样的任务结果就没有可比性。参考答案与打分依据写明成功标准、关键检查点和禁止行为。这里不需要把每一步走法写死但要写清楚必须达成什么不能做什么。我自己踩过的一个坑是参考答案约束太死。早期我在参考路径里把每一步该调用什么工具都写死结果Agent绕了一条更合理的路线解决了问题却被判为失败。后来调整成参考答案只约束结果和必要的关键行为路径完全放开。通过率一下子正常了也更符合只要结果对、过程合理就算好的评估初衷。3.3 质量控制和去偏样本写完之后必须有人工审校环节。我推荐三轮审校第一轮由任务设计者自审看描述是否完整、环境配置是否自洽第二轮由业务方交叉审重点看参考答案有没有歧义、检查点是否客观第三轮用一版内测Agent实际跑一遍凡是出现模型觉得对、人觉得错或者反过来的样本都单独拿出来分析再决定是修样本还是修Agent。去偏也是个不能忽略的点。我会定期统计样本的分布比如来源分布、任务类型分布、指令长度分布。如果发现某类样式样本占比异常高就果断砍掉一部分把配额补给稀疏场景。这种调整看着土但确实能有效避免评估结果被少数几种任务模式带偏。4. 评估运行架构与打分策略4.1 执行器与Mock环境设计运行层要做的事情是让Agent在一个可控环境里反复执行任务并把执行过程完整记录下来。我常用的架构分三层任务调度器、执行器、环境适配层。任务调度器负责按配置分发样本、控制并发和超时。执行器负责把样本转化为Agent可接收的输入并驱动运行。环境适配层负责对接工具或外部依赖生产环境接真实服务评估环境接Mock。Mock环境的重要性怎么强调都不过分。评估时你不会希望Agent真的去发邮件、真的去下单、真的去改线上配置。所以每个外部依赖都要有一套模拟实现返回内容要尽量逼真包括正常的成功返回、各类错误码、偶发超时、边界数据。只有Mock够逼真你看到的Agent行为才接近线上表现。这里还要提醒一个并发问题Agent评估任务的资源消耗和普通接口压测不一样。每条任务可能跑几十轮工具调用日志量和内存消耗都不小。我之前直接把并发开到50结果工具调用日志把磁盘写满一堆任务被环境影响搞挂了。后来压到8到10个并发并且每个进程单独隔离日志目录才稳定下来。4.2 打分方式规则优先模型评判兜底混合用打分环节相当于评估框架的裁判。目前主流的方式有三类各有适用场景。规则打分适用于结果能被结构化校验的场景比如格式检查、必填字段检查、步骤次数统计。它的优点是稳定且零额外成本判定结果不会漂移。缺点是覆盖不了开放性任务。模型评判适合主观性很强的任务比如回答是否自然、方案是否合理。但它有一个大坑评分模型自带偏好。它经常会给更长、更像范文、语气更肯定的输出高分这对简洁有效的回答很不公平。我的混合策略是这样的能写规则的绝不交给模型规则覆盖不了的用模型评判但必须给评判者一套判定指南。判定指南里要明确写些什么比如只根据检查点判断不要因为回答长度加分、提取不出明确结论就零分。而且每次模型评判都要让它产出推理摘要方便之后追溯。另外评分模型不要和被测Agent同源同源模型会产生系统性偏袒或误判换个不同训练分布的模型来做裁判可信度会高很多。4.3 指标汇总与归因分析跑完一批任务框架要输出的绝不只是一个总分而是一套能指导迭代的指标体系。我习惯分成三层来呈现。总体层看任务成功率、平均步骤数、失败率类型层按任务类型和复杂度切分看哪些场景拖了后腿案例层保留失败样本的完整轨迹和偏离点标记。归因分析是价值最大的部分。我通常把失败原因归成几类意图理解错误、工具参数错误、路径规划冗余、环境异常处理失败、样本本身有歧义。每类失败打标签迭代时优先处理占比最高的前两类。有一个容易踩的坑修复某类失败后整体成功率可能不变因为连带变化让另一类失败增多了。所以每次迭代后除了看总体分数更要看失败类别的分布变动。只有类别分布是稳定向好的才算一次有效迭代。5. 常见问题与排查实录5.1 Agent跑飞了无限循环与重复调用最常见的运行异常是Agent在某个步骤上无限循环。表现有三种同一工具连续调用多次但参数几乎一样推理内容越来越长但动作不变或者干脆死循环直到超时。排查思路一般是先看时间戳和工具调用序列找到循环起点。然后看起点附近的推理内容判断它到底是在合理重试还是无效确认。如果确认是重复调用问题要在系统层加保护比如相同参数的工具调用连续出现三次就强制中断并提示Agent更换策略。我在框架里默认加了一条规则工具返回异常错误码时Agent最多重试两次超过两次必须换方案否则直接判定为无效探索。这条规则在实测里把无效调用比例从30%降到了12%左右效果很直接。5.2 评估结果波动大同一版Agent同一条评估集两次结果差很多。这个问题往往出在采样参数上。温度调高、top_p调大输出就会带随机性Agent的路径自然跟着变。要控制波动我推荐两个方向配合用。第一评估模式下把采样温度压到接近0尽量让输出确定。第二关键样本要多次运行取统计结果至少跑3到5次。报告里同时展示首次尝试成功率和多次运行通过率这样能区分Agent是真的不稳定还是样本难度太高导致随机性被放大。还有一种波动来自环境时序。比如Mock服务在高并发下偶尔超时会直接污染Agent成绩。这种情况要在任务调度器里加环境异常重跑机制因环境原因失败的样本先重跑确认再决定是污染还是Agent本身的问题。5.3 评分模型偏见与评分漂移评分模型不是客观的它有偏好。我调了很多轮评判提示词发现一个很典型的偏见只要被测Agent的输出比评分模型预期的更简洁就给低分理由是没有充分展开。但人工看那个回答干净利落该讲的都讲清楚了。处理方式有三步。第一在评判提示词里明确写简洁且完整应当获得满分之类的目标优先声明把评分标准锁定在被测任务本身。第二定期抽检评分模型的满分和零分样本人工复核一遍算一致率。第三每次更换评分模型或修改评判提示词都先在固定样本集上跑一次评分回归确保新旧标准没有漂移过大。条件允许的话用两个异源评分模型交叉打分或者同一个模型用不同提示词各评一次取一致性高的结果。如果分歧大这个样本就进人工仲裁池不要硬出一个分数。6. 我在实操里的一些延续想法评估框架这件事做到后面你会意识到它不是一次性的工程交付而是一条需要长期维护的基础设施。我的习惯是每个版本只要有prompt调整、工具配置改动或选型变更就立刻在同一套评估集上跑回归。跑完整套任务确实要一两个小时但换来的是一旦效果下降就能当天发现而不是上线之后被用户投诉再排查时间成本完全不是一个量级。评估集的持续维护也很关键。我每周会从真实日志里挑几个典型任务脱敏后补充进评估集。半年下来评估集比最初翻了一倍而且越来越贴近真实场景。这个动作比调任何框架参数都有价值。数据是评估的灵魂这句话在Agent评估里体现得尤为明显。还有一个细节值得反复强调评估报告必须保留原始日志。我对每个样本都存储完整输入输出、工具调用、推理轨迹、评分明细统一归档。很多问题当时看不出来是过了很久翻旧日志才定位到根因的。没有可追溯的日志任何评估结论都难以立足这个底线不能丢。Agent评估是个又脏又累的活但它值得做。希望这些经验能帮你少踩几个坑。