本文是 LangChain CEO Harrison Chase 在 OpenAI 发布了一份关于构建智能体 ( agents ) 的指南之后写的一篇文章，这篇文章主要用于指出 OpenAI 的智能体指南中的一些误导性观点，并给出了自己的一些看法。

  1. 定义区分：
    • 工作流 (Workflows)：通过预定义代码路径编排 LLM 和工具，可预测性高。
    • 代理 (Agents)：LLM 动态指导自身流程和工具使用，灵活性高。作者更倾向于 Anthropic 对此的精确技术定义。
  2. 代理失败原因：LLM 表现不佳通常源于上下文问题，如：系统提示不完整、用户输入模糊、工具描述/访问不当、未传入正确上下文、工具响应格式不佳等。
  3. LangGraph 特点：
    • 提供底层编排能力（节点 Nodes 和边 Edges）。
    • 支持声明式（图结构）和命令式（节点/边内部逻辑）编程。
    • 内置持久化层，支持容错、短期/长期记忆。
    • 支持“人在回路”（human-in-the-loop）和“人监控回路”（human-on-the-loop）模式。
    • 内置流式处理（streaming）支持。
    • 与 LangSmith 集成，提供调试、评估和可观测性。
  4. 框架价值：除了代理抽象，好的框架还应提供：短期/长期记忆管理、人机交互支持、流式输出、调试/可观测性、容错机制等。这些价值对工作流和代理都适用。
  5. 对 OpenAI 指南的批评：作者认为 OpenAI 的指南：
    • 错误地将 LangGraph 等声明式方法描绘为繁琐且不灵活。
    • 混淆了“声明式 vs 命令式”与“工作流 vs 代理”以及“抽象”的概念。
    • 声称 Agents SDK 等“非声明式”（实为抽象）方法更灵活、“代码优先”，作者认为这与事实相反。
    • 未能抓住构建可靠代理系统的核心挑战（上下文控制）和框架应提供的核心价值（可靠的编排层）。
  6. 多代理系统：关键在于代理间的通信机制，工作流常用于组织多个代理的协作。
  7. 框架对比：作者提供了一个电子表格链接，用于比较 LangGraph, Agents SDK, CrewAI, AutoGen 等多种框架在不同维度（如编排 vs 抽象、特性支持）上的表现。

原文：如何看待 AI 智能体框架

总结：

  • 构建可靠的智能体系统 ( agentic systems ) 的难点在于确保大语言模型 ( LLM ) 在每一步都能获得恰当的上下文。这既包括控制输入到 LLM 的具体内容，也包括执行适当的步骤来生成相关内容。
  • 智能体系统 ( agentic systems ) 包含工作流程 ( workflows ) 和智能体 ( agents ) ( 以及介于两者之间的一切 )。
  • 大多数智能体框架既不是声明式 ( declarative ) 编排框架，也不是命令式 ( imperative ) 编排框架，而只是一系列智能体抽象。
  • 智能体抽象可以让你轻松上手，但它们也常常会模糊细节，使得难以确保 LLM 在每一步都获得恰当的上下文。
  • 各种形式和规模的智能体系统 ( 无论是智能体还是工作流程 ) 都受益于一组相同的有用功能，这些功能可以由框架提供，也可以从头构建。
  • LangGraph 最好的理解方式是将其视为一个编排框架 ( orchestration framework ) ( 同时提供声明式和命令式 API )，并在其之上构建了一系列智能体抽象。

OpenAI 最近发布了一份关于构建智能体 ( agents ) 的指南，其中包含一些具有误导性的观点，如下所示：

