代理评估延迟使CI增加了18分钟。你们是如何在不破坏开发效率的情况下运行它的?
摘要
讨论将全面代理评估集成到CI中的挑战,其中评估调用的延迟将构建时间从6分钟增加到24分钟,并考虑了并行化、缓存和异步评估等潜在解决方案。
代理 + langgraph + ~7个工具。将全面评估作为阻塞门禁添加到CI中。p99构建时间从6分钟跃升至24分钟。评估调用占主导地位(约200个场景 × 2个样本)。工程师们批量提交变更以绕过门禁。完全破坏了持续交付。尝试过:并行化评估调用(5倍加速,存在429风险);对未变更场景进行语义缓存(约60%命中率,缓存失效问题);PR上轻量评估,夜间全量评估;部署后异步评估搭配金丝雀回滚。倾向于方案4,但担心执行动作的代理短暂发布故障状态。人们是如何组织这个流程的?
相似文章
@Vtrivedy10: 我最喜欢的问题,昨天在AIE演讲中讨论了代码智能体的评估+改进循环基础设施和用户体验!有点偏见,但……
演讲者讨论了评估和改进代码智能体的重要性,强调了LangSmith与Harbor的集成,以提供在隔离环境中运行、追踪和改进智能体评估的统一栈。
大家如何在CI中处理代理回归测试而不抓狂?
作者讨论了在CI/CD中由于LLM的非确定性,AI代理工具调用自动化回归测试面临的挑战,并寻求社区关于有效设置和痛点的见解。
Agent Judge:解决生产环境智能体的长上下文评估(10分钟阅读)
Agent Judge 是一种智能体评估工具,通过处理长轨迹、对照事实源系统验证状态化动作以及适应行为变化,克服了简单 LLM 评判器在长周期智能体评估中的局限性。
@LangChain:在13分钟内,@jeffbarg、Vyshu Khota 和 Soroush Khadem 讲解了 Clay 如何将智能体评估扩展到每月超过3亿次运行…
Clay 将智能体评估规模提升至每月3亿次以上,介绍了其四象限评估框架以及在生产与评估闭环中面临的挑战。
我一直放弃多智能体工作流,因为我无法验证它们提交的代码。你们是怎么处理的?
一位开发者分享了他在使用多智能体编码工作流时的困扰——并行 PR 的产出难以逐一验证——并描述了他如何构建一个 AI QA 智能体,通过真实浏览器(借助 Browserbase)自动点击预览部署,对无法正常运行的 PR 标记失败。