做 AI Agent，跑起来很容易，简单点函数调用+几个最好的大模型，复杂一点，整合或「学习」一些开源的多 Agent 项目，也能跑起来。
但是如何真正要做到一个行业中去，把一个行业 Agent 做好就没那么容易了，特别是让这个 Agent 能稳定的迭代，稳定的跑对了，也就难了。
在这些迭代过程中，我们会不停的换模型、改提示词、加工具、加缓存、改路由、做多智能体……
这样我们就会收获如下的一堆问题：
- 线上用户说「变笨了」，却没证据；
- 反馈说生成效果不行，却不知道该如何描述其所说的效果；
- 修一个 bug，引入三个新 bug；
- 团队讨论靠口感，最后靠拍板；
- 研发不敢升级模型，因为测试周期太长；
- 业务要结果，技术要可控，双方都焦虑。
面对这些问题，我们聊聊如何对行业 Agent 做评测。
0. 说在前面
我们评测的是「系统」，不是「模型」
很多团队说在做评测，实际上只是在测「模型回复像不像」。对 Agent 来说不够，因为 Agent 的能力来自两部分：
- 模型
- 工程：提示词、工具编排、状态管理、记忆、重试策略、检索、权限、路由、超时、并发、回退等
所以评测对象应该是：模型 + 工程 的整体行为。
1. 标准
团队里面一定要有领域专家，没有领域专家的测评只能算自娱自乐。
Agent 的「好」不是抽象的。没有领域专家，评测标准会变成两类坏结果：
- 写得很漂亮，但不对应业务结果（比如客服很礼貌，但票据没关单）
- 标准含糊，评分不可重复（今天判通过，明天同样输出判不通过）
「领域专家」不一定是外部大咖，很多时候就是我们身边的同事：
- 客服主管（知道什么叫“解决”）
- 财务/风控（知道哪些动作不能做）
- 资深运营（知道用户会怎么钻空子）
- 负责交付的实施/售后（知道线上真实约束）
- 售前负责人（知道用户要的是什么）
要求只有一个：两位领域专家独立评审同一个任务，应该能得到一致的 pass/fail。做不到就说明任务或标准还不够清晰。
2. 数据集
输入与输出要成对，从 20 条 good case 和 bad case 开始吧。
很多团队拖着不做评测，理由是「没有足够的数据」。
2.1 数据集怎么来
- 线上事故 / 客诉 / 工单：最值钱，但也是压力最大的
- 发布前人工回归里会反复点的那些检查项
- 运营同学最常复述的“用户就爱这么问”
- 灰度期间的失败轨迹（尤其是工具调用失败、超时、权限不足、状态不一致）
2.2 一个测试任务里应该包含什么
- 输入（用户消息 + 初始状态 + 可用工具 + 环境约束）
- 明确的成功条件
- 参考解（可能是图、视频和文本）
当遇到测试不通过或者通过率很低时，一般不是模型不行，可能是设计的测试任务有问题。
2.3 数据集要有正反两派
测试人都知道的，做测试更多的是测异常。在做数据集时，这个逻辑一样的成立。
- 该搜 vs 不该搜
- 该下单 vs 不该下单
- 该升级人工 vs 应该继续处理
- 该改文件 vs 不该动文件
- 该生成图 vs 应该拒绝（合规/版权/不当内容）
3. 系统
让过程系统化，小系统也是系统
评测不系统化，最后一定会回到「手工点点点 + 群里吵架」。一个可用的评测系统，最少包括：
3.1 评测运行系统
- 并发跑任务
- 每个环境隔离（干净的文件系统、数据库、缓存、账户）
- 固定随机种子/版本（尽量可复现）
- 记录完整过程
- 输出结构化结果
请注意：共享状态会污染结果。
这个系统可以大，也可以小，甚至小到只是一个 python 脚本。
3.2 评测资产管理
- 任务版本化（任务也要像代码一样走 PR）
- rubric/断言版本化
- 基线版本固定可回放
- 失败样本池：每次线上新失败，能快速进入评测集
- 评测数据集管理
- 评测结果管理，特别是图片类 Agent，所有的结果图都需要保存，并且能随时查阅，给到领域专家来审查。
3.3 结果可读性
最终的结果重要，但这个结果不仅仅是分数，还必须能「点开看」：
- 失败的结果
- 判定理由
- 最终的证据（输入的 prompt，图片结果，过程中的数据库/文件/页面状态等等）
4. 成本
和过往的测试工作不同，AI 的评测需要更多些的考虑成本，特别是多模态或视频，生图类 Agent。
这里的基本逻辑是：每个 AI 算力资源都是有限的，也是贵的。
如果在一个死循环中写了调用外部视频生成的接口逻辑，那等待的就是账号里面的钱被用光，如果有加了使用限制，大概率就是达到限制。
以第三方大模型账号为例，有几个小点：
- 测试账号要和生产账号隔离，防止异常突出导致资源受限，在每个平台请求并发数，或者分钟请求数，或者 token 速度都是有限的，不同环境的资源需要隔离开来。
- 账号需要做好限制，防止账号的钱被用完；
- 安全考虑，定期更换。
5. 传统测试方式
静态分析、工具验证、记录分析这些传统的测试方法别丢了。
5.1 静态分析
适合：
- 代码类：lint、type check、安全扫描（ruff/mypy/bandit 这类）
- 配置类：schema 校验
- 文本结构：JSON schema、正则、字段完整性 优势：快、便宜、可复现、可 debug。
5.2 工具验证
Agent 出问题很常见的一类是：工具用错、参数错、顺序不合理、该用不用。
你可以验证：
- 是否调用了某工具
- 参数是否在范围（例如退款金额 <=100）
- 是否访问了不该访问的资源
但要注意：不要把“必须按某条路径走”写死。太死会惩罚合理的创造性解法。更推荐「看产出」，必要时只加一些底线约束（比如必须做身份验证）。
5.3 记录分析
不一定评价“对错”，而是监控质量与成本：
- turn 数、toolcall 数、tokens
- 延迟：TTFT、总耗时、吞吐
- 重试次数、错误码分布
6. 新的基于大模型的测试
该用用，但要用得克制
对于评测，我们通过可以分为三类：代码型、模型型、人工。实际落地里，模型型的价值主要在两件事：
- 开放式输出：没有唯一正确答案（客服话术、研究总结、写作、规划）
- 细粒度质量维度：礼貌、同理心、覆盖度、论证质量、是否胡编
常用方式：
- 打分（按维度给分）
- 自然语言断言（是否满足某条要求）
- A/B 谁更好
- 对照参考答案
- 多裁判投票/取中位数
但需要注意：
- 非确定性：同样输入可能不同评分
- 更贵：相当于每条任务再跑一遍模型
- 需要校准：必须和人评对齐，否则就是“模型自嗨”
一个实用的建议：给 LLM 评测一个「退路」，例如信息不足就输出 Unknown，避免它为了「必须回答」而脑补。
另外：把评分标准结构化，并拆维度单独评，不要一次判所有维度，噪声会很大，因为随着上下文更长，大模型的注意力会出现一些问题。
7. 人工评分
领域专家门禁：效果不好就不能上，灰度可选
人工评分并不是用来「天天打分」的，人工的职责更多是：
- 定义标准（什么叫好）
- 校准 LLM grader（对齐、抽检、纠偏）
- 做门禁（关键版本上线前必须过）
7.1 门禁怎么做
- 定一个小的「关键任务集」（比如 30 条最关键、最敏感、最影响收入/合规的），或者称为黄金链路
- 每次大改/换模型/换工具链，必须过这个集
- 过不了：不讨论「用户可能不在意」，直接回滚或修
7.2 灰度
没有足够流量，灰度很难有显著的效果，也没有啥意义：
- 用离线评测 + 小范围内测
- 线上用强监控兜底（错误、成本、关键转化、人工接管率等）
等流量与组织能力到位，再做严格 A/B。
8. 流程
从 0 到 1，再到可持续
这套流程的目标很简单：让每次改动都有依据，上线前知道会不会退步，退步了能快速定位原因。
第 0 步：尽早开工，小样本就能跑起来
别等“数据够多”。先做一个能工作的最小闭环。
- 先收 20–50 条真实案例（成功和失败都要）
- 来源：线上工单、客服反馈、bug 记录、内部手工测试步骤
- 每条案例都写清楚：什么算成功，什么算失败
- 先把基础能力跑通：
能批量跑 → 每次互不干扰 → 全程有记录 → 能出汇总表
这一阶段不追求完美，只追求“评测能运转”。
第 1 步：把“手工回归”变成固定任务清单
你们发布前人工必做的检查，本质上就是任务列表，只是没系统化。
- 发布前“必须点”的那些流程，全部写成任务，进评测库
- 线上出现的 bug / 客诉，能复现的尽量都写成任务
- 按影响排序：
影响钱 / 合规 / 大客户 / 高频场景优先
做久了会发现：评测库就是你们产品真实使用方式的地图。
第 2 步：任务要写得清楚，评分要能落地
一条任务写不清楚，后面全是噪音。
至少要满足三条：
- 两位领域同学看完任务描述，能给出一致的“过/不过”
- 给每条任务准备一个“标准答案/参考做法”（证明这题能做对）
- 评分标准不能靠“默认常识”
- 评测要检查什么，任务里就要写清楚
- 别出现“任务没说路径，但测试默认某个路径”这种坑
任务写得越清楚，后面迭代越省时间。
第 3 步：任务要成对出现
很多系统越改越怪，可能是评测只给了单边信号。
每类行为都尽量做成一对：
- 该查资料 / 不该查资料
- 该下单 / 不该下单
- 该继续处理 / 该转人工
- 该修改文件 / 不该动文件
- 该生成 / 该拒绝（合规类尤其重要）
第 4 步：把评测环境做稳定，确保结果可信
评测不可信，比没有评测更糟糕。
关键点：
- 每次运行从干净环境开始（文件、数据库、缓存都重置）
- 尽量减少共享状态（否则会互相污染）
- 资源要有上限（CPU/内存/网络），避免“机器不够导致一片失败”
- 失败要能区分：
- 是系统真不行
- 还是环境抖动、配额限制、工具不稳定
要保证：同一版本跑两次，结果大体一致。
第 5 步：评分规则按「能自动就自动」来设计
评分不要一上来就全靠大模型判。
推荐顺序：
- 能用确定规则判断的，先用确定规则
- 结果是否写进数据库、订单是否存在、文件是否生成、测试是否通过
- 能用简单规则校验的，用规则
- 字段完整、格式正确、调用工具参数在范围内
- 只有在确实需要“主观判断”时，才用大模型评分
- 语气、解释是否清楚、内容是否覆盖关键点
还有一条很重要：
尽量评「最终交付」，少评「必须怎么做」。
路径卡太死，会误伤很多正确解。
第 6 步：固定做「看过程记录」，不然不知道问题在哪
很多团队评测做不下去，就是因为只看分数，不看过程。
至少要做到三件事：
- 分数下降时：优先看失败最多、影响最大的那几条任务的过程记录
- 每周抽查一批「通过」的过程记录（防止钻规则漏洞）
- 发现「明明做对了却被判错」，立刻修任务描述或评分规则
一句话：评测系统也要像产品一样调试。
第 7 步：分数到顶了就补题，不然评测会失效
分数 100% 不代表系统没问题，只代表这套题已经测不出差异。
做两件事：
- 持续把新的线上失败变成新任务
- 专门补「更难、更真实」的场景（长流程、多约束、容易出错的边界条件）
评测库要一直增长，否则它会变成摆设。
第 8 步：让评测「有人管、有人用、有人能加题」
长期最有效的分工通常是：
- 有一个小组负责评测系统本身（跑得稳、记录全、报表清楚）
- 各业务团队负责写任务（最懂用户的人写，写出来才贴近真实）
- 写任务像写代码一样走评审流程（谁提的、为什么提、怎么验证）
让离用户最近的人能把问题变成任务，是评测能持续的关键。
9. 非确定性
别再只盯「通过率」，用 pass@k 和 pass^k 讲清楚“稳定性”
Agent 的输出有随机性，同一任务可能今天过、明天不过。以下两个指标可以有：
- pass@k：k 次尝试里至少成功一次的概率
- 适合“允许多试一次”的场景（比如离线生成候选方案）
- pass^k：k 次尝试全部成功的概率
- 适合“线上必须稳定”的场景（客服、交易、流程自动化）
它们会随着 k 分化：
- k 越大，pass@k 越接近 100%
- k 越大，pass^k 越接近 0（对稳定性要求更苛刻）
这能解决很多争论：
- 研发说「抽卡，多跑几次能过」
- 业务说「用户只给一次机会」
用 pass@k 和 pass^k 直接对齐产品要求。
10. 安例：生图 AI Agent 如何评估
生图 Agent 的评测，比「文生图模型评测」更难，因为 Agent 往往还会：
- 和用户多轮确认需求
- 调风格/比例/seed/参考图
- 调用安全审核、版权过滤、提示词改写
- 产出多张候选并做挑选/排序
- 写交付说明（可商用/不可商用、使用建议）
评测要覆盖的不是「画得好不好」一句话，而是「是否按业务标准交付」。
下面给一套实用的评测维度：
10.1 标准
先定“交付合格”是什么
建议产品/设计/合规一起定 3–5 条硬标准，例如：
- 不违规：敏感内容、未成年、色情、仇恨、暴力、政治等必须拦截或降级
- 不侵权：明显模仿特定 IP / 特定艺人脸 / 商标露出等按策略处理
- 满足需求：主体、场景、风格、比例、文字有无（比如“不要文字”）
- 质量底线：严重畸形、手指崩坏、文本乱码（如果要求有字则反过来）
- 可用性：分辨率、格式、背景透明/不透明、交付数量
标准不要写成「更美观」「更高级」，要写成可判定的条目。
10.2 数据集
最有效的来源通常是：
- 用户最常下单的品类（电商主图、海报、头像、插画、UI 素材）
- 客诉：不像、漏元素、风格跑偏、文字错、侵权被投诉、审核误杀
- 运营活动：固定模板需求（这类最适合做回归）
每条任务里建议固定：
- 用户输入（含约束：尺寸、风格、禁忌、用途）
- 允许的工具（生成、放大、背景去除、OCR 检查、合规审查）
- 成功条件（至少满足哪些项）
- 参考交付（如果你们已有人工优秀样例，可以作为对照，但不强制唯一答案）
10.3 评测流程
评测建议按「确定性 → 半确定性 → 开放判断」的顺序叠起来，减少噪音、降低成本。
A. 结果校验（尽量全自动、最优先）
这层解决「交付物是否合格」的硬指标：
- 格式、尺寸、分辨率、通道（如 PNG 透明背景）
- 交付数量（例如必须 4 张）
- 文件可打开、无损坏
- 禁止内容检测（审核模型/规则引擎给出通过/拦截/分级）
B. 内容对齐（半自动，能做多少做多少）
这层解决“有没有按需求做”的关键事实核对：
- 关键元素是否出现：用图像理解/检测器做覆盖检查（比如“猫 + 红围巾 + 雪地”）
- 不该出现的是否出现：
- “不要文字”→ 用 OCR 检测是否有字
- “不要 logo/商标”→ logo/商标检测（覆盖不了的留到抽检）
C. 开放项判断（用于难以规则化的部分）
这层才用多模态判断去评估更开放的维度，例如：
- 主体/场景/风格是否整体匹配需求
- 是否存在明显瑕疵（手部畸形、脸崩、透视严重错误等）
- 交付说明是否写清：能否商用、限制条件、使用建议
注意：开放项的判定要校准，不要一开始就“全自动放行”。
D. 过程约束（管体验、管成本）
对 Agent 的“过程”也要设上限，不然容易出现“靠烧钱刷分”：
- 最大对话轮次（例如 ≤ 6 轮）
- 工具调用次数上限（避免无限重试）
- 总耗时 / 总成本阈值
10.4 成本控制
生图评测很贵，建议分三层跑，不同层用不同频率：
- 回归层（少量高价值，天天/每次发布必跑）
高频品类 + 高风险合规项 + 线上常见故障 - 能力层（持续加难题，定期跑）
风格混合、复杂构图、多约束冲突、长对话澄清等 - 抽检层（人工校准，每周固定抽样）
抽查“通过样本”和“失败样本”，用来校准开放项判断与审核策略
10.5 典型坑
提前避开
- 只看审美分，不看合规/侵权/交付规格 → 上线风险最大
- 只测“能生成”，不测“该拒绝/该降级” → 合规体系形同虚设
- 不看过程记录 → 不知道是 Agent 真错了，还是评分/审核错了；也抓不到“用昂贵链路刷通过”
- 评分规则写死 → 把某一种构图当唯一正确，误杀大量合理解（导致迭代方向跑偏）
11. 最后
评测的目标是：知道变好还是变差、知道差在哪、知道怎么改。
真正成熟的状态通常是这样：
- 每次改动都有反馈：离线分数怎么变、失败清单有哪些，一眼可见
- 分数下降能追到根因：能定位到具体哪条任务、哪段过程记录出了问题
- 关键回归集就是门禁：过不了就不发布（不讨论「感觉应该没事」）
- 换模型/换策略能算账：能快速判断「收益是否值得成本与风险” 」
- 线上与离线形成闭环：
- 线上出现的新失败，能快速回流成任务进评测库
- 离线提前发现的风险，能在上线前就挡住
最后一句：一定要看过程记录。
以上。