最初，这个观点让我很生气，但在我开始写回应后意识到：智能体框架确实很复杂！可能存在上百种不同的智能体框架，有很多不同的维度可以用来比较它们，有时这些维度会混淆 ( 就像这个引文一样 )。存在大量的炒作、夸耀和噪音。关于智能体框架的精确分析或思考非常少。这篇博客是我们的尝试。我们将涵盖：

  • 背景信息
    • 什么是智能体 ( agent )？
    • 构建智能体 ( agents ) 难在哪里？
    • 什么是 LangGraph？
  • 智能体框架的类型
    • “智能体 ( agents )” vs “工作流程 ( workflows )”
    • 声明式 ( declarative ) vs 非声明式 ( non-declarative )
    • 智能体抽象 ( agent abstractions )
    • 多智能体 ( multi agent )
  • 常见问题
    • 框架的价值是什么？
    • 随着模型变得更好，一切都会变成智能体而不是工作流程吗？
    • OpenAI 的观点错在哪里？
    • 所有智能体框架如何比较？

在这篇博客中，我将反复引用一些材料：

  • OpenAI 的智能体构建指南 ( 我认为写得不是特别好 )
  • Anthropic 的构建高效智能体指南 ( 我非常喜欢 )
  • LangGraph ( 我们用于构建可靠智能体的框架 )

背景信息

为后续的博客内容奠定基础的有用背景信息。

什么是智能体 ( agent )

智能体 ( agent ) 没有一致的定义，它们通常从不同的角度来理解。

OpenAI 采用了一种更高级、更具思想领导力的方法来定义智能体：

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

我个人不太喜欢这种说法。它过于笼统，并没有真正帮助我理解智能体是什么。这只是一种思想领导力，完全不切实际。

相比之下，Anthropic 的定义：

“智能体 ( agent )”可以用几种方式定义。一些客户将智能体定义为在很长一段时间内独立运行、使用各种工具完成复杂任务的完全自主系统。另一些客户则使用该术语来描述遵循预定义工作流程的更具规定性的实现。在 Anthropic，我们将所有这些变体归类为 智能体系统 ( agentic systems )，但在体系结构上对 工作流程 ( workflows ) 和 智能体 ( agents ) 进行了重要区分：

工作流程 ( workflows ) 是通过预定义代码路径编排 LLM 和工具的系统。

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

我更喜欢 Anthropic 的定义，原因如下：

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

💡

我们在生产中看到的大多数“智能体系统 ( agentic systems )”都是“工作流程 ( workflows )”和“智能体 ( agents )”的 组合。

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

尽管他们一开始对智能体 ( agent ) 给出了宏大的定义，但这基本上也是 OpenAI 的意思。

这些类型的智能体 ( agents ) 通过以下参数化：

  • 要使用的模型 ( model )
  • 要使用的指令 ( system prompt )
  • 要使用的工具 ( tools )

您在一个循环中调用模型。如果/当它决定调用工具时，您运行该工具，获取一些观察/反馈，然后将其传递回 LLM。您一直运行直到 LLM 决定不调用工具 ( 或者它调用了一个触发停止标准的工具 )。

OpenAI 和 Anthropic 都指出工作流程 ( workflows ) 是一种与智能体 ( agents ) 不同的设计模式。在这种模式下，LLM 的控制权较小，流程更具确定性。这是一个有用的区别！

OpenAI 和 Anthropic 都明确指出，您并非总是需要智能体 ( agents )。在许多情况下，工作流程 ( workflows ) 更简单、更可靠、更便宜、更快、性能更好。Anthropic 的文章中有一句精彩的引言：

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

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

OpenAI 也说了类似的话：

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

实际上，我们发现大多数“智能体系统 ( agentic systems )”都是工作流程和智能体 ( agents ) 的组合。这就是为什么我 不喜欢 讨论某事物是否是智能体 ( agent )，而更喜欢讨论一个系统的智能体化程度 ( agentic )。感谢伟大的 Andrew Ng 提供了这种 思维方式 ：

我认为，与其二元地选择某事物是否是智能体，不如将其视为不同程度的“智能体化”系统会更有用。与名词“智能体”不同，形容词“智能体化”允许我们思考此类系统并将它们全部纳入这个不断发展的运动中。

构建智能体 ( agents ) 困难之处在哪里？

我认为大多数人都会同意构建智能体 ( agents ) 很困难。或者更确切地说——构建一个原型智能体 ( agent ) 很容易，但是一个可靠的，能够为业务关键型应用程序提供支持的智能体呢？那才是困难的。

