Agent评测不是跑通一次就完事，它的非确定性、黑盒化与错误级联让传统测试方法彻底失效。本文从产品经理视角出发，结合实战血泪经验，拆解如何构建体系化的Agent评测框架——从类型划分、指标定义到评测集设计，帮你把不稳定的智能行为收敛成可发布的工程质量。

做AI产品经理这几年，我见过太多这样的场面：

老板问：“咱们这个Agent（智能体）咋样了？”

研发兄弟挠挠头：“跑了几条Case，感觉还行。”

于是兴冲冲上线，结果用户一用——翻车了。有的答非所问，有的瞎承诺退款，还有的工具调了一半卡死了。

这时候大家才反应过来：Agent不是传统软件，不能靠“跑通一次”就当完工。 它是带脑子的系统，有随机性、有黑盒、错还会级联放大。你以为它是确定性的流水线，其实它更像个有时情绪不稳定的新员工。

最近重读了那篇《Agent 评测：方法论与体系设计》，深有感触。今天我就站在产品经理的角度，把这篇文章“翻译”一遍，加点血泪经验，聊聊Agent评测到底该怎么体系化、怎么落地、怎么让老板和研发都服气。

一、为什么Agent评测，是PM逃不掉的一课？

先泼盆冷水：Demo到生产，中间隔着一个太平洋。

传统软件好歹是“输入A，一定输出B”，我们能写单元测试覆盖。但Agent呢？

• 用户不知道要发什么，乱发。
• 同一句Prompt跑两次，结果可能不一样。

多轮对话聊着聊着，它把前面的上下文忘了。

最要命的是，它调工具改了系统状态，一步错、步步错（错误级联放大）。

Agent有三道槛——非确定性、黑盒化、错误级联。这三样凑一块儿，就意味着：

“跑几条Case感觉还行” ≈ 自欺欺人。

我吃过这亏。曾经一个客服Agent，测试环境里退款流程顺滑得很，结果上线后遇到“已发货订单”，它没查状态直接答应“能退”，被用户截图发群里投诉资损风险。一看Trace（执行轨迹），根本没调用订单查询工具，属于假阳性——答案看着像人话，过程早就偏了。

所以作为PM，你得明白：评测是要把不稳定的智能行为，收敛成可发布的工程质量。 评测平台的本质，是把问题转成可执行的修复动作，形成闭环。

一套成熟的评测体系，至少要回答三件事：

1. 能力水位：现在任务完成率多少？幻觉率多高？合规过不过？——给基线。
2. 变更风险：这版新Prompt、新模型、新工具参数是不是把旧场景搞坏了？——给回归门禁。
3. 优化方向：失败都堆在哪个能力域？该谁背锅去修？——给根因和行动项。

回答不了这三个问题，评测就是摆设。

二、先分类型，再定指标

先分清Agent类型，再定义评测指标；类型不分，结果基本不可用。

这事儿太常见了。有人拿“回答通顺不通顺”去评一个下单Agent，结果工具调错、钱扣了没记录，文采再好也白搭；反过来拿“工具调用准确率”去卡一个创意文案Agent，人家本来就要发散，你非要死磕参数，把灵感全卡没了。

站在PM视角，心里要有张表：

• 知识问答型（FAQ、政策咨询）：核心看准确性、忠实性、引用溯源。RAG指标+事实核验是底色，别让它瞎编。
• 任务执行型（退款、下单、预约）：别光看说了啥，看干成没。工具选对没？参数对不对？数据库状态变没变？Trace校验+后端比对才是真理。
• 推理决策型（故障诊断、方案推荐）：过程比结果重要。推理链成立不？证据够不够？得上轨迹评测+专家Judge。
• 多轮引导型（客服、销售）：记性好不好？会不会澄清？情绪接得住吗？User Simulator + Session级评测安排上。
• 创意生成型（文案、活动方案）：相关性、风格、合规底线，模型评分+品牌标准两手抓。
• 多Agent协作型：路由准不准？交接顺不顺？子Agent评测+端到端一起看。

底层骨架其实都能复用：执行用例 → 采集Trace → 跑Scorer（评分器） → 出报告 → 根因归类。但“评什么”和“怎么判”，必须按业务定制。

