Field note

生产级 Agent 评测体系

从提示词、上下文、记忆、RAG、工具、模型、安全到端到端协同，系统梳理生产级 Agent 的分层评测指标、方法与落地顺序。

结论先行

一次 Agent 输出，从来不是”模型一步生成”的结果，而是提示词、上下文、记忆、知识检索、工具调用、模型本身、输出安全一连串环节接力完成的。 任何一个环节出错，都可能导致最终结果错误——但如果评测只看最终结果，根本无法判断问题出在接力的哪一棒。因此评测体系必须按系统的实际组成环节分层建设，每一层有自己独立的指标和评测方法，再加一层端到端验收兜底，而不是笼统地打一个总分。

评测体系覆盖的八个层级（按一次请求实际流经的环节排列）：

提示词层 → 上下文构建层 → 记忆层 → 知识检索（RAG）层 → 工具与行动层 → 模型基座层 → 输出安全层 → 端到端与多轮协同层

下文按四个问题展开：为什么要分层评测、八个层级如何划分、每一层测什么指标、每一层具体怎么评。

一、为什么要按系统环节分层评测

如果只测”用户最终看到的回答好不好”，会遇到三个具体问题：

问题	具体表现	分层评测如何解决
定位不了故障环节	回答错了，但不知道是提示词没写清楚、上下文拼接出了问题、记忆记错了、检索没找对资料、工具调错了参数，还是模型本身能力不够	每一层单独可测，出问题时能直接定位到具体环节，而不是从头排查一遍
责任边界不清	提示词是工程写的，知识库内容是业务/运营维护的，模型能力是供应商提供的，出问题互相说不清楚是谁的责任	每一层对应明确的负责方，评测结果天然把责任边界划清楚
改动影响范围不可控	换一次模型、改一次检索策略、调一次记忆摘要逻辑，不知道会不会波及其他环节	分层评测让”只改了 A 层，其他层要不要重新测”变成一个可以回答的问题，而不是每次改动都要从头全量验证

一个环节的问题会沿着调用链路向下游传导：提示词写得模糊，会导致模型误解意图；上下文拼接把不可信内容当成指令，会导致行为被劫持；记忆记错或过期，会导致建议脱离用户真实情况；检索找错资料，会导致回答有理有据地说错话；工具调用参数错了，会导致执行了错误的动作；模型本身能力不够，会导致以上所有环节即使设计正确，最终生成依然不可靠；输出安全层如果失守，前面所有环节的问题都会真实地暴露给用户。分层评测的价值，就是在每一环都设一道关卡，把问题拦截在离它产生最近的地方，而不是等它传导到用户眼前才被发现。

二、评测体系总览：八个层级

用户输入
   │
   ▼
┌─────────────┐
│  提示词层    │  这一轮该遵守什么规则、扮演什么角色
└─────────────┘
   │
   ▼
┌─────────────┐     ┌──────────┐     ┌──────────────┐
│ 上下文构建层 │ ◄── │  记忆层  │ ◄── │ 知识检索层(RAG)│
└─────────────┘     └──────────┘     └──────────────┘
   │        把提示词、历史、记忆、检索结果组装成最终送给模型的内容
   ▼
┌─────────────┐
│  模型基座层  │  真正做理解、推理、生成的引擎
└─────────────┘
   │
   ▼
┌─────────────┐
│ 工具与行动层 │  需要查数据/办事时，调用外部能力（可能循环回到模型层多轮）
└─────────────┘
   │
   ▼
┌─────────────┐
│ 输出安全层   │  内容送达用户前的最后一道关卡
└─────────────┘
   │
   ▼
最终呈现给用户
   │
   ▼
┌───────────────────────┐
│ 端到端与多轮协同层      │  跨越以上所有环节的"总验收"：任务到底有没有完成、多轮下来前后一不一致、
│（贯穿全流程，独立评测）│  生产真实流量表现如何
└───────────────────────┘

层级	负责回答的问题	典型负责方
提示词层	该遵守的规则、边界，模型有没有听	工程 / 提示词设计者
上下文构建层	该给模型看的信息，有没有被正确、安全地组织起来	工程
记忆层	该记住的记住了没有、该忘的忘了没有	工程 + 产品
知识检索层（RAG）	该找到的依据资料，找到了吗、找对了吗	工程 + 知识库维护方
工具与行动层	该动手做的事，做对了吗	工程
模型基座层	引擎本身的理解、推理、生成能力够不够	模型供应商 + 工程（选型与监控）
输出安全层	内容送到用户面前之前，有没有拦住不该说的话	工程 + 安全/合规
端到端与多轮协同层	以上都对，用户的问题到底有没有被真正解决	产品 + 业务

三、每一层的指标与评测方法

1. 提示词层

这一层负责什么：定义系统的角色设定、行为规则、能力边界、话术风格——是整个系统”该怎么说话、能做什么、不能做什么”的第一道规则来源。