困难之处恰恰在于此——使其可靠。您可以轻松制作一个在 Twitter 上看起来不错的演示。但您能运行它来支持业务关键型应用程序吗？没有大量工作是做不到的。

几个月前，我们对智能体构建者进行了一项调查，询问他们：“您将更多智能体投入生产的最大限制是什么？”迄今为止排名第一的回答是“性能质量”——让这些智能体正常工作仍然非常困难。

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

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

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

  • 不完整或简短的系统消息 ( system messages )
  • 模糊的用户输入 ( user input )
  • 无法访问正确的工具 ( tools )
  • 糟糕的工具描述 ( tool descriptions )
  • 未传递正确的上下文 ( context )
  • 格式不佳的工具响应 ( tool responses )

💡

构建可靠智能体系统 ( agentic systems ) 的困难之处在于确保 LLM 在每一步都拥有适当的上下文。这包括控制输入到 LLM 的确切内容，以及运行适当的步骤生成相关内容。

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

什么是 LangGraph

💡

LangGraph 最好的理解方式是将其视为一个编排框架 ( 同时提供声明式和命令式 API )，并在其之上构建了一系列智能体抽象。

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

  • 一种声明式的 ( declarative )、基于图的语法
  • 智能体抽象 ( agent abstractions ) ( 构建在底层框架之上 )

LangGraph 还支持 函数式 API ( functional API )，以及底层的 事件驱动 API ( event-driven API )。存在 Python 和 Typescript 两种变体。

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

LangGraph 配备了一个 内置的持久化层 ( persistence layer )。这实现了 容错 ( fault tolerance )、 短期记忆 ( short-term memory ) 和 长期记忆 ( long-term memory )。

这个持久化层还支持“ 人在循环中 ( human-in-the-loop )”和“ 人在监控中 ( human-on-the-loop )”模式，例如中断 ( interrupt )、批准 ( approve )、恢复 ( resume ) 和时间旅行 ( time travel )。

LangGraph 内置支持 流式传输 ( streaming )：包括 tokens、节点更新和任意事件。

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

智能体框架的类型

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

工作流程 ( workflows ) vs 智能体 ( agents )

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

让我们记住构建可靠智能体困难之处是什么——确保 LLM 拥有正确的上下文。工作流程之所以有用，部分原因在于它们使得向 LLM 传递正确上下文变得容易。您可以精确地决定数据如何流动。

当您思考希望您的应用程序位于“工作流程”到“智能体”的哪一个谱系上时，需要考虑两件事：

  • 可预测性 ( Predictability ) vs 智能体能力 ( agency )
  • 低门槛，高上限 ( Low floor, high ceiling )

可预测性 ( Predictability ) vs 智能体能力 ( agency )

随着您的系统变得更具智能体能力，它将变得更不可预测。

有时您需要或希望您的系统具有可预测性——出于用户信任、监管原因或其他原因。

可靠性与可预测性并不完全一致，但在实践中它们可能密切相关。

您希望位于这条曲线上的位置取决于您的应用程序。LangGraph 可以用于构建位于这条曲线上任何位置的应用程序，允许您移动到您希望位于的点。

高门槛，低上限 ( High floor, low ceiling ) / 低门槛，高上限 ( Low floor, high ceiling )

在考虑框架时，考虑它们的门槛和天花板会很有帮助：

  • 低门槛 ( Low floor )：低门槛框架对初学者友好且易于上手。
  • 高门槛 ( High floor )：高门槛框架意味着学习曲线陡峭，需要大量的知识或专业知识才能开始有效使用。
  • 低上限 ( Low ceiling )：低上限框架意味着它在能完成的任务方面存在限制 ( 您很快就会超越它 )。
  • 高上限 ( High ceiling )：高上限框架为高级用例提供了广泛的功能和灵活性 ( 它会随着您一起成长？)。

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

