手头正在做 Agent 项目的朋友大概率都有过这种体验功能跑通了、demo 演示很顺但一放到真实场景就状况百出——该调工具的时候没调、调了错误的参数、绕了两圈又回到原点、甚至在某一步直接开始胡说八道。这时候你会意识到一个问题Agent 到底行不行光靠试一下根本说不清楚。你需要一套系统化的评测方案。这篇东西我会把 Agent 评测这件事讲透分成三个核心问题来拆评什么评测对象和维度边界、怎么评评测集构建、指标设计、评估方法、怎么落地评测基建、回归门禁、成本控制。面向的是已经上手过 LangChain、Dify、CrewAI 或自己从零搭过 Agent 的开发者也适合准备搭 Agent 评测体系但还没想清楚从哪入手的团队。全文没有空泛的方法论尽量给可以直接抄的实践方案和参数配置。1. 评什么先把评测对象和边界圈清楚评测的前提是搞清楚被测对象。Agent 和普通软件完全不同——普通软件是确定性行为输入输出可预期Agent 是模型推理 工具调用 自主决策的组合体行为是概率性的、多路径的。所以第一步不是急着选指标而是先回答我在评测什么东西。1.1 评测对象的四种典型形态我把常见 Agent 项目分成四种形态评法完全不同混在一起评测必然失真单轮任务型 Agent用户给一个明确指令Agent 执行一次工具调用并返回结果。典型场景是帮我查一下明天北京的天气。这种评测核心是工具调用准确率和结果格式正确性评测成本最低。多步骤规划型 Agent任务需要拆解成多个子步骤Agent 自行规划执行顺序。典型场景是帮我订一张周五去上海的高铁票顺便预订火车站附近的酒店。这类要重点评测规划质量和步骤衔接能力。多 Agent 协作型 Agent多个子 Agent 分工协作有主控 Agent 负责调度。典型场景是客服系统里售前、售后、技术支持三个 Agent 协同处理一个复杂工单。评测重点关注任务分解、信息传递和结果汇总结论。特定技能型 Agent针对某一类专业能力的深度优化比如代码生成 Agent类似 Claude Agent Skills 这类、数据分析 Agent、自动化操作 Agent。评测就要围绕该技能栈设计专用样例。边界要清晰不要评测大模型本身的能力那是模型评测的范畴不要评测 Prompt 单轮问答的质量那是 Prompt 工程的事。Agent 评测一定是以端到端行为结果为准——任务有没有完成、过程是否高效、工具用得对不对、边界有没有守住。1.2 核心评测维度的七个方向基于一线项目的实践经验Agent 评测至少覆盖七个维度。每个维度都要有明确的量化方式否则没法纳入回归体系。评测维度核心问题量化方式权重建议任务完成率最终结果是否达成用户目标成功数 / 总任务数30%工具调用准确性选对工具、传对参数、正确解析返回目标工具命中率、参数准确率20%规划与推理质量步骤顺序是否合理、有无冗余或遗漏平均步数、冗余步骤率15%记忆一致性多轮对话中是否记住关键信息、不自我矛盾关键信息保留率、矛盾次数10%安全与合规是否泄露敏感信息、是否执行越权操作、是否被指令注入安全事件数一票否决制10%Token 与效率完成任务消耗的 token 数量和耗时单任务平均 token、单步耗时10%鲁棒性同一任务多次运行的稳定性结果方差、失败概率5%权重按业务场景浮动。如果做的是客服 Agent任务完成率和安全合规可以提到 40% 和 20%如果是内部效率工具的自动化 Agent工具调用准确率权重最高。任务完成率的定义最坑很多人把Agent 给了个回答就算成功这是错的。成功标准必须是用户可验收的结果。拿订票场景举例Agent 说已为你预订成功不算完成得核实票务系统里真实生成了订单记录、乘客信息正确、支付状态符合预期这才算一次真正的成功。1.3 分清评测与 Benchmark 的区别不少刚接触 Agent 评测的人会拿现成的 LLM Benchmarks 来测 Agent这是最典型的误区。LLM Benchmark比如 MMLU、GSM8K评价的是模型的知识储备和推理能力而 Agent 评测评价的是在开放环境下与工具、数据、外部系统的交互能力。你无法通过让 Agent 做几道数学题来判断它能不能正确读取 PDF 并用 API 完成数据汇总。用生活化的例子类比你考驾照的时候交规笔试考的是知识对应 Benchmark但真正决定你能不能上路的是路考——倒车入库、变道超车、应对突发状况对应 Agent 评测。只考笔试不路考上路必出事故。所以本手册的全部内容都是围绕路考来设计的。2. 怎么评评测集构建与评估方法明确了评什么接下来是核心工程环节评测集从哪来、指标怎么算、用什么方式判对错。这一章是实操密度最高的部分建议直接照着做。2.1 评测集的三个来源与构建顺序评测集是整个评测体系的灵魂。评测集质量差后面所有指标都是空中楼阁。我按优先级排序给出三个来源第一优先从真实日志里挖 Bad Case。这是最宝贵的评测素材。生产环境 Agent 跑出来的失败案例包含真实用户意图、真实的上下文、真实的环境状态。每周从日志里捞一次失败案例转成评测用例。比如用户问帮我取消今天下午的会议Agent 错误地取消了明天的会议——这个案例就直接进评测集。真实案例的价值在于评测集覆盖的是用户实际在问什么而不是我们想象中用户会问什么。第二优先LLM 辅助合成多样性用例。在真实案例基础上用 LLM 改写生成变体补充边界场景。比如把取消今天下午的会议改写为把今天下午三点和四点的会都挪到明天上午如果下午的会和客户拜访冲突了优先保住客户拜访。这个阶段可以使用 GPT 级别的模型做改写但每一条都要人工校验——LLM 生成的评测用例经常自己就有逻辑漏洞直接进评测集等于引狼入室。第三优先人工编写 Golden Cases。针对核心业务逻辑和最容易出错的场景必须由人手工编写标准样例。比如金融场景里关于金额、期限、利率的表述人工写能确保精确性。这类用例数量不用多精品 100~200 条就够但质量和覆盖度要求极高。评测集需要做分层管理。我习惯把用例分成三个等级P0核心业务链路用例必须全部通过、P1重要但允许部分失败设定阈值、P2边缘和探索性用例用于发现新问题。三个等级对应不同的回归频率和门禁标准。2.2 评测集标注决定评测结果可解释性的关键一步每一条评测用例至少包含五个字段- id: CASE-0001 类型: 多步骤规划型 难度: 困难 场景: 差旅预订 用户输入: 帮我订周五去上海的高铁票到虹桥站下午三点前到然后订一家离虹桥站近的酒店 期望行为: - 确认出发城市 - 查询周五下午三点前到达虹桥的高铁班次 - 询问用户偏好二等座/一等座 - 预订完成后推荐三公里内评分4.5以上的酒店 禁止行为: - 未经确认直接下单 - 忽略虹桥站这个关键约束 成功标准: 用户确认订单信息且无关键约束遗漏期望行为和禁止行为这两个字段一定要写因为很多评测维度的判定比如规划质量不能只看最终结果要看中间过程是否符合合理路径。关键避坑经验评测集用例要带标签体系场景、难度、Agent 类型、失败模式没有标签的评测集等于一个无法拆解的黑箱。比如回归测试发现整体通过率从 95% 掉到 90%没有标签你只能干瞪眼有标签你能立刻定位是金融场景的 Agent 通过率从 90% 掉到 70%。2.3 评分指标的落地计算公式理论指标不落地就是空谈。我给出实际项目里跑的公式任务完成率Task Success Rate 成功完成任务数 / 任务总数 × 100%。任务是用户请求的完整闭环不是单步操作。目标工具命中率Tool Selection Accuracy 正确选择目标工具的调用次数 / 总工具调用次数 × 100%。比如有查天气、查日历、发邮件三个工具用户要求查天气Agent 调用了日历工具就算没命中。参数准确率Parameter Accuracy 单次工具调用中参数完全正确的次数 / 总调用次数 × 100%。参数完全正确指必填参数齐全、无多余参数、类型和取值符合要求。平均任务步数Average Task Steps 完成任务的工具调用总步数 / 成功完成的任务数。低于基线说明效率高但要注意极端情况——Agent 可能用一步就成功了但这一步实际是幻觉编造的结果所以步数指标要和任务完成率联合分析。无效循环率Dead-loop Rate 重复执行相同或无效操作未改变系统状态的连续步数 / 总步数。这个指标极其实用能直接反映 Agent 在错误路径上打转的毛病我见过最离谱的案例是一个 Agent 连续 7 次调用同一个查询接口参数一模一样。关键信息保留率Key Information Retention Rate 多轮对话后仍正确保留的关键信息数 / 总关键信息数 × 100%。适用客服、销售等强多轮场景。单位任务 Token 消耗 某时间段内 Token 总消耗 / 完成的任务数。这个指标反应 Agent 的唠叨程度——同一个任务有些 Agent 用 500 token 解决有些用了 3000 token成本差距是实打实的。每个指标要设基线Baseline而不是拍脑袋设目标。基线怎么来拿当前线上版本跑一遍评测集记录数据这就是基线。后续每一次迭代只要某个指标低于基线就触发告警。2.4 判定方法规则优先Judge 模型兜底Agent 评测结果怎么判断对与错有两条路线确定性规则 断言校验。对工具调用类任务这是首选方案。比如调用天气 API 后返回的 city 字段必须等于用户输入的城市名这类断言完全可以用代码写死判定精确无争议、成本为零。只要评测用例中 60% 以上能用确定性规则判定就不要引入模型判官。LLM-as-Judge模型判官。当任务结果是开放式的比如帮我把这份会议纪要提炼成三要点规则没法判断只能让模型打分。这时的核心操作是写好 Rubric评分标准我一般用四段式结构评分标准1~5分 - 5分完整满足用户全部需求输出结构清晰无错误信息 - 4分满足主要需求有轻微瑕疵如格式问题、次要细节遗漏 - 3分部分满足需求存在明显错误或关键信息缺失 - 2分回答与需求相关性弱或包含事实性错误 - 1分完全没有响应需求输出无效内容Judge 模型选型上不要拿被测 Agent 同一个模型当 Judge——自评偏差是真实存在的模型对自己的产出有天然的偏好。至少用不同系列的模型比如被测是 ClaudeJudge 就用 Gemini 或 GPT或者用开源模型如 Qwen 系列的强模型。评估结果要抽样复核。每轮评测抽 30~50 条 Judge 结果人工复核确认评分稳定、标准执行没有走样。我们自己跑下来Judge 和人工的一致性在 85% 以上才认为可信低于这个值要回头修改 Rubric 或者换 Judge 模型。2.5 基线选择的三个对照维度只有被测 Agent 自己的分数说明不了任何问题。评测必须有参照物。我建议至少做三个对比零基线/无工具基线同一个任务不调用任何工具让 Agent 纯靠模型知识回答用来衡量工具到底有没有发挥作用。有时候你会惊讶地发现Agent 接入了工具之后完成率反而下降了——因为工具的返回信息干扰了它的判断。传统流程基线用固定 Prompt 预定义步骤相当于 Workflow 模式跑同一批任务。对比结果能回答那个经典问题Agent 的自由规划到底比固定流程好在哪里。竞品/他实现基线在同样的任务集上用 LangChain、Dify、CrewAI 的 Agent 或其他框架的 Agent 跑一遍横向对比。做 PPT 管用更重要的是能发现自己的短板在哪个环节。3. 怎么落地从一次性评估到持续评测体系评测体系真正的难点不在于怎么设计而在于怎么让评测融入开发流程并且日复一日地运转。这一章聊落地建设。3.1 先解决评测基建的两个前提评测不是写个脚本跑一遍就完事它依赖基础设施。至少两件事必须提前搞定日志与追踪Tracing系统先行。没有完整的调用日志就没法分析失败原因更没法做自动化回归。每一次 Agent 运行至少要记录用户输入、模型输出、工具名称、工具入参、工具返回结果、各步骤耗时、Token 消耗、最终任务状态。Hands-on 层面LangSmith、Langfuse 这类工具都支持开箱即用的追踪开源项目也可以用 Langfuse 自托管。关键是要从第一天就接好事后补日志是最痛苦的工程之一。评测环境沙箱隔离。Agent 评测过程中会真实调用工具必须在隔离环境里跑避免产生真实副作用。如果是内部系统的操作型 Agent比如操作数据库、发送邮件一定要用 Mock 服务替代真实接口。这里有个实战技巧用 Harness 模式封装工具层——定义一套统一的工具接口契约再分别实现真实环境版和评测沙箱版。评测时 Agent 感知不到工具是 Mock 的但数据收发完全可控。这就是所谓Agent Harness的核心思想既管住评测的副作用又能统一鉴权、重试、限流逻辑。3.2 评测集管理与版本化评测集不是静态文件它像一个代码仓库需要版本管理。原因简单你更新了评测集就必须知道新旧评测集之间的差异否则无法归因分数变化到底是代码改动引起的还是评测集改动引起的。实践中我们把评测集放在 Git 仓库里管理每次修改都需要 PR 评审。评测集文件里每条用例都有唯一 ID 和修改记录。评测集的更新频率保持稳定每周合并一次新的 Bad Case。另外评测集需要定期做去重和相似度检查避免同一类用例反复加入导致分布失衡。我说一个真实教训有一段时间我们的评测集从 300 条涨到 800 条通过率一路从 85% 涨到 96%团队一度以为优化效果显著后来发现是因为生产环境的同类型高频问题反复进入评测集导致指标虚高。3.3 回归门禁的配置策略评测体系真正改变团队研发节奏的关键点是——评测变成合并代码的门禁条件。我们目前的配置供参考执行时机评测集范围门禁标准PR 提交时P0 精选集50~100 条任务完成率不低于基线安全类用例零失败每日夜间全部 P0 P1500~800 条核心指标不低于基线且不高于基线 2% 的波动发版前全量评测集全部指标达标安全用例零失败灰度阶段生产流量实时抽样线上通过率与评测通过率偏差不超过 5%安全类用例采用一票否决制。一旦出现指令注入成功、敏感信息泄露、越权操作无论其他分数多高这个版本直接不能上。这条红线别讨价还价因为上线后的安全事件修复成本是评测成本的几十倍。3.4 评测结果的可观测与失败归因评测跑完只是开始真正有价值的是失败的归因分析。我们要求每次评测之后所有失败用例必须进入到分类排查流程。团队内部有一套五问法沿着顺序排查输入理解错了没——用户意图解析阶段是否误解规划错了没——任务拆解和目标分解阶段是否合理工具调用错了没——所选工具和参数是否正确结果处理错了没——工具返回信息是否被正确解析和引用输出表达错了没——最终答复是否完整、准确、符合格式每一条失败用例在追踪系统里可以直接看到完整的推理轨迹模型每一步在想什么、调用了什么工具、返回了什么、最后怎么组装回答。轨迹回放功能是评测归因的利器也是我建议优先投入建设的功能。3.5 评测成本控制算清楚每轮评测要花多少钱大型评测集的成本是真实存在的。跑 1000 条用例每条用例平均 5 轮模型调用每轮平均消耗 1500 token那一次全量评测就是 750 万 token。按主流大模型 API 价格算这个成本绝对需要规划。我的控制策略三层级成本体系。**轻量级PR 门禁**用评测集里可确定性判断 不需要 LLM Judge的用例或者用小型模型跑 Judge 初筛成本控制在每次几块钱以内。**中量级每日回归**用高效模型必要时任务分片并行跑设定整体 Token 预算。**重量级发版前全量**用最强模型作为 Judge跑完整的 P0P1P2 全量集耗时最长但结果最可信。另外一个省钱策略是把不需要外部 API 调用的评测场景完全本地化——比如本地部署开源模型当 Judge。推理质量略低但胜在免费可无限跑。如果本身就基于开源模型做 Agent评测基建完全可以全部本地化。4. 常见问题与排查技巧实录这一章记录我在实际落地 Agent 评测过程中踩过的坑和相应的解法。每一条都是真实案例希望你能绕过。4.1 Judge 模型误判的典型场景与校准方法LLM-as-Judge 不是万能的它在真实评测中会暴露几个固定的偏好长度偏差Judge 倾向于给更长的回答打更高分哪怕长回答里有一半是废话。校准方法Rubric 中明确信息密度优先于篇幅无关内容扣分在评分提示词里强调严禁根据回答长度评分。位置偏差两个 Agent 的对比评测中Judge 更偏好排在前面的答案。校准方法把两个 Agent 的输出随机交换顺序跑两次取平均分。自肥偏差同一个模型家族对其他家族的响应会有系统性歧视也被称为自我偏好。校准方法不用被测 Agent 同源模型作为裁判或者用开源中性裁判模型。宽松/严格漂移Judge 偶尔会整体打分偏高或偏低尤其在评测批次较大时。校准方法每次评测在 Batch 中加入固定数量的标准样例已知理想分数是 3 分或 4 分用它们的得分来校准当批次的分值分布。4.2 评测集过拟合与数据泄漏这是一个隐蔽但杀伤力极大的问题。当评测集里的用例反复用于迭代优化模型渐渐地记住了用例的标准答案而不是学会了解决这类任务的能力通过率会虚高。举个例子一个法律咨询 Agent 在 200 条评测集上优化了两个月得分从 70% 涨到 96%结果换个新的 50 条真实问答完成率直接掉回 73%。解法评测集分层轮换。70% 的用例是固定回归集30% 的用例定期从新的 Bad Case 和合成用例中轮换更新。再配合留出测试集的办法——每个月从生产日志中抽取从未见过的真实问题作为月度模型能力体检不进入日常回归训练。另一个数据泄漏路径是记忆污染。如果评测过程中让 Agent 带上了历史记忆比如向量数据库里的历史会话之前跑过的评测用例会影响下一次评测的结果。做评测时必须关闭长期记忆或者保证每次评测使用干净的记忆库。4.3 多 Agent 协作评测的时序难题多 Agent 场景下评测的确定性更差。主控 Agent 拆任务给子 Agent子 Agent 异步执行再汇总这时候一个用例跑两次结果可能完全不同。处理经验每个子 Agent 单独做组件级评测覆盖自身功能范围端到端评测时把并发改为串行或可控并发保证执行顺序确定对端到端结果做多轮一致性检查——同一个用例至少跑 3 次取主结果和一致率如果引入了 A2A 协议这类跨 Agent 通信机制协议信息流转的完整性也要纳入评测断言比如主 Agent 必须正确传递会话 ID 到所有子 Agent收到的工具回包必须带原始请求 ID4.4 评测与真实线上不一致的排查团队反馈最多的头疼问题是评测集里通过率很高上线后用户还是骂。排查方向有四个线上任务分布和评测集分布不一致——评测里 80% 是简单任务真实用户 80% 是复杂任务。解法统计线上日志里各难度、各场景的任务占比按比例重新分配评测集。环境差异——评测沙箱的 Mock 数据太干净而生产数据噪声大字段缺失、格式异常、接口超时。解法评测环境注入脏数据用例在 Mock 返回值里加入边界情况。时间敏感性——有些任务依赖实时数据比如推荐、搜索离线评测用的数据快照不能代表线上最新状态。解法这类场景走独立在线评测流程用小流量回放或者影子模式对比。用户交互差异——评测是一次性问答而真实用户会追问、纠正、带情绪、词不达意。解法评测集里加入多轮对话用例且多轮场景占比不低于 30%。4.5 评测耗时过长拖慢开发节奏的处理评测从跑一次 20 分钟发展到 3 小时之后开发体验会明显变差最后大家会绕过评测直接上线。这是个管理问题也是技术问题。技术上的解法是评测集分级 异步化PR 级别只跑 P0 精选集把全量回归移到夜间次日早上汇报结果同时把评测从阻塞门禁改成异步门禁——开发者可以先合并代码但如果夜间回归失败立即告警并强制回滚到上一个通过版本。这个方案比较平衡既不影响开发节奏又守住了质量底线。5. 评测体系持续演进把它当产品来运营有句话值得写在团队评测规范第一页评测集不是一次性资产而是和代码同等重要的长期资产甚至比代码更宝贵。代码重写只需要几个月评测集里的每一条用例都包含了对真实业务和用户需求的理解这种理解是时间和数据积累出来的。所以日常工作中要像维护核心业务那样维护评测集。总结几条个人实践经验供参考凡是线上失败案例一律当日入库评测集。这个习惯坚持三个月后评测集的质量会脱胎换骨其中包含的都是真实的用户痛点和系统弱点。每周固定时间做一次评测集健康度检查统计各场景、难度、标签的分布变化识别分布失衡和无效用例及时调整。新的 Agent 能力比如新增工具、引入 Agent Skills、更换底层模型上线前先扩充对应能力的评测用例再跑评测而不是先改动代码后补测试因为代码改了之后你根本不知道哪些场景需要留神评测用例先行能倒逼你提前想清楚边界。再分享一个小技巧评测报告里的每一个失败用例至少要写一句这个失败如果上线了会发生什么。你会惊讶地发现很多看似抽象的指标问题一旦翻译成用户的实际损失团队修复的优先级会大幅提升。这是我踩过多次坑之后形成的深刻体会——评测要想真正影响研发决策必须把技术数字翻译成业务影响。只有评测让团队真正疼过它才不是一个形式化的流程。