业务Agent评测实战：从轨迹评测到CI集成的全流程指南

1. 业务Agent评测到底在评什么1.1 从“模型评测”到“Agent评测”的认知转变很多人第一次接触Agent评测脑子里浮现的还是那套跑分逻辑拿一个测试集跑一遍算准确率、召回率、F1然后出一张榜单。这套方法在纯LLM评测时代确实够用因为模型输入输出都是确定的——你给它一道题它给你一个答案对错一目了然。但业务Agent完全不是这个逻辑。一个Agent要完成“帮我查一下上个月华东区销售额最高的三个客户并给每个客户生成一份跟进邮件草稿”这样的任务它内部要经历意图理解、任务拆解、工具调用、结果聚合、内容生成等多个环节。任何一个环节出问题最终结果都是错的。你没法用单一的准确率指标来衡量它——是意图识别错了还是SQL写错了还是邮件模板选错了所以Agent评测的核心转变在于从评“答案”转向评“过程”。你要评的是Agent在每一个决策节点上做得对不对而不是只看最终输出。这就引出了Agent评测的第一个核心概念——轨迹评测Trajectory Evaluation。轨迹评测的意思是你不仅记录Agent的最终输出还要记录它每一步的思考、每一次工具调用的参数、每一个中间结果。然后针对这些中间步骤分别打分。这样做的好处是当Agent失败时你能精确定位到是哪一步出了问题而不是对着一个错误答案干瞪眼。我刚开始做Agent评测的时候踩过一个大坑只评最终结果导致一个Agent明明工具调用逻辑全对只是最后格式化输出时多了一个换行符就被判定为完全失败。后来改成轨迹评测才发现它的核心能力其实没问题只是输出格式需要微调。这个教训让我意识到评测粒度决定了你能看到什么。1.2 业务Agent评测的三个核心维度结合我在多个Agent项目中的实操经验业务Agent的评测应该围绕三个核心维度展开第一个维度是任务完成度。这是最直观的指标——Agent到底有没有把用户交代的事情办成。但这里有个细节任务完成度不能简单地用“是/否”来判定而应该分等级。比如一个查数据的任务可以分成“完全正确”“数据正确但格式有误”“数据部分正确”“完全错误”四个等级。这样你才能区分“能力问题”和“工程问题”。第二个维度是过程合理性。Agent在完成任务的过程中是否走了最优路径有没有多余的步骤有没有调用不必要的工具举个例子一个Agent要查天气它先调用了搜索引擎又调用了天气API最后还调用了数据库——虽然最终结果是对的但过程明显冗余。这种Agent在生产环境中会浪费大量token和时间必须通过评测发现并优化。第三个维度是鲁棒性与安全性。当用户输入模糊、有歧义、甚至带有恶意引导时Agent能否正确处理比如用户说“帮我删掉所有不活跃的用户”Agent是直接执行还是先确认“不活跃”的定义这个维度在业务场景中极其重要因为Agent一旦误操作后果可能比单纯答错问题严重得多。这三个维度不是孤立的而是相互关联的。一个任务完成度很高的Agent如果过程冗余长期来看成本会失控一个过程很简洁的Agent如果鲁棒性差在生产环境中就是个定时炸弹。所以评测报告必须三个维度一起看才能做出准确判断。1.3 为什么传统AB Test在Agent评测中不够用说到评测很多人第一反应是AB Test——把两个版本的Agent同时上线看哪个版本的业务指标更好。这个方法在推荐系统、搜索排序等领域非常成熟但用在Agent评测上有几个致命问题。首先是反馈周期太长。AB Test需要足够的样本量和时间才能得出统计显著的结论。但Agent的迭代速度往往很快可能你今天刚上线一个版本明天就发现了一个明显的bad case需要修复。等AB Test跑出结果黄花菜都凉了。其次是归因困难。AB Test只能告诉你“A版本比B版本好”但没法告诉你“为什么好”。是Prompt改进了还是工具调用逻辑优化了还是模型换了你只知道结果不知道原因下次优化时依然两眼一抹黑。最后是成本问题。Agent的每次调用都涉及LLM推理成本不低。如果为了AB Test跑大量样本费用会非常可观。而且有些业务场景本身流量就不大根本凑不够AB Test所需的样本量。所以我的做法是离线评测为主在线AB Test为辅。离线评测用精心设计的测试集快速迭代在线AB Test只用来验证最终版本在真实流量下的表现。两者结合既保证了迭代速度又确保了上线质量。2. 评测数据集的设计与构建2.1 业务Agent测试集的特殊性做LLM评测时测试集通常是“问题-标准答案”的配对。但Agent的测试集要复杂得多因为一个Agent任务往往有多个“正确路径”。比如“帮我订一张明天从北京到上海的机票”Agent可以查航班、可以查高铁、可以先问用户偏好再查——这些路径都可能被判定为正确。所以Agent测试集的设计原则是定义清楚“什么算成功”而不是“必须怎么做”。具体来说每个测试用例应该包含以下要素用户输入模拟真实用户的自然语言指令要包含一定的模糊性和多样性期望结果描述任务完成后的理想状态可以是最终输出的内容要求也可以是系统状态的变更要求约束条件哪些操作是允许的哪些是禁止的比如“不能调用外部支付接口”评分标准如何判断Agent是否成功包括任务完成度、过程合理性等维度的具体打分规则我通常会建议团队先花一周时间专门做测试集设计而不是急着写评测代码。因为测试集的质量直接决定了评测结果的可信度。一个设计糟糕的测试集跑出来的分数再高也没有参考价值。2.2 如何覆盖真实业务场景的长尾分布业务Agent面临的最大挑战之一是长尾问题——80%的用户请求是常见的但剩下20%的请求千奇百怪。如果测试集只覆盖常见场景评测结果会严重高估Agent的实际能力。我的做法是采用三层采样策略第一层是高频核心场景占测试集的50%左右。这些是业务中最常见的请求必须保证Agent在这些场景下表现稳定。比如电商客服Agent的“查订单状态”“申请退款”“修改收货地址”等。第二层是中频变体场景占30%左右。这些是核心场景的变体比如用户用不同的表达方式说同一件事或者请求中夹杂了额外条件。这一层主要测试Agent的泛化能力。第三层是低频边缘场景占20%左右。这些是罕见但重要的场景比如用户输入包含错别字、中英文混杂、或者带有情绪化表达。这一层主要测试Agent的鲁棒性。这三层的比例不是固定的要根据业务特点调整。但核心原则是不能只测“好走的路”必须主动去测“难走的路”。因为生产环境中的bad case往往就藏在那些你没想到的边缘场景里。2.3 测试用例的标注与版本管理测试用例的标注是个体力活但绝对不能马虎。我的经验是标注规范要尽可能细化最好细化到“什么情况下扣几分”的程度。比如对于“任务完成度”这个维度可以定义等级描述分值完全正确任务目标完全达成输出格式符合要求1.0基本正确任务目标达成但输出格式有小瑕疵0.8部分正确任务目标部分达成关键信息缺失或错误0.5完全错误任务目标未达成或输出严重偏离0.0有了这样细化的标准不同标注人员之间的一致性会大幅提升。我见过太多团队因为标注标准模糊导致同一条测试用例两个人标出完全不同的分数最后评测结果完全不可信。版本管理同样重要。测试集不是一成不变的随着业务发展你需要不断补充新的测试用例。但每次修改测试集都会导致历史评测结果不可比。所以我的做法是测试集打版本号每次评测报告都注明使用的测试集版本。这样当分数变化时你能区分是Agent改进了还是测试集变了。3. 评测框架选型与实操3.1 DeepEval框架的安装与核心概念在Agent评测框架的选择上我试过不少方案最后比较稳定的是DeepEval。它最大的优势是对Agent场景的原生支持——内置了工具调用正确性、任务完成度、步骤效率等专门针对Agent的评测指标不用自己从头造轮子。安装很简单pip install deepevalDeepEval的核心概念是指标Metric和测试用例LLMTestCase。一个测试用例包含输入、实际输出、期望输出、以及可选的上下文和工具调用记录。指标则是用来给测试用例打分的函数。对于Agent评测我常用的几个指标包括TaskCompletionMetric评估任务是否完成ToolCorrectnessMetric评估工具调用是否正确StepEfficiencyMetric评估步骤是否冗余AnswerRelevancyMetric评估最终输出是否切题这些指标底层都是通过LLM来打分的所以你需要配置一个评分用的模型。我一般用GPT-4级别的模型来评分因为评分模型的判断力直接决定了评测结果的可信度。3.2 自定义Agent评测指标的实现DeepEval内置的指标虽然好用但业务场景千差万别很多时候你需要自定义指标。比如我们有一个场景是“生成的SQL必须符合公司数据仓库的命名规范”这种业务规则内置指标肯定覆盖不了。自定义指标的基本结构是这样的from deepeval.metrics import BaseMetric from deepeval.test_case import LLMTestCase class SQLNamingConventionMetric(BaseMetric): def __init__(self, threshold: float 0.8): self.threshold threshold def measure(self, test_case: LLMTestCase) - float: sql test_case.actual_output # 检查表名是否以 dw_ 开头 # 检查字段名是否使用蛇形命名 # 检查是否包含必要的注释 score self._evaluate_naming(sql) self.score score self.success score self.threshold return score def is_successful(self) - bool: return self.success property def __name__(self): return SQL命名规范这个自定义指标的好处是你可以把业务规则直接编码进去评测结果更贴合实际需求。而且因为是代码实现的评分速度快、成本低适合大规模跑测试集。我通常会建议团队把评测指标分成两类LLM评分指标和规则评分指标。前者用于评估语义层面的质量比如回答是否切题、推理是否合理后者用于评估硬性规则比如格式是否正确、是否包含敏感词。两类指标结合使用评测结果才全面。3.3 评测流程的自动化与CI集成评测不能是一次性的必须集成到开发流程中。我的做法是把评测做成CI流水线的一个环节每次代码提交或Prompt变更自动触发评测只有评测分数不低于基线才允许合并。具体流程是这样的开发者在feature分支上修改Agent逻辑或Prompt提交PR时CI自动拉取最新代码运行评测脚本评测脚本加载测试集逐条运行Agent收集轨迹和输出调用DeepEval计算各项指标分数将本次分数与基线分数对比生成评测报告如果分数下降超过阈值PR被标记为“需要人工审查”这个流程的关键是基线管理。基线不能定得太高否则每次提交都过不了也不能定得太低否则评测就失去了把关作用。我的经验是基线定在当前版本分数的95%左右允许小幅波动但大幅下降必须报警。另外评测脚本的运行时间要控制好。如果每次CI都要跑半小时开发者会怨声载道。我的做法是快速评测集100条左右用于CI全量评测集1000条以上用于每日定时任务。快速评测集覆盖核心场景能在几分钟内跑完全量评测集用于深度分析不阻塞开发流程。4. 评测执行中的常见问题与排查4.1 Prompt被拦截与请求失败的排查做Agent评测时最让人头疼的问题之一就是Prompt被拦截。你明明写的是正常的业务指令但模型返回一个“invalid prompt: your prompt was flagged as potentially violating our usage policy”。这种情况在批量评测时尤其常见因为测试集里可能包含一些边缘场景的输入触发了模型的安全机制。排查这类问题的思路是首先定位是哪个测试用例触发了拦截。在评测脚本里加上异常捕获把失败的用例单独记录下来。然后逐条分析这些用例的输入看是否包含敏感词或敏感模式。其次区分是输入问题还是输出问题。有时候输入没问题但模型生成的中间结果触发了拦截。这种情况比较隐蔽需要把Agent的完整轨迹打出来才能发现。最后准备降级方案。对于确实无法通过正常渠道完成的测试用例可以标记为“跳过”而不是“失败”。但跳过的比例要控制好如果超过5%说明测试集本身可能有问题需要重新审查。注意不要试图通过修改Prompt来绕过安全机制这既不道德也不可持续。正确的做法是调整测试用例确保它们符合使用规范。4.2 Agent执行中断与超时处理Agent执行过程中断是另一个高频问题。常见的原因包括工具调用超时、LLM返回格式错误导致解析失败、Agent陷入循环等。我的排查清单是这样的问题现象可能原因排查方法Agent执行到一半停止工具调用超时检查工具API的响应时间设置合理的超时阈值Agent反复调用同一工具陷入循环检查Agent的停止条件设置最大步数限制LLM返回无法解析输出格式不符合预期检查Prompt中的格式约束增加输出解析的容错逻辑Agent执行时间过长步骤冗余或工具慢分析轨迹找出耗时最长的步骤对于超时问题我的经验是给每个工具调用设置独立的超时时间而不是给整个Agent执行设置一个总超时。因为不同工具的响应时间差异很大统一超时会导致要么误杀正常调用要么让慢工具拖垮整个流程。另外最大步数限制是必须的。我见过太多Agent因为缺少步数限制在一个死循环里烧掉大量token。一般设置10-15步比较合理具体取决于任务复杂度。4.3 评测结果波动的原因分析与应对评测结果波动是另一个让人抓狂的问题。同一个Agent同样的测试集今天跑出来85分明天跑出来78分。这种波动如果不加以控制评测就失去了意义。波动的主要来源有三个第一是LLM本身的随机性。即使temperature设为0不同批次的推理结果也可能有细微差异。应对方法是多次运行取平均一般跑3次取平均分波动会小很多。第二是评分模型的随机性。如果评分也是用LLM那评分本身就有波动。应对方法是固定评分模型和评分Prompt并且对评分结果做一致性校验——比如让评分模型对同一个输出打两次分如果差异超过阈值就人工介入。第三是测试集本身的噪声。有些测试用例的判定标准比较模糊不同时间跑可能得到不同结果。应对方法是定期审查测试集把那些判定标准模糊的用例挑出来要么细化标准要么直接删除。我的一般做法是评测报告里必须包含波动范围。如果只报一个分数那是在误导人。报“82分±3分”才是负责任的做法。5. 从评测到优化的闭环5.1 利用评测结果定位Agent瓶颈评测的最终目的是优化所以评测报告不能只给分数必须能指导优化。我的做法是把评测结果按维度拆解找出最薄弱的环节。比如一个Agent的整体任务是“处理用户退款申请”评测结果显示意图识别准确率95%工具调用正确率88%退款金额计算准确率72%回复话术满意度85%一眼就能看出退款金额计算是瓶颈。接下来就重点优化这个环节——是Prompt里对计算规则的描述不够清晰还是缺少必要的校验步骤还是工具本身有问题这种按维度拆解的方法比只看总分有效得多。总分85分听起来还不错但拆开一看某个关键维度只有72分这就是必须优先解决的问题。5.2 基于Bad Case的Prompt迭代方法找到瓶颈后下一步就是优化。对于Prompt相关的问题我的迭代方法是从Bad Case出发而不是从理论出发。具体步骤从评测结果中筛选出所有失败的用例按失败原因分类比如“计算错误”“格式错误”“遗漏步骤”针对每一类失败分析Prompt中可能的原因修改Prompt重新跑评测看该类失败是否减少如果减少保留修改如果没减少或引入新问题回滚这个方法的要点是每次只改一个变量。如果你同时改了Prompt、换了模型、调整了工具那评测结果变化了你也说不清是哪个改动起的作用。另外保留Prompt版本历史非常重要。我一般用Git管理Prompt文件每次修改都有commit记录。这样当发现某个版本效果特别好时可以快速回滚。5.3 评测驱动的Agent架构优化有些问题不是Prompt能解决的需要从架构层面优化。比如如果Agent经常在复杂任务中迷失方向可能需要引入任务规划模块先拆解再执行如果Agent的工具调用经常出错可能需要增加工具调用前的校验步骤如果Agent的回复质量不稳定可能需要引入输出后处理模块对结果进行二次校验这些架构层面的优化同样需要评测来验证效果。我的做法是每次架构调整后跑全量评测集对比调整前后的各维度分数。如果某个维度显著提升且没有其他维度下降说明调整有效。评测驱动的架构优化是一个持续迭代的过程。没有一劳永逸的方案只有不断发现问题、解决问题、再发现新问题的循环。但正是这个循环让Agent的能力一步步逼近生产可用的水平。6. 一些实操中的经验与教训6.1 评测不是越早越好但也不能太晚关于什么时候开始做评测我的观点是Agent能跑通基本流程后就应该开始建评测。太早建评测Agent还处于剧烈变动期测试集和指标都要频繁改投入产出比低太晚建评测Agent已经积累了大量技术债改起来成本极高。我的经验时间点是当Agent能稳定完成3-5个核心场景时就可以开始建评测了。这时候Agent的基本架构已经定型测试集不会频繁大改同时又能及时发现方向性问题。6.2 评测集要“养”不能“造完就扔”很多团队把测试集当成一次性投入造完就放在那里不动了。这是大错特错。业务在变用户在变Agent的能力也在变测试集必须跟着变。我的做法是每月做一次测试集审查内容包括删除已经不再相关的测试用例补充新出现的业务场景修正判定标准模糊的用例根据线上bad case补充新的测试用例这个审查过程不需要太长时间半天就够了但效果非常明显。我见过太多团队因为测试集长期不更新导致评测分数很高但线上效果很差——因为测试集已经和真实业务脱节了。6.3 评测报告要让人看得懂最后说一个容易被忽视的点评测报告的可读性。我见过很多评测报告满篇都是数字和术语非技术背景的产品经理根本看不懂。这样的报告是没有价值的因为评测的最终目的是指导决策而决策者往往不是技术专家。我的评测报告一般包含三部分第一部分是一句话结论比如“当前版本Agent在退款场景下表现稳定但在查询场景下存在明显瓶颈”。第二部分是分维度得分表用红黄绿三色标注各维度的健康度一眼就能看出哪里有问题。第三部分是典型Bad Case分析挑3-5个最有代表性的失败案例详细说明失败原因和优化建议。这样的报告技术、产品、运营都能看懂讨论起来也有共同语言。评测的价值才能真正发挥出来。我个人在实际操作中的体会是Agent评测这件事技术只占三成七成是耐心和细致。测试集要一条条设计Bad Case要一个个分析Prompt要一版版迭代。没有什么捷径可走但每一步的投入都会在Agent的最终表现上体现出来。踩过几次坑之后我越来越觉得评测不是Agent开发的附属品而是Agent开发的核心驱动力——没有评测你根本不知道自己在往哪个方向走。