原文: https://blog.langchain.dev/how-to-think-about-agent-frameworks/
原著者: LangChain
发布时间: 2025-04-20
翻译时间: 2025-05-06
译者: Soulter

TL;DR:

• 构建可靠的 Agentic 系统最难的部分是确保 LLM 在每一步都拥有正确的上下文。这包括控制正确的内容进入 LLM 上下文以及执行正确的步骤去生成相关的内容。
• Agentic 系统同时包括 Workflows 和 Agents 两者（和一切这两者之间的事物）。
• 大多数 Agentic 框架既不是声明式也不是命令式的编排框架，而只是一组代理抽象。
• Agent 抽象可以很容易去构建，但是他们通常会造成混淆，并难以确保 LLM 在每一步都有正确的上下文。
• 各种不同的 Agent 系统都受益于同样的一组有用的功能，这些功能可以由框架提供也可以自行从头构建。
• LangGraph 被公认为是一个同时包含声明式和命令式的编排框架，封装了一系列的 Agent 抽象。

OpenAI 最近发布了一份关于构建代理的指南，这其中可能包含了一些误导性的观点，如下图所示：

这个呼吁最初让我很生气，但是当我开始去撰写回应时，我意识到：思考一个 Agent 框架出来是很复杂的一件事！可能有 100 个不同的 Agent 框架，并且有大量不同的维度去比较这些 Agent 框架，有时他们会让人觉得混淆。现在网络上也有很多关于不同 Agent 框架的炒作、姿态和噪音，但是却很少有对于 Agent 框架的精确分析和思考。这篇博客就是我们这样做的尝试，它将包含：

1. 背景
   1. Agent 是什么？
   2. 构建 Agent 最难的部分是什么？
   3. 什么是 LangGraph
2. Agentic 框架的风格
   1. “Agents” vs “Workflows”
   2. 声明式 vs 非声明式
   3. Agent 抽象
   4. Multi Agent
3. 普遍的问题
   1. 框架的价值是什么？
   2. 当模型的性能变得更好时，Workflows 的生态位会被 Agents 挤占吗？
   3. OpenAI 的看法有什么错误？
   4. 如何比较所有的 Agent 框架？

背景

一些有用的背景信息，帮助大家理解剩下的博客内容。

Agent 是什么？

目前，对于 Agent 没有一致的定义，并且通常通过不同的视角来提供。

OpenAI 采用更高层次、更具有思想领导力的方式来定义 Agent。

Agent 是一个能够代表你独立完成任务的系统。

我个人不喜欢这个观点。这是一个模糊的陈述，没有帮助我理解 Agent 到底是什么。这只是一个思想领导力（译者注: thought-leadership 不知道怎么翻译），并不实用。

对比 Anthropic 的定义：

“Agent” 可以通过不同方式来定义。一些客户将 Agent 定义为可以在较长时间内独立运行的，能够使用多种工具去完成复杂任务的完全自主系统。而其他一些客户使用特定的术语去描述一个更加规范的实现，比如预定义的工作流。在 Anthropic，我们将这些各种各样的变体归类为 Agent 系统，但是在 Workflows 和 Agents 之间给予了明确的架构区别：

Workflows 是一个通过预定义的代码路径将大语言模型和各种工具精心策划好的系统。

Agents，是一个由大语言模型动态自行指导任务进程和工具使用的系统，它们自行控制着如何完成任务。

我更喜欢 Anthropic 的定义，基于以下几点原因：

1. 他们的定义更加精确和偏向技术。
2. 他们也引用了 Agenic 系统的概念，并且将 Workflows 和 Agents 二者都归类为 Agentic 系统的变体。我尤其喜欢这一点。

几乎所有我们所见到的“Agentic 系统”产品都是“Workflows”和“Agents”的结合。

在 Anthropic 博客的最后，它们将 Agent 定义为“…典型地只是大语言模型在一个循环中基于环境反馈而使用工具的过程”。

尽管它们一开始给 Agent 所做的定义过于宏大，但这基本上也是 OpenAI 的意思。

