开源AI代理框架大比拼：技术细节与开发者体验全解析

🧠 向所有学习者致敬！

“学习不是装满一桶水，而是点燃一把火。” —— 叶芝

---

我的博客主页： https://lizheng.blog.csdn.net

🌐 欢迎点击加入AI人工智能社区！

🚀 让我们一起努力，共创AI未来！ 🚀

---

我们都听说过 CrewAI 和 AutoGen，但你可能不知道，还有几十种开源的代理框架——而且其中很多都是在过去一年发布的。
好的，我将 Dify 添加到表格中，并翻译为中文。以下是更新后的表格：

希望这个表格对你有帮助！如果还有其他需要调整的地方，随时告诉我哦。
我简单测试了一些比较流行的框架，感受一下它们的工作方式以及上手的难易程度。所以，跟着我一起看看每个框架都有什么亮点吧。

重点关注的框架有 LangGraph、Agno、SmolAgents、Mastra、Pydantic AI 和 Atomic Agents。我们还会将它们与 CrewAI 和 AutoGen 进行比较。

如何比较不同的框架 | 图片由ida-silfverskiold提供

我们会探讨框架的实际功能、不同的设计选择、它们之间的差异，以及背后的思路。

AI Agentic

AI Agentic 本质上是围绕大型语言模型（LLMs）构建系统，让它们能够拥有准确的知识、访问数据的能力以及采取行动的能力。你可以把它想象成用自然语言来自动化流程和任务。

使用自然语言处理（NLP）进行自动化并不是什么新鲜事——我们已经用了好多年 NLP 来提取和处理数据了。新鲜的是，我们现在可以赋予语言模型更多的自由度，让它们能够处理模糊性并动态地做出决策。

动态路由与自然语言——LLMs 可以解释模糊性 | 图片由ida-silfverskiold提供

但仅仅因为 LLMs 能够理解语言，并不意味着它们就有自主性——或者甚至能理解你试图自动化的任务。这就是为什么构建可靠的系统需要大量的工程工作。

如果你对代理型人工智能感兴趣，想了解更多入门知识，可以看看我写的这篇文章 这里。

框架的作用是什么？

从根本上说，代理框架帮助你进行提示工程（prompt engineering）以及将数据路由到 LLMs 和从 LLMs 路由数据——但它们还提供了额外的抽象层，让你更容易上手。

如果你从头开始构建一个系统，让 LLM 使用不同的 API——工具——你得在系统提示中定义这些。然后，你会要求 LLM 在返回响应时附带它想要调用的工具，这样系统就可以解析并执行 API 调用。

提示被发送到 LLM 的示意图（实际的提示文本要长得多） | 图片由ida-silfverskiold提供

所以，归根结底，我们是在谈论提示工程——这是任何框架的基础。

框架通常在两个方面提供帮助：它正确地结构化提示，以确保 LLM 按正确的格式响应，并将响应路由到正确的工具——或者 API、文档或者其他东西。

当我们设置知识时，框架可能会允许始终包含它。这会作为上下文添加到提示中，类似于我们构建标准 RAG（Retrieval-Augmented Generation，检索增强生成）系统的方式。

框架还可以帮助处理诸如错误处理、结构化输出、验证、可观测性、部署等问题——并且通常帮助你组织代码，以便构建更复杂的系统，比如多代理设置。

不过，很多人觉得使用完整的框架有点小题大做。

问题是：如果 LLM 没有正确使用工具，或者系统出了故障，抽象层就会变得很痛苦，因为你不能轻松地调试它。如果你切换模型，系统提示可能为一个模型量身定制，而不能很好地转移到其他模型上。

这就是为什么有些开发者最终会重写框架的一部分——比如 LangGraph 中的 create_react_agent——以获得更好的控制。

有些框架比较轻量，有些比较重量级，提供额外的功能，但围绕它们有一个社区可以帮助你上手。一旦你学会了其中一个（包括它的底层工作原理），其他框架就更容易掌握了。