现在Agent里还流行用Skill（技能单元）封装工具调用和业务流程，PM要盯紧：Skill该不该触发？触发后走没走对流程？异常能不能降级？ 这些都得单独测评，不能全压在端到端分数上。

三、对话Agent最头疼：别只看单轮“答得还行”

如果你做的是客服、导购、售后这类对话形态Agent，我劝你一句：千万别平均每轮打分。

真实场景里，一轮一轮单独看都挺像人话，凑一块儿可能全程没解决问题——用户问成人票，它答了；下一轮问“小孩呢”，它失忆了；中途用户改口问“订单为啥没发”，它还死磕卖票。每轮单独打分可能都是及格，Session（整段会话）一综合：不及格。

我在项目里总结这几条：

• 上下文依赖：单轮没问题，整段像失忆——要靠Session级指标查指代消解。
• 目标动态变化：用户中途改需求——得造目标切换用例，看它会不会切任务、停旧动作。
• 业务流程约束：退款前必须查订单——把SOP转成可检查的状态机，别信它嘴上说说。
• 情绪与体验：用户炸毛了它还机械回复——定情绪回应标准，先安抚再解释，人工校准。
• 人机协同：该转人工时不转——盯转人工触发率、时机、交接摘要准不准。

正确姿势是四层一起看：

1. Turn（单轮）：每步回得合不合理？
2. Session（整段）：最终问题解决没？
3. Trace（执行轨迹）：工具调没调、顺序对不对、证据齐不齐？
4. Outcome（业务结果）：退款单真创建了？状态真改了？

只盯着Turn平均分，是自嗨。

四、指标体系：从“感觉好不好”到“门禁卡你”

PM的价值之一，就是把老板的“体验要好”翻译成可量化、可比较、可回归的指标。

Agent评测指标分成五大类：

P0（上线门禁，不达标别发）

功能正确性：任务完成率、答案准确率、工具调用/参数正确率。

稳定性与安全：幻觉率、越界承诺、隐私泄露、拒答正确率。

P1（版本对比、工程优化用）

过程质量：计划质量、工具顺序、重试次数、无效步骤占比。

效率与成本：平均轮次、耗时、token成本、工具调用次数。

P2（体验改善、长期观察）

体验与对齐：语气自然度、情绪承接、品牌风格、满意度。

如果用了Skill，还得补一组Skill子指标：

• 触发准不准？
• 参数对不对？
• 必须步骤过了没？
• 禁止动作有没有越界？
• 异常容错行不行？

这里有个生产级关键点：一致性。

我建议同一个任务跑N次，看俩数：

• 至少一次成功率：N次里只要成一次，说明有潜力，看上限。
• 连续成功率：N次全成，才算稳定，看下限——客服、支付、退款这种场景，用户不接受“多试几次总有一次对”。

生产系统死磕连续成功率。而且版本对比时，别只看单点分数，要配置信区间、显著性判断、最小可感知变化阈值，不然把随机波动当成能力提升，白高兴一场。

五、评测集不是随便捞：黄金集、边界、Badcase都得有

很多团队评测集=线上随机抽一批日志，看着热闹，其实幸存者偏差严重——正常流程占大头，边缘坑全被淹没了。

评测集是围绕高风险路径、关键逻辑和失败模式设计出来的质量资产，不是随机抽样。

我落地时的做法是四路并进：

1. 专家设计用例（Golden Set）：业务、质检、算法专家坐一块，定50–200条核心场景和高风险边界，锚定业务共识。比如“已发货订单申请退款，必须先查状态再解释规则”。
2. 扩展用例：基于专家用例，用规则定结构（订单状态、用户诉求、期望动作），再让LLM生成不同说法、情绪、边界组合，扩覆盖面。
3. 线上真实数据：按场景和风险分类抽，不全靠随机，补真实分布。
4. Badcase回流：线上失败、人工质检、投诉工单回收回来，沉淀原因和修复状态，这是最值钱的资产。

Skill型Agent的用例，我习惯沿四条线组织：

该不该触发 → 触发后过程对不对 → 最终产物好不好 → 异常/工具失败稳不稳。

记住：先有小而精的Golden Set把关门禁，再慢慢扩分类集、长尾集、对抗集、回流集。

六、评分：规则看硬条件，LLM看语义，人工看终判

