一个 Agent 要调用接口、读取文件、写入数据，还要生成开放内容。
测试团队可以验证接口是否返回 200、字段类型是否正确、文件是否创建成功。可这些检查都通过之后，Agent 仍然可能给出一份事实错误、遗漏重点或者完全不解决用户问题的报告。
这不是测试没有做好，而是测试与测评回答的问题不同。
一个 Agent 同时包含两类系统
传统软件的核心行为大多可以写成明确规格：
- 输入是否合法；
- 接口返回什么状态；
- 字段是否符合类型；
- 权限不足时是否拒绝；
- 重复执行是否产生重复数据。
这些问题有清晰预期，适合用单元测试、接口测试和端到端测试验证。
Agent 中还有另一类行为：
- 回答是否抓住用户真正的问题；
- 报告是否完整且有用；
- 面对信息不足时是否应该追问；
- 应该选择哪个工具；
- 多条可行路径中，是否找到成本合理的一条。
这些问题通常没有唯一正确文本。结果可以不同，但都可能有效；也可能看起来流畅，实际却不能使用。
传统测试负责确定性规格，Eval 负责开放性质量。一个完整 Agent 同时包含两部分，因此两者都需要。
测试经验没有过时
Eval 不是从零发明一套质量方法。很多可靠做法直接继承自软件测试。
分层
复杂系统不能只看最后结果。
底层可以检查解析、检索、函数和结构化输出；中间检查 Prompt、Skill、工具调用和 Agent 计划；上层检查完整工作流与真实业务结果。
越靠下，越适合确定性断言；越靠上，越需要任务成功和质量判断。
用例与边界
正常场景、负例、边界条件、异常恢复和高风险场景，在 Agent 测评中仍然有效。
区别只在于：部分用例的预期不再是一段固定答案，而是允许范围、必须满足项和禁止行为。
基线与回归
没有旧版基线，就不知道新版究竟改善了什么。
线上出现一个坏案例，修复之后也要加入回归集，确保下一次修改不会让同类问题再次出现。
环境隔离与版本记录
模型、Prompt、Skill、工具、数据和参数都可能影响结果。只有固定或记录这些变量，不同时间的结果才可比较。
发布门槛
测试会阻止严重缺陷进入生产，Eval 也应为安全、核心任务、关键分组和成本设定门槛。
所以，Eval 与测试的关系不是另起炉灶，而是在同一工程骨架上增加适合概率系统的测量方法。
AI 测评多出来的四个难题
结果具有随机性
同一个模型面对同一输入，重复运行可能产生不同答案。一次通过不能证明稳定，一次失败也不一定代表必然失败。
测评需要重复运行，观察成功率和波动，而不是只保存最好的一次。
正确答案可能不唯一
一份用户研究总结可以有不同结构和表达。只要事实正确、重点完整、满足任务，它们都可能合格。
这类结果无法只用字符串相等判断，需要按维度描述什么叫好。
评分者也可能出错
开放结果可以由人工判断，也可以让另一个大模型充当 AI 裁判。
但模型评分会受到位置、长度、措辞和自身偏好的影响。人工判断也会因经验和标准理解不同而产生分歧。
因此，评分方法本身也要校准。高风险和临界结果不能完全交给自动评分。
依赖会漂移
模型服务会升级，检索数据会变化，工具接口和用户表达也会变化。
一套曾经有效的结果不能永久证明当前版本有效。变化发生后，需要按影响范围重新测评。
五类质量活动分别解决什么
Agent 团队经常把 Test、Eval、Benchmark、Monitoring 和 A/B Test 混在一起。它们可以共享数据和工具，但承担不同职责。
| 活动 | 主要问题 | 典型结论 |
|---|---|---|
| 软件测试 | 是否符合确定性规格 | 功能是否正确、是否破坏不变量 |
| Eval | 能力质量是否达到预期 | Agent 是否完成目标任务、版本是否改善 |
| Benchmark | 固定任务集上的相对能力如何 | 不同模型或系统如何横向比较 |
| 线上监控 | 生产环境正在发生什么 | 是否异常、漂移、变慢或变贵 |
| A/B 实验 | 变化是否改善真实用户或业务结果 | 采用、转化、效率是否发生变化 |
它们之间也存在明确的证据流：
测试守住确定性底线 → 离线 Eval 验证能力和风险 → 灰度与监控观察真实分布 → A/B 实验验证业务影响 → 线上坏案例返回测试和 Eval。
离线 Eval 通过，不能证明业务一定增长；线上转化提升，也不能说明系统没有隐藏的安全问题。
产品经理怎样拆分一个 Agent 需求
假设一个 Skill 要读取会议材料，并生成结构化需求文档。
可以先把验收要求分成四组。
交给传统测试
- 文件类型和大小限制是否生效；
- 接口失败是否返回明确错误；
- 输出 Markdown 是否成功创建；
- 重复执行是否覆盖错误文件；
- 没有权限时是否停止。
交给 Eval
- 是否提取了真正的业务目标；
- 流程、字段、规则和验收点是否完整；
- 不确定信息是否保留为 TODO；
- 是否混入了材料中不存在的结论；
- 文档是否达到开发可用程度。
交给线上监控
- 真实任务失败率；
- 人工接管和用户纠正；
- 工具错误、延迟和成本异常；
- 新类型输入或未知失败。
交给业务实验
- 使用该 Skill 是否减少整理时间；
- 需求返工是否下降；
- 开发和测试是否更容易理解文档；
- 用户是否愿意持续使用。
这张分工表能解决一个常见问题：所有质量责任都压到一个“通过率”上，最后谁也说不清结果代表什么。
一套更实际的组合
对 Agent 产品，较稳妥的方式不是选择测试或 Eval，而是按问题性质组合。
- 能精确断言的，优先自动测试；
- 需要判断开放质量的，进入离线 Eval；
- 会影响权限、安全和外部状态的，同时设置硬门；
- 真实分布和未知问题，交给生产监控；
- 用户价值与业务结果，使用灰度或 A/B 验证。
测试让系统不轻易“坏掉”，测评让 Agent 不只是“能跑”，而是能够完成用户真正要办的事。
下一篇，我们不再继续讲概念，而是直接用一批真实任务跑通第一次测评。
Agent 测评入门系列
- 【Eval】Agent测评不是简单给回答打分
- 【Eval】测试同学别焦虑，Eval也不是替代品（本文）
- 【Eval】第一次Eval，先干小事情
- 【Eval】测Skill，不只是盯结果
- 【Eval】分数变高，不代表版本真的变好
- 【Eval】规则、AI裁判和人工怎么成为铁三角
- 【Eval】离线全通过，上线仍会失败的原因到底是啥