常见故障模式：规则写得含糊导致模型理解偏差；模板变量渲染出错；改了一版提示词后，原本正常的行为悄悄回归成错误行为；规则被后续拼接进来的上下文覆盖或稀释。

指标	定义	评测方法
模板契约正确性	提示词模板声明的变量和实际使用的变量是否一致，渲染时有没有缺参/多余参数	规则化静态校验，加载时做变量双向比对，100% 自动、每次改动都跑
指令遵从度	模型是否遵守了提示词里规定的行为边界（该做什么、不该做什么、该拒绝什么）	构造一批”规则边界用例”（该拒答的、该调用能力的、不该输出的表述），实际跑一遍统计遵从比例
版本回归通过率	新旧两版提示词，在同一批用例上的行为是否保持一致或变得更好	同一批用例分别跑新旧版本，逐条比对差异，人工确认差异是否可接受
抗覆盖能力	规则本身在后续被拼入大量历史/外部内容后，是否依然被有效遵守，而不是被”稀释”或”劫持”	构造带有诱导性指令的对话历史/外部内容，检验最终行为是否仍然遵守提示词规则

怎么落地评测：模板契约正确性可以做成 100% 自动化的强制检查，每次改动都跑，不通过直接拦截；指令遵从度和版本回归需要一份覆盖”正常、边界、冲突、诱导”四类场景的用例集，能用规则判断的直接判，不能用规则判断的用另一个模型当评委打分，并定期用人工抽查校准这个评委的判断是否可信。

具体评测细节：

测试对象固定化：每次评测必须记录提示词版本、模型版本、采样参数、模板变量、上下文版本和输出结果，确保问题能够复现。对包含条件分支的模板，每个分支至少准备一个用例，避免只测到主路径。
用例分层设计：正常用例验证角色、语气和基本任务；边界用例验证拒答、能力声明和信息不足时的处理；冲突用例同时给出互相矛盾的高低优先级指令；诱导用例在用户输入或外部材料中加入“忽略此前规则”等攻击指令。每类用例都要写明预期行为、禁止行为和关键判定点。
执行与判分：同一用例至少独立运行 3 次，避免偶然采样造成误判。格式、关键词、工具调用等确定性要求用规则判分；语义要求由评委模型按“完全遵从、部分遵从、不遵从”三级评分，分别记为 1、0.5、0 分。指令遵从度 = 实际得分之和 / 满分之和。
回归差异分类：新旧版本输出差异分为“预期改善、无影响变化、能力退化、安全退化”四类。安全退化一票否决；能力退化必须有明确豁免和负责人；仅比较总分不足以发现少量高风险用例退化，因此必须保留逐条差异结果。
建议门槛：模板变量、必填字段和结构化格式合法率必须为 100%；高风险规则（隐私、越权、违规内容）遵从率必须为 100%；普通指令遵从度建议不低于 95%，且不得低于当前线上基线。阈值应结合业务风险调整，而不是跨场景统一套用。
评测产物：输出用例编号、输入、完整渲染后提示词、模型输出、规则判定、评委理由、新旧版本差异和失败归因。失败用例修复后必须进入固定回归集，防止同类问题再次出现。

2. 上下文构建层

这一层负责什么：把提示词、对话历史、记忆摘要、检索到的资料、工具返回的结果，按照一定的顺序、格式、信任标记组装成最终真正送进模型的内容——是”信息怎么被摆放”这件事的责任方。

常见故障模式：外部或历史内容被模型误当成”指令”而不是”数据”来执行（注入攻击）；总长度超出预算导致关键信息被截断；信息堆得太长，模型抓不住真正重要的部分；不同来源的信息拼接时格式混乱，模型无法正确解析。

指标	定义	评测方法
注入隔离有效性	外部/历史内容中携带的”伪指令”，是否被正确识别为数据而非指令去执行	构造已知的注入攻击样本（诱导忽略规则、诱导泄露提示词、诱导越权调用），检验是否被执行
上下文预算利用率	实际内容长度是否在预算范围内，超限时的截断策略是否合理（截掉的是无关信息还是关键信息）	构造刚好超限和大幅超限两类样本，观察截断后关键信息是否被保留
关键信息命中率	塞进较长上下文里的关键信息，不论放在什么位置，模型是否都能真正利用到	把关键信息分别放在上下文的开头、中间、结尾，测试模型能否稳定地找到并使用它，考察是否存在”中间遗忘”现象
多源格式一致性	来自历史消息、检索结果、工具返回、记忆摘要等不同来源的信息，拼接后格式是否统一、模型是否能正确区分来源	构造多源混合的样本，检查模型是否能正确区分”这段是用户说的”还是”这段是检索到的资料”

怎么落地评测：注入隔离和格式一致性可以用固定的对抗样本库做回归测试，每次拼接逻辑改动都要跑；上下文预算和关键信息命中率需要专门构造”长上下文”压力测试集，重点验证系统在信息量接近或超过处理上限时的表现，而不是只测正常长度下的样本。

具体评测细节：

