做了两年多的智能体评测系统从最早“脚本里塞几十个case跑一跑”到后面按工程化标准把评测做成独立的平台级服务我最大的感受是评测系统的复杂度九成不在写代码而在于你如何看待它。多数团队一开始都把评测当成临时验证工具等模型升级、Agent逻辑频繁改动之后才发现缺少一套可靠的评测系统产品迭代就像在没黑灯的路上开车——你敢踩油门但不知道什么时候会撞。这篇文章想聊的不是某个评测指标怎么算也不是某个框架怎么用而是把“智能体评测系统”当成一个正经的软件工程来做的时候架构该怎么拆、模块该怎么设计、工程化落地时哪些地方最容易翻车。适合正在做Agent开发、智能体平台、质量保障或AI应用工程化的团队参考。哪怕你还没有系统化的评测平台读完也可以按里面的思路先从最小闭环开始搭。1. 做评测系统之前先想清楚边界和设计目标1.1 为什么智能体评测不能“跑一下”就完事传统接口测试有一个天然优势输入输出都是结构化数据断言逻辑非常明确。请求发出去返回200且body里某个字段等于预期值这个用例就过了。但智能体评测完全不同。智能体的输入是一段自然语言上下文输出是多轮对话、工具调用、状态变化交织在一起的复杂结果很多时候根本不存在“唯一正确答案”。举个例子你让一个销售智能体处理“客户说太贵了想再便宜点”的场景它可以给出降价方案也可以强调产品价值还可以追问客户预算。三种行为方式不同但可能都是合理的。这种情况下单一断言式校验根本覆盖不了真实业务需要覆盖的能力范围。更麻烦的是智能体行为的不确定性。同一个Prompt模型版本没变、参数没变跑两次结果都可能不一样。再加上Agent在运行过程中可能调用不同工具、走不同路径单次运行结果只能反映当次行为不能代表整体能力。如果评测脚本只是简单地把对话记录下来人工看一眼说“还行”那这个评测结果既不可复现也不可量化更不可能在团队协作中形成统一标准。我见过不少团队的评测脚本散落在个人仓库里标准不统一、数据不共享、结果不可比。A同学说“效果变好了”B同学反问“哪里变好了”谁也说服不了谁。这种状态下评测系统本身就成了一种技术债。所以做系统之前先要接受一个前提评测不是测试的附属品它是一条独立的产品线要按软件工程的标准来建设。1.2 评测系统的四个设计底线我在梳理评测系统架构的时候最先定下来的不是技术选型而是四条设计底线。后续所有模块划分、方案取舍都以这四条为判断依据。第一可重复。同一份评测集、同一个被测版本、同样的评测配置任何时候跑都应该得到一致的结论。这里的“一致”指的是统计意义上可复现而不是要求每次对话一模一样。如果同一天跑两次一次显示成功率80%一次显示60%那这个评测系统本身是不可信的谁都不敢用它做决策。第二可追踪。每一次评测结果都要能追溯到被测代码版本、模型版本、Prompt版本、评测集版本、评测参数五类信息。任何一个维度缺失结果出问题时都没法定位。这条底线直接决定了数据模型怎么设计后面会细说。第三可量化。评测输出必须包含结构化指标而不是只有“看起来不错”。任务成功率、工具调用正确率、平均轮数、Token消耗、安全合规拦截率这些都要落到数字上。数字不一定代表全部但没有数字做基准评测就没有参照系。第四可回归。Agent系统是持续演进的今天改一个系统Prompt明天换一个模型后天加一个工具每次改动都可能影响整体表现。评测系统必须有能力在每次改动后自动跑一遍核心评测集快速发现哪些能力被改坏了。缺少回归能力评测系统就只能当“展示板”起不到质量门禁的作用。这四条底线看起来简单实际落地时每条都会牵扯出一堆细节。可重复牵扯出环境隔离和随机性控制可追踪牵扯出元数据管理和版本关联可量化牵扯出指标体系设计可回归牵扯出执行调度和基线管理。架构设计本质上就是在为这四件事兜底。2. 评测系统的整体架构三层模型和数据流2.1 三层拓扑场景接入层、执行调度层、分析评估层评测系统的整体架构我习惯把它分成三层场景接入层、执行调度层、分析评估层。这个分层方式不是拍脑袋定的而是踩过几次坑之后梳理出来的。场景接入层负责“测什么”。它管理评测场景、用例样本、评测数据集以及用户提交评测任务的入口。这一层本质上是把业务需求翻译成机器可执行的评测任务。你告诉系统“我想测一下销售智能体在客户砍价场景下的表现”系统需要把它转成一个包含场景定义、样本列表、参数配置的评测任务对象。执行调度层负责“怎么测”。它接收评测任务拆解成一个个可独立执行的用例根据并发和限流策略调度执行同时处理超时、重试、状态流转。这一层是整个系统的引擎也是工程化程度要求最高的部分。很多评测系统跑得不稳定问题都出在这一层——并发控制不好导致被上游限流超时设置不合理导致大量误判重试机制不健全导致结果偏差。分析评估层负责“结果是什么”。它收集执行过程中的所有事件数据计算各类指标生成报告管理回归基线。这一层听起来简单实际很容易被低估。指标口径稍有差异同一批执行数据能算出两个截然不同的结论报告如果只给一个成功率数字又完全没办法定位问题。三层结构最核心的价值是隔离。场景接入口径和执行机制无关调度机制和指标计算无关指标计算和场景定义无关。这样任何一层升级其他层都不用跟着重写。我曾经在早期版本把场景定义和执行逻辑写在同一个服务里后来想支持流式对话场景只能把执行模块从服务里抽出来硬生生多花了两个星期重构。2.2 以事件流为主干的数据链路评测运行过程中产生的数据按内容可以分成三类任务元数据、执行轨迹数据、评估结果数据。其中最关键的是执行轨迹数据它记录了智能体在评测过程中每一步的行为包括用户输入、模型输出、工具调用参数、工具返回结果、各阶段耗时、Token消耗等。这些轨迹数据的特征是产生顺序性强、格式多样、写入量大。设计数据链路时我建议以事件流为主干而不是简单地把一次评测执行当成一个同步请求来处理。原因在于智能体运行天然是多步骤、异步化的。一个Agent从接收用户消息到最终给出回复中间可能经历多轮模型推理和工具调用周期长达几十秒甚至几分钟。如果用同步接口等所有步骤跑完再统一返回执行引擎会被长时间占用一旦中途超时之前所有轨迹数据都会丢失。实际方案是执行引擎每产生一个行为事件就立刻写入消息队列或日志管道评估服务异步消费这些事件。这样执行过程和分析过程解耦执行引擎不用等指标算完才结束评估服务也不影响执行稳定性。数据经过清洗、结构化之后进入指标计算流程和Trace存储。这样即使某次评估计算出现故障原始事件还在可以重新计算。2.3 模块边界与部署形态基于上面的分层具体落地时系统至少包括以下模块场景中心、样本管理模块、评测任务服务、执行引擎、指标计算服务、报告服务、评测集管理模块。模块之间通过明确的API或消息协议通信不共享数据库表。部署形态上评测系统建议独立部署不要和业务应用混在一起。一是资源隔离评测执行时会产生较大的计算和网络开销混部会影响线上业务二是稳定性隔离评测系统出故障不能影响生产环境三是安全问题评测系统通常会配置访问第三方模型服务的密钥独立部署可以更严格地管控权限。有同事问过评测系统要不要用微服务架构。我的回答是模块边界一定分但物理部署形态看团队规模。小团队前期完全可以把场景中心、任务服务、执行引擎打包成一个服务指标计算和报告单独放一个服务两者通过数据库和消息队列解耦。等评测规模大了再把执行引擎独立出来做水平扩展。上来就拆八、九个微服务只会增加运维负担不会带来实际收益。3. 评测内容工程化场景、样本与评测集管理3.1 评测场景的数据建模评测场景是评测系统里最基础的概念它描述了一类评测任务要考察的能力范畴。一个场景可能包含以下字段场景名称、描述、任务目标、允许使用的工具范围、初始上下文系统Prompt风格约束、预期行为说明、典型样本示例。建议直接用JSON Schema建模这样既能约束字段又能兼容扩展。举个例子一个“客户砍价应对”场景的Schema大概是这样的{ scenario_id: sales_price_negotiation, name: 客户砍价应对, description: 考察销售智能体在客户提出价格异议时的应对能力, objective: 在不损害公司底价的前提下尽量挽留客户并推进下一步沟通, allowed_tools: [price_query, order_create, customer_info], initial_context: { customer_tier: vip, product_category: saas_subscription }, expected_behaviors: [ 先确认客户需求再给出价格方案, 触碰底价时必须提示审批, 不得虚假承诺折扣 ], tags: [销售, 议价, 高优先级] }场景建模的价值一方面在于结构化更重要的是让不同角色之间有了统一的“沟通语言”。产品经理可以看场景描述工程师可以看工具约束评测人员可以看预期行为。缺少这层结构化定义评测样本就是一堆聊天记录很难维护也很难规模化扩展。3.2 评测集的治理与版本控制评测集是智能体评测系统的“题库”它决定了系统在多大程度上能测出真实能力水平。评测集治理是内容工程的核心工作比写执行代码更耗时也更容易被忽视。评测集必须当成代码来管理。我的习惯是把评测集文件放在独立Git仓库里每一份评测集对应一个目录里面包含样本文件、标注说明、更新记录。任何样本的增删修改都要走评审流程不直接在线编辑。这样做的目的是防止“评测集污染”——哪些样本是原始评测集哪些是后来为了调优模型加进去的都要能追溯。评测集的质量控制有几个关键指标。覆盖度方面要看场景类型是否覆盖了主要业务方向每个场景的样本量是否足够支撑统计结论难度分布方面要有简单、中等、困难三档样本不能全是“送分题”也不能全是“极端刁钻”稳定性方面评测集更新后要对比新旧评测集在历史版本上的表现避免样本替换导致结论漂移。3.3 样本标注的SOP与一致性样本标注是评测内容生产中最容易出问题的环节。一个样本通常包括输入消息、期望行为描述、可接受的优秀表现示例、不可接受的失败表现示例。难点在于多个标注人员对同一个样本的理解可能有差异。我建议为标注团队制定明确的SOP核心是两件事。一是定义清晰的评分标准比如“任务完成度”指标下什么算完成、什么算部分完成、什么算失败都要有可对照的示例二是建立标注一致性校验机制定期抽取一定比例的样本由不同标注员重标计算一致性指标低于阈值的样本要重新讨论。此外样本里不能有明显偏见或诱导性表述。评测智能体的目的是考察其真实服务能力不是“钓鱼执法”。如果故意构造一些容易引发生成不当内容的输入然后把模型判断为不合格这种评测集只会让模型被引导到过度保守的状态反而影响正常场景下的表现。4. 执行引擎并发、限流、超时与状态机4.1 任务模型与状态机执行引擎是评测系统中工程化含量最高的模块。我先定义清楚任务模型评测任务Task是最外层单元代表一次完整评测请求一个Task包含一个或多个评测集Suite每个Suites由若干用例Case组成一个Case对应一条评测样本在指定配置下的一次完整执行。状态机是执行引擎的核心骨架。一种比较实用的状态定义是pending等待执行、running执行中、passed通过、failed未通过、error执行异常、timeout超时、cancelled取消。状态流转逻辑必须单一路径例如pending只能流转到runningrunning只能流转到passed、failed、error、timeout之一。这个状态机看似简单实际落地时容易出问题的是“error”和“failed”的区分。我的定义是failed代表智能体执行了但结果不符合预期属于业务层面的失败error代表执行过程中出现基础设施异常比如模型服务返回5xx、工具调用网络中断属于系统层面的失败。两者的处理策略完全不同——failed需要分析语义error大多可以直接重试。如果混在一起报告里会看到一堆噪音数据。4.2 并发度和限流参数怎么算评测执行通常会调用第三方模型服务或者自建推理服务并发太高会导致限流报错并发太低又拉长评测时长。并发度规划其实可以通过简单计算来确定。假设平均单个用例耗时为15秒包括模型推理和工具调用目标是在20分钟内跑完240个用例。每个执行并发单位上单位时间能完成的用例数为1/15个每秒。设需要的并发数为C则理论上满足240 / 15 240 / (C * 15) 即C 240 / 15 / (2060/15) 240 * 15 / (20 * 60) 3这里推导有点绕换个方式理解单并发20分钟可跑2060/1580个用例240个用例需要240/803个并发。但这是理想情况实际还要考虑网络延迟、重试、以及部分用例超时拉长耗时一般按理想值的1.5倍到2倍预留也就是并发数至少取5到6。限流方面我建议在执行引擎里做两级控制。一级是全局令牌桶控制整体请求速率防止瞬间并发过高冲击模型服务另一级是单任务并发限制防止多个评测任务同时启动时互相抢资源。限流参数不要拍脑袋设根据压测结果动态调整——先从小并发起步逐步加压找到“执行速度不再明显提升”的拐点定为并发上限。4.3 超时、重试与幂等设计智能体评测执行天然存在不确定性超时和重试是保证系统稳定性的关键。超时设置要分层次单次模型调用设置连接超时和读取超时比如连接超时5秒、读取超时30秒单个用例设置总超时通常是正常耗时的3到5倍比如正常15秒的用例总超时给60秒整个评测任务也可以设置最长执行时间防止任务“悬挂”。重试机制要遵守三条原则。第一只对可恢复的错误重试比如上游限流、网络抖动、服务端5xx对业务失败不重试因为重试大概率还是同样结果只会浪费成本。第二重试必须带退避策略推荐指数退避加抖动比如第一次等1秒第二次等2秒第三次等4秒随机加减0到0.5秒。第三重试要做幂等控制同一用例的重试执行要生成新的执行ID但归属到同一个评测任务下保证数据统计时不会把一次用例的多次尝试重复计数。5. 指标计算与评估报告把“感觉变好了”变成数字5.1 指标分层的设计评测报告的指标设计我建议分层梳理不要只盯一个“成功率”。分层的好处是既能看全局又能下钻定位问题。我习惯把指标分成三层结果层、过程层、资源层。结果层回答“任务最终有没有达成目标”包括用例通过率、任务完成度、关键行为覆盖率等。过程层回答“这单在执行过程中表现如何”包括工具调用正确率、上下文利用效率、无效轮数、回复长度合理性、合规拒绝是否正确等。资源层回答“成本花在哪里”包括平均Token消耗、平均调用次数、单用例执行耗时、超时率等。指标口径的定义是这层最容易埋坑的地方。举个例子工具调用正确率分子是“被判定为正确的工具调用次数”分母是什么是总工具调用次数还是应调用工具的总次数两个口径算出来结果可能差很多。我踩过这个坑之后第一件事是给每个指标写清楚“定义文档”包含计算公式、数据来源、计算时点、示例口径。指标口径没有统一后面所有对比分析都是空中楼阁。5.2 自动评估与人工评估怎么结合智能体评测里最难也最核心的是评估环节如何判断一个多轮交互结果是否合格。纯粹靠人工评估代价高、速度慢、难以规模化纯粹靠自动评估又容易在复杂语义场景下出现误判。实际工程落地基本是两者结合按场景类型分配比例。自动评估可以做三类事情规则校验、结果比对、模型辅助评分。规则校验适合硬性条件比如是否提及客服工单号、是否包含必要字段结果比对适合有明确标准的场景比如检索类Agent的知识命中率模型辅助评分LLM-as-Judge适合开放场景但这里有个坑——评估用的模型和被测智能体模型不要用同一个否则相当于让选手给自己当裁判结果偏差会很明显。评估模型的参数也要固定温度设为0System Prompt固定下来Prompt本身要纳入版本管理。人工评估不能省但可以聚焦。建议对自动评估结果中边界分比如得分在阈值附近的用例、争议性强、以及高风险场景的样本设置至少10%到20%的人工抽检比例。抽检结果反过来可以校准自动评估的阈值形成持续改进循环。5.3 报告、回归基线与趋势分析评测报告的目标不是“生成一个漂亮的PDF”而是帮助团队回答三个问题当前版本相比上一版是变好还是变差变好变差集中在哪些场景最典型的失败案例是什么。因此报告要包含以下内容总体指标摘要表与基线差值用上下箭头标明场景维度拆解按场景分组展示通过率、平均轮数、Token消耗等让人一眼看出哪个场景波动最大失败样例列表每条样例附上执行轨迹链接点击即可查看完整对话和工具调用细节以及自动生成的失败原因初步归类方便后续人工分析。回归基线是评测报告最有价值的衍生产物。每次发版后选一个稳定版本作为基线后续所有变更都和基线对比。建议基线每月重新校准一次因为模型能力在持续变化评测集也在迭代基线定太久会出现“现在看什么都退步”的错觉。趋势图上我只看三个东西整体通过率趋势、各场景通过率热力图、失败原因TOP3的变化其余信息太多反而干扰决策。6. 工程化落地的关键环境隔离、可观测性与流水线集成6.1 环境隔离与依赖固定评测系统对环境隔离的要求比普通开发环境严格得多。我早期吃过一次大亏在开发环境评测一个Agent结果另一个同事同时在调试同一套服务两边互相影响评测结果失真。从那以后评测环境必须独立并且每次评测尽量用容器或沙箱形态拉起被测服务。依赖固定也是同样的逻辑。评测时用的模型版本、Prompt版本、外部服务版本、依赖库版本全部要显式声明在评测配置里不能默认拉最新。之前有过Model版本从7B升到13B导致评测集全面通过的“假成功”实际上是模型版本变了被测Agent的推理表现也变了但评测系统没有记录版本号排查了很久才找到根因。6.2 Trace与日志评测过程必须可回溯评测系统最容易被忽视的工程化模块是可观测性。没有Trace追踪评测结果一旦出问题就只能对着一个失败标记干瞪眼。我的经验是评测任务从创建到完成的整个过程每一步都要可回溯。建议评测执行过程中累计三类日志。审计日志任务谁提交的、评测集版本是什么、被测版本是什么轨迹日志智能体每一步的输入、输出、工具调用、状态转换按用例维度组装系统日志执行引擎自身的运行情况、耗时、错误栈。轨迹日志建议采用OpenTelemetry或类似标准埋点配合日志系统实现按用例ID检索完整链路。评测报告里给到的每一个失败用例都应该附上一条可直接点开的Trace链接。这样评测工程师在看到“这个用例失败了”的同时能立刻看到“失败发生在模型推理的第3轮当时调用了价格查询工具返回结果超时”。没有这部分能力评测系统就只是个自动化跑脚本的工具谈不上工程化。6.3 接入CI/CD评测从“人工操作”变成“自动门禁”评测系统工程化落地的标志性节点是把它接到代码提交和发布流程里。我建议分三级跑第一级是冒烟评测代码合入主分支前跑从评测集里抽最核心的50到100个用例执行时间控制在10分钟以内主要目的是发现明显回退。第二级是回归评测每天定时跑全量核心评测集生成趋势报告发现仪式性回退就自动创建追踪问题。第三级是发布门禁发布候选版本必须通过指定评测集通过率低于阈值则阻断发布流程。接入CI/CD的过程中最需要处理的是“评测集规模”和“执行时间”的矛盾。CI里执行时间太长会拖累开发节奏所以冒烟评测集一定要精选优先选代表核心链路和最近改动点的样本把执行时间控制在用户可接受的范围内。可以先在数据上测算比如8到10个并发平均15秒一个用例全量跑500个用例大概15分钟核心冒烟集选80个用例大概2到3分钟这样才适合放在提交阶段跑。6.4 成本预算与控制智能体评测跑起来是实打实要花钱的尤其是调用第三方模型API。成本控制不能等月底账单出来才后悔要在架构层面提前设计。成本计算模型很简单。平均100个用例一天跑两次每个用例平均产生5次模型调用每次约消耗2000 Token按每百万Token的价格计算就能得到单日成本。有了这个基础估算再定每月预算反推每天允许跑的用例总量再分配到各部门的评测任务额度上。具体的一个估算示例如下假设某文本模型价格为每百万Token 50元每个用例平均消耗5000 Token含输入输出评测系统每天跑500个用例则单日Token消耗为500个用例乘以5000 Token等于250万Token日成本约为125元月成本约3750元。如果加入人工评估抽检和失败重试实际成本还会更高预算至少要预留30%的余量。成本控制手段包括评测样本里合理复用上下文减少Token浪费对长时间运行的Agent设置总步数上限避免“死循环”烧Token重试只针对可恢复错误且限制重试次数非关键评测任务放到模型服务低峰期执行降低被限流概率。成本控制做得好评测系统才有长期跑下去的资源保障。7. 踩坑实录与排查技巧7.1 智能体评测典型问题速查表结合我自己和同行交流的经验整理了一份高频问题速查表基本能把评测系统的常见坑覆盖到七八成现象可能原因解决办法同一天跑两次结果差异很大模型版本漂移、参数没固定、评测集被改过固定模型版本、温度、随机种子评测集做版本管理并发一高就大量超时并发参数设置过大、上游限流根据压测重新估算并发度抓上游限流日志确认所有用例几乎都“通过”评分标准太宽松、自动评估Prompt有引导性检查指标口径对边界分加大人工抽检比例单用例执行时间异常长Agent陷入工具调用死循环设置单用例最大步数比如最多调用10次工具失败用例查看发现对话内容错乱并行执行时上下文串台排查线程局部变量或单例对象状态改为用例级隔离报告数据与执行日志对不上事件流有丢失或重复消费检查消费端幂等性事件写入加唯一ID某个场景通过率波动大样本量太小统计误差该场景扩充样本量或放弃该维度的细粒度结论7.2 三个让我印象深刻的坑第一个坑是评估模型的Prompt污染。最早用LLM-as-Judge时评估Prompt里给了“AI助手应该表现出积极友好的态度”这类描述结果所有被测智能体都因为回复不够热情而被打低分而业务方真正关心的是有没有解决问题。后来把评估Prompt改为只针对目标达成度打分同时定期拿人工标注结果校准评估Prompt问题才解决。这个坑的关键在于评估Prompt和被测智能体的Prompt必须完全独立且有明确的评分维度。第二个坑是评测环境的“脏状态”。有一次评测报告显示某个场景的通过率从85%掉到60%排查了很久最后发现是评测环境里缓存了上一个版本的模型配置Agent加载到了旧配置。从那以后每次评测启动前强制清空缓存、校验环境指纹环境指纹包含被测服务版本、模型版本、依赖锁文件哈希等不匹配直接拒绝执行。第三个坑是并发场景下的上下文串台。现象是某个用例的多轮对话中突然混入了另一条消息的内容看起来像“精神分裂”。排查后定位到是执行引擎在压测时共用一个历史消息列表实例并发写导致数据互相覆盖。修复方式是每个用例的执行上下文一律通过依赖注入创建独立实例过程中不共享任何可写状态。7.3 一次成功率下降的排查过程分享一次典型的排查过程里面有很多共性经验。当时线上评测报告显示“订单查询Agent”整体通过率一夜之间下降了12%场景集中在“用户查询多笔订单”相关的样本。第一步查报告里的失败用例列表发现失败集中在同一种表现智能体只返回了第一笔订单信息没有列出其余订单。第二步查看失败用例的执行轨迹发现工具调用返回的结果里其实包含三笔订单但模型在最终生成回复时只引用了第一笔。第三步对照依赖版本信息确认被测Agent的代码没有变更、Prompt没有变更唯一变化的是模型版本从前一天的基础模型升到了新版本。定位到这里基本能判断是新版本模型在“长列表信息汇总”任务上的指令遵循能力变弱了。后面找模型团队反馈同时把该场景的评测集单独拆出来作为新模型版本上线的回归门禁样本。整个过程如果没有Trace追踪和依赖版本记录这种“隐性回归”很难被发现。结尾一点个人体会评测系统的建设技术上的难点其实是有限的难的是把很多流程、规范、细节持续坚持做下去。我自己的体会是评测系统能不能真正跑起来关键往往不在执行引擎写得多好而在于对评测集的态度、对指标口径的较真、对环境隔离的敬畏这些“脏活累活”才是评测系统稳定可信的地基。最后分享一个比较实用的小技巧刚开始没经验的时候不要急着把几百上千个用例全量放进去跑先挑五十个有代表性的用例把从提交评测到出报告的全链路打通确认指标计算口径正确再逐步扩充样本量。先把指标做“可信”再把指标做“好看”顺序反了后面全是返工。评测系统这块内容后续能扩展的方向也很多比如多智能体协作场景的评测编排、评测集自动生成、基于失败样本的自动归因都是值得继续投入的方向。