写在前面这两年很多团队都在做 AI Agent智能客服、AI 助教、自动写报告的助手……产品做出来以后测试同学往往会卡在一个问题上这东西到底怎么测传统功能测试的思路是「输入 A预期输出 B对比一下一致就通过」。Agent 不吃这一套。同一个问题问三遍它可能给出三种说法改了一句提示词昨天好好的功能今天就答歪了换个模型版本整体表现可能变好也可能在某个角落悄悄变差。这篇文章不讲高深的算法只讲一个测试团队怎么从零开始把 Agent 的测试搭成一套能持续运转的体系。核心就三件事评测集测什么、断言怎么判断对错、回归改动之后怎么快速知道有没有变坏。先交代一下贯穿全文的例子。假设我们要测一个「课程顾问 Agent」它能做这些事回答课程相关问题适合几岁、一节课多长、怎么上课调用工具查询用户的订单和剩余课时解释退费、请假等政策遇到解决不了的问题转人工一、先想清楚Agent 到底要测哪几层很多人测 Agent 只盯着最后那句回答其实不够。一个 Agent 干活的过程大致是理解问题 → 决定要不要调用工具 → 调用工具拿数据 → 组织语言回答。每一步都可能出错所以建议分三层来看。第一层最终回答对不对。这是用户直接看到的比如信息是否准确、有没有答非所问、语气是否合适。第二层过程对不对。该查订单的时候有没有真的去查查的是不是当前用户的订单参数传对了没有很多时候最终回答看起来没毛病但其实是模型「猜」出来的根本没调用工具这种问题只看回答是发现不了的。第三层底线守没守住。比如不能泄露其他用户信息、不能乱承诺退款、不能被用户一句「忽略之前的规则」就带跑。这一层出一次问题可能就是事故。后面设计评测集和断言都会围绕这三层来展开。二、评测集给 Agent 准备一套「题库」评测集是什么说白了评测集就是一套题库。每道题包含问 Agent 什么、它应该做到什么、不能做什么。以后每次 Agent 有改动就拿这套题库考一遍看分数有没有下降。它和传统的测试用例很像区别在于传统用例的预期结果是一个确定答案评测集的「标准答案」更像是一份评分要点本系列第二篇专门讲了怎么写。第一步别贪多先做 20 条刚开始最容易犯的错误是一上来就想搞几百上千条题目。结果题目质量参差不齐评分标准也没想清楚跑出来一堆分数谁也说不清它代表什么。我的建议是先挑 20 条最核心的场景人工逐条跑、逐条打分。这 20 条的价值在于你会在打分过程中真正搞清楚「什么样的回答算好」评分标准就是这么磨出来的你会发现哪些东西能用规则自动判断哪些必须靠人或者靠模型判断这 20 条人工打过分的结果以后可以用来校验自动评分准不准后面会讲20 条跑顺了再逐步扩到 50 条、100 条。题目从哪里来按优先级排线上真实对话。这是最有价值的来源。用户实际怎么问比测试人员自己想出来的要「野」得多。比如用户不会说「请帮我查询剩余课时」而是说「我还剩几节课啊」「课还有多少」「上次买的那个包用完没」。业务方最关心的高频问题。找产品和运营要一份清单用户最常问什么、哪些问题答错了会被投诉。历史 bug。每修一个 Agent 的问题就把它变成一道题放进题库防止以后又犯。刁钻和恶意的问题。专门用来测底线比如套话、诱导、越权本系列第一篇有展开。一道题长什么样建议每道题至少包含这几个字段用表格或者 JSON 存都可以{id:course_refund_001,标签:[退费政策,高频,核心],对话历史:[],用户输入:我买的课上了3节不想上了能退吗,必须提到的要点:[说明可以申请退费,说明已上课时会扣除,告知申请途径或转人工],应该调用的工具:[查询订单],绝对不能出现:[承诺全额退款,编造具体退款金额]}几个字段的作用标签方便以后按类别统计比如「退费类通过率 95%查课时类只有 70%」一眼就能看出短板在哪对话历史多轮对话场景用把前几轮对话放进去测第 N 轮的表现必须提到的要点注意写的是信息点不是标准原句应该调用的工具用来测第二层过程绝对不能出现用来测第三层底线题库要分层题目多了以后每次全跑一遍又慢又费钱每调一次大模型都要花钱。所以建议分成三套题库规模什么时候跑作用冒烟集1020 条每次改动都跑快速确认主流程没坏回归集100 条左右改提示词、换模型、上线前全面检查有没有退化对抗集3050 条上线前、定期专门测安全和底线三、断言怎么判断 Agent 答得对不对这是整个体系里最关键的部分。我把判断方式分成三种按「能用简单的就不用复杂的」排序。方式一规则断言最便宜、最稳定能用代码直接判断的一律用代码判断。比如回答里是否出现了「全额退款」这类禁止词是否调用了「查询订单」这个工具参数里的用户 ID 对不对要求输出 JSON 的能不能正常解析、字段齐不齐回答长度是否在合理范围响应时间是否超过 10 秒写起来很简单比如defcheck_forbidden_words(answer,forbidden_list):forwordinforbidden_list:ifwordinanswer:returnFalse,f出现禁止内容{word}returnTrue,通过defcheck_tool_called(tool_calls,expected_tool):names[call[name]forcallintool_calls]ifexpected_toolinnames:returnTrue,通过returnFalse,f没有调用{expected_tool}规则断言的优点是结果稳定、不花钱、速度快。缺点是只能判断「表面」的东西。比如「是否说明了已上课时会扣除」用户可能表达成「上过的课要扣掉」「会按实际消耗计算」用关键词很难覆盖全。方式二让大模型当裁判灵活但需要校准对于「意思对不对」这种问题可以让另一个大模型来打分业内一般叫 LLM-as-Judge。做法就是把问题、Agent 的回答、评分要点一起发给裁判模型让它按标准打分。裁判的提示词大概长这样你是一个严格的评分员。请根据评分要点判断客服的回答是否合格。 用户问题{用户输入} 客服回答{Agent 回答} 评分要点每条都要检查 1. 说明可以申请退费 2. 说明已上课时会扣除 3. 告知申请途径或转人工 禁止内容承诺全额退款、编造具体退款金额 请逐条判断每个要点是否满足再检查是否出现禁止内容。 最后按以下格式输出 {要点1: true/false, 要点2: true/false, 要点3: true/false, 出现禁止内容: true/false, 理由: ...}几个实用技巧让它逐条判断不要直接给总分。直接问「这个回答打几分」裁判会很随意逐条检查要点结果会稳定很多。要求输出固定格式。方便代码解析也方便你事后翻看理由。裁判模型尽量用能力强一点的。省在这里后面分数都不可信。最重要的一点裁判本身也要被测。怎么测还记得前面人工打过分的 20 条吗拿裁判去打一遍对比它和人工的结论。如果 20 条里有 18 条一致说明裁判基本靠谱如果只有 12 条一致说明评分提示词还得改。以后改了裁判提示词也要重新跑一遍这个对比。方式三人工抽检最准但最贵再好的自动评分也有漏网之鱼所以要保留人工抽检每次回归随机抽 10% 左右人工看一遍自动评分判为「不通过」的全部人工复核有可能是裁判判错了新增类型的问题前几次都人工看三种方式怎么组合可以想象成一个金字塔底层是大量的规则断言中间是模型打分顶层是少量人工。一道题可以同时用多种断言比如退费那道题规则断言检查是否调用了「查询订单」、是否出现「全额退款」模型打分检查三个要点是否都讲到了人工抽检偶尔看一眼整体语气和体验四、回归改完之后怎么知道有没有变坏什么时候必须跑回归Agent 的「改动」比传统软件多得多下面这些情况都要跑改了系统提示词哪怕只改一句话换了模型或者模型升级了版本新增或修改了工具知识库内容更新了调整了温度等参数尤其是改提示词经常出现「为了修 A 问题加了一句话结果 B 场景崩了」。这正是回归的意义。同一道题要跑多次这是 Agent 测试和传统测试最不一样的地方。因为输出有随机性一道题跑一次通过不代表它稳定通过。建议核心题目每道跑 35 次看通过率。比如跑 5 次通过 5 次说明很稳跑 5 次通过 3 次说明这个场景不稳定需要重点关注哪怕某一次恰好通过了也不能放心。看变化而不是只看绝对分数回归报告最重要的不是「这次得了 87 分」而是和上一个版本比变了什么。建议报告里至少有这几项整体通过率上一版 90%这一版 87%下降了 3 个点按标签的通过率哪一类下降最多新挂的题目清单上一版通过、这一版失败的题逐条列出来这是最该看的新通过的题目说明改动确实修好了什么平均响应时间和调用成本的变化门禁先观察再卡流程很多团队想一步到位「回归通过率低于 90% 就不许上线」。我的建议是别急。刚开始题库小、裁判还没校准好分数本身就有波动这时候强行卡流程只会让开发觉得测试在添乱。比较稳妥的节奏是观察期每次改动自动跑回归出报告但不拦截先看分数波动有多大提醒期分数下降超过一定幅度比如 5 个点自动通知相关人员拦截期题库和裁判都稳定以后再把核心题目设为上线门禁五、落地节奏参考如果你是团队里第一个做这件事的人可以参考这个节奏第 1 周和产品一起梳理 Agent 的核心场景整理 20 道核心题目人工跑一遍、打分形成初版评分标准第 2 周把能自动判断的部分写成规则断言写一个脚本能批量跑题目、出结果表格第 3 周加入模型打分用人工打分结果校准裁判题库扩到 50100 条分出冒烟集和回归集第 4 周接入流水线每次改提示词自动跑冒烟集出对比报告之后持续从线上对话和 bug 里补充题目逐步推进门禁六、几个常见误区误区一追求 100% 通过率。Agent 本身就有不确定性追求 100% 会让你陷入无休止的调提示词。更务实的目标是核心场景稳定通过整体通过率不下降。误区二只测最终回答。过程不对、结果碰巧对的情况非常多一定要检查工具调用。误区三完全信任模型打分。裁判也会犯错必须定期用人工结果校准。误区四题库建完就不管了。业务在变、用户问法在变题库要像用例库一样持续维护。总结搭建 Agent 测试体系其实没有想象中那么玄。评测集就是题库断言就是判卷标准回归就是每次改完考一遍试。真正的难点不在技术而在于把「什么是好回答」这件事想清楚、写下来。从 20 道题开始先跑起来再慢慢完善比一开始设计一个大而全的方案要靠谱得多。 
长河君 · 2026/10/28 1:45:16 · 阅读 1.2k 从 0 到 1 搭建 AI Agent 评测体系：评测集、断言、回归怎么设计
写在前面这两年很多团队都在做 AI Agent智能客服、AI 助教、自动写报告的助手……产品做出来以后测试同学往往会卡在一个问题上这东西到底怎么测传统功能测试的思路是「输入 A预期输出 B对比一下一致就通过」。Agent 不吃这一套。同一个问题问三遍它可能给出三种说法改了一句提示词昨天好好的功能今天就答歪了换个模型版本整体表现可能变好也可能在某个角落悄悄变差。这篇文章不讲高深的算法只讲一个测试团队怎么从零开始把 Agent 的测试搭成一套能持续运转的体系。核心就三件事评测集测什么、断言怎么判断对错、回归改动之后怎么快速知道有没有变坏。先交代一下贯穿全文的例子。假设我们要测一个「课程顾问 Agent」它能做这些事回答课程相关问题适合几岁、一节课多长、怎么上课调用工具查询用户的订单和剩余课时解释退费、请假等政策遇到解决不了的问题转人工一、先想清楚Agent 到底要测哪几层很多人测 Agent 只盯着最后那句回答其实不够。一个 Agent 干活的过程大致是理解问题 → 决定要不要调用工具 → 调用工具拿数据 → 组织语言回答。每一步都可能出错所以建议分三层来看。第一层最终回答对不对。这是用户直接看到的比如信息是否准确、有没有答非所问、语气是否合适。第二层过程对不对。该查订单的时候有没有真的去查查的是不是当前用户的订单参数传对了没有很多时候最终回答看起来没毛病但其实是模型「猜」出来的根本没调用工具这种问题只看回答是发现不了的。第三层底线守没守住。比如不能泄露其他用户信息、不能乱承诺退款、不能被用户一句「忽略之前的规则」就带跑。这一层出一次问题可能就是事故。后面设计评测集和断言都会围绕这三层来展开。二、评测集给 Agent 准备一套「题库」评测集是什么说白了评测集就是一套题库。每道题包含问 Agent 什么、它应该做到什么、不能做什么。以后每次 Agent 有改动就拿这套题库考一遍看分数有没有下降。它和传统的测试用例很像区别在于传统用例的预期结果是一个确定答案评测集的「标准答案」更像是一份评分要点本系列第二篇专门讲了怎么写。第一步别贪多先做 20 条刚开始最容易犯的错误是一上来就想搞几百上千条题目。结果题目质量参差不齐评分标准也没想清楚跑出来一堆分数谁也说不清它代表什么。我的建议是先挑 20 条最核心的场景人工逐条跑、逐条打分。这 20 条的价值在于你会在打分过程中真正搞清楚「什么样的回答算好」评分标准就是这么磨出来的你会发现哪些东西能用规则自动判断哪些必须靠人或者靠模型判断这 20 条人工打过分的结果以后可以用来校验自动评分准不准后面会讲20 条跑顺了再逐步扩到 50 条、100 条。题目从哪里来按优先级排线上真实对话。这是最有价值的来源。用户实际怎么问比测试人员自己想出来的要「野」得多。比如用户不会说「请帮我查询剩余课时」而是说「我还剩几节课啊」「课还有多少」「上次买的那个包用完没」。业务方最关心的高频问题。找产品和运营要一份清单用户最常问什么、哪些问题答错了会被投诉。历史 bug。每修一个 Agent 的问题就把它变成一道题放进题库防止以后又犯。刁钻和恶意的问题。专门用来测底线比如套话、诱导、越权本系列第一篇有展开。一道题长什么样建议每道题至少包含这几个字段用表格或者 JSON 存都可以{id:course_refund_001,标签:[退费政策,高频,核心],对话历史:[],用户输入:我买的课上了3节不想上了能退吗,必须提到的要点:[说明可以申请退费,说明已上课时会扣除,告知申请途径或转人工],应该调用的工具:[查询订单],绝对不能出现:[承诺全额退款,编造具体退款金额]}几个字段的作用标签方便以后按类别统计比如「退费类通过率 95%查课时类只有 70%」一眼就能看出短板在哪对话历史多轮对话场景用把前几轮对话放进去测第 N 轮的表现必须提到的要点注意写的是信息点不是标准原句应该调用的工具用来测第二层过程绝对不能出现用来测第三层底线题库要分层题目多了以后每次全跑一遍又慢又费钱每调一次大模型都要花钱。所以建议分成三套题库规模什么时候跑作用冒烟集1020 条每次改动都跑快速确认主流程没坏回归集100 条左右改提示词、换模型、上线前全面检查有没有退化对抗集3050 条上线前、定期专门测安全和底线三、断言怎么判断 Agent 答得对不对这是整个体系里最关键的部分。我把判断方式分成三种按「能用简单的就不用复杂的」排序。方式一规则断言最便宜、最稳定能用代码直接判断的一律用代码判断。比如回答里是否出现了「全额退款」这类禁止词是否调用了「查询订单」这个工具参数里的用户 ID 对不对要求输出 JSON 的能不能正常解析、字段齐不齐回答长度是否在合理范围响应时间是否超过 10 秒写起来很简单比如defcheck_forbidden_words(answer,forbidden_list):forwordinforbidden_list:ifwordinanswer:returnFalse,f出现禁止内容{word}returnTrue,通过defcheck_tool_called(tool_calls,expected_tool):names[call[name]forcallintool_calls]ifexpected_toolinnames:returnTrue,通过returnFalse,f没有调用{expected_tool}规则断言的优点是结果稳定、不花钱、速度快。缺点是只能判断「表面」的东西。比如「是否说明了已上课时会扣除」用户可能表达成「上过的课要扣掉」「会按实际消耗计算」用关键词很难覆盖全。方式二让大模型当裁判灵活但需要校准对于「意思对不对」这种问题可以让另一个大模型来打分业内一般叫 LLM-as-Judge。做法就是把问题、Agent 的回答、评分要点一起发给裁判模型让它按标准打分。裁判的提示词大概长这样你是一个严格的评分员。请根据评分要点判断客服的回答是否合格。 用户问题{用户输入} 客服回答{Agent 回答} 评分要点每条都要检查 1. 说明可以申请退费 2. 说明已上课时会扣除 3. 告知申请途径或转人工 禁止内容承诺全额退款、编造具体退款金额 请逐条判断每个要点是否满足再检查是否出现禁止内容。 最后按以下格式输出 {要点1: true/false, 要点2: true/false, 要点3: true/false, 出现禁止内容: true/false, 理由: ...}几个实用技巧让它逐条判断不要直接给总分。直接问「这个回答打几分」裁判会很随意逐条检查要点结果会稳定很多。要求输出固定格式。方便代码解析也方便你事后翻看理由。裁判模型尽量用能力强一点的。省在这里后面分数都不可信。最重要的一点裁判本身也要被测。怎么测还记得前面人工打过分的 20 条吗拿裁判去打一遍对比它和人工的结论。如果 20 条里有 18 条一致说明裁判基本靠谱如果只有 12 条一致说明评分提示词还得改。以后改了裁判提示词也要重新跑一遍这个对比。方式三人工抽检最准但最贵再好的自动评分也有漏网之鱼所以要保留人工抽检每次回归随机抽 10% 左右人工看一遍自动评分判为「不通过」的全部人工复核有可能是裁判判错了新增类型的问题前几次都人工看三种方式怎么组合可以想象成一个金字塔底层是大量的规则断言中间是模型打分顶层是少量人工。一道题可以同时用多种断言比如退费那道题规则断言检查是否调用了「查询订单」、是否出现「全额退款」模型打分检查三个要点是否都讲到了人工抽检偶尔看一眼整体语气和体验四、回归改完之后怎么知道有没有变坏什么时候必须跑回归Agent 的「改动」比传统软件多得多下面这些情况都要跑改了系统提示词哪怕只改一句话换了模型或者模型升级了版本新增或修改了工具知识库内容更新了调整了温度等参数尤其是改提示词经常出现「为了修 A 问题加了一句话结果 B 场景崩了」。这正是回归的意义。同一道题要跑多次这是 Agent 测试和传统测试最不一样的地方。因为输出有随机性一道题跑一次通过不代表它稳定通过。建议核心题目每道跑 35 次看通过率。比如跑 5 次通过 5 次说明很稳跑 5 次通过 3 次说明这个场景不稳定需要重点关注哪怕某一次恰好通过了也不能放心。看变化而不是只看绝对分数回归报告最重要的不是「这次得了 87 分」而是和上一个版本比变了什么。建议报告里至少有这几项整体通过率上一版 90%这一版 87%下降了 3 个点按标签的通过率哪一类下降最多新挂的题目清单上一版通过、这一版失败的题逐条列出来这是最该看的新通过的题目说明改动确实修好了什么平均响应时间和调用成本的变化门禁先观察再卡流程很多团队想一步到位「回归通过率低于 90% 就不许上线」。我的建议是别急。刚开始题库小、裁判还没校准好分数本身就有波动这时候强行卡流程只会让开发觉得测试在添乱。比较稳妥的节奏是观察期每次改动自动跑回归出报告但不拦截先看分数波动有多大提醒期分数下降超过一定幅度比如 5 个点自动通知相关人员拦截期题库和裁判都稳定以后再把核心题目设为上线门禁五、落地节奏参考如果你是团队里第一个做这件事的人可以参考这个节奏第 1 周和产品一起梳理 Agent 的核心场景整理 20 道核心题目人工跑一遍、打分形成初版评分标准第 2 周把能自动判断的部分写成规则断言写一个脚本能批量跑题目、出结果表格第 3 周加入模型打分用人工打分结果校准裁判题库扩到 50100 条分出冒烟集和回归集第 4 周接入流水线每次改提示词自动跑冒烟集出对比报告之后持续从线上对话和 bug 里补充题目逐步推进门禁六、几个常见误区误区一追求 100% 通过率。Agent 本身就有不确定性追求 100% 会让你陷入无休止的调提示词。更务实的目标是核心场景稳定通过整体通过率不下降。误区二只测最终回答。过程不对、结果碰巧对的情况非常多一定要检查工具调用。误区三完全信任模型打分。裁判也会犯错必须定期用人工结果校准。误区四题库建完就不管了。业务在变、用户问法在变题库要像用例库一样持续维护。总结搭建 Agent 测试体系其实没有想象中那么玄。评测集就是题库断言就是判卷标准回归就是每次改完考一遍试。真正的难点不在技术而在于把「什么是好回答」这件事想清楚、写下来。从 20 道题开始先跑起来再慢慢完善比一开始设计一个大而全的方案要靠谱得多。