在发布变更之前，你是如何测试智能体的？
摘要
作者介绍了一种智能体回归测试工具，帮助开发人员在代码变更后验证工具调用及工作流执行结果。
嗨，各位开发者，我正在开发一种智能体回归测试工具，希望能得到大家对于当前处理方式的反馈。我们通常会调整提示词，在本地测试几组输入，一切看起来都正常。但智能体是否真的调用了正确的工具、传入了正确的参数，并且真正完成了任务呢？如果工具返回的数据不完整，或者 API 在执行过程中出现故障，虽然智能体仍能给出看似合理的最终响应，但整个工作流却可能因此出错。我的目标是把这些故障场景转化为可重复的测试：单独运行工作流，检查工具调用及执行结果，然后在提示词或代码发生变化后再次复现相同场景。我希望打造出一种单人开发者也能在发布前轻松设置并使用的工具。对于那些已经在使用此类方法的开发者，除了最终结果之外，你们是如何定义和判断测试是否成功的？是使用自制的测试框架、现有的工具，还是主要通过手动查看日志？还有哪些地方仍然令你们感到困难？
相似文章
在用户发现故障之前，你如何对智能体工作流进行回归测试？
作者询问开发者如何对AI智能体工作流进行回归测试，指出了常见的故障模式，并分享了他们在Runme中添加评估支持的工作，用于记录任务、对轨迹进行评分以及与基准进行比较。
在部署之前，你们是如何测试智能体的？还是大家都在生产环境中凭感觉检查？
关于测试非确定性AI智能体挑战的讨论，质疑开发者如何在没有传统测试模式的情况下验证工具使用、行为和多步骤工作流。
大家如何在CI中处理代理回归测试而不抓狂？
作者讨论了在CI/CD中由于LLM的非确定性，AI代理工具调用自动化回归测试面临的挑战，并寻求社区关于有效设置和痛点的见解。
你们在部署前后是如何测试 AI 智能体的？哪些方法在实际使用中经受住了考验？
一位从业者向社区询问，他们如何在部署前后测试能够调用工具的 AI 智能体，并比较了场景测试、以大语言模型作为评判者、工具调用轨迹检查和回归测试套件，同时对测试覆盖率、评判者的可靠性以及非确定性提出了疑问。
我一直放弃多智能体工作流，因为我无法验证它们提交的代码。你们是怎么处理的？
一位开发者分享了他在使用多智能体编码工作流时的困扰——并行 PR 的产出难以逐一验证——并描述了他如何构建一个 AI QA 智能体，通过真实浏览器（借助 Browserbase）自动点击预览部署，对无法正常运行的 PR 标记失败。