这些类型的 Agent 可以被参数化为：

1. 模型的使用
2. Instruction(system prompt) 的使用
3. 工具的使用

你在一个循环中调用模型，如果/当模型决定去使用一个工具，你就去运行那个工具，然后取得一些发现/反馈（Observation/feedback）。然后，将这些信息回传给模型。你就这样运行直到模型不再打算去使用任何工具（或者它使用了一个专门用于标识结束循环的工具）。

OpenAI 和 Anthropic 都认为 Workflows 是一种与 Agents 不同的设计模式。模型使用会导致可控性变差，工作流会更具确定性。这就是一个有用的区别！

OpenAI 和 Anthropic 都明确地认为你并不总是需要使用 Agents。在很多场景下，Workflows 更加简单、可依赖、便宜、快速和高性能。下面是一个来自 Anthropic 博客的一个很好的引用：

当使用大语言模型构建应用时，我们推荐找一些可能的最简单的解决方案，只在需要的时候增加复杂性。这可能意味着不一定需要构建一个 Agentic 系统，Agentic 系统通常会牺牲延迟和费用来换取更好的性能，你应该权衡这种交换何时才有意义。

当需要增加复杂性时，Workflows 对于一些定义良好的任务来说会带来可预测性和一致性，然而对于一些需要大规模灵活性和模型驱动决策的任务来说，Agents 是一个更好的选择。

OpenAI 说得更简单：

在致力于构建一个 Agent 之前，请验证你的用力能够清晰地满足这些标准，否则，确定性的解决方案可能就够了。

在实践上，我们可以看到大部分“Agentic 系统”都是这二者的结合。这就是我为什么讨厌讨论什么东西是一个 Agent，但是更喜欢讨论系统如何具有代理性（agentic）。向伟大的 Andrew Ng 致敬，感谢他有这样的思考方式：

与其不得不二元地选择某物到底是不是 Agent，我认为，更有用的思考方式是某个系统到底像 “像 Agent” 到了什么程度。不像 “Agent” 这个名词，“Agentic” 这个形容词让我们去深入思考这些系统，并且将所有这些系统都纳入这个不断发展的运动中。

构建 Agent 最难的部分是什么？

我认为大部分人都同意构建 Agent 是有难度的。或者，换句话说，构建一个 Agent 的原型很容易，但是构建一个可依赖的，能够支撑关键业务的应用程序呢？很难。

最艰难的部分绝对是——让 Agent 系统可依赖。你可以做好一个看起来很好的 Demo 然后发到推特上，这很容易，但是你可以让它变成一个能够支撑关键业务的应用程序吗？不做大量工作是不行的。

我们在几个月前做了一个关于 Agent 开发者的调查，我们问他们：“你们让 Agent 生产可用的最大的限制是什么？”排在第一的回应是“性能质量”。让这些 Agent 发挥作用仍然很困难。

是什么导致了 Agent 经常的糟糕的表现？大语言模型搞砸了。

为什么大语言模型搞砸了？两点原因：1. 模型不够好 2. 错误的（或者不完整的）上下文被传递给了模型。

从我们的经验来说，通常是第二点。什么原因导致了这个？

1. 不完整或者短的 system 信息。
2. 模糊的（vague）用户输入
3. 模型没有使用正确的工具
4. 糟糕的工具定义
5. 没有传递正确的上下文给模型
6. 糟糕的工具响应

构建值得信赖的 Agentic 系统最难的部分是确保大语言模型在每一步都拥有正确的上下文。这包括控制正确的内容进入大语言模型上下文以及执行正确的步骤去生成相关的内容。

当我们讨论 Agent 框架时，记住这一点会很有帮助。任何使控制传递给大语言模型的内容变得更加困难的框架都只会阻碍你。向大语言模型传递正确的上下文已经够难了 - 为什么你要让自己变得更难呢？

什么是 LangGraph

// 请参考原文

Agentic 框架的风格

Agentic 框架在几个维度上有一些不同。理解 - 而不是混淆 - 这些维度是正确比较这些 Agentic 框架的关键。

Workflows vs Agents

