# Demo 很惊艳，上线就翻车 ## 一次成功，凭什么相信下一次？ > 人人都在做 Agent，但真正靠谱落地的很少。 > > 当 Agent 在演示里成功完成了一次任务，你凭什么相信它下次还能完成？又怎么知道它到底能不能胜任真实工作？ 这篇文章写给已经做出 Agent 原型，却卡在下面三个问题上的人： - 如何判断这次改动到底有没有效果？ - 如何判断 Agent 达到了可发布的标准？ - 它看起来"进化"了——是真实变好了，还是凭感觉的赌？ **先说结论：** Agent 的评测，本质是把「我觉得它行」换成「**我能证明它行**」。做法只有三步：**从用户想要的结果倒推**，为结果找到**可检查的证据**，再把证据变成**可重复运行的测试**。所有评测方法——人工、LLM 当裁判、仿真轨迹——都只是这三步在不同成本档位上的实现。 --- ## 01 Demo 很惊艳，上线就翻车 过去一年，我见过太多"惊艳的 Demo"死在第二周。 演示现场，Agent 条理清晰地拆解了用户诉求，查了订单、对了政策、建了工单，还贴心地补了一句安抚。会议室里有人鼓了掌。三周后上线，客服群里开始甩截图： - "它把我的退款金额算错了" - "同一个问题问了三次，它给了三个答案" - "客户要转人工，它一直说'我还能帮您做什么'" 问题不在于 Agent 不行。问题在于：**我们从来没能说清楚"它行"是什么意思，自然也无法知道它什么时候不行了。** ### 三个大概率的似曾相识 **第一个场景：** 你挑了几个典型案例，反复调整 prompt、拆结构、加 few-shot、换模型，直到它终于稳稳地给出了你想要的效果。那一刻你甚至有点肃然起敬——"这玩意儿是真聪明"。 **第二个场景：** 测试阶段，大家把截图一张张甩进群里。这条不对、那条也不对、这条刚才还对现在又不对了。你在几十张截图之间来回切换，越看越乱，最后只能凭印象拍板："感觉比昨天好点。" **第三个场景：** 那些"似曾相识"的问题——明明上周修过的那个错，今天又冒出来了，改一条坏一条，像在跟一个贪玩的小孩玩捉迷藏。 然后你开始自省，开始怀疑自己：是不是我不适合做这个？ > **别急着自己怀疑。** 这不是你能力的问题，是你手上缺一件工具。 > > 没有评测的 Agent 开发，就像闭着眼睛调音——你能听见"好像不对"，但你说不出该拧哪颗螺丝、拧多少、拧完到底好了没有。 ### 把焦虑拆成四个具体问题 "感觉不稳定"是个情绪，不是个问题。它拆开之后，其实是四个可以被回答的问题： | 问题 | 为什么 | | --- | --- | | **Q1 一次成功为什么不够？** | 因为一次成功可能来自运气——你恰好挑中了它擅长的输入。你要的不是"某次成功"，而是**在真实分布上稳定成功的概率**。抽样一次，估不出概率。 | | **Q2 怎样定义"完成了任务"？** | 从**用户视角**定义，而不是从 Agent 视角。Agent 说"我已经为您解答了"不算完成；用户不用再问第二遍、问题真的闭环了，才算完成。 | | **Q3 怎样把定义变成可重复的测试？** | 把口头判断改写成**断言**：给定这个输入，必须出现这个结果。断言能被机器执行、能回归、能在每次改动后自动跑一遍。 | | **Q4 拿到结果后，怎样决定下一步改哪？** | 评测的终点不是分数，是**决策**：改哪个模块、能不能放量、要不要回滚。看到分数却不知道改哪，等于没评测。 | ### 回到出发点：为什么要有这个 Agent 把这四个问题往前推一步，会推到一个更根本的地方。 我们为什么要做这个 Agent？为了满足用户的某种需要。谁是这个系统最终结果的获得者？**用户。** 不是你的 KPI，不是演示会上的掌声，是那个带着一个真实问题找上门的人。 > **Agent 的评测应当从「用户希望得到的结果」出发，再为这个结果寻找「可检查的证据」。** > > —— 这句话是全文的题眼。后面所有方法，都是它的展开。 注意这句话的两个半边，缺一不可： - **从结果出发** —— 否则你会陷入"测试一大堆指标，却没一个跟用户感受有关"的自我感动； - **找可检查的证据** —— 否则"用户满意"就只是一句无法执行的愿望。 --- ## 02 先定义"完成"，再谈评测 很多人一上来就问"用什么工具评测"。工具是最不重要的那一步。**先要能说清楚：什么算完成。** 以跨境电商客服里最常见的一个场景为例——"我要退货"。用户嘴里的一句话，翻译成用户真正想要的结果是： > **用户想要的结果：** 退货这件事被办成了，而且我不用把问题重复讲一遍。 那"证据"是什么？证据要能被人看见、被机器检查。它分布在四个层次上： | 证据层 | 要检查什么 | 举例（退货场景） | | --- | --- | --- | | **说对了什么** · 内容层 | 关键事实是否准确，政策引用是否正确 | 退款金额算对（¥268，不是 ¥180）；政策引用正确（7 天无理由 / 15 天质量问题） | | **做对了什么** · 动作层 | 该调的工具是否调了、参数是否对 | 查了订单 ORD20240715002；创建工单类型 = 退款；未误触"取消订单" | | **结束了什么** · 状态层 | 会话 / 工单是否进入正确的终止状态 | 会话正常结束而非沉默超时；72 小时内无二次进线；未发生非必要转人工 | | **感觉如何** · 体验层 | 用户的情绪与主观评价 | CSAT 打分；负面情绪是否在对话中被成功化解 | 这张表就是"可检查的证据"的具体形态。**一旦写成这样，评测就从"感觉"变成了"跑一遍看断言过没过"。** 而它也顺手回答了下一个问题：改完到底有没有变好——看哪一层的前通过率变了。 > ⚠️ **常见误区：只定义最后一层。** "客户满意度 > 4.2"当然重要，但它是滞后指标——等它掉下来，错误已经发生了几万次。前三层是**先行指标**，能在问题伤到用户之前拦住它。 ### 顺手把指标定下来：六个科目一起看 结果定义清楚后，指标是自然长出来的。做客服 Agent 通常会落在这六个上——我把它们叫"六个科目"，因为偏科的学生一定会出事： | 科目 | 它在回答什么 | 健康线 | 掉了先查什么 | | --- | --- | --- | --- | | **解决率** | 问题真的被解决了吗 | > 75% | 知识库是否漏了新政策 | | **首解率 FCR** | 一次就解决，不用回头 | > 65% | 答了，但有没有答透 | | **转人工率** | 搬救兵的比例是否合理 | 20-35% | 低于 15% 要警惕：是不是该转没转 | | **CSAT** | 用户的感受 | > 80%（Top-Box） | 按意图拆开看，别混着看 | | **单会话成本** | 服务一次花多少钱 | < ¥0.5 | 是否上了不必要的长上下文 | | **逃逸率** | 答不出又没喊老师的比例 | < 3% | 转人工通道是否失效 | 前三个回答"干得好不好"，后三个回答"代价是什么"。**只盯前者，你会得到一份很好看的月报和一张很难看的账单。** 这里必须提一个真实案例，因为它太典型了：某团队连续三个月只看解决率和 CSAT，看起来一切平稳。直到财务发现——解决率从 78% 涨到 81%、CSAT 稳在 4.2 的同时，**月净亏 16 万**。原因很简单：为了让"解决率"更好看，他们放任上下文无限增长，单会话 Token 成本悄悄翻了一倍。 > 🚨 **教训：单指标一定可以被优化到失真。** 指标不是用来"达标"的，是用来"互相牵制"的。你要的从来不是某个数字漂亮，而是这六个数字同时站在健康区里。 --- ## 03 三种评测方式，和它们各自的坑 结果定义清楚了，接下来才轮到"怎么测"。就像传统系统研发一样，**组件级评测是最直接验证结果能否如我们预料的那样发展的必要方式**——先把整车拆成零件，因为整车里任何一个零件坏了，表现都是"车不走了"，你根本不知道该拧哪儿。 ### 3.1 组件级评测：先拆零件，再测整车 一个客服 Agent 在工程上不是一个东西，而是一串零件：意图识别 → 槽位抽取 → 检索 → 回复生成 → 工具调用 → 路由决策。组件级评测就是给每个零件单独出题，外部依赖全部 mock 掉。 | 零件 | 断言什么 | 最常见的坏法 | | --- | --- | --- | | **意图识别** | 输入 → 预期意图标签 | 把"我要退钱"判成"查询订单"（相邻意图混淆） | | **槽位抽取** | 订单号 / 金额 / 时间是否抽对 | 多轮里槽位被覆盖、被遗忘 | | **检索 RAG** | Top-K 是否命中正确文档 | 召回了相似但过期的旧政策 | | **回复生成** | 事实与语气是否达标 | 事实对但语气冷，或事实错但语气好 | | **工具调用** | 该不该调、参数对不对 | 参数幻觉：编了一个不存在的订单号 | 组件级评测的三个好处：**定位快**（失败直接落到零件上）、**成本低**（毫秒级、可跑几千条）、**可回归**（每次改代码自动跑）。它是评测体系的地基，不是可选项。 具体到数字上，工程上常见的做法是：单元测试覆盖率 **≥ 80%**，检索这条链路用 **Top-50 → Rerank → Top-5** 的两阶段验证，相似度阈值卡在 **0.65** 附近。**这些不是"最佳实践"，而是让失败可复现的最低门槛。** ### 3.2 人工评测：贵，但它是尺子的原器 人工评测是金标准——不是因为人不会错，而是因为**标准本身是由人定义的**。它有两个不可替代的用途： 1. **造基准。** 算法打出来的分，最终都要和人的判断对一遍，才知道准不准。 2. **判长尾。** 那些规则写不出来、又确实很关键的场景（讽刺、方言、情绪化表达），只有人能判。 但人工评测有三个纪律，不遵守就是白花钱： - **盲评** —— 评的人不能知道这是哪个版本、哪个模型产出的。带着预设打的分不叫评测，叫确认偏误。 - **双人 + 算一致率** —— 关键样本至少两人独立标注，算标注者间一致性。两人都对不齐的标准，机器更对不齐。 - **抽样要有攻击性** —— 别只抽随机样本。主动抽：高频意图、上个月失败过的、情绪激烈的、边界模糊的。 ### 3.3 LLM as Judge：能规模化，但你要知道它在骗你 人工评测的瓶颈是成本，于是大家开始让大模型当裁判（LLM as Judge）。它确实解决了规模问题：几千条会话可以在几分钟内打完分。但这个方法有几个必须先认清的问题： | 问题 | 表现 | 应对 | | --- | --- | --- | | **长度偏见** | 倾向给更长的回答打高分——写得啰嗦反而得分高 | 打分维度里单列"简洁性"；或对长度做归一 | | **位置偏见** | 做 A/B 对比时，受选项顺序影响，谁排在前面谁容易赢 | 交换顺序各评一次，两次取平均 | | **稳定性问题** | 同一个输入多次打分不一致，分数抖动 | 固定温度参数；多次采样取中位数；记录方差 | 这三个偏见不会因为换个更强的模型就消失，它们是评判机制本身带来的。 所以最关键的从来不是"用哪个模型当裁判"，而是**校准**： > **用人工标注做基准，裁判与人工的一致率需要达到 85% 以上，这个裁判才允许上岗。** > > 低于这条线，它打出来的所有分数都只是噪音——更糟的是，是看起来很专业的噪音。 还有两条容易被忽略的工程经验： - **裁判要和被测模型异厂商。** 生产用 A 家的模型，就用 B 家的来评判。同一个模型家族共享相似的偏好与盲区，自己给自己改卷，只会系统性地高估。 - **打分要拆维度。** 别问"这个回答好不好"，要拆成准确性 / 完整性 / 语气三项各 1-5 分。笼统的分数无法驱动改进——你拿到 3.2 分，也不知道该改什么。 ### 3.4 仿真轨迹：把"多轮 + 工具调用"跑成可复现的剧本 前三种方法有个共同的盲区：它们大多在评"一句话的回复"。但 Agent 和聊天机器人的本质区别，恰恰在于它会**多轮推进、调用工具、改变系统状态**。 仿真轨迹要做的就是：用一个模拟用户（有人设、有目标、有情绪曲线）去跟 Agent 跑完整条链路，然后检查**整条轨迹**是否合法——不只检查它最后回答得对不对。 | 检查点 | 问题 | | --- | --- | | **路径合法性** | 状态机有没有走非法转移？该澄清的有没有澄清？ | | **工具调用序列** | 调用顺序对不对？有没有多余调用、重复调用、漏调用？ | | **上下文一致性** | 第 5 轮还记得第 2 轮说过的订单号吗？有没有自相矛盾？ | | **终止正确性** | 该结束时结束了吗？还是陷入循环、或者过早放弃？ | 能规模化跑长链路、能复现、能覆盖真实流量里的长尾——这是仿真轨迹的最大价值。典型配置是 **20-30 个完整场景**，每个场景组合不同意图、情绪与多轮分支。 > ⚠️ **它的风险也很明确：仿真用户和真实用户的分布不一致。** 你设计的模拟用户只覆盖你能想到的路径。所以仿真轨迹不能替代真实流量验证——线上要高比例抽样回放（shadow），用真实数据反向修正你的仿真剧本集。 --- ## 04 从"一次成功"到"可重复的测试" 方法讲完了，现在把它们装进一套能天天跑的系统里。这套系统的第一块砖，是一份**测试集**。 ### 第一步：把 100 道真题攒起来 不要凭空编题。真实日志里躺着你最需要的题目分布。起步做法务实到近乎无聊： 1. **抽 100 条真实会话**，覆盖 5 类意图、正负情绪、单轮与多轮； 2. **人工给每条写出"标准答案"**——包括正确的事实、该调的工具、应有的终止状态； 3. **把它变成断言**：可以被机器自动判过或不过，而不是让另一个人再读一遍。 听起来工作量不小，但它是一次性投入、长期复用。而且它会立刻带来一个副作用：**你第一次能说出"这次改动让通过率从 72% 变成了 81%"。** > ⚠️ **两个必须防的坑：** > > ① **测试集泄漏**——拿测试题去调 prompt，等于把答案写进模型，分数会虚高，上线即打回原形； > > ② **测试集僵化**——业务变了、政策变了，题库不更新，你测的是去年的世界。定个节奏，双周更新一次。 ### 第二步：分层测试，让便宜的测试拦住大部分问题 真实工程里不会只有一份测试集。问题越早发现越便宜——这句话决定了测试必须是金字塔结构： | 层级 | 对应什么 | 内容与门槛 | | --- | --- | --- | | **L4 线上监控** | 大考（真实流量） | 真实用户、真实流量，每天都在跑 | | **L3 预发布评估** | 模拟考 | 100 道真题；放行门槛：意图 **≥90%** / 检索 **≥85%** / 回复 **≥80%** | | **L2 集成测试** | 月考 | 20-30 个完整场景，多轮 + 工具 + 转人工 | | **L1 单元测试** | 随堂测 | 零件级，依赖全 mock，覆盖率 ≥80% | L3 那三个门槛数字（**90 / 85 / 80**）值得抄进你们的发布检查表——它们是"能不能放行"的硬开关，不是参考值。 ### 第三步：给 Agent 划一条"及格线" Agent 每次回答都带着一个把握分（置信度，0-1）。把握分够高就直接答，不够高就走澄清或转人工。**这条线划在哪，直接决定它是"敢答但爱错"还是"保守但爱推"。** 同一份数据、三种及格线的实测对比： | 置信度阈值 | 精确率 P | 召回率 R | F1 综合分 | 结论 | | --- | --- | --- | --- | --- | | **0.7（严格）** | 82% | 78% | 80.0 | 准，但 22% 该答的被拒，转人工率被推高 | | **0.6（平衡）** | 75% | 88% | **81.0 ★** | 两种代价最平衡 | | **0.5（宽松）** | 68% | 93% | 78.6 | 敢答，但错答率 32%，客户信任受损 | 阈值往上调：更准，但该答的也不敢答（召回率掉、转人工率涨）；往下调：敢答，但错答变多。**没有标准答案，只有"你更怕哪一种代价"。** 而且不同意图应该用不同阈值——**答错代价越大，及格线越高**： | 意图类型 | 建议阈值 | 理由 | | --- | --- | --- | | 查物流 | 0.55 | 答错代价低，客户多问一句而已 | | 产品咨询 | 0.60 | 一般性表述，容错空间中等 | | 退换货政策 | 0.70 | 规则性强，说错会引发纠纷 | | 退款 / 金额相关 | 0.85 | 说错直接产生资损与投诉 | ### 第四步：合成一个总分，防止"偏科"和"假性健康" 六个科目各打一个分，按权重加权求和，得到 0-100 的健康度。解决率权重最高（30%），其余 10-15%。 | 综合分 | 状态 | | --- | --- | | ≥ 85 | ✅ 健康 | | 60 - 85 | ⚠️ 亚健康 | | < 60 | ❌ 异常 | 综合分不是为了让老板看着开心，它是**防骗机制**：单个指标可以骗人，六个同时骗你的概率小得多。 ### 第五步：拿到结果，决定下一步改哪 评测真正的产出不是分数，是**归因**。看一个真实的三个月： | 时间 | 解决率 | 单会话成本 | ROI | | --- | --- | --- | --- | | 2 月 | 78.3% | ¥0.42 | 1.35 | | 3 月 | 76.1% ↓ | ¥0.58 ↑38% | 0.92 ↓32% | | 4 月 | 83.5% ↑ | ¥0.39 ↓ | 1.62 ↑76% | 2 月时 CSAT 还稳在 4.21，看起来一切正常。**但三项指标同向恶化**——解决率微降、成本涨 38%、ROI 跌 32%。如果只看 CSAT，你要等到 3 月才发现；看综合分，2 月就报警了。 而 4 月的回升也不是靠"再调调 prompt"，是**归因**的结果：补 50 条物流 FAQ + 回退长上下文 + 恢复 200 个转人工关键词。 #### 要不要放量？——A/B 测试，必须有对照组 某团队优化 prompt 后，解决率从 76% 涨到 81%，全员庆功。同一时间，跑着旧版本的对照组也涨到了 80%。**真实提升只有 1 个点，其余 4 个点是季节性咨询变简单了。** 没有对照组，他们大概率会把这次"运气"当成"方法"，推广到所有场景。 做对比测试的要点很朴素： 1. 随机分桶（同一用户始终进同一组）； 2. 一次只改一个变量； 3. 跑之前就定好主指标和胜出条件； 4. **给守护指标一票否决权**——主指标赢了但成本或投诉率恶化，直接判负。 另外三个动作都是作弊：每天偷看、试 20 个指标挑一个显著的发战报、跑三天就宣布胜利。 #### 要不要全量？——灰度，一步一级 大考过了也别一次性全放。按 **1% → 10% → 50% → 100%** 推进，每一级有观察期和门票：意图准确率 **≥90%**、检索命中 **≥85%**、回复质量 **≥80%**。任何一级不达标就地回滚，而回滚通道要提前演练过——目标是在 5 分钟内退回旧版本。 > **回滚不是失败，是保险生效。** 一个从没演练过回滚的团队，等于把"能不能退回去"这件事交给了运气。 #### 上线之后呢？——告警管急症，巡检管慢病 上线不是终点。生产环境要有告警（分钟级响应突发），也要有巡检（每天低峰自动跑核心测试集，抓那些"悄悄变坏"的慢变量：知识过期、模型漂移）。 告警贵精不贵多——**凡是响了但你做不了任何动作的告警，都是噪音，删掉或降级成周报**。告警太多，结果是全部静音。 --- ## 05 五条总结 ### 1. 评测标准要先于开发建立 标准不是开发完之后补上的"验收环节"，它是需求的一部分。先想清楚"怎么算做对了"，再动手写第一行 prompt。 > 人话：没有验收标准的开发，等于没有施工图的装修。 ### 2. 警惕指标崇拜 任何单一指标被当作目标，都会被优化到失真。解决率可以靠"磨"上去，转人工率可以靠"不敢转"压下去，CSAT 可以靠"挑人发问卷"刷上去。 > 人话：指标之间要互相牵制，六个一起看。 ### 3. 重视过程胜于结果，警惕"蒙对答案" 答对了不代表做对了。它可能检索到了错误的文档、用错误的路径凑出了正确的结论——换个输入立刻就错，而你浑然不知。所以要看轨迹：检索命中了吗？工具调用合法吗？状态转移正确吗？ > 人话：蒙对的答案，会在下一次变成错的答案。 ### 4. 评测是持续的，要 CI/CD 化 知识会过期、模型会漂移、业务会变。一次性的评测报告，本质是一张过期的体检单。把评测接进流水线，让它像单元测试一样每次改动自动跑。 > 人话：不是考一次期末考，是每天都随堂测。 ### 5. 让评测服务于决策 一个分数如果不能指向一个动作，它就只是装饰。评测的输出应该是三种决策：**改哪里**、**能不能放量**、**要不要回滚**。 > 人话：分数是用来做决定的，不是用来汇报的。 --- ## 06 写在最后 回到开头那个问题：当 Agent 在演示里完成了一次任务，你凭什么相信它下次还能完成？ 答案不是"再试几次看看"，也不是"我觉得它挺稳定的"。答案是：**因为你知道"完成"的定义是什么，知道要用哪些证据去检查它，并且这些检查每次都自动跑一遍，结果可比较、可追溯、可复盘。** 这件事没有想象中那么重。你不需要一上来就建一套完美的评测平台。把它拆到最小可行动作，其实只有三件事： | 最小动作 | 具体做什么 | | --- | --- | | **① 一百道真题** | 从真实日志抽 100 条，人工写出标准答案，变成能自动判过不过的断言 | | **② 六个指标上墙** | 把解决率、FCR、转人工率、CSAT、成本、逃逸率的当前值算出来，贴在团队每天都能看到的地方 | | **③ 一个 badcase 会** | 每周 30 分钟，只看失败案例做归因，不听成绩汇报 | 这三件事跑起来，你已经超过大多数团队了——他们还在用"感觉还行"，管理着一个每天要和几千个真实用户说话的系统。 > **把「我觉得它行」换成「我能证明它行」。** > > 这是 Agent 从 Demo 走向生产，唯一必须跨过的那道坎。 Loading... # Demo 很惊艳，上线就翻车 ## 一次成功，凭什么相信下一次？ > 人人都在做 Agent，但真正靠谱落地的很少。 > > 当 Agent 在演示里成功完成了一次任务，你凭什么相信它下次还能完成？又怎么知道它到底能不能胜任真实工作？ 这篇文章写给已经做出 Agent 原型，却卡在下面三个问题上的人： - 如何判断这次改动到底有没有效果？ - 如何判断 Agent 达到了可发布的标准？ - 它看起来"进化"了——是真实变好了，还是凭感觉的赌？ **先说结论：** Agent 的评测，本质是把「我觉得它行」换成「**我能证明它行**」。做法只有三步：**从用户想要的结果倒推**，为结果找到**可检查的证据**，再把证据变成**可重复运行的测试**。所有评测方法——人工、LLM 当裁判、仿真轨迹——都只是这三步在不同成本档位上的实现。 --- ## 01 Demo 很惊艳，上线就翻车 过去一年，我见过太多"惊艳的 Demo"死在第二周。 演示现场，Agent 条理清晰地拆解了用户诉求，查了订单、对了政策、建了工单，还贴心地补了一句安抚。会议室里有人鼓了掌。三周后上线，客服群里开始甩截图： - "它把我的退款金额算错了" - "同一个问题问了三次，它给了三个答案" - "客户要转人工，它一直说'我还能帮您做什么'" 问题不在于 Agent 不行。问题在于：**我们从来没能说清楚"它行"是什么意思，自然也无法知道它什么时候不行了。** ### 三个大概率的似曾相识 **第一个场景：** 你挑了几个典型案例，反复调整 prompt、拆结构、加 few-shot、换模型，直到它终于稳稳地给出了你想要的效果。那一刻你甚至有点肃然起敬——"这玩意儿是真聪明"。 **第二个场景：** 测试阶段，大家把截图一张张甩进群里。这条不对、那条也不对、这条刚才还对现在又不对了。你在几十张截图之间来回切换，越看越乱，最后只能凭印象拍板："感觉比昨天好点。" **第三个场景：** 那些"似曾相识"的问题——明明上周修过的那个错，今天又冒出来了，改一条坏一条，像在跟一个贪玩的小孩玩捉迷藏。 然后你开始自省，开始怀疑自己：是不是我不适合做这个？ > **别急着自己怀疑。** 这不是你能力的问题，是你手上缺一件工具。 > > 没有评测的 Agent 开发，就像闭着眼睛调音——你能听见"好像不对"，但你说不出该拧哪颗螺丝、拧多少、拧完到底好了没有。 ### 把焦虑拆成四个具体问题 "感觉不稳定"是个情绪，不是个问题。它拆开之后，其实是四个可以被回答的问题： | 问题 | 为什么 | | --- | --- | | **Q1 一次成功为什么不够？** | 因为一次成功可能来自运气——你恰好挑中了它擅长的输入。你要的不是"某次成功"，而是**在真实分布上稳定成功的概率**。抽样一次，估不出概率。 | | **Q2 怎样定义"完成了任务"？** | 从**用户视角**定义，而不是从 Agent 视角。Agent 说"我已经为您解答了"不算完成；用户不用再问第二遍、问题真的闭环了，才算完成。 | | **Q3 怎样把定义变成可重复的测试？** | 把口头判断改写成**断言**：给定这个输入，必须出现这个结果。断言能被机器执行、能回归、能在每次改动后自动跑一遍。 | | **Q4 拿到结果后，怎样决定下一步改哪？** | 评测的终点不是分数，是**决策**：改哪个模块、能不能放量、要不要回滚。看到分数却不知道改哪，等于没评测。 | ### 回到出发点：为什么要有这个 Agent 把这四个问题往前推一步，会推到一个更根本的地方。 我们为什么要做这个 Agent？为了满足用户的某种需要。谁是这个系统最终结果的获得者？**用户。** 不是你的 KPI，不是演示会上的掌声，是那个带着一个真实问题找上门的人。 > **Agent 的评测应当从「用户希望得到的结果」出发，再为这个结果寻找「可检查的证据」。** > > —— 这句话是全文的题眼。后面所有方法，都是它的展开。 注意这句话的两个半边，缺一不可： - **从结果出发** —— 否则你会陷入"测试一大堆指标，却没一个跟用户感受有关"的自我感动； - **找可检查的证据** —— 否则"用户满意"就只是一句无法执行的愿望。 --- ## 02 先定义"完成"，再谈评测 很多人一上来就问"用什么工具评测"。工具是最不重要的那一步。**先要能说清楚：什么算完成。** 以跨境电商客服里最常见的一个场景为例——"我要退货"。用户嘴里的一句话，翻译成用户真正想要的结果是： > **用户想要的结果：** 退货这件事被办成了，而且我不用把问题重复讲一遍。 那"证据"是什么？证据要能被人看见、被机器检查。它分布在四个层次上： | 证据层 | 要检查什么 | 举例（退货场景） | | --- | --- | --- | | **说对了什么** · 内容层 | 关键事实是否准确，政策引用是否正确 | 退款金额算对（¥268，不是 ¥180）；政策引用正确（7 天无理由 / 15 天质量问题） | | **做对了什么** · 动作层 | 该调的工具是否调了、参数是否对 | 查了订单 ORD20240715002；创建工单类型 = 退款；未误触"取消订单" | | **结束了什么** · 状态层 | 会话 / 工单是否进入正确的终止状态 | 会话正常结束而非沉默超时；72 小时内无二次进线；未发生非必要转人工 | | **感觉如何** · 体验层 | 用户的情绪与主观评价 | CSAT 打分；负面情绪是否在对话中被成功化解 | 这张表就是"可检查的证据"的具体形态。**一旦写成这样，评测就从"感觉"变成了"跑一遍看断言过没过"。** 而它也顺手回答了下一个问题：改完到底有没有变好——看哪一层的前通过率变了。 > ⚠️ **常见误区：只定义最后一层。** "客户满意度 > 4.2"当然重要，但它是滞后指标——等它掉下来，错误已经发生了几万次。前三层是**先行指标**，能在问题伤到用户之前拦住它。 ### 顺手把指标定下来：六个科目一起看 结果定义清楚后，指标是自然长出来的。做客服 Agent 通常会落在这六个上——我把它们叫"六个科目"，因为偏科的学生一定会出事： | 科目 | 它在回答什么 | 健康线 | 掉了先查什么 | | --- | --- | --- | --- | | **解决率** | 问题真的被解决了吗 | > 75% | 知识库是否漏了新政策 | | **首解率 FCR** | 一次就解决，不用回头 | > 65% | 答了，但有没有答透 | | **转人工率** | 搬救兵的比例是否合理 | 20-35% | 低于 15% 要警惕：是不是该转没转 | | **CSAT** | 用户的感受 | > 80%（Top-Box） | 按意图拆开看，别混着看 | | **单会话成本** | 服务一次花多少钱 | < ¥0.5 | 是否上了不必要的长上下文 | | **逃逸率** | 答不出又没喊老师的比例 | < 3% | 转人工通道是否失效 | 前三个回答"干得好不好"，后三个回答"代价是什么"。**只盯前者，你会得到一份很好看的月报和一张很难看的账单。** 这里必须提一个真实案例，因为它太典型了：某团队连续三个月只看解决率和 CSAT，看起来一切平稳。直到财务发现——解决率从 78% 涨到 81%、CSAT 稳在 4.2 的同时，**月净亏 16 万**。原因很简单：为了让"解决率"更好看，他们放任上下文无限增长，单会话 Token 成本悄悄翻了一倍。 > 🚨 **教训：单指标一定可以被优化到失真。** 指标不是用来"达标"的，是用来"互相牵制"的。你要的从来不是某个数字漂亮，而是这六个数字同时站在健康区里。 --- ## 03 三种评测方式，和它们各自的坑 结果定义清楚了，接下来才轮到"怎么测"。就像传统系统研发一样，**组件级评测是最直接验证结果能否如我们预料的那样发展的必要方式**——先把整车拆成零件，因为整车里任何一个零件坏了，表现都是"车不走了"，你根本不知道该拧哪儿。 ### 3.1 组件级评测：先拆零件，再测整车 一个客服 Agent 在工程上不是一个东西，而是一串零件：意图识别 → 槽位抽取 → 检索 → 回复生成 → 工具调用 → 路由决策。组件级评测就是给每个零件单独出题，外部依赖全部 mock 掉。 | 零件 | 断言什么 | 最常见的坏法 | | --- | --- | --- | | **意图识别** | 输入 → 预期意图标签 | 把"我要退钱"判成"查询订单"（相邻意图混淆） | | **槽位抽取** | 订单号 / 金额 / 时间是否抽对 | 多轮里槽位被覆盖、被遗忘 | | **检索 RAG** | Top-K 是否命中正确文档 | 召回了相似但过期的旧政策 | | **回复生成** | 事实与语气是否达标 | 事实对但语气冷，或事实错但语气好 | | **工具调用** | 该不该调、参数对不对 | 参数幻觉：编了一个不存在的订单号 | 组件级评测的三个好处：**定位快**（失败直接落到零件上）、**成本低**（毫秒级、可跑几千条）、**可回归**（每次改代码自动跑）。它是评测体系的地基，不是可选项。 具体到数字上，工程上常见的做法是：单元测试覆盖率 **≥ 80%**，检索这条链路用 **Top-50 → Rerank → Top-5** 的两阶段验证，相似度阈值卡在 **0.65** 附近。**这些不是"最佳实践"，而是让失败可复现的最低门槛。** ### 3.2 人工评测：贵，但它是尺子的原器 人工评测是金标准——不是因为人不会错，而是因为**标准本身是由人定义的**。它有两个不可替代的用途： 1. **造基准。** 算法打出来的分，最终都要和人的判断对一遍，才知道准不准。 2. **判长尾。** 那些规则写不出来、又确实很关键的场景（讽刺、方言、情绪化表达），只有人能判。 但人工评测有三个纪律，不遵守就是白花钱： - **盲评** —— 评的人不能知道这是哪个版本、哪个模型产出的。带着预设打的分不叫评测，叫确认偏误。 - **双人 + 算一致率** —— 关键样本至少两人独立标注，算标注者间一致性。两人都对不齐的标准，机器更对不齐。 - **抽样要有攻击性** —— 别只抽随机样本。主动抽：高频意图、上个月失败过的、情绪激烈的、边界模糊的。 ### 3.3 LLM as Judge：能规模化，但你要知道它在骗你 人工评测的瓶颈是成本，于是大家开始让大模型当裁判（LLM as Judge）。它确实解决了规模问题：几千条会话可以在几分钟内打完分。但这个方法有几个必须先认清的问题： | 问题 | 表现 | 应对 | | --- | --- | --- | | **长度偏见** | 倾向给更长的回答打高分——写得啰嗦反而得分高 | 打分维度里单列"简洁性"；或对长度做归一 | | **位置偏见** | 做 A/B 对比时，受选项顺序影响，谁排在前面谁容易赢 | 交换顺序各评一次，两次取平均 | | **稳定性问题** | 同一个输入多次打分不一致，分数抖动 | 固定温度参数；多次采样取中位数；记录方差 | 这三个偏见不会因为换个更强的模型就消失，它们是评判机制本身带来的。 所以最关键的从来不是"用哪个模型当裁判"，而是**校准**： > **用人工标注做基准，裁判与人工的一致率需要达到 85% 以上，这个裁判才允许上岗。** > > 低于这条线，它打出来的所有分数都只是噪音——更糟的是，是看起来很专业的噪音。 还有两条容易被忽略的工程经验： - **裁判要和被测模型异厂商。** 生产用 A 家的模型，就用 B 家的来评判。同一个模型家族共享相似的偏好与盲区，自己给自己改卷，只会系统性地高估。 - **打分要拆维度。** 别问"这个回答好不好"，要拆成准确性 / 完整性 / 语气三项各 1-5 分。笼统的分数无法驱动改进——你拿到 3.2 分，也不知道该改什么。 ### 3.4 仿真轨迹：把"多轮 + 工具调用"跑成可复现的剧本 前三种方法有个共同的盲区：它们大多在评"一句话的回复"。但 Agent 和聊天机器人的本质区别，恰恰在于它会**多轮推进、调用工具、改变系统状态**。 仿真轨迹要做的就是：用一个模拟用户（有人设、有目标、有情绪曲线）去跟 Agent 跑完整条链路，然后检查**整条轨迹**是否合法——不只检查它最后回答得对不对。 | 检查点 | 问题 | | --- | --- | | **路径合法性** | 状态机有没有走非法转移？该澄清的有没有澄清？ | | **工具调用序列** | 调用顺序对不对？有没有多余调用、重复调用、漏调用？ | | **上下文一致性** | 第 5 轮还记得第 2 轮说过的订单号吗？有没有自相矛盾？ | | **终止正确性** | 该结束时结束了吗？还是陷入循环、或者过早放弃？ | 能规模化跑长链路、能复现、能覆盖真实流量里的长尾——这是仿真轨迹的最大价值。典型配置是 **20-30 个完整场景**，每个场景组合不同意图、情绪与多轮分支。 > ⚠️ **它的风险也很明确：仿真用户和真实用户的分布不一致。** 你设计的模拟用户只覆盖你能想到的路径。所以仿真轨迹不能替代真实流量验证——线上要高比例抽样回放（shadow），用真实数据反向修正你的仿真剧本集。 --- ## 04 从"一次成功"到"可重复的测试" 方法讲完了，现在把它们装进一套能天天跑的系统里。这套系统的第一块砖，是一份**测试集**。 ### 第一步：把 100 道真题攒起来 不要凭空编题。真实日志里躺着你最需要的题目分布。起步做法务实到近乎无聊： 1. **抽 100 条真实会话**，覆盖 5 类意图、正负情绪、单轮与多轮； 2. **人工给每条写出"标准答案"**——包括正确的事实、该调的工具、应有的终止状态； 3. **把它变成断言**：可以被机器自动判过或不过，而不是让另一个人再读一遍。 听起来工作量不小，但它是一次性投入、长期复用。而且它会立刻带来一个副作用：**你第一次能说出"这次改动让通过率从 72% 变成了 81%"。** > ⚠️ **两个必须防的坑：** > > ① **测试集泄漏**——拿测试题去调 prompt，等于把答案写进模型，分数会虚高，上线即打回原形； > > ② **测试集僵化**——业务变了、政策变了，题库不更新，你测的是去年的世界。定个节奏，双周更新一次。 ### 第二步：分层测试，让便宜的测试拦住大部分问题 真实工程里不会只有一份测试集。问题越早发现越便宜——这句话决定了测试必须是金字塔结构： | 层级 | 对应什么 | 内容与门槛 | | --- | --- | --- | | **L4 线上监控** | 大考（真实流量） | 真实用户、真实流量，每天都在跑 | | **L3 预发布评估** | 模拟考 | 100 道真题；放行门槛：意图 **≥90%** / 检索 **≥85%** / 回复 **≥80%** | | **L2 集成测试** | 月考 | 20-30 个完整场景，多轮 + 工具 + 转人工 | | **L1 单元测试** | 随堂测 | 零件级，依赖全 mock，覆盖率 ≥80% | L3 那三个门槛数字（**90 / 85 / 80**）值得抄进你们的发布检查表——它们是"能不能放行"的硬开关，不是参考值。 ### 第三步：给 Agent 划一条"及格线" Agent 每次回答都带着一个把握分（置信度，0-1）。把握分够高就直接答，不够高就走澄清或转人工。**这条线划在哪，直接决定它是"敢答但爱错"还是"保守但爱推"。** 同一份数据、三种及格线的实测对比： | 置信度阈值 | 精确率 P | 召回率 R | F1 综合分 | 结论 | | --- | --- | --- | --- | --- | | **0.7（严格）** | 82% | 78% | 80.0 | 准，但 22% 该答的被拒，转人工率被推高 | | **0.6（平衡）** | 75% | 88% | **81.0 ★** | 两种代价最平衡 | | **0.5（宽松）** | 68% | 93% | 78.6 | 敢答，但错答率 32%，客户信任受损 | 阈值往上调：更准，但该答的也不敢答（召回率掉、转人工率涨）；往下调：敢答，但错答变多。**没有标准答案，只有"你更怕哪一种代价"。** 而且不同意图应该用不同阈值——**答错代价越大，及格线越高**： | 意图类型 | 建议阈值 | 理由 | | --- | --- | --- | | 查物流 | 0.55 | 答错代价低，客户多问一句而已 | | 产品咨询 | 0.60 | 一般性表述，容错空间中等 | | 退换货政策 | 0.70 | 规则性强，说错会引发纠纷 | | 退款 / 金额相关 | 0.85 | 说错直接产生资损与投诉 | ### 第四步：合成一个总分，防止"偏科"和"假性健康" 六个科目各打一个分，按权重加权求和，得到 0-100 的健康度。解决率权重最高（30%），其余 10-15%。 | 综合分 | 状态 | | --- | --- | | ≥ 85 | ✅ 健康 | | 60 - 85 | ⚠️ 亚健康 | | < 60 | ❌ 异常 | 综合分不是为了让老板看着开心，它是**防骗机制**：单个指标可以骗人，六个同时骗你的概率小得多。 ### 第五步：拿到结果，决定下一步改哪 评测真正的产出不是分数，是**归因**。看一个真实的三个月： | 时间 | 解决率 | 单会话成本 | ROI | | --- | --- | --- | --- | | 2 月 | 78.3% | ¥0.42 | 1.35 | | 3 月 | 76.1% ↓ | ¥0.58 ↑38% | 0.92 ↓32% | | 4 月 | 83.5% ↑ | ¥0.39 ↓ | 1.62 ↑76% | 2 月时 CSAT 还稳在 4.21，看起来一切正常。**但三项指标同向恶化**——解决率微降、成本涨 38%、ROI 跌 32%。如果只看 CSAT，你要等到 3 月才发现；看综合分，2 月就报警了。 而 4 月的回升也不是靠"再调调 prompt"，是**归因**的结果：补 50 条物流 FAQ + 回退长上下文 + 恢复 200 个转人工关键词。 #### 要不要放量？——A/B 测试，必须有对照组 某团队优化 prompt 后，解决率从 76% 涨到 81%，全员庆功。同一时间，跑着旧版本的对照组也涨到了 80%。**真实提升只有 1 个点，其余 4 个点是季节性咨询变简单了。** 没有对照组，他们大概率会把这次"运气"当成"方法"，推广到所有场景。 做对比测试的要点很朴素： 1. 随机分桶（同一用户始终进同一组）； 2. 一次只改一个变量； 3. 跑之前就定好主指标和胜出条件； 4. **给守护指标一票否决权**——主指标赢了但成本或投诉率恶化，直接判负。 另外三个动作都是作弊：每天偷看、试 20 个指标挑一个显著的发战报、跑三天就宣布胜利。 #### 要不要全量？——灰度，一步一级 大考过了也别一次性全放。按 **1% → 10% → 50% → 100%** 推进，每一级有观察期和门票：意图准确率 **≥90%**、检索命中 **≥85%**、回复质量 **≥80%**。任何一级不达标就地回滚，而回滚通道要提前演练过——目标是在 5 分钟内退回旧版本。 > **回滚不是失败，是保险生效。** 一个从没演练过回滚的团队，等于把"能不能退回去"这件事交给了运气。 #### 上线之后呢？——告警管急症，巡检管慢病 上线不是终点。生产环境要有告警（分钟级响应突发），也要有巡检（每天低峰自动跑核心测试集，抓那些"悄悄变坏"的慢变量：知识过期、模型漂移）。 告警贵精不贵多——**凡是响了但你做不了任何动作的告警，都是噪音，删掉或降级成周报**。告警太多，结果是全部静音。 --- ## 05 五条总结 ### 1. 评测标准要先于开发建立 标准不是开发完之后补上的"验收环节"，它是需求的一部分。先想清楚"怎么算做对了"，再动手写第一行 prompt。 > 人话：没有验收标准的开发，等于没有施工图的装修。 ### 2. 警惕指标崇拜 任何单一指标被当作目标，都会被优化到失真。解决率可以靠"磨"上去，转人工率可以靠"不敢转"压下去，CSAT 可以靠"挑人发问卷"刷上去。 > 人话：指标之间要互相牵制，六个一起看。 ### 3. 重视过程胜于结果，警惕"蒙对答案" 答对了不代表做对了。它可能检索到了错误的文档、用错误的路径凑出了正确的结论——换个输入立刻就错，而你浑然不知。所以要看轨迹：检索命中了吗？工具调用合法吗？状态转移正确吗？ > 人话：蒙对的答案，会在下一次变成错的答案。 ### 4. 评测是持续的，要 CI/CD 化 知识会过期、模型会漂移、业务会变。一次性的评测报告，本质是一张过期的体检单。把评测接进流水线，让它像单元测试一样每次改动自动跑。 > 人话：不是考一次期末考，是每天都随堂测。 ### 5. 让评测服务于决策 一个分数如果不能指向一个动作，它就只是装饰。评测的输出应该是三种决策：**改哪里**、**能不能放量**、**要不要回滚**。 > 人话：分数是用来做决定的，不是用来汇报的。 --- ## 06 写在最后 回到开头那个问题：当 Agent 在演示里完成了一次任务，你凭什么相信它下次还能完成？ 答案不是"再试几次看看"，也不是"我觉得它挺稳定的"。答案是：**因为你知道"完成"的定义是什么，知道要用哪些证据去检查它，并且这些检查每次都自动跑一遍，结果可比较、可追溯、可复盘。** 这件事没有想象中那么重。你不需要一上来就建一套完美的评测平台。把它拆到最小可行动作，其实只有三件事： | 最小动作 | 具体做什么 | | --- | --- | | **① 一百道真题** | 从真实日志抽 100 条，人工写出标准答案，变成能自动判过不过的断言 | | **② 六个指标上墙** | 把解决率、FCR、转人工率、CSAT、成本、逃逸率的当前值算出来，贴在团队每天都能看到的地方 | | **③ 一个 badcase 会** | 每周 30 分钟，只看失败案例做归因，不听成绩汇报 | 这三件事跑起来，你已经超过大多数团队了——他们还在用"感觉还行"，管理着一个每天要和几千个真实用户说话的系统。 > **把「我觉得它行」换成「我能证明它行」。** > > 这是 Agent 从 Demo 走向生产，唯一必须跨过的那道坎。 最后修改：2026 年 10 月 01 日 © 允许规范转载 赞 如果觉得我的文章对你有用，请随意赞赏