不同的开源框架

我们确实需要参考社区的意见，了解框架在实际应用中的表现如何。然而，最受欢迎的框架并不总是最佳选择。

我们都知道的有 CrewAI 和 AutoGen。

CrewAI 是一个高抽象度的框架，它通过隐藏底层细节，让你能够快速构建代理系统。AutoGen 则专注于自主的、异步的代理协作，代理们可以自由地按照自己的意愿进行协作——这可能使它更适合用于测试和研究。

流行且主流的库 | 图片由ida-silfverskiold提供

LangGraph 也是一个相当知名的系统，但值得特别强调，它是开发者的主要框架之一。它采用基于图的方法，通过代理连接节点。与其他两个相比，它为你提供了更严格的工程控制，不会假设代理应该有很大的自主性。

需要注意的是，许多人觉得 LangGraph 的抽象过于复杂，难以调试。它的理念是，虽然学习曲线陡峭，但一旦你掌握了基础知识，就会变得容易一些。

接下来，还有一些比较新的框架，我也想在这里介绍一下。

下一个要介绍的是 Agno（之前叫 Phi-Data），它专注于提供极佳的开发者体验。它还拥有我见过的最干净的文档之一。它非常即插即用，帮助你快速上手，有很多内置功能，这些功能被组织成逻辑清晰、干净的抽象，很有意义。

SmolAgents 是一个非常基础的框架，它引入了一个代理——CodingAgent——通过代码而不是 JSON 路由数据。它还让你可以直接访问 Hugging Face 模型库的全部内容。

代码代理通过代码而不是 JSON（大多数其他框架都是这样）路由数据 | 图片由ida-silfverskiold提供

至于那些不太常被提及的开源框架：

PydanticAI 基于 Pydantic 构建，几乎没有抽象，提供了一个非常基础的框架，高度透明。当你需要严格的类型安全和可预测、经过验证的输出，进行细粒度控制时，它非常有用，这使得调试也更容易。

Atomic Agents 是由一位代理构建者开发的，它使用基于模式的构建模块，你可以像搭积木一样将它们连接起来，重点在于结构和控制。它是为了解决缺乏在实践中表现良好的替代方案而开发的。

PydanticAI 和 Atomic Agents 的目标都是远离独立行动的黑盒人工智能。

Mastra 是由 Gatsby 团队创建的，是一个面向前端开发者的 JavaScript 框架，让他们能够在自己的生态系统中轻松构建代理。

不太主流的框架以及发布时间 | 图片由ida-silfverskiold提供

我们会逐一介绍这些框架的特点，以及它们之间的差异。

它们都具备的

大多数框架都具备相同的核心构建模块：支持不同的模型、工具、记忆和 RAG。

大多数开源框架或多或少都是模型不可知的。这意味着它们被构建为支持各种供应商。然而，正如前面提到的，每个框架都有自己的系统提示结构——而这种结构可能更适合某些模型而不是其他模型。

这也是为什么你最好能够访问系统提示，并且在需要时能够对其进行调整。

所有代理框架都支持工具，因为工具对于构建能够采取行动的系统至关重要。它们还使得定义自己的自定义工具变得容易，通过简单的抽象实现。如今，大多数框架都支持 MCP（Multi-Call Processing，多调用处理），无论是官方支持还是通过社区解决方案。

它们通常总是具备的功能的有趣插图 | 图片由ida-silfverskiold提供

重要的是要明白，并非所有模型都适用于函数调用，而这是使用工具所必需的。要确定哪些模型最适合作为基础 LLM，你可以查看 Hugging Face 的代理排行榜 这里。

为了使代理能够在 LLM 调用之间保留短期记忆，所有框架都利用了状态。状态帮助 LLM 记住早期步骤或对话中的部分内容。

大多数框架还提供了简单的选项来设置 RAG，使用不同的数据库为代理提供知识。

