所以... 我们团队里没人能告诉我哪个版本的智能体实际上在生产环境中运行!
摘要
一个团队在生产环境中遇到AI智能体的版本跟踪和监控故障,导致未经审查的更改和行为漂移。作者讨论了像管理传统软件一样管理智能体部署的工具和实践。
这件事发生在几周前,确实很尴尬。我们在不同团队运行了几个智能体大约六到七个月。不同的框架,最初构建它们的人不同,有些在转移到其他项目时换了负责人。这就是这些东西演化的正常混乱现实。在一次会议上,一位相当资深的人问某个特定智能体的当前版本是什么。然后整个房间就安静了。有人说他们认为可能是两个月前的那个版本。其他人说不对,七月份有更新推送。没人能实际确认。我们去查看了,情况比那更糟。我们发现一个提示词更改未经任何审查就被部署了。我们发现一个API依赖改变了其响应格式,智能体几乎三周以来一直在悄悄产生略微错误的输出。没人发现是因为我们监控的是正常运行时间,而不是行为漂移。一旦我们找到所有问题,修复是直接的。弄清楚发生了什么花了将近两天时间。让我印象深刻的是,对于常规软件,我们绝不会让这种事发生。一切都通过git,每个部署都有版本标签,回滚只需一个命令。对于智能体,我们不知怎么地接受了一个完全不同的标准,而没有有意识地决定。从那以后,我一直在阅读其他团队如何处理这件事:Langfuse在可观察性方面很好,用于了解智能体事后做了什么。在部署和版本控制方面,我发现了Lyzr的控制平面方法,这基本上是将智能体部署视为与任何其他软件基础设施相同的方式。还有一些其他方法也类似。总之,我想知道这是否是常见现象,还是我们只是特别混乱。这里的人们实际上如何跟踪多个智能体在生产环境中运行的情况?不是理想的设置。但是你们实际拥有的是什么!
相似文章
为什么部署代理仍然感觉像是在部署一个副项目?
文章强调了将AI代理从简单的本地开发转移到生产环境时的挑战,重点介绍了部署工作流中的缺口,如监控和版本控制。
我分析了 50 多个 AI 团队如何调试生产环境中的智能体故障,结果令人意外
基于对 50 多个 AI 团队的访谈,作者指出生产环境中的智能体故障往往源于细微的提示词或配置问题,而非深层模型缺陷。文章主张采用版本控制、A/B 测试和实验跟踪等软件工程实践以提高可靠性。
为什么AI Agent原型感觉很棒,但生产部署却变成一团糟
作者分享了将AI Agent系统从沙盒迁移到生产环境的经验,强调了当Agent执行任务时,人类角色变得模糊,团队脱离参与,导致运营失败。
AI Agent 故障排查研究与分析
一篇关于在生产环境中诊断 AI agent 故障根因之困难的实践讨论:即使已有 traces、工具调用记录和 prompt/响应日志,仍难以定位问题,以及如何在 agent 的步骤历史中回溯错误来源。
监控和审计自主AI代理运行时行为的最佳工具:生产环境中哪些真正有效?
一位从业者分享了在生产环境中监控自主AI代理的挑战和工具,涵盖了运行时提示注入检测、带推理轨迹的工具调用审计、行为漂移检测以及多代理授权,同时测试了Arize Phoenix、Protect AI Guardian、Metoro、Alice、Asqav和Microsoft Agent Governance Toolkit等工具。