你肯定见过这种场面Demo 会上Agent 行云流水老板眼睛放光当场拍板「下周上线」。然后呢上线两周效果还行三周之后幻觉率上来了人工接管率上来了业务投诉也上来了。Demo 和生产的差距比你想的大得多。问题出在哪出在评测。大多数团队根本没搞评测或者只搞了「离线准确率」这种自欺欺人的东西。先别急着反驳。你可能会想「我们当然测了上线前跑了几百个用例准确率 95% 呢。」但我要问的是你那几百个用例是从哪来的如果是业务专家手写的「标准问题」那大概率是白测——因为专家觉得「正常用户不会这么问」结果线上全是「这么问」的。评测这件事难的不是「跑用例」是「用例从哪来、测什么、怎么判断好坏」。先泼盆冷水为什么 Demo 会骗人Klarna 当年 AI 客服上线首月处理 230 万次对话响应时间从 11 分钟压到 2 分钟媒体一片叫好。结果呢退货争议、账户问题、复杂策略的边缘案例AI 处理得一塌糊涂。2025 年 5 月Klarna 的 CEO 自己承认「走得太远了」开始往回招客服。Salesforce 更惨裁了约 4000 个客服岗位换 AI后来被质疑客户满意度下滑又把客服工作改成「一半 AI 一半人工」。这俩案例说明什么说明离线 Demo 测不出线上真实场景。Demo 里那 20 个精心挑选的问题掩盖了长尾里 80% 的复杂情况。你测的是「模型能不能答对」线上要的是「能不能把事办成」。我想把「Demo 为什么骗人」拆开讲。Demo 骗人不是因为它造假而是因为它「选择性展示」。你准备 Demo 的时候会本能地挑那些「模型答得好」的问题——这是人之常情谁也不会拿一个答不对的问题去演示。但线上的问题是「长尾分布」的80% 的问题集中在少数高频场景剩下 20% 是千奇百怪的边缘案例。Demo 只覆盖了那 80% 里最好答的一部分边缘案例一个都没碰到。所以 Demo 的「准确率 100%」跟线上的「准确率 80%」测的根本不是一回事。更麻烦的是Demo 测的是「答对」线上要的是「办成」。客服 Agent 答对「退款流程是什么」很容易但「真的帮用户把退款办下来」很难——后者要调系统、要验证身份、要处理异常。你 Demo 里测的是前者线上要的是后者这中间的差距评测体系不建起来永远发现不了。评测要测四件事不是一件事我后来把评测拆成四个维度缺一不可任务完成率1000 笔申请920 笔结果跟人工复核一致完成率就是 92%。这是最核心的指标。决策准确率Agent 在推理步骤里的正确比例。比如风控场景症状匹配、规则判断每一步对不对。效率指标响应时间、任务耗时、人工介入率。人工介入率尤其关键——介入越多说明 Agent 越不顶用。安全合规数据泄露、越权操作、内容违规。这条不过前面全白搭。这四个维度我想逐个讲一下为什么缺一不可以及怎么测。「任务完成率」是最核心的因为它测的是「事办成了没有」。怎么测拿真实业务数据回放——把过去一段时间的人工处理记录拿出来让 Agent 重新处理一遍看结果跟人工一致的比例。这个指标最接近「线上真实效果」因为它用的是真实业务、真实数据、真实判断标准。「决策准确率」测的是「每一步对不对」。为什么单测这个因为任务完成率是「结果」决策准确率是「过程」。有时候结果对了过程是歪的——比如风控 Agent 碰巧拦对了一笔欺诈但判断依据是错的。这种「碰巧对」在线上是隐患因为换个场景就露馅。所以要把 Agent 的推理步骤拆开一步步验证。「效率指标」里我最看重「人工介入率」。这个指标特别诚实——Agent 越顶用需要人介入的就越少介入越多说明 Agent 越不顶用。而且人工介入率是「线上指标」离线测不出来必须上线后看真实数据。所以它既是评测指标也是灰度放量的决策依据。「安全合规」这条很多人觉得「跟效果无关」其实它是「一票否决」项——数据泄露、越权操作、内容违规任何一条出了事前面三个维度做得再好都白搭。所以安全合规要单独测、单独盯不能混在效果指标里。评测脚本不难写难的是想清楚测什么# 一个最朴素的 Agent 评测循环defevaluate(agent,cases):totallen(cases)done0escalated0forcincases:resultagent.run(c[input])ifresult.statusDONEandresult.outputc[expected]:done1ifresult.statusESCALATED:escalated1return{task_completion:round(done/total,3),# 任务完成率escalation_rate:round(escalated/total,3),# 人工接管率}# 跑一遍看数字别信感觉print(evaluate(my_agent,production_cases))这个脚本粗但方向对评测集必须来自真实生产数据不是手工挑的「漂亮案例」。评测集怎么攒从线上捞别自己编攒评测集这事我踩过坑。一开始我们让业务专家手写测试用例写得又慢又偏——专家觉得「正常用户不会这么问」结果线上全是「这么问」的。后来改成从线上日志捞真实对话按场景分层抽样再让专家标注正确答案。效果立竿见影。评测集要持续更新。Agent 上线后每周把新增的失败案例、用户投诉、人工接管记录回填进评测集。这样评测集才能跟着业务长。为什么「从线上捞」比「专家手写」靠谱因为线上日志是「真实分布」专家手写是「想象中的分布」。真实用户的问题带着口语、错别字、上下文省略、情绪——专家写不出来这些。而且线上日志能反映「长尾」——那些专家想不到的奇葩问题日志里全都有。所以评测集的第一原则从线上捞别自己编。评测集还要「分层」。不是随机抽几百条就完事要按场景分层高频场景多抽、低频场景也要有、边缘案例必须覆盖。不然评测集又会偏向「好答的问题」重蹈 Demo 的覆辙。评测集要「持续更新」这个很多人会忽略。业务在变——新产品上线了、政策改了、用户问法变了评测集不跟着变就会「过期」——测出来的准确率虚高线上实际效果已经下滑了。所以评测集不是「建一次就完事」是「每周回填」的活。灰度是评测的「线上补考」离线评测做得再好也只是「模拟考」。真正的大考是灰度。别一上来就全量发布。先放 5% 的流量盯三个指标agent_error_rate目标 0.5%、tool_call_failure_rate每个工具单独盯、human_escalation_rate人工接管率。指标稳了再逐步放量。出问题随时回滚——生产环境至少保留两个可用版本Prompt 变更也要可审计、可回退。为什么灰度这么重要因为离线评测再全面也覆盖不了「线上真实环境」——真实流量、真实并发、真实数据、真实用户行为。灰度就是让 Agent 在「小范围真实环境」里先跑用真实数据验证指标稳了再放量。这比任何离线评测都可靠。灰度放量不是「拍脑袋」是「看指标」。5% 流量跑一周三个指标都稳放到 20%再稳放到 50%全稳才全量。任何一个指标异常立刻回滚。这套流程听着繁琐但能避免「全量上线翻车」这种最惨的结局。有个千万级 AI 项目就是这么死的测试环境准确率漂亮生产环境性能断崖式下跌为了低延迟绕过数据治理触了数据安全红线被叫停加了审批校验之后延迟又飙到 3 秒以上。一步错步步错。这个项目我多说两句因为它把「评测和灰度的坑」踩了个遍。测试环境准确率漂亮——因为评测集是「漂亮案例」生产环境断崖下跌——因为真实数据跟测试数据分布完全不同绕过数据治理——因为只盯着「性能」不看「合规」加审批后延迟飙到 3 秒——因为架构设计时根本没考虑审批环节的开销。每一步单看都是「小决策」连起来就是「大事故」。如果它有灰度至少能在 5% 流量时发现问题不至于全量翻车。反常识的结论评测比模型重要说了这么多我想表达的核心就一句在 Agent 这件事上评测体系比模型选择重要得多。模型不行可以换评测体系不行你连「不行」都发现不了。Manus 当年靠演示视频火遍全网邀请码一度炒到 5 万估值冲到 5 亿美元最后裁员退出市场。它缺的不是模型是经得起真实数据考验的评测和工程。这句话怎么理解你想想模型是「可替换的」——今天用这个明天换那个效果差不了太多。但评测体系是「不可替换的」——它决定了你能不能发现「模型变差了」「数据过期了」「业务变了」。没有评测体系你就像蒙着眼开车——车好不好不知道路况怎么样也不知道只能等撞了才知道。所以我说评测比模型重要不是贬低模型是提醒你别把精力放错地方。顺带一提我自己的雷达鸭那个收录一人公司赚钱案例的小程序里问答助手也套了这套评测思路的简化版——每周从对话日志捞失败案例回填测试集。个人项目规模小但道理一样没有评测你永远不知道它什么时候开始变傻。评测这关过了Agent 才算真正「能上线」。下一篇聊聊上线之后的事——监控、成本和回滚。10 年软件开发经验软件设计师、人工智能应用工程师主要折腾鸿蒙应用开发ArkTS和 Web 前端也爱琢磨 AI 自动化不定期在 CSDN 分享鸿蒙和 AI 方向的技术文章。本文遵循 MIT 协议转载请注明出处。