大多数框架包含了高层次的 Agent 抽象。一些框架包含了一些常见的工作流的抽象。LangGraph 是一个较为底层的精心策划的 Agentic 框架，支持 Workflows、Agents 和任何这两者的中间形态。我们认为这是至关重要的。正如上面所提到的，大多数 Agentic 系统产品都是 Workflows 和 Agents 的结合，一个生产可用的框架需要同时支持这两者。

让我们回想一下构建可靠的 Agents 中难的一部分 - 确保大语言模型拥有正确的上下文。Workflows 能够有用的一部分原因就是它能很容易地将正确的上下文传递给大语言模型——由你来决定数据如何周转。

当你在思考应该在 Workflow 到 Agent 的哪个范围内构建应用程序时，你应该考虑以下两点：

1. 可预测性 vs 代理性（Agency）
2. 门槛低，天花板高

可预测性 vs 代理性(Agency)

当你的系统变得更加 Agentic，那他就会变得更加无法预测。

有时候你会因为用户信任、合规性或者其他原因而想要或者你需要系统变得可预测。

可靠性并不 100% 和可预测性相关，但是在实践上它们关系非常密切。

你希望在这条曲线上的位置与你的应用程序息息相关。LangGraph 可用于在这条曲线的任何位置构建应用程序，让你能够移动到您想要的曲线位置。

门槛高但天花板低

当考虑框架时，考虑他们的下限和上限是很有帮助的一件事：

• 低门槛：一个低门槛的框架对初学者很友好
• 高门槛：一个高门槛的框架意味着陡峭的学习曲线，需要较多的知识储备才能高效地使用。
• 天花板低：一个天花板低的框架意味着其可以实现的功能有限（你很快会超越它）
• 天花板高：一个天花板高的框架为高级应用场景提供了广泛的能力和灵活性（它会随着你一起成长？）

Workflow 框架提供了高天花板，但也带来了高门槛 - 你不得不自行写很多 Agent 逻辑。

Agent 框架是低门槛的，但也有着低天花板 - 你很容易上手，但对于非平凡的场景还不够。

LangGraph 的目标是既具有低门槛（内置 Agent 抽象能够很容易上手）也具有高天花板（低级功能，以实现高级用例）

声明式 vs 非声明式

声明式的框架由几大优点，但也存在缺点。这似乎在程序员间是一个永无止境的争论，每个人都有自己的偏好。

当人们谈到非声明式时，他们通常会暗示命令式作为替代。

大多数人们将 LangGraph 作为声明式的框架，这只对一部分。

首先，当连接好节点和边（workflow）后，这些只不过是一些 Python 或者 TypeScript 的函数而已。因此，LangGraph 是声明式和命令式的混合体。

其次，除了推荐的声明式 API 之外，我们实际上还支持其他 API。具体来说，我们同时支持函数式 API 和事件驱动 API。虽然我们认为声明式 API 是一种有用的思维模型，但我们也意识到它并不适合所有人。

关于 LangGraph 的常见评论是，它类似于 Tensorflow（声明式深度学习框架），而 Agents SDK 等框架类似于 Pytorch（命令式深度学习框架）。

这完全是错误的。像 Agents SDK（以及最初的 LangChain、CrewAI 等）这样的框架既不是声明式的也不是命令式的——它们只是抽象。它们有一个代理抽象（一个 Python 类），其中包含一系列运行代理的内部逻辑。它们实际上不是编排框架。它们只是抽象。

Agent 抽象

大多数 Agent 框架包含一个 Agent 抽象。他们通常以涉及一个 prompt、模型和工具开始。之后他们会增加一小部分参数…然后再增加一些…然后再增加更多。到最后你会得到一连串的控制多种行为的参数，所有这些参数都会抽象到一个类内。如果你想了解发生了什么，或者改变逻辑，你必须进入类并修改源代码。

这些抽象最终使得理解或控制大模型各个步骤中的具体内容变得非常困难。这一点很重要——拥有这种控制对于构建可靠的 Agent 至关重要（如上所述）。这就是代理抽象的危险所在。