评分器（Scorer）这块，有三类优先级：

1. 代码/规则Scorer：查工具调没调、字段有没、敏感词在不在——稳定、便宜、可复现，硬条件首选。
2. LLM-as-Judge：看解释质量、情绪承接、策略合理——接近专家判断，但要校准，防漂移、防自家模型偏心。
3. Human Scorer：业务口径没固化、高风险、争议Case、Judge抽检校准——成本高，但不可替代。

整体原则一句话：

能写成代码的，别让LLM猜；LLM能稳判的，别长期耗人工；人工留给定口径、终判、高风险。

LLM Judge别只写“请打1–5分”，好的Judge要有：

• 明确分档标准
• 输出reason（方便定位）
• few-shot + COT（边界样本写上）
• 周期性校准（跟人工一致率到85%左右再常态化）
• 多模型对抗打分，治偏见
• 我还加了一层人工评分路由：不是分数低于阈值就转人工，而是——Judge结论置信低、边界模糊、多Judge分歧
• 新模型/新Prompt/新工具Schema上线初期抽样
• 规则与Judge冲突

往上走还有分层筛查：

• 粗筛：规则 + 轻量LLM，快速分流通过/失败/存疑
• 精判：完整规则+LLM，确认Badcase，输出问题分类、现象、置信度、依据
• 人工复核：高风险、低置信、冲突样本

特别提一句假阳性检查：

• 必要路径检查（退款前必须查订单）
• 禁止路径检查（没查状态不能creat refund、不能承诺“一定”）
• 证据一致性（说“订单已发货”得有Trace支撑）风险信号（投诉升级没转人工？赔付没复核？）

评分结果别只吐pass/fail，问题分类、现象、置信度、判定依据都得带——这是给下一章根因定位铺路。

七、Badcase根因定位：从“哪儿错了”追到“谁去修”

评测打出低分只是开始，根因定位（RCA）才是PM推动落地的杀手锏。

原文给的链路很实用：

证据汇总 → 范围收敛 → 分模块诊断 → 责任判定 → 结构化落盘

我补充点PM视角的细节：

证据汇总：靠Trace。SessionId/ChatId/TraceId一串，把用户输入、Agent回复、模块IO、Prompt、工具返回、异常、耗时全拉齐。没Trace = 瞎猜。

范围收敛：别无差别排查，维护一张“问题现象 × 功能模块”映射表。

• 答非所问 → 意图识别、Query改写、知识筛选
• 订单未澄清 → 槽位抽取、上下文判断
• 事实性错误 → FAQ检索、知识筛选、回复生成
• 过度承诺 → 风险拦截、回复生成
• 命中走确定路径，未命中LLM兜底缩圈。

分模块诊断：逐个看候选模块input/output，标PASS/FAIL/SOFT_PASS，写关键证据。比如事实性错误，检索过了、知识筛过了，就生成模块背主责。

责任判定：三层来——

1. 严重模块直接定责
2. 规则引擎匹配确定模式
3. LLM汇总复杂链路责任传递

输出主责/次责、问题分类、问题枚举、修复建议。

结构化落盘：别只扔报告里，写进任务记录，方便看板、工单流转。

Skill相关失败还能再快分一层：

• 没调用Skill → 路由/意图/触发策略
• 调错Skill → Skill选择/任务分类
• 调对了但结果错 → Skill自身逻辑/工具/产物
• 输出对但Agent解释错 → Agent消费Skill结果/回复生成
• 单都对但整体败 → 编排/多Skill依赖/状态管理

根因标签要稳定可统计，绑定Owner：

Intent识别错（补样本/改澄清/Prompt）、Context丢（改摘要/状态管理）、Retrieval不足（补知识/改分片/召回重排）、Tool选错/参错（改描述/Schema/校验）、Reasoning错（改推理Prompt/中间校验）、Policy/SOP错（更新流程/规则/接管）、Response问题（模板/风格/体验）、System异常（工具稳定/降级/监控）。

PM在这里的核心作用是聚类：同一根因、同一场景、同一工具、同一知识点的Badcase聚成“问题簇”，比如“已发货退款场景23次跳过订单查询，集中在v1.8 Prompt”，一次修一片，而不是一条条修。

八、优化建议：别只说“优化Prompt”，要落到工单里

