在生产环境中测试和监控 AI 代理

将人工智能代理部署到生产环境并不是实施的结束，而是传统软件所不存在的操作规则的开始。传统应用程序会确定性地失败：给定相同的输入，您会得到相同（错误）的输出。 AI 代理可能会失败：相同的输入在 97% 的情况下产生正确的输出，在 3% 的情况下产生轻微错误的输出，并且随着模型更新、输入分布变化和业务规则发展，这 3% 的情况会发生变化。

本指南涵盖了在部署之前测试 AI 代理并在生产中持续监控它们的完整操作框架，以及 OpenClaw 实施的特定模式。

要点

• AI代理测试需要功能测试（正确输出）和行为测试（一致推理）
• 模型更新时回归测试至关重要 - 假设行为会发生变化，直到得到其他证明
• 生产监控必须跟踪准确性指标，而不仅仅是可用性和延迟
• 令牌使用和成本监控可防止意外的账单高峰
• 代理输出中的异常检测可在影响业务成果之前捕获准确性下降
• 人工审核抽样为校准自动监控提供了基础事实
• 人工智能代理的事件响应手册与传统软件事件有根本不同
• A/B测试框架可以安全评估即时变更和模型升级

---

为什么 AI 代理测试不同

测试人工智能代理需要与测试传统软件完全不同的思维方式。在传统的软件测试中，您编写测试用例、提供输入并根据预期值验证输出。如果测试始终通过，则软件是正确的。

人工智能代理不是这样工作的。它们的输出是概率性的——它们可能是正确的、略有偏差或完全错误，结果的概率分布取决于模型版本、提供的上下文以及输入的具体措辞。传统测试面临三个挑战：

非确定性： 相同的提示运行两次可以产生不同的输出。测试必须评估一定范围内的输出质量，而不是完全相等。

**模型版本敏感性：**当您的LLM提供商发布新的模型版本时，您的代理的行为可能会以不立即明显的方式发生变化。对您的任务准确率为 94% 的模型可能会提高到 96% 或降低到 91% — 您需要机制来检测这一点。

上下文依赖性： 代理行为在很大程度上取决于所提供的上下文（检索的文档、对话历史记录、系统指令）。上下文组装的微小变化可能会显着影响输出质量。

---

预生产测试框架

技能单元测试

每个 OpenClaw 技能都应该有一个测试套件，通过具有代表性的输入样本来验证其行为。这些测试不是标准的断言等于测试——它们使用对输出质量进行评分的评估框架。

合同审查的测试结构技能：

class ContractReviewSkillTests:
    def test_identifies_indemnification_clause(self):
        # Provide sample contract containing indemnification clause
        # Assert: clause is identified, page number is correct
        # Assert: risk level is "high" for unlimited indemnification
        # Assert: recommended action is present

    def test_handles_missing_clause(self):
        # Provide contract without limitation of liability clause
        # Assert: missing clause is flagged
        # Assert: recommended action is to add clause

    def test_handles_unusual_clause_language(self):
        # Provide contract with atypical but valid indemnification language
        # Assert: clause is still identified (recall test)
        # Assert: unusual language is flagged for review

每项测试的评估标准：

• 回忆（特工发现那里有什么吗？）
• 精确度（代理是否只标记相关项目？）
• 风险评估的准确性（风险级别是否合适？）
• 建议行动的完整性
• 输出格式合规性（存在必填字段，结构正确）

黄金数据集测试

维护包含 50-200 个代表性输入和经过人工验证的预期输出的黄金数据集。在每次生产部署之前，针对此数据集运行代理并计算准确性指标。准确度低于阈值的部署将被阻止。

黄金数据集构建： 1.从生产流量中收集200个真实输入（必要时匿名） 2. 让领域专家审查并注释每个的正确输出 3. 对数据集进行分层以涵盖边缘情况、异常输入和常见错误模式 4. 根据黄金数据集建立基线准确度指标 5. 将低于基线的任何回归视为部署障碍

黄金数据集的自动评估： 雇用或培训 LLM 作为评估员 - 一个单独的 LLM 调用，它采用代理的输出和人工验证的预期输出并生成相似性/正确性分数。这就是“LLM作为法官”的模式。结合对边缘案例的人工审查，它将黄金数据集评估扩展到频繁运行。

集成测试

在整个系统中端到端测试代理行为，包括集成：

集成测试场景：

