"在什么情况下添加另一个代理实际上会损害您的系统？问这个是因为我的6代理流水线比旧的2代理流水线更慢且更不可靠"

过去几个月我一直在评估编排框架，已经厌倦了那些基准测试帖子和YouTube教程——它们都恰到好处地在部署前结束。以下是实际发布一些东西后的心得：**LangGraph**——适用于需要显式控制图的有状态工作流。检查点功能确实有用，但调试体验很糟糕。生产环境中图中间出现故障时，除非你自己构建了可观测层，否则回溯当前状态非常痛苦。**CrewAI**——快速原型设计很棒。基于角色的代理设置直观。但当我需要非标准功能时遇到了瓶颈。早期使其易用的抽象后来成了天花板。处理较长任务时还有可靠性问题——代理会以难以复现的方式偏离脚本。**AutoGen**——尚未发布，仅用于演示。对话式多代理循环看起来令人印象深刻，但我真的不知道如何在实际生产环境中为其设置防护措施。欢迎指正。现在我在面向客户的应用中使用更轻量级的自定义方案，仅当需要跨长时间运行任务维持持久状态时才使用LangGraph。好奇其他人实际发布过什么——不是笔记本上看起来不错的。特别感兴趣：1. 如何处理工作流中间的故障？2. 是否在人机协同步骤中使用了这些框架？3. 大规模Token成本——框架选择是否影响了这一点？提前感谢。