\n\n本文强调AI Agent评估应作为产品交付的核心环节。通过建立可重复的场景测试、记录完整执行路径及trace数据，团队可量化评估Agent在权限控制、逻辑遵循及准确性方面的表现，从而构建起可靠的发布门禁。
译自：AI agent evaluations are part of the product
作者：Jeremy Daly
一个团队构建了一个Agent，在测试对话中给它几个有代表性的问题，并看着它生成有用的答案。有人尝试了一个稍微难一点的提示词（prompt），结果也奏效了。团队录制了一个演示视频，批准了这次变更，并将其发布了。
然后，检索配置发生了变化。几周后进行了模型升级。Agent仍然可以回答最初的问题，但在一个任务中跳过了必要的引用，在另一个任务中选择了非预期的客户查找工具。这个问题可能直到用户反馈或监控显示出来时才会被发现。
一个好的演示只能说明Agent在特定的测试条件下成功过一次。它并不能完全确定下一个版本是否能持续保持用户和运营人员所需要的行为。为此，评估必须成为交付过程的一部分。
“如果它不能重现运行过程或高风险工作流中的重大回归，那么该产品就不具备通过发布门禁的条件。”
一个可重复的评估系统会在产品的执行路径上运行固定的场景，并记录足够的证据来决定是否应该继续发布。它应该检查组装上下文的代码、Agent可以调用的工具，以及运行时强制执行的权限。如果它不能重现运行过程或高风险工作流中的重大回归，那么该产品就不具备通过发布门禁的条件。
在编写测试之前定义正确的行为
“答案很好”并不是一个任何人可以测试两次的需求。在选择评估工具之前，写下Agent执行的工作、每项工作的限制范围，以及落在产品可接受运行边界之外的结果。
对于一个支持型Agent，一项有用的工作可能是使用正确账户的记录来回答账单问题，并引用当前生效的政策。其限制可能禁止更改计划或暴露其他客户的数据。当找不到相关政策时，Agent应该承认这一缺口，并避免将不支持的答案呈现为事实。该Agent在继续之前可能还需要请求账号，或者将异常情况转给具有适当访问权限的人。
将结果与产生结果的过程分离。Agent可以在检索到错误的文档后给出正确的答案，或者在调用不必要的工具或在客户范围之外进行搜索后完成任务。它甚至可能升级一个本应自行处理的常规请求。这些运行在转录中看起来可能很成功，但却掩盖了在不同请求下可能出现的弱点。
从每项工作的几个可观测需求开始。必要的事实必须有指定的来源支持，写入操作必须等待确认。当数据缺失时，Agent应该询问而不是猜测。高风险规则需要精确的断言；其措辞可以容忍一些变化。
基于真实用户工作构建场景
第一组测试集应该足够小，以便维护。十个真实任务比一个充满用户从不发送的提示词的大型基准测试更有价值。
“十个真实任务比一个充满用户从不发送的提示词的大型基准测试更有价值。”
支持工单和工作流日志是很好的原始材料。事件报告和与用户的对话也是如此。包含构成大部分工作负载的普通请求，然后添加指令不清或缺少账户数据的案例。测试当文档过时或工具超时时会发生什么。有些场景需要先获得批准，Agent才能采取行动，还有一些应该涵盖不寻常但仍然完全有效的请求。
Agent在多轮对话中运行，因此某些场景也应该这样。请求账户更改，在下一条消息中提供缺失的标识符，并在第三条消息中确认拟议的更改。测试应该验证Agent在多轮对话中携带了账户标识符和拟议的更改，而不会将不相关的细节拖入最终操作。
每个场景也需要固件（fixture）。冻结运行期间使用的文档和工具响应，并将账户状态固定在一个已知的快照上。政策版本和Agent的权限也同样重要。你无法重现的失败会变成关于Agent可能看到了什么的争论。固定的固件将其变成了一个工程问题。
生产环境中的失败应被视为永久的回归案例。随着时间的推移，测试套件记录了团队已经为此付出代价并从中吸取的教训。
测试完整的执行路径
最终答案评分错过了许多将Agent与聊天机器人区分开来的东西。Agent检索数据并选择调用哪些工具。它提供参数，读取结果，然后决定是否继续。即使响应看起来令人信服，循环中的任何步骤都可能偏离预期的路径。
捕获请求和系统指令。记录确切的模型和应用程序构建。对提示词和检索配置进行版本控制，包括工具模式。然后记录每个检索到的源及其版本，以及每个工具调用、其参数及其结果。权限检查和最终响应也属于跟踪范围，延迟、Token使用量和成本也是如此。跟踪数据应该回答实际问题，而不需要有人从不相关的日志中重建运行过程。
“最终答案评分错过了许多将Agent与聊天机器人区分开来的东西。即使响应看起来令人信服，循环中的任何步骤都可能偏离预期的路径。”
当结合服务端强制执行和审计记录时，跟踪数据应该显示搜索仍然在正确的租户和客户账户内。它还应该识别批准的政策来源和答案中引用的记录。对于写入操作，它应该显示用户确认了更改，并且服务端权限检查通过。这些是确定性的检查：它们要么发生了，要么没发生。
清晰度和有用性是不太确定性的。人工审核员或基于模型的评估器可以对响应是否回答了请求、解释了限制或提出了合理的后续问题进行评分。将这些判断附在跟踪数据上。当分数下降时，团队应该能够找到发生变化的步骤。
这也使得评估器失败更容易被发现。基于模型的评估器在升级后或对修订后的准则做出不同响应后，可能会产生不同的判断。保存评估器的版本和指令及其结果。定期将这些分数的样本与人工审核进行比较。
两列最终都得到了令人信服的答案。只有其中一列能告诉你Agent是否正确地基于事实。
将固定规则与可变分数分开
Agent质量并不适合用一个无法解释的数字来衡量。将任务完成情况和事实支持与检索质量分开跟踪。将政策合规性与用户体验、延迟和成本区分开来。
其中一些信号具有容差：多花200毫秒的响应可能仍然可以接受，稍长的答案甚至可能更清晰。其他的则不允许有任何失败。未经批准的更新、跨租户检索或缺少批准应该仍然是发布阻碍条件，无论其他分数如何。
在相同的场景和固件上比较候选版本与已知基准。向审核员展示更改后的答案和背后的记录，然后让工具路径和个人分数来解释原因。如果新版本完成了更多任务但延迟翻倍，这可能是一个合理的决策。如果它提高了平均分数但绕过了一个权限门禁，则不然。
当行为不稳定时，重复场景。一个不稳定成功的任务（例如，十次尝试中只有一次成功）尚未达到可靠的发布阈值。根据风险设定阈值，并为系统必须每次都遵守的规则保留绝对门禁。
所有这些都不需要从头开始构建自己的工具。诸如 Promptfoo, DeepEval, LangSmith, 和 Braintrust 等工具提供了构建评估工作流的功能。根据工具的不同，这种支持可以包括运行场景和捕获跟踪数据。有些还使用模型来给结果打分。
指标词汇表也值得学习。从概念上讲，pass@k 询问k次尝试中是否至少有一次成功，而 pass^k 询问是否所有k次尝试都成功。当一致的行为很重要时，Pass^k 很有用，但它不能取代Agent必须遵守的规则的精确门禁。
评估也有成本。每一次调用模型的实时、端到端运行都会消耗Token。评判模型比字符串检查成本更高，并且在每次提交时运行大型套件会迅速增加成本。为真正存在风险的场景保留昂贵的判断。
将评估作为发布门禁
只要团队更改了模型或提示词，就运行测试套件。新的检索配置算作变更，对内存策略或工具接口的任何更改也算作变更。对普通更改使用快速测试集，并在重大发布或模型迁移之前使用更广泛的测试集。当行为变更是故意的时，要求审核员批准新的预期，而不是重写测试。
这个过程背后的记录需要与Agent本身相同的控制，因为评估输入可能包含客户数据。跟踪数据可以包括检索到的文本和内部指令。它们可能还捕获包含凭据或个人数据的工具参数。对记录进行版本控制并仔细限定访问权限。考虑在持久化之前对敏感值进行脱敏，并根据所涉及的数据应用适当的加密、访问控制和保留策略。
将更多此类工作保持在操作数据附近可以缩短路径。Oracle AI Vector Search 将向量嵌入与业务数据存储在一起，SQL查询可以将相似性搜索与关系过滤和词法搜索结合起来。使用 Oracle AI Database 的团队可以将操作记录及其向量保留在他们已经控制的数据平台中。
同一个平台可以保存评估跟踪数据并强制执行访问规则。数据库强制执行的访问控制可以在数据库内应用行级和列级策略，为强制执行数据访问边界提供另一层保障。确切的平台并不重要，重要的是不变性：团队需要持久的评估案例、每次运行使用的输入，以及每次构建通过原因的记录。
发布门禁应该阻止具有已知高风险条件的发布，同时承认某些判断需要背景。精确检查会阻止权限和政策回归。阈值会捕获可衡量的质量下降，而人工审核则处理分数无法解决的模糊变化。
硬规则会阻止任何失败；其他一切情况都有容差或由审核员处理。
从十个案例开始，并保留每一个重要的失败
本周挑选十个真实的任务。记录预期的结果和Agent应该使用的证据。注意它绝不能采取的行动。冻结固件，捕获跟踪数据，并在下一次发布前运行这些案例。
“当团队能够重放发生的情况并表明下一次发布仍然尊重用户所依赖的边界时，对Agent的信任就会增长。”
当发生事件时，将其添加到套件中。当用户发现一个无人预测的失败时，保留它。测试套件将随着产品的增长而增长。
当团队能够重放发生的情况并表明下一次发布仍然尊重用户所依赖的边界时，对Agent的信任就会增长。评估系统是所发布产品的一部分。
***需要Agent评估方面的帮助？在 Oracle’s AI Developer Hub 中可以找到这些模式的有效示例，包括带有混合搜索的Agentic RAG模式。***全 端 工智能
