很多团队能把智能体做出漂亮的演示，却说不清它到底有多可靠。问题不在模型，而在缺一套评估：没有尺子，所有优化都只能靠感觉。这篇文章讲清评估该从哪儿开始。
一、演示好看，不等于真好用
先说一个经验：在演示里表现惊艳的智能体，上线后大概率会让你失望。不是因为团队造假，而是因为演示只走「顺利路径」。
真实任务里，输入往往是不完整的、格式是乱的、需求是含糊的。演示回答的是「它能不能做到」，而实际使用要回答的是另外两个问题：多大概率能做到，做错了代价有多大。
没有评估的团队会遇到一个很具体的痛苦：改了一版提示词、换了一个模型，却不知道是变好了还是变差了，只能凭感觉。所有的优化都变成玄学。
二、先把「办成了」定义清楚
评估的第一个难题不是技术，而是标准：什么算成功？这个问题答不上来，后面全是白忙。
好标准的关键是「可判定」：结果对不对、文件有没有生成、格式合不合规、数字准不准。像「回答得好不好」这种描述，听着合理，但无法打分，也就无法比较。
定义清楚之后，评估通常会分成三个维度：任务完成度（成了还是没成）、质量（好、一般、差）、代价（花了多少步、多少 Token、需要多少次人工介入）。只有三个维度都看，评估才不会被单一指标带偏。
三、三个层次的评估，从便宜到真实
工程上习惯把评估拆成三层，成本和可信度逐层上升：
▪︎ 单步能力：给一个明确输入，看输出对不对。便宜、快、好回归，但容易高估整体能力；
▪︎ 端到端任务：给一个真实任务，看最终交付成不成。这是核心指标，最接近用户的真实感受；
▪︎ 线上表现：上线后的真实数据——成功率、人工接管率、投诉率。它才是最终答案，只是反馈慢。
三层缺一不可：只看单步，会盲目乐观；只看线上，发现问题时已经付出代价。
四、三个最常见的坑
即使搭了评估，也未必测得准。下面三个坑几乎每个团队都踩过：
▪︎ 只测顺利路径：评测集里全是标准题，一遇到输入不完整、格式错乱就崩，而线上恰恰全是这种情况；
▪︎ 自己出题自己打分：出题的人和被评的对象是同一批人，等于自证，分数再高也没有意义；
▪︎ 用模型评模型：让另一个模型当裁判，便宜但不可靠——它往往偏爱「说得漂亮」的答案，而不是「做得对」的结果。
第三个坑值得多说一句：自动评分可以用，但只适合做筛子（把明显离谱的挑出来），不能当尺子（用它定最终分数）。
五、小团队怎么低成本把评估跑起来
看到这里可能会觉得评估很重。其实起步阶段不需要平台，一张表就够了：
▪︎ 从 20 到 50 条真实任务开始：直接从客服记录、工作群、工单里捞，不要自己编；
▪︎ 每条都写上「正确答案应该是什么」，否则没法判分；
▪︎ 每周跑一次，同时记下失败类型：工具选错、参数写错、漏了步骤、还是凭空接造；
▪︎ 看趋势而不是绝对值：这一版比上一版多成了几单，比「得了 90 分」有意义得多。
当失败类型的分布稳定下来，你就能看出真正的短板在哪里，也就知道下一个优化该往哪儿使劲。
结语
评估不是学术仪式，它是你唯一能证明「这一版比上一版好」的东西。没有它，所有的优化都只能靠感觉；有了它，智能体才从「看起来挺厉害」变成「可以放心交付」。前者是演示，后者才是产品。