智能体框架门槛较低，但天花板较低——易于上手，但不足以应对非平凡的用例。

LangGraph 旨在同时具备低门槛 ( 内置的智能体抽象，使其易于上手 ) 和高上限 ( 低级功能以实现高级用例 )。

声明式 ( declarative ) vs 非声明式 ( non-declarative )

声明式框架有很多优点。也有缺点。这是程序员之间一个看似没完没了的争论，每个人都有自己的偏好。

当人们说非声明式时，他们通常暗示着命令式 ( imperative ) 作为替代方案。

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

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

其次——除了推荐的声明式 API，我们实际上还支持其他 API。具体来说，我们支持 函数式 ( functional ) 和 事件驱动 ( event-driven ) 的 API。虽然我们认为声明式 API 是一个有用的心智模型，但我们也认识到它并不适合所有人。

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

这完全不正确。像 Agents SDK ( 以及原始 LangChain、CrewAI 等 ) 这样的框架既不是声明式也不是命令式——它们只是抽象。它们有一个智能体抽象 ( 一个 Python 类 )，并且其中包含大量运行智能体的内部逻辑。它们不是真正的编排框架。它们只是抽象。

智能体抽象 ( Agent Abstractions )

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

💡

这些抽象最终使得理解或控制到底是什么进入 LLM 的每一步变得非常困难。这一点很重要——拥有这种控制权对于构建可靠的智能体至关重要 ( 如上所述 )。这就是智能体抽象的危险之处。

我们经历了艰难的教训。这是原始 LangChain 链和智能体的问题所在。它们提供的抽象阻碍了进展。两年前那些原始抽象之一就是一个接受模型、提示和工具的智能体类。这不是一个新概念。那时它没有提供足够的控制，现在也没有。

需要明确的是，这些智能体抽象确实有一些价值。它们使入门变得更容易。但我认为这些智能体抽象还不足以构建可靠的智能体 ( 也许永远都不行 )。

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

这就是为什么我们在 LangGraph 之上构建了智能体抽象。这提供了一种轻松上手智能体的方式，但如果您需要逃离到较低级别的 LangGraph，您可以轻松做到。

多智能体 ( Multi Agent )

智能体系统通常不会只包含一个智能体，它们会包含多个。OpenAI 在他们的报告中说：

对于许多复杂的工作流程，将提示和工具分散到多个智能体可以提高性能和可扩展性。当您的智能体无法遵循复杂的指令或始终选择不正确的工具时，您可能需要进一步分解您的系统并引入更多不同的智能体。

💡

多智能体系统的关键在于它们如何通信。再次强调，构建智能体困难之处在于将正确的上下文提供给 LLM。这些智能体之间的通信非常重要。

有很多方法可以做到这一点！交接 ( Handoffs ) 是一种方式。这是 Agents SDK 中的一个智能体抽象，我确实非常喜欢它。

但这些智能体之间最佳的通信方式有时是工作流程。查看 Anthropic 博客文章中的所有工作流程图，并将 LLM 调用替换为智能体。这种工作流程和智能体的结合通常能提供最佳的可靠性。

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

组合和定制这些模式

这些构建模块不是规定性的。它们是开发者可以塑造和组合以适应不同用例的常见模式。

常见问题

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

框架的价值是什么？

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

智能体抽象 ( Agent abstractions )

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

短期记忆 ( Short term memory )

如今大多数智能体应用程序都涉及某种多轮 ( 例如聊天 ) 组件。LangGraph 提供了 可用于启用多轮体验 ( 线程 ) 的生产级存储。

长期记忆 ( Long term memory )

虽然还处于早期阶段，但我非常看好智能体系统从经验中学习 ( 例如记住跨对话的事情 )。LangGraph 提供了 用于跨线程记忆的生产级存储。

人在循环中 ( Human-in-the-loop )

许多智能体系统通过某种“人在循环中”组件而变得更好。示例包括从用户那里获取反馈、批准工具调用或编辑工具调用参数。LangGraph 提供了 内置支持，以在生产系统中启用这些工作流程。

