拆解 Agent 评测如何用指标分层、GT 来源和 Judge 校准形成可回归的质量闭环。原文链接AI 小老六导语Agent 上线后最难回答的问题往往不是“模型有没有变强”而是“这个 Agent 在业务里到底有没有帮上忙”。传统软件可以用单测、集成测试、覆盖率来兜住质量Agent 却绕不开自然语言判断一句回答是否有用、一次路由是否准确、一段诊断是否真的缩短了排障时间都不是字符串相等能解决的事。评测系统要解决的是这个落差。它不能只给一个漂亮的总分也不能靠几条人工样本临时验收。更可靠的做法是把业务价值拆成几层能独立观测的信号再用线上行为、LLM 推断和人工 Golden Set 组成 Ground Truth 来源最后把LLM-as-Judge放进一个可校准、可回归、可持续运行的工程闭环。这篇文章不展开具体项目故事只讨论一套可复用的 Agent 评测架构指标怎么分层GT 怎么拿Judge 怎么防偏知识库和诊断类 Agent 又该怎样接入同一套评测引擎。Agent 评测的工程矛盾语义正确性、业务价值和持续运营图将自然语言输出、行为信号和业务结果拆成可观测评测层Agent 评测有三类麻烦任何一类处理不好分数都会变得不可用。第一类是准确性。Agent 的输出通常是自然语言或多步执行结果正确性强依赖领域知识。一个故障诊断回答可能方向对了但证据不够一个知识库回答可能引用了来源却漏掉了关键约束。二值的“对/错”很难承载这些中间态。第二类是有效性。Agent 做对了一件事不等于业务一定变好。回答准确率、路由准确率、诊断采纳率、MTTR 降低幅度属于不同层次的信号混在一起只会让问题失焦。第三类是在线运营。离线评测集会过期线上行为信号又稀疏且带噪声。评测系统必须能持续吸收新问题、识别 badcase、校准 Judge并在每次版本变更后快速跑出可比较的结果。图Agent 评测面对的准确性、有效性、稳定性和在线运营挑战这也是为什么通用 benchmark 不够用。HELM、AgentBench 这类基准可以告诉我们模型或 Agent 在标准任务上的能力但业务评测要回答的是另一件事在一个具体系统里Agent 是否产生了可验证、可归因、可持续追踪的价值。指标分层不要把业务结果和 AI 质量揉成一个数评测体系的第一步是分层。SRE 里常用 Four Golden Signals 区分系统健康、流量和业务 SLOAgent 评测也需要类似的拆解。底层信号要快、自动、可定位顶层信号要接近业务价值但可以周期更长。层级关心的问题典型指标用法AI 性能指标Agent 能不能稳定运行成功率、错误率、P99 耗时、TTD实时发现系统故障和链路退化AI 质量指标Agent 做得对不对路由准确率、知识准确率、Faithfulness、KeyPoints Coverage定位模型、召回、工具调用或 Prompt 问题AI 有效性指标Agent 是否被业务采纳覆盖率、采纳率、有效回复率判断 Agent 是否触达并解决真实问题业务结果引入 Agent 后业务是否变好MTTR、定位时长、人工处理成本、SLO 改善评估投入产出通常周期更长这种分层的价值在于归因。比如“有效诊断率”下降不一定说明模型变差。可能是覆盖率下降Agent 没有触达足够多的场景也可能是诊断质量下降工程师看到了但不采纳还可能是整体 Oncall 流量结构变了。一个总分无法区分这些原因。一个更可用的拆解方式是AI 有效诊断率 ≈ 诊断覆盖率 × 诊断采纳率诊断覆盖率 产生 AI 诊断卡片的 Oncall 数 / 总 Oncall 数诊断采纳率 被工程师采纳的 AI 诊断卡片数 / 产生 AI 诊断卡片的 Oncall 数如果覆盖率低应该先检查触发策略、白名单、召回入口和工具可用性如果采纳率低才进入诊断内容质量、证据完整性和 Judge 评分标准的排查。图性能、质量、有效性与业务结果之间的支撑关系Ground Truth 生成线上信号优先LLM 推断兜底人工集校准图从线上确认、上下文证据到人工 Golden Set 的 GT 生产链路Agent 评测的上限常常不是 Judge 模型决定的而是 Ground Truth 决定的。GT 不可信后面的评分再复杂也没有意义。可以把 GT 来源分成三类。GT 来源适用场景优点风险线上行为信号用户有明确操作反馈如点击采纳、确认处理、选择团队实时、低成本、贴近真实业务覆盖不全沉默用户无法解释LLM 推断有上下文但没有直接标注如从群聊推断实际处理团队、从对话判断诊断是否被采纳自动化、覆盖更广需要防幻觉必须有置信度和排除机制人工 Golden Set知识库问答、关键业务规则、无法从行为推断的内容最可靠可复用成本高会过期需要维护工程上不建议把三者看成互斥方案。更稳妥的策略是分级兜底图线上信号、LLM 推断和人工 Golden Set 的分级兜底机制这里最关键的原则是“无法判断时排除而不是猜”。把噪声样本硬塞进分母会让指标看起来覆盖更全实际上是在稀释判断力。对于路由类问题线上按钮点击往往是最可靠的信号没有点击时可以用群聊里的处理人、关闭前最后处置人、明确“已修复/已回滚”的发言来推断仍然无法解析时就不要计入准确率分母。对于知识库问答人工核准的标准答案和 Key Points 更适合作为 GT线上 query 可以用来扩充问题池但不能自动升级成准确率评测集。LLM-as-Judge先拆任务再评分图用事实抽取、分项评分和人工抽检降低 Judge 偏差LLM-as-Judge 很好用也很容易被用坏。常见偏差包括位置偏差、冗长偏差和自我增强偏差。更长的回答看起来更“完整”排在前面的答案更容易被偏袒同源模型也可能对自己的输出更宽容。可靠的 Judge 设计不是让模型“一步给分”而是把判断拆开。几个细节很重要。设计点解决的问题推荐做法任务拆解一步评分容易幻觉先抽取根因和证据再进入评分三级评分二值评分看不到中间改进使用 0 / 0.5 / 1 捕捉“方向对但证据薄”的状态Gating 熔断冗长回答可能拿虚高分结论准确性为 0 时直接 rejected不再加权业务类型打标不同问题的满分标准不同先识别 issue_tag再按类型套评分标准异源裁判既当选手又当裁判Judge 模型和被评 Agent 不同源且不读取被评系统内部状态人工抽检Judge 偏差会积累每轮抽 3%~5% 样本复核用于修 Prompt 和阈值知识库评测也适合类似结构。准确率不应该只看“回答像不像标准答案”而要拆成三个维度指标权重检测对象Answer Relevancy0.2是否回答了目标问题是否偏题或用通用话术搪塞KeyPoints Coverage0.5是否覆盖人工核准的必答要点是否漏掉关键边界条件Faithfulness0.3是否有出处支撑是否与来源材料冲突或无中生有其中 KeyPoints Coverage 通常最有价值。很多知识库回答看上去写了不少其实漏掉了“例外条件”“适用边界”“违反规则后的处理方式”。整体相似度很难抓住这类问题逐条 Key Point 判定更稳。覆盖率判定识别“看似回答实际拒识”知识库 Agent 的覆盖率不是“有没有吐出文字”。真正要判断的是知识库是否掌握了这个问题需要的知识并且回答是否建立在可追溯的证据上。有些系统不会直接说“不知道”而是输出领域通用知识、反问用户补充信息或者确认政策存在但不给具体内容。这些都属于未覆盖只是形式比显式拒识更隐蔽。图结构化信号与 LLM 偏转检测结合判断覆盖状态覆盖率和准确率必须分开看。覆盖率高、准确率低说明系统愿意回答但答得不稳准确率高、覆盖率低说明系统保守能答的范围太窄。把二者合成一个分数会把完全不同的工程问题盖住。评测数据集L1 问题池和 L2 Golden Set 分工一套评测集同时承担“看覆盖面”和“看准确性”会很吃力。更可维护的设计是两层数据集。层级作用关键字段准入标准L1 问题池覆盖率分母越全越好问题、来源文档、优先级、LLM 草稿答案、Key Points 初稿可由线上 query、文档切分、LLM 扩展生成L2 Golden Set准确率和回归基准越精越好L1 字段 人工核准标准答案 人工核准 Key Points必须人工核准P0 问题优先进入问题优先级也要进入数据结构。优先级含义处理方式P0必须答对答错会造成实质影响强制升级 L2进入回归红线P1应该答对答错会明显影响体验优先升级 L2P2补充知识或低频问题可长期停留 L1先扩大覆盖率分母L1 可以通过三类来源融合构建历史用户 query、权威文档切分后的知识点、LLM 从边界条件和跨章节关系中补充的问题。这里 LLM 适合做批量扩展不适合直接做最终裁判。它生成的答案和 Key Points 必须带“待验证”标记人工核准后才能升级成 L2。问题池大小也要和告警精度匹配。50 道题只能可靠捕捉较大的覆盖率变化100 道题可以看 3% 左右的波动如果希望把 2% 作为回归告警阈值问题池通常需要扩到 300 题量级。稳定性评测passk 看上限pass^k 看下限Agent 的非确定性决定了“跑一次通过”不够。多次运行可以回答两个完全不同的问题。指标定义衡量对象适用场景passkk 次中至少 1 次通过峰值能力Agent 有没有可能做到新能力探索看上限pass^kk 次全部通过稳定性Agent 是否每次都能做到生产上线门槛看下限如果 pass1 高但 pass^5 低说明系统处在“偶发成功”状态。它有能力答对但不可靠。对故障定位、安全审计这类关键决策 Agentpass^k 的失败容忍度应该接近 0对辅助分析类 Agent可以接受少量波动对创意生成或代码建议类场景多样性本身是特性稳定性阈值可以更宽。Agent 类型pass^k 失败容忍原因关键决策类0%任意一次失败都可能造成严重误判辅助分析类≤ 10%偶发偏差可通过人工复核兜底创意生成类≤ 40%输出多样性本身有价值评测集生命周期能力集找上限回归集守底线图能力探索、badcase 修复和回归红线构成持续运营闭环单一评测集很快会失效。更健康的做法是把评测集分成 Capability 和 Regression 两类。类型核心问题目标通过率更新方式触发机制Capability 能力测评集Agent 能把什么做好起步 20%~50%随迭代爬坡频繁调整加入新能力和边界场景新 Skill、新链路、新能力开发时启动Regression 回归测评集原有能力是否还在接近 100%只增不减作为守门员每次 PR、CI、模型或知识库版本更新触发两类集合之间要有流转机制图线上 badcase 从能力集沉淀到回归集的持续运营链路这样评测系统就不只是验收工具而是持续改进机制。线上发现的 badcase 会进入能力集修复稳定后沉淀为回归红线后续版本不能再把同一个坑踩回去。落地顺序先跑通基线再补全自动化大型评测体系不要一口吃完。比较现实的顺序是Phase 1跑通核心链路 - 打通目标 Agent 接口到评测引擎的数据通路 - 先做 P0 问题构建 30–50 条最小评测集 - 算出第一版基线明确当前质量水位 Phase 2补全能力和自动化 - 扩充 L1 问题池分层管理 P0/P1/P2 - 接入 LLM Evaluator、覆盖率判定和回归告警 - 建立趋势看板版本变更后能自动比较 Phase 3进入持续运营 - 按周期抽检 Judge 偏差 - 根据线上 badcase 扩充评测集 - 支持多 Agent、多知识库横向对比第一阶段最重要的是跑出可信基线而不是追求评测集完美。只要分层指标、GT 来源和回归触发机制先站住后续问题池、Judge Prompt、Adapter 和看板都可以迭代。结语Agent 评测不是给模型打一个分数也不是上线前做一次抽查。它更像一套质量基础设施底层看运行稳定性中层看回答和动作是否正确上层看业务是否真的被改善。这套基础设施的关键不在复杂而在克制。指标分层不把不同问题揉成一个总分GT 分级不把猜测伪装成事实Judge 拆解不让模型一步做完所有判断评测集分生命周期不让一次性验收变成长期幻觉。当这些机制连起来Agent 的每次改动就能留下可比较的质量轨迹。团队不再靠感觉判断“好像变聪明了”而是能看到它在哪一层进步在哪一层退化哪个 badcase 已经修掉哪个红线不能再破。推荐阅读团队落地 Agent 工程化 Loop 的一些必看小技巧Agent 工程化新底座用 CLI 契约层打通 HTTP 接口与业务能力AI Coding 不只靠 PromptAgent 工程闭环如何接入 DevOpsAgent Loop 架构拆解让 AI Agent 自己跑完验收闭环SkillOpt 架构拆解把 Skill 文本当参数用执行轨迹训练 Agent