本文来自微信公众号： AIGC从0到1 ，作者：王零壹，原文标题：《Agent 评测，正在成为 AI 产品的新分水岭》
过去一年，模型能力还在进步，工具调用也越来越成熟。但当一个系统开始替人做事，问题就不再是“它偶尔能不能完成任务”，而是“你是否知道它会在什么地方失手，又能否在它失手之前把它拦下来”。
评测因此变了。
它不再只是上线前跑几条case，给产品打一个分。它正在变成Agent的质量系统：定义什么叫成功，记录它怎么成功或失败，把问题交给对应的人修，再确认修完以后不会在下一个版本里重新出现。
很多团队还把eval当成一个辅助工具。其实到了Agent这里，评测更像是生产系统的一部分。
01一个Agent的问题，通常不是“答错了”
传统软件测试处理的是相对确定的系统。
输入一组参数，期待一个确定的返回值。即使系统很复杂，工程师也能把它拆成函数、模块、接口和单元测试。测试失败了，通常能顺着报错栈去找问题。
Agent不一样。
它面对的输入往往不完整。用户说“帮我处理一下这个订单”，没有说清是退款、改地址还是投诉；它需要在多轮对话里保持上下文，也需要决定先问什么、先查什么、什么时候调用工具、工具返回异常以后怎么处理。它还可能在任务执行中改变外部状态：修改文件、提交代码、发送邮件、创建工单、触发付款，甚至代表企业向客户作出承诺。
这意味着，Agent的错误不是一个点，而是一条链。
它可能一开始就识别错了意图；也可能意图没错，但查错了知识库；也可能知识库检索到了正确规则，却在生成回复时把规则解释反了；还可能所有文字都写得很漂亮，唯独漏掉了一次关键工具调用。
在客服场景里，这类错误很常见。比如用户申请退款，Agent最终回复“可以处理”，语气也很专业。可如果订单已经发货，它本应先查订单状态，再解释拒收、售后或人工介入的路径。最终答案看起来过得去，执行过程却已经埋下了资损和投诉的风险。
这种“结果像是对的，过程其实不对”的情况，是Agent评测最容易漏掉的假阳性。
所以，评测Agent不能只问“最终答案对不对”。还要问：
它有没有理解正确的任务目标？
它走的路径是否符合业务规则？
关键工具是否在正确的时机被调用？
参数是否正确？
异常发生以后，它是继续硬做、降级处理，还是及时把任务交回给人？
同一个任务多跑几次，表现会不会大幅波动？
这些问题叠在一起，才构成一个Agent的真实质量。
02先别急着谈指标，先分清你到底在测什么
现在很多团队一上来就设计分数：任务成功率多少、满意度多少、工具调用正确率多少。
这些指标当然重要，但更早的问题是：你到底想用评测回答什么。
至少有四类问题，不能混在一个总分里。
第一类是能力上限。这个Agent有没有完成某项任务的能力？比如一个代码Agent能不能修复某个真实bug，一个研究Agent能不能完成资料搜集和论证，一个办公Agent能不能跑通报销流程。
第二类是稳定性。它不是“有一次做对”就够了，而是要看在相同条件下多次运行，是否仍能做对。对研究和内容类任务而言，偶尔得到一份好结果或许有价值；但对客服、支付、医疗、合规等场景来说，用户不会接受“多试几次总有一次对”。
第三类是过程合规。Agent是否遵守了那些不能被结果抵消的约束。比如未查询订单状态就不能承诺退款，未获得权限就不能访问某类数据，未经过审批就不能执行付款，修代码时不能绕过安全检查。
第四类才是生产结果。上线以后，用户的问题有没有真的被解决，转人工率是否下降，重复追问是否减少，投诉率有没有上升，业务指标是否改善。
这四类问题的评分方法也不同。
能力上限可以看任务完成率；稳定性需要重复运行，观察连续成功率和波动；过程合规要依赖工具日志、状态检查和规则；生产结果则必须回到真实用户行为和业务结果。
把它们压成一个“综合得分”，看上去很整齐，实际往往没有什么决策价值。
一个退款Agent的综合得分从84分涨到88分，并不能告诉你它能不能上线。对业务来说，更关键的是：它是否在高风险退款场景中仍有过度承诺？它是否在订单状态缺失时愿意转人工？它有没有在某个版本之后突然漏掉核心工具调用？
评测真正服务的不是排名，而是发布决策。
03 Benchmark测能力，生产测代价
这两年，Agent领域最容易被误解的，是把benchmark分数直接等同于产品能力。
Benchmark很重要。它提供了统一任务、可复现环境和可比较的结果。没有它，大家连模型、框架和Agent harness的基本能力都很难讨论。以SWE-bench Verified为例，它把一批软件工程任务交给人工复核，确保问题描述清楚、测试补丁合理、任务可解。这样的工作，让代码Agent的比较至少有了共同语言。
但共同语言，不等于生产结论。
公开benchmark通常测的是一类被精心定义过的任务。任务边界、环境、成功标准，大多已经被提前固定。真实世界没有这么配合。
真实用户不会把需求写成标准题面。企业政策会变，知识库会更新，工具会超时，接口会返回脏数据，用户还会在任务执行到一半时改主意。更麻烦的是，Agent可以访问工具和环境本身，评测环境里一个不小心暴露的文件、一段历史记录、一个可搜索到的公开答案，都可能让它“做对”一道题，却没有真正展示出解决问题的能力。
评测里甚至会出现另一种尴尬：Agent找到了更符合用户目标的办法，却因为没有按评测预设的路径走而被判失败。
问题在于，benchmark只能回答它设计来回答的问题。
它可以告诉你，一个Agent在某类标准化任务上表现如何；却不能代替你判断，它是否能承受自己业务里的噪声、约束、风险和成本。
因此，成熟团队需要两套东西。
一套是外部benchmark，用来认识通用能力边界，也用来判断模型、框架和工具链的大致水平。另一套是内部评测集，用来检验真实业务路径。后者不必很大，却必须足够贴近自己的产品：高频任务、风险边界、历史事故、新上线工具、经常变化的政策，都应该在里面。
外部榜单可以帮你选模型。内部评测，才决定你敢不敢放权。
04 Agent评测，应该同时看任务、行为和环境
传统LLM评测常常很简单：给一个prompt，拿到一个回答，再和参考答案比较。
Agent评测至少多了两层。
第一层是任务本身。任务不应只是“请完成某件事”，还要包括初始状态、可用工具、权限边界、成功标准，以及哪些行为绝不能发生。对代码Agent来说，任务环境可能是一套仓库、依赖和测试；对客服Agent来说，任务环境可能是订单状态、用户身份、售后政策和可调用接口。
第二层是执行轨迹，也就是trace。
一个完整trace至少要记录：用户输入、Agent每一轮决策、调用了什么工具、工具入参与返回值、关键状态如何变化、发生过什么异常、任务耗时多久。复杂Agent还应记录计划、检索证据、子Agent协作和安全拦截。
没有trace，评测很容易沦为猜谜。
一个Agent回答错了，到底是意图识别错了，检索没找到，还是找到了却没用？是工具没被调用，还是工具参数错了？是模型把返回值看反了，还是外部系统本身出了异常？没有执行轨迹，团队只能从最终一句回复倒推，通常既慢又不准。
但过程评测也不能走到另一个极端。
Agent和传统流程编排的区别之一，就在于它可能找到多条合理路径。如果评测把“正确过程”写得过于死板，最后测到的就不是能力，而是它是否模仿了测试作者的操作习惯。
因此，过程评测要抓住真正不能妥协的约束，而不是要求它复刻唯一一条路径。
例如，对一个退款Agent，可以要求它在作出承诺前必须完成订单状态校验；对一个代码Agent，可以要求它在提交前运行必要测试、不得读取不该访问的文件；对一个研究Agent，可以要求它对关键事实保留来源、不能把未经证实的推断写成结论。
至于它是先查FAQ再查订单，还是先澄清用户意图再检索政策，只要不违反约束、结果可靠、成本可接受，就不该因为路径不同被扣成失败。
这也是Agent评测比传统测试更像一门系统设计的原因。你不仅在测模型，也在定义一个系统允许怎样行动。
05一套能用的评测体系，不会只产出一个分数
真正落地时，评测系统通常要由几种不同的评分方式共同组成。
能用规则判断的，就尽量交给规则。
工具有没有被调用，关键字段是否缺失，调用顺序是否违反SOP，数据库状态有没有变化，输出是否含有禁止内容，这些都不该交给语言模型猜。确定性问题用代码判，成本低、结果也稳定。
难以穷举的语义和策略问题，可以交给LLM Judge。
比如客服解释是否清楚，研究结论是否忠实使用了证据，Agent是否在信息不足时进行了恰当追问，代码修改是否除了通过测试之外还具备基本可维护性。这类问题没有简单的正则表达式，需要给Judge足够明确的评分标准、正反例和失败定义。
LLM Judge也不是“写一句请你从1到5分打分”就结束了。
它本身同样会漂移，会偏好某种表达风格，也可能更偏爱与自己同系列模型生成的答案。团队需要维护一小批人工确认过的校准样本，定期检查Judge与人工结论的一致性，特别关注它有没有漏掉高风险错误，或者把合理的多样化解法误判成失败。
人工仍然不可少，只是位置变了。
人工不适合承担每天的大规模重复判分。那样既贵，也会让标准不断漂移。更适合人工介入的，是新业务刚上线、风险规则尚未固化、多个评分器出现分歧、低置信样本、赔付隐私合规等高风险场景。人工在这里的角色，不是“替系统打所有分”，而是制定口径、裁决争议、校准自动化系统。
好的评测报告也不该只告诉你pass或fail。
它至少应该说明：问题出在哪里，证据是什么，评分器有多确定，这个问题影响哪个模块，下一步该由谁处理。否则，分数只是看板上的颜色，并不会变成研发行动。
06最值钱的部分，是把Badcase变成资产
Agent团队真正的分水岭，往往出现在第一次线上事故之后。
有些团队开会复盘，改一个prompt，问题暂时消失，过两周又换了个方式回来。有些团队会把这次失败拆成一个可复现任务，保存上下文、工具返回和trace，写清期望行为和风险点，加入回归集。下次无论换模型、改Prompt、加Skill、改工具schema，系统都必须重新通过它。
两种团队，短期看差别不大。半年以后，差别会非常大。
后者开始积累一套很难靠外部采购得到的质量资产：高质量Golden Set、线上回流的长尾样本、对抗样本、Judge校准集、根因标签、典型trace、修复方案和版本对比记录。
这些资产不是数据量越大越好。
最开始，团队完全可以只做50到200条高质量用例。它们应优先覆盖核心业务路径和P0风险：错误退款、权限越界、关键知识遗漏、工具调用失败、状态冲突、用户目标突然变化。每一条都要有清楚的成功标准和失败边界。
随着产品运行，再补进几类样本。
一类是扩展样本。围绕已经确认的业务规则，改变用户表达、订单状态、情绪强度和上下文缺失程度，检验Agent是否只会做一道原题。
一类是线上回流样本。用户投诉、人工接管、低满意度会话、异常工具调用、版本回归失败，都可能是新的评测来源。
还有一类是对抗样本。用户故意诱导越权、在多轮对话中改变目标、混入冲突信息、要求Agent忽略规则。这类样本平时占比不高，却最适合检验系统在压力下会不会失控。
Badcase入库也需要标准。一次性网络抖动、无法复现的外部故障、期望行为本身没有定论的案例，不应直接塞进核心回归集。否则，回归集会很快膨胀成一堆无法维护的噪声。
一条错误要成为质量资产，至少应满足几个条件：有稳定证据，期望行为明确，能指向某个能力域或责任模块，并且经过脱敏和合规处理。
这看起来像是很细的工程工作，却决定了Agent团队能否真正加速。
因为Agent的迭代速度很快。模型会换，Prompt会换，工具会换，业务规则也会换。没有回归体系，每一次升级都像重新赌一次；有了回归体系，团队才知道新版本到底是变好了，还是只是在另一批样本上看起来更聪明。
07从“发现错误”到“修掉错误”，中间还有一条长链路
很多eval系统停在发现Badcase这一步。
它能告诉你：这个版本的任务完成率下降了，这类问题有100条失败样本。可这还不够。研发真正需要的是根因。
以“Agent对用户作出了错误退款承诺”为例，表象是最终回复有问题，候选原因却很多：意图识别是不是把“咨询规则”误判成“申请退款”？订单查询是否失败？知识检索是否没有召回例外条款？退款Skill是否没有被触发？工具调用是否缺少关键参数？模型是否看到了正确结果，却在生成回复时忽略了它？安全护栏是否没有拦住过度承诺？
有效的根因分析，不应该让人对所有模块无差别排查。
它应该先收集证据，再缩小范围，最后定责。
先按session、trace或评测运行ID拉出完整链路。再根据问题现象缩小候选模块：答非所问优先看意图识别、Query改写和知识筛选；事实性错误优先看检索、证据保留和生成忠实性；过度承诺优先看风险规则、工具状态校验和回复生成。
随后，再检查每个候选模块的输入、输出、Prompt、工具返回和异常日志。
最后才是责任判定：主责模块是什么，问题属于哪一类，具体失败模式是什么，应该改规则、改配置、改知识库、改工具，还是改模型策略。根因标签必须稳定，才能聚类和统计；修复动作必须明确，才能进入工单和发布流程。
一个成熟的系统不会只告诉你“退款场景表现不好”。
它会告诉你：在已发货退款场景中，Agent在23次失败里有19次跳过订单状态校验；问题集中发生在某个版本的退款Skill；主责是关键工具未调用；修复方案是把状态校验变成硬性前置条件；修复后必须在核心回归集、长尾集和灰度流量中再次验证。
这时，评测才真正接上了研发。
08评测不该只在发布前出现
把评测放在上线前最后一关，已经太晚了。
Agent的质量应该随着研发节奏分层运行。
开发阶段，先测单个Skill、工具参数和关键规则。这里追求的是快速发现明显错误，规则和固定环境很有用。
版本候选阶段，再跑完整任务集和多次重复试验，检查任务质量、稳定性、成本和高风险边界。这里要有发布门禁：P0问题不通过，版本就不能发。
上线以后，离线评测并没有结束。线上仍需要看任务完成率、转人工率、重复追问、投诉、异常工具调用、延迟、成本，以及业务结果是否真的改善。离线得分上涨，线上投诉率却升高，通常意味着评测集与真实分布之间出现了偏差，或者团队优化了错误的目标。
这也是为什么trace、监控和eval最终会靠得越来越近。
Trace让团队看见发生了什么；评测判断这是否符合预期；监控告诉你问题是不是开始在真实流量中扩散；发布和回滚机制决定系统能否及时止损。把这几件事拆开采购、拆开建设当然可以，但在产品运行层面，它们是一条链。
成本也要被放进这条链里。
复杂Agent的一次完整评测，可能要跑很多轮工具调用，甚至需要构造隔离环境。每次代码合并都全量跑所有长程任务，成本和时间都难以承受。现实做法通常是分层筛查：每次变更先跑高确定性的P0用例；每天或每晚跑更大规模的回归；新模型或新工具上线前做多次试验；高风险场景增加人工抽检；线上灰度期重点监控异常信号。
评测不是越重越好。它应该把昂贵的判断留给真正值得判断的地方。
09评测会不会成为下一层Agent基础设施
我倾向于认为，会。
很多公司需要的不是再多一个只会画分数图表的Dashboard，而是一组嵌进研发和运营流程里的能力：测试环境、任务和数据集版本管理、trace采集、评分器、人工复核路由、根因分析、回归门禁、线上监控和事故回放。
模型会越来越容易替换，通用工具框架也会越来越成熟。真正难迁移的，是一家公司围绕自己业务沉淀下来的失败样本、规则边界、用户行为和修复经验。
这也是Agent时代一种很现实的壁垒。
一家做企业客服的公司，最有价值的未必是“会调用几个模型”，而是它知道哪些订单状态最容易引发错误承诺，哪些政策组合会让模型误解，哪些用户说法看似普通却需要转人工。一个代码Agent团队最有价值的未必是榜单上的一次高分，而是它能否证明：在自己的代码库、权限体系、CI环境和成本预算里，这个Agent可以持续、稳定地完成工作。
模型能力决定Agent能做到什么。
评测体系决定一家企业是否知道，它做到了没有，哪里没做到，以及下一步该怎么改。
10不必先搭一个大平台，先把失败留下来
对于正在做Agent的团队，最实际的起点并不复杂。
先挑出最常见、最重要，也最容易造成损失的任务。把成功标准写清楚，把不能碰的红线写清楚。不要一开始追求几千条样本，也不要先做一个漂亮的看板。
然后要求每次关键运行都留下trace。没有trace，就没有有效的复盘。
再把规则、模型Judge和人工复核放在各自适合的位置。规则处理硬条件，Judge处理语义和策略，人工处理高风险与不确定性。每次线上出现真正重要的Badcase，都问同一个问题：它能不能变成一个下次自动发现的问题？
能，才入库。
做过一段时间以后，团队会发现，评测最有价值的产物不是分数，而是一份越来越清楚的“失败地图”。它告诉你这个Agent最常在哪些地方误解用户，哪些工具最容易被误用，哪些业务规则最难被遵守，哪些看似不错的版本其实已经埋下了回归。
到那时，评测就不再是QA的附属工作了。
它成了团队理解Agent、约束Agent、改进Agent的共同语言。
Agent的竞争当然还会围绕模型、算力、数据和工具展开。但当越来越多产品跨过“能跑”的阶段，真正拉开差距的，往往是那些不太适合放在发布会里的能力：谁能更早发现错误，谁能把错误稳定地追到根因，谁又能让同一个错误不再回来。
谁能把失败变成下一次发布前就能识别的资产，谁才更接近真正的生产级Agent。