做 AI Agent，跑起来很容易，简单点函数调用+几个最好的大模型，复杂一点，整合或「学习」一些开源的多 Agent 项目，也能跑起来。

但是如何真正要做到一个行业中去，把一个行业 Agent 做好就没那么容易了，特别是让这个 Agent 能稳定的迭代，稳定的跑对了，也就难了。

在这些迭代过程中，我们会不停的换模型、改提示词、加工具、加缓存、改路由、做多智能体……

这样我们就会收获如下的一堆问题：

• 线上用户说「变笨了」，却没证据；
• 反馈说生成效果不行，却不知道该如何描述其所说的效果；
• 修一个 bug，引入三个新 bug；
• 团队讨论靠口感，最后靠拍板；
• 研发不敢升级模型，因为测试周期太长；
• 业务要结果，技术要可控，双方都焦虑。

面对这些问题，我们聊聊如何对行业 Agent 做评测。

0. 说在前面

我们评测的是「系统」，不是「模型」

很多团队说在做评测，实际上只是在测「模型回复像不像」。对 Agent 来说不够，因为 Agent 的能力来自两部分：

• 模型
• 工程：提示词、工具编排、状态管理、记忆、重试策略、检索、权限、路由、超时、并发、回退等

所以评测对象应该是：模型 + 工程 的整体行为。

1. 标准

团队里面一定要有领域专家，没有领域专家的测评只能算自娱自乐。

Agent 的「好」不是抽象的。没有领域专家，评测标准会变成两类坏结果：

• 写得很漂亮，但不对应业务结果（比如客服很礼貌，但票据没关单）
• 标准含糊，评分不可重复（今天判通过，明天同样输出判不通过）

「领域专家」不一定是外部大咖，很多时候就是我们身边的同事：

• 客服主管（知道什么叫“解决”）
• 财务/风控（知道哪些动作不能做）
• 资深运营（知道用户会怎么钻空子）
• 负责交付的实施/售后（知道线上真实约束）
• 售前负责人（知道用户要的是什么）

要求只有一个：两位领域专家独立评审同一个任务，应该能得到一致的 pass/fail。做不到就说明任务或标准还不够清晰。

2. 数据集

输入与输出要成对，从 20 条 good case 和 bad case 开始吧。

很多团队拖着不做评测，理由是「没有足够的数据」。

2.1 数据集怎么来

1. 线上事故 / 客诉 / 工单：最值钱，但也是压力最大的
2. 发布前人工回归里会反复点的那些检查项
3. 运营同学最常复述的“用户就爱这么问”
4. 灰度期间的失败轨迹（尤其是工具调用失败、超时、权限不足、状态不一致）

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 算力资源都是有限的，也是贵的。

如果在一个死循环中写了调用外部视频生成的接口逻辑，那等待的就是账号里面的钱被用光，如果有加了使用限制，大概率就是达到限制。

以第三方大模型账号为例，有几个小点：

1. 测试账号要和生产账号隔离，防止异常突出导致资源受限，在每个平台请求并发数，或者分钟请求数，或者 token 速度都是有限的，不同环境的资源需要隔离开来。
2. 账号需要做好限制，防止账号的钱被用完；
3. 安全考虑，定期更换。

5. 传统测试方式

静态分析、工具验证、记录分析这些传统的测试方法别丢了。

5.1 静态分析

适合：

• 代码类：lint、type check、安全扫描（ruff/mypy/bandit 这类）
• 配置类：schema 校验
• 文本结构：JSON schema、正则、字段完整性 优势：快、便宜、可复现、可 debug。

5.2 工具验证

Agent 出问题很常见的一类是：工具用错、参数错、顺序不合理、该用不用。

你可以验证：

• 是否调用了某工具
• 参数是否在范围（例如退款金额 <=100）
• 是否访问了不该访问的资源

但要注意：不要把“必须按某条路径走”写死。太死会惩罚合理的创造性解法。更推荐「看产出」，必要时只加一些底线约束（比如必须做身份验证）。

5.3 记录分析

不一定评价“对错”，而是监控质量与成本：

• turn 数、toolcall 数、tokens
• 延迟：TTFT、总耗时、吞吐
• 重试次数、错误码分布

6. 新的基于大模型的测试

该用用，但要用得克制

对于评测，我们通过可以分为三类：代码型、模型型、人工。实际落地里，模型型的价值主要在两件事：

1. 开放式输出：没有唯一正确答案（客服话术、研究总结、写作、规划）
2. 细粒度质量维度：礼貌、同理心、覆盖度、论证质量、是否胡编

常用方式：

• 打分（按维度给分）
• 自然语言断言（是否满足某条要求）
• A/B 谁更好
• 对照参考答案
• 多裁判投票/取中位数

但需要注意：

• 非确定性：同样输入可能不同评分
• 更贵：相当于每条任务再跑一遍模型
• 需要校准：必须和人评对齐，否则就是“模型自嗨”

一个实用的建议：给 LLM 评测一个「退路」，例如信息不足就输出 Unknown，避免它为了「必须回答」而脑补。

另外：把评分标准结构化，并拆维度单独评，不要一次判所有维度，噪声会很大，因为随着上下文更长，大模型的注意力会出现一些问题。

7. 人工评分

领域专家门禁：效果不好就不能上，灰度可选

人工评分并不是用来「天天打分」的，人工的职责更多是：

