从生产追踪构建智能体回归测试闭环

我是 Sofia Jakovcevic，Arize 的前线部署工程师。智能体可能让构建 AI 系统显得直观，但其行为也可能像黑箱。可观测性帮助我们逐步看清系统实际在做什么；随后可以评测其行为，并利用信息改进系统。

挑战不仅是找出哪里出错。提交修复时，我们还需要知道是否破坏了其他工作流。我想展示一个基于观察到的行为并连接持续集成的回归流程，随后再讨论智能体如何帮助闭合这一循环。

设想一个客服智能体，安全工程师要求增加一行：执行行动前先确认。这听起来无害，而自然语言提示词可能让我们误以为自己清楚改动会产生什么行为。我们需要覆盖重要结果的评测套件，而不是只依靠直觉。

在示例中，后续评测显示行动安全性提高了 17 个百分点，但任务完成率下降了 17 个百分点：如果智能体每一步都要求确认，而用户离开，会话可能永远无法完成。两个变化取平均后净变化为零，掩盖了取舍。这些分数来自演示，并非确认策略的普遍效果。

审查者可能只看到系统提示词的一行改动，但行为影响发生在智能体运行时。改动可能在许多轨迹中改变步骤、子智能体交接和工具调用。差异展示改了什么；追踪记录某次运行中实际发生了什么。

Jakovcevic 认为，追踪有助于揭示难以仅从静态改动推断的静默失败。它们是对实际运行的观察，并不能保证涵盖所有可能行为。她以追踪作为回归循环的起点。

拟议循环有五步：从生产追踪中选择数据集、定义评测器、运行基线实验、将改动与基线比较，以及在 CI 中执行选定标准。目标是在部署前测试候选方案，而不是事后才发现其全部后果。

数据集应使用代表正常工作流的真实输入、工具调用和结果。加入已知失败和边界案例，也要纳入必须保护的成功工作流。只测试正在修复的失败，可能遗漏原本正常功能的回归。

接下来为重要维度选择评分机制，例如任务完成率、事实性、工具轨迹或效率。Jakovcevic 介绍了使用语言模型作为裁判，按评分标准对追踪或片段分类。分数使比较成为可能，但模型裁判本身也可能出错，需要结合适当的人类或其他参考判断进行验证。

评测不一定都需要语言模型。代码检查可以测试确定性属性，而模型评测器可能有助于评估较不确定的行为。选择取决于团队想衡量什么，以及评测器自身的可靠性。

让智能体针对选定数据集运行，并对输出评分以建立基线。然后只做一项改动，例如策略、提示词、模型、工具或交接方式，再运行同样的测试。分别比较各维度，更容易发现一个领域改善而另一个领域退步。

Jakovcevic 以模型选择为例：更贵的模型应根据应用关心的质量、成本和延迟来评估。实验可以为这种取舍提供依据，但数字分数只是测试设计范围内的证据，并不能证明每次部署都有相同的投资回报。

第五步是将实验放入 CI。拉取请求可以运行回归套件，团队可以要求满足选定标准后才合并。失败的候选方案返回调查和迭代；通过门槛的意义取决于案例、阈值和评测器的质量。

在 Arize 演示中，Jakovcevic 展示了包含多个提示词版本的退款智能体实验。界面比较行动安全性和任务完成率；一个例子显示相反方向的 17 个百分点变化，另一个候选方案则有不同的改善。这些是演示结果，不是对所有智能体或产品的受控比较。

她打开提示词 playground，选择一个已保存的提示词和包含 100 行的数据集，后者包括边界案例、已知失败和需要保护的成功案例。她复制候选方案，以便并排测试两个提示词版本，然后加入任务完成率和行动安全性评测器。

界面针对记录运行评测，并展示评测分数、延迟、成本和错误率等指标。Jakovcevic 随后展示智能体 playground：它可以通过 HTTP 调用远程智能体，让同一数据集和评测器测试包含子智能体的更复杂系统。

她说，除了用户界面，还可以通过 SDK、API、CLI 或 CI 以编程方式运行实验。她特别介绍 Arize 的公开智能体技能代码库，称它可以将编程智能体与可观测性系统及生产行为背后的上下文连接起来。

由人主导的循环是观察、评测、改动、测试和改进。工程师收集追踪并评分，修改提示词、模型、工具、技能或策略，再测试候选方案。当生产环境出现新的失败时，可以将案例加入回归套件，以便后续改动接受检查。

Jakovcevic 提问：如果由智能体调查失败并提出修复，而不是完全依靠人查看仪表盘和分诊，会怎样？她设想让编程智能体连接运行时追踪，以便检查行为并提出改动。这是她对智能体可观测性方向的设想，并不能证明自主修复总是正确或不需要监督。

她最后认为，没有运行时上下文的代码改动可能看不到生产环境中的行为。让智能体访问追踪、评测和反馈，可以帮助它们调查并改进自身系统。这一循环的价值仍取决于数据、测试和拟议改动周围的保护措施。