AI Agent 评估本身就是产品的一部分

团队构建了一个 agent，给它几个测试聊天中的代表性提问，然后观察它产生有用的回答。有人试了一个稍微难一点的 prompt，那也行得通。团队录了个 demo，审批了这次变更，然后上线了。

然后检索配置变了。几周后模型升级跟进。agent 仍然能回答原来的问题，但现在它在某个任务上漏掉了一个必需的引用，在另一个任务上选了一个非预期的客户查询工具。这个问题可能直到用户反馈或监控暴露它之前都不会被发现。

一个好的演示告诉你一个 agent 在你当时给出的条件下工作过一次。它不能完全确定下一个版本是否会始终如一地保持你的用户和运维人员需要的行为。为此，评估必须成为交付流程的一部分。

“如果不能复现一次运行或高风险工作流中的实质性回归，这个产品就没有准备好通过发布关卡。”

一个可重复的评估系统沿着产品的执行路径运行固定场景，并记录足够的证据来确定是否应该继续发布。它应该对组装上下文的代码、agent 可以调用的工具以及运行时执行的权限进行测试。如果不能复现一次运行或高风险工作流中的实质性回归，这个产品就没有准备好通过发布关卡。

编写测试前先定义正确行为

"答案是不错"不是任何人能重复测试的需求。在选择评估工具之前，先写下 agent 执行的各个任务、每个任务的边界，以及超出产品可接受运营范围的结果。

对于一个支持 agent，一个有用的任务可能是使用正确账户的记录回答一个计费问题，并引用当前生效的策略。它的限制可能禁止更改计划或暴露另一个客户的数据。当找不到策略时，agent 应该承认这个缺口，避免将不支持的答案作为事实呈现。agent 可能还需要在继续之前请求账户号码，或者将异常转给具有相应访问权限的人。

将结果与产生它的过程分开。一个 agent 可能在检索了错误文档后给出正确答案，或者在调用了不必要的工具或搜索了客户范围之外的内容后完成任务。它甚至可能将本应自己处理的常规请求升级。在 transcript 中这些运行可能看起来是成功的，但实际上掩盖了在不同请求下可能暴露的弱点。

从每个任务的几个可观察需求开始。必要的事实必须由命名的来源支持，写操作必须等待确认。当数据缺失时，agent 应该询问而不是猜测。高风险规则使用精确断言；这些规则的措辞可以容忍一些变化。

从真实用户工作中构建场景

第一个测试集应该小到足以让某个人维护。十项真实任务比一个充满你的用户永远不会发送的 prompt 的大型基准测试更有价值。

"十项真实任务比一个充满你的用户永远不会发送的 prompt 的大型基准测试更有价值。"

工单和工作流日志是很好的原材料。事件报告和与用户的对话也是。包括构成大部分工作负载的常规请求，然后添加指令不明确或账户数据缺失的案例。测试当文档过时或工具超时时会发生什么。一些场景应该在 agent 行动前需要审批，还有几个应该覆盖不常见但仍然完全有效的请求。

Agent 跨多轮运行，因此一些场景也应该如此。先请求一个账户变更，在下一条消息中提供缺失的标识符，然后在第三条消息中确认提议的变更。测试应该验证 agent 在各轮之间携带了账户标识符和提议的变更，而不会将无关细节带入最终操作。

每个场景也需要固件（fixtures）。冻结运行期间使用的文档和工具响应，并将账户状态固定到一个已知的快照。策略版本和 agent 的权限同样重要。一个你无法复现的失败会成为关于 agent 可能看到了什么的争论。固定的固件将其转化为一个工程问题。

生产失败应该被视为永久的回归案例。随着时间推移，测试套件记录了团队已经付出代价并从中学习的错误。

测试整个执行路径

最终答案评分遗漏了区分 agent 和聊天机器人的大部分内容。Agent 检索数据并选择调用哪些工具。它提供参数，读取结果，然后决定是否继续。即使响应看起来令人信服，那个循环中的任何步骤都可能偏离预期路径。

捕获请求和系统指令。记录确切的模型和应用程序构建版本。对 prompt 和检索配置进行版本管理，包括工具模式。然后记录每个检索到的来源及其版本，以及每次工具调用、其参数及其结果。权限检查和最终响应也属于 trace，同样还有延迟、token 使用量和成本。Trace 应该能回答实际问题，而不需要某人从无关日志中重建运行过程。

"最终答案评分遗漏了区分 agent 和聊天机器人的大部分内容。即使响应看起来令人信服，那个循环中的任何步骤都可能偏离预期路径。"

当与服务器端 enforcement 和审计记录结合时，trace 应该显示搜索保持在正确的租户和客户账户范围内。它还应该识别审批的策略来源和答案中引用的记录。对于写操作，它应该显示用户确认了更改，并且服务器端权限检查通过。这些是可确定性检查：它们要么发生了，要么没有。

