我分析了 50 多个 AI 团队如何调试生产环境中的智能体故障，结果令人意外

我最近进行了一项关于 AI 智能体可靠性的个人研究，并与 50 多个使用大语言模型（LLM）/智能体构建产品的团队进行了交流。有一个现象反复出现。团队经常发布各种变更，例如提示词调整、模型替换、温度参数修改、检索更新等。但很少有团队将这些视为受控实验。因此，当生产环境中出现问题时，调试过程变得混乱不堪，因为没人知道究竟是什么导致了性能回退。 我注意到一个模式：大多数团队最初倾向于认为问题是出在深层原因上，比如上下文窗口限制、内存问题、模型退化或延迟/负载问题。但令人惊讶的是，相当多的故障最终被证明是由管道中某处的微小提示词或配置交互引起的。例如，一个团队花了近 3 周时间调试他们以为是一个多智能体工作流中的上下文处理问题。当他们最终添加了适当的实验跟踪和并排对比后，他们发现问题仅仅是其中一个中间智能体的系统提示词中存在一条冲突的指令。实际修复这个问题花费不到 20 分钟，但他们花了 9 天才找到问题所在。 那些似乎更善于处理这种情况的团队，其运作方式更像软件工程团队： * 对提示词/配置进行版本控制 * 基线对比 * 金丝雀发布 * 流量拆分 * 回滚支持 * 回归跟踪 另一个有趣的现象是，目前大多数工具似乎要么专注于故障发生后的可观测性/日志记录，要么专注于离线评估基准。这两者都很有用，但都不能完全解决智能体系统在生产环境中的安全实验问题。我很好奇大家在实际工作中是如何处理这个问题的？你们是否对提示词/模型进行版本控制，或者对智能体变更运行 A/B 测试？你们又是如何在用户察觉之前检测到回归问题的？