把同一段 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 把 agent 建模成 StateGraph，节点之间的数据流动走 Pregel 式"超步"——一轮所有节点算完才算一步。这个模型对状态机极友好，但对高并发是把双刃剑。每个会话一条 thread，thread 之间天然可并行，社区有成熟的"1000 并发会话"模板，靠 FastAPI + astream 把每个会话挂到 asyncio。问题在于：LangGraph 默认不对模型 API 调用做并发封顶，1000 条 thread 各自发起请求会瞬间击穿模型 TPM。
# 必须自己加一道闸门，否则 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 的核心抽象是 Crew + Process，官方明确两种模式：sequential（顺序）和 hierarchical（经理-工人）。生产事故的第一名就是"选错 Process 类型"。问题不在选哪种，而在 Process 这层抽象本身不暴露并发原语——你不能对一个 Crew 说"这 5 个 agent 并发跑"。并发的唯一入口是任务内的 fan-out，而 Crew 默认把 agent 当串行角色调度。
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 模型重写：每个 agent 是一个 actor，拥有自己的信箱（mailbox），消息通过 SingleThreadedAgentRuntime 的单事件循环分发。actor 一次只处理一条消息，天然串行化单 agent 的并发请求；多个 actor 在同一 Runtime 上并发调度，由 Runtime 决定何时 yield。这套设计让"1000 个 agent 各跑各的"不需要你写一行 semaphore。
runtime = SingleThreadedAgentRuntime()
await AssistantAgent.register(runtime, "a", factory) # 注册即进 Runtime
await runtime.start() # 单事件循环统一调度
# 背压：消息队列满时自然降速，而非击穿
代价是心智模型重——actor、topic、消息路由对初学者不友好，上手门槛是六者最高。但对真正要扛高并发、还要分布式扩展（跨进程、跨机器 actor）的场景，它是唯一不用从零搭调度的。社区资料印证："事件驱动、可扩展的多智能体系统"是官方定位。它适合做多 agent 客服中枢、批量任务农场，也最容易讲"工程化、可扩展"的变现故事。
OpenAI Agents SDK（前 Swarm 的正式版）是最"薄"的一层。核心是 Runner 类，三个入口 run() / run_sync() / run_streamed()，底层全是 asyncio。它不发明新的并发模型，把并发完全交给 Python 原生 asyncio.gather，多 agent 并行就是几行 gather：
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，它是"中央编排组件"，管 agent 执行、session 生命周期、artifact 存储。关键设计是把逻辑与持久化解耦——Runner 要求显式传入 session service、artifact service 实例，这意味着并发模型可以由你注入的服务决定（内存、数据库、Vertex Agent Engine）。运行时行为由 RunConfig 控制：流式模式、语音设置、LLM 调用模式。
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 的工具调用能力构建，提供 Python/TypeScript 双 SDK，核心运行模式是异步事件流（streaming events）。它的并发模型接近 OpenAI Agents SDK——async 优先，靠 asyncio 汇聚——但更强调"工具调用密集型"场景下的流式稳定性：每个工具调用的结果以事件流回灌，工具多的 agent 不会因为单个工具阻塞整个循环。
async for event in agent.run_streamed(user_input):
# 工具结果、思考、文本分事件回流，可边收边处理
handle(event)
# 并发：同样外挂 semaphore 控制模型 TPM
吞吐中高，背压需手挂。它的差异化在安全与结构化输出：guardrails 与结构化输出是一等公民，这对合规要求高的金融/医疗 agent 是护城河。弱点是绑定 Anthropic 生态、限流同样需要你自己写。适合做"工具多、合规重、要审计"的垂直 agent。
把六套放一起看，千并发塌方往往不在框架本身，而在三个被忽视的隐形税：
httpx.AsyncClient 不共享时 1000 并发 = 1000 条 TLS 握手，握手开销吃掉 15-30% 吞吐。正解：全局单例 client。flowchart TD
Q["并发请求池 1000"] --> SEM["外层 Semaphore=模型TPM/单请求成本"]
SEM --> POOL["共享连接池 httpx.AsyncClient 单例"]
POOL --> RL["限流/退避层 429→指数退避"]
RL --> RT["框架运行时<br/>LangGraph超步 / Actor信箱 / Runner事件循环"]
RT --> TOOL["工具并发子集"]
TOOL --> R["结果回流/背压"]
R -.队列满则降速.-> SEM
style SEM fill:#ffe4b5
style POOL fill:#cfe8ff
style RT fill:#d4f4dd
图里黄色 semaphore 是"该挂的唯一正确位置"，蓝色连接池是"常被漏掉的复用"，绿色运行时是"各框架真正不同的地方"——把这三层看清，吞吐就能从塌方拉回线性。
一句话决策法则：先看你的并发是"会话级"还是"任务级"，再选框架。会话级（每个用户一条长期对话）→ LangGraph/ADK；任务级（海量一次性任务）→ AutoGen/OpenAI Agents SDK；两者都不是、就是小团队多角色协作 → CrewAI 回到它的舒适区。
[!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 等场景全覆盖。