系列定位：AI测试实战方法论 · Agent评测篇
阅读对象：AI测试/评测工程师，尤其是从传统测试转型AI方向的同学
核心价值：一套可复用的Agent评测流程骨架，每个新迭代照着走
一、这篇文章要解决什么问题
做Agent评测，最头疼的不是某个技术点不会，而是整个流程没有一条清晰的线。
需求来了先干嘛？场景怎么梳理？断言怎么设计？提测之后怎么快速出脚本？跑完之后通过率怎么算？
这些问题每个迭代都会碰到，但如果每次都靠临场发挥，效率和质量都没法保证。
这篇文章来自一个健身类AI产品的Agent评测实战------两轮迭代踩完坑之后，沉淀出来的一套流程骨架。不是理论框架，是实际干活的顺序和每一步的重点。新迭代进来，照着走就行。
二、阶段一：需求熟悉 → 场景梳理
先搞清楚你测的范围比你以为的大
Agent系统有一个特点：很多行为不在代码里，在配置里。prompt模板、意图路由规则、白名单，可能都在数据库或配置中心里。这意味着一次配置变更就可能改变Agent的行为，但代码层面看不到任何diff。
所以需求评审的时候，除了功能需求本身，还要问清楚：哪些行为是配置驱动的？配置变了怎么通知测试？不问清楚，后面会漏。
如果产品是多region部署（比如国内用一个模型、海外用另一个），同一个场景在不同region的表现可能完全不一样，场景梳理阶段就要把region作为一个维度考虑进去。
场景梳理：传统方法迁移，一个核心变化
场景梳理的方法论其实没变，就是传统用例设计那套：
- 等价类：按用户意图类型划分------增肌/减脂、轻松/加强、删动作/加动作/换动作，每类挑代表性Query，不穷举
- 边界值：极端和缺省诉求------没设备、时间极短、诉求互相矛盾、什么都不指定走默认
- 正反例：正常诉求 vs 越界诉求（"三天练成肌肉男""删光所有动作"，看AI守不守底线）
- 多轮流程：主流程、中途改主意、中途给矛盾信息
唯一真正变了的：输入从"接口参数"变成了"自然语言意图"。参数是有限的、结构化的，意图是模糊的、高维的、带隐含诉求的。所以"划等价类"这一步比传统测试难得多------类划不准，后面断言的松紧度也定不好。
这一步也顺便回答了一个常见问题：数据集到底要多少条？ 答案是数意图等价类覆盖了没有，不是数条数。
三、阶段二：数据集准备 → 业务细化
场景梳理完，下一步是把场景落成数据集，然后做业务细化。
三层数据框架
- Golden Set（基准集）：核心意图 × 标准场景，保证每轮迭代的回归基线不丢
- Iteration Set（迭代集）：本轮新增的场景和case，跟版本走
- Risk Set（风险集）：边界/极端/对抗场景，来源包括需求分析、线上Bad Case回灌、安全测试case
业务细化的粒度标准
业务细化到什么程度才算够？一个判断标准：细化到能直接支撑后面每一条断言check。
比如"用户说加两组卧推"，业务细化要到：加的是哪两组？加在计划的哪个位置？原有的动作要不要调整？如果冲突了怎么处理？每一条都要有明确的业务预期，不然后面断言写不出来，或者写出来的断言是模糊的。
这一步急不得。业务细化做扎实了，后面断言设计和脚本生成都会快很多；这一步偷懒了，后面全是返工。
四、阶段三：断言设计------提测前就要定好"什么叫对"
这是整个流程里最核心、最难的一步，也是评测组独立价值最集中的地方。
三层断言结构
AI的输出每次都不一样，不能像传统接口测试那样断一个精确值。断言要从"预期=精确值"改成"预期=检查规则清单"，分三层：
- 链路层：AI是否跑完、不断流、不报错------对应传统测试里的状态码检查
- 结构层：输出是否合法可解析（JSON能不能解析、字段齐不齐）------对应传统测试里的schema校验
- 业务层：输出是否满足这条Query的业务诉求------对应传统测试里的业务断言
前两层所有Case通用，写一次就行。第三层按Query配，这是最难的。
第三层松紧度：不是一个全局旋钮，是逐条分类
第三层的每条业务check，先分类再定松紧：
意图违反类------用户说"不要删动作"结果删了，用户说"无设备"结果推荐了器械。这种必须严，二值判定，无松紧空间。
程度量级类------用户说"轻松点"，减2组、3组、5组都在合理范围。这种该松，用"有界宽区间"：下界是必须朝对的方向变，上界是不能变到离谱，中间全过。
语义质量类------生成的训练总结描述准不准。这种靠确定性规则断不了，用LLM裁判或人工抽检。
分类一定，松紧自动就定了。
从APP页面反推断言重点
还有一个实操技巧：从最终用户看到的APP页面倒推，哪些字段/行为是用户真正能感知的？这些才是核心断言。用户看不到的中间过程字段，优先级可以降低。这样既保证了核心质量，又不会把断言写得太死导致通过率极低。
一条设计原则
能压到确定性规则的就别上LLM裁判。可复现性是预算，省着花。每条check声明自己用哪种判定模式（固定规则 / 阈值区间 / LLM裁判），别混着来。
五、阶段四：提测后 → 快速生成脚本
提测了，拿到开发的Mock字段和接口结构，结合前面做好的业务细化和断言设计，让AI快速生成测试脚本。
防幻觉的分层经验
这里有一个血泪教训：不要把评审文档直接扔给AI让它一次性生成脚本。 它会同时猜业务逻辑、默认值、Mock数据、断言规则，产出一堆看起来像模像样但全是幻觉的东西。
正确做法是分层喂：
- Fixture独立：完整的上游对象（用户画像、已有计划等）单独保存，不让AI猜
- Case只描述差异：每条Case只说"这条和基准比，变了什么"，不重复上下文
- 业务事实层先做，不写假JSON：业务预期用自然语言描述清楚，但不要过早写成Mock数据格式------格式等真实Mock出来再对齐
- 格式占位：接口结构没出来的部分，圈成占位符，等开发真实Mock出来再补
这样每一层AI只处理一个维度的问题，幻觉大幅减少。
基础设施缺失的现实
理想情况是有完善的mock/hook/trace支持，实际情况可能什么都没有。这时候别等，自己想办法绕------比如自己写个小工具解决图片上传的问题，比如手动抓包补trace。能推动开发补基础设施当然好，推不动就先绕路把活干了，同时记录下来作为后续改进项。
六、平台化：把重复劳动自动化，但只自动化该自动化的部分
前面五个阶段里，场景梳理、业务细化、断言设计，这些靠人的判断，平台化没意义。真正该上平台的是执行和对比------跑case、算通过率、跨版本diff。这些是每个迭代都要重复的劳动，人做一次可以，迭代多了就是纯消耗。
现实：时间有限，先做刚好够用的
平台开发的时间基本是见缝插针，不可能一次做完。但"刚好够用"已经能解决真实问题。
以意图识别为例------Agent对话链路的第一环，所有用户请求先过意图识别再分发给各个Agent。这一层接入平台后，每次迭代不用人工重新跑一遍，一键执行就能拿到：每个意图分类的通过率、和上一轮迭代的对比、有没有regression。
这就是一个最小闭环：case管理 → 自动执行 → 结果对比。虽然只覆盖了意图识别这一层，但它解决的问题是真实的------迭代一多，人工回归根本跟不过来，而意图识别一旦降质，后面所有Agent的表现都会跟着出问题。
平台和评测流程的分工
一句话：人负责"定义什么叫对"，平台负责"重复地检查对不对"。
前面阶段一到四（场景梳理、数据集、断言设计、脚本生成）的产出，最终变成平台里的case和断言规则。平台做的事就是拿着这些规则，每轮迭代自动跑一遍，告诉你哪里过了、哪里没过、和上一版比哪里变了。
扩展方向
意图识别跑通了，后面可以按同样的模式逐步接入：计划生成评测、工具调用评测、动作纠正评测。数据管理层（Case schema、数据集结构）是统一的，执行逻辑按业务类型分pipeline------Agent走接口调用+断言，CV走图片/视频输入+指标计算，不用硬统一。
平台的OKR达成口径也不用追求"功能覆盖度"这种虚指标，从实际效果量化：接入了几个评测场景、每个场景的case量、能不能做到每次迭代自动跑回归出对比。
七、阶段五：通过率与Bad Case闭环
脚本跑完了，两个问题立刻冒出来。
通过率怎么算？
AI每次输出不同，同一条Case跑10次可能6次过4次不过。那这条Case算过还是不过？
这个问题没有标准答案，但你必须提前定义清楚规则，而不是跑完之后临时决定。比如：跑N次取通过率，高于阈值算pass；或者区分"必须每次都过"的硬断言和"允许波动"的软断言，分开统计。
关键是：通过率的定义本身就是评测设计的一部分，不是跑完才想的事。
Bad Case闭环
跑出来的Bad Case不能测完就完了，要闭环：
- 分类：已知问题的新变种，还是全新失败模式？
- 溯源：评测集里有没有覆盖？有的话为什么没拦住？没有就是覆盖漏洞
- 回灌：有代表性的Bad Case补进Risk Set
- 验证：下轮迭代必须包含回灌的case，确认问题修复
这个闭环跑起来之后，数据集就不是静态的了，它会随着每轮迭代自动演进。
八、整个流程的一张图
需求评审
│ 搞清范围(含配置驱动的行为、多region差异)
▼
场景梳理
│ 等价类/边界值/正反例/多轮流程
│ 核心难点：自然语言意图的等价类划分
▼
数据集准备 + 业务细化
│ Golden/Iteration/Risk三层
│ 细化到能支撑每一条断言check
▼
断言设计(提测前)
│ 链路/结构/业务三层
│ 松紧度三分类：意图违反(严)/程度量级(宽)/语义质量(LLM裁判)
│ 从APP页面反推核心断言
▼
提测后生成脚本
│ 分层防幻觉：Fixture→Case差异→业务事实→格式占位
│ 查漏补缺
▼
平台化(把重复劳动自动化)
│ 人定义"什么叫对"，平台重复检查"对不对"
│ 一键回归 → 分类别通过率 → 跨迭代对比
▼
执行 + 通过率定义
│ 提前定好pass/fail规则
▼
Bad Case闭环
│ 分类→溯源→回灌→下轮验证
▼
下一轮迭代(回到顶部)每个新迭代进来，变的是业务内容，不变的是这套骨架。
九、这套流程的两个用法
当SOP用：新迭代来了，照着走，不用重新想先干嘛。每一步的重点和容易踩的坑都标好了。也可以交给新人作为上手指南。
当叙事用 ：面试或技术分享的时候，这就是你的故事线。面试官要听的不是"我跑了多少case"，而是你怎么理解Agent评测的流程、每一步解决什么问题、踩过什么坑、怎么处理理想和现实的差距。踩坑本身就是最值钱的分享内容。
如果你也在做Agent评测，欢迎交流。场景梳理和断言松紧度这两个点，踩得越多越有聊的。