摘要

• 构建可靠的智能体系统最困难的部分是确保 LLM 在每个步骤都有适当的上下文。这包括控制输入到 LLM 的确切内容，以及运行适当的步骤来生成相关内容。
• 智能体系统由工作流和智能体（以及两者之间的所有内容）组成。
• 大多数智能体框架都不是声明式或命令式的编排框架，而仅仅是一组智能体抽象。
• 智能体抽象可以轻松上手，但它们常常会混淆视听，使得难以确保 LLM 在每个步骤都拥有适当的上下文。
• 各种形状和大小的智能体系统（智能体或工作流）都受益于同一组有用的功能，这些功能可以由框架提供，也可以从头开始构建。
• LangGraph 最好的理解方式是一个编排框架（具有声明式和命令式 API），在其之上构建了一系列智能体抽象。

OpenAI 最近发布了一个关于构建智能体的指南，其中包含一些像下面这样带有误导性的观点。

这个标注最初激怒了我，但在我开始写回复时，我意识到：思考智能体框架非常复杂！可能存在一百种不同的智能体框架，它们有很多不同的比较维度，有时它们会被混淆（就像在这个引述中一样）。市场上存在大量炒作、姿态和噪音。关于智能体框架的精确分析或思考非常少。这篇博客就是我们为此所做的尝试。我们将介绍

• 背景信息
  • 什么是智能体？
  • 构建智能体有什么难处？
  • 什么是 LangGraph？
• 智能体框架的类型
  • “智能体”与“工作流”
  • 声明式与非声明式
  • 智能体抽象
  • 多智能体
• 常见问题
  • 框架的价值是什么？
  • 随着模型越来越好，一切都会变成智能体而不是工作流吗？
  • OpenAI 的观点错在哪里？
  • 所有智能体框架如何比较？

在这篇博客中，我将多次引用一些资料

• OpenAI 构建智能体的指南（我不认为它特别好）
• Anthropic 构建有效智能体的指南（我非常喜欢）
• LangGraph（我们用于构建可靠智能体的框架）

背景信息

为博客的其余部分奠定基础的有用背景信息。

什么是智能体

没有对智能体的一致定义，它们经常通过不同的视角呈现。

OpenAI 采取一种更高层次、更具思想领导力的方法来定义智能体。

智能体是代表您独立完成任务的系统。

我个人不喜欢这个。这是一个模糊的陈述，并没有真正帮助我理解什么是智能体。它只是思想领导力，一点也不实用。

与 Anthropic 的定义相比

“智能体”可以有几种定义方式。一些客户将智能体定义为在延长时间内独立运行、使用各种工具完成复杂任务的完全自主的系统。另一些人则使用该术语来描述遵循预定义工作流的更具指导性的实现。在 Anthropic，我们将所有这些变体归类为 智能体系统，但我们在 工作流 和 智能体 之间进行了重要的架构区分。

工作流 是 LLM 和工具通过预定义的代码路径进行编排的系统。

另一方面，智能体 是 LLM 动态地指导自己的流程和工具使用，并保持对其如何完成任务的控制的系统。

我更喜欢 Anthropic 的定义，有几个原因

• 他们对智能体的定义更加精确和技术化。
• 他们还提到了“智能体系统”的概念，并将工作流和智能体都归类为此类变体。我 非常喜欢 这一点。

在博客文章的后面，Anthropic 将智能体定义为“……通常只是 LLM 根据环境反馈在循环中使用工具。”

尽管他们一开始对智能体有一个宏大的定义，但这基本上就是 OpenAI 的意思。

这些类型的智能体由以下参数化：

• 要使用的模型
• 要使用的指令（系统提示）
• 要使用的工具

你在循环中调用模型。如果/当它决定调用一个工具时，你就运行该工具，获得一些观察/反馈，然后将其传递回 LLM。你一直运行，直到 LLM 决定不调用工具（或者它调用了一个触发停止条件的工具）。

OpenAI 和 Anthropic 都将工作流称为与智能体不同的设计模式。LLM 在其中的控制力较小，流程更具确定性。这是一个有用的区别！

