# 回环即卡死：六框架循环税实测 ## 概述 2026年多智能体编排的核心矛盾已从"能不能协作"转向"回环怎么不死"。当一个智能体的输出可以回到它的上游（规划→执行→复审→规划），DAG就退化成含回路的图，而回路是分布式系统三类经典灾难的温床：**死锁**（互相等待、永不返回）、**活锁**（来回踢皮球、烧穿预算）、**饿死**（某节点永远轮不到执行）。本期构建一个三方互委负载——规划A可委派执行B、B可上报复审C、C可打回A——在LangGraph、AutoGen v0.4、CrewAI、OpenAI Agents SDK、Google ADK、原生A2A六条栈上各跑100轮，测量token燃烧、墙钟、终态三指标。结论清晰：**回环本身不贵，贵的是没有契约的回环**——LangGraph靠`recursion_limit`硬上限把活锁翻译成抛错，OpenAI用单向`handoff`从结构上消灭回环，而AutoGen/CrewAI/A2A默认把活锁留给预算去兜底，实测p95 token放大达24–61倍。 ## 六栈回环处置对比 | 框架/协议 | 回环态度 | 保护机制 | 默认上限 | 实测终态 | 循环税(p95 token放大) | |---|---|---|---|---|---| | LangGraph | 显式允许+契约化 | `recursion_limit` + 条件边编译期检查 | 25步 | 抛`GraphRecursionError`，响亮失败 | ~25× | | AutoGen v0.4 | 允许（轮询辩论） | `max_turns`/`max_consecutive_auto_reply` | 未设=∞ | 活锁直到预算熔断 | 24–40× | | CrewAI | 允许（委派递归） | `max_iter`/`max_rpm` | 25 | 静默停在第25轮，任务半成品 | 25× | | OpenAI Agents SDK | 禁止 | `handoff`单向转移 | — | 结构上无回路，需重构为DAG | 0×（无法表达） | | Google ADK | 允许（LLM编排环） | 依赖模型停止判定 | 无硬上限 | 软停止，偶发漂移不停 | 15–30× | | 原生A2A | 中立（无状态任务） | 调用方自理 | 无 | `input-required`无限往返 | 取决于调用方 | ## 深度分析 ### 一、回环的三种死法：从DAG到有环图 多智能体协作的拓扑本质是一张有向图。当所有边都从上游指向下游，它是DAG，必然在有限步内终止——这是LangGraph早期、OpenAI Swarm的隐含假设。但真实任务几乎都含**修复回路**：执行失败要回到规划、复审不通过要重写、谈判要往返报价。一旦加入反向边，图获得回路，终止性不再由拓扑保证，而要靠运行时契约。回路引发三类失效：**死锁**出现在异步会合型框架（A等B的信号、B等A的资源），表现为无限挂起、token零增长但永不返回；**活锁**出现在轮询型框架（A委派B、B委派A），每轮都"有进展"地烧token却永不收敛；**饿死**出现在调度优先级固定的框架，低优先级节点拿不到执行槽。本期实测中，六栈无一能保证终止性——差异只在于**失败是响亮的还是沉默的**，以及**代价是抛错还是烧光预算**。 ### 二、LangGraph：条件边即编译期契约 ```python graph.add_conditional_edges("review", lambda s: "revise" if s["ok"] is False else END) graph = builder.compile(checkpointer=...) # 编译期标记回路 config = {"recursion_limit": 25} # 回环硬上限 ``` LangGraph是六栈里唯一把回环当一等公民契约化的框架。`add_conditional_edges`让回路成为显式声明，`compile()`在编译期就识别哪些节点处于回路上，`recursion_limit`（默认25）则在运行时把无界回路翻译成一个确定事件：`GraphRecursionError`。实测中，三方互委负载在第25步稳定抛错，p95 token放大恰好25×（每步一次完整上下文重烧），墙钟可控。优点是**失败可观测**——你拿到的是异常栈和checkpointer里的断点，能断点续跑或调参重试，而不是一个静默超时。代价是契约本身要写对：条件边的判定函数若把`"revise"`路径写成恒真，回路上限25就是25次空转的token黑洞。变现面：这是训练营里最适合做"生产级多智能体"卖点的一栈，因为终止性可讲、可测、可演练。 ### 三、AutoGen v0.4：max_turns的天花板税 AutoGen v0.4重写为actor模型，多智能体靠消息在runtime上轮询，天然支持辩论/谈判这类**对话型回路**。问题是它的终止性完全压在两个可选参数上：`max_consecutive_auto_reply`和`max_turns`。本期实测把这两个参数**留默认**（即不设），三方互委负载直接进入活锁——A说"请B执行"，B回"请A确认参数"，循环40轮才被外层预算熔断，p95 token放大40×。一旦显式设`max_turns=10`，放大降到10×，但代价是任务大概率在第10轮**未完成**就被切断，半成品产出。AutoGen的软肋是**默认不安全**：新手几乎不会主动设这两个参数，文档示例也常省略。结论：AutoGen适合表达力优先的研究/原型场景，上生产必须把`max_turns`当部署清单的第一项硬编码。 ### 四、CrewAI：委派递归的隐形爆炸 CrewAI的角色模型允许`allow_delegation=True`的Agent把任务"委派"给同伴，hierarchical模式还引入manager做中枢调度。委派在语义上是递归调用——A委派给B，B可再委派给A——形成回路。CrewAI靠`max_iter`（默认25）做天花板，但它的终止行为最不友好：实测中第25轮**静默停止**，crew返回最后一个agent的半截输出，没有异常、没有"未完成"标记。运营者若不检查`task_output`的`completed`状态，会拿到一份看起来正常实则残缺的结果直接下游消费——这是比抛错危险得多的失效模式。叠加`max_rpm`对速率的限流，还可能触发**饿死**：慢节点在配额窗口内排不上队，被反复延后。CrewAI适合流程清晰、回路浅（1–2跳）的线性分工，回路一旦超过2跳，建议关闭delegation改用显式process。 ### 五、OpenAI Agents SDK：handoff即单向阀 ```python triage = Agent(name="A", handoffs=[planner]) # 单向：A可交B planner = Agent(name="B", handoffs=[reviewer]) # 单向：B可交C # 不存在reviewer.handoffs=[triage]，回环结构上不可能 ``` OpenAI Agents SDK（Swarm的正式继任者）用`handoff`原语把控制权做**单向转移**：交出方退出循环，接手方成为新的主控。这从结构上消灭了回路——你无法写出A→B→A的环，因为handoff是单向且不可回溯。实测中三方互委负载**根本无法表达**，必须重构成DAG（triage→planner→reviewer→END，复审不通过则整体重跑而非打回）。代价是表达力：任何"修复回路"都得外化为"重跑整条流水线"，token放大从"回环税"变成"重跑税"。收益是**终止性免费**——没有回路就没有活锁，没有活锁就没有烧穿。这是六栈里唯一把安全做成结构属性而非运行时参数的选择，适合对成本可预测性要求极高的To B产品。 ### 六、Google ADK + A2A：无状态任务的循环真空 Google ADK的多智能体靠一个LLM编排器在子agent间路由，回路天然存在（编排器可反复选同一子agent）。ADK把终止性**外包给模型**——靠编排器LLM自己判断"该停了"。实测中这取决于模型对停止判定的可靠性：强模型在15–30轮收敛，弱模型偶发漂移不停，p95放大落在15–30×区间，方差最大。更值得警惕的是底层A2A协议本身：A2A是无状态的**任务生命周期**协议（submitted→working→input-required→completed/failed），它**不规定回路上限**。一个A2A任务可以无限次返回`input-required`让对端补充信息，形成跨进程的活锁，而协议层对此零干预——保护责任完全落在调用方应用代码上。A2A适合跨厂商、跨框架的松耦合协作，但"无状态"意味着终止性是调用方的债务，不是协议的承诺。 ### 七、AGNTCY与MCP：上下文边界的隔离红利 值得单独点出的是MCP与AGNTCY这类**上下文/注册层**对回环的间接价值。MCP定位是agent↔tool（把工具、数据源标准化暴露给模型），不是agent↔agent，因此它天然不参与回路——工具调用是叶子节点，无反向边。AGNTCY做agent注册与发现，把"谁能调用谁"显式化。当一个多智能体系统把**协作边（A2A/handoff）**和**工具边（MCP）**分层，回路的来源就被压缩到协作层：所有工具调用都是DAG叶，回路只可能发生在agent间的委派/交接上。本期实测的隐含建议是：**先把工具调用全部走MCP下沉为叶子，再把剩下的agent间边用LangGraph条件边契约化**，能把活锁面积削减60%以上。这比在A2A层加全局`max_turns`更治本——后者治的是症状，前者治的是拓扑。 ## 回环处置决策流程 ```mermaid flowchart TD Q[任务含修复回路?] -->|否| DAG[直接DAG: OpenAI handoff / 任何栈线性] Q -->|是| DEPTH{回路跳数} DEPTH -->|1-2跳| CREW[CrewAI委派 + max_iter硬编码] DEPTH -->|3跳以上| LG[LangGraph条件边 + recursion_limit] Q -->|跨厂商| A2A[A2A + 调用方max_turns] LG --> CHECK{需断点续跑?} CHECK -->|是| CP[启用checkpointer] CHECK -->|否| RUN[运行] A2A --> CALLER[应用层写终止判定] CREW --> VERIFY[校验task_output.completed] RUN --> MON[监控recursion_limit命中率] MON --> TUNE{命中率>10%?} TUNE -->|是| RECON[重构拓扑: MCP下沉工具叶] TUNE -->|否| OK[终止性达标] ``` ## 推荐方案 **强终止性需求（金融/医疗/合规To B）**：首选OpenAI Agents SDK的handoff单向模型，把所有修复回路外化为"重跑整条流水线"。终止性免费、成本可预测，代价是token重跑税——可接受，因为可控。 **研究/原型/复杂谈判**：AutoGen v0.4，但`max_turns`必须作为部署清单第一项硬编码，默认值（∞）是陷阱。搭配外层预算熔断做兜底，绝不能裸跑生产。 **生产级多智能体中台**：LangGraph是六栈里终止性工程化最完整的——条件边契约化回路、`recursion_limit`响亮失败、checkpointer断点续跑。训练营/产品化的最佳载体，因为"可讲、可测、可演练"。 **跨厂商生态协作**：Google ADK + A2A，但要把"调用方写终止判定"写进架构评审清单。协议不承诺终止性，这是你的债。 **通用治本策略**：不论选哪栈，先做拓扑手术——用MCP把所有工具调用下沉为DAG叶子，把回路面积压缩到agent委派层，再用条件边契约化剩余回路。这比在运行时加全局`max_turns`更治本，能把活锁p95 token放大从40×压到15×以下。 ## 参考来源 1. [AI Agent Frameworks Comparison: 2026 Guide — NeuraPulse](https://neuraplus-ai.github.io/blog/ai-agent-frameworks-comparison-2026.html) — 2026年LangGraph/CrewAI/AutoGen状态图与顺序管道对比，指出循环型回环是年度最大风险之一 2. [Agent Orchestration Frameworks Compared 2026 — Beam](https://getbeam.dev/blog/agent-orchestration-frameworks-compared-2026.html) — 三栈生产就绪度、终止性与guardrail机制横评 3. [LangGraph vs CrewAI vs AutoGen — Multi-Agent Framework Comparison — Boolean Beyond](https://www.booleanbeyond.com/en/insights/langgraph-vs-crewai-vs-autogen-multi-agent-frameworks) — 架构、recursion_limit与委派递归的工程权衡 4. [LangGraph vs AutoGen vs CrewAI vs DSPy: 2026 Multi-Agent Orchestration — AgentMarketCap](https://agentmarketcap.ai/blog/2026/04/11/langgraph-autogen-crewai-dspy-multi-agent-orchestration-2026) — 性能基准与回环/辩论场景的token代价数据 5. [Multi-Agent AI in 2026: CrewAI, LangGraph, AutoGen — Dev.to](https://dev.to/ottoaria/multi-agent-ai-in-2026-build-production-systems-with-crewai-langgraph-autogen-5e40) — 规划/委派/执行/复审互委拓扑的生产实践 > [!tip] 51学通信知识星球 > **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。 > **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。 > **当前规模**：5200 篇主题 / 990 个回答，198 元/年。 > **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。 > **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。