最后，几乎所有框架都支持 异步调用、结构化输出、流式传输以及添加可观测性的能力。

有些框架没有的

框架在某些方面会有所不同，例如支持多模态输入、记忆和多代理系统。有些框架为你处理这些，而有些则需要你自己来连接。

首先，一些框架有 内置的多模态处理解决方案——即文本、图像和语音。只要模型支持，你也可以自己实现这些功能。

正如前面提到的，短期记忆（状态）总是包含在内——没有它，你就不能构建一个可以使用工具的系统。然而，长期记忆的实现要复杂得多，这就是框架不同的地方。有些提供了内置解决方案，而有些则需要你自己连接其他解决方案。

框架名称	模型	数据传递方式	内存与 RAG	流式传输	可观测性	多模态支持	哲学/社区	多代理支持	团队/代理设置	工程化 vs 非工程化	自主性 vs 控制	抽象层次	开发者体验	问题/限制
Agno	支持20+供应商	JSON/对象（Pydantic）	内置内存与向量数据库/RAG	支持——按令牌级别流式传输	内置云仪表盘和日志集成	原生支持（文本、图像、音频、视频）	快速、灵活、透明的推理；社区正在壮大	预定义的主管/工作角色	内置团队对象，模式清晰	更易于访问：开箱即用的团队和工具对象，可最小化额外编码构建解决方案	低自主性	中等（到高）	良好	如果需要深度定制，可能无法暴露所有底层细节；一些高级编排可能需要额外编码
LangGraph	通过 LangChain 支持任何 LLM	显式状态（字典）	持久化状态；易于与外部内存集成	支持——通过图节点实时流式传输	与 LangSmith 和可视化图编辑器集成	主要是文本；可通过自定义节点扩展	通过显式编排实现完全控制；最适合复杂工作流	分层、逐步编排	通过图形设计每次交互	更技术化：你必须设计并连接流程图中的每个节点，因此需要更深入的工程知识	高控制：你显式定义每次交互；代理严格按你的设计行动	中等（到高）	学习曲线陡峭	需要牢固掌握图论和手动节点连接——随着系统扩展，复杂图形可能难以调试
SmolAgents	支持 Hugging Face 和 LiteLLM 模型	输出 Python 代码	内置短期记忆；自定义长期记忆	不原生支持；通常仅支持完整响应	最小化——依赖外部日志和临时工具	可通过外部工具实现（非原生）	极简主义且透明；吸引那些青睐以代码为中心的方法的人	通过 Python 调用手动组合	手动链接（从一个代理调用另一个代理）	面向开发者：最小化框架，代理是普通的 Python 函数，因此需要编码专业知识来设置	高自主性：代理“用代码思考”，自由决定调用工具或其他代理，提供大量自主性	低层次（基础）	良好	没有内置编排；你需要自己实现所有任务协调，使其不太适合复杂、分层的多代理系统。未为扩展而构建
Mastra	支持 Vercel AI SDK（OpenAI、Anthropic、Gemini 等）	强类型 TS/JSON	持久化工作流状态；原生 RAG 管道	支持——支持实时流式传输	内置 OpenTelemetry 追踪和仪表盘支持	通过集成支持多模态数据	有观点的、企业级的；适合生产 AI 应用	原生多代理工作流与仪表盘	完整的工作流引擎，支持团队和主管	混合型：其可视化仪表盘和 CLI 降低了非工程师的使用门槛，尽管初始配置仍然需要编码	低自主性：工作流引擎强制执行严格的角色和预配置路径，减少代理的自发决策	高层次	良好	高层次的抽象可能会隐藏底层细节，使得调试更加困难，并且如果你需要细粒度控制，灵活性会降低
Pydantic AI	通过简单扩展支持主要供应商	使用 Pydantic 模型进行依赖注入	使用依赖注入进行内存和 RAG 集成	支持——流式传输时立即验证	有限——可以与标准 Python 日志记录和 OpenTelemetry 集成	专注于文本；通过自定义依赖注入实现多模态	类型安全的“FastAPI”风格；可靠且适合生产环境	类型安全的链接（手动编排）	手动链接代理或通过简单图形	仅面向开发者：专为熟悉 Python/Pydantic 编码的人设计；不针对非技术用户	低自主性：严格的类型安全和模式验证意味着代理必须遵循预定的契约	低层次（基础）	良好	需要你构建自己的编排层和集成，增加大型系统的开发工作量
Atomic Agents	通过 Instructor 支持 OpenAI、Anthropic 等	定义的模式（“乐高积木”）	每个代理的内存和 RAG，通过向量数据库工具	支持——支持令牌和中间流式传输	默认最小化；推荐外部工具	原生支持多模态	模块化、可预测的“乐高积木”方法，用于可扩展、高效的代理	显式链接“乐高积木”以构建工作流	手动连接小型、可测试的模块	仅面向工程师：非常模块化的“乐高积木”方法，需要手动连接小型、可测试的单元；适合具有工程知识的团队	低自主性：每个模块都有严格的输入/输出契约，因此代理行为受到设计的严格限制	低层次（基础）	良好	缺乏内置编排；你必须手动连接每个模块，对于动态或复杂的多代理工作流来说可能很繁琐
Autogen	广泛支持并灵活路由	JSON 和函数调用	内置短期记忆；需要外部长期记忆	支持——原生支持流式响应	中等——包含内部日志但没有完整的仪表盘	主要是文本；可以扩展到其他模态	优先考虑代理的自由度以实现紧急协作，而不是严格控制	紧急的、自由形式的代理协作	代理自由自组织（结构不严格）	面向开发者：需要技术专业知识来配置自由形式的代理交互；它不是为免干预使用而设计的	高自主性：代理自由自组织并决定如何交互（导致更不可预测的紧急行为）	高层次	控制困难	高层次的抽象降低了开发者的控制能力，当代理行为不可预测时，诊断问题更具挑战性
CrewAI	为多个供应商提供统一 API	为团队提供结构化的 JSON	为团队集成有状态的内存和 RAG	支持——支持实时流式交互	集成仪表盘用于日志记录、监控和团队管理	支持多种模态（文本、图像等）	针对组织需求，提供分层团队监督	为多个团队设计，设有主管角色	为多团队设置设计，设有主管	混合型：由技术团队设计和设置，但提供集成仪表盘，让非技术用户可以管理团队配置和监督任务	低自主性：强制执行严格的团队角色和监督规则，确保可预测的代理间协作	高层次	设置困难，调试困难（特别是输出方面）	深层次的抽象可能会掩盖底层细节，使得定制和调试更加困难，尤其是在扩展到大量代理时
Dify	支持主流 LLM 模型	内置 JSON 数据传递	内置短期记忆；支持外部 RAG 集成	支持——实时流式传输	内置日志记录和简单仪表盘	原生支持文本和图像	简单易用，适合初学者和开发者	内置多代理支持，支持分层协作	内置团队对象，支持多种协作模式	更易于上手：提供开箱即用的团队和工具对象，适合非技术用户	低自主性：代理行为严格遵循预定义的规则	中等层次	良好	对于复杂工作流和大规模代理系统，灵活性可能不足；需要进一步扩展社区支持