OpenAI 和 Anthropic 都明确指出，您并不总是需要智能体。在许多情况下，工作流更简单、更可靠、更便宜、更快、性能更好。Anthropic 文章中的一个绝佳引述：

在构建 LLM 应用程序时，我们建议寻找最简单的解决方案，并在需要时才增加复杂性。这可能意味着根本不构建智能体系统。智能体系统通常以延迟和成本换取更好的任务性能，您应该考虑何时这种权衡是有意义的。

当需要更多复杂性时，工作流为定义明确的任务提供了可预测性和一致性，而当需要大规模的灵活性和模型驱动的决策时，智能体是更好的选择。

OpenAI 也说了类似的话

在承诺构建智能体之前，请验证您的用例是否能够清晰地满足这些标准。否则，确定性解决方案可能就足够了。

实际上，我们发现大多数“智能体系统”是工作流和智能体的组合。这就是为什么我实际上 讨厌 谈论某物是否是智能体，而更喜欢谈论一个系统的智能性有多高。致敬伟大的 Andrew Ng 提出的这种 思考方式。

与其二元地选择某物是智能体还是不是，我认为将系统视为不同程度的“像智能体一样”更有用。与名词“智能体”不同，形容词“智能的”使我们能够思考这些系统并将它们都包含在这个不断发展的运动中。

构建智能体有什么难处？

我认为大多数人会同意构建智能体是困难的。或者说——原型构建智能体很容易，但构建一个可靠的、能够为业务关键型应用程序提供支持的智能体呢？这很难。

棘手的部分正是这一点——使其可靠。你可以轻松地创建一个在 Twitter 上看起来不错的演示。但你能用它来支持业务关键型应用程序吗？不行，需要大量工作。

几个月前，我们对智能体构建者进行了一项调查，并问他们：“在生产中部署更多智能体的最大限制是什么？” 迄今为止，最常见的回答是“性能质量”——仍然很难让这些智能体正常工作。

是什么导致智能体有时表现不佳？ LLM 出错了。

为什么 LLM 会出错？ 两个原因：(a) 模型不够好，(b) 传递给模型的上下文错误（或不完整）。

根据我们的经验，第二种情况非常常见。这导致了什么？

• 不完整或简短的系统消息
• 含糊的用户输入
• 无法访问正确的工具
• 糟糕的工具描述
• 未传递正确的上下文
• 格式不佳的工具响应

在讨论智能体框架时，牢记这一点很有帮助。任何使控制传递给 LLM 的 确切内容 变得更困难的框架都只会碍事。将正确的上下文传递给 LLM 已经够难了——为什么要让自己更难？

什么是 LangGraph

LangGraph 是一个事件驱动的框架，用于构建智能体系统。使用它的两种最常见方式是通过

• 一种 声明式的、基于图的语法
• 智能体抽象（构建在更低层框架之上）

LangGraph 还支持 函数式 API，以及底层 事件驱动 API。同时存在 Python 和 Typescript 版本。

智能体系统可以表示为 节点 和 边。节点代表工作单元，边代表转换。节点和边仅仅是普通的 Python 或 TypeScript 代码——因此，虽然图的结构以声明式方式表示，但图逻辑的内部功能是正常的、命令式的代码。边可以是 固定的 或 条件性的。因此，虽然图的结构是声明式的，但通过图的路径可以是完全动态的。

LangGraph 带有 内置持久层。这实现了 容错、短期记忆 和 长期记忆。

此持久层还支持“人工介入”和“人工监督”模式，例如中断、批准、恢复和时间旅行。

LangGraph 内置支持 流式传输：令牌、节点更新和任意事件。

LangGraph 与 LangSmith 无缝集成，用于调试、评估和可观测性。

智能体框架的类型

智能体框架在几个维度上有所不同。理解（而不是混淆）这些维度是能够正确比较智能体框架的关键。

工作流 vs 智能体

大多数框架包含更高级的智能体抽象。一些框架包含一些常见工作流的抽象。LangGraph 是用于构建智能体系统的低级编排框架。LangGraph 支持 工作流、智能体以及两者之间的任何内容。我们认为这很重要。如前所述，生产中的大多数智能体系统都是工作流和智能体的组合。一个生产就绪的框架需要同时支持两者。

