AI 智能体评估：上线前的验收测试

AI 智能体评估应确定助手是否完成了约定业务任务，而不只是最终消息是否听起来可信。如果智能体声称更新了客户记录，验收证据既应存在于对话中，也应存在于目标系统中。

用代表性任务、明确验收规则和独立核实的结果评估 AI 智能体。除成功案例外，也纳入拒绝、不确定性、中断和人工交接。将发布决策与经过测试的流程和版本绑定，而不是依赖单一综合分数。

考虑一个准备变更送货地址的助手。有用的演示可能在聊天窗口展示正确地址。有用的评估则要明确哪个订单被更改、谁授权了变更、配送是否已经锁定，以及目标系统响应不确定时发生了什么。这是不同的问题。

下文示例是评估设计建议，并非客户成果或已发表的基准测试。它们帮助业务负责人在允许智能体执行更多工作前，委托获取证据。

定义 AI 智能体评估的结果

从运营同事能理解的任务开始。描述初始状态、允许操作和可接受的结束状态。对于地址变更示例，验收可能要求符合条件的订单、已验证的拟议地址、批准，以及订单系统中的匹配记录。

Anthropic 对智能体评估的解释 区分了对话轨迹与环境的最终状态。即使实施使用其他供应商，这一区分也有用。流畅的成功描述是关于响应的证据，而不是业务结果的独立证明。

不要要求每次有效执行都使用完全相同的措辞或单一工具顺序。不同路径可能产生可接受结果。应区分必须遵守的约束和可变化的实施细节。即使最终回答很友好，禁止的记录变更也应使测试失败。

为有争议的案例指定负责人。如果销售、财务和运营对正确结果意见不同，自动评估器无法替他们解决业务政策。在将案例作为发布门槛前，把分歧记录为未解决的要求。

构建代表性案例集

从实际流程收集示例，然后移除不必要的个人信息。纳入常规请求、合法但棘手的值，以及系统应要求澄清的情况。避免整个测试集都是构建智能体的开发者写出的整齐示例。

将此矩阵视为起点，而非通用覆盖承诺。薪资助手、内部研究工具和客户支持智能体需要不同证据。关键是，运行之前每个案例就有预期业务含义。

将探索案例与验收案例分开

探索案例可以发现新故障，即使评分规则尚未确定。这是有价值的学习，但不应悄然改变此前约定的通过定义。保留稳定验收集，并单独维护需要调查或政策决定的案例队列。

保留暴露真实缺陷的案例。缺陷修复后，它就成为回归检查。操作范围扩大时加入新示例，而不是反复重写旧案例来迎合最新输出。

选择每项结果的核查方法

对真正确定的事实使用确定性检查。目标标识符、未变化的受保护字段，或不存在未授权写入，通常可以直接检查。模型评审可以帮助评估解释质量，但不应成为判断资金是否移动或记录是否变化的唯一权威。

记录检查存在的理由。奖励某种特定道歉措辞的字符串匹配，可能拒绝完全有用的答案。接受预期字段名的模式，仍可能接受错误客户。JSON Schema 的对象指南 解释结构验证，业务正确性还需要额外断言。

对于主观回答，要求审核者描述缺陷，而不只是选择分数。响应是否缺乏依据、令人困惑、不完整，或超出用户权限？不同标签使下一次工程变更更容易论证，下一次审核也更容易重复。

控制测试环境和版本

可重复案例需要的不只是保存的提示词。记录智能体实施、相关指令、工具定义、模型配置和初始数据。如果上游记录在两次执行之间变化，结果可能因与智能体变更无关的合理原因而不同。

对会产生业务影响的操作使用受控目标系统。有计划地重置或重建初始状态。第二次对已被首次修改的记录执行，即使自然语言请求完全相同，也是不同测试。

检查不止一次尝试

智能体行为可能在多次尝试间变化。提前决定重复试验如何影响验收，并保留所有结果。只报告最佳执行，会使负责人无法理解不一致性。同样，不要从少量成功示例宣称确定性。

约定实用的评估预算。一些案例可在工具契约变更时运行，其他案例则需要专家审核者或昂贵集成环境。分层测试套件可以经常提供有限检查，同时在操作范围变化时保留更广泛的发布评估。

让失败和交接成为有用结果