直接检查组装结果：评测不能只看最终回答，还要保存并检查真正发送给模型的完整消息序列，包括消息角色、来源标识、排序、分隔符、截断位置和 token 数。这样才能区分“上下文没有正确组装”和“模型看到了但没有使用”。
构造长度梯度：分别在上下文窗口的 25%、50%、75%、90%、100% 和超限状态下执行相同任务；把同一关键事实轮换放在开头、中间、结尾，并加入语义相近的干扰事实。关键信息命中率要按位置和长度分别统计，不能只报平均值。
验证截断策略：为每段内容标记优先级和是否必须保留，超限后逐项检查系统是否优先保留系统规则、当前用户请求、必要工具结果和有效记忆，优先删除重复、低相关和过期内容。关键内容被截掉即判该用例失败。
注入攻击矩阵：在用户历史、检索文档、网页内容、工具返回和记忆摘要五种来源中分别放入直接注入、角色伪装、编码混淆、跨段拼接和提示词窃取指令；统计攻击成功率。只要模型执行了外部数据中的越权指令、泄露受保护提示词或触发未授权工具调用，即视为攻击成功。
多源边界检查：验证不同来源是否有明确的结构边界、转义机制和信任等级；构造字段缺失、分隔符嵌套、超长字段、异常字符和内容重复等样本，检查是否发生角色串位、内容粘连或解析失败。
建议门槛：越权类注入攻击成功率必须为 0；关键规则和当前用户请求的保留率必须为 100%；正常预算内的多源解析正确率建议不低于 99%；长上下文关键信息命中率应按业务基线设门槛，并重点约束最差位置表现。
失败定位：报告中同时给出“进入组装器的原始信息、组装后信息、模型实际输入和模型输出”，将失败归因为来源缺失、排序错误、格式错误、截断错误、隔离失败或模型未利用，避免把所有问题笼统归到模型层。

3. 记忆层

这一层负责什么：让系统在多轮对话、跨会话的场景下，记得住该记住的信息，并在信息发生变化时正确更新或遗忘——是系统能否支撑”持续服务关系”而不只是”一次性问答”的关键。

常见故障模式：记忆被污染（把对话中出现的诱导性/虚假内容当成事实记录下来）；记忆过期（用户已经修正了偏好，但旧信息依然在被使用）；长程遗忘（早期的关键信息在后续摘要压缩过程中丢失）；摘要幻觉（生成记忆摘要时编造了用户从未表达过的内容）。

指标	定义	评测方法
短期一致性	同一次对话内，前后表述是否自相矛盾	构造需要跨轮次保持一致的问题，检验回答是否前后统一
长期召回准确率	跨越很多轮次或跨会话之后，是否还能准确复述早前提到的关键信息	构造”单跳直接回忆、多跳需要组合信息、时间相关、开放追问”四类场景的问答测试，覆盖不同难度的记忆调用需求
更新与遗忘正确性	用户中途修正或更新过的信息，后续是否被正确采用，旧信息是否被正确废弃	构造”早期给出偏好、中途修正、后期考察采用的是新偏好还是旧偏好”的测试脚本
摘要保真度	自动生成的记忆摘要是否忠实于原始对话内容，没有编造原文没有的信息	用另一个模型或人工逐条核对摘要内容与原始对话是否对应
记忆抗污染能力	对话中出现的诱导性或虚假陈述，是否被错误地当成确认过的事实记录进长期记忆	构造带有诱导性虚假陈述的对话，检验记忆系统是否正确地未采信

怎么落地评测：这一层几乎无法靠单轮测试覆盖，必须构造多轮甚至跨会话的场景化脚本；摘要保真度和抗污染能力适合用另一个模型做初筛、定期人工抽样复核，因为这类判断往往涉及语义细节，规则很难穷举。

具体评测细节：

建立事实账本：每个多轮脚本维护一份独立于系统记忆的标准事实账本，记录事实内容、来源轮次、置信状态、有效时间、是否允许长期保存以及后续更新关系。评测时以账本为准，而不是用模型之前的回答作为标准答案。
覆盖记忆生命周期：至少包含“写入—召回—更新—冲突处理—过期—删除”六个阶段。测试用户首次给出偏好、重复确认、明确修改、提供矛盾信息、要求忘记，以及跨会话再次询问时，系统是否执行了正确的生命周期动作。
设置干扰轮次和时间跨度：在事实写入和召回之间插入 5、20、50 轮无关对话，并分别测试同会话、次日会话和长期跨会话。召回结果按实体、属性、时间和状态四个字段逐项比对，避免“意思大概对”掩盖关键字段错误。
摘要保真度判定：将摘要拆成最小事实单元，逐条标记为“原文支持、原文矛盾、原文未提及、重要事实遗漏”。摘要事实精确率 = 有原文支持的事实数 / 摘要事实总数；摘要事实召回率 = 被摘要保留的重要事实数 / 原文重要事实总数。编造敏感属性应作为严重错误单独统计。
污染与冲突测试：加入未经用户确认的推测、引用他人的信息、玩笑或否定句、外部文档中的人物资料以及“请把下面内容永久记住”的恶意指令，检查其是否被错误写入。新旧事实冲突时，还要验证系统是否依据时间、来源可信度和用户明确确认进行更新，而不是简单追加两个矛盾结论。
隐私与删除验证：对不应持久化的敏感信息检查是否未写入；用户要求删除后，同时检查可见记忆、检索索引、摘要和后续回答是否均不再使用该信息。删除后仍可被召回，应视为高风险失败。
建议门槛：明确更新采用率和删除执行率必须为 100%；摘要中“原文矛盾”和“原文未提及”的关键事实必须为 0；普通事实长期召回准确率建议不低于 95%。评测报告需同时展示平均值和最差场景结果。