我们经历了惨痛教训才明白这一点。这正是最初 LangChain 链和 Agents 的问题所在。他们提供的抽象实际上阻碍了实际操作。两年前的原始 Agent 抽象只是一个 Agent 类，包含一个模型、一个 prompt 和一些工具。这不是新概念。这没有提供足够的控制权（给到用户），现在也是如此。

需要明确的是，这些 Agent 抽象确实有其意义。他让上手变得简单，但是我认为这些 Agent 抽象不足以构建一个可靠的 Agent（甚至永远也不够）。

我们认为最好的去思考这些 Agent 抽象的方式是像 Keras 那样。它们提供了更高级的抽象去让上手变得简单。但是至关重要的一点是它们是基于一个更低级的框架，这样你就不会超越它。

这就是为什么我们已经在 LangGraph 之上构建 Agent 抽象，者提供了更加简单的方式去上手 Agents，但是如果你想要跳转到更低级的 LangGraph，那你也可以轻松做到。

Multi Agent

通常情况下，Agentic 系统不仅包含一个 Agent，可能会有多个。OpenAI 在报告中这样写：

对于很多复杂的 Workflows，分割 prompts 和工具给多个 Agent 能够带来更好的性能和可扩展性。当你的 Agents 无法遵循复杂的 instructions 或者始终选择了错误的工具时，你可能需要去进一步划分你的系统并引入更多不同的 Agents。

Multi Agent 系统的核心是这些 Agents 之间如何交流。同样的，构建 Agents 的难点在于找到合适的上下文给大语言模型。这些代理之间的交流至关重要。

有很多方式能做到这一点！Handoffs 是其中一种方法。这也是来自 Agents SDK 的代理抽象，我很喜欢这一点。

但是最好的方式有时其实是 Workflows。参考 Anthropic 的博客中的所有工作流程图，并将所有的大语言模型调用替换成 Agents。这种 Workflows 和 Agents 的结合有时候能够带来最佳的可靠性。

同样的，Agentic 系统不仅仅是 Workflows，也不仅仅是一个 Agent。他可以是也经常是这两者的结合。正如 Anthropic 指出的：

请组合和定制这些模式。

这些构建块并不一定是规定性的。它们是开发者可以根据不同应用场景进行调整和组合的通用模式。

常见问题

框架的价值是什么？

我们经常看到有人问，构建 Agent 系统是否需要一个框架？Agent 框架能提供什么价值？

Agent 抽象

框架通常很有用，因为它们包含实用的抽象，这使得入门变得简单，并为工程师提供了一种通用的构建方式，从而更容易上手和维护项目。正如上面提到的，Agent 框架确实也有其缺点。对于大多数 Agent 框架，这是它们提供的唯一价值。我们非常努力地确保 LangGraph 不会出现这种情况。

短期记忆

如今，大多数 Agent 应用都​​涉及某种多轮（例如聊天）组件。LangGraph 提供了生产可用的存储，以实现多轮体验。

长期记忆

虽然还处于早期阶段，但我非常看好 Agent 系统能够从自身经验中学习（例如，跨对话记忆信息）。LangGraph 为跨对话记忆提供了可用于生产的存储。

Human-in-the-loop

许多 Agent 系统通过一些 human-in-the-loop 组件得到了改进。例如，获取用户反馈、批准工具调用或允许编辑工具调用参数。LangGraph 提供了内置支持，以便在生产系统中实现这些工作流程。

Human-on-the-loop

除了允许用户在 Agent 运行时影响其运行之外，允许用户在 Agent 运行结束后检查其轨迹，甚至可以返回到之前的步骤，然后从那里重新运行（包含更改）也非常有用。我们称之为 human-on-the-loop，LangGraph 内置了对此的支持。

Streaming

大多数 Agent 应用程序需要一段时间才能运行，因此向最终用户提供更新对于提供良好的用户体验至关重要。LangGraph 提供内置的 streaming of tokens、graph steps 和 arbitrary streams。

Debugging/observability

