第 5 章：Agent 应用的分层评测对象模型
第 5 章：Agent 应用的分层评测对象模型
5.1 一个错误回答背后的多层系统
客服 Agent 回答错了退款政策，团队通常会很快陷入争论。
算法同学说：“模型可能幻觉了。”
工程同学说：“是不是知识库没有更新？”
产品同学说：“业务规则本身就有例外情况。”
平台同学说：“评测脚本只看最终回答，没有保存检索和工具调用过程。”
安全同学说：“问题不只是答错，它还可能绕过身份校验。”
这些说法都可能正确，也都可能只看到了一部分。企业级 AI 应用不是一个单模型系统，而是由模型、知识、工具、记忆、流程、编排、权限和业务规则共同组成的运行系统。只用“模型好不好”来描述它，粒度太粗；只用“最终答案对不对”来评估它，信息太少。
分层评测对象模型的价值，就是把一个看似模糊的失败，拆成可以观测、可以度量、可以归因、可以修复的多个层级。
5.2 为什么不能把 LLM、RAG、Tool Call 和 Agent 并列
很多评测方案会把评测对象列成四类：LLM 评测、RAG 评测、Tool Call 评测、Agent 评测。这个分类在工作沟通中方便，但如果直接作为体系设计，会带来一个问题：它把不同层级的对象放在同一平面上。
LLM 是能力底座。RAG、Tool Call、Memory、Skill、Workflow 是建立在模型能力之上的组件能力。Agent 编排则把这些组件组织成多步执行过程。最终交付给用户的，是带有业务规则、权限边界和体验要求的应用系统。
换句话说，它们不是并列关系，而是层级关系。
图 5-1 Agent 分层评测对象模型图
flowchart TB
L4["应用业务层<br/>业务目标 / SOP / 权限 / 终态 / 用户体验"]
L3["编排执行层<br/>Planner / Executor / 状态管理 / 异常恢复 / 多轮决策"]
L2["组件能力层<br/>RAG / Tool Call / Memory / Skill / Workflow"]
L1["基础模型层<br/>LLM 理解 / 推理 / 生成 / 指令遵循 / 安全边界"]
L1 --> L2
L2 --> L3
L3 --> L4
分层之后，一个核心原则就清楚了：组件正确不代表应用正确，最终答案正确也不代表过程安全。
一个客服 Agent 最终给出了正确退款结论，但过程中查询了不该访问的用户信息，这不是成功。一个代码 Agent 最终修复了 Bug，但修改了无关文件、删除了测试、绕过了安全检查，这也不是成功。Agent 评测必须同时看组件、过程、结果和副作用。
5.3 四层评测对象模型
5.3.1 基础模型层
基础模型层关注 LLM 自身的通用能力和边界。它不关心具体业务工具是否可用，也不关心某个企业知识库是否更新，而是回答模型在给定输入和上下文下是否具备基本能力。
典型被评对象包括：
- 语言理解。
- 指令遵循。
- 事实一致性。
- 推理能力。
- 格式遵循。
- 长上下文利用。
- 安全拒答。
- 稳定性和采样波动。
客服 Agent 中的基础模型层问题，可能表现为：模型看到了正确政策片段，但仍然编造额外条件；模型被要求输出结构化 JSON，却混入自然语言解释；模型在多轮对话中忘记用户已经提供过订单号。
基础模型层的评测结论通常用于模型选型、模型升级、Prompt 基线验证和能力边界判断。
5.3.2 组件能力层
组件能力层关注可被单独拆测的能力模块。它们通常由模型能力、Prompt、数据、工具和工程逻辑共同组成。
典型组件包括：
- RAG：检索、重排、上下文组装、引用。
- Tool Call：工具选择、参数生成、Schema 遵循、返回结果使用。
- Memory：短期状态、长期偏好、用户画像、任务进度。
- Skill：封装后的可复用任务能力。
- Workflow：固定流程、半固定流程、动态流程。
客服 Agent 中的组件问题，可能表现为：正确政策没有被召回；退款资格校验工具选对了但参数错了；用户已经通过身份验证，但状态没有被保存；Agent 在投诉流程中漏掉人工升级节点。
组件能力层的评测价值在于定位。端到端任务失败后，只有组件级指标能告诉团队具体坏在哪一环。
5.3.3 编排执行层
编排执行层关注 Agent 如何组织多步任务。它的核心对象不是单次输出，而是完整执行轨迹。
典型被评对象包括：
- 任务规划。
- 步骤顺序。
- 工具调用链。
- 状态更新。
- 记忆读写。
- 异常恢复。
- 循环检测。
- 多 Agent 协作。
- 过程成本和延迟。
客服 Agent 中的编排执行问题，可能表现为：用户问“我的退款为什么没到账”，Agent 没有先查询订单状态，而是直接解释通用政策；工具调用失败后没有重试或转人工；在同一个问题上反复询问用户已经提供的信息。
编排执行层必须引入 Trace。没有 Trace，就只能看到最终回答，无法判断过程是否合理、安全、可复现。
5.3.4 应用业务层
应用业务层关注系统是否在真实业务约束下完成任务。它关心的不只是回答对不对，而是业务目标、用户体验、权限边界和最终状态是否满足要求。
典型被评对象包括：
- 业务 SOP 遵循。
- 权限和身份校验。
- 任务完成率。
- 业务终态正确性。
- 用户体验。
- 转人工策略。
- 成本和延迟。
- 合规审计。
客服 Agent 中的应用业务层问题，可能表现为：答案本身没有明显错误，但没有解决用户问题；该转人工的投诉没有转；本应拒绝的他人订单查询被继续处理；退款申请被提交到错误流程。
应用业务层的评测结论最接近发布决策。它回答的是：这个 Agent 是否能在真实业务中承担责任。
5.3.5 层级不是组织架构，而是归因坐标
分层模型不是为了把团队重新划成四个部门。真实企业里，一个问题往往跨越多个团队和系统。分层的作用，是在评测和归因时提供稳定坐标。
同一个 Bad Case 可以同时带有多个层级标签。例如，客服 Agent 错误承诺“会员积分不会扣回”，可能涉及：
| 层级 | 证据 | 归因含义 |
|---|---|---|
| 基础模型层 | 正确证据已进入上下文，模型仍补充不存在的承诺 | 生成忠实性不足 |
| 组件能力层 | 积分扣回政策没有被召回 | RAG 召回或知识库问题 |
| 编排执行层 | Agent 没有先调用退款资格校验工具 | 工具使用顺序问题 |
| 应用业务层 | 高风险权益问题没有触发人工审批 | 业务 SOP 和门禁问题 |
归因时要避免两个极端：一是只找一个“唯一原因”，忽略多因素共同导致的失败；二是把所有层级都标成问题，导致没有修复优先级。更实用的做法是区分主根因、贡献因素和暴露条件。
| 标签 | 含义 | 例子 |
|---|---|---|
| 主根因 | 不修复就无法解决该类问题 | 正确政策未进入索引 |
| 贡献因素 | 加重问题或降低恢复概率 | Prompt 没要求引用生效时间 |
| 暴露条件 | 让问题在特定场景出现 | 用户询问部分退款叠加会员权益 |
这种标注方式会在后续 Bad Case 归因章节继续展开。这里先要建立一个意识：分层不是分类游戏，而是为了让修复动作落到正确对象。
5.4 分层后的 Case 结构差异
不同层级的 Case 结构不同。如果所有评测都只用“input + expected answer”，评测体系会天然偏向最终答案，无法支持组件诊断和过程归因。
| 层级 | Case 需要包含什么 | 评测关注点 |
|---|---|---|
| 基础模型层 | input、context、reference、Rubric、generation config | 输出质量、指令遵循、格式、稳定性 |
| 组件能力层 | query、component state、expected intermediate result、tool Schema、evidence | 组件是否产生正确中间结果 |
| 编排执行层 | goal、environment、tools、initial state、Trace、success criteria | 过程是否合理，状态是否正确，工具链是否安全 |
| 应用业务层 | business scenario、user journey、SOP、risk constraints、final state | 业务任务是否完成，风险是否可接受 |
以“用户要求查询退款进度”为例：
- 基础模型层 Case 只需要验证模型能否理解用户问题并给出符合格式的回答。
- RAG 组件 Case 需要验证系统是否召回正确的退款进度说明和订单状态解释文档。
- Tool Call Case 需要验证 Agent 是否调用订单查询工具，并传入正确订单号和用户身份。
- 编排执行 Case 需要验证 Agent 是否先校验身份，再查订单，再解释状态，工具失败时是否转人工。
- 应用业务 Case 需要验证用户是否得到可执行结论，是否没有泄露隐私，是否满足客服 SOP。
同一个业务问题，在不同层级会变成不同 Case。评测体系必须允许这些 Case 共存，而不是互相替代。
5.5 分层后的指标差异
指标也必须分层。一个总分无法解释复杂系统。
| 层级 | 指标示例 | 指标用途 |
|---|---|---|
| 基础模型层 | 指令遵循率、事实一致性、格式通过率、拒答正确率 | 判断模型能力边界和 Prompt 基线 |
| 组件能力层 | 召回率、引用准确率、工具选择准确率、参数准确率、记忆读写正确率 | 定位组件瓶颈 |
| 编排执行层 | 任务步骤合理率、无效动作率、循环率、异常恢复率、轨迹成本 | 判断 Agent 过程质量 |
| 应用业务层 | 任务完成率、SOP 遵循率、越权率、投诉率、转人工率、单会话成本 | 支撑发布和业务决策 |
指标分层后，团队可以避免两种常见误判。
第一种误判是组件指标好，就认为业务体验一定好。RAG 召回率很高，但 Agent 可能不会正确使用证据；工具调用准确率很高，但编排流程可能漏掉身份校验。
第二种误判是业务指标差，就认为模型一定差。转人工率上升可能是模型幻觉，也可能是知识库缺失、工具失败、流程设计不合理，甚至是业务规则太复杂。
5.6 分层后的 Evaluator 差异
Evaluator 也不能“一把尺子量到底”。不同层级适合不同评估器。
| 层级 | 适合的 Evaluator | 示例 |
|---|---|---|
| 基础模型层 | LLM-as-Judge、规则校验、人工复核 | 判断回答是否忠实、是否符合格式 |
| 组件能力层 | 检索指标、脚本校验、工具返回校验、状态检查器 | 验证正确证据是否召回、工具参数是否正确 |
| 编排执行层 | Trace 解析器、步骤级 Rubric、沙箱终态校验 | 检查步骤顺序、循环、异常恢复 |
| 应用业务层 | 业务规则引擎、人工专家复核、线上指标 | 判断 SOP、权限、终态和用户体验 |
例如，客服 Agent 的“退款金额是否正确”不应交给 Judge 主观判断，而应由脚本根据订单金额、优惠券、支付方式和退款规则计算后校验。相反，“回答是否清楚解释了为什么当前订单不可退”更适合使用 Rubric + Judge + 人工抽检。
Evaluator 的选择本质上是在决定：这个维度有没有客观标准，能否执行验证，是否需要主观判断，风险是否需要人工兜底。
5.7 组件评测与端到端评测的关系
组件评测和端到端评测经常被误解为二选一。
只做组件评测，团队会得到很多局部正确的结论，却不知道系统整体是否真的能完成任务。检索模块通过，工具模块通过，Prompt 单测通过，不代表 Agent 在真实对话中能稳定处理退款申请。
只做端到端评测，团队能看到最终成败，却很难解释为什么失败。一个任务没有完成，可能是模型理解错了，可能是工具参数错了，也可能是业务流程本身缺少分支。
成熟的评测体系应该这样组合：
- 端到端评测用于发布决策：系统在真实任务上能不能达标。
- 组件评测用于诊断归因：失败发生在哪一层、哪一环。
- 组件回归用于防止局部能力退化。
- 端到端回归用于防止组合后出现涌现问题。
客服 Agent 的退款场景可以采用如下策略：
| 评测层次 | 评测目标 | 决策用途 |
|---|---|---|
| RAG 组件评测 | 正确政策是否召回 | 定位知识链路问题 |
| Tool Call 组件评测 | 是否正确调用订单和退款工具 | 定位工具使用问题 |
| Trace 过程评测 | 是否按身份校验、查询、解释、操作顺序执行 | 定位编排问题 |
| 端到端业务评测 | 用户是否得到正确、安全、可执行的处理结果 | 支撑上线决策 |
5.7.1 分层归因的最小诊断路径
当端到端 Case 失败时，可以按“证据是否存在、证据是否到达、系统是否使用、业务是否允许”的顺序诊断。
| 诊断问题 | 若答案是否定的 | 优先检查层级 |
|---|---|---|
| 正确业务规则是否存在并有效 | 规则缺失或过期 | 应用业务层 / 知识治理 |
| 正确证据是否被解析和索引 | 文档没有进入可检索状态 | 组件能力层 |
| 正确证据是否被召回并进入上下文 | 检索或上下文组装失败 | 组件能力层 |
| Agent 是否调用了必要工具 | 工具选择或流程约束失败 | 编排执行层 |
| 工具参数和返回是否正确 | 参数、权限或工具语义失败 | 组件能力层 / 编排执行层 |
| 模型是否忠实使用证据和工具结果 | 生成或指令遵循失败 | 基础模型层 |
| 最终动作是否符合 SOP 和风险边界 | 业务流程或权限失败 | 应用业务层 |
这条路径有一个好处：它把争论从“是不是模型问题”转成“证据链断在哪一段”。只有证据链被复原，修复才不会停留在凭经验改 Prompt。
5.8 客服 Agent 的完整分层示例
下面用一个具体场景走一遍分层。
用户说：“我上周买的耳机已经拆封了，现在有点问题，能不能直接退？帮我处理一下。”
这句话看起来简单，实际涉及多个层级：
| 层级 | 系统需要做什么 | 可能失败点 |
|---|---|---|
| 基础模型层 | 理解用户在咨询并可能发起退款 | 把“有点问题”误解为普通咨询 |
| RAG 组件 | 检索耳机品类、拆封、质量问题、退货政策 | 召回普通 7 天无理由政策，漏掉质量问题条款 |
| Tool Call 组件 | 查询订单、校验签收时间、商品状态和售后资格 | 工具选错或订单号参数错误 |
| Memory / State | 记住用户已说明“拆封”和“有问题” | 多轮后丢失关键信息 |
| 编排执行层 | 先确认订单和问题类型，再判断政策，再决定是否提交售后 | 跳过问题确认，直接承诺退款 |
| 应用业务层 | 遵守售后 SOP，不越权承诺，不泄露隐私，必要时转人工 | 对需要人工质检的商品直接发起退款 |
如果最终回答错了，分层模型能帮助团队设计诊断路径：
- 正确政策是否被召回？
- 工具是否查到了正确订单？
- Agent 是否正确保存了“拆封”和“质量问题”状态？
- 执行顺序是否符合 SOP？
- 最终回答是否忠实于证据和业务规则？
- 是否存在越权承诺或隐私风险？
这条诊断路径比“模型答错了”更可操作。
5.9 交付物一：Agent 应用分层评测对象模型
可以用下面的表作为团队统一对象模型。
| 层级 | 被评对象 | 核心问题 | 典型指标 | 主要交付物 |
|---|---|---|---|---|
| 基础模型层 | LLM 能力 | 模型在给定输入下是否具备基本理解、生成和安全能力 | 指令遵循率、事实一致性、格式通过率 | 模型能力评测集、Prompt 基线 |
| 组件能力层 | RAG、Tool、Memory、Skill、Workflow | 单个组件是否产生正确中间结果 | 召回率、工具参数准确率、记忆读写正确率 | 组件 Eval Set、组件 Evaluator |
| 编排执行层 | Planner、Executor、状态管理、异常恢复 | 多步任务过程是否合理、安全、可恢复 | 任务步骤合理率、循环率、异常恢复率 | Trace Schema、轨迹评分 Rubric |
| 应用业务层 | 业务 Agent、SOP、权限、终态 | 系统是否完成真实业务任务且风险可控 | 任务完成率、越权率、投诉率、成本 | 业务 Eval Set、发布门禁、线上看板 |
这张表应成为评测团队、算法团队、平台团队和产品团队的共同语言。讨论 Bad Case 时，先定位层级，再讨论修复方案。
5.10 交付物二：不同层级 Eval Case 字段对照表
| 字段 | 基础模型 Case | 组件 Case | 编排执行 Case | 应用业务 Case |
|---|---|---|---|---|
| case_id | 必需 | 必需 | 必需 | 必需 |
| scenario | 可选 | 必需 | 必需 | 必需 |
| input / goal | 必需 | 必需 | 必需 | 必需 |
| context | 必需 | 必需 | 必需 | 必需 |
| reference / expected | 必需 | 必需 | 可选 | 可选 |
| tools | 不适用 | 视组件而定 | 必需 | 必需 |
| environment | 不适用 | 可选 | 必需 | 必需 |
| initial_state | 可选 | 可选 | 必需 | 必需 |
| Trace | 不适用 | 可选 | 必需 | 必需 |
| final_state | 可选 | 可选 | 必需 | 必需 |
| Rubric | 必需 | 必需 | 必需 | 必需 |
| risk_level | 可选 | 建议 | 必需 | 必需 |
| evaluator_config | 必需 | 必需 | 必需 | 必需 |
这张表不是最终 Schema，而是设计 Case 时的检查清单。真正的 Schema 会在第 12 章展开。
5.11 本章小结
企业级 AI 应用不能用单层视角评测。LLM、RAG、Tool Call、Memory、Workflow、Agent 编排和业务应用不是并列模块，而是从基础能力到业务交付的层级结构。
分层模型带来三个直接收益：
- 评测对象更清楚：知道每层该评什么。
- 归因更准确：知道问题发生在哪一层。
- 修复更可执行：知道该改模型、数据、Prompt、RAG、工具、编排还是业务规则。
后续章节会沿着这套分层模型展开，先讨论组件层失效模式，再从业务目标出发把这些对象转化为指标树。
下一章，我们先从最底层的 LLM 本身开始，理解模型的能力边界和典型失效模式。