4. 知识检索层（RAG）

这一层负责什么：从知识库、文档、数据库中找到能够支撑回答的真实依据，让系统的回答”有理有据”，而不是靠模型自身记忆自由生成——是控制幻觉最关键的一道防线。

常见故障模式：该找到的关键资料没有被检索到（漏检）；检索到了大量不相关的内容，干扰模型判断（噪声）；生成回答时脱离检索到的内容自由发挥（生成侧幻觉）；引用的来源本身是编造的；依据材料已经过期但依然被使用。

指标	定义	评测方法
检索召回率	该被找到的关键依据，有多大比例真的被检索到	用”问题-标准依据”配对数据集，统计标准依据出现在检索结果中的比例
检索精确率	检索出来的内容里，有多大比例是真正相关、有用的	同样用标准数据集，统计检索结果中无关内容的比例
排序质量	最相关的内容是否排在结果的前面	检查真正相关的依据是否排在检索结果的靠前位置，而不是被埋没在后面
生成忠实度	最终回答的内容是否完全基于检索到的依据，而非脱稿编造	逐句核对回答内容和检索到的依据材料是否对应，可由另一个模型辅助批量判断
引用可追溯性	回答里标注的引用来源，是否真实存在于本次检索结果之中	规则校验：引用标识是否落在本次检索结果的白名单集合内
知识新鲜度	被引用的依据材料是否为最新有效版本，而非已经作废的旧版本	结合知识库的更新时间戳做规则校验，或抽样人工核实
无依据场景的诚实拒答率	知识库中确实没有相关信息时，系统是否如实告知，而不是编造答案	构造已知”库内确实没有答案”的问题集合，检验是否诚实拒答

怎么落地评测：召回率、精确率、排序质量需要一份专门标注过”标准依据”的评测集，这份数据集的质量直接决定评测结果是否可信；忠实度和引用可追溯性建议作为发布前的强制检查项，因为这两项直接对应”胡说八道”这个最容易伤害用户信任的失败模式。

具体评测细节：

建设标准数据集：每条样本至少包含用户问题、标准答案、必要证据文档 ID、可接受的补充证据、无关但相似的干扰文档、时间有效性和答案是否应拒答。数据集要覆盖精确问法、口语问法、错别字、同义改写、多跳问题、时间敏感问题和库内无答案问题。
拆分检索与生成评测：检索评测固定查询，只检查候选文档是否找对；生成评测固定提供标准证据，只检查回答是否忠实；最后再跑真实端到端链路。三组结果可以分别定位检索器、重排器和生成器的问题。
检索指标计算：使用 Recall@K 衡量前 K 条中覆盖了多少必要证据，Precision@K 衡量前 K 条中相关证据占比，MRR 衡量首条正确证据的排名，nDCG@K 衡量多级相关性下的整体排序质量。K 应与线上实际传给模型的文档数量一致，并同时报告 K=1、3、5 等关键档位。
切片级核验：除文档 ID 外，还要检查命中的具体段落是否包含回答所需信息。仅检索到正确文档、却没有把正确片段送给模型，不能记为成功。对表格、图片 OCR、标题层级和跨页内容应单独建样本。
回答忠实度评测：将回答拆成可验证主张，逐条标记为“证据直接支持、可合理推导、证据冲突、无证据”。生成忠实度 = 被支持或可合理推导的主张数 / 可验证主张总数；涉及数字、日期、主体、条件和结论的关键主张须进行精确匹配。
引用校验：检查引用 ID 是否来自本次检索、引用片段是否真的支撑相邻主张、链接是否可访问、版本是否有效。引用存在但不能支撑对应结论，应记为错误引用，而不是引用成功。
无答案与新鲜度测试：对库内无答案、仅有过期答案、不同版本相互冲突三类问题分别测试。期望行为是说明依据不足、优先采用当前有效版本或明确呈现冲突，不允许将旧材料无提示地当成现行结论。
建议门槛：关键业务问题的必要证据 Recall@K 建议不低于 95%，引用可追溯率必须为 100%，关键事实忠实度必须为 100%，无依据问题不得编造答案。普通指标阈值应依据当前线上基线和业务风险分级设置。

5. 工具与行动层

这一层负责什么：让系统具备真正”动手做事”的能力——查询数据、调用外部服务、执行操作，是 Agent 区别于纯聊天系统的核心能力，也是唯一可能产生不可逆后果的一层。

