一个很有意思的现象是很多人一谈起 Agent 评估第一反应是“给模型打分”好像只要把提示词、工具调用、最终答案丢给评测脚本就能得到一份可以上会汇报的准确数字。但在真实项目里Agent 的评估难度和传统功能测试完全是两个量级——它没有固定的输入输出没有唯一的正确答案甚至同一个任务换一个表达方式结果就可能从“完美跑通”变成“原地打转”。这也是我要花很长的篇幅去拆解 Agent Eval 方法的原因。这篇内容会围绕一套完整的评估方法论展开不只是一堆指标清单而是从“任务定义”说起一直讲到“持续改进”的闭环。无论你是刚接触 Agent 开发的新手还是已经在生产环境里被评估问题折磨过的开发者这套思路应该都能直接用上。借用 Anthropic 在 Agent 评估相关文章中给出的框架方向再加进我在实际项目里踩过坑之后总结的经验尽量做到既有方法论又有能落地的步骤。我先把一个最容易被忽略的结论放在最前面Agent 评估的成败绝大多数在写评估任务的那一刻就决定了。后面的指标、评估器、回归体系都是在为“任务定义”买单。1. 评估的第一步不是选指标而是定义“任务本身”很多团队在搭建 Agent 评估时第一件事是找评测集第二件事是挑一个大模型当评委第三件事是看分数然后就没有然后了。问题在于这个流程从一开始就走错了方向——你连“Agent 要完成的任务到底是什么”都没说清楚再精密的评估器也只能给你一个看似精确的幻觉。1.1 为什么 Agent 评估比传统评测难这么多传统软件测试的输入和输出是相对确定的一个接口传入参数返回结果断言布尔值。但在 Agent 场景里任务往往是自然语言描述的目标输入可能是一封邮件、一段用户反馈、一张截图输出则是一连串工具调用和中间决策。整个过程充满了开放性也就是说并不存在一个权威的“标准答案”可以直接比对。我习惯用一个类比来解释这件事传统评测像做填空题答案写在试卷上批改标准明确Agent 评估则像面试候选人需要自己决定先回答什么、怎么组织、要不要反问、遇到不会的问题怎么办。面试官不能只盯着最后的结论还得看候选人的思考路径是否合理、有没有绕远路、有没有踩到不该踩的风险。这里就引出了 Agent 评估的第一个核心原则评估对象不是“答案”而是“决策过程”。一个 Agent 即使最终得到了正确结果也可能在中间步骤里删除了重要数据、调用了高成本接口、或者反复回退死循环。只看最终答案的评估方式几乎无法发现这些真实生产环境中要命的问题。1.2 把任务定义写清楚五个必须回答的问题我在实际项目里总结了一张“任务定义检查单”任何一条 Agent 评估任务在写进评测集之前都必须先回答这五个问题第一目标是什么不是一句话目标而是可验证的终态。比如“完成退货流程”这不算目标“退货单状态变为已退款、客户收到退款通知邮件、库存数据同步完成”才算。第二边界是什么Agent 允许调用哪些工具不允许调用哪些工具数据范围的限制是什么这决定了评估任务的可执行范围也直接关系到安全性评估。第三输入是什么包含哪些信息缺失哪些信息是完整的结构化数据还是包括模糊的自然语言描述输入缺失的部分恰恰是最容易暴露 Agent 判断能力的点。第四路径自由度有多大同一个目标允许多种路径到达还是必须按特定流程走这决定了评估时候是看最终状态还是也要检查轨迹。第五失败标准是什么什么样的结果算失败超时算不算部分完成算不算哪些错误是不可原谅的比如删库、越权这些问题没有写完之前我不建议碰任何评估指标。因为指标只是对目标的量化包装目标本身是模糊的指标就是从虚数里强行开出来的根号。1.3 任务定义要从用户视角反推任务定义还有一个经常被跳过的维度用户的真实诉求。很多团队喜欢从工程视角写任务比如“正确调用某个 API 并解析返回结果”但用户根本不在意 API 细节用户在意的是“我的问题被解决了没有”。我的做法是每写一个评估任务都先在文档里用一句话描述“用户在这个场景里希望获得什么”然后从这个诉求倒推出可验证的结果状态。举个例子如果用户想“查一下上周的销售数据并生成对比分析”真正的任务目标不只是“查询成功”还包括“数据口径是否正确”“分析维度是否覆盖用户提到的对比需求”“输出是否清晰可读”。这些几乎不可能被一句“任务成功”指标覆盖必须在任务定义阶段就拆出来。任务定义这件事本质上是在为一个开放问题画边界。边界画得越清楚后续的评分标准、数据构造、评估器设计就越轻松边界画不清后面每一步都是在打补丁。2. 评估数据与指标体系没有基准评分就是空谈任务定义完成之后紧接着要解决的是两个问题拿什么数据来测按什么标准来判这两个问题表面上是两件事实际上是一件事——数据决定了评估的覆盖面指标决定了数据的价值如何被提取。2.1 从“评估集”到“评估环境”传统评测集是一堆固定的“问题-答案”对。Agent 评估里我更倾向把它叫“评估环境”不仅是任务输入还包括初始状态、可用工具、环境约束、可能出现的干扰因素。举个例子测试一个“自动处理客户邮件”的 Agent评估集不能只是一封邮件文本还要包含当前订单状态、库存数据、客户历史记录、可用的退款和物流接口、以及一封可能带有歧义的邮件。Agent 接下去要做的每一次工具调用都会改变这个环境的状态。所以在落地评估集的时候我会为每个任务建立一个“初始状态描述”明确写清楚环境变量、数据快照和工具可用范围。没有这个东西同一个任务跑两次可能会得到完全不同的结果——不是 Agent 变聪明了而是环境状态对不上。另外评估集一定要区分“标准场景”和“边界场景”两层。标准场景是主流程跑通边界场景则专门放那些容易让 Agent 翻车的输入模糊指令、缺失字段、互相矛盾的信息、需要拒绝执行的高风险请求。很多团队只把精力放在标准场景上结果就是测试集上分数亮眼一到真实环境就被花式输入打穿。2.2 指标分层最终结果、关键节点、轨迹质量缺一不可用一个单一指标来评价 Agent是评估体系里最容易出现的偷懒行为。我建议至少拆成三个层级第一层是结果指标即最终目标是否达成。这个指标最容易理解但同时也最容易产生误导。一个 Agent 可能在“最终状态达标”的指标上拿到了高分但过程里充满了不必要的重复调用和危险操作。第二层是关键节点指标即任务过程中的关键步骤是否按预期完成。比如一个售后 Agent关键节点可能包括“是否正确识别退换货原因”“是否选择了正确的退款金额”“是否生成了合规的审批单”。把这些节点设计出来评估就能定位到具体哪一步出了问题而不是只知道“整体任务失败”。第三层是轨迹质量指标即整个过程是否高效、稳定、安全。这时候看的是工具调用次数、重试频率、无效操作数量、越权行为次数、是否陷入死循环等。这一层指标数据可以从 Agent 的执行日志里自动统计评估成本相对较低但价值非常高。下面这张表是我在一个模拟项目里用的指标模板可以作为一个起点参考指标层级典型指标举例获取方式用途结果指标任务成功率、目标达成度自动对比终态全局判断关键节点指标关键步骤正确率、分支决策准确率轨迹标注或规则检测定位问题环节轨迹质量指标工具调用次数、无效调用率、越权次数日志统计衡量稳定性和安全性资源指标Token 消耗、延迟、API 调用成本运行时采集成本控制和性能基准这些指标不是每轮评估都必须全部统计但至少要明白只用结果指标你只能知道 Agent 行不行加上节点和轨迹指标你才能知道 Agent 哪里不行。2.3 没有现成数据时如何造出第一版评估集绝大多数团队在开始做 Agent 评估时手上并没有合适的现成数据。我见过不少人在这个阶段卡住一直等着“数据凑齐了再开始”结果一等就等到了项目上线评估体系还是空的。我的建议是第一版评估集不求多但必须来自真实生产场景的拆解。把过去一段时间里用户实际提过的问题、生产环境里真实触发过的案例收集起来挑出 20 到 30 条有代表性的转化成结构化的评估任务。宁可先只有 20 条经过精心设计的任务也不要一上来就堆 500 条用 AI 批量生成、但跟实际场景脱节的假任务。数据构造的具体流程我一般分四步先圈定场景范围然后从真实案例里抽取原始输入再补充环境状态数据和边界条件最后人工审核一遍确保每条任务的定义符合第一步写好的任务定义标准。这个流程虽然慢但每一条评估数据都是有效的基础打牢之后后续新增评估数据的效率会高很多。3. 评估器设计模型评分与人工复核的配合方式任务定义和评估数据都准备好了接下来一个问题谁来判断结果判断标准是什么这一节的内容是整个 Agent Eval 方法论里最容易产生分歧的地方也是我认为被误解最多的地方。3.1 文本答案评分相对容易难的是过程评分如果 Agent 的任务只是生成一段文本用另一个模型来评分已经是一个比较成熟的方案给评估模型一段评分标准让它输出 1 到 5 分并附加理由基本能够满足大部分需求。但 Agent 评估的难点从来不在最终文本而在过程。一个 Agent 可能先调用了错误的工具然后通过另一个工具绕回来可能在删除数据之后才发现路径不对又尝试恢复可能把用户隐私信息打印到了日志里但最后任务成功了。这些过程中的瑕疵单纯靠对“最终输出”评分是无法被捕捉到的。所以我在实际项目中会把评分对象从“结果文本”扩展到“完整的执行轨迹”。评估模型看到的不仅是一句回复而是整个工具调用序列、每一步的中间结果、Agent 当时的思考摘要、以及最终输出。评分标准也不再是“回复是否准确”而是“决策路径是否合理”“是否有无效操作”“是否违反了约束条件”。3.2 给评估器加约束评分标准、参考轨迹、自检机制直接让一个模型对着复杂轨迹打分结果往往是不稳定的。为了把评估器的输出拉回可用的水平我习惯给它加三层约束。第一层是显式评分标准。把每个分数档位的含义写清楚比如“3 分代表任务完成但有轻微瑕疵”“2 分代表任务核心目标未完成”避免评估模型自由发挥。第二层是参考轨迹。我至少会在每一条评估任务里提供一个“理想执行路径说明”告诉评估模型正常情况下应该先后调用哪些工具、在哪些节点做哪些判断。评估模型有了参照物之后给 Agent 打分的可靠性会明显提升。第三层是自检机制。在提示词里要求评估模型在给出结论前列举自己检查过哪些关键点并且标注信息来源。这一招本质上是在做“强迫评估器解释自己”能在一定程度上减少模型瞎打分的情况。下面是一个简化的评估提示词结构可以当作模板参考你是一个严格的 Agent 执行过程评估器。 以下是 Agent 执行某任务时留下的完整轨迹请从以下三个维度评估 1. 最终目标是否达成 2. 关键节点判断是否准确 3. 执行路径是否存在高风险或低效行为 请先总结关键事实再对照理想轨迹给出评分。 评分前请说明你在每个维度上检查了哪些证据。这个模板用在很多场景里都有效但具体参数要根据 Agent 的任务类型调整。评估任务越复杂对评估器提示词的精确度要求就越高。有时候甚至需要为不同类型的任务单独设计评估器而不是让一个通用评估器包打天下。3.3 人工不能只抽样式复核要做“分歧仲裁”评估器再完善也不可能完全替代人工判断。但人工评估有一个很大的坑如果每个人按自己的标准打分结果比模型还不稳定。我的做法是把人工的角色从“打分员”调整为“仲裁员”。评估器输出结果之后系统会自动标记两类样本一类是低置信度的评分样本一类是评估器与规则判定出现分歧的样本。这些样本才进入人工复核池。人工只需要处理被标记的争议样本不必逐条重新评分工作量会大幅下降同时质量也能守住。人工仲裁的标准也需要提前约定。我在项目里会让参与评估的同事每人先独立评分同一批样本然后把分歧点拿出来讨论直到达成一个统一的口径。这一步骤看起来麻烦但它决定了后续人工仲裁的一致性。没有预先校准的人工评估只不过是把随机性从模型换成了人。4. 持续改进让评估集跟着开发节奏一起更新评估体系搭建起来之后最大的悲剧是它变成一个“一次性工程”。项目上线时跑了一遍评测之后所有人都忙着迭代功能评估集逐渐和实际需求脱节。等到哪一天真的出现重大故障回头查的时候才发现评估体系已经完全不能反映真实场景了。所以“持续改进”不是评估体系的附加功能而是它的基本生存方式。这里我把持续改进拆成几个可以日常执行的环节逐个说明。4.1 回归测试与失败样本沉淀每一次 Agent 行为变更无论是对提示词的调整、工具定义的修改还是模型底座的升级都应该触发一轮完整回归评估。这一轮评估的价值不仅在于确认“没有变差”更在于发现评估体系里还没有覆盖到的盲区。回归评估中发现的所有失败案例都要进入一个新的集合——失败样本库。这个样本库在后续优化中扮演着两个角色提醒开发者曾经的失败不要重演同时为新版本的 Agent 提供“针对性检验”。我经历过一次印象深刻的教训在一次模型版本升级之后Agent 的通用能力提升很明显但在一个很冷门的边缘场景上表现反而退化了。如果没有回归评估这个退化会被整体指标的提升掩盖掉。回归测试的意义正在于此——它不让你被平均值蒙在鼓里。4.2 评估数据泄露的坑持续改进过程中有一个非常隐蔽的坑评估数据泄露。它和传统机器学习的数据泄露不太一样主要体现在两种形式上。第一种是提示词暗示。如果评估任务里包含了太多“引导性信息”Agent 在答题时反而更容易走偏。这个问题在写评估数据时就要注意数据里只能包含用户在真实场景里能够获得的信息不能为了让任务看起来更清晰就额外塞提示词。第二种是评估集污染。当 Agent 的开发流程里反复使用同一批评估数据Agent 可能会在隐式层面“记住”这些任务的特征模式导致后续评估得分虚高但真实泛化能力并没有提升。这个问题没有完美解法我的应对方案是定期从真实生产日志中抽取新的评估样本逐步替换掉那些已经太“熟”的旧数据。4.3 一个可落地的迭代节奏持续改进不能靠“想起来才做”得有一个固定的节奏。我在项目里跑顺的节奏大概是这样的每完成一个功能迭代先跑一轮全量回归把指标变化记录下来每两周从生产环境日志里抽一批新的真实场景样本加入评估集每个月做一次评估体系复核检查任务定义、评估器提示词和人工仲裁标准是否需要同步更新。这个节奏不一定适合所有团队但核心思路是一致的评估体系必须和 Agent 本身一样处于持续的迭代循环里。Agent 在变评估集也得变评估标准在变评估器也得跟着变。否则你维护的不是一套评估体系而是一座越来越旧的历史博物馆。5. 落地这套方法之后我最想分享的几条实战教训方法讲完之后我想把自己真正踩过坑、摔过跟头之后留下的几条经验放在最后。熟悉 Agent Eval 的朋友都知道纸上谈兵和真实落地之间的差距往往比想象中大得多。第一条教训最省事的评估器最容易骗自己。项目早期为了方便我试过直接用字符串匹配来判断 Agent 输出是否正确。结果可想而知输出里多了一个空格、换了一行、加了一句解释都会被判定为失败整体分数惨不忍睹。后来换成了大模型评估器又差点走到另一个极端——只要最终回复看起来合理不管过程评估器就判高分。任何一种评估器选择都有代价关键是你得知道自己放弃了什么。第二条教训把大任务拆成小任务评估才不会变成玄学。一个复杂的 Agent 任务如果从头到尾只给一个总分出问题的时候你根本不知道问题出在哪个环节。更合理的做法是把大任务拆成多个可独立评估的子任务各自有各自的目标和评分标准。比如一个“数据分析”Agent可以拆成“数据读取是否完整”“查询逻辑是否正确”“结论是否对得上数据”三个子任务分别评估。这样总分下降的时候你能立刻定位到具体的失败点。第三条教训评估结果一定要让所有开发环节都看得到。很多人做评估是为了自己心里有数做完评测之后把报告一存其他同事根本不知道 Agent 的哪些能力在退化。我的建议是把每次评估结果里最关键的几张图、几个失败的案例、几条指标变化直接同步到团队信息流里让参与 Agent 开发、产品、运营的人都能看到。评估结果只有流动起来才能真正推动改进否则它只是一堆无生命力的数字和截图。第四条教训没有“万无一失”的评估但持续评估可以无限逼近。最后想说的是Agent 的开放性和动态性决定了它不可能被一次评估彻底覆盖。总有新的任务类型、新的表达方式、新的边界条件是你当前的评估集没有考虑到的。但这并不代表评估没有价值——恰恰因为 Agent 是开放的我们才需要让评估也保持开放持续从真实场景中吸收新的样本不断修正评估标准让“任务定义到持续改进”这个循环一直转下去。在我自己的实践中Agent 评估最宝贵的不是某一次评测的高分而是那套能够不断发现问题的机制本身。它可能不会让你的 Agent 一夜之间变聪明但它至少能确保每一次迭代的方向都走在正路上。