2026 AI Agent 框架与平台对比:功能、GitHub 与生态分工
比较十个 AI Agent 框架与平台,提供官方 GitHub、功能与适用场景,解释哪些可以互相替代、哪些适合组合使用。
本文索引09
LangChain、LangGraph、OpenAI Agents SDK、CrewAI、Microsoft Agent Framework、Google ADK、PydanticAI 和 Mastra 提供了不同的代码开发方式。Dify 与 Langflow 则增加了可视化搭建应用的界面。比较这些项目时,需要知道它们分别能承担什么工作、哪些解决同一类需求,以及哪些可以搭配使用。
下面的表格直接链接到官方 GitHub。我选取十个项目,覆盖应用 SDK、有状态编排、几种语言生态和可视化交付方式。功能描述来自维护者的文档,核对日期为 2026 年 9 月 12 日。本文比较已公开的能力,没有做这些框架之间的性能基准测试。
GitHub 上的 AI Agent 框架:功能与适用场景
表格最后一列是采用前需要在自己项目里确认的问题,表示你需要安排的工作,不代表项目一定缺少对应功能。
| 项目与官方 GitHub | 主要角色 | 文档列出的能力 | 适合从什么任务开始,先确认什么 |
|---|---|---|---|
| LangChain | 应用开发框架 | 模型与工具集成、Agent 开发抽象 | 要连接多种模型或数据源的应用;需要多大程度地控制抽象之下的执行过程? |
| LangGraph | 有状态编排 | 图控制流、持久化、durable execution、人工介入 | 会暂停和恢复的任务;哪些状态与外部动作需要在中断后保留? |
| OpenAI Agents SDK | Agent SDK | Agent Loop、工具、handoff、session、guardrail、tracing | 在现有应用里接入可调用工具的 Agent;准备使用哪些模型、工具和追踪服务? |
| CrewAI | 多 Agent 与工作流框架 | 按角色协作的 Crews、事件驱动的 Flows | 按角色分工的研究或业务任务;哪些步骤转换应由 Flow 控制? |
| Microsoft Agent Framework | Agent 与工作流框架 | Python 和 .NET、多模型提供方、图工作流、checkpoint | 已有 Python 或 .NET 服务的团队;哪些托管和持久化组件需要自己运行? |
| Google ADK | Agent 开发框架 | 工具、多 Agent 组合、工作流执行、开发工具 | 正在评估 Google Agent 技术栈的团队;所选语言的 SDK 实际提供哪些能力? |
| PydanticAI | 带类型的 Python Agent SDK | 带类型的工具和依赖、结构化输出校验、模型集成 | 要把 Agent 结果交给现有 Python 程序;如何处理不合法或不完整的结果? |
| Mastra | TypeScript Agent 框架 | Agent、工作流、记忆、评估、暂停与恢复 | TypeScript 或 Node.js 产品;准备使用什么存储和部署方式支持工作流? |
同一项目的不同语言实现可能位于不同仓库:LangChain.js、LangGraph.js 和 OpenAI Agents SDK JavaScript/TypeScript 版 都有各自的包与文档。确认准备安装的那个实现,不能用 Python 示例推断另一个 SDK 的行为完全一致。
AI Agent 平台:Dify 与 Langflow
平台可以把工作流编辑、模型配置、知识接入和应用交付放在一起。除了 Agent 功能,还需要比较团队日常如何使用和维护它。
| 平台与官方 GitHub | 文档列出的能力 | 适合从什么任务开始 | 采用前需要检查 |
|---|---|---|---|
| Dify | 可视化工作流、RAG 管线、Agent 工具、模型管理、观测;云端和自托管选项 | 团队通过共享界面搭建与维护 AI 应用 | 工作空间管理、自托管运维、所需集成、许可证条件 |
| Langflow | 可视化组合、可编辑的 Python 组件、调试界面、API 与 MCP 服务 | 搭建还需要被其他应用调用的流程 | 自定义组件维护、部署、对外服务的访问控制 |
两者都提供可视化编辑,因此功能有重叠。从官方介绍看,Dify 更强调应用工作空间,Langflow 更强调组合流程并通过 API 或 MCP 提供调用。可以在两者中各搭一个相同的小流程,再判断这种侧重点对自己的团队是否重要。
仓库公开也不能直接说明所有使用方式都获许可。例如,Dify 的许可证包含附加条件,Mastra 的许可证映射则区分核心代码和企业目录。采用前应阅读对应代码及用途的许可条款。
哪些是竞品,哪些可以替代?
当你希望两个项目承担同一份工作时,它们才成为需要比较的候选方案。按任务整理候选,能把比较范围缩到实际需要的几个项目。
| 要做的决定 | 可以比较的候选 | 有用的比较任务 |
|---|---|---|
| 用 Python 做一个会调用工具的应用 | LangChain、OpenAI Agents SDK、PydanticAI | 调用相同工具,返回相同数据结构,检查校验和错误处理 |
| 编排有分支、会暂停的任务 | LangGraph、CrewAI Flows、Microsoft Agent Framework、Google ADK | 等待人工检查,中途重启进程,观察从哪里继续执行 |
| 在 TypeScript 产品中开发 Agent | Mastra、LangChain.js / LangGraph.js、OpenAI Agents SDK JS | 接上已有前后端,比较工作流存储和部署需要做的工作 |
| 让团队可视化编辑、发布流程 | Dify、Langflow | 搭建一个基于文档的助手,更新数据,再交给目标用户使用 |
这些是建议采用的评估任务,并非已经完成的横向测试结果。一个项目可能出现在多个场景里。先按主要需求选出候选,再检查它们能否满足其余要求。
LangChain 与 LangGraph 可以一起使用
LangChain 官方文档说明,其 Agent 建立在 LangGraph 之上。LangChain 提供较高层的接口和集成,LangGraph 让开发者更直接地控制执行和状态。可以从任一层开始,LangGraph 也能独立于 LangChain 使用。两者既涉及抽象层的选择,也属于同一套技术栈。
AutoGen 需要先看维护状态
旧的框架比较文章经常把 AutoGen 列为新项目的起点。它的当前官方 README已声明进入维护模式,并将新用户引向 Microsoft Agent Framework。已有 AutoGen 应用需要评估迁移成本,推荐方向变化不代表原来的应用立刻不能用。Microsoft 提供了 AutoGen 迁移指南。
生态分工:框架周围还需要什么?
一个 Agent 应用还需要模型、工具、执行位置,以及检查结果的方式。有些产品会把其中几项一起提供。
| 层 | 承担的工作 | 与上面候选项目的关系 |
|---|---|---|
| 模型服务 | 生成回答与工具调用请求 | 通过框架支持的模型接口接入 |
| Agent 框架与运行时 | 运行循环、分配工作、管理其 API 暴露的状态 | 前面比较的代码开发方案 |
| 应用平台 | 让人配置、发布和管理应用 | 可能在界面背后组合框架与运行时 |
| 执行环境与 Harness | 把模型、工具、文件、权限和工作环境接起来 | 要检查动作实际执行的位置;不同产品的术语和打包方式有差异 |
| MCP | 定义应用连接工具及其他外部上下文的协议 | 可以把框架或平台接到单独维护的服务上 |
| 搜索、检索及其他工具 | 在各自系统里获取或修改信息 | 主框架更换时可以继续独立使用 |
| 评估与观测 | 记录执行过程,按选定标准检查结果 | 用来比较候选实现、排查失败 |
MCP 官方介绍描述的是连接标准,因此 MCP Server 经常与编排框架搭配使用。采用 MCP 以后,应用仍需要决定何时调用工具、授予什么访问能力,以及如何使用返回结果。
概念的进一步解释见框架、平台、Harness 与 MCP 的边界指南。
一个例子:整理竞品简报的 Agent
假设任务是阅读官方文档,比较三个产品,最后给出带来源链接的简报。验收条件可以很具体:每条功能判断有出处,缺失的证据能看见,简报发送前由人检查。
模型帮助提取和解释差异,框架协调搜索、读取页面与写作。搜索工具发现资料,页面读取工具取得正文。如果检查过程会跨会话,才需要继续考虑持久化工作流状态;如果另一位同事要经常修改流程,可视化平台可能更合适。
这个任务并不自动需要多个 Agent。可以先用一个 Agent 加搜索和读取工具。若拆出研究与核查角色能改善已经观察到的问题,再用相同资料和验收条件,比较角色协作与原来较简单的实现。
做这个比较时,我会记录哪些判断有证据、哪些来源请求失败、中断后是否重复执行动作,以及每份完成的简报花了多少成本。这些观察才足以支撑一次选型决定。
Agent Search MCP 放在哪一层?
我维护的 Agent Search MCP 是通过 MCP 提供中英文网页搜索的工具服务。GitHub 仓库记录了可用来源、配置方法和限制。
它位于上表的搜索工具层。如果已经选好框架,接下来需要网页搜索,可以把它与原本准备使用的搜索 API 或提供方集成进行比较:自己的查询能找到什么来源,失败是否可见,Agent 收到的结果是什么格式。更多提供方的比较可以继续看 AI Agent 搜索 API 选型指南。
怎样用 GitHub 证据做选择?
Star 可以帮助发现项目。要做采用决定,还需要查看正在维护的包、许可证、发布记录,以及对应自己需求的示例。Issue 能暴露具体限制,但单看数量无法判断可靠性或采用程度。
对每个候选项目,从官方仓库找到准备使用的文档和版本,跑一个代表任务,再跑一个中断场景。记下版本、配置和观察到的结果,其他开发者才能复现这次比较。
这次 9 月修订用有来源的功能比较,替换了原文 6 月的热度表和市场预测,不提供当前 Star 数量或市场份额结论。准备把候选名单变成实现方案时,可以继续用框架选型指南逐项检查控制流、状态恢复、审批和部署。