通过结果测试AI智能体：验证状态而非依赖回复
学会通过检查最终状态、动作轨迹及真实性来评估使用工具的AI智能体，包括超时情况、无动作场景以及重复试验的可靠性。
来源: Your AI Agent Says “Done.” Did Anything Actually Happen?
当人工智能代理回复“已完成”时，这句话只是一种声明，并非确认凭证。仅查看最终消息的评估系统很可能会将这种虚假的成功判定为合格结果。本指南介绍了如何通过实际世界中的变化来测试工具使用型代理：如何定义任务完成标准、应检查哪些证据、如何处理超时情况以及代理无需采取行动的情形，还有如何衡量其可靠性而非仅凭一次侥幸的演示。
自信的回复并非证据
以向日程安排助手提出的一个简单请求为例：将会议改到周四下午。助手礼貌且毫不犹豫地回答说会议时间已经是下午3点。但当你打开日历后，发现该事件仍位于原来的位置。
其他可能性也同样存在：该事件可能转移到了其他时区的下午3点，或者出现了全新的事件而原事件依然存在，这样用户就会面对两个事件。这个例子是虚构的，但测试中确实存在这样的问题：如果仅根据智能体生成的文本来评分，那么这三种失败情况看起来都会与成功情况无异。
有用的思维方式是这样理解：对智能体而言，答案是对工作情况的报告，而报告也有可能出错。模型所处的整体系统，也就是其框架，决定了它是否能够可靠地运行（我们将在可靠智能体行为究竟源自何处一文中探讨这一层面）。评估则是用来确认该系统是否真正完成了任务的步骤。
先制定验收标准
“移动我的会议”听起来很简单，直到你试图为它制定验收标准时才会发现困难。
以当前的示例而言，假设用户已选定一个活动，指定了日期和时区，并授权进行更新。所需的结果并非仅仅是下午3点存在某个会议，而是该活动确实从指定时间开始，保持原有的时长和参会者列表，且其他活动不受影响。如果请求表述模糊或助手没有相应权限，正确的做法是询问用户，而非自行猜测。
那些规则适用于这款假设中的产品。其他产品可能会发送通知、要求明确批准，或以不同方式处理参与者。重要的是要将相关条款写入合同。如果没有合同，一位评审者会称赞助手主动作为，而另一位则会将同一操作视为未经授权的更改，这样一来评分就会变得毫无意义。
因此，每个评估案例都应明确说明：
- 环境的初始状态；
- 用户的需求；
- 智能体被允许采取的行动；
- 操作完成后必须满足的条件；以及
- 必须保持不变的内容。
最后一点很容易被忽略。一个好的测试会同时明确目标及其边界。
同一次运行的三种视角
每次智能体的运行都可以从三个角度进行审视，每个角度能发现不同的问题。
- 输出：用户看到的消息。它是否准确且有用，是如实反映未完成的工作还是试图掩盖问题？
- 执行过程：可观察到的工具调用、工具结果、审批、重试和检查的序列。智能体是否选择了正确的操作，是否在权限范围内行事，以及在工具出错时是否做出了合理的反应？
- 最终结果：尝试结束后日历的实际状态。
Anthropic的智能体评估指南同样将对话记录与环境最终状态区分开来，并提醒不要用固定的步骤序列来评判每一个有效解。这种平衡值得采用——应观察智能体的行为表现，但除非操作顺序确实属于约定要求，否则不必坚持自己的首选路径。
具体而言，两个智能体可能通过不同的操作方式查看日历，但最终得到相同的正确结果；两者都应通过评估。而跳过必要的审批步骤，则即便日历最终显示正确也会被视为失败。结果决定了任务是否成功，规则边界决定了该操作是否被允许，而过程记录则解释了两者之间的差异。
通过独立渠道检查世界状态
为验证日历测试，需通过与代理自身回复无关的授权接口来读取存储的事件。代理不得给自己打分。
将实际定义正确性的字段与预期状态进行对比：
- 稳定的事件标识符；
- 开始时间、结束时间以及时区；
- 参与者列表；
- 应保持不变的相邻事件。
避免依据事件标题进行匹配。两个会议可以使用相同的名称，而仅凭标题匹配很可能会误判。
这一理念早于如今的智能体框架出现。τ-bench通过将最终数据库状态与标注的目标状态进行比较来评估工具使用类对话，而WebArena则衡量任务在真实的网页环境中是否在功能上得到完成。二者都是以评估实际发生的情况而非仅凭对话内容来打分的科研示例。
了解成功信号真正的含义
成功的API响应虽是有力的证据，但前提是你必须明白它究竟能保证什么。“已接受”可能仅表示请求已被排队，而非实际已被处理。浏览器中的成功提示也可能在相关记录被真正存储之前就出现。
对于异步系统，需提前确定验证器应等待多久以及何种状态才算已解决。如果完全无法观测到该状态，则将结果记录为未验证。既不要擅自将其视为通过，也不要假设其失败。一旦请求开始超时，第三类状态就变得至关重要。
最艰难的时刻：超时之后
超时并不能说明更新是否已成功送达。请求可能在到达日历服务之前就失败了，也可能已经成功，只是返回的响应在传输过程中丢失了。
如果代理通过创建新的替代会议来应对，可能会给用户留下两个事件。因此，恢复机制属于首要的测试案例。合理的恢复流程如下：
- 再次读取目标事件。
如果之后仍无法确定结果，正确的做法可能是暂停并向用户说明不确定性。清晰的沟通胜过虚假的成功。这种模式在普通后端设计中也很常见；有关服务器端的详细内容，请参阅Node.js POST端点的幂等性键。
既要评估状态，也要评估表述。“我无法确认更新情况”这一说法是真实的，即便服务在片刻之后就应用了该更改。“没有任何变化”在完全相同的情境下则属于毫无依据的宣称。不确定性是客服人员必须妥善处理的正常结果，而非他们应当用确定性来填补的空缺。
将评分标准与问题匹配
不同的问题需要不同的评判标准。
- 针对确切事实的确定性代码：标识符、时间戳、允许的更改范围、重复事件的计数。
- 针对沟通质量的基于模型的评分标准及明确细则：助手是否区分了已完成的工作与尝试中的工作，以及是否在描述后续步骤时没有编造细节？
LangSmith的评估文档将代码规则、人工审核和基于模型的判断视为不同的选项。即便不使用该平台，将它们分开处理也能带来好处。
有一种反模式值得特别提及：将智能体给出的确定答案交给另一个模型，询问该任务是否成功。判断模型会被同样的确定性所误导。相反，应向判断模型提供问题实际所需的证据，让其能够给出“证据不足”的答复。
应将严重故障与质量评分分开。不得用友善的语气或精炼的措辞来掩盖未经授权的日历修改行为。简洁的评分表效果很好：结果正确、边界得到尊重、报告真实、恢复措施得当。应在评分表旁标注处理延迟和成本，而非将所有信息合并为一个难以理解的数字。
需包含“无需采取任何行动”这一正确答案的情况
日历助手的合理初始测试案例应包括：
- 正常的日程重新安排；
- 两个标题相同的事件；
- 未指定时区的请求；
- 被拒绝的权限申请；
- 日历服务超时；
- 在代理程序运行前已应用的更新；
- 仅请求起草变更方案而不实际执行的操作。
最后一个案例能保护你免受隐性偏差的影响。如果每次测试都奖励那些进行外部更改的操作，最终选出的代理就会表现得过于急切。
在隔离的测试账户或受控环境中运行会改变状态的测试，并在每次独立尝试之间重置测试环境。上一次运行留下的痕迹绝不能让下一次运行显得成功。
这份清单只是一个起点，并非具有足够统计意义的样本。应根据用户实际的需求、真正的风险所在以及实践中出现的故障来进一步扩展它。从打算重复使用的测试环境中删除个人数据，并限制能够查看包含隐私数据的日志的人选。
衡量一致性，而非最佳演示效果
每个测试案例都要运行多次，并记录每一次尝试的情况，包括超时以及验证失败的运行结果。
τ-bench引入了重复试验指标pass^k，该指标关注的是智能体是否在k次尝试中全部成功，而非至少成功一次。其公布的模型评分属于历史数据，不应被视为对当前智能体的排名，但这一经验依然重要：“能够成功”与“稳定成功”是不同的属性，仅一次成功的尝试只能说明前者。
初始的产品控制面板可以追踪以下内容：
- 有效完成率；
- 未经授权的操作次数；
- 不成立的成功声明数量；
- 适当的升级处理情况；
- 延迟时间；
- 每次有效完成所需的成本。
必须明确分母的含义。您统计的是用户请求次数、独立尝试次数还是单独的重试次数？同样的数据因选择不同而会产生截然不同的比率。
一起阅读这些数据。如果某种改进虽然提升了完成率，却同时增加了未经授权的操作，那并不能算真正的胜利。同样，那些通过拒绝所有有用任务来规避一切风险的智能体也不可取。应对具有相同预算的同一案例的不同版本进行比较，并公布你运行了多少案例以及各次运行结果之间的差异程度。如此少量的试验远远不足以得出精确的生产可靠性数据。
将每一次失败都转化为回归测试
当某个案例失败时，首先要弄清楚究竟出了什么问题：是智能体、工具、环境还是评分系统的问题。失败的测试并不能证明模型本身存在缺陷。
接着要找到一个最简的可复现案例，并锁定所有可能影响它的要素：任务内容、预期状态、评分工具、模型配置、指令以及工具接口规范。一旦这些要素中的任何一项发生变化，就需要重新运行受影响的案例。锁定预期状态与锁定模型同样重要；我们在关于LLM评估系统中版本锁定的文章中对此进行了更深入的探讨。
离线测试与实时监控解决的是不同的问题。经过筛选的预发布版本评估能告诉你某个变更是否安全可上线；而对实际使用场景的评估则能揭示现场出现的问题。LangSmith的文档对这两种方法都有说明，并建议将生产环境中的故障反馈到测试集中。
对于日历助手而言，这样的循环可能从用户报告的重复事件开始，将未收到回复的情况加入处理流程，并在更广泛推广之前确认修复方案有效。
关键要点
- 将“已完成”视为需要验证的声明，而非确凿证据。
- 根据具体场景编写契约：初始状态、请求内容、允许的操作、要求的最终状态以及不可更改的要素。
- 对结果进行评级，严格执行边界限制，并利用追踪信息解释差异。
- 通过独立的授权读取路径进行验证，将“未验证”视为真实结果。
- 明确测试超时、重复事件以及无操作情况；这些正是可靠智能体容易出错的地方。
- 避免将严重故障计入平均质量评分，同时衡量重复尝试的可靠性。