大家好，我是玄姐。
PS：
AI 工程落地干货直播，欢迎点击预约，直播见。
"用户说 Agent 答非所问，但到底是哪里出了问题？" "改了代码重新上线，结果旧 bug 修好了，新问题又冒出来了。" "评测集跑分挺高，一到真实环境就拉胯……"
如果你也在做 AI Agent 的落地，上面这些灵魂拷问一定不陌生。我们团队最近在支撑商品中心智能答疑 Agent 的迭代时，也踩了同样的坑。一开始，我们像大多数团队一样，写几个测试用例，跑一遍端到端，看看最终答案对不对，评分差不多就上线了。直到有一次，两个版本的 Agent 综合评分只差 2%，但上线后用户投诉量却差了 3 倍。我们翻遍日志才发现：A 版本在"意图识别"环节悄悄退化，把大量本该走 Skill 链路的问题错误路由到了知识库；B 版本虽然总分低一点，但每个模块表现稳定，实际体验反而更好。这件事让我们意识到：粗粒度的"通过/不通过"，已经撑不起业务快速迭代的需要了。我们需要知道 Agent 在哪个环节、因为什么问题、以多大的概率出错。这篇文章，就完整分享我们构建这套 Agent 精细化评测体系的设计思考与工程实践。从指标体系、数据集构建、自动化评测到可视化看板，全部可落地、可复用。PS：
AI 评估更多案例深入免费学习去这里：
1.打开 AITutor 新一代 AI 原生学习伙伴：www.aiaitutor.com 2.在首页输入"AI 评估” 就能看到更详细更丰富案例。3.包含了图文、视频、播客、闪卡、代码、测验等9种学习模态。
一、为什么传统评测方法在 Agent 时代失效了？
1.1 从"文本生成"到"多步决策"：评测对象变了
在传统的 NLP 时代，BLEU、ROUGE 这些指标够用了，机器翻译嘛，看译文和参考译文像不像就行。但 Agent 不是"标准答案生成器"，它是一个"理解意图 → 做出决策 → 调用工具 → 完成任务"的多步骤自主决策系统。它的输出不是一段孤立的文本，而是一整套行为链路的最终结果。只对比最终答案，等于把 Agent 当成黑盒。你根本发现不了它是否走了弯路，比如是否做了冗余的工具调用、是否在某个关键步骤出现了偏差但最终"蒙对了"答案。1.2 六个让传统评测"失灵"的真实场景
我们复盘了团队早期的评测工作，发现当时只关注最终答案质量、用 LLM 给文本相似度打分的做法，至少存在六个致命伤： | | |
|---|
| 两个版本综合评分相近，但差异来自"某环节提升、另一环节退化"还是"均匀波动"，完全不知道 | |
| 文本相似度指标给"看似合理但实际编造"的答案打高分 | |
| | |
| 两个 Agent 输出同样质量，但一个调用 3 次工具、耗时 2 秒，另一个调用 15 次、耗时 15 秒 | |
| | |
| 评测集是人工构造的"干净"问题，用户输入充满歧义和口语化 | |
一句话总结：传统评测只能告诉你"车能不能从 A 开到 B"，但车坏了你根本不知道修发动机还是换轮胎。二、评测体系总览：把车架上升降台，逐模块体检
2.1 先认识你的 Agent：四大核心模块
在设计评测之前，必须先理解被测对象的内部结构。我们的商品中心 Agent 由四个核心模块协作运行：负责接收用户输入，判断问题是否可被已注册的 Skill 直接处理，实现语义理解和意图识别。未命中时自动降级至知识库检索。基于感知结果制定执行策略，决定是否需要调用工具、是否检索知识库、如何存储记忆等。实现 Skill 场景与 RAG 场景的自动分流。短期记忆基于会话 ID 维护多轮对话上下文（滑动窗口截取最近 N 轮）；长期记忆对接 RAG 知识库，将检索结果注入 Prompt。通过 MCP 协议自动发现并注册远程工具，同时基于文件系统管理 Skill，两类工具统一封装为标准回调接口，由 Agent 按需调度。2.2 黑盒 vs 白盒：为什么必须拆到模块级？
假设你的 Agent 任务完成率从 85% 掉到了 60%，端到端评测只能告诉你"车坏了"，但模块级评测能定位到：- 感知模块：把"查 Trace"错误识别为知识库问答（意图识别错误）
- 规划模块：该调用 Skills 时选择了 RAG 检索（路由决策错误）
- 记忆模块：多轮对话中丢失了上一轮提到的商品 ID（记忆丢失错误）
- 工具模块：错误调用了 MCP 或工具参数填充错误（工具调用错误）
端到端评测定义了"好车"的标准，模块级评测提供了"把车修好"的路径。两者相辅相成，缺一不可。2.3 三个维度：质量 × 成本 × 性能
一个"回答正确但耗时 30 秒"的 Agent 不是好 Agent；一个"回答正确但每次消耗 10 万 Token"的 Agent 不可持续。- 答案好不好？（质量维度：正确性、完整性、忠实性、幻觉检测）
- 成本高不高？（成本维度：模型调用次数、工具调用次数、Token 消耗量）
- 速度快不快？（性能维度：首 Token 延迟、端到端响应时间）
只追求质量，可能在成本和延迟上失控；只优化速度，可能在复杂问题上过于简化；只看成本，可能导致准确率断崖式下跌。健康的 Agent 是三个维度在当前业务场景下的最优平衡。三、指标体系设计：从北极星指标到模块级诊断
3.1 端到端：用户最能感知的六项指标
回答一个最基本的问题：Agent 是否成功完成了用户请求的任务？判断标准是语义层面的完成度，不要求字面匹配，但核心信息不能缺失。例如，用户问"商品为什么不可售"，Agent 只要正确输出了不可售原因的诊断分析即为通过，不要求措辞与标准答案完全一致。
评估 Agent 在 2-5 轮对话中能否持续理解意图、维持上下文连贯并最终完成任务。需要对整组对话做整体评判，而非逐轮独立打分。关注形式正确性。某些 Skill 对回复格式有明确约束，需要分模块输出、包含特定分析维度、表格化呈现。衡量 Agent 是否按业务约束的格式回答。判断 Agent 是否忠实于知识库片段、工具返回的原始数据以及历史上下文，是否存在"无中生有"或"擅自篡改"。重要边界划定：我们只判断 Agent 有没有"忠实转述"，不判断信息来源本身对不对。知识库错了是知识库的问题，Agent 如实反映了它所看到的内容，即使与客观事实不符，也判定为忠实。
合理归纳总结、基于上下文的解释性补充 → 忠实；凭空捏造具体接口名/函数名/配置项、给出与检索结果直接矛盾的核心信息 → 幻觉。
面对空输入、超长文本、乱码、特殊字符注入甚至 Prompt 注入攻击，Agent 是否能优雅降级，返回合理引导提示而非崩溃或乱答。依赖线上反馈收集评分，用于校准评测盲区，为优化动作指明方向。3.2 感知模块：Agent 看懂了没有？
- 精确率：识别为 Skill 的请求真的可以由 Skill 处理吗？
用户一句话混合多个意图，"帮我查一下这个商品为什么不可售，顺便分析一下错误码 F_IC_SERVICE_QUERY_020 是什么意思"，Agent 能否完整拆解？面对"帮我看一下这个商品怎么回事"这类模糊问题，合理行为是主动追问澄清，或基于合理推断给出有价值的回答；不合理行为是答非所问或产生幻觉。当问题超出所有 Skill 范围时，是否正确触发知识库检索兜底，而非强行路由到不匹配的 Skill？3.3 规划模块：Agent 想对了没有？
在"调用 Skill"和"检索知识库"之间做出正确选择。错误的路由决策会导致后续执行环节偏离正轨。决定调用工具时，是否选对了工具种类？该调 Trace 分析工具还是错误码查询工具？问题不属于任何 Skill 时，是否正确触发了知识库检索？通过人工评估 Agent 选择的执行路径是否最优，需要领域专家介入评判。3.4 记忆模块：Agent 记住了没有？
评估多轮对话中的上下文连贯性。当用户在第三轮说"这个商品"时，是否还记得第一轮提到的商品 ID？判断标准强调语义连贯性而非字面匹配，Agent 无需逐字复述历史实体名，只要回复在语义上延续了前文主题和约束即可。
检索回来的内容中，有多少与用户问题真正相关？直接回答问题的核心内容当然相关，提供理解所需的背景上下文（如概念定义、表结构说明）同样视为相关。知识库中应该被检索到的知识点，在 Agent 最终回复中覆盖了多少？需要预先标注"应检索到的知识点列表"。直观揭示 Agent 记忆的"保质期"。在 2、3、5 轮分别插入需引用历史信息的问题，统计各轮记忆保留率。3.5 工具模块：Agent 做对了没有？
Agent 启动或运行时，外部服务能否正确初始化并接入？这是工具调用的"前置条件"。是否正确将用户意图映射为工具调用参数？用户说"查一下商品 1005007651467330 在韩国的可售状态"，传给工具的商品 id 参数是否正确？3.6 成本与性能指标
成本指标：平均模型调用次数、平均工具调用次数、平均输入/输出 Token 数（通过系统埋点自动采集）。- 端到端：首 Token 延迟（决定用户"等待焦虑感"）、端到端响应延迟
- 模块级：意图识别延迟、规划决策延迟、记忆注入/检索延迟、工具调用延迟、热更新生效延迟（精确定位性能瓶颈）
四、评测数据集：不是"造几道题"那么简单
4.1 八类评测集，覆盖真实业务场景
我们结合真实业务场景构造了 8 类评测集，形成"基础覆盖 + 专项探测"的分层结构： | | | |
|---|
| 按 Skill 维度构造，实时性场景通过 Mock 隔离外部依赖 | | |
| | | |
| 构造 2-5 轮对话链，覆盖上下文引用、话题切换、指代消解 | | |
| 空输入、超长文本、乱码、特殊字符、Prompt 注入 | | |
| | | |
| | | |
| | | |
| | | |
4.2 评测用例的"豪华配置"
一条好的评测用例远不止"输入 + 期望输出"。我们为每条用例设计了丰富的标注字段，使一条数据可以同时供多个 Judge Task 使用，最大化数据利用率。{ "id": "BF-TRACE-001", "sceneCode": "i18n-ic-trace-analyzer", "userInput": "traceId：2116440e17706430209582423d0733", "expectedSkill": "i18n-ic-trace-analyzer", // → 意图准确率 "expectedRoute": "SKILL_HIT", // → 路由决策准确率 "expectedIntent": "i18n-ic-trace-analyzer", // → 意图召回率/精确率 "evalMode": "E2E_MOCK", // Mock 模式 "mockDataId": "MOCK-TRACE-001", // 关联 Mock 数据 "referenceOutput": "Agent应调用trace分析工具..." // 参考输出}
- E2E_MOCK（Mock 模式）：通过 mockDataId 关联预置的 Mock 数据，Agent 运行时注入 Mock 替代真实工具调用。适用于 Trace 排查、可售性分析等依赖外部工具的实时性分析场景，确保评测结果可复现、不受商品状态影响。
- E2E_REAL（真实模式）：不注入 Mock，Agent 直接调用真实服务。适用于不依赖实时性分析的 Skill 评测和知识问答评测，Mock 反而会失去评测意义。
{ "id": "KQA-BASE-001", "userInput": "商品和SKU有什么区别？请举例说明。", "referenceOutput": "商品（Product/Item）是指可以在平台上销售的实体或服务...", "expectedSkill": null, // 期望不命中任何 Skill "expectedRoute": "SKILL_MISS", // 期望路由到知识库 "expectedIntent": "knowledge_qa", "expectedKnowledge": [ // 期望检索到的知识点 "商品（Product/Item）是指可以在平台上销售的实体或服务...", "SKU（Stock Keeping Unit，库存量单位）是商品的最小销售单元..." ], "evalMode": "E2E_REAL"}
{ "id": "KQA-NEG-004", "userInput": "IC的deleteAllProducts接口怎么调用？需要传哪些参数？", "referenceOutput": "IC中不存在deleteAllProducts接口，应明确告知未找到该接口的相关信息。", "expectedSkill": null, "expectedRoute": "SKILL_MISS", "expectedKnowledge": [] // 没有应检索到的知识点}
deleteAllProducts 这个接口名看起来完全符合 IC 的命名风格，Agent 很容易基于已有的接口知识"推理"出一个看似合理但完全虚构的回答。这正是幻觉率检测要捕捉的问题。
{ "id": "MT-001", "userInput": "商品1005007651467330在韩国不可售是什么原因", "evalMode": "E2E_MOCK", "mockDataId": "MOCK-MT-001", "conversationChain": [ { "turnNumber": 1, "userInput": "商品1005007651467330在韩国不可售是什么原因", "expectedContains": ["不可售", "sale_country_rule"] }, { "turnNumber": 2, "userInput": "sale_country_rule和visible_country_rule有什么区别？", "expectedContains": ["可售", "可见", "黑名单", "白名单"] }, { "turnNumber": 3, "userInput": "黑名单模式和白名单模式分别是怎么生效的？", "expectedContains": ["黑名单", "白名单"] } ]}
4.3 LLM 自动生成评测集：从"手搓"到"半自动"
手工编写数百条测试用例效率低且覆盖不足。我们实现了从知识文档到评测用例的自动生成：输入一篇语雀文档 URL 和目标数据集类型，系统会根据特定的 Prompt 模板和文档内容，自动生成符合标注规范的结构化测试用例。例如指定KNOWLEDGE_QA类型，生成器会自动产出包含expectedKnowledge的用例。工作流：LLM 生成 → 人工审核 → 入库。在保证质量的前提下，构建效率提升了数倍。五、Judge Task 设计：让大模型当"靠谱裁判"
面对若干指标、数百条用例的评测规模，人工评测不可持续。传统规则匹配（关键词、正则）又无法处理语义等价，"商品下架对应的事件标识"和"product-downshelf 消息类型"语义完全等价，但关键词匹配会判定为不一致。我们采用 LLM-as-Judge 作为核心自动化评测手段。但要让 LLM 成为可靠的裁判，需要面向指标类型设计特定的评测任务和提示词。5.1 四条 Prompt 设计原则
一个 Prompt 只评测一个指标。我们曾尝试在一个 Prompt 中同时判断任务完成率和忠实性，结果两项指标的准确率都下降了，多任务混合会增加 LLM 的理解负担。每个 Prompt 都要求 LLM 先输出reasoning（思维链推理），再给出结论。这不仅提高了判断准确性，也让评测结果具备可解释性，Judge 不通过时，你能看到它的推理依据。每个 Prompt 都包含典型的"通过"和"不通过"示例。例如任务完成率的 Prompt 中会给出对比：用户问"商品 XXX 不可售原因"，Agent 输出具体不可售原因分析 → 通过；Agent 回答了商品基础信息但未分析不可售原因 → 不通过。所有 Judge 的输出都要求严格的 JSON 格式，便于自动化解析和指标计算。在 Prompt 末尾明确给出输出格式模板，是确保 LLM 输出可解析的关键。5.2 主指标策略：别让"格式不对"否定一个"内容正确"的回答
一种常见做法是把所有 Judge Task 的结果做 AND 运算，全部通过才算通过。但这不合理：一个知识问答场景，Agent 准确回答了"商品不可售原因"，内容完整、结论正确，但回复格式没有严格按照参考输出的分段结构，指令遵循判定为不通过。如果因为格式问题否定内容正确的回答，评测结果的真实性将严重偏离。
我们的做法：为每种评测场景设定一个"主指标"，只看这一个指标决定 case 是否通过。其他指标不影响最终通过判定，而是作为质量维度单独衡量，用于定位具体的能力短板。5.3 一个关键细节：路由错误时，下游指标应当跳过
假设一条知识问答用例，期望路由是SKILL_MISS（走知识库检索），但 Agent 误将其路由到了某个 Skill。此时：- 幻觉率：需要拿回复与知识库原文对照，但没有知识库原文
- 长期记忆检索精确率/召回率：需要统计返回的 chunk，但没有返回任何 chunk
如果仍然执行评测，这三项指标都会因为路由错误而被判定为不通过。但它们衡量的是回答生成和知识库检索的能力，它们本身没有出错，只是根本没有被执行的机会。解决方案：在每个依赖 RAG 数据的 Judge Task 执行前，先检测是否存在路由误触发。一旦检测到，相关的下游 Judge Task 自动标记为error并跳过统计，不计入分子也不计入分母。这样做的效果是：路由错误只会体现在路由决策准确率这一项指标上，而幻觉率、检索精确率/召回率只反映模块本身的能力，不会被上游错误污染。每项指标各司其职，一个模块的错误不会雪崩式拖垮其他模块的数据。六、评测执行引擎：从"跑一遍"到"工程化流水线"
6.1 完整执行链路
- 提交评测请求：指定评测范围（datasetType + evalMode）
- 自动装配数据集：根据评测范围加载用例，无需人工逐个对接
- 并发执行：单条超时 120s，失败自动重试至多 2 次
- 构造输入：注入 sessionId、Mock 数据
- 调用 Agent 完整链路：感知 → 规划 → 记忆 → 工具 → 生成
- 采集 EvalTrace：覆盖各模块和 RAG 检索、模型消耗等维度
- 生成评测报告：输出质量 × 成本 × 性能三大类指标
6.2 15 种评测范围，一键切换
我们设计了 15 种评测范围，覆盖从单个数据集到全模块评测的各个粒度：- 端到端评测：组合基础技能、知识问答、多轮对话、异常输入
- 分模块评测（4 种）：例如感知模块加载基础技能、知识问答、多意图、模糊意图
评测范围一变，数据集和埋点指标自动跟着调整，通过"选择评测范围 → 自动装配数据集 → 自动筛选对应指标"，使评测过程简单而灵活。6.3 无侵入的 Trace 采集：如何不改动业务代码就能拿到中间指标？
核心挑战：如何在 Agent 执行过程中采集中间指标，而不侵入业务逻辑？我们设计了一个轻量级的 Trace 数据结构，随 Agent 处理链路一起流转。各节点完成工作后，将关键信息写入 Trace：- 感知节点：是否命中 Skill、实际命中 Skill 名称、意图类型、识别耗时
- 工具节点：工具调用记录（工具名、参数、是否成功、耗时）
Agent 执行完毕后，Trace 和最终输出一起交给 Judge。Judge 不仅参考输出文本，还会利用 Trace 中的中间数据，例如"Agent 是否确实调用了某个工具"不需要从回复文本中推断，直接看 Trace 记录即可。6.4 多轮对话评测的特殊处理
多轮对话是评测中最复杂的场景，需要处理三个特殊问题：会话上下文共享：每组多轮对话生成独立的 session 标识符，各轮次共享同一个标识符，确保 Agent 能读到完整对话历史。轮次间同步：每轮执行完毕后等待会话持久化完成（通常 2 秒），再发起下一轮。否则下一轮可能读不到上一轮历史，导致误判 Agent 不具备记忆能力。整体评判：所有轮次输出拼接后统一交给 Judge 评估，而非逐轮独立评判。第一轮正确但第三轮失忆，整组对话应判为失败。6.5 两种互补的评测模式
Agent 走完整线上链路，包括真实的 LLM 调用、工具调用和知识库检索。能真实反映生产环境表现，但结果会受外部依赖抖动影响（工具超时、知识库更新、LLM 随机性）。注入预设的工具调用返回值，Agent 的推理和决策仍然是真实的，但工具调用结果固定。消除外部依赖的不确定性，保证评测结果可复现。- Mock 模式：Trace 排查、可售性分析、标签分析等依赖外部工具的实时性分析场景
- Real 模式：错误码查询等不依赖实时性分析的 Skill 评测、知识问答类评测
6.6 重试与容错策略
- 执行异常（超时、网络错误）：最多重试 2 次，间隔 3 秒
- 评估失败（Judge 判定不通过）：不重试，这是 Agent 能力问题
- 超时保护：单条用例 120 秒超时，防止单个异常用例阻塞整批评测
6.7 并行执行与异步管理
- 并发度：3 线程并行（在评测效率和 LLM API 限流之间权衡）
- 异步模式：客户端提交评测请求立即获得 taskId，后台异步执行，客户端轮询查询进度，支持运行中取消任务
七、可视化看板：让评测结果"一眼看懂"
我们构建了一个轻量级评测看板，核心理念是"选择评测范围 → 自动装配数据集 → 自动筛选对应指标"。7.1 看板核心能力
- 数据集栏：8 种评测数据集（基础技能、知识库问答、多轮对话、工具调用、多意图、模糊意图、异常输入、长对话衰减）
- 评测模式栏：端到端、核心模块、感知模块、规划模块、记忆模块、工具模块、全量评测
选择"感知模块评测"后，看板自动加载意图识别准确率、召回率、精确率、多意图识别率、模糊意图澄清率、降级触发准确率等指标，以及对应的埋点数据（意图识别延迟）。支持多版本 Agent 的指标趋势对比，直观展示每次迭代各模块的能力变化。八、写在最后：评测不是"考试"，是"体检"
回顾这套评测体系的构建过程，我们有三个核心体会想分享：第一，评测面向架构。Agent 由感知、规划、记忆、工具四大模块组成，评测也应按同样的结构逐层拆解，让每一层的质量都可独立观测。黑盒测试只能告诉你"车能不能开"，白盒诊断才能告诉你"发动机有没有问题"。第二，指标面向行动。每一项指标都是一份"诊断报告"而非"成绩单"。它的价值不在于给出多高的分数，而在于下降时能够精准告诉开发者：是该修改 Skills、替换 MCP 工具、还是优化知识检索。第三，能力面向产品。评测不应是上线前跑一次就扔掉的一次性脚本，而应是像监控告警一样能够可持续运行、可横向对比、可追溯演进的基础设施。Agent 技术还在快速演进，评测体系也没有"标准答案"。但我们相信，只有当你能精准度量 Agent 的每个环节时，你才能真正驾驭它，而不是被它牵着鼻子走。
送个福利：
新一代 AI 原生学习伙伴 AITutor「www.aiaitutor.com」，重构学习方式，AI 驱动个性化精准成长，体系化学习+真实案例，塑造 AI 实战能力。快来免费体验吧。
PS：
AI 工程落地干货直播，欢迎点击预约，直播见。
—8—
加我微信
扫码加我👇有很多不方便公开发公众号的我会直接分享在朋友圈，欢迎你扫码加我个人微信来看👇
加星标★，不错过每一次更新！
⬇戳”阅读原文“，立即预约
