事情是这样的。
前阵子有个做 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 那篇指南里有一句话，我觉得是整篇文章最值钱的一句。
bash
Grade what the agent produced, not the path it took评 Agent 产出了什么，别评它怎么走的。
因为 Agent 经常能找到评测者没想到的合法解法。你要是卡死路径，会把对的判成错的。
这个思路一旦想通了，评测体系的设计就有了方向。
你盯住的是最终状态对不对。数据库改对了没有，用户的单退了没有，文件生成对了没有。至于 Agent 中间先调哪个工具后调哪个工具，走了几步弯路，不重要。
评测工具，得选对
光有思路不够，得有趁手的工具。
但选工具之前，得先把一件事搞清楚。Agent 评测这块，工具分两类。
一类叫 benchmark，俗称标准考场。固定题目，固定评分，Agent 丢进去跑一圈，给你一个横向对比的分数。测的是「别人出的卷子你考多少分」。
另一类是评测框架，你自己出题自己考。把自家业务 case 喂进去，按自己的标准打分。测的是「你自己的 Agent 行不行」。
两类的定位完全不同。搞混了，工具再好也白搭。
第一类：标准测试集
benchmark 里，AgentBench 是绕不过去的一个。
清华和人大搞的，覆盖面广。八个环境，操作系统、数据库、知识图谱、卡牌游戏、逻辑推理、家务任务、网购、网页浏览。Agent 跑一圈，能看出来它通用能力几斤几两。
测试集 13000 多条多轮交互样本，横向对比了 27 个模型。你选底座模型的时候，AgentBench 是个不错的参考。
毛病也有。离真实业务场景有点远。你做的是客服 Agent，AgentBench 测的是它能不能玩好卡牌游戏，多少有点错位。
如果你做的是研发方向的 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 有多好，而是为了让你清楚地知道，它有多差，差在哪，差多少。