跳到主要内容
返回写作

2026 AI Agent 框架与平台对比:功能、GitHub 与生态分工

比较十个 AI Agent 框架与平台,提供官方 GitHub、功能与适用场景,解释哪些可以互相替代、哪些适合组合使用。

本文索引09
  1. 01GitHub 上的 AI Agent 框架:功能与适用场景
  2. 02AI Agent 平台:Dify 与 Langflow
  3. 03哪些是竞品,哪些可以替代?
  4. 04LangChain 与 LangGraph 可以一起使用
  5. 05AutoGen 需要先看维护状态
  6. 06生态分工:框架周围还需要什么?
  7. 07一个例子:整理竞品简报的 Agent
  8. 08Agent Search MCP 放在哪一层?
  9. 09怎样用 GitHub 证据做选择?

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 SDKAgent SDKAgent Loop、工具、handoff、session、guardrail、tracing在现有应用里接入可调用工具的 Agent;准备使用哪些模型、工具和追踪服务?
CrewAI多 Agent 与工作流框架按角色协作的 Crews、事件驱动的 Flows按角色分工的研究或业务任务;哪些步骤转换应由 Flow 控制?
Microsoft Agent FrameworkAgent 与工作流框架Python 和 .NET、多模型提供方、图工作流、checkpoint已有 Python 或 .NET 服务的团队;哪些托管和持久化组件需要自己运行?
Google ADKAgent 开发框架工具、多 Agent 组合、工作流执行、开发工具正在评估 Google Agent 技术栈的团队;所选语言的 SDK 实际提供哪些能力?
PydanticAI带类型的 Python Agent SDK带类型的工具和依赖、结构化输出校验、模型集成要把 Agent 结果交给现有 Python 程序;如何处理不合法或不完整的结果?
MastraTypeScript 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 产品中开发 AgentMastra、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 数量或市场份额结论。准备把候选名单变成实现方案时,可以继续用框架选型指南逐项检查控制流、状态恢复、审批和部署。