AI Agent 框架选择指南：Portia AI 实践

如果你想用 Portia AI 构建 agent，可以在 Github 上免费试用我们的 SDK。欢迎点赞！

考虑到"AI Agent SDK"这个词在 Google Trends 上 6 个月前的热度为 0，现在有大量 AI Agent 构建工具出现。

乍一看，很难区分它们的差异，也不清楚哪一个适合你的用例。为了显得"适配"尽可能多的人，每个产品都用同样的措辞来描述自己。

在 Portia AI 花了几周时间研究市场后，我意识到写一篇高层次的文章来介绍不同的 Agent 构建工具以及如何在它们之间做出选择会很有用。

当你想快速自动化某些事物且不写太多代码时

这个类别包括 n8n、MindStudio 和现在的 CrewAI。这些产品既面向商业用户，也面向工程师。它们的设计宗旨是易于使用，可以用可视化工作流而不是代码来设置。它们用简洁性换取控制力，因此灵活性较差，你不会拥有代码优先产品那样细粒度的选项。非常适合原型设计和尝试新想法，或者如果你有一个非常简单的生产用例。如果你要为银行构建一个 KYC agent，你会希望能够内置更多的监督机制。

MindStudio 的设计目的是使用模板和无代码方式快速启动和运行 AI agent。当你想快速推进且集成了主流 LLM 提供商时非常有用。它还内置了工具，你可以用来轻松为 agent 装备功能。它最适合用于简单的 AI 工作流，你可以在几分钟内原型化，例如一个总结页面上所见内容的 agent。

n8n 更像 Zapier。它在连接事物以自动化现有业务流程时最强大。虽然可视化构建器是入口点，但它可以用代码扩展。它开箱即用支持非常庞大的 LLM、数据库、API 和工具库，这意味着你不需要为现有流程构建自己的集成。它最适合于你过去会用 Zapier 做的那种简单自动化，例如，当有人提交我们的潜在客户表单时给我发送电子邮件，并在我们的 CRM 中添加记录。它不太适合需要多步推理或内存管理的长时间运行或复杂自主任务。

CrewAI 过去因为他们的开发者 SDK 产品而闻名，但他们现在也为无代码工作流构建了工具。他们结合了可视化、无代码和低代码的界面以及开发者体验。你可以创建多 agent 系统，使用一个领导 AI 来判断需要什么以及以什么顺序进行，然后委派给其"团队"中的专家 agent。这可能不可预测，因为你依赖领导 agent 来保持对所有事物的控制。他们现在引入了"流"（flows）的概念来帮助抵消这一点。你可以使用条件逻辑、循环和状态管理来定义 agent 需要采取的确切步骤和顺序。你失去了一些自主性和灵活性，但这提高了可靠性，使你的 agent 更容易审计。我很想看他们如何在无代码体验和解决方案驱动的方法与开发者产品的开发之间优先考虑变化。他们的网站现在强调前者。

当你需要对关键用例的 agent 拥有更多控制权时

这些是程序员使用的有主见的库或 SDK 来构建他们的 agent。它们是代码优先框架，没有无代码选项。比开箱即用和模块化的解决方案需要更多工作才能入门，但你会获得细粒度的控制和透明度。如果你正在构建多 agent 系统，这是你想要的监督和控制级别。如果你不是，那么你可以先试试上面的一些解决方案，如果它们没有给你需要的监督，再升级到这些 SDK 中的一个。

LangChain / LangGraph： LangChain 给你构建块，想象提示、内存和工具包装器，这样你可以从头开始构建自己的 agent。它是这个抽象级别最受欢迎的工具之一，因为它支持你可能想使用的基本上所有模型、工具和数据库。LangChain 使用允许你链接 LLM 调用并让模型决定接下来做什么的架构。它非常适应性强，但与任何 AI agent 一样，增加自主性意味着你失去一些控制。调试问题所在可能很困难。LangGraph 构建在 LangChain 之上，引入了更具声明性的、有状态的图架构。你明确定义 agent 步骤的流程，获得更好的可见性和控制。它也支持人工检查点，所以你可以暂停以获得手动批准。它是开源的，可以免费尝试。

Portia AI： 也是开源和开发者导向的。它是我们的产品，我们构建它是为了成为生产级的 agent 编排框架。它比本节提到的其他工具更有主见，因为我们内置了我们认为生产 agent 应该如何组合的方式。你可以与规划 agent 来回互动以创建结构化的计划。然后它将其分解为多步工作流，计划就变成不可变的。执行 agent 随后执行计划。你也可以开箱即用地添加"升级点"，其中 agent 需要在满足特定条件时向人工核查。还有内置的身份认证、集成工具如 Slack、GitHub、Zendesk、Google 和 1000+ 工具，你可以通过 MCP 服务器访问。它针对可预测性、可审计性和安全性重要的行业，以及你想要指导如何构建生产级 agent 的行业。它的级别高于 LangGraph 和 Pydantic。

