大家如何处理代理之间的会话膨胀和状态移交？
摘要
一位用户讨论了在多代理工作流中会话膨胀和状态移交的挑战，寻求关于状态摘要、外部数据库或LangGraph和AutoGen等框架的解决方案的建议。
大家好，随着我不断扩展我的多代理工作流，我一直在遇到一个令人沮丧的瓶颈：会话状态管理。当对话持续时间过长，或者当代理处理复杂任务时，会话状态（和上下文窗口）就会爆炸式增长。它变得非常昂贵，延迟也急剧上升。我目前的主要挑战是移交过程。当会话变得过于臃肿，我需要将上下文传递给另一个专门的代理或一个全新的会话时，最干净的方式是什么，而不会丢失关键上下文？我对你们的真实环境设置很好奇：你们是在移交前对状态进行摘要吗？完全依赖外部数据库（如Redis、Postgres或Vector DBs）来重建状态吗？使用像LangGraph或AutoGen这样的框架来管理路由和记忆吗？很想听听你们在生产中是如何解决这个问题的！
相似文章
如何管理代理记忆而不让其变成杂物抽屉？
关于管理AI系统中代理记忆的实际挑战的讨论，侧重于避免信息过载导致输出质量下降，并提出使用工作流状态和多代理架构等策略。
大家是如何处理长时间运行的代理的状态的？无状态沙盒正在吞噬我的夜晚
一位开发者讨论了在使用沙盒环境下的长时间运行编码代理中状态持久化的挑战，详细说明了高昂的恢复开销，并寻求社区解决方案来实现无需自定义检查点层的持久状态处理。
你们是如何在视觉上串联多个代理时维护状态或处理内存的？
作者分享了使用名为 architect by Lyzr 的可视化工具来编排多步骤 AI 代理管道的经验，强调了与传统自动化工具相比，状态跟踪和调试更加容易。
LangGraph 监督者应如何在同一个聊天会话中路由多个代理？
一位开发者请求构建多代理 LangGraph 应用程序时的架构建议，该应用使用监督者处理动态路由、状态管理和同一聊天会话内的人机交互工作流。
我们的大部分“智能体”问题实际上是工作流/状态问题
一位开发者讲述，构建AI智能体时的许多挑战实际上源于工作流和状态管理问题，而非模型智能，强调了稳健的状态处理和可观测性的必要性。