做 Agent 的人迟早会撞上一堵墙功能好像都通了但你根本说不清它到底行不行。手动喂十几条测试用例、肉眼盯着日志看结果一次两次还行等 Agent 要接工具、要处理几十步长任务、要面对真实用户各种奇怪输入的时候这种土办法马上崩盘——你不知道哪次改动改坏了东西也不知道当前版本离上线标准还差多少。Anthropic 公开的 Agent Eval 方法正是把这件原本很靠感觉的事变成一套从任务定义、评测用例设计、自动判分到持续改进的工程化流程。这篇分享里我会按这套思路结合自己做 Agent 评测的实操经验把每个环节拆开讲透争取让你看完就能直接照着搭一套适合自己的评测体系。1. 先搞清楚Agent 评测难在哪为什么必须体系化很多人一开始对 Agent 评测的态度是不就是拿几个 case 跑一下看看输出对不对吗。这话对了一半。对单轮问答模型这个思路勉强够用对 Agent 来说这种想法会很快让你在第一个真实项目里栽跟头。想做好评测得先明白 Agent 和普通语言模型在被评测这件事上到底差在哪。1.1 单轮问答评测与 Agent 评测的本质差异单轮问答的评测本质上是一次输入-输出比对。你给模型一句 prompt它吐一段回答你拿参考答案或者规则去判断对错整个过程是一个静态快照。Agent 完全不是这么回事。它在一次任务里会经历多轮推理、多次工具调用、环境状态变化甚至中途还要根据返回结果调整策略。这就像单轮问答是改一篇作文而 Agent 评测是验收一条流水线——你不仅要看最终产品合不合格还要看中间每一道工序有没有跑偏。有一回我调试一个需要联网查资料再汇总的 Agent跑出来的报告本身完全正确但我翻日志发现它先调用了一个错误接口拿数据发现不对又绕回来用正确接口。最终结果对过程却在浪费时间和 token。如果只看最终输出这种低效行为永远不会被发现积累到一定程度就变成线上成本失控。多步任务的错误会逐层叠加任何一个环节的微小偏差都可能在后续步骤中被放大这是 Agent 评测比传统评测难一个量级的根本原因。1.2 一套体系化评测要解决的四个实际问题你需要的不是更多测试用例而是一套能回答以下四个问题的机制。回归检测这次改了 prompt 或换了模型哪些已有能力被破坏没有持续评测你根本不知道一次优化是不是在拆东墙补西墙。能力边界当前版本到底能处理什么任务、处理到什么程度这个结论不能靠感觉得有覆盖各种任务类型和难度等级的评测数据支撑。迭代依据当你要在提示词方案和代码方案之间做选择或者要对比两个不同版本的工具调用策略时评测结果是你唯一能站得住脚的判断依据。上线信心发布前你总得回答能不能上这个问题量化指标比我大概试了试没什么问题有说服力得多。这四个问题环环相扣。没有回归检测迭代就是在黑箱里乱撞没有能力边界认知上线就是在赌运气。所以问题的关键不是选什么评测工具而是流程本身——从定义任务的那一刻开始评测就已经在发生了。2. 整体思路拆解这套评测方法的骨架是什么Anthropic 那篇 Agent Eval 分享里最触动我的不是某个具体的评测技术而是他们把整个流程串成了一条清晰的链路先定义任务再构造评测用例接着设计判分逻辑最后用持续改进把整个系统盘活。这个顺序本身就是学问。2.1 把任务定义放在最前面是被逼出来的Agent 评测的第一步不是写代码而是写清楚任务到底是什么。听起来像废话但真正做过的人都知道这是整个流程里最容易被跳过、也最致命的一步。如果你把任务定义成回答用户的问题那么评测标准就是答得对不对等于什么都没定义。但如果你把任务定义为在不超过 5 轮交互、只允许调用这三个工具的前提下从用户提供的报销单据中提取金额、类别和日期并按模板提交申请你的评测用例、判分逻辑、失败分析就全部有了锚点。这不是理论上的美好愿望而是被真实教训逼出来的。我见过太多项目Agent 行为诡异团队争论半天它到底算不算做对了最后发现根因是任务描述本身就含混不清——有人理解成要直接给结论有人理解成要先查库再给结论。任务定义清楚之后一半的评测争议自动消失。2.2 两种评测形态结果导向与轨迹导向在实际搭建评测时你会发现评测用例天然分成两类一类只看最终结果一类要管中间过程。两种形态各有适用场景我整理了个对照表。维度结果导向评测轨迹导向评测关注点最终输出是否正确过程行为是否符合预期典型场景信息提取、报告生成、单轮问答工具调用、多步规划、安全合规判分方式规则断言、LLM 打分器轨迹断言、运行时钩子优点实现简单、贴近用户实际感知能发现中间隐患、可定位失败环节缺点无法解释失败原因用例编写复杂、容易过拟合行为模板实际项目里我不会二选一而是混合使用以结果导向评测决定过不过以轨迹导向评测回答为什么挂。结果导向的用例负责守底线轨迹导向的用例负责挖细节。比如判断一个检索增强型 Agent结果导向只看最终答案是否覆盖关键信息点轨迹导向则检查它有没有在检索阶段就漏掉关键文档——后者往往是前者失败的真正原因。2.3 评测粒度分层从单步到端到端除了评测形态评测粒度也得分层。我把 Agent 评测分成三个层级组件级单独测某一个环节比如路由判断是否准确、单次工具调用的参数是否正确、检索结果相关性是否达标。这类评测跑得快、反馈快适合开发过程中频繁执行。任务级跑完整条任务链路看最终目标能否达成。这是评测体系的核心直接反映用户可感知的效果。系统级把多个任务组合起来考察资源消耗、并发表现、稳定性、超时率等。这类评测最接近生产环境也最贵通常放在发布前执行。分层带来的最大好处是反馈速度的优化。你不需要每次改代码都跑一遍完整的端到端评测组件级用例几十秒就能给结果等组件都绿了再跑任务级和系统级省时省力。我见过有人把所有评测都堆到端到端结果一次改动要等半小时才能知道结果迭代效率低到令人绝望。3. 任务定义与评测用例设计动手前最重要的 50%如果问我评测体系里哪部分投入产出比最高我会毫不犹豫地说任务定义和评测用例设计。这部分做好后续的判分和持续改进都是水到渠成这部分糊弄过去后面每一步都在还债。3.1 怎样写一份可判读的任务说明书一份能直接指导评测的任务说明书至少包含这样几个模块目标一句话可验证例如根据用户上传的报销单据图片提取金额、类别、日期并生成报销申请草稿。这句话必须可以判定真伪不能出现提供帮助给出建议这种含糊表述。可用资源明确列出可调用的工具清单、数据范围、权限边界。Agent 只能用定义好的工具这是评测的硬约束。约束条件包括最大交互轮数、超时时间、预算上限、合规要求。这些约束本身就是评测的一部分。成功标准这是最关键也最容易偷懒的模块。要写满足以下全部条件才算成功而不是尽量表现好。边界与反例明确哪些情况不算成功。比如用户提供的单据模糊无法识别时必须主动询问而不是猜测填写这就堵住了 Agent 乱猜的后路。拿某客服工单自动处理 Agent 举例任务说明书的成功标准大致是准确识别工单类型、在允许的工具范围内查询用户信息、给出符合话术规范的回复、涉及退款时必须转人工并在回复中明确说明。你看这样定义完之后评测用例和判分逻辑几乎是顺理成章的事。3.2 评测用例的三类来源评测用例不能拍脑袋凭空编我常用的来源有三个按优先级排序真实日志沉淀从线上日志里挑出成功和失败的真实任务这是最有价值的用例来源。因为它代表真实的用户分布包含各种预料之外的输入方式。我每个迭代周期都会从日志里随机采样一批任务补充进评测集。人工构造变体围绕核心任务人工制造变体换表达方式、换数据格式、换边界条件。比如测试报销提取就要覆盖手写体模糊、多币种金额、缺少日期等各种情况。变体的目的是逼出 Agent 的薄弱点。合成难度递增序列从单步任务开始逐步叠加难度——增加检索步骤、增加多工具协作、引入冲突信息、设置需要拒绝执行的场景。这类用例用来探能力上限。无论用例来自哪里我要求每一条都必须能回答两个问题它在测什么能力什么行为算通过回答不了这两个问题的用例趁早删掉留着只会制造噪音。3.3 成功标准的可操作化把好变成可判断很多人写成功标准时喜欢用形容词准确合理流畅这些词在评测里毫无意义。你要做的是把宏观描述逐步拆解成可验证的具体条件。以正确调用工具这个标准为例拆解之后至少包括三层用了正确的工具该调提交接口时没有调查询接口、传了正确的参数金额字段没有塞进备注字段、在正确的时机调用没有在用户还没确认前就提交。每一层都可以写成具体断言。下面是一条任务级评测里很典型的断言逻辑def assert_task_success(trace, result): # 1. 最终结果结构必须完整 assert result[status] submitted assert set(result[fields]).issuperset({amount, category, date}) # 2. 关键工具调用必须发生且顺序正确 tool_names [call[name] for call in trace[tool_calls]] assert extract_receipt in tool_names assert tool_names.index(submit_expense) tool_names.index(extract_receipt) # 3. 交互轮次不能超限 assert len(trace[turns]) 5 # 4. 不得出现越权操作 assert not any(call[name] quote_price for call in trace[tool_calls])要注意的是断言不是越多越好。写得太细会过度编码实现细节比如强制要求 Agent 必须用某种特定方式思考反而让评测集变得脆弱。我的经验是断言覆盖任务的必要条件和结果质量至于 Agent 用什么路径达到结果留给轨迹评测单独去管。4. 自动判分与轨迹采集评测运行的工程化任务定义和用例设计做好之后接下来的问题就是怎么把评测跑起来、跑得稳。这一环节最考验工程功底因为评测系统本身也是一个系统它也会出错、也会不稳定。4.1 规则断言与 LLM 打分器怎么配合判分方式我通常按输出类型分两派。结构化输出用规则断言。只要 Agent 的输出是 JSON、是字段化数据就用代码直接校验 schema、校验必填字段、校验值域。规则断言快、稳定、无歧义一个字段对就是对错就是错。这里面有个实用技巧在评测环境里把 Agent 的最终输出解析成统一的数据结构再交给断言函数不要直接拿原始文本做字符串匹配后者会死得很惨。开放式输出用 LLM 打分器。汇总报告、邮件草稿、话术回复这类内容没有标准答案只能让一个语言模型当评委。但 LLM 打分器有个著名的问题——不稳定。同一个回答换个 prompt 或换个顺序分数可能就变了。我在实践里总结了几个稳住的要点打分器温度设为 0关掉随机性在打分 prompt 里先写明评分卡rubric再让模型给出判定理由最后给出分数给打分器提供几个已标注的示例示例的形态要覆盖高分、低分、临界三种情况多条用例运行时随机打乱顺序避免位置偏差。一个简化版的打分器 prompt 长这样judge_prompt f 请根据以下评分标准判定 Agent 回复是否成功完成任务。 评分标准满足任意一条即判失败 1. 回复未给出用户问题对应的明确方案 2. 方案引用了不存在的数据或字段 3. 需要转人工的场景退款、投诉未明确提示转接。 请先陈述判定理由再输出 PASS 或 FAIL。 Agent 回复 {agent_response} 这样做的核心思路是把主观判断尽可能变成客观条件让打分器的自由裁量空间最小化。你给它的约束越清晰它的结果越稳定。4.2 运行时钩子评测不能只盯最终输出前面说过Agent 评测要看轨迹。轨迹从哪来从运行时埋点来。评测系统必须在 Agent 的整个执行过程中插入钩子记录每一步的关键信息。我在评测框架里最少会埋三类钩子工具调用前、工具调用后、任务结束。工具调用前记录 Agent 的推理意图和将要执行的调用用来判断该不该调工具调用后记录返回内容和状态判断调得好不好任务结束时汇总轮次、耗时、token 消耗。一个简单的拦截逻辑可以这样写def before_tool_call(context, call): context.record_intent(call[reasoning]) if call[name] not in context.allowed_tools: # 调用白名单之外的接口直接判失败 return {action: abort, reason: tool_not_allowed}钩子设计有个重要原则评测用的钩子和生产环境的日志埋点尽量共用一套基础设施。否则你评测时看到的行为轨迹和线上真实行为可能不一致评测就失真了。另外完整轨迹必须落库保存这不仅是定位问题的手段更是后续复现失败用例的数据基础。没有轨迹评测结果就只是一个没有证据的结论。4.3 评测运行与结果管理的工程化细节评测代码写好了怎么跑、怎么管理结果同样有一堆学问。我踩过不少坑之后固定下来一套做法固定一切可固定的东西。模型版本、温度参数、随机种子、工具列表版本全部固定并在评测记录里写明。不然出了结果差异你都不知道是哪一层变了。对非确定性结果做重复实验。Agent 天然有随机性单次 PASS/FAIL 不能说明问题。重要用例至少要跑 3 次取多数结果或稳定率作为最终指标。评测结果落库。每次运行的时间、版本、通过率、完整轨迹、判分明细全部入库。这是持续改进环节的数据基础没有历史数据你就没法做回归对比。定义统一的指标口径。我常用的是主任务通过率端到端成功比例、工具调用成功率单个工具调用被判定为正确的比例、平均交互轮次、超时率。这四个指标能覆盖大部分 Agent 的核心表现。工程化做到这个程度评测本身才算一个可信的测量工具。否则它只是一个偶尔跑一下的脚本提供不了可供决策的信号。5. 持续改进让评测真正驱动迭代评测体系建起来只是开始真正让它发挥价值的是持续改进这个环节。如果评测结果出来没人看、看完没动作那整套体系就只是个昂贵的摆设。我从实践里总结出的核心是把评测当成一个活的系统每周都要喂东西进去、每周都要做清理。5.1 建立评测评审的固定节奏我习惯每周固定一个半小时做评测评审雷打不动。这个评审不是把通过率看一遍就完事而是逐条过新增失败和争议用例做三件事分类失败原因。把每一条失败明确归到真回归、评测用例本身有问题、模型能力确实不足三类。真回归要马上查代码或配置变更评测用例有问题要改用例改标准模型能力不足则排进迭代计划。回填真实新任务。从本周线上日志里采样新的真实任务人工标注后加入评测集。只有不断把真实分布喂进来评测才不会慢慢脱离实际。清理失效用例。那些连续多次全过、且不再对应任何能力风险的用例降级或移除那些反复被改来改去的用例停下来问一句是不是原来的成功标准就没定对。评审之后失败的案例进入两个去向修正评测标准或者修复模型行为。然后重新跑一轮评测验证。这个失败案例 → 分析归类 → 修正评测或修复模型 → 回归验证的循环就是持续改进的核心节拍。我见过最快把 Agent 质量拉起来的团队不是他们模型调参多厉害而是这个循环跑得又勤又准。5.2 一次典型迭代从评测误判到能力提升光讲流程有点抽象说个我实际遇到的案例。某项目的客服工单 Agent端到端通过率一度停在 91%其中退款类工单这一个分类的失败率占了七成。一开始判断是 Agent 不会处理退款团队猛调 prompt调了两周效果甚微。后来做了一次深度的失败用例分析把每一条失败轨迹都翻出来看发现问题根本不是 Agent 不会处理退款而是评测标准定义错了。原任务说明书里的成功标准写着回复必须包含明确解决方案可公司政策要求退款类工单必须优先引导转人工禁止直接在回复里承诺退款。Agent 行为完全正确却因为评测用例的成功标准没跟上业务规则被判成失败。修正成功标准、把退款类工单正确转人工设为有效终态之后通过率数据一瞬间变得真实了模型改动也终于有了正确的反馈信号。这个案例给我的教训很深刻评测用例不是石头刻的它必须随着业务规则和任务定义的进化而进化。持续改进不只是改模型改评测本身同样是改进。5.3 防止评测集过拟合与退化的三条红线评测集用久了会慢慢丧失区分度最后变成一块谁都能过的牌子。我给自己定了三条红线触犯任何一条都要立刻处理。评测集不能当训练集用。反复对着同一个评测集调 prompt、调参数本质上就是在过拟合这几十条用例。评测分数看起来漂亮换一批新任务立刻现原形。解决方法是留一个固定的 holdout 集——从评测集里划出一部分不参与日常调试只在里程碑节点跑一次。定期从真实分布采样刷新评测集。评测集必须是一个不断进化的活样本而不是一个固化的存档。真实任务分布变了评测集不变评测就变成自欺欺人。监控评测有效性与业务指标的联动。如果某个阶段的评测通过率一直在涨但线上用户的成功率、投诉量没有同步变好那你就要警惕评测集很可能已经失真了。评测的价值最终要体现在真实世界的表现上这条不成立上面的努力全部白费。三条红线本质上是一条永远不要让评测脱离它服务的对象。评测是手段真实任务是目的。6. 常见问题与排查技巧实录最后这部分是踩坑实录。我把自己在做 Agent 评测过程中遇到过的高频问题整理成了一张速查表后面再挑三个最典型的展开讲。症状常见根因处理办法通过率虚高上线后效果很差评测用例与真实分布脱节从真实日志回流用例定期刷新评测集判分结果不稳定同一回答时对时错LLM 打分器随机性大、评分卡模糊温度设 0、写清评分卡、提供已标注示例偶发失败重跑又通过环境依赖不固定、超时处理缺失固定版本和种子保存完整轨迹复现评测集越来越大跑一次要半小时用例无分层、无清理分 smoke/full/nightly 三层定期清理6.1 评测用例模棱两可怎么判这是最隐蔽也最普遍的问题。一看评测用例好像写了细看全是合理判断适当处理这类虚词判分的人或判分的模型只能靠猜。结果就是同一个用例不同人标注结果不一样评测结果根本不可信。我的解法很朴素把成功标准改写成一组二值条件每个条件只能回答是或否。同时给每条用例配上至少一个通过示例和一个失败示例。这两个示例的价值在于把抽象标准落到具体形态上。另外评审会上但凡出现判定争议不争论直接改用例——要么补充条件要么调整示例定稿后写进用例描述里。这种争议即更新的机制让评测标准越来越清晰。6.2 评测结果忽高忽低、复现困难Agent 评测的非确定性来源很多模型采样的随机性、工具调用返回时间不同、并行执行时共享状态被改动、第三方服务限流等等。如果你不做控制评测结果就是一片噪声。我的处理方式分三层入口层把随机种子、模型版本、温度全部固定执行层对关键用例做多次重复取稳定通过率而不是单次结果分析层把每一次执行的完整轨迹存下来失败时能精确重放而不是只能看一个秃秃的 FAIL。这里有个容易忽略的点第三方工具调用的返回内容也要记录。没有它很多偶发失败根本没法定位到底是不是外部服务抽风。6.3 评测集越来越臃肿跑一次要很久评测集不会自然保持精简它会不断膨胀——每周都加新用例但几乎没人删用例。几个月之后跑一轮完整评测成了煎熬大家开始跳过评测体系就名存实亡了。我用的是三层评测策略smoke 层只有十几条最核心的用例每次代码改动都跑几分钟出结果full 层包含全部任务级用例每日跑一次nightly 层包含系统级和压力类用例每晚跑一次。新增用例先进 full 层观察连续一段时间不出问题再降级或移除。这个策略保证了反馈速度和覆盖度的平衡评测才不会演化成负担。说到底评测体系能不能坚持下去取决于它跑起来有多省事而不是它有多全面。我自己在实际搭建这套流程时最深的一个体会是Agent 评测表面上是在测 Agent实际上是在逼你把任务本身想清楚。很多项目的问题根本不是模型不够强而是任务定义模糊、成功标准含糊、行为边界不清——评测体系把这些问题全部暴露出来。所以哪怕你暂时不打算做完整评测也建议从写清楚任务说明书开始这一个小动作就能帮你避免大量的无效迭代。如果再贪心一点给每条评测用例记一笔为什么加它的日志三个月后回头看你会感谢现在的自己。