先说个我自己踩过的场景Agent的Demo演示给老板、客户看效果惊艳能规划、能查资料、能调用工具现场掌声一片。结果一进生产环境用户问法稍微绕一点它就答非所问工具调用链一长中间一步失效就全盘崩溃上下文稍微长一点它反而开始丢关键信息。这个时候你才会明白Agent从“能在演示环境里跑通”到“能在生产环境里扛住”中间差的不是一两个prompt调试而是一整套评估体系。这个评估体系不是简单拿几个测试用例跑一遍看看对不对而是要把Agent的行为、链路、产出、成本全部量化用数据说话。只有把它做扎实了Agent迭代才不是靠感觉上线才不是靠赌。这篇文章就从我实际搭建评估体系的经历出发聊聊从Demo到生产这段“最后一公里”里评估体系到底该怎么设计、怎么落地、怎么避坑。1. Agent评估体系的核心思路拆解1.1 Demo与生产之间的“失真”到底发生在哪做过Agent的朋友应该都有感触Demo环境里Agent的表现基本是“可控的乐观”。因为这个阶段你喂给它的都是精心设计的用例意图明确资料充分工具链路也相对短。而生产环境里用户输入是无限多样的可能有歧义、有口语化表达、有错别字甚至故意刁难工具服务不稳定第三方接口随时可能超时或返回脏数据业务数据分布也在变化上周还好用的检索策略下周可能就失灵了。我后来反思了一下Demo环境最大的问题不是“技术验证不够”而是缺少了一个负反馈闭环。在Demo里只要跑通就是成功在生产里跑通了但用户不满意也是失败。Demo阶段关注的是“能不能调用工具、能不能完成任务”而生产阶段关注的是“在大量不确定因素下能不能稳定、准确、低成本地完成任务”。这两者的评估标准完全不同。所以做评估体系的第一步不是去选工具而是先接受一个现实Agent的质量不是一个静态指标而是多维度的复合结果包括任务完成度、路径合理性、回复准确性、工具调用可靠性、时间消耗和成本开销。缺了任何一个维度评估都是不完整的。1.2 评估体系不是“测试”而是“质量闭环”一开始我犯过一个认知错误把Agent评估当成了传统软件测试——写一批test cases跑一遍看通过率。这个做法对传统函数是有效的但对Agent来说远远不够。原因有两点。第一Agent的输入输出不是纯函数式的。同一个用户问题今天回答A明天可能回答B原因可能是模型版本变了、上下文窗口轮转不同、检索到的文档片段排序变了。用固定期望输出比对的方式根本写不出断言。第二Agent的行为链路太长。一个任务可能要经历“理解意图-拆解步骤-调用工具-检索信息-生成回复”多个环节任何一个环节出错最终输出都会受影响。你是该在最终结果上评估还是在每个环节上评估答案是都要而且要分层。所以我的思路是评估体系本质上是一个质量闭环它应该包含三层能力——度量Measure、诊断Diagnose、回归Guard。度量阶段定义指标、采集数据诊断阶段定位问题出在哪个环节、哪类场景回归阶段在每次迭代后跑一遍评估防止新改动引入旧问题。数据回流到测试集和prompt里再继续下一轮迭代。2. Agent评估体系的四层设计2.1 第一层路径级评估——把Agent的每一步“行踪”摸清楚做Agent评估最容易忽略的就是过程。只盯着最终输出你会发现很多问题被“糊”过去了。比如Agent明明调错了一个工具但最后还是拼凑出了一个看起来还行的答案或者它绕了一大圈中间浪费了十来次模型调用最后才找到正确结果。这些情况只看最终答案根本发现不了。路径级评估要关注的就是Agent每一步的行为轨迹。具体来说我要看三件事。一是工具调用的准确率。它决定该调“天气API”的时候是不是真的调了天气API而不是调成了“日历API”参数有没有传对比如查询天气的城市、日期是否正确。二是步骤拆解的顺序合理性。一个“帮我安排周三下午三点的产品评审会议预订会议室并通知参会人”的任务正常的路径应该是先查参会人忙闲、再订会议室、然后创建会议邀请、最后通知参会人。如果Agent先去通知参会人、再找会议室顺序倒置就算它最后也完成了任务也会给用户带来困扰。三是无效循环与死胡同的检测。这个在生产环境特别常见Agent会陷入同一个错误里反复重试比如调一个接口报了401它不检查token是不是过期了换个prompt再试一次还是401又试一次。这种情况在Demo里几乎不会出现因为Demo的接口全是mock好的。我在落地路径级评估时用的是两步走方案第一步在Agent框架里加一个统一的trace埋点把每次模型调用、工具调用、中间结果、耗时全部结构化记录下来第二步写一个路径校验器用规则解析trace里的关键节点用“合理路径模板”去比对实际路径。模板不用写很多常见场景每个场景准备三五条最佳路径、一两条可接受的容错路径就够了。这里补充一个实操细节路径校验器不要全用规则去匹配建议“规则为主模型为辅”。规则负责检查硬性条件工具名、参数类型、必填字段模型负责判断顺序和语义合理性比如“先查日程再订会议室”和“同时进行”是否可接受这样既稳定又灵活。2.2 第二层状态级评估——用工具输出反推Agent的“理解程度”路径级评估能告诉你Agent“做了哪些事”但还不能告诉你它“做得对不对”。比如Agent调了一个“获取订单状态”的工具工具返回了“订单已发货”这是正确的调用但如果用户问的是“我的订单什么时候到”Agent只回复“已发货”就结束了没给出预计送达时间那么这个调用本身虽成功但任务并没有真正完成。状态级评估的做法是把工具返回的结构化数据作为“中间状态”再结合用户原始问题去判断“这个状态是否真正解答了用户的问题”。这个环节我完全交给LLM来判断但给LLM设计了严格的评估模板不是为了让它自由发挥而是让它按照“证据→结论”的链条来打分。具体评估模板我会让裁判模型先输出三个字段用户核心诉求、工具返回的关键证据、证据能否完全支撑诉求。如果证据不足再输出缺少哪一类信息。最后再给一个0到5分的过程得分。这套模板跑下来能非常有效地发现“工具调对了但任务没有完成到底”的情况。状态级评估还有一个隐藏好处它可以把“Agent的理解能力”和“Agent的执行能力”分开度量。理解能力看它是否选了正确的工具和参数执行能力看它是否把工具返回的信息真正用到了最终答案里。这两个能力在后续调优时的优化手段完全不同分开度量后能少走很多弯路。2.3 第三层结果级评估——LLM-as-a-Judge的选型与部署结果级评估是大家最熟悉的一层就是直接对Agent的最终回答进行质量打分。早期我做这种评估试过Rouge、BLEU、BERTScore这一套文本相似度指标用下来总体感受是文本相似度指标与用户体验的相关性非常弱。原因其实不难理解。用户问“帮我查一下上海明天天气”Agent回答“明天上海晴23到28度东南风3级”和参考回答“上海明天最高28度最低23度晴好天气东南风3级”在字面上差别不小但意思完全一样语义等价。Rouge得分可能只有0.5但用户满意度是100%。反过来两个回答字面上高度相似但一个多了一句话“建议带伞”这个才真正影响体验。所以传统文本匹配指标在开放式生成任务上基本失效。最终我选了LLM-as-a-Judge用大模型当裁判作为结果级评估的主力方案。具体做法是准备一个独立部署的裁判模型可以是GPT-4级别的闭源模型也可以是开源的Qwen2.5-72B这类模型把用户问题、Agent回答、参考回答如果有一起喂给它让它按照预设的评分卡输出维度得分、总分和判定理由。需要特别注意的一点是裁判模型最好和Agent模型不是同一个。如果Agent和Judge共享同一个模型Judge很容易对Agent的“风格偏好”产生纵容从而给出虚高的分数。我之前做过一次对比实验用同一个模型又当选手又当裁判平均分比用独立裁判模型要高出0.7分左右。所以哪怕成本高一点也建议用独立模型。评分维度我也调整了好几版最终稳定在这五个维度正确性信息是否准确、有无幻觉、完整性是否覆盖用户所有诉求、可操作性用户能否直接照做、语气与安全是否专业、合规、无歧视性内容、冗余度有没有车轱辘话。每个维度按5分制打分再加上总分和一句总结性理由。2.4 第四层非功能性评估——成本、时延、稳定性这一层是Demo阶段最容易忽略、生产环境最致命的。我见过太多Agent项目在Demo里跑得好好的上了生产发现每次问答要花5到8秒用户早就走了或者一次调用的token费用是预算的10倍老板看完账单直接让项目下马。非功能性评估我重点看四个指标。一是单轮时延从用户发起请求到收到完整回复的总时间P50、P90、P99三个分位都要记录因为P50再好看P99如果超过15秒长尾用户照样会流失。二是调用成本把模型token费用、工具调用费用分摊到每个任务上按天和按版本分别统计。三是稳定性连续跑N轮测试统计超时、报错、解析失败的比例。四是上下文损耗长对话场景下Agent在多少轮之后开始出现“失忆”或关键信息遗漏。这四项指标里调用成本是最容易被低估的。Agent不是一个单次问答而是一个有多次模型调用和工具调用的复合流程。如果Agent在一个任务里平均调用模型8次即使单次价格很低整体成本也会被放大很多倍。所以定量策略很重要给每个Agent项目设定一个“单任务成本阈值”超过阈值要么优化prompt减少不必要的调用要么换一个更小、更便宜的模型处理子步骤。我在实际项目里通过给简单子任务换用小型模型将单任务整体成本压低了约40%效果非常明显。3. LLM-as-a-Judge的工程化实践与调优3.1 评分卡与评估Prompt的设计细节Judge模型的Prompt设计是整个评估体系里技术含量最高的一个环节。Prompt写得好不好直接决定评估结果可不可信。我见过一些团队把评估Prompt写得很随意两行字就让模型打分打分结果在0到10之间波动剧烈今天同一份测试集跑出7分明天跑出4分根本没法用。经过多次迭代我的评估Prompt固定成四段式结构。第一段身份与任务的声明“你是一名专业的Agent质量评测专家请根据以下评分卡对Agent的回答进行客观打分”。第二段评分维度的明细每个维度单独一行附上该维度的定义和打分锚点。例如“正确性1分表示核心信息错误3分表示部分信息准确但存在遗漏或错误5分表示信息完全准确且无关键遗漏”。第三段输入信息的分隔与标注用XML格式清晰的标记用户问题、Agent回答、工具调用记录避免信息粘连。第四段输出格式要求必须严格输出JSON对象包含每个字段的得分和reason字段。这里有个很细微但也非常重要的点评分锚点必须描述到“行为”层面而不是“感受”层面。不能写“5分回答质量高”要写“5分回答中所有关键信息都有准确出处且无任何与用户问题无关的扩展”。同样3分的描述里要写明“有多少比例的信息是准确的”。把每个档位的行为描述清楚能明显降低不同批次评测之间的浮动幅度。3.2 四个Judge模型的典型坑与对策Judge模型在实际运行中我踩过并验证过的有四个典型问题值得单独列出来。第一个是序列位置偏见。Judge会对位置靠后的内容给出更高权重尤其是当内容较长时。我的对策是在多个测试用例中进行“AB交换”随机化处理同一组对比把Agent回答A和B的顺序互换着评估取两次结果的平均值作为最终结论。如果没有条件做双向评估至少要在结果字段里特别提示Judge“不要因为内容位置不同就改变打分”。第二个是自增强偏差。Judge和Agent如果是同一个模型或者同一个模型系列Judge会倾向于给“与自己风格更接近”的回答更高分。这个我在前面提到过解决方法是使用完全不同的模型家族或者至少在评估结果中做人工抽检校准。第三个是得分趋中。很多模型在不确定给多少分时会倾向于给一个中间分比如3分导致评估结果区分度很差。解决办法是把一些典型答案作为“锚点样本”放进Prompt中作为few-shot示例例如“当回答完全跑题时应给出1分例如……”或者要求Judge先给出各维度证据再输出最终分证据先行能显著减少趋中倾向。第四个是指令过宽导致的幻觉评分。Judge在没有足够上下文时容易脑补Agent没有说过的话。尤其当Agent的回答有引用了文档内容但省略了原文时Judge会默认Agent说得对。对策是在评估Prompt中增加一个声明“当某个信息没有被Agent明确提供时该信息视为答错不得自行补全”。这一条对幻觉检测尤其有效。3.3 评估结果的可信度验证与校准再好的Prompt也不能保证Judge模型100%可靠。所以我会在评估流程里加一道“可信度验证”的工序。具体操作是定期从测试集里抽20到30条样本请真实业务人员或领域专家自己对Agent回答打一次分然后对比Judge的评分计算相关系数我一般用Spearman相关系数和一致率。相关系数低于0.7说明Judge的评估结果不能直接用需要回头检查Prompt或更换Judge模型。另外我还会给每条评测记录加上一个“置信度”字段。这个置信度由Judge自己给出是一个0到1的值用来表达它对自己所打分数的确信程度。置信度低于0.4的样本系统会自动标记为“待人工复核”不会进入后续的分数汇总。这样做还有一个好处它能很自然地识别出那些边界模糊、模型自己都拿不准的测试用例而这些用例往往恰恰是最有价值的迭代素材。4. 从评估集构建到上线回归的完整链路4.1 评测集从哪里来历史沉淀、分类归因、难例挖掘构建评测集是评估体系里看似简单但实际最花时间的部分。我一开始以为写个三五十条测试用例就够了后来发现远远不够。Agent的应用场景往往很宽泛市面上真实用户的问法又千奇百怪评测集覆盖面不足评估结果就容易“自我感觉良好”。我的评测集构建来源有三个。第一个来源是历史对话沉淀把线上日志里真实用户的query全部捞出来做主题聚类和去重挑出高频、高价值、高失败率的样本进入评测集。第二个来源是人为构造的“难例”根据当前Agent的薄弱点故意构造刁钻的输入比如带错别字的query、语义歧义的query、多步骤嵌套指令、需要常识推理才能回答的问题等。第三个来源是回归补漏每次生产中出现的bad case修复之后立即加入评测集确保同类问题不会复发。在评测集的管理上我做了拆分按域划分比如“订单查询域”“售后处理域”“产品推荐域”每个域单独维护并且把评测集拆成“核心回归集”和“候选扩展集”两部分。核心回归集每次版本迭代必跑候选扩展集用来探索新的边界。核心回归集不建议频繁扩充数量控制在每域30到50条否则每次跑评测的成本和时间会吃不消候选扩展集则可以随线上反馈不断累积积累到一定量级后经过筛选并入核心回归集。4.2 评估流水线如何接入CI/CD评估体系要发挥作用不能只靠开发人员手动在本地跑它必须成为开发流程的一部分在每次代码或配置变更时自动触发。我把这套流程接入了项目的CI流水线一共有三个关键环节。第一个环节是离线评估阶段。每次MR合并请求创建时会在一个独立的环境中拉起一个新的Agent实例跑一遍核心回归集生成一份评估报告。报告里会显示各项指标与上一次基准baseline的对比分数下降超过阈值比如正确性下降超过0.3分就视为“回归失败”直接阻断合并。第二个环节是线上小流量验证阶段。离线评估通过后新版本会先部署到小流量环境把真实流量的5%切给新版Agent同时把线上日志的评估结果收集好后与旧版Agent进行在线对比。这个环节有一件很重要的事要有独立的“暗标”比较就是同一个用户问题同时让新旧两个Agent回答但不是都发给用户只拿旧版给用户新版留作对比。这样才能拿到同分布数据下的性能对比不会因为流量偏差导致误判。第三个环节是发布后的持续监控阶段。发布完成后不代表评估结束了。线上Agent每处理一条请求都会自动采集结果进入评估队列以天为粒度生成质量报表。一旦某个域的单日平均分低于阈值会立刻触发告警提醒开发人员去查看是数据分布变化了还是模型本身出了问题。4.3 一次真实的Agent上线复盘说了这么多理论放一个我最近一次上线的实际案例给大家一个直观的概念。这次上线的是一个面向内部员工的知识库问答Agent核心能力是检索公司政策文档并回答员工问题。Demo阶段我们发现Agent在公司网络环境下跑得很流畅demo演示的30个用例正确率做到了90%以上老板当时就拍板要往生产推。推上生产后第一周问题就暴露了。首先是真实员工的提问方式和我们Demo里的query差异太大员工喜欢用很碎的口语比如“年假能休几天来着”、“报销发票怎么搞”Agent经常识别不了意图其次是知识库里的文档格式五花八门有PDF、有Word、有网页抓取来的文本Agent在检索阶段经常抽到不相关的片段导致回答质量大幅下降。我们把线上第一周的数据全部捞回来做了二次标注扒出了117个bad cases进行归类后发现主要问题集中在三个域语义匹配错误31%、信息遗漏27%、检索结果不相关22%。针对这三个问题我们对检索策略做了优化引入了向量检索与关键词检索的双通道融合并给Agent增加了“当检索置信度不足时主动承认并反问用户”的行为。同时把这些问题样本全部补进评测集里。第二次评估时正确率从生产初期的68%提升到81%但更让我满意的不是分数本身而是每个分数背后都有明确的归因我们知道提升来自哪一部分改动、哪些bad case被修复了、哪些还没覆盖。这种透明度才是评估体系真正带来的价值。5. 常见问题与排查技巧实录5.1 评估体系落地中的高频问题速查把我在不同Agent项目里踩过、以及被同事问过的高频问题整理成一个速查表方便大家对照排查。问题现象可能的根因排查与解决建议Judge评分结果抖动大同一份测试集两次跑分差很多Judge Prompt缺少行为锚点或者温度参数过高给评分锚点加行为级描述Judge推理参数temperature设到0或0.2Agent在Demo里效果很好但评测集里得分很低评测集与Demo用例分布不一致存在覆盖盲区检查评测集的域覆盖情况优先补充真实线上query离线评测通过上线后被用户投诉评测集偏向“友好输入”缺乏对抗性和反向用例增加难例、歧义例、超长上下文的评测样本工具调用成功率很高但最终回答还是错问题出在“结果生成”阶段比如幻觉、没用到工具结果用状态级评估检查工具返回信息是否被正确消费成本指标爆炸远超预算Agent循环调用模型次数过多增加单任务调用次数上限对简单子任务换用小模型评测集越攒越多每次跑评测时间太长测试集没有分层管理拆成核心回归集和候选扩展集核心集控制规模5.2 几个避免评估“自我感觉良好”的再补充最后补充三个我后来才意识到的小技巧专门用来防止评估体系本身变成一个“自我感觉良好”的摆设。第一个是定期“金丝雀式”人工复核。就算Judge和置信度机制再完善也要定期拿一批样本给真人看。我现在的节奏是每两周做一次人工抽样复核每次抽20条不只看分数对不对还要看“评测标准本身还合不合适”。因为业务在变用户的期望也在变半年前觉得“能查到即可”的答案现在可能觉得“还要给出建议才满意”。标准不跟着变评估体系就会从“质检员”变成“段子手”。第二个是刻意让评测集“过拟合”Detect出来。如果持续用同一批评测集迭代模型和prompt很快会对评测集产生“越调越好但对真实场景变化无效”的过拟合。比如评测集里某个问题连续三次迭代都是满分那它就不再提供信息量了。我会定期统计每个测试用例的历史得分把连续多轮满分、且没有争议的样本“退居二线”换成更有挑战性的难例。这样能让评测集永远处于“有压力”的状态。第三个是双通道盲测。当你要在两个Agent版本之间做决策时不要只看各自分数要把新旧两个版本的输出随机打乱让标注员或Judge进行AB对比并记录“偏好”而非“绝对分”。偏好类问题的标注一致性通常会比打分高很多而且能告诉你的不是“这两个版本大概谁强”而是“强在哪个场景、哪个维度”决策价值直接高一个量级。6. 把评估体系变成Agent迭代的“指南针”评估体系这东西做着做着你会发现它的价值不在于“打分”本身而在于它逼着你想清楚你做的这个Agent到底好在哪、坏在哪、下一步应该优化哪里。没有评估体系的Agent迭代就像蒙着眼睛开车开到沟里才知道方向错了有了评估体系每次改动都能看到指标在趋势上的变化它会告诉你哪条路更值得继续走。从我的实际经验看一个评估体系的建立真正难的不是技术选型而是坚持把每一环做细评测集是不是够贴近真实、Judge的评分准不准、回归的闸门该设多紧、线上数据有没有回流。这些琐碎的事情叠加在一起才构成了从Demo到生产这段“最后一公里”里最扎实的那段路。最后分享一个小技巧如果你的Agent项目还没建立评估体系别想着一步到位做很复杂的。先从“20条核心用例 一个粗略的LLM打分器”这种最小闭环开始跑起来再逐步加维度、加评测集、加流程。我见过太多团队因为一开始把评估体系设计得太重最后维护不下去全盘放弃。小而精的闭环比大而全的依赖表可靠得多。
