你做了一个 Agent。
在演示里，它能理解问题，会调用工具，还能生成一份像模像样的结果。连续试了三次都没出错，团队自然会问：是不是可以上线了？
还不能。
这三次成功只能证明它在三个已知案例上工作过。它没有证明面对不同用户表达、信息缺失、工具异常或模型波动时，仍然能稳定完成任务。
测评的作用，就是把“感觉能用”变成“有证据证明能用”。
Demo 成功不等于产品可用
我们在演示 Agent 时，通常会下意识选择最熟悉的路径：
- 输入比较完整；
- 任务边界比较清楚；
- 工具和网络都处于正常状态；
- 失败后可以马上换一个问题重试；
- 结果看起来合理，就默认它已经完成任务。
真实用户不会这样配合。
他们可能只说半句话，也可能把两个任务混在一起；可能缺少必要信息，也可能要求 Agent 执行一个没有权限的操作。外部接口会超时，文件可能打不开，同一个模型面对同一输入也可能给出不同结果。
所以，Demo 回答的是“它能不能成功一次”，产品需要回答的是“它能不能在目标场景中持续工作”。
这两个问题之间，就是测评要补上的证据。
测评需要回答四个问题
对一个 Agent 做测评，不是为了得到一个漂亮的总分。它至少要回答四类产品问题。
1. 它能不能完成任务
这是最基础的一层。
用户要求整理一份资料，Agent 是否真的生成了文件？用户要求查询数据，它是否返回了正确范围的数据？Skill 是否在应该出现的时候被调用？
这里关注的是任务完成，而不是回答“看起来很聪明”。
2. 它做得好不好
任务完成不等于结果可用。
一份报告可能已经生成，但内容不完整；一个数据表可能格式正确，但关键字段错了；Agent 也可能给出正确结论，却暴露了不该使用的信息。
质量至少包括正确、完整、相关、可读和安全。不同产品还会有自己的专业要求。
3. 它是否稳定
如果同一个任务第一次成功、第二次失败、第三次走错工具，这项能力就不能直接交给用户。
Agent 依赖概率模型。同一输入重复运行，结果可能不同。测评不能只保存最好的一次，而要观察成功率和波动。
4. 它是否值得上线
一个版本质量更高，但调用成本翻倍、响应时间过长，也未必适合真实产品。
上线决策还要考虑成本、延迟、人工接管、安全风险和维护难度。测评最终服务的是保留、修改、换模型、灰度或回滚，而不是单独证明某个模型厉害。
你测的不是一个模型
Agent 出问题时，团队最容易先怀疑大模型。
但真实的被测对象通常包括：
- 模型和采样参数；
- System Prompt 与用户 Prompt；
- Skill 的描述、规则和脚本；
- 上下文、记忆和知识库；
- 可以使用的工具及其权限；
- 外部接口、运行环境、超时和重试策略。
Prompt 没变，模型版本变了，结果可能变化。模型没变，Skill 描述调整了，触发率也可能变化。工具权限不足时，模型再聪明也无法完成任务。
因此，每次测评都要记录完整配置和版本。否则今天的 85 分和下周的 90 分，可能根本不是同一个系统跑出来的。
一次测评最少需要六样东西
第一次做 Eval，不需要先搭一个复杂平台。一个表格加上可保存的运行结果，也能完成最小闭环。
但下面六样东西不能缺。
一个明确的目标
不要写“测一下 Agent 好不好”，要写“判断这个 Skill 能否稳定生成可交付的竞品分析，并决定是否进入内部试用”。
目标需要同时说明评什么和用于什么决定。
一批有代表性的任务
不能只选标准示例。任务中需要有正常场景、不同表达、信息缺失、边界情况、已知坏案例和高风险案例。
数量不是第一优先级，代表性更重要。
可观察的成功标准
“专业”“自然”“智能”都很难直接验收。
更有效的写法是：
- 必须包含哪些内容；
- 必须生成什么产物；
- 哪些字段和状态必须正确；
- 哪些行为绝不能发生；
- 哪些体验可以继续优化。
可追溯的运行证据
只保存最终回复不够。
对于会调用工具的 Agent，还要知道它是否触发了正确 Skill、调用了什么工具、传了什么参数、生成了哪些文件，以及执行前后状态发生了什么变化。
合适的评分方法
格式、字段、文件和状态可以用规则检查。开放性的内容质量可以用评分标准配合模型判断。高风险或有争议的结果仍需要人工复核。
评分者也可能犯错，所以判定理由需要能够复查。
预先写好的决策规则
测评开始前就要说明：
- 哪些错误一票否决；
- 核心任务至少达到什么水平；
- 哪些退化可以接受；
- 什么情况下保留、补测、灰度或回滚。
不要等结果出来后，再为喜欢的版本临时解释标准。
第一步不是改 Prompt，而是写一张测评对象卡
如果你准备评估一个 Agent，可以先回答下面六个问题：
| 问题 | 需要写清的内容 |
|---|---|
| 测谁 | Agent、Prompt 或 Skill 的具体版本 |
| 为谁服务 | 目标用户和使用场景 |
| 完成什么 | 一个边界清晰的真实任务 |
| 最怕什么 | 高成本、高风险或不可恢复的失败 |
| 如何证明 | 用例、标准和需要保存的证据 |
| 测完做什么 | 保留、修改、换模型、灰度或上线 |
这张卡片不会直接给出分数，却能避免后面大部分无效工作。
因为很多所谓“Eval 做不好”，问题并不在评分工具，而在团队从一开始就没有说明：我们到底想证明什么。
下一步，我们需要处理另一个常见疑问：已有软件测试之后，为什么 Agent 还需要单独做测评？
Agent 测评入门系列
- 【Eval】Agent测评不是简单给回答打分（本文）
- 【Eval】测试同学别焦虑，Eval也不是替代品
- 【Eval】第一次Eval，先干小事情
- 【Eval】测Skill，不只是盯结果
- 【Eval】分数变高，不代表版本真的变好
- 【Eval】规则、AI裁判和人工怎么成为铁三角
- 【Eval】离线全通过，上线仍会失败的原因到底是啥