你的“自主代理”不断循环的隐秘原因（对代理底层记忆的深度剖析）

目前关于 CrewAI 和 AutoGen 等“多代理框架”的热度很高。当你观察终端输出时，感觉就像是不同的数字员工在开会。我想知道在底层层面这些编排究竟是如何运作的，因此我花了一个周末潜入这些框架的源代码和执行日志，研究它们如何路由信息。以下是对你的代理们实际如何相互通信的深度剖析——以及它们为何有时会陷入无限循环。 “独立代理”的幻象 在底层，并没有独立的“代理”在内存中等待轮到它们发言。整个架构本质上是一个复杂的、自动化的提示链式循环，操作着单一的文本管道。 1. “管理器”路由机制 当管理代理委派任务时，它并非发送一个 ping。它只是一个被强制使用严格输出模式（通常是 JSON）的 LLM。框架提示 LLM：“基于 X，接下来应由哪个角色处理？仅输出其名称和指令。”Python 脚本解析该 JSON，找到下一个角色的系统提示，并启动一个全新的 LLM API 调用。 2. 上下文交接（“草稿本”） 当代理 A 将工作传递给代理 B 时，框架会创建一个“草稿本”。它获取代理 A 的最终输出，在其前面加上代理 B 的系统指令，然后发送出去。问题在于：如果你不积极过滤传递的内容，上下文窗口会在每一轮中呈指数级膨胀。代理 C 最终会读取代理 A 的原始思考过程，从而导致产生幻觉目标。 3. 为什么它们会循环（终止失败） 大多数无限代理循环的发生是因为缺少确定性的停止条件。框架依赖 LLM 输出像 TERMINATE 或 FINAL_ANSWER 这样的特定字符串。如果上下文窗口变得过于嘈杂，LLM 便会忽略那条严格的系统指令，继续生成对话填充内容，从而使 Python 循环无限保持活动状态。 给开发者的启示： 不要将代理视为会议室里的人类。将它们视为函数式编程函数。 缩小范围：不要给代理一个宽泛的角色（“你是一位资深研究员”）。给它一个单一的输入/输出函数（“仅从这段文本中提取主要的 URL”）。 硬编码路由：除非你确实需要非确定性路由（让 LLM 决定谁下一步行动），否则使用标准代码（如 if/else 逻辑）在 LLM 调用之间路由数据。这样更快、更便宜，且不会无限循环。 你实际成功部署到生产环境且没有崩溃的最可靠的代理工作流程是什么？