简介：AI 智能体迭代频繁，仅靠一个综合评分做发布决策，容易被“平均分”掩盖模块级退化。本文对比两类典型评测体系：以加权总分为核心的聚合评测，与按意图识别、路由、技能调用等环节拆解的分层评测，从指标粒度、回归发现、故障定位、埋点成本与适用场景等维度展开分析，并结合一次“总分更高却暗藏意图识别退化”的发布复盘，给出选型建议与迁移落地注意事项。
先从一个真实的发布复盘说起。某智能体应用在两个候选版本之间做上线决策：按既有评测口径，A 版本综合评分更高，B 版本略低，按“分数优先”的原则理应上线 A。但灰度期间的用户反馈却与评分相反：A 版本上线后，“答非所问”的case明显增多。
团队翻查线上日志后才发现根因：A 版本在意图识别环节发生了退化，大量本应路由到技能（Skill）链路处理的问题，被错误地路由到了知识库问答链路。知识库并不承载这类问题的答案，只能返回近似内容或兜底回复；而在端到端打分时，这类失败被其他模块的稳定表现稀释了。B 版本虽然总分略低，但每个模块都稳定在基线附近，链路行为可预期，实际体验反而更好。
这个案例暴露的不是“评分算错了”，而是评测体系架构的问题：当评测只输出一个聚合总分时，局部退化会被平均掉。本文围绕两类典型评测体系展开对比——以加权总分为核心的总分制聚合评测（方案A），与按链路模块拆解指标的分模块分层评测（方案B）——分析两者在架构、能力、成本与适用场景上的差异，帮助团队判断该建哪一种、先建哪一种。
方案A：总分制聚合评测。 将意图理解、答案质量、响应速度等多个维度得分加权合成为一个综合分，以总分对比版本优劣、决定是否发布。它回答的问题是“整体有没有变好”，典型形态是：准备一批测试问题，跑端到端问答，人工抽检或自动打分，加权平均出总分。
方案B：分模块分层评测。 按智能体的链路结构（意图识别 → 路由分发 → 技能编排与调用 → 知识检索 → 答案生成）逐环节设定独立指标，再叠加端到端任务完成率作为汇总视图，形成一棵“指标树”。它回答的问题是“哪个环节变坏了、坏到什么程度、是否阻断发布”。
两类体系并非对立，它们共享同一套基础设施：
差异不在于“评什么”，而在于指标怎么组织、退化怎么暴露。
1. 指标粒度与体系结构。 总分制把多个维度压成一个标量，信息在聚合时丢失；分模块制保留每个环节的独立指标，总分只是最上层的汇总视图，不下沉替代模块指标。
2. 回归发现能力：平均分陷阱。 示意说明：假设总分由五个维度加权构成，意图识别权重占两成，当意图识别准确率明显下滑时，反映在总分上可能只是零点几分到一分的波动；若其他维度小幅提升，总分甚至不降反升。这正是开篇案例中“总分更高、体验更差”的数学来源。分模块制下，同一退化会直接体现在意图识别指标上，无需等到用户投诉。
3. 故障定位与修复效率。 总分制发现问题后，需要回翻线上日志、逐条人工归因，排障周期以天计；分模块制的指标本身即指向劣化环节，配合全链路 trace 可直接圈定问题版本与问题链路，排障周期可缩短到小时级。
4. 对路由类错误的敏感度。 智能体中“路由错误”具有隐蔽性：本该走技能链路的问题进了知识库，若知识库碰巧覆盖了部分近似内容，端到端答案打分可能给出中等分而非零分，错误被“软性掩盖”。只有路由准确率这一独立指标能稳定捕捉这类问题。
5. 埋点与日志要求。 总分制只需留存端到端的输入输出；分模块制要求各环节的结构化埋点、trace id 全链路贯通、中间结果（识别出的意图、实际路由目标、技能调用参数与返回）可留存可回放，对工程规范要求更高。
6. 标注与维护成本。 分模块制需要环节级标签（每条样本的期望意图、期望路由、期望技能），基准集治理成本高于一套端到端标注；但换来的是回归可解释。
7. 决策语义。 总分制适合对外汇报与趋势观察；分模块制适合工程决策——门禁可以按模块设阈值，“任一核心模块跌破阈值即阻断”，而不是“总分下降即阻断”。
| 对比维度 | 总分制聚合评测（方案A） | 分模块分层评测（方案B） |
|---|---|---|
| 指标结构 | 多维度加权合成单一总分 | 按链路环节的指标树 + 端到端汇总 |
| 回归发现 | 可能被平均稀释，波动难归因 | 模块级波动直接暴露 |
| 故障定位 | 需回翻日志，人工归因 | 指标直接指向劣化环节 |
| 埋点要求 | 端到端输入输出即可 | 全链路结构化埋点、trace 贯通 |
| 标注成本 | 一套端到端标注 | 需环节级标签，成本更高 |
| 门禁语义 | “整体变好/变坏” | “哪个环节劣化、是否阻断” |
| 建设维护成本 | 低，起步快 | 高，需持续治理指标与基准集 |
| 适用阶段 | 原型期、单一能力应用 | 生产级、多技能多模块智能体 |
工程上，方案B通常分为四层：采集层（线上埋点 + 全链路日志）、数据层（分层基准集：意图集、路由集、技能集、拒答集）、计算层（指标引擎）、决策层（门禁规则与看板）。示意伪代码如下：
# 分模块评测流水线（示意）report = TraceReport()for case in golden_set:trace = agent.run(case.query) # 各环节输入输出留存于 tracereport.collect(intent_hit = trace.intent == case.golden_intent, # 意图识别命中routing_hit = trace.route == case.golden_route, # 路由正确skill_ok = trace.skill_call.success, # 技能调用成功answer_ok = judge(trace.answer, case.golden_answer) # 答案质量)metrics = report.summarize() # intent_acc / routing_acc / skill_sr / answer_pass# 门禁：任一核心模块跌破阈值即阻断，而非只看加权总分release = all(metrics[k] >= threshold[k] for k in core_modules)
若智能体应用托管在百度智能云等云平台，采集与观测层可复用平台通用的日志检索、监控告警类能力，降低自建采集管道的成本。
条件化结论：当智能体链路变长、模块变多、发布变频繁时，评测价值的主要来源会从“综合结论”转向“定位能力”，此时分模块制的收益远大于其建设成本；反之，总分制仍是低成本起步的合理选择。
从总分制演进到分模块制，需关注：埋点先行，无结构化 trace 则模块指标无从计算；基准集分层重建，历史端到端标注无法直接复用，需补环节级标签；线上线下对齐，离线评测集与线上真实分布存在漂移，需定期以线上采样回流校准；裁判一致性，LLM-as-Judge 需抽样人审标定，避免裁判本身成为退化源；门禁灰度联动，模块阈值触发应与灰度发布、快速回滚机制打通；保留总分视图，不必推翻已有汇报口径，总分作为汇总层继续存在。
总分制回答“好不好”，分模块制回答“坏在哪”。开篇案例的核心教训是：聚合指标会稀释局部退化，而智能体的体验往往恰恰毁于单个环节的退化。选型思路可归结为一句话——链路短用总分快速起步，链路长、发布频繁则以模块级指标为门禁、以总分为汇总视图，让评测体系从“打分器”进化为“定位与回归防线”。