我一直放弃多智能体工作流,因为我无法验证它们提交的代码。你们是怎么处理的?
摘要
一位开发者分享了他在使用多智能体编码工作流时的困扰——并行 PR 的产出难以逐一验证——并描述了他如何构建一个 AI QA 智能体,通过真实浏览器(借助 Browserbase)自动点击预览部署,对无法正常运行的 PR 标记失败。
我试过 Conductor 这类智能体编排工具,但从来没能坚持长期使用,因为我根本没办法验证它们在几乎没有校验的情况下产出的大量工作。我总是退回到单智能体的 Claude Code 工作流,却又总觉得自己错过了什么。
我反复遇到的情况是:
1. 3-5 个智能体并行展开,各自开一个 PR
2. CI 通过,diff 看起来也没问题
3. 我根本不可能在早上之前把每个预览都点一遍
4. 我只凭 diff 和 CI 信号就合并了
5. 第二天生产环境出问题——因为智能体按字面意思完成了我的需求,但功能其实根本不能用
CI 通过并不能告诉你点那个按钮有没有反应。并行跑的智能体越多,我在没有验证的情况下合并的 PR 也越多。
大家是怎么处理这个问题的?
- 手动把每个预览都点一遍?(每天早上要花 2-3 小时)
- 用某种 QA 智能体来驱动预览部署?
- 提前写好覆盖所有 UI 流程的集成测试?(哈)
- 直接合并,出问题了再回滚?
我一直在这个方向上做探索。我构建了一个第二智能体,它会拿到每个 PR 的预览部署地址,通过 Browserbase 在真实浏览器中打开,点击测试该功能,如果不正常就让 PR 失败。整个验证流程自动运行,我不需要亲自充当 QA 环节。如果验证失败,构建智能体会收到报告并最多迭代 3 次。
对我来说,这就是缺失的那块拼图。没有它,我跑 5 个智能体却不敢合并任何一个 PR;有了它,我只需要看 QA 报告,把通过的合并就行了。
有没有人也解决了这个问题,还是大家都在不验证的情况下直接合并?
相似文章
在部署之前,你们是如何测试智能体的?还是大家都在生产环境中凭感觉检查?
关于测试非确定性AI智能体挑战的讨论,质疑开发者如何在没有传统测试模式的情况下验证工具使用、行为和多步骤工作流。
我的AI代理在同一QA任务上反复失败10多次。如何修复工作流?
用户报告在使用AI代理(Hermes + Claude Code)对Web应用进行探索性QA时反复失败,原因包括数据库错误、缓存过时和基础设施调试。他们寻求关于创建可靠工作流的建议,包括预检查、清除缓存和限制代理范围。
在实际仓库中运行编码代理:代理写完代码后哪些环节会出问题?
本文讨论了工程团队在采用AI编码代理时面临的实际挑战,如任务安全性、上下文检索、输出审查和协调,并提出了一个用于评估的准备度模型。
当你的智能体在生产环境中出错时,如何定位哪一步出了问题?
一位开发者分享了在多步骤智能体生产调试中遇到的挑战——由于复杂的工具使用和自信的错误回答,失败难以追踪,并向社区寻求更好的监控和回归检测方法。
真的有人在从issue到PR的流程中自主运行编码代理吗?
这是一场讨论,探讨完全自主编码代理的实际使用情况——这种代理接收issue并生成PR,无需人工引导,重点在于验证和人工监督。