清晰度和有用性不太容易确定。人工审核员或基于模型的评估器可以对响应是否回答了请求、解释了限制或提出了合理的后续问题进行评分。将这些判断附加到 trace 上。当分数下降时，团队应该能够找到发生变化的步骤。

这也使得评估器的失败更容易被发现。基于模型的评估器在升级后可能产生不同的判断，或者对修订后的评分标准做出不同反应。将评估器的版本和指令与其结果一起保存。定期将样本分数与人工审核进行比较。

两列都以一个令人信服的答案结尾。只有其中一列能告诉你 agent 是否被正确地 grounded。

将固定规则与可变分数分开

Agent 质量不适合用一个未作解释的数字来表达。将任务完成度和事实支持与检索质量分开跟踪。将策略合规性与用户体验、延迟和成本区分开来。

其中一些信号有容差：响应时间延长 200 毫秒可能仍然可以接受，稍微长一点的答案甚至可能更清晰。其他的则不允许任何失败。未经审批的更新、跨租户检索或缺失审批应该仍然是发布阻塞条件，无论其他分数如何。

在相同场景和固件上将候选版本与已知基线进行比较。向审核员展示变更后的答案及其背后的记录，然后让工具路径和各个分数来解释原因。如果新版本完成了更多任务但延迟翻倍，这可能是一个合理的产品决策。如果它在绕过一个权限关卡的同时提高了平均分数，则不是。

当行为不稳定时重复场景。一个任务如果不一致地成功——例如，十次尝试中成功一次——还没有达到可靠的发布阈值。根据风险设置阈值，并为系统每次必须遵守的规则保留绝对关卡。

所有这些都不需要从零开始构建自己的工具。Promptfoo、DeepEval、LangSmith 和 Braintrust 等工具提供了构建评估工作流的能力。根据工具的不同，这种支持可以包括运行场景和捕获 trace。其中一些还使用模型对结果进行评分。

指标词汇也值得学习。从概念上讲，pass@k 问的是 k 次尝试中是否至少有一次成功，而 pass^k 问的是 k 次尝试是否全部成功。当一致的行为很重要时 pass^k 很有用，但它不能替代 agent 必须遵守的规则的精确关卡。

评估也有成本。每次调用模型的实时端到端运行都会消耗 token。Judge 模型的成本比字符串检查更高，在每次提交上运行大型套件会很快累积。将昂贵的判断留给真正有风险的场景。

让评估成为发布关卡

每当团队更改模型或 prompt 时运行套件。新的检索配置算在内，内存策略或工具接口的任何更改也算。在普通更改时使用快速集，在重大发布或模型迁移前使用更广泛的套件。当行为变更是有意为之时，要求审核员审批新的预期而不是重写测试。

这个流程背后的记录需要与 agent 本身相同的控制，因为评估输入可能包含客户数据。Trace 可能包含检索到的文本和内部指令。它们还可能捕获包含凭据或个人数据的工具参数。仔细对记录进行版本管理和访问范围控制。在持久化之前考虑对敏感值进行脱敏，并根据涉及的数据应用适当的加密、访问控制和保留策略。

在这类工作更接近运营数据的地方保持更多工作可以缩短路径。Oracle AI Vector Search 将向量嵌入存储在业务数据旁边，SQL 查询可以将相似性搜索与关系过滤和词法搜索结合起来。使用 Oracle AI Database 的团队可以在他们已经控制的数据平台中保留运营记录及其向量。

同一平台可以保存评估 trace 并强制执行访问规则。数据库强制的访问控制可以在数据库内应用行级和列级策略，为强制数据访问边界提供另一层保护。确切的平台不那么重要，不变式才是：团队需要持久的评估案例、每次运行使用的输入，以及每个构建为何通过的记录。

发布关卡应该阻止具有已知高风险条件的发布，同时认识到有些判断需要上下文。精确检查阻止权限和策略回归。阈值捕获可衡量的质量下降，人工审核处理分数无法解决的模糊更改。

硬规则在任何失败时阻塞；其他一切都有容差或审核员。

从十个案例开始，保留每个重要失败

这周挑选十个真实任务。记录预期结果和 agent 应该使用的证据。记下它不能采取的行动。冻结固件，捕获 trace，在下次发布前运行这些案例。

"当团队能够重放发生的事情并表明下一个发布仍然尊重用户依赖的边界时，对 agent 的信任就会增长。"

当事件发生时，将其添加到套件中。当用户发现一个没有人预测到的失败时，保留它。套件将随产品一起成长。

当团队能够重放发生的事情并表明下一个发布仍然尊重用户依赖的边界时，对 agent 的信任就会增长。评估系统是所交付产品的一部分。

需要帮助进行 agent 评估吗？Oracle AI Database 中这些模式的实际示例，包括带有混合搜索的 agentic RAG 模式，可在 Oracle 的 AI Developer Hub 中找到。