• 代理从 ERP 读取、处理数据、写回 — 验证数据完整性
• 代理调用外部API，处理成功和失败响应
• 代理在多代理工作流程中与另一个代理协调
• 代理妥善处理超时、速率限制和 API 不可用
• 代理产生正确触发下游业务流程的输出

模拟故障测试：

• 在外部API调用中注入超时失败
• 提供格式错误或缺失的数据
• 模拟模型提供者不可用
• 当代理无法完成任务时测试优雅降级

---

生产监控架构

AI 代理监控的四大支柱

支柱 1：运营健康（标准软件监控）

• 正常运行时间和可用性
• 每次执行的延迟（P50、P95、P99）
• 错误率（代理崩溃、未处理的异常、API 故障）
• 队列深度和吞吐量
• 资源利用率（CPU、内存、API 并发）

支柱 2：输出质量（特定于 AI 的监控）

• 采样输出的准确率（人类或法学硕士判定）
• 幻觉检测（输出包含不在所提供上下文中的信息）
• 格式合规率（满足所需结构的输出）
• 置信度分数分布（突然表现出较低置信度信号退化的代理）
• 任务完成率（代理成功生成完整输出与返回错误或不完整响应）

支柱 3：业务影响（结果监控）

• 下游行动成功率（成功下订单、正确路由审批等）
• 人类推翻率（人类推翻代理决策的频率）
• 面向客户的代理的客户满意度（CSAT、NPS）
• 异常率（输入升级为人工审核）
• 流程周期时间（端到端任务完成时间）

支柱 4：成本（代币和 API 成本监控）

• 每次执行的令牌消耗（输入+输出）
• 每次成功完成任务的成本
• 异常的令牌使用（执行消耗的令牌明显多于平均信号提示注入或上下文污染）
• 每日/每周成本趋势与预测

可观察性实施

OpenClaw 提供内置的执行跟踪。每次代理运行都会生成结构化跟踪，包括：

• 执行ID和时间戳
• 输入数据（应用了 PII 修订）
• 上下文检索（RAG 块、之前的对话轮次）
• 完整的提示发送给LLM
• 法学硕士回应
• 后处理步骤
• 最终输出
• 代币数量和成本
• 总执行时间
• 任何例外或升级

当代理产生不正确的输出时，此跟踪数据可以启用事后调试。您可以重播确切的执行过程并查看每一步。

微量采样策略：

• 对 100% 高价值交易进行抽样（> $X 货币影响）
• 对 100% 的异常和升级进行抽样
• 对日常交易的 5-10% 进行抽样以进行质量监控
• 为客户报告问题抽取 100% 的输出样本

仪表板设计

有效的人工智能代理监控仪表板传达的信息与传统应用程序仪表板不同。按键面板：

实时操作面板：

• 积极执行
• 队列深度
• 执行率（最后 5 分钟与基线）
• 错误率（最后 5 分钟）
• P95 延迟

质量趋势面板（24小时视图）：

• 准确率趋势（来自抽样评估）
• 人力覆盖率趋势
• 异常/升级率趋势
• 置信度分数分布

成本面板：

• 今天的代币消费与预测
• 每个成功任务的成本（趋势）
• 异常执行（异常代币消耗）
• 每周成本预测

业务成果小组：

• 按工作流类型划分的任务完成率
• 下游成功率
• 客户满意度（如果衡量）
• 处理量（与上一时期相比）

---

漂移检测

最隐蔽的人工智能代理故障模式之一是逐渐漂移——随着输入的分布偏离训练分布，或者随着提供者更新模型，代理的性能随着时间的推移慢慢下降。

输入分布监控

跟踪一段时间内输入数据分布的统计数据。重大转变警报：

• 词汇漂移（出现训练数据中没有的新术语）
• 输入长度分布变化（异常长或短输入）
• 输入中的语言或格式更改
• 文档处理管道中出现新的文档类型

模型版本变更检测

LLM 提供商不断更新他们的模型。有些更新是静默的（相同的型号标识符，不同的权重）。监控：

• 响应长度分布变化
• 格式合规率变化
• 延迟配置文件更改
• 置信度分数分布变化

当这些指标中的任何一个发生显着变化时，请立即运行黄金数据集评估以量化准确性影响。

概念漂移

业务规则和领域知识随着时间的推移而变化。当 2025 年定价规则生效时，接受过应用 2024 年定价规则培训的代理将产生不正确的输出。监控：

• 按原因代码划分的人工覆盖率（因特定原因增加覆盖表明该区域的概念漂移）
• 错误类型分布变化
• 异常升级原因