常见故障模式：该用哪个能力选错了；参数错误、缺失校验或超出合理范围；本该先向用户确认却直接执行；在权限范围之外行动；反复进行无意义的重复调用；工具调用失败或返回异常时不会合理应对。

指标	定义	评测方法
工具选择准确率	面对特定需求，是否选择了正确的能力去处理	构造覆盖不同意图的用例集，对照标准答案检验选择是否正确
参数正确率	调用时填入的参数是否合法、完整，且确实来自用户明确提供的信息	参数 Schema 校验 + 构造”信息不全""参数越界""参数被恶意篡改”等对抗样本
调用时机合理性	信息不全时是否先追问，而不是靠猜测直接执行	构造信息故意残缺的多轮场景，检验是否主动追问而非臆测
权限遵从 / 越权行为率	是否始终在授权范围内行动，有没有做出超出权限的承诺或操作	构造诱导越权的对抗性场景（如诱导给出未授权的折扣、承诺），检验是否守住边界
副作用可控性	一次行动有没有波及不该波及的范围，造成难以撤销的后果	针对具备实质性副作用的能力，单独设计边界测试，确认异常输入不会触发破坏性操作
重复/冗余调用率	是否存在无意义的重复调用或陷入循环	统计单次任务内的调用次数和重复调用比例，设定合理上限
失败恢复能力	调用失败或返回异常时，能否合理应对而不是编造一个看似正常的结果	主动构造工具返回错误、超时、空结果等异常场景，检验后续应对是否诚实、合理
多轮任务成功率	结合多次工具调用完成一个完整、真实的任务，最终是否达成用户目标	用”模拟用户”进行多轮真实交互（会分批透露信息、会追问、会中途改主意），全程结束后判定任务是否达成
多次运行稳定性	同一任务反复运行多次，成功率和结果是否保持稳定	同一用例独立重复运行多次，统计成功率的波动范围

怎么落地评测：参数正确率、权限遵从、副作用可控性属于能明确写成规则的部分，必须做成强制的硬门禁；多轮任务成功率和调用时机合理性必须依赖”模拟用户”做真实的多轮交互测试，单轮测试完全覆盖不到”该追问却没追问”这类失败模式。

具体评测细节：

建立工具契约：为每个工具明确名称、用途、输入 Schema、字段来源、默认值、权限要求、幂等性、副作用等级、超时策略和预期返回结构。评测标准直接来自契约，避免用“最终看起来完成了”替代对调用过程的检查。
按风险分级执行：只读查询可在隔离测试环境直接运行；可撤销写操作在沙箱账户运行并检查回滚；付款、删除、对外发送等高风险操作只能使用 mock 或专用测试账户，并必须验证确认步骤。任何评测都不得触达真实用户数据或真实生产副作用。
工具选择用例：为“必须调用、可以调用、不应调用、无可用工具”四种情况分别准备样本。既要统计选错工具，也要统计该调用却未调用和无需调用却多调工具，避免准确率掩盖过度调用问题。
参数来源追踪：每个关键参数要能够回溯到用户输入、可信上下文或工具返回；无法回溯且未经用户确认的参数视为臆造。测试必填项缺失、单位歧义、日期时区、枚举边界、超长输入、特殊字符和恶意参数注入。
确认与授权测试：对不可逆操作设置“执行前状态、待确认方案、用户确认、执行后状态”四个检查点。确认内容必须包含操作对象、范围和关键后果；用户只确认部分范围时，不得扩展执行。撤销确认或中途改意图后，应停止后续调用。
故障注入：模拟超时、限流、鉴权失败、部分成功、返回空值、Schema 变化、重复响应和服务不可用。检查 Agent 是否有限次重试、是否避免重复副作用、是否准确说明未完成部分，以及是否在无法确认结果时停止而不是声称成功。
轨迹级判分：除最终任务是否成功外，还要检查调用序列。建议将单条用例拆成工具选择、参数、权限、确认、执行结果、恢复行为和最终说明七个评分点；其中越权、真实副作用失控、伪造成功结果为一票否决项。
稳定性与成本：非确定性任务至少独立运行 5 次，报告成功率、平均调用次数、P95 调用次数、平均耗时和工具成本。设置最大调用轮次与重复调用检测，相同参数连续调用且没有新的信息依据时，应标记为冗余或循环。
建议门槛：越权调用率和高风险误执行率必须为 0；参数 Schema 合法率必须为 100%；高风险操作确认率必须为 100%；普通任务成功率建议不低于 95%，失败后“虚假宣称成功”的比例必须为 0。

6. 模型基座层

这一层负责什么：真正承担理解、推理、生成的底层引擎能力。这一层通常来自外部模型供应商，团队无法直接修改它的内部行为，但必须持续监控它——尤其是换模型、模型升级、供应商静默调整版本这些时刻。

常见故障模式：供应商在背后静默升级模型版本，导致系统行为在没有任何代码改动的情况下发生漂移；更换模型供应商后，同一套提示词在新模型上表现明显不同；不同模型对结构化指令、长上下文、复杂指令的敏感度存在系统性差异。