构建可靠 Agent 的难点在于确保将正确的上下文传递给大语言模型。能够检查 Agent 执行的确切步骤以及每个步骤的确切输入/输出对于构建可靠 Agent 至关重要。LangGraph 与 LangSmith 无缝集成，提供一流的调试和可观察性。注意：AI 可观察性与传统的软件可观察性不同（这值得另文探讨）。

Fault tolerance

容错是构建分布式应用程序的传统框架（如 Temporal）的关键组成部分。LangGraph 通过持久的工作流和可配置的重试机制，使容错变得更加简单。

Optimization

与其手动调整 prompt，有时更容易的是定义一个评估数据集，然后基于此数据集自动优化代理。LangGraph 目前不支持此功能——我们认为现在实现此功能还为时过早。但我想将其纳入其中，因为我认为这是一个值得考虑的有趣维度，也是我们一直在关注的领域。dspy 是目前最好的框架。

所有这些价值主张（除了 Agent 抽象之外）都为代理、工作流以及介于两者之间的一切提供了价值。

所以，你真的需要一个 Agentic 框架吗？

如果你的应用程序不需要所有这些功能，或者你想自己构建这些功能，那么你可能不需要。其中一些功能（例如短期记忆）并不复杂。其他一些功能（例如 human-on-the-loop，或特定于大语言模型的可观测下）则更为复杂。

关于 Agent 抽象，我同意 Anthropic 在其文章中的观点：

如果你确实在使用一个框架，确保你了解底层代码。对底层原理的错误假设是客户错误的常见来源。

当模型的性能变得更好时，Workflows 的生态位会被 Agents 挤占吗？

支持 Agent 的一个常见的论调是，虽然现在不起作用，但是将来会起作用。因此你只需要简单的，工具调用的 Agent。

我认为有多种情况是正确的：

• 工具调用 Agent 的性能肯定会提升
• 控制传递给大语言模型的上下文的内容仍然很重要（garbage in, garbage out）
• 对于一些应用，工具调用循环已经足够了
• 对于一些其他应用，Workflows 一定会更简单、更便宜、更快和更好。
• 对于大多数应用，Agentic 系统的产品是 Workflows 和 Agents 的结合。

我认为 OpenAI 或 Anthropic 不会辩论这些观点。Anthropic 的帖子是这么说的：

当使用大语言模型构建应用时，我们推荐找一些可能的最简单的解决方案，只在需要的时候增加复杂性。这可能意味着不一定需要构建一个 Agentic 系统，Agentic 系统通常会牺牲延迟和费用来换取更好的性能，你应该权衡这种交换何时才有意义。

OpenAI 是这么说的：

在致力于构建一个 Agent 之前，请验证你的用力能够清晰地满足这些标准，否则，确定性的解决方案可能就够了。

是否存在这种简单的工具调用就足够了的应用？我认为只有当你使用的模型基于大量特定于你用例的数据进行训练/微调/强化学习时，这种情况才可能出现。这可能通过两种方式实现：

• 你的任务是独一无二的。你需要收集大量数据，并训练/微调/强化学习你自己的模型。
• 你的任务并非独一无二。大模型实验室正在使用与你的任务相关的数据进行训练/微调/强化学习。

（附注：如果我在一个我的任务并不独特的领域建立一家垂直初创企业，我会非常担心我的初创企业的长期可行性）。

你的任务是独一无二的

我敢打赌大多数使用场景（当然是大多数企业使用场景）会归为这一类。AirBnb 如何处理客户支持与 Klarna 如何处理客户支持与 Rakuten 如何处理客户支持是不同的。这些任务中有很多微妙之处。Sierra——一家在客户支持领域领先的 Agent 公司——并没有构建单个客户支持 Agent，而是构建了一个客户支持代理平台：

Sierra Agent SDK 使开发人员能够使用声明性编程语言构建强大、灵活的 Agent，并使用可组合的技能来表达程序知识

它们需要这样去做是因为每一家公司的客户支持都是独一无二的，通用 Agent 的性能不够（效果不好）。