让我们记住构建可靠智能体的难点——确保 LLM 具有正确的上下文。工作流之所以有用，部分原因在于它们可以轻松地将正确的上下文传递给 LLM。您精确地决定数据如何流动。

当您考虑在“工作流”到“智能体”的哪个谱线上构建应用程序时，有两件事需要考虑

• 可预测性 vs 智能性
• 低门槛，高上限

可预测性 vs 智能性

随着您的系统变得更加智能，它的可预测性将降低。

有时您希望或需要您的系统具有可预测性——为了用户信任、法规原因或其他原因。

可靠性并不完全随着可预测性而增长，但在实践中它们可能密切相关。

您希望在这个曲线上的哪个位置取决于您的应用程序。LangGraph 可用于构建此曲线上任何位置的应用程序，让您可以移动到您想要的位置。

高门槛，低上限

在考虑框架时，考虑其门槛和上限很有帮助

• 低门槛：低门槛 框架对初学者友好且易于上手
• 高门槛：高门槛 框架意味着学习曲线陡峭，需要大量的知识或专业知识才能开始有效使用。
• 低上限：低上限 框架意味着其功能有限（您很快就会过时）。
• 高上限：高上限 框架为高级用例提供了广泛的功能和灵活性（它会与您一起成长吗？）。

工作流框架提供了高上限，但伴随着高门槛——您必须自己编写大量的智能体逻辑。

智能体框架是低门槛，但低上限——易于上手，但对于非平凡用例来说不够。

LangGraph 旨在具有低门槛的方面（内置智能体抽象，易于上手），但也具有高上限（低级功能，用于实现高级用例）。

声明式与非声明式

声明式框架有其优点。也有缺点。这是程序员之间似乎永无止境的争论，每个人都有自己的偏好。

当人们说非声明式时，他们通常暗示命令式是替代方案。

大多数人会将 LangGraph 描述为声明式框架。这只是部分正确。

首先——虽然节点和边之间的连接是以声明式方式完成的，但实际的节点和边仅仅是 Python 或 TypeScript 函数。因此，LangGraph 是一种声明式和命令式的混合体。

其次——除了推荐的声明式 API，我们还支持其他 API。特别是，我们支持 函数式 和 事件驱动式 API。虽然我们认为声明式 API 是一个有用的心智模型，但我们也认识到它并非适合所有人。

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

这是完全错误的。Agents SDK（以及原始的 LangChain、CrewAI 等）之类的框架既不是声明式的也不是命令式的——它们只是抽象。它们有一个智能体抽象（一个 Python 类），其中包含运行智能体的许多内部逻辑。它们并不是真正的编排框架。它们只是抽象。

智能体抽象

大多数智能体框架都包含一个智能体抽象。它们通常以一个包含提示、模型和工具的类开始。然后它们添加更多参数……然后更多……然后更多。最终，您会得到一长串控制多种行为的参数，所有这些都抽象在一个类中。如果您想了解正在发生的事情，或更改逻辑，您必须进入类并修改源代码。

我们为此付出了惨痛的代价。原始的 LangChain 链和智能体存在这个问题。它们提供了碍事的抽象。两年前，其中一个原始抽象是一个接受模型、提示和工具的智能体类。这不是一个新概念。当时它没有提供足够的控制，现在也没有。

需要明确的是，这些智能体抽象有一些价值。它使上手更容易。但我认为这些智能体抽象目前还不足以构建可靠的智能体（也许永远也做不到）。

我们认为看待这些智能体抽象的最佳方式就像 Keras。它们提供了更高级的抽象，可以轻松上手。但确保它们构建在低级框架之上至关重要，这样您就不会超越它。

这就是为什么我们在 LangGraph 之上构建了智能体抽象。这提供了一种轻松上手智能体的方法，但如果您需要逃到更底层的 LangGraph，也很容易做到。

多智能体

通常，智能体系统不仅包含一个智能体，还包含多个。OpenAI 在其报告中说：

对于许多复杂的系统，将提示和工具分配给多个智能体，可以提高性能和可伸缩性。当您的智能体未能遵循复杂的指令或一贯地选择错误的工具时，您可能需要进一步划分您的系统并引入更多不同的智能体。