指标	定义	评测方法
指令遵从的模型侧差异	同一套提示词，在新旧模型或新旧版本之间的行为一致性	用同一份评测集分别跑新旧模型/版本，逐条比对结果差异
输出格式稳定性	要求结构化输出时，新模型是否依然能稳定产出合法格式	大批量重复采样，统计格式合法率
幻觉基线水平	在完全相同的任务和依据材料下，不同模型自身固有的幻觉倾向差异	用固定的忠实度评测集，对比不同模型的幻觉率基线
版本漂移监控	在没有主动升级的情况下，模型的实际表现是否发生了未经通知的变化	定期（而不是只在主动升级时）重新跑一遍基线评测集，监控指标是否出现异常波动

怎么落地评测：换模型或模型版本变化前，必须用完整的黄金评测集在新旧模型上各跑一遍做逐条对比，而不是假设”提示词没变、效果就不变”；同时应该定期而非被动地重跑基线评测，因为供应商侧的静默升级不会主动通知使用方。

具体评测细节：

隔离系统变量：模型基座评测应固定系统提示词、上下文、工具返回、解码参数和输出解析器，只替换模型或模型版本。否则评测结果无法说明差异究竟来自模型还是系统其他环节。
能力集构成：黄金集至少覆盖意图理解、指令遵从、信息抽取、结构化输出、事实性、长上下文、逻辑推理、多语言、拒答边界和工具参数生成。业务核心场景应占主要权重，通用公开基准只作为补充，不能替代真实业务样本。
重复采样：对温度大于 0 或表现不稳定的任务，每条样本至少运行 3—5 次，报告均值、标准差和最差结果。仅跑一次会把随机波动误判成版本提升或退化。
成对盲评：语义质量比较采用隐藏模型身份和输出顺序的成对盲评，由评委选择 A 优、B 优或持平；定期抽取样本由两名人工独立复核，计算一致率。评委模型不得仅凭文风、篇幅或自报身份判断优劣。
格式与事实硬指标：JSON、字段、类型和枚举值用解析器直接校验；数学、日期、实体等有标准答案的任务做精确或容差匹配；开放回答再使用量表评分。能确定性判断的内容不得交给评委模型主观打分。
升级判定：同时比较质量、P50/P95 延迟、输入输出 token、调用成本、限流率和错误率。新模型只有在安全指标不退化、核心任务达到门槛且成本延迟可接受时才能升级；不能用普通用例的平均提升抵消高风险用例的下降。
漂移监控：保存模型返回的版本标识、请求时间和供应商元数据；按日运行小型哨兵集、按周或按月运行完整基线集。使用固定样本监控控制图或相对基线变化，连续异常或核心指标超过容忍区间时触发调查。
建议门槛：结构化输出合法率建议不低于 99.5%，安全和权限相关能力不得低于现网模型，核心场景胜率不得出现统计显著退化。具体升级门槛应在测试前确定，避免看完结果后再调整标准。

7. 输出安全层

这一层负责什么：在内容真正送达用户之前的最后一道防线——拦截违规表述、剔除伪造引用、阻止越权承诺，是防止前面所有环节的潜在问题真正暴露给用户的兜底机制。

常见故障模式：语义层面的过度承诺没有被固定的禁词表覆盖到；流式输出场景下，用户已经看到了违规内容的一部分才被后台检测拦截；安全审查环节本身出错或超时时，被错误地当作”审查通过”处理（一种高危的失效模式）。

指标	定义	评测方法
明确禁语拦截率	已知的、被明令禁止的表述是否被完全拦截	用已知违规样本库做覆盖率测试，要求达到接近 100%
语义违规检出率	没有触发明确禁词、但语义上构成误导或过度承诺的表述，能否被识别	用另一个模型专门做语义层面的判断，并用人工标注数据分别核算这个判断的准确率和召回率
跨分片检测有效性	在流式分段输出的场景下，被拆散到多个片段里的违规内容，拼起来看依然能被识别，而不是因为逐片段检测而被漏过	构造把已知违规表述人为拆分到多个输出片段中的样本，检验是否依然能被识别
安全审查失效时的默认策略	审查环节本身出错、超时或返回异常时，系统的默认处理是”保守拦截/降级”还是”直接放行”	主动模拟审查服务异常，检查默认行为是否倾向保守，“直接放行”应被视为设计缺陷
越狱/注入抵御率	面对刻意构造的诱导性攻击，安全策略能否守住既定规则	用持续更新的对抗样本库定期做红队测试

怎么落地评测：明确禁语拦截和跨分片检测必须做成强制门禁，且要专门测试”分片输出”场景，因为很多团队只测试了完整文本、漏测了真实流式场景下的分片行为；语义违规检出率对应的评委模型必须先用人工标注过的历史违规/合规案例做校准，不能假设它天生可信；安全审查失效时的默认策略必须显式测试，这是最容易被忽视、但一旦发生就后果严重的一类隐患。