拒绝可能是正确结果。订单不明确时暂停的智能体，可能比完成错误变更的智能体更有用。定义可接受的澄清、升级处理和人工继续方式，避免评估器奖励不计代价的完成。

应像检查已完成操作一样仔细检查交接记录。记录应说明原请求、相关目标引用、未解决问题及负责队列。笼统要求联系支持，可能让同事从头重做调查。

将评估与更广泛的安全评估分开。OWASP ASVS 为验证应用安全要求提供基础。我们的 AI 智能体安全指南 讨论权限和恶意输入。流程评估应包含这些边界，但良好的任务完成结果并不是完整安全保证。

决定什么会阻止发布

演示前写出停止条件。跨客户信息泄露或未授权写入，可能无论平均任务完成情况如何，都足以停止发布。令人困惑但可恢复的解释，则可能要求缩小范围或开展受监控试点。严重程度来自业务影响。

除整体结果外，也按案例类别报告。大部分示例都是常规查询时，强综合成绩可能掩盖薄弱的恢复行为。任何汇总分数旁都应说明测试案例的数量和性质、未解决失败、审核分歧及已知排除项。

验收应适用于具体范围和版本。通过只读订单问题，不能证明已准备好修改订单。新增目标系统、用户组或写入工具会改变操作边界，应触发对案例集的有计划审查。

保留其他团队成员能够理解的发布记录。说明测试了什么、什么失败、做了什么变更，以及负责人为何接受剩余限制。原评估者不在时，缺乏解释的绿色仪表板无法提供良好交接。

为证据和持续维护编制预算

要求以 GBP 计价、范围明确的测试设计、受控环境、实施、审核和报告方案。将初始工作与重复评估执行、业务规则变化后的案例维护分开。不知道流程，就无法给出有依据的通用评估单价。

有用的首次投资通常是能捕获高成本错误类别的小型套件。其价值来自支持的决策，而不是电子表格中提示词的数量。避免购买无人能关联到日常运营的大型合成基准测试。

委托范围有限的评估试点

准备任务描述、代表性脱敏示例，以及证明完成的目标状态。明确智能体绝不能执行的操作，以及将判断模糊案例的同事。若能妥善处理敏感细节，现有事故示例很有用。

我们的 AI 集成范围明确试点 可从任务及其验收证据开始。初始范围可以在扩大访问前，确定智能体、工具及目标系统是否能够可靠协作。

向我们提供流程和需要作出的发布决策 。要求可重复评估套件、盲点说明和明确交接。交付应帮助你决定，接下来可以安全地信任智能体做什么。

常见问题

什么是 AI 智能体评估？ AI 智能体评估按明确任务和验收规则检查智能体。它检查产生的系统状态、允许操作，以及解释或交接的质量，而不是把可信的最终消息当作完成证明。

基准测试分数足以批准业务智能体吗？ 不够。通用基准可帮助技术比较，但发布验收需要反映你的记录、权限、故障模式和业务规则的案例。应报告经过测试的范围和未解决限制。

需要多少测试案例？ 没有通用数量。从拟议流程中的不同结果和重要故障路径开始。当新工具、用户组或政策例外带来实质不同的行为时加入案例。大量近乎相同的提示词，不等于广泛的运营覆盖。

可以让另一个模型为答案评分吗？ 可以，用于适合的审核部分。用有经验的人核查过的示例校准，并对哪个记录被更改等事实保留确定性的目标系统断言。模型判断不应替代业务操作证据。

正确拒绝应算成功吗？ 应该，前提是拒绝是预期结果。定义有用拒绝应说什么，并确认没有发生禁止操作或信息泄露。

需要生产环境客户数据吗？ 通常应从受控示例开始，保留相关结构和棘手情况，同时避免不必要的个人信息。任何真实数据使用都需要明确目的、适当访问权和处理政策。代表性行为比将整个生产数据库复制到评估器中更重要。

评估供应商应交接什么？ 案例集、预期结果、初始状态说明、评分规则、版本记录和故障证据。纳入重复评估所需的命令或流程，以及更新负责人。

什么时候应再次运行套件？ 模型、指令、工具、权限或目标系统行为变化后，重复相关检查。业务任务扩大时审查覆盖范围。此前的验收结果属于此前经过测试的范围。