定位完根因，下一步是把原因翻译成动作。原文这点我很赞同：建议不能停在“优化Prompt”“加强训练”这种空话。

我要求团队产出结构化行动项，直接对接工单系统和研发流：

• 问题摘要：用业务语言描述失败模式（如：已发货退款场景未查订单就承诺退款）
• 影响范围：场景、样本数、失败率、风险等级（售后退款 / 18条失败 / P0资损）
• 根因判断：能力域+组件（退款Skill步骤约束缺失）
• 证据：关键Trace、工具调用、Judge reason
• 建议动作：可执行修复（修改退款Skill步骤描述，强制先查order.query再决定路径）
• Owner：Skill owner + Prompt owner
• 验收标准：回归集同类case通过率100%，越界承诺率0
• 优先级：P0/P1/P2

不同根因对应不同手段：

• Prompt/策略 → 改系统Prompt、工具说明、思考步骤、接管策略
• RAG/知识 → 补知识、改chunk、召回重排、引用校验
• 工具/API → 优化描述、Schema、错误码、幂等、超时降级
• 业务流程 → SOP显式化状态机/规则/工作流
• 产品交互 → 澄清入口、确认步骤、人工接管、风险提示
• 模型能力 → 换模型、微调、few-shot、拆任务

成熟度可以分四级：

• L0只报告
• L1生成工单
• L2生成可审阅配置建议（Prompt/规则/阈值）
• L3自动修复候选PR（人审+回归）

PM的价值，就是让评测报告→工单→修复→回归这条链跑通，而不是停在PPT上。

九、全链路闭环：Badcase是资产，不是垃圾

评测平台的终点不是报告，是把线上失败变成可复用的研发资产。

我常跟团队说：发现问题本身不产生价值，沉淀问题才产生价值。

一条Badcase至少能产三类反馈：

1. 回归用例：抽输入、期望动作、评分规则、根因标签，进Golden/Regression Set，防复发。
2. Prompt/工具改进建议：基于根因出diff或修改说明。
3. 业务规则/知识库修订：生成知识缺口、冲突规则、过期内容清单，反哺运营和业务。

平台层面分三条生产线：

• 评测生产线：Golden、Regression、对抗Case——防复发、扩覆盖
• 运营生产线：知识/SOP/规则/转人工配置缺口——修业务源头
• 模型生产线（可选）：偏好数据、SFT/DPO样本、工具调用轨迹——提模型与策略能力

入库要有标准，别什么都往回归集塞：

• 失败可复现或有稳定Trace+人工确认
• 期望行为明确，能写成规则/Judge标准
• 根因标签清、归到具体能力域/流程
• 有代表性，覆盖一类问题，非一次性抖动
• 已脱敏合规

同时做样本治理：同簇留代表例，P0/P1长期保留，稳定多版通过的可降抽样集；新分布靠主动学习优先捞低置信、高影响、新意图/工具/知识点入人工确认。

最终沉淀下来的，是质量资产库：用例库、Trace库、根因标签库、修复建议库、Judge校准集、回归集。资产越厚，后面迭代越不靠拍脑袋救火。

十、PM视角的几句大实话：评测是协作问题，不是技术问题

文章最后，跳出方法论，说点心里话。

做Agent评测这一年多，我发现技术只占一半，另一半是跨团队协作。

• 研发说“准确率85%”，你要问：是哪类场景？P0过了没？连续成功率多少？
• 算法说“换大模型吧”，你要先拉Trace看：是模型问题，还是检索没召回、工具Schema歧义、Prompt没约束步骤？
• 运营说“线上感觉变差了”，你要拿评测信号+线上信号对照：离线门禁过了没？转人工率、重复追问率、投诉率怎么变？
• 老板说“快点上线”，你要亮门禁：P0不达标不能发，连续成功率没到阈值不能放，资损/合规风险没清零不能松。

评测体系好不好，不看分打多高，而看它能不能稳定地把“低分”变成“谁去修、怎么修、修完怎么验”的行动项。

如果你的评测报告发出来，大家只会“嗯嗯不错”，然后该咋样还咋样——那评测就还是成本中心；

如果评测报告发出来，工单自动建、Owner自动分、回归集自动补、下个版本门禁自动卡——那评测才是真正的产品持续进化发动机。