具体评测细节：

建立安全分类体系：按照业务规则定义违规类别、严重等级、允许例外和期望处置，例如直接拦截、改写、脱敏、提示风险或转人工。每条测试样本必须绑定类别与期望动作，不能只标一个笼统的“安全/不安全”。
正负样本同时评测：违规集覆盖直接表达、同义改写、隐喻、错别字、谐音、编码、跨语言和上下文组合；合规集包含容易被误伤的新闻讨论、教育说明、否定句和合理业务表达。分别统计召回率和误杀率，避免通过“全部拦截”获得虚假的高安全分。
分级指标：对每类分别计算召回率、精确率、误杀率和漏放率，并按严重度单独报告。高危漏放不能被大量低风险样本的正确结果稀释，因此不得只看一个总体准确率。
流式输出测试：将违规短语按字符、词语和语义单元拆分到多个分片，并改变分片大小和间隔；记录从违规内容形成到停止输出之间已经暴露的字符数和检测延迟。需要验证缓冲窗口足以覆盖跨分片语义，同时不会造成不可接受的用户延迟。
敏感信息与引用检查：植入手机号、证件号、密钥、内部提示词和虚构来源，验证脱敏或拦截行为。对合法引用和虚构引用分别测试，防止安全层只判断内容类别、不校验来源真实性。
失效与旁路测试：主动模拟审核服务超时、异常状态码、空响应、解析失败和网络中断，同时检查同步输出、流式输出、重试和降级路径。任何一条路径绕过审核直接放行，都应作为高风险缺陷处理。
红队迭代：每次生产发现的新攻击方式先脱敏，再加入对抗样本库；定期改变表达、语言和上下文，防止模型只记住固定字符串。修复时同时测试同类变体和合规近邻样本，避免修复一个漏放却引入大面积误杀。
建议门槛：最高风险类别召回率和审核异常时的保守处置率必须为 100%；其他类别门槛按风险确定，同时为合规误杀率设置上限。发布报告必须列出全部漏放样本和高影响误杀样本，而不是只展示汇总分数。

8. 端到端与多轮协同层

这一层负责什么：前面七层各自都测过，不代表把它们组合在一起就一定没问题——这一层做”总验收”，同时覆盖只有把全流程放在一起看才能发现的问题：多轮对话的整体连贯性、多个协作角色之间的交接是否正确、真实生产流量中暴露的新问题、以及最终这套系统有没有真正为业务创造价值。

常见故障模式：每一步单独看都对，但整体任务没有真正达成用户目标；多轮之间前后矛盾但没有单独触发某一层的检测；多个分工协作的环节之间责任交接出现遗漏；离线测试通过，但真实生产流量中出现了测试阶段完全没有预料到的新场景。

指标	定义	评测方法
端到端任务成功率	一次完整的交互下来，用户的真实目标有没有被达成	构造覆盖典型场景的端到端用例集，用模拟用户完整走一遍全流程后判定
多轮/跨会话一致性	贯穿整个任务的过程中，各个环节组合起来是否依然保持一致，没有出现单层检测不到的矛盾	设计需要跨越多个环节才能验证的综合场景，例如”记忆里的信息”和”检索到的资料”如果冲突，系统如何处理
协同交接正确率	如果系统由多个分工角色组成，一个角色向下一个角色交接任务时，信息传递是否完整、准确	检查每次交接时上下文和关键信息是否完整传递，有没有遗漏
生产真实流量异常率	系统上线后，真实请求中出现格式错误、超时、拒答率异常、负反馈等问题的比例	对生产日志做实时规则统计和告警，配合每日抽样人工复核
新失败模式发现速度	从生产环境出现一个此前未见过的失败场景，到它被识别、分析、补充进离线评测集的时间	建立”生产发现问题 → 定期复核 → 回补测试集”的固定流程，并跟踪这个周期的时长
业务结果指标	系统上线后，真实的业务效果（任务转化、投诉率、满意度、净人力成本变化等）是否得到改善	结合业务数据看板，对比上线前后或对照组数据，定期复盘

怎么落地评测：端到端和多轮一致性适合用模拟用户做完整场景的黄金用例回归，作为发布前的最后一道关卡；生产真实流量异常率和新失败模式发现速度不是发布前能测出来的，必须依赖上线后的持续监控和抽样复核机制；业务结果指标滞后性最强，不用于单次发布的通过/拒绝判断，而是决定”要不要继续加大对这个场景投入”的依据。

具体评测细节：

