2026 开源 AI Agent 框架生产选型：10 个框架横评，谁真的扛得住线上
做 Agent 的 demo 有手到擒来，做 Agent 的生产系统却是另一回事。区别在于：demo 需要一个循环加一个工具；生产系统需要的是能在崩溃后接着跑的持久化状态、能挂起数小时等人审批的人工介入点、以及能发到你自己的后端的链路追踪。
这三条把 2026 年的开源 Agent 框架分成了泾渭分明的两半。
本文的主源是一份 2026 年 10 月 6 日发布的横评——作者逐个核对了 10 个框架的 GitHub 仓库与官方文档，记录了每个项目的语言、许可证、状态管理、人工介入、MCP 支持、追踪方式，以及 AutoGen 这个名字最后的去向。作为交叉佐证，我引入了 RankSquire 2026 年 5 月的 SVS 评分体系（基于 AgentRM 论文对 6 个框架、40,000 个 GitHub issue 的分析）以及其主权 TCO 测算。
先看结论表：10 个框架的能力矩阵
主源给的对比表是最有价值的部分。以下是核心维度的完整搬移（”—”表示所读文档未覆盖该能力，属未确认而非缺失）：
| 框架 | 语言 | 许可证 | 最新版本（截至 2026-10-06） | 状态与持久化 | 人工介入 | MCP | 追踪 |
|---|---|---|---|---|---|---|---|
| LangGraph | Python | MIT | 1.2.13（10-05） | 持久化执行 + 短期/长期记忆 | Interrupts | 经 langchain.mcp |
LangSmith（商业） |
| CrewAI | Python | MIT | 1.15.23（09-28） | 记忆、知识、checkpointing | 任务级人工审阅 | 支持，另有 A2A | 默认匿名遥测；AMP 提供追踪 |
| Microsoft Agent Framework | Python、.NET；Go 预览中 | MIT | Python 1.20.0（10-02） | 会话；工作流支持 checkpoint 与 time travel | 工作流内支持 | MCP 客户端 | 内置 OpenTelemetry |
| OpenAI Agents SDK | Python、TypeScript | MIT | 0.23.1（10-02） | 会话 | 内置 | MCP 工具 | 默认开启，发送至 OpenAI |
| Google ADK | Python、TypeScript、Go、Java、Kotlin | Apache 2.0 | Python 2.11.0（10-02） | 会话、状态、记忆 | 工具调用确认 | MCP 工具 + A2A | 日志、指标、链路 |
| Pydantic AI | Python | MIT | 2.54.0（10-03） | 八种引擎上的持久化执行 | 工具审批 | 内核内置 | 原生 OpenTelemetry |
| LlamaIndex Agent Workflows | Python | MIT | workflows 2.25.0（09-25） | 可插拔持久化 | 工作流服务器内 | — | — |
| smolagents | Python | Apache 2.0 | 1.26.0（05-29） | — | — | MCP 工具 | — |
| Strands Agents | Python、TypeScript | Apache 2.0 | Python 1.58.0（10-05） | 会话管理器 | Interrupts | 内置 | OpenTelemetry 发往你指定的 exporter |
| Mastra | TypeScript | Apache 2.0；ee/ 目录为企业许可 |
core 1.74.0（10-05） | 工作流状态存于存储层 + 记忆 | 挂起并恢复 | 可编写 MCP Server | 内置可观测性 |
第三方视角：SVS 评分与主权 TCO
主源提供的是功能核对，RankSquire 提供的是另一套视角——Sovereign Viability Score（主权可行性评分），评分公式为 SVS = (P + O + C + S + M) / 5，五个维度分别是：状态持久化与可恢复性、可观测性与可调试性、规模化成本可预测性、支持自托管与 BYOC 及欧盟数据驻留的主权性、维护节奏。
| 框架 | SVS 评分 | ALM 系数 | 月度成本（1 万任务/天，估算值） | 佐证（RankSquire）标注的硬性限制 |
|---|---|---|---|---|
| LangGraph | **9/10** | 1.2x | $700 – $2,200 | — |
| Pydantic AI | **8/10** | 1.1x | $800 – $2,400 | — |
| Google ADK | **8/10** | 1.3x | $900 – $2,600 | 非 GCP 环境未列 |
| CrewAI | **7/10** | 2.8x | $1,200 – $3,500 | **并发复杂 Agent 超过 20 个时调度失败**，44% 并发利用率 kill 阈值 |
| OpenAI Agents SDK | **7/10** | 1.5x | $2,500 – $6,000 | — |
| Mastra | **7/10** | 1.4x | $800 – $2,200 | — |
| AG2（原 AutoGen） | **5/10** | 3.87x | $2,500 – $5,000 | 仅建议用于研究与实验 |
表中 ALM 系数与月度成本均来自佐证方 RankSquire 的决策矩阵原文：ALM 是无协调多智能体部署相对基础 LLM 成本的放大倍数，月度成本对应 1 万任务/天、法兰克福负载，成本区间为估算值（ESTIMATED，非厂商报价）。
LangGraph 拿 9 分的原因很具体：原生的 PostgreSQL checkpointing 加显式的 interrupt 节点，直接满足欧盟 AI 法案第 14 条人工监督的要求（留痕/可追溯对应第 12 条）。主源也独立印证了这一点——LangGraph 的 README 列出持久化执行（从失败点恢复）、人工介入 interrupts（可在运行中检视并修改状态）、短期工作记忆与跨会话长期记忆三件套。
Pydantic AI 与 Google ADK 各 8 分，但理由不同：前者靠结构化输出抽取质量，后者靠 A2A 原生的多智能体协同。
CrewAI 的 7 分带着一条硬伤：并发复杂 Agent 超过 20 个之后调度失败会让系统失去响应，kill 阈值定在 44% 并发利用率。RankSquire 给出的算例很直白——25 个 Agent 时，CrewAI 的稳定性系数 0.61 会算出「不稳定」，而 LangGraph（系数 0.92）在同等负载下仍是「稳定」。这一条与主源给出的「Crews 面向自治协作、Flows 面向事件驱动精确控制」的双模型定位是吻合的：角色化协作越重，规模天花板越低。
ALM（Agent Loop Multiplier）= 3.87 倍，指的是无协调的多智能体部署相对基础 LLM 成本的放大倍数——这条来自 AgentRM 论文对 40,000 个 GitHub issue 的分析，也是 RankSquire 全部推理链的源头。
同一负载（法兰克福、1 万任务/天）下，完全自托管的 LangGraph 栈是 $700–$2,200/月，而托管 API 方案是 $2,500–$6,000/月。这组数字是佐证方 RankSquire 标注的估算值（ESTIMATED，非厂商报价），只对”有条件自托管”的自主权团队成立，不是普适结论。
分框架细看：各自的杀手锏与坑
LangGraph：状态图与中断是第一生产力
LangGraph 是低层的长运行、有状态编排库。1.0 版本于 2025 年 10 月 17 日发布（与 LangChain 1.0 同期），截至 2026 年 10 月已到 1.2.13。
两个容易被忽略的变化：MCP 支持已经迁入 LangChain 自家的 langchain.mcp 命名空间，原先独立的适配器仓库在 2026 年 9 月被归档；追踪与部署单独售卖，即 LangSmith 与 LangSmith Deployment。
选型建议很明确：如果你的团队要写显式的、可中断可恢复的有状态图，这是首选。
CrewAI：少写代码的双模型
两种模型：Crews（角色化 Agent 带一定自治地协作）与 Flows（事件驱动工作流做精确控制，可调用 Crews）。README 列出的能力包括工具、记忆、知识、checkpointing、异步执行、MCP 与 A2A 支持，任务可包含人工审阅。1.0 于 2025 年 10 月 20 日发布。
坑在遥测：默认开启，收集版本号、Agent 角色、工具名等匿名使用数据——除非主动 opt-in 用 share_crew，否则不涉及 prompt 与输出。内网环境需设置 CREWAI_DISABLE_TELEMETRY=true 或 OTEL_SDK_DISABLED=true。托管部署、追踪与治理在商业版 CrewAI AMP 里。
Microsoft Agent Framework 与 AutoGen 的结局
这是 2026 年最值得记住的一次框架换代。Agent Framework 于 2026 年 4 月 2 日对 Python 和 .NET 达到 1.0，Go SDK 处于公开预览。微软官方定位它是 AutoGen 与 Semantic Kernel 的直接继任者，由相同团队打造：AutoGen 的 Agent 抽象，加上 Semantic Kernel 的会话状态、中间件与遥测，再加上图式工作流。
工作流支持顺序、并发、handoff 与 group 模式，带 checkpointing、流式、人工介入和 time travel，OpenTelemetry 内置。Agent 可使用 MCP server，可跑在 Foundry、Azure OpenAI、OpenAI、Anthropic、Ollama 等模型上。
AutoGen 已经进入维护模式：README 顶部挂着维护模式横幅，不再有新特性，由社区管理，引导用户迁移到 Agent Framework。Semantic Kernel 的 README 同样指向 Agent Framework 作为继任者。
如果你有存量 AutoGen 或 Semantic Kernel 代码，2026 年这批改名与仓库迁移是需要逐个 changelog 排查的——这正是主源建议”优先选 1.x API、锁定版本、认真读 changelog”的原因。
OpenAI Agents SDK：轻量但有两个坑
围绕 Agent、handoff、guardrail、session、人工介入、长任务沙箱 Agent 与语音构建的轻量框架，Python 与 TypeScript 双版本。provider 无关，支持 OpenAI 的 Responses 与 Chat Completions 以及 100 多种其他模型。
两个坑：其一，版本号仍在 1.0 以下（0.23.1）；其二，追踪默认开启并导出到 OpenAI 后端，需要用 OPENAI_AGENTS_DISABLE_TRACING=1 关闭，或替换默认 processors。文档还特别说明：使用 OpenAI API 且处于 Zero Data Retention 协议下的组织，追踪功能不可用。
Google ADK：语言覆盖最广
Apache 2.0，支持 Python、TypeScript、Go、Java、Kotlin 五种语言，是多语言组织里覆盖最广的选择。Python 版的 ADK 2.0 于 2026 年 5 月 19 日发布，带来图式工作流 runtime，覆盖路由、fan-out/fan-in、循环、重试、状态与人工介入，并新增 Task API 用于 Agent 间的结构化委派。
工具调用可要求显式确认；支持 MCP 工具与 A2A 协议；内置带用户与环境仿真的评估框架；输出日志、指标与链路。对 Gemini 优化但模型无关，可部署到任意容器平台或 Google Cloud。
Pydantic AI：类型化 + 八种持久化引擎
来自 Pydantic 团队的类型化 Python 框架，自 2026 年 6 月 23 日起进入 v2。最独特的是在八种引擎上做持久化执行，包括 Temporal、DBOS 和 Prefect——Agent 能在你已经在运维的基础设施上存活数天。人工介入的工具审批内置，MCP 是内核的一部分，instrumentation 原生 OpenTelemetry 且可对接任意后端，Pydantic Evals 负责测试 Agent 行为。模型用一个字符串切换，包括通过 Ollama 跑本地模型。
LlamaIndex Agent Workflows、smolagents、Strands、Mastra
LlamaIndex 的 Agent 层现更名为 LlamaAgents，基于 Agent Workflows：事件驱动库，步骤是消费/发出事件的 async Python 函数，支持分支、循环、并行与可插拔持久化（文件或数据库）。llama-agents-server 把工作流包成带流式、持久化与人工支持的 REST API。适合已经在用 LlamaIndex 做检索的团队。
smolagents 来自 Hugging Face，Agent 逻辑只有约 1,000 行。CodeAgent 把动作写成 Python 代码而非 JSON 工具调用，代码可在 Blaxel、E2B、Modal 或 Docker 沙箱里跑。最新版本 1.26.0 发布于 2026 年 5 月 29 日，节奏比这份名单上其他项目都慢，但 9 月底仍有提交。
Strands Agents 是 Apache 2.0 的模型驱动 Agent 循环，跑在你自己的进程里、没有托管控制面。Python 与 TypeScript 两个 SDK 已合并进一个名为 harness-sdk 的 monorepo，旧的 TypeScript 仓库归档。MCP、流式、多智能体模式、结构化输出内置，interrupts 可暂停运行等人输入，session manager 持久化状态。追踪是你自己配置的 exporter 才收 OpenTelemetry span——默认什么都不发出去，这一点在合规场景里是加分项。
Mastra 是 TypeScript 优先选项：Agent、图式工作流（.then()、.branch()、.parallel()）、会话历史与长期记忆、RAG、评估与可观测性，模型路由覆盖 40 多个 provider。人工介入靠挂起 Agent 或工作流、存储状态、收到输入后再恢复——无论隔多久都行。还能编写 MCP server 暴露 Agent 与工具。许可证要留意：核心是 Apache 2.0，但 ee/ 目录下代码是 Mastra Enterprise License 的 source-available，生产使用需要许可。
许可证与合规：这是最容易翻车的一栏
十个框架里六个是 MIT（LangGraph、CrewAI、Microsoft Agent Framework、OpenAI Agents SDK、Pydantic AI、LlamaIndex Agent Workflows）、三个是纯 Apache 2.0（Google ADK、smolagents、Strands Agents），Mastra 单列——核心 Apache 2.0、ee/ 目录为企业许可。但真正需要逐个读 LICENSE 文本的是其他几个：主源专门点出了两个——AG2（Apache 2.0，1.1.2）仍在以自己的名字做多智能体工作，但经典的 autogen import 名与 Agent 类已迁到独立的 “AG2 Classic” 命名空间；以及 Claude Agent SDK for Python，其 README 声明使用受 Anthropic 商业服务条款约束，需要连同仓库许可证一起核对。
另外默认值方向值得警惕：OpenAI Agents SDK 默认发追踪到 OpenAI，CrewAI 默认发匿名遥测，Strands 默认什么都不发。这三个默认值分别对应”你的数据可能离开你的网络”、”你的使用模式可能离开你的网络”和”你得自己动手”。
生产选型的四条判据
主源给出的判断标准比任何单一评分都实用：
再加一条实操建议：原型阶段要压最难的路径，不是最顺的那条。强制中途崩溃、把审批挂一整夜、撤销一个工具，然后看每个候选框架各自怎么反应。
小夏点评
一、2026 年 Agent 框架的分水岭不是能力，是”故障语义”。 十年前我们比的是谁能调通工具链，现在比的是崩溃后能不能接着跑、审批能不能挂住、链路能不能自持。功能列表在快速趋同（大家都支持 MCP、都支持 A2A、都在做图式工作流），但持久化执行的引擎选型这一层差异极大：Pydantic AI 直接支持 Temporal/DBOS/Prefect 八种引擎，意味着持久化这件事不必自研；而 CrewAI 的 checkpointing 更像框架内置能力，跨引擎的弹性明显弱一些。这条差异在 demo 阶段完全看不出来，在一次生产故障后才会显形。
二、评分体系要挑对维度看，否则容易被带偏。 SVS 里主权性占一整维，这会天然抬高可自托管框架的分数——它在”有主权合规要求”的场景下是加分项，在”纯粹追求最快上线”的场景下就是无关项。同理，ALM 3.87 倍这个数字，衡量的是无协调多智能体的成本放大，真正的解法恰恰是加协调（用图式工作流而非自由互聊），这也是 LangGraph 分数高的深层原因之一。第三方评分适合当假设，不适合当结论。
三、给国内 IT 运维和开发者的启示：2026 年最该自建的不是 Agent 逻辑，而是”Agent 治理层”。 主源把话说得很直白——身份、权限、审计、评估、部署和值班支持全部落在框架之外，这部分成本才是真实的总量。具体建议三条：其一，默认出网必须全部关掉，OpenAI Agents SDK 的 OPENAI_AGENTS_DISABLE_TRACING=1、CrewAI 的 CREWAI_DISABLE_TELEMETRY=true、Strands 的 exporter 显式配置，这三行配置要写进部署清单和 CI 检查，而不是靠人记得；其二，MCP 权限从第一天就放在网关侧的角色注册中心，别让每个 Agent 的代码各自持有一份白名单，否则半年后没人说得清某个 Agent 到底能干什么；其三，给并发规模设一个显式上限并做压测，CrewAI 超过 20 个并发复杂 Agent 就调度失败这类阈值必须写进容量规划，国内做多智能体客服/风控编排的团队尤其容易在这上面翻车；其四，如果数据出境有硬约束，Pydantic AI + Temporal 这条「自托管 + 持久化引擎 + OpenTelemetry 自收」的组合，是目前开源选项里工程代价最小的一条路。