框架在处理多代理能力方面也有所不同。 多代理系统允许你构建协作的或分层的设置，通过主管将多个代理连接起来。

大多数框架建议保持代理的专注——狭窄的范围和有限的工具集。这意味着你可能需要构建一个代理团队来处理复杂的流程。所有框架都允许你构建一个团队，但在扩展到多层级系统时，有些框架会变得复杂。

这就是 LangGraph 突出的地方——你可以构建节点，将它们连接到不同的主管，并且可视化不同的团队如何交互。在大规模构建多代理系统时，它是最灵活的。

Agno 最近增加了对团队的支持，包括协作和分层团队，但目前还没有太多关于更复杂、多层级系统的示例。

SmolAgents 允许你将代理连接到主管，但随着系统的增长，它可能会变得复杂。 它让我想起了 CrewAI 是如何构建代理团队的。Mastra 也有类似的结构。

对于 PydanticAI 和 Atomic Agents，你需要手动连接代理团队，所以编排工作落在你身上。

你也可以在这个 仓库 中找到一个表格，对各类框架有更好的概述。

它们的不同之处

框架在抽象程度、给予代理的自主性以及你需要编写多少代码才能让东西运行起来方面有所不同。

首先，有些框架强调包含许多内置功能，让你能够快速上手。

我觉得 Mastra、CrewAI 和在一定程度上 Agno 都是即插即用的。