有很多方法可以做到这一点！交接是一种方式。这是 Agents SDK 的一种智能体抽象，我实际上很喜欢。

但这些智能体进行通信的最佳方式有时可以是工作流。将 Anthropic 博客文章中的所有工作流图替换为智能体。这种工作流和智能体的结合通常能提供最佳的可靠性。

再次——智能体系统不仅仅是工作流，也不是单个智能体。它们可以是——而且通常是——两者的组合。正如 Anthropic 在其博客文章中所指出的：

组合和定制这些模式

这些构建块不是规定性的。它们是开发人员可以根据不同用例进行塑造和组合的常见模式。

常见问题

在定义和探讨了用于评估框架的不同维度之后，现在让我们尝试回答一些常见问题。

框架的价值是什么？

我们经常看到人们质疑他们是否需要一个框架来构建智能体系统。智能体框架能提供什么价值？

智能体抽象

框架普遍有用，因为它们包含有用的抽象，易于上手，并为工程师提供了一种通用的构建方式，从而更容易入职和维护项目。如上所述，智能体抽象也有真正的缺点。对于大多数智能体框架来说，这是它们唯一提供的价值。我们非常努力地确保 LangGraph 不是这样。

短期记忆

今天的大多数智能体应用程序都涉及某种多轮（例如，聊天）组件。LangGraph 提供生产就绪的存储，以实现多轮体验（线程）。

长期记忆

虽然还处于早期阶段，但我对智能体系统从经验中学习（例如，跨对话记住事情）非常有信心。LangGraph 提供生产就绪的跨线程记忆存储。

人工介入

许多智能体系统通过某种人工介入组件得到改进。例如，获取用户反馈、批准工具调用或编辑工具调用参数。LangGraph 提供内置支持，以在生产系统中实现这些工作流。

人工监督

除了允许用户在智能体运行时影响它之外，还允许用户在事后检查智能体的轨迹，甚至可以回到早期步骤然后从那里（进行更改后）重新运行。我们称之为人工监督，LangGraph 提供对此内置支持。

流式传输

大多数智能体应用程序运行需要一些时间，因此向最终用户提供更新对于提供良好的用户体验至关重要。LangGraph 提供内置的令牌、图步和任意流的流式传输。

调试/可观测性

构建可靠智能体的难点在于确保您将正确的上下文传递给 LLM。能够检查智能体采取的确切步骤以及每个步骤的确切输入/输出对于构建可靠的智能体至关重要。LangGraph 与 LangSmith 无缝集成，提供一流的调试和可观测性。注意：AI 可观测性不同于传统软件可观测性（这值得另发一帖）。

容错

容错是构建分布式应用程序的传统框架（如 Temporal）的关键组件。LangGraph 通过持久化工作流和可配置重试使容错更容易。

优化

手动调整提示可能很麻烦，有时更容易定义一个评估数据集，然后根据该数据集自动优化您的智能体。LangGraph 目前不支持开箱即用的此功能——我们认为现在还为时过早。但我想包含这一点，因为它是一个有趣的考虑维度，也是我们一直在关注的。dspy 目前是最好的框架。

那么——您真的需要一个智能体框架吗？

如果您的应用程序不需要所有这些功能，和/或您想自己构建它们，那么您可能不需要。其中一些（如短期记忆）并不特别复杂。其他一些（如人工监督或特定于 LLM 的可观测性）则更复杂。

关于智能体抽象：我同意 Anthropic 在他们的文章中说的

如果您确实使用了框架，请确保您理解底层代码。对幕后情况的错误假设是客户出错的常见原因。

随着模型越来越好，一切都会变成智能体而不是工作流吗？

支持智能体（与工作流相比）的一个常见论点是，尽管它们现在不起作用，但将来会起作用，因此您只需要简单的、调用工具的智能体。

我认为多件事可以同时为真

• 这些调用工具的智能体的性能将会提高
• 能够控制输入到 LLM 的内容仍然非常重要（垃圾进，垃圾出）
• 对于某些应用程序，这种调用工具的循环就足够了
• 对于其他应用程序，工作流将更简单、更便宜、更快、更好
• 对于大多数应用程序，生产智能体系统将是工作流和智能体的组合

