咱们接着上次的 AgentLoop 数据飞轮往下聊。前两篇分别讲了飞轮的整体设计和数据采集环节这篇到核心环节了评估。准确说是从“只盯一个黄金指标”到“用 Rubric 体系评估 Agent 行为质量”的完整转变过程。这次实践里我踩了不少坑也把一套能直接用的评估链路跑通了整理出来给还在纠结“怎么评估 Agent 效果”的朋友做个参考。先说结论如果你现在做 Agent 应用还在只看任务成功率短期内能应付但一旦开始做 prompt 迭代、模型替换、bad case 分析单一指标会让你寸步难行。评估这件事必须从决策层的黄金指标下沉到迭代层的 Rubric 多维度评分体系并且要把评估结果接回数据飞轮里让每次评估都在给下一次迭代供弹药。1. 只盯一个黄金指标踩到了哪些坑1.1 黄金指标对决策有用对迭代没用黄金指标在 Agent 场景里通常是任务成功率、用户留存、单次会话解决率这类高度聚合的数字。它最大的价值是给团队一个“要不要上线”的决策依据比如我们当时定的核心黄金指标是售后工单 Agent 的任务成功率也就是用户提一个问题Agent 能不能在限定轮次内给出可用答复并关闭工单。问题是这个数字到后期基本不动了卡在 87% 附近怎么调都上不去。我们最初以为是模型能力到瓶颈了后来一细拆才发现这个数字根本没法告诉我们瓶颈在哪。任务失败时到底是意图识别错了、工具调用错了、还是回复内容用户不认可黄金指标一概不回答。更麻烦的是如果你把它作为迭代指标团队会陷入“刷分”状态——为了把成功率从 87% 刷到 88%可能只是把系统搞得更保守让 Agent 少干活、多转人工表面数据好看了用户体验实际在退步。所以我的结论是黄金指标适合在管理层看板、周报、上线决策里出现但不适合直接指导 prompt 怎么写、工具调用怎么改、few-shot 怎么加。后者需要一套更细的“过程标尺”。1.2 单指标在 Agent 场景下会失真Agent 任务和传统分类任务最大的不同是它是一个多轮、多工具、长上下文的动态过程。同一个“成功”结果背后的过程质量可能天差地别。我举两个真实案例。第一个案例是订机票场景。Agent 用 3 轮对话完成出票和另一个 Agent 花了 10 轮、多调了两次无用的航班查询接口、中间还让用户重复确认了三次任务结果都标记为“成功”。在这个场景里黄金指标完全无法区分这两个版本谁好谁坏。直到我们把所有“成功”样本拉出来看过程日志才发现有大量冗余调用和无效追问用户体验极差但指标无感。第二个案例更隐蔽。Agent 在中间步骤里生成了一条错误的中间信息——比如把用户证件类型说成护照但实际上用户是身份证——最后工具调用时系统自动纠正了任务最终成功。从结果看是成功的但中间产生了事实性错误。这种“过程错误但结果碰巧对了”的样本在单指标评估里会被当成优质样例如果拿去微调模型等于在教模型犯错。这些失真背后的本质是黄金指标只看“终点状态”而 Agent 的质量由“整条路径”决定。路径上的规划合理性、调用正确性、信息忠实度、沟通效率全部被平均到了同一个二值结果里。数据飞轮如果建立在这种评估基础上飞轮转得越快错误模式固化得越深。1.3 分层抽样的假象指标好看掩盖模型崩溃还有一个更隐蔽的问题是输入分布偏移导致指标短期失真。某个版本上线后任务成功率看着涨了后来一查是用户请求结构发生了变化——简单问题比例变多了而不是模型真的变强了。如果我们只盯这一个数很容易做出“新版本更好”的错误判断然后盲目推广结果复杂场景的性能已经崩了。这种情况在数据飞轮里特别危险。因为飞轮的采集环节会随线上流量持续回流数据如果评估环节只看聚合成功率那么新样本里简单问题居多时指标就会虚高团队拿着虚高指标去调整 prompt方向大概率是偏的。评估环节必须有能力拆开看按场景维度、工具维度分别评估而不是被一个平均数蒙住眼。这些坑踩完之后我开始动手设计一套多维度评估规则也就是 Rubric。2. 从黄金指标到 Rubric评估维度怎么拆、怎么打分2.1 Rubric 不是打分表是校准工具很多人一听 Rubric 就以为是一张打分表比如“内容质量 1-5 分沟通能力 1-5 分”然后让标注员凭感觉打分。这么做和直接用黄金指标没有本质区别甚至更糟——维度拆得再细如果每个维度的分数没有明确的“行为锚点”标注员仍然是在凭直觉打分一致性会非常差。真正的 Rubric 必须建立行为锚定量表英文叫 Behaviorally Anchored Rating Scale简称 BARS。核心思想是每个维度的每个分数档都必须对应一个可观察、可判断的具体行为描述而不是“较好”“较差”“中等偏上”这种模糊形容词。标注员看到的是一个行为清单然后在会话记录里去匹配行为是否发生。举个例子。“信息忠实度”这个维度如果定义是“模型是否忠实于已知信息”标注员还是会困惑——什么算忠实但如果你定义成5 分所有回复中的事实信息均能在对话上下文或工具返回结果中找到依据没有出现任何编造3 分存在一处事实性瑕疵但被后续对话修正或未影响任务完成1 分存在明显编造的实体、数据或结论。标注员就能非常明确地把一条会话归类到对应档位。2.2 一个可复用的 Rubric 模板我给 AgentLoop 设计的通用 Rubric 包含四个维度需求满足度、路径效率、信息忠实度、沟通质量。每个维度独立评分1-5 分最终得到一条会话的四维向量。需求满足度衡量最终结果是否覆盖了用户的全部显式和合理隐式需求。路径效率衡量完成任务是否走了最短且合理的路径工具调用是否必要有没有绕弯。信息忠实度是我最看重的一个维度衡量 Agent 输出的信息是否有依据、有没有编造。沟通质量衡量话术是否清晰、是否让用户感到被尊重有没有不必要的重复确认。下面是我在售后工单场景实际使用的评分锚点表维度1 分3 分5 分需求满足度未解决用户核心诉求答复与问题无关解决了主要诉求但遗漏次要细节或未主动追问关键信息完整覆盖显性需求并识别隐性需求一次性解决路径效率多次无效工具调用明显绕路轮次严重超出必要范围存在一次冗余调用或一次不必要追问整体路径可接受工具调用最少化规划合理每一轮都有推进作用信息忠实度出现明显编造的实体、数据或结论且未被纠正存在一处事实瑕疵但未影响任务结果或被后续纠正所有事实信息均有上下文或工具返回依据沟通质量话术生硬、有歧义或重复要求用户澄清沟通基本顺畅偶有一处不恰当的表述话术清晰简洁主动告知进展用户体验良好注意第三列和第一列我故意没有写 2 分和 4 分因为实践中我发现要求标注员精确区分 2 分和 3 分之间的细微差别会极大损害一致性。更好的做法是先在锚点上做粗粒度判断如果标注员觉得“介于 3 和 5 之间”再要求他根据存在的缺陷轻微加减最终落到 4。这样虽然 4 分的主观成分多一些但 1、3、5 三档的一致性是有保障的。2.3 维度权重和总分合成别掉进加权平均的陷阱分维度评完之后下一个问题是四个分数怎么合并成最终质量结论我见过很多团队直接加权平均比如需求满足度 40%、路径效率 20%、信息忠实度 30%、沟通质量 10%然后算一个总分。这个做法有一个致命缺陷它允许“短板拉长板”。举例来说一个 Agent 在信息忠实度上得了 1 分编造了关键信息但其他维度得分都很高加权平均后总分还有 3.8 分。如果拿这个分数去判断“这个版本能不能上线”结论可能是可以但这显然是不对的。信息忠实度出现编造属于一票否决级别的问题。所以我在设计总分成品时用了两类规则。第一类是组合规则总分采用加权求和作为参考分数但同时启用“最低维度门限”——如果某个关键维度低于 3 分整体质量评级直接锁定为不合格不参与版本对比。第二类是分层加权不同业务场景下各维度的权重不同。比如工具调用类场景路径效率权重提高纯知识问答场景信息忠实度权重进一步提高。权重怎么定我建议不要拍脑袋。初期可以用成对比较法把所有维度两两配对让业务方和技术方分别回答“这一对里哪个对用户体验影响更大”然后统计出排序。也可以用二元回归来校准小批量人工标注几百条会话然后拟合维度得分和用户满意度之间的权重关系。关键是不追求数学最优先定出一个非对称的权重结构——明确哪个维度是卡脖子的哪个维度只是参考。3. AgentLoop 数据飞轮的评估链路设计与落地3.1 评估在飞轮里的位置承上启下的核心枢纽数据飞轮的完整闭环是“采集-评估-优化-上线”评估处在承上启下的位置。往上它承接采集环节回流的线上日志和标注数据往下它要给优化环节输出三个关键产物版本质量结论、bad case 列表、可回归的评估数据集。我在设计 AgentLoop 评估链路时给自己定了三条硬性原则。第一一套评估结果必须同时服务三个目标既能支撑“新版能不能上线”的决策也能筛选出模型在哪类场景犯错的 bad case还能沉淀成回归评测集供后续 prompt 优化做对照。第二评估成本和线上流量增长要解耦不能流量翻倍评估成本就翻倍所以必须有自动评估兜底。第三评估链路本身要可追溯任何一次评分都能追溯到是哪条会话、哪个 Rubric 版本、哪个 judge 模型给出的。这三个原则决定了评估不可能纯靠人工标注必须引入 LLM-as-Judge 自动化评估配合人工抽检校准。3.2 LLM-as-Judge 的评估执行方案用大模型来评估大模型核心在于控制评判标准的一致性和可解释性。我在 AgentLoop 里已经积累了一套比较成熟的 judge 评估 prompt 模板结构上固定为四段式背景信息、评分标准、评估步骤、输出格式。背景信息里写明当前任务的业务背景和用户核心诉求帮助 judge 理解场景。评分标准直接嵌入上面设计的 Rubric 锚点表一个维度一个维度地给。评估步骤强制 judge 先逐个维度、逐个锚点去匹配会话日志中的具体行为再定性打分。输出格式要求必须是 JSON包含每个维度的分数和一句简短理由。这里的几个关键设计点我展开说。第一要强制 judge 输出证据片段。也就是在理由里必须引用对话原文或工具调用记录里的一句原话作为依据不能凭空给分。这一招极大减少了 judge 编造理由、乱给分的现象。第二四个维度分别独立判断不允许 judge 在一个维度上打完分之后再基于整体印象“顺便”给另一个维度打分防止维度间串扰。第三加一个置信度字段让 judge 自己判断这轮评分有多确定。置信度低的样本会被挑出来进入人工复核流程而不是直接信任自动评分。实际执行时的伪代码如下我简化了业务逻辑保留核心骨架import json from llm import call_llm JUDGE_SYSTEM_PROMPT 你是一个严格的 Agent 行为评估器。 请根据给定的评分标准评估用户与 Agent 的对话记录。 评分标准如下 需求满足度 5分完整覆盖显性需求... 3分解决了主要诉求... 1分未解决用户核心诉求... ... 评估步骤 1. 阅读对话记录提取关键事实与工具调用链。 2. 逐维度匹配行为锚点引用对话原文作为证据。 3. 基于证据给出 1-5 分整数评分。 输出 JSON 格式 {need_satisfaction: {score: 5, evidence: ... }, path_efficiency: {...}, information_faithfulness: {...}, communication_quality: {...}, confidence: 0.9} def judge_evaluate(conversation: str, tools_log: str) - dict: messages [ {role: system, content: JUDGE_SYSTEM_PROMPT}, {role: user, content: f对话记录\n{conversation}\n工具调用日志\n{tools_log}} ] response call_llm(messages, max_tokens800) result json.loads(response) return result这里有一个很重要的提醒judge 模型的能力必须明显强于被测 Agent否则 judge 看不出的问题、跟着一起犯的错误会让整个评估完全失真。我们实测下来用同级别模型做 judge评分和人类标注的一致性只有 0.4 左右换成高一档的模型一致性可以拉到 0.75 以上。成本确实会高一些但评估是整个飞轮的方向盘这个钱不能省。3.3 人工抽检和一致性校准流程LLM-as-Judge 不是天然可信的必须建立人工抽检校准机制。我的做法是每批次自动评估完成后按 10%-20% 的比例抽检置信度低于 0.8 的样本以及部分高分、低分的极端样本交给标注员人工按同一份 Rubric 打分然后计算 judge 和人工打分的加权 Cohens Kappa 系数。这里解释一下 Kappa 系数是什么。它衡量两个评分者之间的一致程度剔除了随机猜中的可能取值范围 0 到 1。我们内部定的线是Kappa 大于 0.75 认为 judge 可信0.6 到 0.75 之间需要检查出分歧较大的维度并微调锚点描述低于 0.6 则判定 judge 不可用立刻调整 prompt 或更换模型。实际校准过程中我发现最容易出问题的三个点。第一是置信度字段不可靠—— judge 自认为很确定的样本人工一看却有明显错误这类样本说明 judge 的标准理解有偏需要回到 prompt 里找原因。第二是对长对话的判断容易失真当对话超过 10 轮之后judge 会丢掉早期信息我加了一个先让 judge 用一句话总结用户核心诉求再评分的强制步骤效果明显。第三是锚点描述在真实场景里出现二义性比如“多次无效工具调用”里的“多次”到底几次有些 judge 理解成 2 次有些理解成 5 次后来我把这类量词全部替换成了具体行为描述。3.4 评估数据回流与 Rubric 版本化评估环节的产出不能只是“打过分的数据库记录”它要成为数据飞轮优化环节的弹药。我在 AgentLoop 里把回流分成两条路。第一条路是低分样本和低置信度样本自动进入标注池。每个回流样本都带上了完整的评估上下文会话日志、judge 评分、证据片段、置信度。标注员打开时已经能看到初步判断只需确认或纠正效率能提升不少。这些经过人工确认的标注数据一部分进入微调训练集一部分沉淀为回归评测集用来验证每个新版本是不是真的变强了。第二条路是 Rubric 本身的版本化。这里容易踩坑飞轮转了几轮之后你会觉得某个维度锚点不合理需要改或者要新增一个维度。可一旦评估标准变了前后两次的评估分数就不能直接比较了。我的办法是给每一条评估记录都加上 rubric_version 和 judge_model 两个字段prompt 优化做对比实验时强制只对比相同版本的数据。Rubric 我始终把它当作一个会持续演进的产物而不是一次定死后就当圣旨供着的东西。4. 常见问题与排查技巧实录4.1 常见问题速查表这一节我把实践中踩过的问题整理成表方便大家遇到类似情况时快速定位问题现象可能原因解决方法judge 打分离散度低大量聚集在 4 分锚点描述不够具体judge 标准过宽细化 3 分和 5 分的行为描述引入反例judge 理由和分数对不上理由明显合理但分数给错模型输出格式不稳定JSON 生成出现偏移输出前增加“自我复核”步骤强行要求对照锚点两个版本同集评估分数都涨了输入分布变了评估集没有固定做版本回归时必须锁定同一份评估集人工和 judge 一致性突然下降线上话术模板变了导致 judge 认知偏差将新话术样例加入 judge prompt 校准集维度分数之间高度相关需求满足度低时信息忠实度也低维度定义边界不清晰评估时被整体印象主导重写锚点强制每个维度只看对应行为证据同一个会话前后两天评估结果不一致judge 模型非确定性输出导致评分漂移设置 temperature0增加多数投票4.2 让评估链路稳定运行的几条经验最后分享几条我从这套体系里沉淀出来的实操经验。第一条评估 prompt 必须强制要求 judge 先引述对话原文证据再进行量化打分。这个设计的本质是把“评判”变成“匹配”让打分过程可复核、可追溯也更容易在出现分歧时定位是 judge 的问题还是锚点的问题。如果你让 judge 仅凭整体印象打分它给出的理由会是典型的“正确的废话”对问题排查毫无价值。第二条评估系统的版本治理要和业务代码一样严格。我也经历过 Rubric 改了一版之后和上一版数据对不上、所有历史趋势全部失去参考价值的尴尬局面。后来我要求所有评估结果必须同时提交 rubric 版本号和 judge 模型版本号任何版本的变更都要在记录旁标注原因。看上去只是多记录两个字段的事但在飞轮跑起来之后这个习惯省了我大量返工时间。第三条注意评估温度参数。大模型生成时自带随机性同一个会话同一条 prompt今天给 4 分明天可能给 5 分。如果我们要拿评估结果做版本对比这类随机噪声会让我们很难判断分数变化到底是模型改进了还是 judge 波动了。我现在所有自动评估全部把温度设为 0并且对关键样本做 3 次评分取多数结果虽然成本高了一些但换来的是结果稳定可解释这笔账是划算的。第四条也是我特别想提的一点别把自动评估结果当成 100% 准确的标准答案。整个评估链路里真正决定评价标准有效性的是人工校准环节自动化和成本优化的方向应该围绕“人工校准的效率和准确性”来投而不是单纯追求自动化覆盖率。我们飞轮跑起来之后评估成本下降了一半精力反而全部集中在了校准和锚点优化上效果比一开始想的要好得多。最后再分享一个我个人的习惯每次跑完一批评估我至少看三张表——黄金指标趋势表、Rubric 维度热力表、人工与 judge 一致性表。三个数据都正常才说明当前的评估体系是可信的这时候做的任何迭代结果才是可以信任的。如果中间任何一个表的异常我宁可暂停迭代先把评估体系修好再继续。评估体系一旦失真后续所有优化动作都是在给错误方向加固数据飞轮转得越快越容易把自己带进坑里。