业务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 测试用例的标注与版本管理

测试用例的标注是个体力活，但绝对不能马虎。我的经验是，标注规范要尽可能细化，最好细化到“什么情况下扣几分”的程度。比如对于“任务完成度”这个维度，可以定义：

有了这样细化的标准，不同标注人员之间的一致性会大幅提升。我见过太多团队因为标注标准模糊，导致同一条测试用例两个人标出完全不同的分数，最后评测结果完全不可信。

版本管理同样重要。测试集不是一成不变的，随着业务发展，你需要不断补充新的测试用例。但每次修改测试集，都会导致历史评测结果不可比。所以我的做法是：测试集打版本号，每次评测报告都注明使用的测试集版本。这样当分数变化时，你能区分是Agent改进了，还是测试集变了。

3. 评测框架选型与实操

3.1 DeepEval框架的安装与核心概念

在Agent评测框架的选择上，我试过不少方案，最后比较稳定的是DeepEval。它最大的优势是对Agent场景的原生支持——内置了工具调用正确性、任务完成度、步骤效率等专门针对Agent的评测指标，不用自己从头造轮子。

安装很简单：

pip install deepeval

DeepEval的核心概念是指标（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变更，自动触发评测，只有评测分数不低于基线，才允许合并。

具体流程是这样的：

1. 开发者在feature分支上修改Agent逻辑或Prompt
2. 提交PR时，CI自动拉取最新代码，运行评测脚本
3. 评测脚本加载测试集，逐条运行Agent，收集轨迹和输出
4. 调用DeepEval计算各项指标分数
5. 将本次分数与基线分数对比，生成评测报告
6. 如果分数下降超过阈值，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执行设置一个总超时。因为不同工具的响应时间差异很大，统一超时会导致要么误杀正常调用，要么让慢工具拖垮整个流程。

另外，最大步数限制是必须的。我见过太多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出发，而不是从理论出发。

具体步骤：

1. 从评测结果中筛选出所有失败的用例
2. 按失败原因分类，比如“计算错误”“格式错误”“遗漏步骤”
3. 针对每一类失败，分析Prompt中可能的原因
4. 修改Prompt，重新跑评测，看该类失败是否减少
5. 如果减少，保留修改；如果没减少或引入新问题，回滚

这个方法的要点是每次只改一个变量。如果你同时改了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开发的核心驱动力——没有评测，你根本不知道自己在往哪个方向走。