Agent质量怎么评？

事情是这样的。前阵子有个做 AI 产品的朋友找我说他遇到点麻烦。他们团队做了个客服 Agent内部测试的时候准确率 90 多Demo 演示效果很好老板看了很满意拍板上线。结果上线一周客服工单炸了。用户骂得很难听。「这 AI 是智障吧」「问它退换货它给我推荐新品」截图满群飞。他回去翻评测分数还是 90 多分。分数没变但产品已经翻车了。我听完一点都不觉得意外。真实用户问题会千奇百怪操作顺序完全不讲逻辑给你的数据可能是脏的乱的错的。有的用户什么都不干就是多跟你聊两轮Agent 自己就跑偏了。更要命的是Agent 这玩意儿有随机性。同一个问题今天答对了明天可能就给你整出个新花样。你手动跑十遍八遍根本覆盖不过来。我跟他说你的问题不是模型不行。是你压根没有一套靠谱的方法去判断你的 Agent 到底行不行。后来翻了 Gartner 2026 年的报告发现这真不是个例。缺乏系统化评测体系的 Agent 项目上线后故障率是成熟项目的4.2 倍。还有一个数字更狠。到 2027 年40% 的 Agentic AI 项目会被直接砍掉。40%。接近一半。很多团队都卡在这。Agent 做出来了Demo 效果也不错但真到要上线那一下心里开始发虚。评测这事偷不了懒说实话我一开始也没把评测当回事。每改一版 Agent手动跑几个 case 看看效果跑通了就继续下一版。觉得效果还行就往前推评测这种事等做完了再说。后来发现问题了。你手动跑的那几个 case是你自己挑的。输入是你准备的问题是预期的用户的操作路径也是你能想到的。变量全被你控制了Agent 当然能跑通。线上不是这样。真实用户的操作是不可控的。有人一句话里塞了三个问题有人上一秒问退货下一秒改地址有人给的数据格式乱七八糟。这些情况你手动测的时候想不到。更麻烦的是 Agent 有随机性。同一个 case 今天跑是对的明天可能就不一样了。手动跑十遍覆盖不过来你永远不知道没跑的那些场景会出什么问题。Anthropic的工程团队也聊过这个事。靠手动测试和直觉能走得很远但 Agent 投入生产之后没有 eval 的开发就开始崩溃。你不做评测就永远不知道你的 Agent 在多少场景下是挂的。你看到的只是测过的都过了没测过的地方是个黑盒。评测就是帮你把黑盒打开。你不一定要把每个角落都测到但你至少得知道哪些地方有坑坑有多大上线的时候心里才有数。为什么传统测试的那套不够用了如果你是测试出身第一反应可能是这不就是软件测试吗。写 case跑断言覆盖率搞上去不就完了。我一开始也这么想的。后来发现真不是。传统软件测试有个前提输入确定输出就确定。你给函数传两个参数 2 和 3它就应该返回 5。不返回 5 就是 bug逻辑清晰断言好写。但 Agent 完全不是这个玩法。第一Agent 是多步的。它不是一问一答是要自己规划、自己调工具、走好几步才能拿到结果。中间任何一步走偏了最后的输出就不对。你光看最后答案对不对定位不了问题出在哪一步。第二Agent 要调工具。调对了工具没有参数传对了没有调用顺序合不合理这些都会影响结果。而工具调用的正确性传统断言很难覆盖。第三Agent 有自主性。同一个任务它这次可能走 A 路径下次走 B 路径两条路都能到终点。你不能说它没按你预设的路径走就是错的。第四也是最要命的一点。同一个任务跑多次结果可能不一样。这四条加在一起传统的「输入→输出→断言」就不够用了。你得换一套思路。核心原则评产出不评路径Anthropic 那篇指南里有一句话我觉得是整篇文章最值钱的一句。Grade what the agent produced, not the path it took评 Agent 产出了什么别评它怎么走的。因为 Agent 经常能找到评测者没想到的合法解法。你要是卡死路径会把对的判成错的。这个思路一旦想通了评测体系的设计就有了方向。你盯住的是最终状态对不对。数据库改对了没有用户的单退了没有文件生成对了没有。至于 Agent 中间先调哪个工具后调哪个工具走了几步弯路不重要。评测工具得选对光有思路不够得有趁手的工具。但选工具之前得先把一件事搞清楚。Agent 评测这块工具分两类。一类叫 benchmark俗称标准考场。固定题目固定评分Agent 丢进去跑一圈给你一个横向对比的分数。测的是「别人出的卷子你考多少分」。另一类是评测框架你自己出题自己考。把自家业务 case 喂进去按自己的标准打分。测的是「你自己的 Agent 行不行」。两类的定位完全不同。搞混了工具再好也白搭。第一类标准测试集benchmark 里AgentBench是绕不过去的一个。清华和人大搞的覆盖面广。八个环境操作系统、数据库、知识图谱、卡牌游戏、逻辑推理、家务任务、网购、网页浏览。Agent 跑一圈能看出来它通用能力几斤几两。测试集 13000 多条多轮交互样本横向对比了 27 个模型。你选底座模型的时候AgentBench 是个不错的参考。毛病也有。离真实业务场景有点远。你做的是客服 AgentAgentBench 测的是它能不能玩好卡牌游戏多少有点错位。如果你做的是研发方向的 Agent写代码、修 bug 这类SWE-Bench更对路。Princeton 弄的从 GitHub 上扒了 2294 个真实 issue让 Agent 去修。判分方式很硬核直接跑仓库里的测试用例过就是过不过就是不过。没有 LLM 当评委那种主观分。软件工程场景里目前 SWE-Bench 是最权威的一把尺。第二类评测框架benchmark 到此为止接下来聊评测框架。这一类才是真正落到你自家 Agent 头上的。DeepEval我自己用得多。开源Apache 2.0 协议对接 pytest。写法和写单测一模一样把 Agent 的输出当断言对象。内置 50 多个指标G-Eval、任务完成度、faithfulness常用的都有。还支持按步骤打分多步任务里每一步都能单独评。本地跑不依赖云服务。CI 里直接集成每次改完代码自动跑一轮。如果你的 Agent 是用 LangChain、LangGraph 那套搭的LangSmith顺理成章。闭源免费档够个人用。强项是 trajectory eval。Agent 跑一遍整条决策链路摆出来你可以挂 LLM-as-Judge 自动判也可以进 annotation queue 一条条人工过。debug 也方便。哪一步调错了工具、哪个 prompt 漏了信息trace 里一目了然。OpenAI Evals是老牌了MIT 协议。设计上偏 registry 那套一个 case 注册进去可复现地跑。Completion Function Protocol 这个抽象让它能测带工具调用的 Agent。但上手成本不低。配置比较重文档说实话也不算特别友好。新项目用它得掂量一下。这五个不是五选一。AgentBench和SWE-Bench是选型阶段用的看底座够不够强。DeepEval、LangSmith、OpenAI Evals 是开发阶段用的盯你自己的 Agent。选型用 benchmark开发用评测框架。别搞反了。Agent 质量保障体系评测体系搭好了离线指标都跑通了是不是就可以安心上线了。还不够。离线评测再全面也覆盖不了线上所有情况。用户会问出你测试集里没有的问题会出现你没想到的操作组合甚至会有恶意攻击。所以一套完整的 Agent 质量保障体系应该是三层架构。第一层离线评测。就是前面聊的那些。上线之前把能测的都测了。基准测试、业务场景测试、边界 case 测试。这是地基没有这层你心里没底。第二层红队测试。这一层很多人会漏。红队测试就是主动找 Agent 的漏洞往死了里整。注入恶意 Prompt构造对抗场景诱导 Agent 违反规则做不该做的事。Agent 这个东西有个要命的特点它犯错的时候看起来特别有道理。一个被 Prompt 注入的 Agent可能一本正经地把不该给的数据给了用户整个过程行云流水你光看对话记录都觉得没毛病。所以红队测试不是可选项。尤其是你的 Agent 要碰敏感数据或者核心业务的时候。自己不整它上线之后被人整代价完全不一样。第三层在线监控。Agent 上线之后你得盯着。响应延迟有没有突增任务完成率有没有掉用户投诉有没有异常增多。这层最难的是成本和延迟的平衡。你不可能每个请求都做深度评测太慢太贵。你得设计轻量级的检查点在不影响用户体验的前提下把异常捞出来。这三层合在一起才是完整的质量保障。离线评测兜底红队测试找漏洞在线监控守防线。缺了任何一层都是在裸奔。给落地团队的四条建议道理讲了这么多真正落地的时候我自己踩坑之后总结了几条。第一评测数据要跟真实业务对齐。不要拿一堆公开数据集跑个高分就觉得行了。公开数据集和你的业务场景差了十万八千里。优先从真实业务数据里采脱敏之后构建自己的测试集。这个测试集才是你的底牌。第二LLM as Judge 要校准。很多团队用强模型给弱模型打分又快又省。但 Judge 模型自己也会犯错也会有自己的偏好。你得先拿一批人工标注的数据校准你的 Judge 模型确认它的打分和人工打分基本一致。不校准的 LLM as Judge结果可信度要打问号。第三评测要持续做不是一次性的。Agent 不是上线就完事了。模型更新了工具变了业务规则调整了Agent 的表现都会变。你得有一套持续评测的机制定期跑有问题及时发现。评测要内建到开发流程里不是外挂的。第四不要追求一步到位。一上来就想搭一套大而全的评测体系往往搭不起来。先从最关键的几个业务场景开始先把 pass¹ 和工具调用准确率跑通。等 Agent 真正上线了再逐步加 pass^k、红队测试、在线监控。评测体系是跟着 Agent 一起长大的。你第一次搭的肯定不完美但不完美有比没有强太多了。写在最后回到开头那个数字4.2 倍。这不是一个抽象的统计数字背后是一堆真实翻车的 Agent 项目。我看过太多团队的做法了。做 Demo 的时候热情高涨谈评测的时候面露难色上线之后祈祷平安。祈祷当然没用该翻的车一辆都少不了。Agent 这个东西跟传统软件最大的不同在于它的行为是概率性的不是确定性的。概率性的东西你不能靠感觉判断你得靠数据。评测体系不是为了给你一个好看的高分让你去汇报。它的价值是在你上线之前告诉你哪些地方会翻车翻车的概率有多大你能不能接受这个风险。它不是为了证明你的 Agent 有多好而是为了让你清楚地知道它有多差差在哪差多少。