不同框架的高与低抽象程度 | 图片由ida-silfverskiold提供

LangGraph 也有相当程度的抽象，但它采用基于图的系统，你需要手动连接节点。这给了你更多的控制权，但也意味着你必须自己设置和管理每一个连接，这带来了 更陡峭的学习曲线。

然后我们有低抽象程度的框架，如 PydanticAI、SmolAgents 和 Atomic Agents。

这些框架强调透明性，但你通常需要自己构建编排。 这给了你完全的控制权，并且有助于调试——但它也增加了构建的时间。

另一个不同点是框架假设代理应该有多少自主性。有些框架建立在 LLMs 应该足够聪明，能够自己完成任务的想法上。 其他框架则倾向于严格控制——给代理一个任务，一步步引导它们。

AutoGen 和 SmolAgents 属于第一类。其余的则更倾向于控制。

不同框架的高与低自主性 | 图片由ida-silfverskiold提供

这里还有一个需要考虑的问题：当开发者构建强调严格控制的框架时，往往是因为他们还没有找到一种方法让代理自己工作——至少目前还不可靠。

这个领域也越来越像工程学了。

如果你要构建这些系统，你确实需要懂得如何编程。真正的问题是这些框架在技术要求上有多大的不同。

不同框架所需的开发经验水平 | 图片由ida-silfverskiold提供

如果你是初学者，选择 CrewAI、Agno 或 Mastra 可能是个好主意。

SmolAgents 对于简单用例来说也相当直接。

至于 PydanticAI、Atomic Agents 和 LangGraph——你将需要自己编写更多的逻辑。不过说句公道话，你总是可以构建一个代理来帮助你正确地构建代码结构。

如果你完全不懂编程，那么可以看看 Flowise 或 Dify。

最后，值得一提的是 这些框架的开发者体验。

从我所见，大多数开发者发现 CrewAI 和 AutoGen 很难调试。SmolAgents 的 CodeAgent 引入了一种新颖的方法，代理通过输出代码来路由数据——这是一个很酷的想法，但并不总是按预期工作。

LangGraph，特别是与 LangChain 配对时，有一个陡峭的学习曲线，以及一些你可能需要拆开并重新构建的令人困惑的抽象。

PydanticAI 和 Atomic Agents 通常受到开发者的喜爱，但你需要自己构建编排。

Agno 和 Mastra 是不错的选择，但你可能会遇到诸如循环调用等问题，这些问题很难调试。

一些注意事项

最好的开始方式就是直接动手尝试。但我希望这为你提供了一个开源框架的合理概述——以及什么可能适合你。

这只是一个比较浅的概述，因为我还没有深入探讨企业级可扩展性或操作稳健性等问题。如果你正在构建这方面的内容，你需要单独研究这些部分。

有些开发者说，AI 代理框架是抽象的最糟糕的形式——它们通常比直接使用官方 LLM 提供商的 SDK 更加复杂。

我把这个决定留给你来判断。

完整的代理框架列表可以在这里找到 这里。