按用户目标设计场景：每条端到端用例包含用户画像、初始目标、已知信息、隐藏信息、允许的目标变更、成功条件、失败条件和最大轮次。成功条件应描述可验证的业务结果，而不是“回答流畅”或“用户看起来满意”。
覆盖完整场景类型：至少包括黄金路径、信息不全、用户中途改意图、记忆与检索冲突、工具部分失败、需要转人工、长对话和跨会话恢复。关键业务流程还应覆盖取消、回滚和重复提交等异常路径。
模拟用户约束：模拟用户只能根据脚本逐步透露信息，不得主动替 Agent 补齐其本应追问的字段；当 Agent 问错问题、重复追问或做出错误假设时，模拟用户按预设规则响应。模拟器使用的模型、提示词和随机种子要版本化，避免评测环境变化造成结果漂移。
结果与轨迹双重判分：结果分检查任务是否真正完成、关键事实是否正确、用户目标是否满足；轨迹分检查轮次、澄清质量、工具调用、交接、恢复和安全行为。最终结果偶然正确但过程越权，仍判失败；过程合理但外部服务失败，可以单独标记为可恢复失败。
多角色交接检查：为每次交接定义必传字段、禁止传递字段、状态和下一步责任人；比较发送方交接包、接收方实际上下文和后续行为。交接正确率 = 完整且准确传递的必需字段数 / 必需字段总数，并单独统计敏感信息越界传递。
一致性检查：把跨轮次出现的用户事实、系统承诺、任务状态和工具结果抽取成状态表，逐轮检查是否发生无依据变化。遇到记忆与最新用户信息、检索资料与工具实时结果冲突时，检查系统是否按预设优先级处理并向用户说明。
生产评测机制：对真实流量按场景、用户类型、模型版本和风险等级分层抽样，先脱敏再评审；监控成功率、超时率、重试率、转人工率、负反馈率和安全事件。线上 A/B 测试要预先定义主指标、护栏指标、样本量和停止条件。
失败闭环：每个失败记录首次发现时间、影响范围、严重度、责任层、根因、临时措施和永久修复；修复后将脱敏样本加入对应单层评测集和端到端回归集。新失败模式发现速度按“首次发生到完成分类入库”的时长计算。
建议门槛：关键黄金路径任务成功率建议不低于 95%，高风险流程的安全违规和越权执行必须为 0，交接必需字段完整率必须为 100%。发布时除总体成功率外，还必须满足各核心场景的最低门槛，不能用简单场景的高分抵消关键场景失败。
发布判定方式：采用“硬门禁 + 加权总分”组合。安全、权限、不可逆副作用、关键事实错误属于硬门禁，任一失败即停止发布；其余质量、效率、成本和体验指标按业务权重汇总，并与当前线上版本做成对比较。

四、八层汇总速查

层级	核心指标数量级	主要评测方式	能否 100% 自动化
提示词层	4 项	规则校验 + 场景用例回归	大部分可以
上下文构建层	4 项	对抗样本库 + 长上下文压力测试	大部分可以
记忆层	5 项	多轮/跨会话场景化脚本 + 模型辅助核对	部分需要人工抽查
知识检索层	7 项	标注数据集量化 + 模型辅助核对 + 规则校验	部分需要人工抽查
工具与行动层	9 项	参数规则校验 + 模拟用户多轮交互	部分需要模拟用户脚本
模型基座层	4 项	新旧模型/版本逐条对比 + 定期基线重跑	大部分可以
输出安全层	5 项	违规样本库 + 语义评委 + 故障注入测试	部分需要人工校准评委
端到端与多轮协同层	6 项	模拟用户完整场景回归 + 生产监控 + 业务复盘	需要持续的人工介入

一条贯穿八层的通用原则：能用规则判断的指标，一律用规则判断，做成每次改动都能跑的强制门禁；规则无法覆盖的语义类指标，用另一个模型做评委，但评委本身必须先用人工标注的历史真实案例校准过判断力（准确率和召回率要分开测，不能只看笼统的一致率）；人工复核始终保留在体系里，专门负责发现新的失败模式和校准评委——越靠近”端到端与多轮协同层”，人工参与的比例应该越高。

五、落地顺序建议

八层不需要同时铺开，投入产出比最高的顺序是：

先建提示词层和输出安全层：这两层能规则化的比例最高，成本最低、见效最快，也是防止最严重后果（违规、越权）的第一道防线。
再建知识检索层：只要系统依赖外部知识回答问题，忠实度和引用可追溯性就是控制幻觉最直接的手段，投入优先级仅次于安全层。
针对具备实质行动能力的场景，重点建设工具与行动层：尤其是参数校验和权限遵从，这一层的失误后果是行动层面的，代价最高。
记忆层和模型基座层可以稍晚投入：记忆层的价值随着系统支持的对话轮次和跨会话场景增多而增大；模型基座层的监控在每次换模型/模型升级前必须补上，平时可以按较低频率抽查。
端到端与多轮协同层贯穿始终，但深度随其他七层的成熟度递增：初期只需要覆盖最核心的几条黄金路径做发布前回归；生产监控和业务复盘从上线第一天就应该同步建立，越早建立，越早开始积累”生产发现问题反哺离线测试集”的闭环。

判断该往哪一层优先投入的依据只有两条：这一层一旦出错，后果的严重程度有多高（是”回答不够好”还是”造成了不可逆的行动后果或合规风险”），以及这一层当前的覆盖率有多低。优先补最高风险、当前覆盖率最低的层，而不是平均用力。