人在监控中 ( Human-on-the-loop )

除了允许用户在智能体运行时影响它之外，允许用户事后检查智能体的轨迹，甚至返回到早期步骤并从那里 ( 经过修改后 ) 重新运行，也是非常有用的。我们将这称为“人在监控中”，LangGraph 提供了 内置支持。

流式传输 ( Streaming )

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

调试/可观测性 ( Debugging/observability )

构建可靠智能体困难之处在于确保将正确的上下文传递给 LLM。能够检查智能体采取的确切步骤以及每一步的确切输入/输出对于构建可靠智能体至关重要。LangGraph 与 LangSmith 无缝集成，提供一流的调试和可观测性。注意：AI 可观测性与传统软件可观测性不同 ( 这值得单独撰写一篇文章 )。

容错 ( Fault tolerance )

容错是传统框架 ( 如 Temporal ) 用于构建分布式应用程序的关键组成部分。LangGraph 通过 耐用工作流程和 可配置重试使得容错更容易。

优化 ( Optimization )

与其手动调整提示，有时定义一个评估数据集然后基于此自动优化智能体更容易。LangGraph 目前不直接支持此功能——我们认为现在这样做还为时过早。但我想提及这一点，因为它是一个值得考虑的有趣维度，也是我们一直在关注的问题。目前， dspy 是这方面最好的框架。

💡

所有这些价值主张 ( 除了智能体抽象 ) 都为智能体、工作流程以及介于两者之间的一切提供了价值。

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

如果您的应用程序不需要所有这些功能，并且/或者您想自己构建它们，那么您可能不需要一个框架。其中一些功能 ( 例如短期记忆 ) 并不特别复杂。另一些功能 ( 例如人在监控中或 LLM 特定的可观测性 ) 则更复杂。

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

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

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

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

我认为多件事可能同时是真的：

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

我认为 OpenAI 或 Anthropic 不会争论这些观点中的任何一个吧？来自 Anthropic 的文章：

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

来自 OpenAI 的文章：

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

会存在简单的工具调用循环就足够的应用程序吗？我认为这可能只在您使用针对您的用例特定的大量数据进行训练/微调/RL 的模型时才成立。这可以通过两种方式发生：

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

( 旁注：如果我在一个我的任务不是独一无二的领域创办一家垂直领域的初创公司，我会非常担心我的初创公司的长期生存能力 )。

您的任务是独一无二的

我敢打赌，大多数用例 ( 当然是大多数企业用例 ) 都属于这一类别。AirBnb 处理客户支持的方式与 Klarna 处理客户支持的方式不同，也与乐天处理客户支持的方式不同。这些任务有很多微妙之处。Sierra——一家在客户支持领域领先的智能体公司——正在构建的不是一个简单的客户支持 智能体，而是一个客户支持智能体 平台：

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

他们需要这样做，因为每家公司的客户支持体验都足够独特，以至于一个通用智能体无法达到足够的性能。

使用针对特定任务训练的模型进行简单工具调用循环的一个智能体示例是：OpenAI 的深度研究 ( Deep Research )。所以这是可以实现的，并且可以产生令人惊叹的智能体。

如果您能够针对您的特定任务训练出一个最先进 ( SOTA ) 的模型——那么是的，您可能不需要一个能够实现任意工作流程的框架，您只需使用一个简单的工具调用循环。在这种情况下，智能体将优先于工作流程。

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

您的任务并非独一无二

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

OpenAI 通过 API 发布了他们的 Computer Use 模型，这是一个针对通用计算机使用数据进行微调的模型，旨在在那个通用任务上表现良好。( 旁注：我认为它还远未达到足够好的水平 )。

代码是一个有趣的例子。编码相对通用，而且到目前为止，编码绝对是智能体领域的一个突破性用例。Claude code 和 OpenAI 的 Codex CLI 是使用这种简单工具调用循环的两个编码智能体示例。我可以大胆猜测，基础模型是在大量编码数据和任务上进行训练的 ( 可以从 这里 看到 Anthropic 这样做的证据 )。

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

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