---

AI 代理的事件响应

人工智能代理事件与传统软件事件不同。失败通常不是崩溃，而是输出质量的下降，从而微妙地影响业务成果。

事件严重级别：

P1 事件响应手册：

1. 检测： 监控系统自动触发警报
2. 评估（5 分钟）： 查看最近的执行情况，识别错误模式
3. 包含（10 分钟）： 切换到手动回退过程，必要时禁用代理
4. 诊断（30-60分钟）： 确定根本原因（模型更改、输入分布偏移、提示回归、集成失败）
5. 修复： 应用修复（提示更新、模型回滚、输入验证更改、集成修复）
6. 验证： 针对固定代理运行黄金数据集评估
7. 恢复： 重新启用代理并在提升的警报状态下进行监控
8. 事后分析： 48 小时内记录 - 失败的原因、原因、如何防止再次发生

---

针对代理改进的 A/B 测试

改进人工智能代理需要在全面部署之前安全地评估更改。 A/B 测试可以实现这一点：

影子模式测试： 在生产流量上运行新的代理版本而不使用其输出 - 将影子输出与当前代理输出进行比较，以在影响客户之前量化差异。

金丝雀部署： 将 5-10% 的生产流量路由到新代理版本。监控金丝雀种群与对照种群的质量指标。如果指标有所改善或保持不变，则前滚；如果指标下降，则回滚。

冠军/挑战者： 当前的生产代理是“冠军”。新的代理版本是“挑战者”。挑战者必须证明黄金数据集在统计上有显着改进，然后才能晋级冠军。

回滚触发器： 定义自动回滚触发器 - 如果金丝雀的准确性下降到阈值以下或人为覆盖率增加到阈值以上，则自动恢复为冠军。

---

常见问题

我们应该在生产中多久运行一次黄金数据集评估？

在每次部署（包括模型版本更改）上运行，每周进行运行状况检查，并在监控检测到异常时立即运行。对于高风险代理（财务决策、医疗文件），每天运行。自动化 CI/CD 管道可以在每次代码更改时自动触发黄金数据集评估。

我们如何检测LLM提供商何时默默更新模型？

监控应稳定的响应特征：平均响应长度、格式合规率、置信度得分分布和延迟概况。这些指标的任何重大变化都会触发黄金数据集评估，以量化准确性影响。一些提供商提供固定到特定版本的模型版本控制 - 在可用的情况下使用它。

生产 AI 代理可接受的准确度阈值是多少？

这完全取决于用例和错误成本。对于自主做出财务决策的代理来说，通常需要 98% 以上的准确度。对于生成供人工审核的草稿的代理来说，85-90% 通常是可以接受的，因为人工会发现错误。对于生成内部分析且错误风险较低的代理来说，80% 可能就足够了。根据错误成本分析而不是任意基准来定义阈值。

我们如何处理存储代理执行跟踪的 GDPR 和数据隐私要求？

OpenClaw 的跟踪系统支持存储前的 PII 编辑 — 在跟踪配置中配置要编辑的字段。跟踪存储的保留期限可配置，以满足数据最小化要求。对于基于 EU 的部署，跟踪存储可以配置为仅限 EU 区域。个人可以根据 GDPR 删除权条款请求从痕迹中删除其数据。

有效的质量监控所需的人工审核采样率是多少？

对于大多数代理商来说，对生产输出进行 2-5% 的抽样可以提供具有统计意义的质量监控。对于高价值或高风险代理，增加至10-20%。评审过程应该是结构化的——评审者使用标准化的标题而不是一般的印象。 OpenClaw 的审核界面显示带有标题的采样输出并捕获结构化反馈。

我们可以使用另一个法学硕士来自动化人工审核流程吗？

部分地。 “LLM 作为法官”模式非常适合评估输出格式、完整性和基本事实准确性。它们在评估特定领域的正确性方面效果较差（合同风险评估是否正确需要法律专业知识，而不是一般的人工智能判断）。使用自动化法学硕士评估进行规模化，并使用人工审核进行校准和验证。

---

后续步骤

对 AI 代理实施生产级测试和监控需要具备 AI 系统和 DevOps 实践方面的经验。 ECOSIRE 的 OpenClaw 实施包括专为您的特定代理工作流程设计的监控架构、预配置的仪表板、警报策略和事件响应操作手册。

探索 OpenClaw 支持和维护服务 以了解持续监控和优化选项，或安排咨询以讨论当前或计划的 OpenClaw 部署的监控架构。