我认为 OpenAI 或 Anthropic 不会争论任何一点？来自 Anthropic 的文章

在构建 LLM 应用程序时，我们建议寻找最简单的解决方案，并在需要时才增加复杂性。这可能意味着根本不构建智能体系统。智能体系统通常以延迟和成本换取更好的任务性能，您应该考虑何时这种权衡是有意义的。

来自 OpenAI 的文章

在承诺构建智能体之前，请验证您的用例是否能够清晰地满足这些标准。否则，确定性解决方案可能就足够了。

会有一些应用程序，其中这个简单的调用工具循环就足够了吗？我认为只有当您使用针对大量特定用例数据进行训练/微调/RL 的模型时，这才会是这种情况。这可以通过两种方式实现：

• 您的任务是独一无二的。您收集大量数据并训练/微调/RL 您自己的模型。
• 您的任务不是独一无二的。大型模型实验室正在使用代表您任务的数据进行训练/微调/RL。

（旁注：如果我正在构建一个特定领域的初创公司，而我的任务不是独一无二的，我会非常担心我的初创公司的长期生存能力。）

您的任务是独一无二的

我敢打赌，大多数用例（尤其是大多数企业用例）都属于这一类。Airbnb 如何处理客户支持与 Klarna 如何处理客户支持与 Rakuten 如何处理客户支持是不同的。这些任务有大量的细节。Sierra——客户支持领域的领先智能体公司——并非构建单一的客户支持 智能体，而是构建一个客户支持智能体 平台。

Sierra Agent SDK 使开发人员能够使用声明式编程语言，通过可组合的技能来表达过程知识，从而构建强大、灵活的智能体。

他们需要这样做，因为每家公司的客户支持体验都足够独特，以至于通用智能体不够强大。

一个使用在特定任务上训练的模型进行简单调用工具循环的智能体示例：OpenAI 的 Deep Research。所以这是可以做到的，而且它可以产生令人惊叹的智能体。

如果您能为您的特定任务训练一个 SOTA 模型——那么是的，您可能不需要一个支持任意工作流的框架，您只需要使用一个简单的调用工具循环。在这种情况下，智能体将比工作流更受欢迎。

我心中一个非常开放的问题是：有多少智能体公司将拥有数据、工具或知识来为其任务训练 SOTA 模型？在此时此刻，我认为只有大型模型实验室能够做到这一点。但这会改变吗？一个小型的特定领域初创公司能否为其任务训练 SOTA 模型？我对这个问题非常感兴趣。如果您目前正在这样做——请联系我！

您的任务不是独一无二的

我认为有些任务足够通用，以至于大型模型实验室能够提供足够好的模型来在这些非通用任务上进行简单的调用工具循环。

OpenAI 通过 API 发布了其计算机使用模型，这是一个在通用计算机使用数据上进行了微调的模型，旨在在该通用任务上表现足够好。（旁注：我认为它还没有足够好。）

代码是一个有趣的例子。编码相对通用，而且编码一直是智能体的一个突破性用例。Claude code 和 OpenAI 的 Codex CLI 是使用这个简单的调用工具循环的编码智能体的两个例子。我非常有把握，基础模型是在大量编码数据和任务上进行训练的（证据请参见此处，Anthropic 确实这样做了）。

有趣的是——当通用模型在这些数据上进行训练时，这些数据的确切形状有多重要？Ben Hylak 前几天有一个有趣的推文，似乎引起了大家的共鸣。

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

它们都被优化用于终端。这就是为什么 3.7 和 o3 在 Cursor 中如此糟糕，而在它之外如此出色。

这可能暗示两点

• 您的任务必须非常非常接近通用模型所训练的任务。您的任务越不相似，通用模型就越不可能适合您的用例。
• 在其他特定任务上训练通用模型可能会降低您任务的性能。我相信用于训练新模型的数据中，与 Cursor 用例相似的数据量也一样多（甚至更多）。但如果涌入了形状略有不同的新数据，它就会压倒其他类型的数据。这暗示着通用模型很难在大量任务上表现出色。