Pydantic AI： Pydantic 给你工具按照你的方式构建生产级 agent，但这很复杂。它是为具有关于他们希望 agent 架构如何查看的强硬观点的工程师构建的。你将 agent 定义为具有结构化输入和输出类型、系统提示和函数调用工具的 Pydantic 模型。它是模型无关的，与 Pydantic Logfire 紧密集成以进行实时调试和可观察性。Agent 是可重用的、类型安全的，可以使用依赖注入来实现上下文/工具。流响应会被持续验证正确性。你仍然需要设计工作流、提示模板、工具逻辑和编排。然而，框架抽象了验证、结构和运行时安全，使在 Python 中构建生产级 agent 更容易。

当你想利用你已经使用的平台并将所有东西连接起来时

这些框架为创建 AI agent 提供了脚手架，但如果你已经深入 Google、OpenAI 和 Amazon 生态系统，并且不想向堆栈中添加新的提供商，其主要好处就体现出来了。

OpenAI Agent SDK： 它通过创建一些轻量级的抽象如 agent 循环、工具注册、对其他 agent 的切换和追踪来提供脚手架。然后由你来创建 agent、定义工具和护栏以将其投入生产。内置的可追踪性超级有用，SDK 在底层与任何 LLM 互操作。如果你想要一些轻量级的、代码优先的东西来构建你的第一个 agent，这是一个不错的选择。

OpenAI Agent SDK： 它通过创建一些轻量级的抽象如 agent 循环、工具注册、对其他 agent 的切换和追踪来提供脚手架。然后由你来创建 agent、定义工具和护栏以将其投入生产。内置的可追踪性超级有用，SDK 在底层与任何 LLM 互操作。如果你想要一些轻量级的、代码优先的东西来构建你的第一个 agent，这是一个不错的选择。

Google 的 ADK（agent developer kit） 是另一个开源、代码优先的工具包。它帮助开发者构建使用动态推理或强制某种结构的 agent 系统。它提供了不同的内置 agent 类型（循环、并行、LLM 驱动），你可以根据需要的控制程度围绕这些类型设计工作流。如果你在该生态系统内自动化事物，它有 Google 服务的内置工具。开箱即用的内存处理也超级有帮助。你仍然需要计算出 agent 逻辑、提示和连接所有东西。但它很灵活，抽象了 agent 设计中的一些更复杂的领域。

Google 的 ADK（agent developer kit） 是另一个开源、代码优先的工具包。它帮助开发者构建使用动态推理或强制某种结构的 agent 系统。它提供了不同的内置 agent 类型（循环、并行、LLM 驱动），你可以根据需要的控制程度围绕这些类型设计工作流。如果你在该生态系统内自动化事物，它有 Google 服务的内置工具。开箱即用的内存处理也超级有帮助。你仍然需要计算出 agent 逻辑、提示和连接所有东西。但它很灵活，抽象了 agent 设计中的一些更复杂的领域。

Amazon Bedrock 是另一个生产就绪的 agent 工具包。它有一个可视化构建器和模块化的服务，如内存、网关和代码解释器。你可以连接 agent 到你的 API、Lambda 函数和已经在 Amazon 上运行的知识库开箱即用。它现在也支持内存保留而无需你自己实现它。与 Google ADK 一样，你仍然需要设计 agent 逻辑、编排、提示和集成流程，但 Amazon AgentCore 帮助管理关键基础设施：会话隔离、可观察性、身份和工具访问。

Amazon Bedrock 是另一个生产就绪的 agent 工具包。它有一个可视化构建器和模块化的服务，如内存、网关和代码解释器。你可以连接 agent 到你的 API、Lambda 函数和已经在 Amazon 上运行的知识库开箱即用。它现在也支持内存保留而无需你自己实现它。与 Google ADK 一样，你仍然需要设计 agent 逻辑、编排、提示和集成流程，但 Amazon AgentCore 帮助管理关键基础设施：会话隔离、可观察性、身份和工具访问。

我应该选哪一个？

如你从这篇文章可以看出，没有"最好的"产品。你需要在构建 agent 系统时弄清楚你想要做出什么权衡。以下是一些可以帮助你做出选择的问题：

谁在构建 agent，开发者还是其他业务部门？

你需要对 agent 有多少控制权？

你需要一个 agent 还是很多？

你正在创建快速测试的东西还是关键的基础设施？

你对 agent 应该如何构建有强硬看法还是在寻求指导？

你想要或需要自己构建多少？

你在多大程度上被特定供应商锁定？

新的框架和工具一直在出现，所以我们预计这些工具会随着时间的推移开始看起来更相似。同样，随着 MCP 标准的推出和 A2A 的出现，随着标准的建立，事物很可能会变得更具互操作性，而不是更少。框架不是互相排斥的，你可以根据你在开发生命周期中的位置以及对上述问题的回答来选择正确的方法。无代码工具可以提供快速原型但受到限制。如果你需要灵活性和控制，那么中层的有主见的框架是一个强势的选择。如果你有一个大型开发团队和一套非常自定义的设置，那么从基础提供商 SDK 开始可以给你需要的细粒度控制。祝你好运！