01只有正常场景的评测是不完整的
一家法律科技公司部署了一个合同审查AI，在内部测试阶段，工程团队对100个合同样本进行了评测，系统的准确率达到了94%。团队信心满满地将产品推向律师用户。
两个月后，一位律师在审查一份不寻常的合同时发现：当他故意在提问中加入一些"语义混淆"的措辞，系统会提供完全错误的合同条款解读，而且给出的置信度仍然很高。更严重的是，当他测试系统对一些刻意设计的越权请求的处理方式时，发现系统会在某些措辞下尝试提供本应受访问权限限制的信息。
团队复盘后发现：他们的100个评测样本，几乎全部是来自真实业务场景的"正常案例"。没有一个边界案例（格式异常的合同、极端复杂的嵌套条款），也没有一个对抗案例（语义攻击、越权测试）。他们测出了系统在正常场景下的功能质量，却对系统在异常和对抗情境下的表现完全没有了解。
02三层评测结构的逻辑
评测矩阵的三层结构，对应了Agent在真实世界中面对的三种不同类型的挑战，每一层回答一个不同的质量问题。
正常场景（60%）：这个Agent能完成它承诺的事情吗？这是最基础的功能验证。正常场景来源于真实用户的高频使用路径：标准问答、典型任务执行、常见格式的输入。通过率标准最高（>95%），因为这代表了Agent的核心价值承诺。如果正常场景的通过率不达标，说明产品还没有准备好面对用户。
边界场景（30%）：当事情不按预期发展时，Agent能优雅处理吗？这是鲁棒性验证。真实世界的用户不总是按照产品设计的方式使用系统：他们会输入超长文本，会发出模糊的请求，会在多轮对话中改变意图，会使用产品未见过的特殊格式。边界场景的通过标准相对宽松（>85%），因为并非所有边界情况都需要完美处理——有时候优雅地拒绝或请求澄清，比强行给出错误答案要好。
对抗场景（10%）：当有人试图破坏系统时，Agent能抵御吗？这是安全性验证。Prompt注入攻击尝试通过特殊构造的输入来覆盖系统的安全指令；越权操作尝试通过声称特殊身份或编造紧急情况来获得超出权限的信息；敏感信息泄露尝试通过间接提问来诱导系统透露不应公开的数据。对抗场景的通过标准是99%的拦截率——在安全性上，几乎不允许任何失败。
03七维评测指标：不只是准确率
准确率是最常被单独提及的评测指标，但它只是七个重要维度中的一个。单独看准确率，会错过系统质量的其他关键维度。
准确性（任务完成率）回答的是"做对了吗"；相关性（回答相关度）回答的是"有帮助吗"——这两个问题的答案可能不同。一个在技术上正确但完全不回答用户实际问题的回复，准确率高但相关性低。
安全性（攻击拦截率）要求近乎完美（>99%），体现了安全性在整个质量体系中的特殊地位——它不是一个可以与其他维度权衡的指标，而是一票否决的底线。
一致性（输出稳定性）是一个容易被忽视的维度。相同的输入在不同时刻产生差异极大的输出，会破坏用户对系统的信任，即便每次的输出在内容上都可以接受。一致性阈值80%意味着：给定相同输入，至少80%的运行结果应该落在质量可接受的范围内。
合规性（合规通过率）的阈值是100%，没有妥协空间。任何合规性失败，无论多么罕见，都可能带来法律责任和声誉损失。合规测试应该涵盖所有适用于产品的监管要求，并随着监管变化及时更新。
04评测集的构建：质量优于数量
一个精心构建的50个测试案例的评测集，比随机收集的500个案例更有价值。评测集的质量取决于三个要素：场景代表性（每个案例是否代表了一类真实的使用场景）、评分可操作性（期望输出和评分标准是否清晰到可以被不同人一致执行）、层次完整性（三层结构的覆盖比例是否合理）。
构建评测集的起点是场景收集，而非案例编写。先从用户日志中识别高频的正常使用路径，从历史故障记录中提取典型的边界问题，从安全威胁建模中确定需要防御的对抗模式。有了场景地图，再为每类场景编写具体的测试案例。
评测集不是一次性工作，而是需要持续维护的活文档。每个月应该审视：是否有新的使用场景未被覆盖？是否有历史案例因为产品升级已经过时？是否有新的安全威胁需要加入对抗场景？评测集的更新频率，应该匹配产品的迭代节奏。
05评测运营：让质量成为持续的事情
评测如果只在发布前做，它就是一个检查点；如果它成为持续的活动，它就是质量文化的一部分。
常规评测（每次发布前）由开发团队负责，确保每次变更不引入新的质量退化。深度评测（每月一次）由专门的质量团队负责，进行更全面的质量分析，包括对评测集本身质量的回顾。红队测试（每季度一次）由安全团队负责，模拟真实的对抗攻击，发现评测集可能遗漏的安全漏洞。
每两周一次的指标复盘是整个评测运营体系的关键活动。它不是汇报结果，而是提问：质量趋势是在改善还是在下滑？哪些维度出现了新的问题模式？评测集是否需要新增或淘汰案例？这些问题的答案，直接驱动下一个开发周期的优化优先级。
06那家法律科技公司的后续
那家法律科技公司在事故之后，重建了评测体系。他们在原有100个正常场景案例的基础上，增加了45个边界场景（极端格式的合同、高度嵌套的条款、多语言混合文档）和15个对抗场景（语义攻击、越权尝试、信息泄露尝试）。
重建后的评测集揭示了4个之前未知的系统缺陷：在某类特殊格式的合同上，关键条款的识别准确率只有67%；对于某种措辞方式的越权请求，系统的拦截率只有82%。两个问题都通过针对性的工程修复得到了解决，但更重要的是，评测体系现在能够在问题进入生产环境之前就被捕获。
评测矩阵的价值不在于发现问题，而在于建立对系统质量全貌的诚实认知。一个只覆盖正常场景的评测，给出的是一个乐观但不完整的质量画像——它告诉你系统在最好的情况下表现如何，却无法告诉你系统在压力下会如何失败。
01团队成员无法测试他们想象不到的失败模式
智能体产品发布之前，几乎所有团队都会做测试。测试结果通常是令人满意的——设计的场景通过了，主要功能运行正常，输出质量达标。团队有信心地推进发布。
然后，真实用户开始使用。几天之内，出现了一批测试时从未预料到的失败：用户用了一个没想到的问法方式，系统给出了完全错误的响应；某个用户提交了一个边界情况的输入，系统陷入了循环；一个试图攻击的用户输入了几句特殊措辞，系统的行为模式发生了不该发生的改变。
团队回头看测试设计，发现问题所在：测试用例全部来自团队成员的预设场景——他们能想到的用法、他们觉得合理的输入。但真实用户的行为从来不只在预设场景里发生。
02测试设计的系统性盲点
本框架创新：将软件测试的边界值分析和安全领域的红队对抗测试，系统性地引入智能体评测设计，构建三层递进的评测矩阵；提出"缺少任何一层，质量画像都不完整"作为评测完整性的强制要求。
这不是测试做得不认真的问题，而是测试设计有一个系统性的认知盲点：团队成员无法测试他们想象不到的失败模式。
传统软件测试的范围定义，主要基于功能规格和代码分支。通过分析功能规格和代码，可以设计出覆盖所有代码路径的测试用例，这叫做"覆盖率"，是传统软件测试质量的核心指标。
智能体系统的测试覆盖率概念在这里失效了。智能体的"输入空间"是自然语言，这个空间是无限的，没有可以被穷举的代码路径。任何基于团队预设场景的测试集，都只覆盖了这个无限空间的极小一角。
在智能体系统里，对真实使用威胁最大的，恰恰是那些测试覆盖率最低的场景类型——边缘情况和对抗性输入。这两类场景，在团队的预设测试集里几乎不存在，但在真实世界里真实发生。
03三层评测矩阵的设计逻辑
TSEM 把智能体系统的评测覆盖，分为三个在难度和风险维度上递进的层次。
第一层·正常场景层（Normal Scenarios）
预期用户在预期方式下的典型使用。这一层的设计相对直接——团队根据产品定位，设计覆盖主要使用场景的测试用例，验证基础功能是否运行正常。这是大多数团队的测试重心，也是基础质量的必要条件，但只有这一层远远不够。正常场景层揭示的是：系统在理想情况下能不能做到基础的事。
第二层·边缘场景层（Edge Cases）
偏离预期的输入——格式不标准、描述模糊、包含歧义、覆盖边界条件、测试极限输入长度。边缘场景不是异常，而是正常使用场景的扩展——任何真实用户群体中，都有相当比例的用户不会以"标准"的方式使用产品。设计边缘场景测试，需要团队主动思考：如果用户描述不清楚、用了一个我们没想到的词汇、输入了一个极端长的文本——系统怎么处理？答案应该是"优雅地降级"，而不是"失败或产生错误输出"。边缘场景层揭示的是：系统的鲁棒性边界在哪里。
第三层·对抗场景层（Adversarial Scenarios）
主动尝试让系统失效的输入——提示词注入攻击、越权请求、角色劫持、刻意构造的矛盾性输入。这一层需要团队以攻击者的视角来看待自己的系统：如果有人想要让这个系统做它不应该做的事情，最可能通过什么方式？对抗场景测试的价值，不只是发现可以被利用的安全漏洞，更在于揭示系统在压力下的行为模式。
04三层的内在必要性
"缺少任何一层，质量画像都不完整"——这句话不是夸张，而是有严格逻辑支撑的命题。
只有正常层，没有边缘层：系统在测试环境里完美，在真实用户的多样使用方式里频繁降级，因为真实用户不遵守"标准使用方式"。
只有正常层+边缘层，没有对抗层：系统在意外输入下能够优雅处理，但面对主动攻击时毫无防御，一次提示词注入就可以让系统产生有害输出或者泄露不该泄露的信息。
只有边缘层+对抗层，没有正常层：这种情况比较少见，但存在于那些只重视"把系统做得足够强壮"而忽视了"基础功能是否正确"的团队。
三层必须同时存在，缺少任何一层，都会在那个层次代表的场景类型里留下未被检验的质量漏洞。
05人类想象力的局限
三层评测矩阵揭示的，是真实世界和测试环境之间差距的根本来源。
测试环境是被设计出来的，它包含了设计者能想到的场景。真实世界不被设计，它包含了所有可能的场景，包括设计者没有想到的。
测试覆盖率的局限，本质上是人类想象力的局限。没有人能够预设所有可能的边缘情况，没有人能够完全模拟所有可能的攻击向量。三层评测矩阵不能消除这个局限，但它能够系统性地扩展测试的覆盖范围，让"我们没想到的失败"发生在发布之前，而不是发布之后。
在软件工程有一句经典名言：没有被测试过的代码，是已知有缺陷的代码。在智能体工程里，这句话可以被扩展：没有经过三层评测的智能体，是已知在边缘和对抗场景下质量未知的智能体。
T1理论来源与学术引证
以下为本框架的理论基础说明，提炼自正文中的理论注释块。
本框架创新：将软件测试的边界值分析和安全领域的红队对抗测试，系统性地引入智能体评测设计，构建三层递进的评测矩阵；提出"缺少任何一层，质量画像都不完整"作为评测完整性的强制要求。
T2框架定位与适用边界
本框架是管理实践工具，为高管和研究者提供结构化分析视角，不提供可直接验证的因果预测。其有效性依赖于：分析者对所在行业的深度认知、可获取的组织数据质量、以及将分析结论与具体决策场景相结合的能力。
智能体时代的框架有一个共同的时效性问题——AI 技术演化速度快于传统战略框架的更新周期。建议每 12–18 个月对本框架的核心假设进行一次复盘，检视其前提条件是否仍然成立。