你究竟如何调试AI代理？
摘要
开发者分享了在生产环境中调试AI代理的困境，指出了幻觉问题、提示词更改导致的回归以及高昂的API成本，并向社区征求策略。
我已经在生产环境中运行AI代理6个月了（Cursor、Claude Code、自定义Mastra管道），但调试它们仍然是一场噩梦。仅上周：
\- 一个代理悄悄产生幻觉，虚构了一个配置值。两天后才被发现。
\- 更新提示词后出现回归——完全不知道何时出了问题。
\- 一项我以为只需8美元的任务花了80美元的API费用。
我花在阅读日志上的时间比实际构建的时间还多。你们是怎么处理的？是手动审查输出吗？内部构建了工具？还是干脆放弃，接受混乱？真心好奇，这只是我一个人的问题，还是大家共同的痛点。
相似文章
我分析了 50 多个 AI 团队如何调试生产环境中的智能体故障，结果令人意外
基于对 50 多个 AI 团队的访谈，作者指出生产环境中的智能体故障往往源于细微的提示词或配置问题，而非深层模型缺陷。文章主张采用版本控制、A/B 测试和实验跟踪等软件工程实践以提高可靠性。
给在生产环境中运行 AI 代理的朋友们一个快速问题
一个问题，指出 AI 代理记忆层缺乏可观测性，询问团队在没有完整追踪能力的情况下如何调试错误的检索结果。
在部署之前，你们是如何测试智能体的？还是大家都在生产环境中凭感觉检查？
关于测试非确定性AI智能体挑战的讨论，质疑开发者如何在没有传统测试模式的情况下验证工具使用、行为和多步骤工作流。
当你的代理做出错误决策时，事后如何找出原因？
一位开发者询问其他人如何调试因信息过时而做出错误决策的AI代理，并对当前追踪工具（如LangSmith、LangFuse和Phoenix）的有效性提出质疑。
如何提高AI代理的可靠性？
讨论将AI代理从沙箱迁移到生产环境所面临的挑战，强调高敏感性导致大量噪声，并提出解决方案，如二级评估器、启发式方法和级联架构。同时向社区询问他们的过滤方法。