• 定义标准（什么叫好）
• 校准 LLM grader（对齐、抽检、纠偏）
• 做门禁（关键版本上线前必须过）

7.1 门禁怎么做

• 定一个小的「关键任务集」（比如 30 条最关键、最敏感、最影响收入/合规的），或者称为黄金链路
• 每次大改/换模型/换工具链，必须过这个集
• 过不了：不讨论「用户可能不在意」，直接回滚或修

7.2 灰度

没有足够流量，灰度很难有显著的效果，也没有啥意义：

• 用离线评测 + 小范围内测
• 线上用强监控兜底（错误、成本、关键转化、人工接管率等）

等流量与组织能力到位，再做严格 A/B。

8. 流程

从 0 到 1，再到可持续

这套流程的目标很简单：让每次改动都有依据，上线前知道会不会退步，退步了能快速定位原因。

第 0 步：尽早开工，小样本就能跑起来

别等“数据够多”。先做一个能工作的最小闭环。

• 先收 20–50 条真实案例（成功和失败都要）
  • 来源：线上工单、客服反馈、bug 记录、内部手工测试步骤

 

• 每条案例都写清楚：什么算成功，什么算失败
• 先把基础能力跑通：
  能批量跑 → 每次互不干扰 → 全程有记录 → 能出汇总表

这一阶段不追求完美，只追求“评测能运转”。

第 1 步：把“手工回归”变成固定任务清单

你们发布前人工必做的检查，本质上就是任务列表，只是没系统化。

• 发布前“必须点”的那些流程，全部写成任务，进评测库
• 线上出现的 bug / 客诉，能复现的尽量都写成任务
• 按影响排序：
  影响钱 / 合规 / 大客户 / 高频场景优先

做久了会发现：评测库就是你们产品真实使用方式的地图。

第 2 步：任务要写得清楚，评分要能落地

一条任务写不清楚，后面全是噪音。

至少要满足三条：

1. 两位领域同学看完任务描述，能给出一致的“过/不过”
2. 给每条任务准备一个“标准答案/参考做法”（证明这题能做对）
3. 评分标准不能靠“默认常识”

• 评测要检查什么，任务里就要写清楚
• 别出现“任务没说路径，但测试默认某个路径”这种坑

任务写得越清楚，后面迭代越省时间。

第 3 步：任务要成对出现

很多系统越改越怪，可能是评测只给了单边信号。

每类行为都尽量做成一对：

• 该查资料 / 不该查资料
• 该下单 / 不该下单
• 该继续处理 / 该转人工
• 该修改文件 / 不该动文件
• 该生成 / 该拒绝（合规类尤其重要）

第 4 步：把评测环境做稳定，确保结果可信

评测不可信，比没有评测更糟糕。

关键点：

• 每次运行从干净环境开始（文件、数据库、缓存都重置）
• 尽量减少共享状态（否则会互相污染）
• 资源要有上限（CPU/内存/网络），避免“机器不够导致一片失败”
• 失败要能区分：
  • 是系统真不行
  • 还是环境抖动、配额限制、工具不稳定

要保证：同一版本跑两次，结果大体一致。

第 5 步：评分规则按「能自动就自动」来设计

评分不要一上来就全靠大模型判。

推荐顺序：

1. 能用确定规则判断的，先用确定规则

• 结果是否写进数据库、订单是否存在、文件是否生成、测试是否通过

1. 能用简单规则校验的，用规则

• 字段完整、格式正确、调用工具参数在范围内

1. 只有在确实需要“主观判断”时，才用大模型评分

• 语气、解释是否清楚、内容是否覆盖关键点

还有一条很重要：
尽量评「最终交付」，少评「必须怎么做」。
路径卡太死，会误伤很多正确解。

第 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 成本控制

生图评测很贵，建议分三层跑，不同层用不同频率：

1. 回归层（少量高价值，天天/每次发布必跑）
   高频品类 + 高风险合规项 + 线上常见故障
2. 能力层（持续加难题，定期跑）
   风格混合、复杂构图、多约束冲突、长对话澄清等
3. 抽检层（人工校准，每周固定抽样）
   抽查“通过样本”和“失败样本”，用来校准开放项判断与审核策略

10.5 典型坑

提前避开

• 只看审美分，不看合规/侵权/交付规格 → 上线风险最大
• 只测“能生成”，不测“该拒绝/该降级” → 合规体系形同虚设
• 不看过程记录 → 不知道是 Agent 真错了，还是评分/审核错了；也抓不到“用昂贵链路刷通过”
• 评分规则写死 → 把某一种构图当唯一正确，误杀大量合理解（导致迭代方向跑偏）

11. 最后

评测的目标是：知道变好还是变差、知道差在哪、知道怎么改。

真正成熟的状态通常是这样：

• 每次改动都有反馈：离线分数怎么变、失败清单有哪些，一眼可见
• 分数下降能追到根因：能定位到具体哪条任务、哪段过程记录出了问题
• 关键回归集就是门禁：过不了就不发布（不讨论「感觉应该没事」）
• 换模型/换策略能算账：能快速判断「收益是否值得成本与风险” 」
• 线上与离线形成闭环：
  • 线上出现的新失败，能快速回流成任务进评测库
  • 离线提前发现的风险，能在上线前就挡住

最后一句：一定要看过程记录。

以上。