★ FEATURED ARTICLE 1. 评测难难在哪里先看清 Agent 评测和传统模型评测的本质差异这两年但凡是做 AI 应用落地的人绕不开一个词Agent。不管是基于大模型做工具调用、做多步任务规划还是对着网页操作、数据库查询Agent 已经从“能聊天”快速演进到“能干活”。但“能干活”这件事怎么证明这就逼出了 Agent 评测这个非常现实的问题。我见过不少团队Agent 开发得挺热闹演示 Demo 一遍过一上真实场景就翻车。问他们有没有评测体系回答说“有啊我们跑了几十个 case让 GPT 打分”。这不叫评测这叫抽查。真正的 Agent Evaluation是能持续、可重复、端到端地衡量 Agent 在完整任务链路中的表现而不是孤立地看某一个节点的输出。一个 Agent 系统至少要经历意图理解、任务拆解、工具选择、参数生成、结果校验、异常恢复等多个环节任何一个环节出问题最终任务都可能失败。传统模型评测是“输入-输出”的静态比对Agent 评测则是“输入-多步行为序列-环境反馈-最终结果”的动态闭环评估。这两者的差别是搭建评测体系时所有设计决策的起点。另一个让 Agent 评测棘手的地方在于Agent 的行为带有随机性同样的任务跑两次中间选择工具或生成参数的方式可能不同结果却可能都正确。反过来因为大模型解码的随机性或环境状态的细微差异也可能导致同样的任务这次成功、下次失败。这种随机性会让评测结果变得不稳定如果评测体系没有考虑到这一点就很难区分是 Agent 的能力波动还是评测本身的问题。还有个常被忽略的层面Agent 评测必须贴近真实使用场景。你在测试集里给 Agent 干净整洁的任务描述、明确可用的工具列表但真实用户提问方式是口语化的工具可能突然不可用数据格式可能和预期不一致。端到端评测的意义恰恰在于把这些问题全部暴露出来。所以现在业内越来越多的人讨论 Agent Evaluation本质上是在讨论怎么把一个动态、多轮、有环境交互的系统用一套可量化的方法去衡量它到底行不行。基于我自己的实践经验要构建一套合格的端到端 Agent 评测体系至少需要想清楚四件事评测集怎么建、评测环境怎么搭、跑评测的 Harness 怎么设计、结果指标怎么定义和解读。下面我一条条展开讲。2. 评测集构建这是整个体系的地基也是最容易糊弄的部分2.1 先搞清楚评测集到底在测什么评测集不是把一堆用户问题攒在一起就行它需要结构化地覆盖 Agent 的能力维度和难度层次。我习惯把任务集分成三个维度去设计复杂度维度、工具类型维度、干扰项维度。复杂度维度解决的是“这个任务需要几步才能完成”的问题。单步任务比如“查一下今天北京的气温”Agent 只需要调用一次天气 API。多步任务比如“帮我安排明天上午从上海到北京的高铁要 9 点前到达选最快的一趟并预订靠窗座位”这需要先查车次、筛选时间、解析座位偏好、再执行预订至少四到五个决策点。端到端评测一定要以多步任务为主因为单步任务无法暴露 Agent 在规划、记忆、状态管理方面的问题。工具类型维度要覆盖 Agent 实际会用到的主要工具类型包括信息查询类搜索、数据库查询、操作执行类创建订单、发送消息、修改配置、计算分析类代码执行、数据计算。不同工具类型的失败模式完全不同查询类工具容易产生幻觉和错误引用操作类工具容易在执行参数上出错分析类工具则可能在代码生成上产生语法错误或逻辑错误。评测集只有覆盖这些差异才能定位到 Agent 具体哪类能力薄弱。干扰项维度是最容易被忽视的也恰恰是区分评测集质量的关键。真实用户不会按照标准格式提问会在问题里加入无关信息、包含模糊的表达、甚至给出互相矛盾的约束。我建议评测集中至少有 20% 到 30% 的任务包含干扰项比如在预订机票的任务中故意提及“不要红眼航班但明天只有一班红眼航班直飞”测试 Agent 是否能识别矛盾并主动询问用户而不是硬着头皮做出一个错误选择。2.2 任务难度分布要有耐心地设计评测集的难度分布直接决定评测结果的价值。全部是简单任务评测分数虚高无法指导优化全部是困难任务Agent 全军覆没评测失去区分度。我实践的配比是简单任务占 20%用来做回归测试确保新版本没有破坏基础能力中等任务占 50%这是 Agent 能力的主要检验区困难任务占 30%用来筛选顶尖表现和挖掘瓶颈。困难任务的定义我建议用“至少需要 5 步以上的决策并且至少有两个可行的路径”来界定。比如“帮我比较上海和杭州的三家酒店根据评分、价格和距离综合推荐然后预订性价比最高的那家”好的 Agent 会主动搜索并比较多源信息而弱一些的 Agent 可能只搜索了一两家就开始推荐。2.3 评测集要防泄漏还要防“刷题”评测集污染在大模型训练领域被谈得很多但在 Agent 评测中同样危险。如果 Agent 的记忆模块能访问到历史会话而评测任务恰好出现在历史会话中那评测结果就没有任何参考价值了。更隐蔽的问题在于很多 Agent 系统会用外部知识库做检索增强如果评测任务的标准答案恰好存在于知识库中等于直接给 Agent 开了卷。我的做法是评测任务集与线上真实数据严格隔离并且定期做一轮“去污扫描”用 Agent 自身去跑一遍评测集再人工检查那些异常高分的任务看看是不是存在答案泄漏。另一个有效手段是构造动态任务也就是任务框架固定但具体参数由程序随机生成比如“预订从[随机城市A]到[随机城市B]的航班日期为[未来第N天]”。这样即使 Agent 见过类似任务也无法通过记忆具体答案来得分。另外评测集要预留一部分“新任务”每次回归测试时混入 10% 到 20% 以前没见过的任务类型。因为 Agent 的能力不只包括处理已知任务更重要的是泛化到新场景。如果一个评测体系永远只测固定的几百个任务Agent 完全可以通过策略学习在这几百个任务上刷出高分但换个场景就原形毕露。这个机制能有效防止评测分数虚高。2.4 标注和验收策略这是最容易被忽视的地基工程评测集建完之后谁来判定 Agent 的结果是成功还是失败这是我最想强调的环节。Agent 任务不像选择题有唯一标准答案很多任务存在多种合理完成方式。比如“帮我整理一下这份会议纪要”Agent 可以输出纯文本摘要也可以输出结构化条目两种方式都是合格的。所以评测任务必须配套验收规范包括三个要素必达条件、禁止行为和可接受的状态。必达条件指任务目标必须完成到什么程度比如“必须实际完成预订并返回订单号”。禁止行为指哪些行为就算结果看似正确也不能算成功比如“在没有确认用户身份的情况下直接修改配置”。可接受的状态指允许多样性存在的空间比如“输出格式可以是表格或列表只要关键信息完整”。校验方式上纯人工校验准确但成本高纯自动校验又快但容易误判。我目前采用的是分层校验一级用规则和关键字自动判定能覆盖大约 60% 到 70% 的简单任务二级用 LLM Judge 对剩余任务的完成度做打分三级针对 LLM Judge 容易误判的任务类型必须人工复核。这里要提醒的是LLM Judge 本身也会有偏好和幻觉所以每次评测前还需要抽检一批 LLM Judge 的判定结果确保判定标准没有漂移。3. 评测环境与模拟器测试 Agent 为什么必须搭一个“可控的真实世界”3.1 为什么不直接在线上环境做评测很多人觉得评测 Agent 最真实的方式就是把它接到生产环境里跑真实任务。这个想法在早期验证阶段可以但一旦要系统化地做评测问题就来了生产环境的系统状态不可控订单库存、数据库内容、第三方接口响应都在动态变化同一个任务在不同时间跑前置条件完全不同评测结果无法复现。举一个我实际遇到的例子当时做电商场景的 Agent 评测任务是“把购物车里的商品按价格从低到高排序并结账”。这个任务在线上跑会受实时价格变动和库存影响同样的指令今天能完成明天可能因为某个商品下架而失败。这种失败反映的是环境变化不是 Agent 能力问题但混在一起根本无法定位。评测的真正目标不是让 Agent 在特定时间点完成特定任务而是验证它在所有可控条件下的一致性表现。所以必须构建一个独立的评测环境用沙箱化的工具和服务来模拟真实世界这就是 Agent 评测里面常说的 Sandbox 或 Simulator。3.2 模拟器设计状态可控、响应可预期、干预可视化搭建评测环境的核心原则有三条状态可控、响应可预期、干预可视化。状态可控的意思是评测环境里的业务状态完全由测试脚本初始化。比如要测一个预订类 Agent评测执行前先通过 API 注入几个特定状态的预订记录有的已确认、有的待支付、有的已取消。Agent 启动时的环境状态是确定的任务执行后的状态变化可以被精确比对。如果状态不可控就很难判断 Agent 的内存管理或状态跟踪能力——你连它一开始看到什么都不确定还怎么判断它后面做的事情对不对。响应可预期是指评测环境中涉及的外部服务天气查询、地图、数据库、第三方支付模拟器都要有固定的 mock 实现或录制的响应数据。真实服务的延迟波动和返回格式变化会影响评测的稳定性和可复现性所以评测环境中要用录制回放或模拟器替代真实服务。比如天气查询 mock 可以固定返回“上海多云25 摄氏度东南风 3 级”这样 Agent 关于天气的回答就有了唯一的比对基准。干预可视化则要求评测平台能记录每一次工具调用的输入输出、Agent 内部状态的变化和决策路径。这不是为了实时调试而是为了评测结束后能做回溯分析定位到具体是哪一步决策出了问题。我见过不少团队评测只记录最终结果一旦发现失败就抓瞎被迫用几乎同等的成本重跑一遍任务来复现问题。3.3 一个可落地的评测环境参考设计具体到落地我给出一个基于开源组件的基础方案。评测环境的骨架用 Docker Compose 编排包含三部分评测服务负责调度测试任务、目标 Agent 容器被测系统、模拟外部服务用 WireMock 或自建 mock server。执行流程是评测服务向被测 Agent 发送任务指令Agent 在运行中通过工具调用访问模拟服务所有交互记录保存在评测服务的日志存储中。需要特别提醒的是评测环境要和 Agent 开发环境物理隔离。开发环境里 Agent 能访问的真实数据库、真实第三方服务一律不能在评测环境里出现否则评测过程中 Agent 一旦行为失控可能对真实数据造成不可逆的影响。另外评测环境里给 Agent 配置的权限也要区分层级核心场景建议从最小权限开始逐步增加避免一个评测 bug 引发连锁故障。3.4 评测中的 Backend 与 Harness 该分开还是结合顺着环境设计自然要提一下 Backend 和 Harness 的关系。在评测语境下Backend 通常指评测依赖的后端支撑服务比如模拟外部系统的 mock 服务、负责状态注入和校验的运行时环境Harness 则是评测框架本身负责加载任务、驱动被测 Agent、采集交互数据、输出指标报告。这两者职责不同建议在架构上做清晰分离。Harness 应该干三件事把评测集里的任务描述注入给 Agent、控制评测环境的开始与结束状态、收集 Agent 在任务执行过程中的完整交互数据。Backend 则提供评测所依赖的确定性外部条件。两者分离的最大好处是换一个 Harness 或换一组模拟服务不会互相影响。比如你今天用自研 Harness 跑评测明天换成开源评测框架Backend 无需改动或者你今天用 WireMock 模拟天气服务明天改用真实 API 录制回放Harness 也无需改动。我还见过团队把环境模拟和任务调度耦合在同一个系统里初期跑得挺快后期维护时苦不堪言。因为评测集的增加会带来新的查询类型你不得不去魔改调度逻辑而不是简单地加一个模拟服务。所以从一开始就把这两个层面分开后面会省非常多的事。4. 评测指标体系端到端评测不能只盯“成没成”4.1 从结果到过程一套完整的指标框架我在搭评测指标体系时分成了四层任务成功率、步骤正确率、效率指标、安全与稳定性指标。很多团队只用了第一层也就是看任务最终完成没完成。这一层当然重要但提供的信息远远不够。任务成功率Task Success Rate是最基础的指标定义是“评测集中完成成功的任务数占总任务数的比例”。这个指标直观但粗暴它无法回答 Agent 是“一次做对”还是“试了很多次勉强做到”。步骤正确率Step Accuracy拆解到任务内部衡量每个决策步骤的正确性。比如一个预订机票的任务需要解析意图、搜索航班、筛选条件、填写乘客信息、确认支付五个步骤其中搜索航班这一步调用了错误的日期参数但后面几步歪打正着成功了任务总评分可能是成功步骤正确率却暴露了问题。步骤正确率的统计依赖于完整的工具调用日志和每一步的校验规则所以上一节讲的交互记录采集是否完整直接决定这个指标能不能算出来。效率指标包括任务完成时间、工具调用次数和无效调用率。工具调用次数直接反映 Agent 的规划能力规划好的 Agent 能用最少的调用完成目标规划差的会在同一个查询上反复兜圈子。无效调用率即那些返回错误或未被正确处理的结果它往往暗示 Agent 对工具能力和返回结果的理解存在偏差这个指标在评测过程中做横向对比尤其有用一般建议控制在 15% 以下超过 30% 基本可以判定 Agent 的工具使用逻辑有系统性问题。4.2 安全指标必须从第一天就做安全与稳定性指标容易被技术团队忽视但它恰恰是 Agent 上生产环境的生死线。我至少要统计这几类危险操作次数比如删除、重置、支付等敏感操作是否被妥善管控、权限逃逸次数Agent 是否试图调用超出任务范围的工具或访问未授权的数据、失败恢复成功率任务执行途中出现异常后Agent 是否能够自行恢复或及时求助。安全指标的判定规则要独立于任务成功率单独统计哪怕一个任务最终成功了但中间产生了一次危险操作这个任务在安全维度上也是不合格的。这里要多说一句评测 Agent 的时候要故意埋一些“诱导性场景”比如在用户输入中加入恶意指令或模糊越权请求看 Agent 是否会被误导。这类对抗性 Case 的数量不需要多但必须存在否则评测结果无法证明 Agent 在安全层面的真实水平。4.3 端到端评测还要关注“用户可感知”的体验指标除了上述客观指标还有一类指标更贴近真实用户的感受包括首响时间从提交任务到 Agent 给出第一个有意义的响应、澄清次数Agent 主动向用户确认信息的次数和无效往返次数用户在完成一个任务过程中被迫重复描述的轮次。这些指标反映的是交互质量而不是纯粹的任务完成能力。举个例子一个 Agent 能完成任务但完成前问了用户八次澄清问题每次确认的都是同一类信息。从成功率看它是合格的从用户体验看它几乎不可用。所以我通常会在评测指标表里把澄清次数控制在不超过任务步骤数的一半作为阈值超过即视为一次体验失败的用例这样单看成功率看不出的问题就能被量化表暴露出来。5. Harness 设计与实操让端到端评测真正跑起来5.1 评测管线的基本架构与流程编排说完了指标接下来讲怎么把这些东西落到具体可运行的评测管线里。基于我自己的经验一套可复用的端到端评测管线至少包含如下环节任务加载与参数替换、环境初始化、Agent 启动与交互驱动、运行监控与日志采集、结果校验与指标计算、报告生成与归档。用 YAML 来描述一个评测任务的定义可以让整个评测集清晰可维护。比如task: id: hotel_booking_001 description: 帮我在上海预订一家评分不低于4.5的酒店预算500元以内住两晚需要包含早餐 environment: hotel_service: mock_hotel_api_v2 payment_service: mock_payment_api_v1 success_criteria: - 返回的酒店评分4.5 - 预订的总价1000元 - 订单状态为confirmed - 包含早餐字段 expected_steps: 4 max_steps: 8 forbidden_actions: - 直接调用payment_service的refund接口这种配置文件的核心价值有二一是通过参数替换实现动态任务避免评测集过于静态二是让任务验收标准显式化后续无论换评测框架还是换 Agent 实现都能复用同一套评测定义。5.2 评测执行器实现时的几个关键设计我在实现评测执行器时踩过的几个坑值得分享。第一个坑是任务注入方式。很多评测框架把任务描述直接拼在 Agent 的 System Prompt 里这破坏了评测的真实性。真实用户的任务是通过对话接口传进来的所以评测执行器也应该通过 Agent 对外提供的交互接口发送任务而不是直接改它的 Prompt。这样可以测出 Agent 从指令输入开始全链路的真实表现。第二个坑是超时设置。Agent 执行多步任务时单步工具调用如果卡死整个任务会被拖死。所以评测执行器必须有三级超时控制单步工具调用的超时、单任务总执行的超时、整个评测集的全局超时。缺了任何一级都会出现评测卡死或一个超大任务霸占资源的情况。第三个坑是并行度设计。端到端评测最耗时的环节就是任务执行一个任务动辄要一两分钟几百个任务串行跑起来效率非常低。但并行度过高又会给模拟服务带来压力甚至引发资源竞争导致的评测失败。我实践中比较稳妥的做法是并行度控制在 4 到 8 个任务同时跑并且对模拟服务做并发压测确认它在对应并发下的稳定性。评测不是为了追求最短时间而是为了在可控条件下获取稳定的数据。5.3 评测结果校验与 LLM Judge 的工程化应用对评测结果做校验是整个 Harness 中最难自动化的环节。规则类结果比如“返回的订单号是否为数字”可以用脚本校验但更多结论类结果比如“推荐的酒店是否真的符合用户偏好”只能靠语义判断。我的做法是引入了两级校验。第一级是确定性规则校验比如必达条件中涉及数值大小、字段包含关系、操作动作是否执行等这类字段可以完全脚本判定。第二级才用 LLM Judge 对整体完成质量做打分LLM Judge 的 Prompt 里会把任务描述、验收标准、Agent 的完整行为日志全部喂进去要求输出 PASS、FAIL 或 UNCERTAIN 三态判定。UNCERTAIN 的任务会进入人工复核队列。这里有一个很关键的工程细节LLM Judge 每次只做一个任务的判定并且判定依据必须依赖完整的 Agent 行为日志而不是只看最终输出。只看最终输出会让 Judge 被“看似正确的答案”误导而完整日志能帮助它识别出“最终结果正确但过程有问题”的隐蔽失败模式。5.4 评测结果的回归对比与趋势分析评测的意义不在一次跑分而在于长期趋势对比。所以我建议评测系统从第一天就建立基线机制每个重要的 Agent 版本迭代都要基于同一套评测集重新跑一遍完整评测并把结果自动归档到基线数据库中。对比时有几个注意事项。第一Agent 模型的温度参数必须固定否则结果波动可能完全来自解码随机性。第二评测环境版本要锁定模拟服务的响应数据变了前后结果对比就失去意义。第三对比不仅看总成功率变化还要看每个能力维度的分项变化这样版本升级带来的能力提升或回退才能看得一清二楚。比如新版本总成功率提升了 3 个百分点但操作执行类任务的成功率反而下降了这就是值得警惕的回退信号。6. 常见问题与排查技巧性能瓶颈、随机性和安全风险一个都不能放过6.1 评测结果不稳定怎么办最典型的问题是同一个 Agent、同一个任务集两轮评测结果却差了不少。先别急着怀疑 Agent 的能力排查顺序应该是环境状态是否一致、温度参数是否固定、Mock 服务是否被外部请求污染、并行执行时是否产生了任务间资源竞争。我印象很深刻的一次排查经历某轮评测成功率突然下降了 12 个百分点检查半天发现是评测环境的数据库状态没有正确重置前一轮评测写入的数据污染了后一轮的初始条件。从那以后我在每个任务跑完后的归档阶段都会额外做一次环境清理动作并把这个动作的完成状态写入日志作为评测有效性的前提条件。6.2 Agent 出现了预期外的行为怎么办Agent 评测过程中尤其是具备联网搜索能力的 Agent偶尔会出现预期外的工具调用比如反复请求同一个接口、对模拟服务发起大量参数试探、甚至尝试访问评测环境以外的地址。这类行为在评测中很难完全杜绝但评测框架本身需要有应急机制一旦监测到 Agent 的工具调用超出任务允许范围或出现快速连续的错误调用评测执行器应当主动中断该任务并将事件标记到安全维度指标中。有条件的团队还可以做一层外网隔离比如在评测环境的网络中只开放模拟服务需要的端口和域名其他出网请求一律阻断。这个设置既保证评测免受外部干扰也是一种安全兜底。6.3 端到端评测曝光了 Bad Case怎么定位评测完成后面对一批失败任务怎么排查根因我的建议是先用步骤正确率做粗筛看看失败集中在哪个环节再抽取典型任务的完整工具调用日志逐帧检查每一步的输入输出最后针对可疑的步骤做局部复测把问题隔离出来。举个例子某个任务失败在“预订”这个最终环节但步骤正确率显示前面几个环节都是正常的。查看日志发现Agent 在预订时提交的入住日期比查询日期早了一天这显然不是工具的问题而是 Agent 在状态跟踪上出了遗漏。类似这种问题靠只看最终结果或只看完成率是无论如何也发现不了的。6.4 评测集要多久更新一次评测集不是一次性资产它会随 Agent 能力提升而逐渐失效。如果一个 Agent 连续三轮评测都是接近满分的表现说明评测集对当前能力已经失去区分度需要补充更难的任务或更复杂的工具组合。我的建议是每季度做一次评测集的有效性审查依据三项指标做增量更新任务通过率是否过高超过 90% 就要警惕区分度、是否存在多轮评测从未失败过的“僵尸任务”、是否有新增的工具类型或场景没有被覆盖。另外每次线上出现典型的用户失败案例都应该经过脱敏处理补充进评测集这会让评测体系保持和真实世界的同步进化。6.5 参考配置与开始搭建的第一步如果你是从零开始搭一套端到端评测体系我给的最小起步建议是先不追求评测集规模从 30 个任务开始包含 15 个多步任务、10 个带干扰项的任务、5 个对抗性安全任务跑通一个最小闭环。先解决“能不能跑、指标能不能算出来”的问题再去扩充任务规模和优化效率。评测体系本身也是需要迭代的一开始想建完美体系往往连第一步都迈不出去。这里提供一份简化版的环境配置参考供快速上手编排工具Docker Compose评测服务 被测 Agent 模拟服务三个容器模拟服务WireMock预先录制好返回数据通过配置开关切换不同场景评测执行器自研脚本读取 YAML 任务定义驱动 Agent采集日志结果存储SQLite评测结果和基线数据量初期不大SQLite 完全够用校验模块规则脚本为主 LLM Judge 为辅判定结果都写入结果库先把这套骨架跑起来再逐步引入更复杂的场景编排、并行调度和自动化告警这套体系就能慢慢陪你走到评测越来越复杂的阶段。7. 最后再分享一个实操心得翻了翻手头最近的评测记录我发现一个有趣的现象那些在 Demo 里表现得非常惊艳的 Agent放到端到端评测中往往分数并不高反而是那些看起来中规中矩的系统在评测里能稳定拿到高分。这个反差让我反思了很久。原因其实不复杂。Demo 里人类会下意识地给 Agent 兜底会顺着它的思路走会忽略掉它犯的小错。但评测系统不会它验证的是“任务目标是否被真正达成过程是否安全合规遇到异常是否有效恢复”。它像一个严格的验收官来不得半点含糊。有一套可靠的端到端 Agent 评测体系相当于给 Agent 开发装上了一面照妖镜。这面镜子照出的不是参数的优劣而是系统能力的边界是你设计决策中的盲区。有了这面镜子你在迭代 Agent 的时候心里始终有底因为你清楚地知道自己每一次改动到底是让 Agent 进步了还是只是换了一种花哨的失败方式。如果你正在被 Agent 的效果问题困扰我建议别急着调 Prompt先去把评测体系建起来再说。
阅读完成 · 觉得有帮助？
