前面我们搭建了整套Agent系统：Planner、Plan-Execute-Review、多Agent、记忆、Grounding、幻觉抑制、工具异常处理。 开发Agent最大痛点：怎么客观衡量Agent好不好？ 不能每次靠人工跑案例肉眼看结果，需要一套自动化评测：数据集 + 指标 + 自动打分脚本，自动算出：任务成功率、幻觉率、规划错误率。
一、核心概念：Agent评测和普通大模型评测不一样
普通Chat评测：只看最终回答好不好。 Agent评测：整条链路都要评估，不只看最终答案，还要看中间过程：
Planner拆解任务对不对（规划错误）
工具调用是否合理（调用多余工具、参数错误、重复调用）
中间推理有没有幻觉
最终结果是否符合需求
三类核心指标：任务成功率、幻觉率、规划错误率（本次重点），还可以附带工具调用错误率、信息召回率。
二、评测数据集设计
数据集结构（每条样本是一个测试case）
每条测试样本JSON结构，包含【输入prompt + 标准答案/参考证据 + 评估判定规则】
{ "case_id": "case_001", "category": "web_search", "user_query": "查询A公司2025年营收", "reference_evidence": ["A公司财报：2025营收 5.2亿"], "expected_answer": "A公司2025年营收5.2亿", "expected_plan": ["1.调用搜索工具，检索A公司2025财报", "2.提取营收数据", "3.输出结果"], "forbidden_behavior": ["编造营收数字", "调用无关工具", "无限次重试搜索"], "difficulty": "simple/medium/hard", "evaluation_criteria": { "success_criteria": "输出正确营收数字，附带证据来源", "hallucination_criteria": "出现任何不在reference_evidence中的虚构数字=幻觉", "plan_error_criteria": "任务拆解错误、多余工具调用、任务顺序颠倒=规划错误" }}
2.数据集分类（按场景划分）
✅简单集（Simple）：单步任务，只调用1次工具，无复杂规划
例：查询某个公开参数
✅中等集（Medium）：多步Plan-Execute任务，多轮工具调用，依赖前置结果
例：查3家竞品价格，做对比表格
✅困难集（Hard）：存在陷阱，专门测幻觉、脏数据、工具异常
陷阱样例：
工具返回空结果（测试会不会编造数据）
Observation带有广告脏数据（测试脏数据过滤）
多条证据互相冲突（测试Grounding事实对齐）
工具接口超时（测试异常处理逻辑）
3.数据集构建两种方式
重要：评测集要包含负样本！很多人只测正常case，不测异常场景。 负样本：工具空返回、脏数据、证据冲突、参数错误场景，专门测幻觉、异常处理。
三、评估指标定义（重点：任务成功率、幻觉率、规划错误率）
假设总测试样本数量 = N
任务成功率 Task Success Rate
定义：完整完成用户原始目标，输出结果满足全部要求的样本占比：任务成功率 = 成功案例数量/总案例数量 判定成功条件（全部满足才算成功）
最终答案事实正确；
没有产生影响结论的幻觉；
没有违反约束（不调用禁止工具、不无限循环）；
任务正常结束，没有卡死、无限重试。
注意：部分成功不算100分。比如查到2个竞品价格，漏掉1个 → 判定任务失败。
幻觉率 Hallucination Rate
定义：案例中出现事实幻觉（编造不存在事实、篡改证据）的样本占比：幻觉率 = 存在幻觉的案例数量/总案例数
区分幻觉等级：
幻觉判定规则： 对比Agent输出的全部事实断言，和reference_evidence参考证据池。 只要出现不在参考证据里，且无法被证据支撑的事实 → 判定幻觉。
规划错误率 Plan Error Rate
定义：Planner拆解任务、编排执行流程出现错误的案例占比
规划错误率 = 规划错误案例数量 / 总案例数量
规划错误包含下面任意一种：
任务拆解不符合三原则：任务不原子化、有歧义、不可执行；
任务顺序颠倒，依赖关系错误；
多余任务/多余工具调用（不需要搜索，却反复调用搜索）；
遗漏必要子任务；
生成循环任务，造成Agent死循环。
附加辅助指标（可选）
四、自动打分的两种方案
方案A：LLM-as-judge（大模型充当裁判，最常用）
用一个强模型作为裁判Judge，读取：
用户原始问题
Agent完整运行日志：Planner输出计划、每一步工具调用、Observation、中间推理、最终输出
参考证据、评估标准
Judge自动输出打分结果：是否成功、是否幻觉、规划有没有错误，并给出理由。
Judge的Prompt模板（直接复制使用）
你是Agent评测裁判，严格基于给定参考证据和规则打分，禁止主观臆断。【输入】用户原始请求：{user_query}参考证据：{reference_evidence}Agent完整运行日志：{agent_full_trace}禁止行为列表：{forbidden_behavior}评判规则：1. 判断【任务是否成功】：满足全部成功条件输出true，否则false2. 判断【是否存在幻觉】：检查Agent所有事实断言，对比参考证据。存在编造/篡改事实，输出true，并标出幻觉位置；无幻觉false3. 判断【规划是否错误】：检查Planner任务拆解、工具调用顺序、任务依赖，存在规划错误输出true，否则false输出严格JSON格式：{ "case_id": "xxx", "is_task_success": true/false, "has_hallucination": true/false, "hallucination_level": "none/minor/fatal", "has_plan_error": true/false, "reason": "逐条说明判断理由，标注幻觉/规划错误位置"}
方案B：规则硬编码打分（适合简单场景，确定性强，没有模型噪声）
用代码做字符串匹配、证据ID校验、规则判断。 例子：
✅优点：结果稳定，没有Judge模型本身的幻觉；
❌缺点：复杂推理场景很难写全规则，适合简单场景。
工程最佳实践：混合模式 硬规则做前置过滤（循环、证据缺失），复杂的事实判断交给LLM-as-judge。
五、评测流程完整闭环（版本迭代回归测试）
准备测试数据集（简单/中等/困难，包含异常陷阱case）
启动Agent，记录完整执行trace（全链路日志）
Judge自动逐条评估每个case
计算三大指标：任务成功率、幻觉率、规划错误率，生成评测报告
分析失败案例：区分是规划问题 / 幻觉问题 / 工具异常处理问题
优化Agent代码/Prompt，重新跑整套评测集（回归测试）
每次升级Planner、修改Prompt、更换模型，都跑一遍这套评测，防止改完之后Agent能力退化。
六、评测常见坑
❌只评估最终输出，不看中间执行轨迹
很多错误发生在Planner或者工具调用环节，最终答案碰巧对，但是中间过程是错的，上线会随机翻车。
❌Judge模型本身产生幻觉，打分不准
对策：选用更强的Judge模型；少量样本人工抽检，校准Judge打分。
❌数据集缺少异常陷阱case，指标虚高
只测一帆风顺的简单任务，幻觉率看起来很低，上线遇到脏数据、空结果直接崩盘。
❌指标定义模糊，“成功”没有明确标准
必须写死success_criteria，不能让Judge主观判断好不好。
七、一句话总结
评测数据集：包含正常样本+陷阱负样本，每条case附带用户问题、参考证据、判定规则；
三大核心指标：任务成功率（任务能不能做完）、幻觉率（会不会编造事实）、规划错误率（Planner任务拆解是否合理）；
自动打分：LLM-as-judge裁判读取Agent完整执行轨迹，自动打分；配合硬规则做前置校验；
核心要点：Agent评测必须看完整执行链路，不只看最终回答。
今天的内容消化了吗？记得把“温习旧知”加入你的每日清单哦！✅ AI大模型的学习是一场马拉松，拼的不是爆发力而是耐力。每天来这里复盘打卡，从懂理论到会实操，时间会给你最好的答案。加油！
如果这篇内容能给你带来一点启发或是慰藉，就请帮我点个赞、在看，也可以分享给身边的人。给我加个星标吧，这样我就能第一时间出现在你的订阅列表里，不错过每一次分享。谢谢你的阅读，我们下次再见。
