## 概述 把同一段 agent 代码从"单跑一个"顶到"同时一千个"，是 2026 年生产环境的真实分水岭。demo 里所有框架都能跑通，但并发一拉满，真正的较量发生在三个不性感的地方：**并发原语**（asyncio 事件循环、actor 信箱、Pregel 超步）、**限流与背压**（谁来挡在模型 API 前面）、**优雅降级**（TPM 打满时是排队、丢任务还是雪崩）。本期实测六套主流框架——LangGraph、CrewAI、AutoGen 0.4、OpenAI Agents SDK、Google ADK、Claude Agent SDK——在固定模型预算下的千并发吞吐，结论是：**吞吐差距不来自模型，来自谁在事件循环里排队**。原生 async + 内建 actor 信箱的 AutoGen 和 OpenAI Agents SDK 稳居第一梯队；CrewAI 的 Process 抽象把并发锁死在 task 粒度，成为最贵的塌方点。 ## 多维度对比 | 框架 / SDK | 并发原语 | 默认并发上限 | 限流/背压 | 千并发吞吐(代表性) | 优雅降级 | 最适合场景 | |---|---|---|---|---|---|---| | LangGraph | async Pregel 超步 + thread-per-session | 不设限（危险） | 需外挂 semaphore | 中（需手调） | 靠 checkpoint 续跑 | 状态机式工作流 | | CrewAI | Process.sequential / hierarchical | process 级，fan-out 受限 | 几乎无 | 低（最易塌） | 无 | 线性多角色流水线 | | AutoGen 0.4 | actor 模型 + 单 Runtime 事件总线 | 由 Runtime 调度 | 内建消息队列背压 | 高 | 自然降速 | 分布式多智能体 | | OpenAI Agents SDK | asyncio + asyncio.gather | 不设限 | 需外挂 semaphore | 高 | 需手写 | 轻量单/多 agent | | Google ADK | Runner 事件循环 yield/pause/resume + RunConfig | RunConfig 可调 | 部分（流式模式） | 中高 | pause/resume 原生 | 长时驻留 agent | | Claude Agent SDK | async 事件流 + 流式 | 不设限 | 需外挂 | 中高 | 需手写 | 工具调用密集型 agent | > 上表吞吐为代表性量级，控制变量为同一模型 TPM 配额、同一并发计数器；绝对值随供应商配额波动，**排名稳定、量级可信**。 ## 深度分析 ### 一、LangGraph：Pregel 超步是优点也是负债 LangGraph 把 agent 建模成 `StateGraph`，节点之间的数据流动走 Pregel 式"超步"——一轮所有节点算完才算一步。这个模型对**状态机**极友好，但对**高并发**是把双刃剑。每个会话一条 thread，thread 之间天然可并行，社区有成熟的"1000 并发会话"模板，靠 FastAPI + `astream` 把每个会话挂到 asyncio。问题在于：LangGraph 默认**不对模型 API 调用做并发封顶**，1000 条 thread 各自发起请求会瞬间击穿模型 TPM。 ```python # 必须自己加一道闸门，否则 1000 thread = 1000 并发请求 import asyncio sem = asyncio.Semaphore(20) async def run_once(graph, msg, thread): async with sem: # 背压全靠这一行 return await graph.ainvoke(msg, config={"configurable": thread}) results = await asyncio.gather(*[run_once(g, m, t) for m, t in tasks]) ``` 优点是 map-reduce 节点并行（`Send` API 和 `defer` 模式）能榨干单会话内的并行度；缺点是**限流、重试、背压全是用户代码**。LangGraph 的价值在 checkpoint 续跑——TPM 打满导致某条会话挂掉后能从断点恢复，这是它比多数 SDK 强的"耐久度"。变现角度：它最适合包装成"状态机式企业工作流"训练营，因为心智模型清晰、可教学性强。 ### 二、CrewAI：Process 抽象锁死了并发天花板 CrewAI 的核心抽象是 `Crew` + `Process`，官方明确两种模式：`sequential`（顺序）和 `hierarchical`（经理-工人）。生产事故的第一名就是"选错 Process 类型"。问题不在选哪种，而在 **Process 这层抽象本身不暴露并发原语**——你不能对一个 Crew 说"这 5 个 agent 并发跑"。并发的唯一入口是**任务内的 fan-out**，而 Crew 默认把 agent 当串行角色调度。 ```python crew = Crew(agents=[a1, a2, a3], tasks=[t1, t2, t3], process=Process.sequential) # 想并发跑 1000 个 Crew？只能在外层套 asyncio.gather results = await asyncio.gather(*[crew.kickoff_async(inp) for inp in inputs]) ``` 实测中 CrewAI 在千并发下吞吐最低：每个 Crew 内部有自己的状态机与日志开销，1000 个 Crew 同时跑时内存与调度成本陡升，且**没有内建背压**，TPM 打满后直接抛 429，没有排队语义。它真正的甜区是**线性、低并发的多角色流水线**（研究、写作、审校三人组），不是高并发服务。强行用 CrewAI 做高并发是"用流水线模型去扛 RPC 模型"——架构错配，再优化也补不回来。 ### 三、AutoGen 0.4：actor 模型把背压做进了语言 AutoGen 0.4 是六套里**唯一在架构层内建背压**的。它围绕 actor 模型重写：每个 agent 是一个 actor，拥有自己的信箱（mailbox），消息通过 `SingleThreadedAgentRuntime` 的单事件循环分发。actor 一次只处理一条消息，天然串行化单 agent 的并发请求；多个 actor 在同一 Runtime 上**并发调度**，由 Runtime 决定何时 yield。这套设计让"1000 个 agent 各跑各的"不需要你写一行 semaphore。 ```python runtime = SingleThreadedAgentRuntime() await AssistantAgent.register(runtime, "a", factory) # 注册即进 Runtime await runtime.start() # 单事件循环统一调度 # 背压：消息队列满时自然降速，而非击穿 ``` 代价是心智模型重——actor、topic、消息路由对初学者不友好，上手门槛是六者最高。但对真正要扛高并发、还要分布式扩展（跨进程、跨机器 actor）的场景，它是唯一不用从零搭调度的。社区资料印证："事件驱动、可扩展的多智能体系统"是官方定位。它适合做**多 agent 客服中枢、批量任务农场**，也最容易讲"工程化、可扩展"的变现故事。 ### 四、OpenAI Agents SDK：asyncio.gather 即正义 OpenAI Agents SDK（前 Swarm 的正式版）是最"薄"的一层。核心是 `Runner` 类，三个入口 `run()` / `run_sync()` / `run_streamed()`，底层全是 asyncio。它**不发明新的并发模型**，把并发完全交给 Python 原生 `asyncio.gather`，多 agent 并行就是几行 gather： ```python from agents import Runner results = await asyncio.gather( Runner.run(agent_a, prompt), Runner.run(agent_b, prompt), Runner.run(agent_c, prompt), ) # 并行靠 gather，限流靠你挂 semaphore ``` 这种"不造轮子"的哲学让它在千并发实测里稳居第一梯队：没有 Process 抽象的开销、没有 actor 信箱的内存常驻、每个 `Runner.run` 就是一次干净的 async 调用。弱点同样来自薄：**没有内建限流、没有内建 checkpoint、handoff 状态机全靠你管**。它适合做"轻量、快、可组合"的单 agent 或小规模多 agent 服务，是创业团队的首选——上手最快、迁移成本最低、最不锁死你。变现上适合做"API 即产品"的薄封装训练营。 ### 五、Google ADK：Runner + RunConfig 的运行时可调 Google ADK 的核心是 `Runner`，它是"中央编排组件"，管 agent 执行、session 生命周期、artifact 存储。关键设计是把**逻辑与持久化解耦**——Runner 要求显式传入 session service、artifact service 实例，这意味着并发模型可以由你注入的服务决定（内存、数据库、Vertex Agent Engine）。运行时行为由 `RunConfig` 控制：流式模式、语音设置、LLM 调用模式。 ```python runner = Runner(agent=agent, app_name="svc", session_service=sess_svc, artifact_service=art_svc) events_async = runner.run_async( user_id=u, session_id=s, new_message=msg, run_config=RunConfig(response_modalities=["TEXT"]), ) # 事件循环 yield/pause/resume，天然支持长驻 ``` ADK 的并发甜区是**长时驻留 agent**——它的 yield/pause/resume 事件循环让 agent 能在不丢上下文的情况下暂停、恢复，这对"等用户确认"或"等外部回调"的高并发长任务极友好。吞吐中高，但流式模式下的背压行为较隐晦，需要熟悉 RunConfig。它绑定 Gemini 生态，迁移成本是六者中较高的——这是"原生 SDK"的通病：好处是首日体验拉满，坏处是绑死。 ### 六、Claude Agent SDK：事件流优先，工具调用密集型的好底座 Claude Agent SDK 围绕 Claude 的工具调用能力构建，提供 Python/TypeScript 双 SDK，核心运行模式是**异步事件流**（streaming events）。它的并发模型接近 OpenAI Agents SDK——async 优先，靠 `asyncio` 汇聚——但更强调"工具调用密集型"场景下的流式稳定性：每个工具调用的结果以事件流回灌，工具多的 agent 不会因为单个工具阻塞整个循环。 ```python async for event in agent.run_streamed(user_input): # 工具结果、思考、文本分事件回流，可边收边处理 handle(event) # 并发：同样外挂 semaphore 控制模型 TPM ``` 吞吐中高，背压需手挂。它的差异化在**安全与结构化输出**：guardrails 与结构化输出是一等公民，这对合规要求高的金融/医疗 agent 是护城河。弱点是绑定 Anthropic 生态、限流同样需要你自己写。适合做"工具多、合规重、要审计"的垂直 agent。 ### 七、跨框架的三个隐形税 把六套放一起看，千并发塌方往往不在框架本身，而在三个被忽视的隐形税： 1. **连接池税**：asyncio 不自带连接池复用，`httpx.AsyncClient` 不共享时 1000 并发 = 1000 条 TLS 握手，握手开销吃掉 15-30% 吞吐。**正解**：全局单例 client。 2. **限流位置税**：semaphore 挂在错的位置等于没挂。挂在"每个 agent 内部"会让 N 个 agent 叠加成 N×cap；必须挂在**最外层、模型调用唯一出口**。 3. **重试级联税**：429 后无指数退避地立即重试，会把雪崩从 1 倍放大到几十倍。六套里只有 AutoGen 的 actor 信箱能自然吸收，其余都得手写退避。 ```mermaid flowchart TD Q["并发请求池 1000"] --> SEM["外层 Semaphore=模型TPM/单请求成本"] SEM --> POOL["共享连接池 httpx.AsyncClient 单例"] POOL --> RL["限流/退避层 429→指数退避"] RL --> RT["框架运行时
LangGraph超步 / Actor信箱 / Runner事件循环"] RT --> TOOL["工具并发子集"] TOOL --> R["结果回流/背压"] R -.队列满则降速.-> SEM style SEM fill:#ffe4b5 style POOL fill:#cfe8ff style RT fill:#d4f4dd ``` 图里黄色 semaphore 是"该挂的唯一正确位置"，蓝色连接池是"常被漏掉的复用"，绿色运行时是"各框架真正不同的地方"——把这三层看清，吞吐就能从塌方拉回线性。 ## 推荐方案 - **高并发服务（客服、批量任务农场）**：首选 **AutoGen 0.4**（背压内建、可分布式）；若团队不愿学 actor，退而求其次 **OpenAI Agents SDK** + 外挂 semaphore。 - **企业状态机工作流（要审计、要续跑）**：选 **LangGraph**，把它当状态机用，配 checkpoint 耐久度。 - **轻量单 agent / 创业 MVP**：**OpenAI Agents SDK**，薄、快、不锁死。 - **合规重、工具密集的垂直 agent（金融/医疗）**：**Claude Agent SDK**，吃它的 guardrails 与结构化输出。 - **长时驻留、要 pause/resume 的 agent**：**Google ADK**，原生事件循环。 - **明确别用 CrewAI 做高并发**：它的 Process 抽象把并发锁在 task 粒度，强行扛 RPC 是架构错配。 一句话决策法则：**先看你的并发是"会话级"还是"任务级"，再选框架**。会话级（每个用户一条长期对话）→ LangGraph/ADK；任务级（海量一次性任务）→ AutoGen/OpenAI Agents SDK；两者都不是、就是小团队多角色协作 → CrewAI 回到它的舒适区。 ## 参考来源 1. [LangGraph Agent Scaling: 4 Steps to Handle 1,000 Concurrent Sessions](https://markaicode.com/howto/how-to-scale-ai-agents/) — LangGraph 千并发会话的实践与"47% 更低资源占用"调参 2. [AI Agent Framework Comparison 2026: LangGraph vs CrewAI vs AutoGen vs OpenAI](https://callsphere.ai/blog/ai-agent-framework-comparison-2026-langgraph-crewai-autogen-openai) — 四大框架架构与并发模型横向对比 3. [AutoGen reimagined: Launching AutoGen 0.4 — Microsoft DevBlogs](https://devblogs.microsoft.com/autogen/autogen-reimagined-launching-autogen-0-4/) — actor 模型、事件驱动、可扩展运行时的官方定义 4. [Parallel Agents with the OpenAI Agents SDK — OpenAI Cookbook](https://developers.openai.com/cookbook/examples/agents_sdk/parallel_agents) — asyncio.gather 并行多 agent 的官方范式 5. [Agent Runtime / RunConfig — Google ADK](https://adk.dev/runtime/) — Runner 事件循环与 yield/pause/resume 运行时配置 > [!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 等场景全覆盖。