OpenAI 的 Deep Research 就是一个 Agent 的例子，它使用一个针对特定任务训练的模型，通过简单的工具调用循环来实现。所以这是可以实现的，而且它能够生成出色的 Agent。

如果你可以在你的特定任务上训练出一个 SOTA 级别的模型，那么是的，你可能不需要一个支持任意工作流的框架，你只需要一个简单的工具调用循环。在这个场景下，Agents 当然会比 Workflows 好（成为首选）。

我脑海中一个非常开放的问题是：有多少 Agent 公司有能力拥有（这么大量的）数据、工具或者知识去为它们的任务训练一个 SOTA 级别的模型呢？目前，我认为只有大模型实验室才能做到这一点。但这种情况会改变吗？小型垂直领域的初创公司能够训练出一个 SOTA 模型来完成他们的任务吗？我对这个问题非常感兴趣。如果您目前正在做这件事，请与我们联系！

你的任务不是独一无二的

我认为有些任务足够通用，大模型实验室将能够提供足够好的模型来对这些非通用任务执行简单的工具调用循环。

OpenAI 通过 API 发布了他们的 Computer-use 模型，该模型基于通用计算机使用数据进行了微调，旨在达到通用任务的良好性能。（附注：我认为它还远远不够好。）

编程是一个很有趣的例子。编程是相对通用的，并且到目前为止，编程无疑是一个突破性的应用场景。Claude code 和 OpenAI 的 Codex CLI 就是使用这种简单工具调用循环的这方面的两个 Coding Agent 例子。我强烈打赌他们的 base models 训练集中有大量的 Coding 数据和相关任务（可参考这里****，可证明 Anthropic 确实这么做了）。

有趣的是，由于通用模型（general models）都是基于这些数据来训练的，那么这些数据的具体形状（译注: 原文是 exact shape, 不清楚是不是这么翻译）有多重要？Ben Hylak 之前发过一条很有趣的推文，似乎引起了大家的共鸣(resonate)：

模型不再知道如何使用 Cursor 了。

它们对 terminal 进行了优化。这就是为什么 Claude 3.7 和 GPT o3 在 Cursor 中表现如此糟糕，而在 Cursor 之外如此优秀的原因。

这可能表明了两件事情：

1. 你的任务不得不需要和通用模型训练时使用的任务非常非常接近。你的任务越不相似，通用模型就越不可能适合你的应用场景。
2. 通用模型在其他特定任务上训练可能会导致在你的任务上的表现下降。我确信用于训练新模型的数据与 Cursor 的应用场景类似（甚至更多）。但如果有与这种形状略有不同的新数据的涌入，其价值将超过任何其他类型的数据。这意味着目前通用模型很难在大量任务上真正表现出色。

即使对于优先使用 Agents 而不是任何类似 Workflows 的应用程序，你仍然可以受益于与低级工作流控制无关的框架的功能：短期记忆存储、长期记忆存储、human-in-the-loop、human-on-the-loop、streaming、容错、调试/可观察性。

OpenAI 的看法有什么错误？

如果我们重新审视 OpenAI 的态度，就会发现这个态度建立在错误的二分法之上，这种二分法将不同维度的 Agentic 框架混为一谈，以夸大其单一抽象的价值。特别地是，它将“声明式与命令式”和 Agent 抽象以及“Workflows 与 Agents”混为一谈。

最后，它没有抓住对构建生产可用的 Agentic 系统的主要挑战以及框架应该提供的价值，即：一个可靠的编排层，让开发者能够明确控制大语言模型的上下文，同时无缝地处理生产问题，如持久化、容错、human-in-the-loop 的交互过程。

让我们来分析一下我所质疑的具体部分：

“声明式 vs 非声明式图”

LangGraph 并非完全声明式——但它的声明性已经足够强了，所以这并非我的主要抱怨。我主要抱怨的是“非声明式”这种说法做了很多工作，而且具有误导性。通常，当人们批评声明式框架时，他们更倾向于更命令式的框架。但 Agents SDK 并非命令式框架。它是一种抽象。更合适的标题应该是“声明式 vs 命令式”或“你需要一个编排框架吗”或“为什么你只需要 Agent 抽象”或“Workflows vs Agents”，这取决于他们想要讨论的内容（他们似乎在下面对两者都进行了讨论）。