OpenAI 的观点错在哪里？

如果我们回顾 OpenAI 的立场，我们会发现它基于错误的二分法，它混淆了“智能体框架”的不同维度，以便夸大其单一抽象的价值。特别是，它混淆了“声明式与命令式”与“智能体抽象”，以及“工作流与智能体”。

让我们分解一下我特别不满意的部分

“声明式与非声明式图”

LangGraph 并非完全声明式——但它足够声明式，所以这不是我的主要不满。我的主要不满是“非声明式”这个词的含义太广且具有误导性。通常，当人们批评声明式框架时，他们会更喜欢命令式框架。但 Agents SDK 不是命令式框架。它是一个抽象。一个更恰当的标题应该是“声明式与命令式”或“您是否需要一个编排框架”或“为什么智能体抽象就是您需要的一切”或“工作流 vs 智能体”，取决于他们想论证什么（他们似乎在下面论证两者）。

“这种方法可能很快变得繁琐且具有挑战性，因为工作流变得更加动态和复杂”

这与声明式或非声明式无关。这与工作流与智能体有关。您可以在 Agents SDK 中轻松地将智能体逻辑表示为声明式图，而该图与 Agents SDK 一样动态和灵活。

关于工作流与智能体的观点。许多工作流不需要这种程度的动态性和复杂性。OpenAI 和 Anthropic 都承认这一点。当您可以使用工作流时，就应该使用工作流。大多数智能体系统是组合。是的，如果一个工作流非常动态和复杂，那么就使用智能体。但不要对所有事物都使用智能体。OpenAI 在论文中明确提到了这一点。

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

同样——Agents SDK 不是命令式框架。它是一个抽象。它还有一个领域特定语言（它的抽象）。我认为，在目前这个时间点，学习和绕过 Agents SDK 抽象比学习 LangGraph 抽象要糟糕。很大程度上是因为构建可靠智能体的难点在于确保智能体拥有正确的上下文，而 Agents SDK 比 LangGraph 更模糊了这一点。

“更灵活”

这纯粹是错误的。事实恰恰相反。您可以使用 Agents SDK 做的所有事情，都可以用 LangGraph 完成。Agents SDK 只能让您做 LangGraph 功能的 10%。

“代码优先”

使用 Agents SDK，您编写它们的抽象。使用 LangGraph，您编写了 大量 普通代码。我看不出 Agents SDK 如何更“代码优先”。

“使用熟悉的编程结构”

使用 Agents SDK，您必须学习一套全新的抽象。使用 LangGraph，您编写了大量普通代码。还有什么比这更熟悉的呢？

“实现更动态和适应性强的智能体编排”

同样——这与声明式与非声明式无关。这与工作流与智能体有关。请参阅上面的观点。

比较智能体框架

我们已经讨论了智能体框架的许多不同组件

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

我认为尝试将这些维度列入电子表格会很有趣。我试图做到尽可能公正（我从 Twitter 上获得了大量反馈！）。

目前，它包含了与 Agents SDK、Google 的 ADK、LangChain、Crew AI、LlamaIndex、Agno AI、Mastron、Pydantic AI、AutoGen、Temporal、SmolAgents、DSPy 的比较。

如果我遗漏了一个框架（或关于某个框架的信息有误），请留下评论！

结论

• 构建可靠的智能体系统最困难的部分是确保 LLM 在每个步骤都有适当的上下文。这包括控制输入到 LLM 的确切内容，以及运行适当的步骤来生成相关内容。
• 智能体系统由工作流和智能体（以及两者之间的所有内容）组成。
• 大多数智能体框架都不是声明式或命令式的编排框架，而仅仅是一组智能体抽象。
• 智能体抽象可以轻松上手，但它们常常会混淆视听，使得难以确保 LLM 在每个步骤都拥有适当的上下文。
• 各种形状和大小的智能体系统（智能体或工作流）都受益于同一组有用的功能，这些功能可以由框架提供，也可以从头开始构建。
• LangGraph 最好的理解方式是一个编排框架（具有声明式和命令式 API），在其之上构建了一系列智能体抽象。