它们都在针对终端进行优化。这就是为什么 3.7 和 o3 在 Cursor 中表现如此糟糕，而在 Cursor 之外却如此出色。

这可能表明两点：

  • 您的任务必须与通用模型训练的任务非常非常接近。您的任务越不相似，通用模型对您的用例来说就越不可能足够好。
  • 在其他特定任务上训练通用模型可能会降低其在您的任务上的性能。我相信有同样多 ( 甚至更多 ) 类似于 Cursor 用例的数据被用于训练新模型。但如果存在这些略有不同形状的新数据涌入，它就会压倒任何其他类型的数据。这意味着目前通用模型很难在大量任务上都表现得非常出色。

💡

即使对于智能体优于任何类似工作流程的应用，您仍然会受益于与低级别工作流程控制无关的框架功能：短期记忆存储、长期记忆存储、人在循环中、人在监控中、流式传输、容错、调试/可观测性。

OpenAI 的观点错在哪里？

如果我们回顾 OpenAI 的立场，会发现它建立在错误的二分法之上，为了夸大其单一抽象的价值，它混淆了“智能体框架”的不同维度。具体来说，它混淆了“声明式 vs 命令式”与“智能体抽象”以及“工作流程 vs 智能体”。

💡

最终，它未能抓住构建生产级智能体系统的主要挑战以及框架应该提供的主要价值，即：一个可靠的编排层，它赋予开发者对到达其 LLM 的上下文的显式控制权，同时无缝处理持久化、容错和人在循环交互等生产问题。

让我们分析一下我认为有问题的地方：

“声明式 vs 非声明式图”

LangGraph 不是完全声明式的——但它足够声明式，所以这不是我的主要抱怨。我的主要抱怨是“非声明式”这个说法有很多误导性。通常当人们批评声明式框架时，他们更喜欢命令式框架。但 Agents SDK 不是 命令式框架。它是一个抽象。更恰当的标题应该是“声明式 vs 命令式”或者“您需要一个编排框架吗”或者“为什么智能体抽象就是您所需要的”或者“工作流程 vs 智能体”，这取决于他们想论证什么 ( 他们似乎在下面同时论证两者 )。

“随着工作流程变得更动态和复杂，这种方法会迅速变得笨拙和具有挑战性”

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

至于工作流程 vs 智能体。很多工作流程并不需要这种程度的动态性和复杂性。OpenAI 和 Anthropic 都承认这一点。在可以使用工作流程时，您应该使用工作流程。大多数智能体系统是组合的。是的，如果一个工作流程确实非常动态和复杂，那么就使用智能体。但不要对所有事情都使用智能体。OpenAI 在文章前面确实这样说了。

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

再说一次——Agents SDK 不是命令式框架。它是一个抽象。它也有领域特定语言 ( 它的抽象 )。我认为，与学习 LangGraph 抽象相比，现在不得不学习和绕过 Agents SDK 抽象更糟。很大程度上是因为构建可靠智能体的困难在于确保智能体拥有正确的上下文，而 Agents SDK 比 LangGraph 更模糊这一点。

“更灵活”

这简直是完全错误的。事实恰恰相反。用 Agents SDK 能做的一切，用 LangGraph 都能做到。Agents SDK 只能做到 LangGraph 10% 的事情。

“代码优先”

使用 Agents SDK，您需要编写它的抽象。使用 LangGraph，您需要编写 大量 的普通代码。我不明白 Agents SDK 如何更“代码优先”。

“使用熟悉的编程结构”

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

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

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

比较智能体框架 ( Comparing Agent Frameworks )

我们已经讨论了智能体框架的许多不同组成部分：

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

我想尝试在一个表格中列出这些维度会很有趣。我尽量保持公正 ( 我 要求并获得了 Twitter 上许多有益的反馈！ )。

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

如果我遗漏了某个框架 ( 或者对某个框架的说法有误 )，请留下评论！

💡

您可以在 这里 找到此电子表格的实时版本。

结论

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