如果你在公司里负责智能体平台一定绕不开一个问题怎么证明你开发的Agent真的比上一个版本强跑几个例子发给同事看效果再惊艳也只是个案模型一换、Prompt一调好与坏全凭感觉。我在过去半年里正好从零搭建了一套智能体评测系统核心目标只有一个把“我觉得它变好了”变成“数据说明它变好了”。这套系统的架构设计、工程化落地过程中踩的坑、总结的经验今天全部拆开来讲。智能体评测不是传统意义上的自动化测试评测对象是一个会思考、会调用工具、会跟你来回多轮对话的系统。它的结果不仅受模型影响还受Prompt、上下文、工具返回、甚至随机种子影响。如果不把评测系统建成分层、可扩展、可观测的工程化设施上线第一天就会陷入“用例怎么维护、结果怎么解读、分数怎么对比”的泥潭。本文适合正在做智能体平台、准备给Agent搭建评测体系或者想把评测结果接入发布流程的工程师参考内容不涉及具体的商业产品绑定而是围绕评测系统本身的架构思路与工程实施展开。1. 为什么应该把智能体评测当成一套系统来建设1.1 智能体评测和传统单元测试完全是两码事传统后端单元测试讲究的是确定性输入一个参数输出一个返回值断言相等或不相等。智能体评测则面对的是一个“概率性”对象。同一个问题两次调用可能得到不同表达方式、不同步骤顺序甚至不同结论。如果你的评测方式还停留在“比对字符串是否包含某个关键词”很快就会误判大量结果。我最早踩过这个坑。当时团队直接写了个Python脚本把几十条问题丢给Agent然后检查输出里有没有“好的”“已为您”这些词。结果一次Prompt迭代后Agent开始用更自然的表达不再说“已为您”脚本全挂但真实用户体验其实是变好的。这件事让我意识到评测必须支持“多维度判定”而不是一个函数里的几个断言。智能体的评测还要处理多轮对话状态。比如用户先问“杭州明天天气”Agent回答后又追问“那后天呢”这里“后天”必须依赖前文语境。用例数据如果不包含多轮对话和中间状态测出来的结果就没有参考价值。再加上智能体普遍会调用外部工具比如搜索、查库、写工单。这意味着一轮评测可能触发真实外部请求如果不对工具层做Mock或沙箱隔离测试环境会被污染线上数据也可能被误操作。所以智能体评测系统其实是一个集用例管理、执行调度、工具隔离、结果判定、可视化分析于一体的复杂工程绝不是拿个脚本跑一遍就完事。1.2 评测系统的能力边界评测什么、不评测什么在动手设计之前先想清楚边界。我一般把评测系统拆成五个关注面功能达成度、内容质量、性能、成本和安全性。功能达成度是“任务有没有完成”例如用户要查天气Agent有没有给出天气信息用户要订会议室Agent有没有真的调用接口并确认成功。内容质量是“答得好不好”包括表达是否清晰、格式是否满足要求、有没有胡编乱造。性能主要看首Token延迟、完整响应时长、工具调用耗时。成本主要看Token消耗和工具调用次数。安全性则关注Prompt注入、越权访问、敏感信息泄露等。评测系统需要明确自己不做什么。我不建议把线上真实用户满意度直接塞进评测系统里当唯一指标因为线上行为受运营活动、网络环境、用户意图偏差影响太大。评测系统的价值在于“受控环境下的标准化比较”要评估一个Prompt或一个模型可不可用用固定数据集跑回归得出横向对比分数用户在真实场景下的反馈应该走另一套监控和可观测体系。边界定义清楚之后系统的模块划分、数据模型和调度策略也就有了依据。2. 整体架构设计方案与关键选型思路2.1 架构总览任务编排、隔离执行、结果回流我最终落地的架构可以分成五层入口接入层、任务编排层、执行层、数据层和分析展示层。入口接入层负责接收评测触发命令可以是人工点击也可以是Git提交触发的Webhook还可以是定时任务。任务编排层把评测请求拆解成原子任务单元分发给执行器并负责状态流转、重试策略和超时控制。执行层运行真正的智能体实例通过适配器连接Dify、扣子等智能体平台或者直接调用内部Agent服务执行过程中记录完整日志和Trace。数据层存储评测用例、运行记录、评测结果、打分明细、Token用量等。分析展示层把原始数据聚合成趋势报表、对比图表和失败样本列表。分层的好处在于每一层都能独立扩展。比如开始团队只有几十条用例执行层用本地进程池就够了后来用例增长到数千条我只需要把执行层换成分布式Worker入口和编排逻辑完全不用动。同理今天你要接一个新的智能体平台只需新增一个适配器不影响数据层和分析层。2.2 为什么用分布式任务队列而不是同步轮询早期版本我非常天真评测直接用HTTP同步请求一次评测发起几十个并发请求然后阻塞等结果。用例少的时候没什么问题但用例一多上游服务稍微慢一点整个评测脚本就卡死在那里一次全量评测跑一个多小时而且失败一个也不知道怎么回事。后来我把执行链路改成了异步任务队列。整体结构是评测发起方把任务写入队列Worker从队列里拉取任务执行完把结果写入存储前端通过WebSocket或轮询查询进度。这套模型可以轻松支持上千个并发任务还能在某个智能体服务抽风时通过队列积压避免雪崩。队列选型上早期我用Redis的List实现了一个轻量队列优点是部署简单、无额外依赖缺点是缺乏任务确认ACK和延迟队列能力一旦Worker崩溃就会丢任务。后来切换到RabbitMQ使用持久化队列和手动ACK才真正解决可靠投递问题。如果你的团队已经在用Kafka也可以使用Kafka的消费者机制但要注意不能把Kafka默认的at-least-once语义当成恰好一次消费端必须做好幂等。2.3 用例、数据集、智能体实例如何建模评测系统里的核心模型有三个评测用例、评测数据集、智能体实例配置。评测用例是最小执行单元包含用户输入、初始上下文、期望行为、建议答案或检查点。我通常用JSON保存一份用例里面存对话轮次列表每一轮包含role、content、期望工具调用等信息。评测数据集是用例的集合并带有版本号、标签、创建人、变更说明。数据集需要像代码一样做版本管理因为每次模型升级后我们必须用同一份数据集去对比新旧模型效果不同时间跑出来的分数才有可比性。智能体实例配置是评测系统与具体Agent服务的连接描述包括平台类型、API地址、API Key别名、模型名称、Prompt版本、工具开关等。评测执行时会把“数据集智能体实例配置”组合成一次评测任务这样同样一批用例可以分别跑“旧Prompt”和“新Prompt”也可以跑“GPT-4”和“Claude”的对比。3. 核心模块的工程化落地实操3.1 用例与数据集管理版本、标签、依赖注入用例管理是我建议优先做的事。很多团队直接从Excel维护用例一开始还好过了两百条就彻底失控。我们现在的做法是用Git管理用例文件每个用例是一个JSON文件目录结构按照业务域划分比如“天气查询”“会议室预定”“工单处理”。每个用例文件包含id、statusactive/disabled、tags、priority、dialogue、expected、owner等字段。这里最关键的字段是tags我通常会打上“回归”“冒烟”“边界”“多轮”“工具调用”等标签这样执行评测时可以按标签筛选比如每次发版前只跑冒烟集每周五跑全量回归。数据集管理要做到“不可变”。我使用语义化版本号命名数据集例如weather-dataset-v1.3.0每次修改都要追加变更记录。评测报告里必须记录当时使用的数据集版本否则一周后发现分数变了你根本不知道是模型变了还是用例变了。依赖注入是指用例里需要外部变量时不能写死。比如用户问“查一下杭州未来三天的天气”这个用例如果第二天跑步杭州天气确实在变但Agent返回结果都无法断言对错。我们的做法是在用例里定义变量占位符例如{city}和{date}执行器在运行前从变量池随机或按规则注入。这样同一套用例可以反复使用也避免固定答案对Agent产生误导。3.2 执行器设计如何让评测过程可重复、可隔离执行器是整个系统的引擎设计上必须解决三个问题隔离、超时、幂等。隔离方面每个评测任务最好跑在独立环境里。开始我直接用多线程调用Agent API代价是一个Agent因为上下文太长卡住线程池全部占满其他用例跟着遭殃。后来我改成进程池Docker容器每条用例或一组用例分配一个独立容器容器里可以起一个轻量HTTP服务内部封装对Agent服务的调用。这样即使某个用例触发了无限循环的工具调用最多只影响当前容器杀掉重跑即可。超时控制要分层设计。每次工具调用、每个对话轮次、整条评测任务都要有独立的超时时间。我通常设置单轮等待超时15秒整条多轮任务超时120秒超过就把任务标记为“超时失败”并保留超时前的全部日志。超时后的重试次数默认2次但如果第一次已经把外部工具真的执行了重试前需要确认工具是否具备幂等性否则不能盲目重试。幂等性主要体现在消费任务时。评测任务可能因为网络问题重复投递Worker必须保证同一任务不会反复写入重复结果。我们用任务ID在存储层做唯一约束插入结果时如果发现主键冲突就丢弃本次执行保证结果表里一个任务只对应一条核心记录。执行器通过适配器模式连接不同Agent平台。每个适配器只需要实现两个方法construct_messages() 和 execute()。前者把评测用例的对话轮次转换成目标平台要求的消息格式后者负责发起调用并接收响应。只要接口一致新增平台只是多写一个适配器的事。3.3 评判模块规则、LLM-as-Judge、人工抽检的三层结构智能体评测最难的部分是结果判定。我实践下来最可靠的是三层判定结构。第一层是规则判定适合有明确结构或关键行为的结果。比如Agent是否在指定参数下调用了某个工具、返回JSON是否包含必填字段、多轮对话中是否出现指定节点。规则判定执行成本低、结果稳定能用就用。第二层是LLM-as-Judge用一个大模型去评判Agent的输出。适合内容质量类指标比如“回答是否清晰完整”“是否准确引用了文档”“是否规避了敏感问题”。这里必须注意两点一是Judge模型和被测模型最好不要是同一个模型否则容易出现系统性偏好二是Judge的Prompt要写得非常具体最好给出评分维度和样例避免让模型输出一个空洞的分数。第三层是人工抽检。LLM打分再准也不可能100%可靠所以我会对每次评测自动抽5%到10%的失败样本推送给人工复核。人工复核结果回填到数据库用于持续优化规则和校准Judge的 Prompt。三层结构落地时每个判定结果都要保留可解释信息。规则判定要有命中了哪条规则LLM打分要有思考过程或打分理由人工抽检要记录复核人。不能只存一个总分否则后续排查“为什么这条用例挂了”完全无从下手。3.4 报告与可观测性失败样本如何追溯评测报告不是给机器看的是给工程师和产品经理一起看的。所以我要求每次评测任务结束后系统自动聚合一份可读报告至少包含本次评测总体通过率、关键指标趋势、失败用例列表、Token消耗统计、对比例如果有旧版本基线。失败样本追溯是最容易被忽略但也是实际排查效率最高的环节。每一条失败样本必须关联完整的执行链路包括每一轮对话的输入输出、每次工具调用的参数和返回结果、整体耗时、Token消耗、以及最终打分结果。这样当业务方来问“为什么说这个用例没过”时你可以在十分钟内贴出一条完整记录而不是让业务方去看一堆日志。技术栈上我用ClickHouse存储评测明细记录用PostgreSQL存储配置类和聚合报表数据。ClickHouse对这类时序性日志查询效率很高一条用例的完整Trace可以通过trace_id一次性拉出来。展示端一开始用Grafana后来发现Grafana不适合做复杂的评测报告就换成自研的React页面只展示评测相关视图逻辑更聚合。4. 对接常见智能体框架与平台时要注意的细节4.1 对接Dify和扣子这类平台Agent API现在很多团队不是从零写Agent而是基于Dify、扣子这类平台搭工作流评测系统必须能友好对接。这类平台基本都提供API接口关键是要弄清楚会话管理的粒度。有的平台每个Session独立记忆评测时必须为每条用例创建新的Session避免上一条用例的历史污染下一条。有的平台支持通过参数覆盖模型配置评测时可以把模型名和Prompt模板作为变量传入这样一次能跑多组对比。另一个细节是平台方的限流策略。很多SaaS平台的API有并发限制评测系统如果一下子打到几十路并发很容易触发429。我的做法是在适配器层做令牌桶限流同时设置重试机制。限流参数要可配置不同平台的配额不一样。我之前接Dify时踩过一个坑Dify的会话接口返回时默认只返回最终答案文本工具调用过程要通过日志接口查询。如果评测只看最终文本很多“过程错误但最后蒙对”的用例会被放行。所以适配器里如果平台支持查询工具调用日志一定要一并拉取并把工具调用记录纳入规则判定。扣子这边的情况类似平台API会返回消息体但不同插件的输出格式差异很大评测用例里的期望工具调用需要尽量结构化成统一的中间格式比如tool_calls: [{name, input, output}]这样分析层不需要关心底层平台差异。4.2 多智能体与工具调用场景的评测怎么设计现在复杂业务早就不止单个Agent了很多是“主Agent多个子Agent”编排或者“Agent大量工具插件”协作。评测系统如果只测最终答案会漏掉链路中的关键故障。我在实际项目中把多智能体评测拆成两个层次一个是整链路结果评测用户问题丢进去看最终输出是否满足需求另一个是节点级评测重点是“关键决策点是否正确”。例如用户问“我要订周五下午三点的会议室”主Agent判断意图调用会议室查询工具子Agent确认会议室状态然后调用预定接口。如果最终反馈“预定成功”但过程中查询日期是错的整链路评测可能会给通过节点级评测就能抓出问题。为此我在用例模型里增加了一个预期链路字段叫做expected_trace记录关键步骤的顺序和参数。评测执行时适配器会把实际执行Trace与预期Trace做对齐这里不要求完全相等但每个关键节点必须存在且参数正确。工具调用参数验证也很讲究。不能只看工具有没有被调用还要看入参是不是从用户对话里正确抽取的。比如用户说“帮我定后天下午三点的会议室”Agent如果算对了“后天”的具体日期但把时间配成了下午3点半这个错误在最终结果里可能看不出来但参数校验一定会暴露。4.3 把评测接入CI/CD和灰度发布流程评测系统最大的价值在于持续回归。如果只是人想起就跑一次很快就会荒废。正确做法是把评测接入研发流程强制每次变更都经过回归。我建议在CI流水线里加两个阶段提交级评测和发布级评测。提交级评测只跑冒烟集包含20到50条核心用例目标是快速发现问题整个流程控制在10分钟以内。发布级评测跑全量回归包含几百甚至上千条用例可能耗时较长一般放在构建后的独立任务里跑。全量评测跑完后系统会自动生成一份与最新基线版本的对比报告。如果通过率下降超过一定阈值比如2%流水线直接失败不允许发布。这里阈值设置要动态调节一开始我们设5%发现经常漏问题后来改成2%但偶尔会因为数据标注不准确引发误报于是加了一个“人工确认可豁免”的机制。灰度发布阶段我建议把评测配置也纳入灰度。比如新Prompt先对10%的真实流量放量同时后台用评测系统对新Prompt跑一遍全量回归两边的结果互相印证。这样即使用户反馈有滞后评测回归也能提前暴露风险。5. 常见问题与排查技巧实录5.1 结果不稳定同一用例两测结果不一样这是接触评测系统的人第一个崩溃点。同样一条用例上午跑通过了下午跑挂了换一个模型之前一大批用例全挂模型没变只是随机种子变了分数波动很大。根本原因在于智能体是概率模型相同输入可能生成不同输出。排查方向有三个。第一先看模型采样参数比如temperature、top_p如果允许随机性较大评测结果波动是正常的我通常评测环境把temperature设为0或0.1让输出尽量稳定。第二看外部依赖工具返回的实时数据可能变化这就要在评测环境对工具做Mock或者依赖注入固定参数。第三看上下文污染如果Session复用或者全局Prompt被其他任务修改也会导致结果漂移。我排查这类问题时习惯固定一个“复现专用配置”固定模型版本、固定数据集版本、固定工具Mock数据、固定最大Token和temperature然后反复跑五次。如果波动仍然很大基本就是评测设计本身不够稳定需要调整用例断言而不是抱怨Agent不听话。5.2 评测任务卡死超时、连接不释放、并发死锁评测系统跑了一段时间后最容易出现“任务一直卡在运行中”的问题。第一次遇到时我以为是网络慢等了十分钟发现还在运行然后整个队列都被堵住了。逐层排查后最大的罪魁祸首是HTTP连接不释放。很多HTTP客户端默认连接池大小有限并发一高连接被占满新请求排不上队任务就一直等着。解决方法是给每次调用设置明确的超时时间包括连接超时、读取超时和总超时并且把所有超时时间配置化不要写死在代码里。另一个原因是任务重试逻辑设计有误。如果任务因为超时失败后立即重试而底层Agent服务还是卡着的重试只会加重故障形成“重试风暴”。后来我在重试策略里加了指数退避第一次等5秒第二次等20秒并且设置最大重试次数。对于彻底卡死的任务还要靠“看门狗”兜底。我实现了一个定时任务每隔30秒扫描一次运行中状态超过阈值的任务强制标记为失败并记录失败原因为heartbeat_timeout。这样即使Worker本身崩溃也不会让评测任务永远悬挂在队列里。5.3 LLM打分不稳定偏见、幻觉、规则冲突LLM-as-Judge并不是银弹。我踩过最大的坑是模型打分时带有明显的“偏好”同一个答案被Judge模型评价为高质量换一个Judge模型就给了低分甚至同一个模型题目顺序调换分数也变。后来我做了几个优化。第一Judge的Prompt改成结构化的评分卡明确列出“内容正确性”“完整性”“表达清晰度”三个维度每个维度给权重并要求模型输出JSON格式。输出里必须包含“评分理由”不能只给分数。第二对Judge结果做一致性校验如果多次打分结果方差过大自动标记为“低置信度”转入人工抽检。第三出现规则判定和LLM打分冲突时以规则判定为准并在报告中标注冲突详情。还有一个常见问题是模型幻觉。Judge模型可能因为“觉得”某个答案看起来像官方文风就给高分但答案实际引用了不存在的接口。这类问题靠规则判定兜底比较有效凡是用例里声明了必须包含某些信息或格式的先跑规则再跑LLM打分最后两个结果交叉。5.4 数据泄漏测试集被模型学到以后分数虚高这是最隐蔽、影响最大的问题。如果评测用例集长期固定且不脱敏模型在生产环境或者Fine-tuning时可能已经“背过”答案评测分数会高得离谱完全失去参考意义。我处理数据泄漏有三个原则。第一评测数据集与训练/精调数据必须物理隔离禁止互相混用。第二用例数据集按月滚动加入新的真实用户问题淘汰明显过时或模型已经“背熟”的题目。第三对每一条用例记录“首次加入时间”和“最后修改时间”如果一条用例很久没更新且通过率长期100%会触发提醒让运营人工审核是否还有价值。有一次我们的一个内部Agent模型通过率突然从88%涨到96%所有人都很高兴只有我觉得不对劲。查了日志才发现是评测数据集里的部分问题被采集到了线上日志又在Fine-tuning时混进了训练集。去掉这些重叠用例后真实通过率回落到89%。从那以后数据泄漏检测就加进了每周评测报告里自动化扫描数据集和训练集的文本重叠情况。6. 成本控制与持续迭代机制6.1 算力与Token消耗怎么估算评测系统跑一次全量回归成本比大部分人想象的高。以前跑500条用例每条大概10轮对话每轮调用一次模型算下来5000次模型调用如果每次都携带较长上下文一次全量评测可能就要消耗几百万Token。如果一天跑多轮成本很快失控。我建议在评测发起前先做一个成本估算。很简单根据数据集里用例的平均对话轮数和平均Token数乘上模型单价得出每次评测的预估成本。如果超过预设阈值系统会弹窗提醒要求选择“只跑冒烟集”或“限制并发”。执行过程中我也对每条用例单独记录Token消耗最终报告里能看到Token最高的Top 20用例。很多高成本用例其实是大段上下文塞入了引用文档但在评测场景里并不需要那么长上下文这个时候就应该在用例里精简输入而不是让模型白白多算一遍。6.2 少样本高覆盖从冒烟集到全量集不要一开始就追求大规模评测用例。我建议分成三层来建设。第一层是冒烟集10到20条覆盖核心主流程例如“天气查询”“创建待办”“订阅新闻”目标是把链路通断测出来任何一次Prompt修改都先过这层。第二层是回归集100到300条覆盖典型业务场景和常见边界情况比如“超出上下文长度的长文本”“工具参数缺省”“多轮指代消解”。第三层是全量集1000条以上用于重大版本发布前的全面评估覆盖长尾场景和异常输入。很多团队上来就拼命堆用例结果数据质量差每条用例里还有大量错误标注评测得出的分数完全不可信。我宁愿先把500条高质量用例打磨好也不建议盲目扩到5000条低质量用例。质量优先数量其次。对于冒烟集和回归集我还有一个强制要求任何一次模型升级、Prompt迭代、平台切换都必须先跑回归集不在CI里做一次完整回归不允许进入下一步。这条规则看着粗暴但极大避免了“模型升级后功能整体退化”的线上事故。6.3 评测结果如何反哺智能体优化评测系统不是终点它的数据必须回流到Agent开发流程里才能形成闭环。我落地了几个机制。第一个是“失败样本周会”每周从评测系统里导出分类好的失败样本分发给对应的Agent开发工程师每人领走自己负责模块的问题修复后提交新的评测任务进行验证。第二个是“回归基线自动更新”当新版Agent通过率连续稳定高于旧版后系统自动把基线切到新版避免一直拿老版本做对比让新优化受到老问题的拖累。第三个是“提示词变更关联”每次Prompt或者工具描述改动都可以在评测系统里建立一次实验实验ID关联到评测报告方便回溯哪次改动造成了哪个指标波动。我还把评测结果接入了团队的消息通知全量评测完成或通过率下降超过阈值时自动发送到IM群。这个看似简单的功能实际使用率比任何数据看板都高因为人是被事件驱动的而不是靠主动进系统看报表。回到最初的问题智能体评测系统到底该怎么做我的答案很简单先定义边界再搭架构后端用分布式任务队列保证扩展性用例和数据集必须版本化管理执行模块要隔离和可观测评判用三层结构结果必须能追溯到执行链路。工程化落地不是把脚本重构成服务而是让评测这件事成为团队内部的基础设施像CI系统一样可靠、可重复、可依赖。我个人在实际操作中的体会是评测系统最难的不是写代码而是接受“不完美”。它永远会有误报、漏报和不稳定但只要能把问题快速暴露出来就已经比“拍脑袋判断Agent好坏”强了百倍。最后再分享一个技巧如果你还在用脚本临时测Agent可以先别急着上平台把你现在的脚本输出改成统一JSON格式每条结果带一个trace_id再给用例加上版本号你会惊讶地发现这两个小改动就能让评测工程化往前推进一大步。