多智能体循环故障可能是组织设计问题，而非提示词问题

仓库：https://github.com/jeongmk522-netizen/agentlas_org_chart 几乎我发布或测试过的所有多智能体设置最终都会遇到同一个瓶颈。智能体之间互相推诿，评审者无休止地要求再润色一遍，研究人员不断衍生出无穷无尽的子话题，工具调用不断升级直到触发递归限制。框架文档通常将这些称为“循环”，并提供一个最大迭代次数的旋钮。我开始怀疑这个旋钮只是在处理症状，真正的问题更接近智能体最初的组织方式。 反复出现的模式是：当智能体被设计为同级关系（研究人员与分析人员对话，分析人员与作者对话，作者将结果交回评审者），没有谁明确拥有最终成果的所有权。每个智能体都可以不断要求另一个智能体做更多的工作。理论上图中存在停止条件，但没有哪个智能体有权宣布“已完成，停止运行”。这种权限充其量只是隐含的，并在同级网络中逐渐被稀释。 我正在测试的假设是：循环故障更像是组织设计失败，而非提示词失败。解决方法是把智能体网络视为具有明确汇报关系的组织架构图，而不是一个同级聊天室。一个负责的任务拥有者。每个工作流只有一个所有者。有限的委托深度。每个工作者有一个类型化的返回契约（状态、证据、输出、阻碍因素、下一步行动）。只有管理者有权重新打开或终止。记忆存在于权限层，专家只能获得限定范围的上下文。 我一直在使用的层级大致是主席、战略办公室、部门经理、团队负责人和专业工作者，质量保证和政策作为独立的参谋部门，可以拒绝和升级，但自身不能衍生无限制的新工作。特别是评审者递归失败模式，当验证者在结构上被允许一次拒绝通过，然后必须升级时，这种模式就会被消除。 框架已经具备大部分基础组件。CrewAI 具有分级流程，管理者验证工作者输出。LangGraph 有监督者、子智能体和明确的递归限制。OpenAI Agents SDK 有区别于同级交接的管理者式编排。AutoGen 有 GroupChatManager。Anthropic 发布的研究系统是协调者-工作者模式。 我认为被低估的是：把管理者视为拥有终止权限的正式汇报线，而不是开放式群聊的主持人。 有两件事我不确定。首先，层级本身可能成为瓶颈。如果每个决策都向上传递，主席智能体会成为延迟和故障的单点。其次，作为特性的升级机制只有在组织架构的顶层拥有真正的停止权限时才有效。如果主席只是调用另一个 LLM，而那个 LLM 又调用更多 LLM，那么循环只是向上移动了一层。