“随着工作流程变得更加动态和复杂，这种方法很快就会变得繁琐和具有挑战性”

这与声明式或非声明式无关。这完全取决于 Workflows 与 Agents。你可以轻松地将 Agents SDK 中的 Agent 逻辑表达为声明式图，并且该图与 Agents SDK 一样动态且灵活。

关于 Workflows 与 Agents 的比较。很多 Workflows 不需要这种程度的动态性和复杂性。OpenAI 和 Anthropic 都承认这一点。如果可以使用工作流，就应该使用工作流。大多数 Agent 系统都是组合使用。没错，如果 Workflows 确实动态且复杂，那么可以使用代理。但不要事事都使用 Agents。OpenAI 在论文的前面部分就明确指出了这一点。

“通常需要学习专门的领域特定语言”

再次强调：Agents SDK 并非命令式框架。它是一种抽象。它本身也是一种领域特定语言（它的抽象）。我认为，目前学习和处理 Agents SDK 的抽象比学习 LangGraph 的抽象更糟糕。很大程度上是因为构建可靠 Agents 的难点在于确保 Agents 拥有正确的上下文，而 Agents SDK 在这方面的混淆程度远高于 LangGraph。

“更灵活”

这完全是错误的。事实恰恰相反。Agents SDK 能做的所有事情，LangGraph 都能做到。Agents SDK 只能实现 LangGraph 功能的 10%。

“代码优先”

使用 Agents SDK，你可以编写它们的抽象。使用 LangGraph，你需要编写大量的常规代码。我不明白 Agents SDK 怎么会更注重代码优先。

“使用熟悉的编程结构”

使用 Agents SDK，你需要学习一整套全新的抽象概念。使用 LangGraph，你需要编写大量的常规代码。还有什么比这更熟悉的呢？

“实现更加动态和适应性更强的代理编排”

再说一遍，这跟声明式和非声明式无关。这跟 Workflows 和 Agents 有关。参见上文。

如何比较所有的 Agent 框架？

我们讨论了 Agent 框架的许多不同组件：

• 它们是灵活的编排层，还是仅仅是 Agent 抽象？
• 如果它们是灵活的编排层，它们是声明式的还是其他类型的？
• 除了 Agent 抽象之外，这个框架还提供了哪些功能？

我觉得把这些维度列在电子表格里会很有趣。我尽量保持客观公正（我从推特上征求了很多反馈，而且得到了很多好评！）。

目前，这个比较包含了 Agents SDK, Google’s ADK, LangChain, Crew AI, LlamaIndex, Agno AI, Mastra, Pydantic AI, AutoGen, Temporal, SmolAgents, DSPy.

如果我遗漏了一个框架（或者框架有误），请发表评论！

你可以在 here 找到实时表格。

结论

• 构建可靠的 Agentic 系统最难的部分是确保 LLM 在每一步都拥有正确的上下文。这包括控制正确的内容进入 LLM 上下文以及执行正确的步骤去生成相关的内容。
• Agentic 系统同时包括 Workflows 和 Agents 两者（和一切这两者之间的事物）。
• 大多数 Agentic 框架既不是声明式也不是命令式的编排框架，而只是一组代理抽象。
• Agent 抽象可以很容易去构建，但是他们通常会造成混淆，并难以确保 LLM 在每一步都有正确的上下文。
• 各种不同的 Agent 系统都受益于同样的一组有用的功能，这些功能可以由框架提供也可以自行从头构建。
• LangGraph 被公认为是一个同时包含声明式和命令式的编排框架，封装了一系列的 Agent 抽象。

译者案: 在看了很多技术博客后我发现自己的表达能力和总结能力有一定欠缺，因此决定挑一些自己感兴趣的前沿领域的一些技术博客上学习他们的思考方式以及行文思路等，来提升自己的能力。少部分用到了 Google Translator，但是 95% 的内容都为自行翻译，如有纰漏请指出。