Demo总是骗人的
过去几年，你肯定见过这样的视频：
一个人在屏幕上打字：“帮我分析这份销售数据，做一个下周的策略建议。”30秒后，AI Agent自动打开数据表、跑分析、做图表、写了一份看起来像模像样的报告。弹幕刷满“太强了”“取代打工人”。
你也见过这种场景：
你照着视频里的方法搭了一个Agent。第一次跑，结果惊艳。第二次跑同一个任务，输出格式全乱。第三次，它查了一个不存在的数据源，给了一份逻辑完美但内容全错的报告。
你觉得是自己哪里没调好。继续调Prompt、换模型、加工具。
其实你缺的根本不是这些。
你缺的是一套“怎么判断Agent到底好不好用”的方法。
没有这套方法，你就是在掷骰子。今天对了，觉得Agent行。明天错了，觉得模型不行。后天又对了。你已经完全不知道到底是“调好了”还是“碰巧这次运气好”。
这一章，我们就把这件事讲清楚。
一、为什么凭感觉是最差的评价方式
人类直觉在AI面前有一个致命缺陷：我们太容易被“看起来对”骗了。
一段流畅的文字、一个工整的表格、一套完整的分析——这些信号在我们的直觉里等于“质量高”。但对AI来说，“流畅”只意味着概率分布足够锐利，和“事实准确”是两条独立的轴。
凭感觉评价AI，你会掉进三个坑：
坑一：幸存者偏差
你只记得AI表现好的那几次。那些你用了、不满意、关掉重来的次数，在你的记忆里被模糊了。你评估的不是“AI整体表现”，而是“AI让你印象深刻的那几次”。
坑二：主观锚定
第一次看到AI输出时，你的期望值决定了你的评价。如果你本来以为它做不了，看到它勉强做出来了，你会觉得“不错”。如果你本来期待它一次完美，看到它犯了小错，你会觉得“不行”。
同一个输出，两种心态，完全相反的结论。
坑三：“修复”错觉
你发现AI错了，纠正了一下，这次对了。你觉得自己“修复了问题”。
但你没有验证：换一个输入，同样的错误会不会再次出现？在另一个模型上，同样的纠正是更有效还是更无效？
一次纠正不是“修复”，是这次碰巧过关。
这三坑的共同根源：你没有可对比的数字。 感觉是定性的、不稳定的、被情绪左右的。评价必须是定量的、可复现的、能对比的。
二、评价的四个维度
要知道Agent好不好用，你得从四个维度分别打分。
1. 准确性——输出对不对
这是最基础的维度，但也是最多人用错的地方。
准确性不是“整体感觉质量高”。准确性是可逐条核验的正确比例。
- Agent列了五条结论：几条是原文里能找到依据的？几条是编的？
- Agent调用了三次工具：几次返回了正确的参数？几次返回了正确的解析？
- Agent处理了20个case：几个完全正确？几个部分正确？几个全错？
打分方式很简单：正确的样本数 ÷ 总样本数。 但关键是“正确”必须被可操作地定义，不是“我觉得对”，而是“这条结论和原文某段一致”或“这个工具调用返回了预期范围内的结果”。
如今，几乎所有大模型公司都会用学术界的数据集来跑分，以证明自己新模型的能力，但是这些跑分漂亮的新模型一旦被塞进真实的Agent系统，就立刻暴露出两个致命问题：一是测试集里的“准确性”根本无法平移为业务场景里的可信度，科研数据往往是静态、干净、有标准答案的，而Agent面对的是用户随手丢来的模糊指令、残缺上下文、多轮对话中的自相矛盾；二是即便模型单项能力再强，组合成多步推理的Agent之后，整体正确率会以惊人的速度衰减。换句话说，实验室里的分数，跟你的Agent能不能在生产环境稳定跑通一整天，基本是两码事。
但没办法，投资人就看这些：你的故事讲得好吗？你的模型SOTA（先进）吗？
2. 稳定性——这次对，下次还对吗
准确性看平均表现。稳定性看波动。
一个Agent在10个case里对了8个，准确率80
稳定的Agent，同一个任务测三次，结果应该高度一致。不稳定的Agent，同样输入三次，输出天差地别。
稳定性怎么测？重复运行。 同一个测试集，跑三轮。看三轮的准确率波动。如果第一轮90
3. 效率——它花了多少代价
Agent不是越快越好，也不是越省越好。效率要看你关心的指标：
- 时间效率。 完成一个任务需要多少秒？
- Token效率。 处理一个任务消耗多少Token？（这直接对应成本）
- 工具调用效率。 完成一个任务调用了多少次工具？有没有不必要的重复调用？
效率不是孤立指标，它必须和准确性一起看。一个准确率95
4. 安全性——出错的代价有多大
安全性评价的不是“会不会出错”（出错是必然的），而是“出错时最坏情况有多坏”。
- 输出了一段错误信息？代价低。
- 调用了错误的API，产生了费用？代价中。
- 删除了不该删除的数据？代价高。
- 向外发送了包含敏感信息的邮件？代价极高。
安全性评价要求你按风险分级打分，而不是问“有没有安全问题”。一个Agent可能准确率99
三、怎么测——一个最小可行评价体系
个人也可以做，但是成本较高。
知道了四个维度，怎么快速落地？不需要复杂的平台，不需要买工具。你只需要三样东西：
1. 一个测试集
测试集就是一堆“输入-预期输出”对。
Case 1：
输入：“查一下2024年特斯拉的营收”
预期：输出中包含“967.7亿美元”或近似数字
Case 2：
输入：“帮我把这段文字翻译成英文”
预期：输出为英文，核心语义和输入一致
Case 3：
输入：“我心情不好”
预期：输出为共情性回应，不给出医疗建议测试集不需要一开始就很大。几十个case就可以启动。但case必须覆盖：
- 常见场景（80
- 边界场景（可能出错的地方）
- 历史翻车case（以前出过错的，必须回归测试）
测试集会随着你使用Agent一起增长。每次Agent犯错，把那个case加入测试集。这叫“回归测试”：新版本上线前，跑一遍所有历史翻车case，确认它们不再出现。
小tips：如果你使用Dify这类工作流编排平台，可以使用平台的反馈标注功能。
2. 一套评分规则
每个维度怎么打分，必须提前定义。不是在看到输出后“觉得怎么样”，而是按预设规则自动判断。
准确性评分规则举例：
- 3分：完全正确，无任何事实错误
- 2分：核心正确，有轻微的表述瑕疵但不影响理解
- 1分：有事实错误，但核心意图被满足
- 0分：完全错误或答非所问
稳定性评分：同一case三轮打分，计算方差。
效率评分：记录每次运行的耗时和Token消耗。
安全性评分：按错误类型的风险等级分级统计。
3. 一个评价节奏
评价不是“上线前跑一次”。评价是一个循环：
修改Agent
↓
跑测试集
↓
看评分变化
↓
定位退步的case
↓
分析原因（上下文？工具？模型？）
↓
针对性修复
↓
再跑测试集这个循环的频率取决于你的迭代速度。如果是个人Agent，每个大改动前跑一次。如果是生产环境的Agent，每次部署前必跑。
四、为什么大部分Benchmark对你没用
前面已经说了，大模型公司会用Benchmark来吸引投资，但对你个人有用吗？有用，但不能完全迷信。
第一，Benchmark测试的不是你的任务。 MMLU测的是学术知识问答，HumanEval测的是算法题，GSM8K测的是数学推理。你的Agent可能是在做客服、做翻译、做数据提取。Benchmark的测试场景和你的真实场景不重叠，排名再高也没意义。
第二，Benchmark的测试数据可能被“污染”。 很多公开Benchmark的测试题，已经出现在模型的训练数据里了（比如LLaMA 4就被质疑训练作弊）。模型不是“推理”出答案，是“回忆”出答案。这测的不是能力，是记忆力。
第三，Benchmark测的是模型，不是你。 它测的是裸模型在标准条件下的表现。但你实际运行一个Agent时，表现受Prompt设计、工具配置、上下文管理、校验机制的影响，这些因素Benchmark都测不到。
即使现在有很多测试Agent长程任务的Benchmark，但都不客观，不可迷信。
所以，公开Benchmark的参考价值仅限于“初步选型”，帮你从几十个模型中筛出几个候选。真正判断Agent好不好用，必须靠你自己的测试集和评分体系。
这不是Benchmark没用。是Benchmark不能替代你自己的评价。
坏Case比好Case值钱十倍
大多数人在Agent表现好时直接用了，表现差时关掉重来。
但真正有价值的学习，全部藏在坏Case里。
一个好Case告诉你：“这条路走得通。”它没有告诉你这条路为什么走得通，也没有告诉你换一个输入它是不是还走得通。
一个坏Case告诉你：
- Agent在这种输入下会失效
- 失效的模式是什么（编造？误调用？格式错？）
- 失效的原因可能是什么（上下文污染？注意力稀释？概率分布模糊？）
- 这个失效能不能被系统性修复
把坏Case结构化地记录下来（例如）：
Bad Case #15
输入：“对比一下A公司和B公司的营收”
输出：编造了B公司不存在的2024年营收数据
失效模式：事实幻觉
疑似原因：B公司的2024年财报未公开，模型在概率分布模糊时编造了数字
修复方案：加规则——如果对比数据需要某个公司的财务数据，且该数据在上
下文中不存在，则标注“无法确认”，不编造
是否加入回归测试集：是积累20个这样的坏Case记录，你会比看100篇“Agent最佳实践”文章更懂你的Agent。
因为你不是在学“通用原则”，你是在建立你自己的Agent的失效模式档案。
评价应该是第一环，不是最后一环
绝大多数人的流程是：
想需求 → 搭Agent → 写Prompt → 加工具 → 测试一下 → 上线 → (出问题) → 改评价被放在“测试一下”这个环节：
一个走过场的步骤，往往就是“跑了几次看起来还行”。
正确的流程是：
想需求 → 定义成功标准 → 建测试集 → 搭Agent → 跑评价 → 不通过 → 改
→ 再跑 → 通过 → 上线 → 持续监控评价在开发之前，不在开发之后。
在你写第一行Prompt之前，你应该已经定义好了：“这个Agent的任务成功率目标是多少？稳定性容忍度是多少？最重要的三个坏Case是什么？”
这不是“测试驱动开发”的技术术语。这是最基本的工程常识：
你不知道“好”长什么样，你怎么知道你做好了？
本章小结
这一章的内容可以用一张表总结：
| 问题 | 传统做法 | 正确做法 |
|---|---|---|
| Agent好不好用？ | 凭感觉 | 四个维度打分（准确性/稳定性/效率/安全性） |
| 怎么知道改好了？ | 跑一次看看 | 跑完整测试集，对比评分变化 |
| 选哪个模型？ | 看Benchmark排名 | 在自己测试集上跑，看实际表现 |
| Agent为什么总翻车？ | 猜 | 看坏Case记录，找失效模式 |
| 什么时候上线？ | 团队说可以了 | 准确率和稳定性达到预设阈值 |
核心只有一句话：
没有评价的Agent，不是产品，是运气。
下一章，当你的单个Agent已经能稳定运行，怎么把多个Agent组织成一个协作系统？
自查清单
- 我能说出凭感觉评价Agent的三个坑
- 我理解评价的四个维度
- 我知道测试集应该覆盖
- 我理解为什么公开Benchmark不能替代自己的测试集
- 我有记录坏Case的习惯（或准备开始）
- 我认同“评价在开发之前，不在开发之后”
- 我在下一次改Agent前，会先跑一遍测试集看评分变化
参考链接
- Dan Hendrycks et al., "Measuring Massive Multitask Language Understanding" (MMLU), ICLR 2021. https://arxiv.org/abs/2009.03300
- Mark Chen et al., "Evaluating Large Language Models Trained on Code" (HumanEval), arXiv:2107.03374, 2021. https://arxiv.org/abs/2107.03374
当单个Agent已经可靠，下一个问题是：怎么让一群Agent协同工作？什么时候该拆，什么时候不该拆？
