你的 CI 通过了，但你的 Agent 尚未达到交付标准

我们在上个季度向一家企业客户交付了一个文档 Agent。

我们的测试套件显示通过率为 94%。

在试点运行三周后，该 Agent 开始为它无法读取的发票进行退款。它是静默执行的。没有错误，也没有日志。Agent 只是给出了看起来正确的错误答案。

我们的 CI 一直显示为绿色（通过状态）。

问题不在于模型或提示词（prompt）。问题在于我们没有测试的那 6% 的数据。那 6% 是操作员提供的第一批真实数据。

这不是边缘情况（edge case）。这就是“达到交付标准（operator-ready）”的定义。

“生产就绪（Production-ready）”关乎基础设施。它意味着你的服务能够保持运行并处理负载。

“交付就绪（Operator-ready）”则完全不同。它意味着你的 Agent 能为那些并非开发者的人工作。它能处理你未曾设计过的数据。它做出的决策会产生真实的后果。

大多数测试流水线衡量的都是你创建的数据集上的通过率。它们无法衡量当真实数据与你的测试集不同时会发生什么。

一个验证成功率为 97% 的模型听起来很不错。但请看看那失败的 3%。

如果你的 Agent 在重试期间用默认值填充缺失字段，那么你构建的是一台“静默错误机器”。Schema（模式）校验通过了，但数据是错误的。

要解决这个问题，需要将 Schema 有效性与内容置信度分开。

我们为每个响应都增加了置信度分数。现在，低置信度会触发人工审核，而不是重试。这一改动在我们最初的 18 起事故中抓住了 14 起。

你的测试集涵盖了你预想到的情况。而操作员的数据涵盖了你遗漏的情况。

在我们的案例中，我们测试的是单页发票。而操作员使用的是带有扫描 PDF 的多页发票。Agent 在这种新格式上失败了。

不要只是修复解析器。在正式上线前，请针对操作员的实际数据进行测试。

在任何交付之前，我们现在要求使用来自操作员自身数据的 50 份文档。我们不使用合成数据（synthetic data），我们使用他们的。

你还需要完整的审计追踪（audit trail）。不要只记录模型返回了什么，还要记录模型决定“不做什么”。

最基本的审计追踪需要：

  • 带有字段级置信度分数的输出
  • 显示 Agent 是否进行了重试的降级指示器（fallback indicator）
  • 用于重放精确文档的输入哈希（input hash）
  • 所使用的具体模型和提示词版本

在将 Agent 交给操作员之前，请检查以下五件事：

  • 使用操作员实际数据的 50 多个样本进行测试。
  • 在日志中搜索那些通过了 Schema 检查但导致下游错误的输出。
  • 输入畸形数据，以确保 Agent 能安全地失败（fails safely）。
  • 确保你能在 5 分钟内查明针对特定文档发生了什么。
  • 检查 Agent 是否拥有尽可能低的权限。

我们的测试通过率是 94%。我们第一个月的错误率是 8%。

在我们增加了置信度分数、真实场景测试和更好的日志记录后，错误率降至 1.4%。

测试分数不是问题，测试范围才是。

Source: https://dev.to/ethanwritesai/our-ci-passed-your-agent-isnt-operator-ready-2mfn

Optional learning community: https://t.me/GyaanSetuAi