智能体深度解析：LangChain批驳OpenAI Agent手册存在误导性

LangChain创始人Harrison Chase似乎是个“好斗分子”，经常对某些观点或现象发表看法甚至写长文辩论批驳。

比如在2024年，他曾指出AutoGPT等框架的问题在于“试图完全自主运行”，缺乏人类干预机制。主张通过LangGraph等工具实现“Human-in-the-loop”控制，提倡Agent应支持从结构化工作流到灵活模型的渐进式过渡。

比如对当前爆火的MCP，Chase由开始质疑到后来肯定其价值。认可MCP在降低开发门槛和标准化工具集成方面的潜力，虽然当前存在技术局限性和成功率问题需要突破，但能够推动AI普及并可能成为行业标准。这在仍有不少质疑声的情况下，显得难能可贵。

Chase对OpenAI尤为关注，并经常对其新动向发表看法。2023年OpenAI发布GPTs时，他肯定GPTs无代码创新但反对其封闭生态，并推出开源OpenGPTs提供多模型支持和数据控制能力。他认为GPTs适合简单应用，而复杂场景仍需LangChain等开源框架,体现其开放生态的技术理念。

最近OpenAI发布了名为《A Practical Guide to Building AI Agents》的指导手册，这份短短34页的文件被认为是当前构建AI智能体的最佳资源，引发业界赞誉，甚至被奉为“Agent圣经”。

Harrison Chase却批评这份Agent开发指南“具有误导性”，认为其过于强调Agent与Workflow的二元对立，而现实中系统往往是混合体。他指责该指南脱离生产实际，忽视复杂需求，并过度简化“大模型主导一切”的思路。

这个观点，源自其在LangChain官方博客撰写了一篇名为《How to think about agent frameworks》长文。该文深入探讨了构建可靠的Agentic 系统所面临的挑战，核心在于确保语言模型（LLM）在每个步骤都拥有适当的上下文。批判了当前Agent框架领域存在的概念混淆和缺乏精确分析的现象，并提出了理解和比较不同 Agent 框架的关键维度。

对OpenAI观点的批判，可以算是该文的一大看点。文章认为OpenAI 的指南存在概念混淆，未能抓住构建生产级 Agentic 系统的核心挑战和框架的真正价值。

构建可靠的Agentic系统是一个复杂的问题，核心在于有效地管理和控制传递给LLM的上下文。当前的Agent框架格局尚不成熟，大多数框架仅仅是Agent封装的集合，仅仅提供了易于入门的Agent封装，牺牲了对底层逻辑和LLM输入的精细控制。

这篇文章对Agent框架进行了深入的思考和分析，强调了控制LLM上下文的重要性，并批评了过度依赖简单Agent封装集合的做法。推崇将Agentic系统视为工作流和agents的组合，并介绍了LangGraph作为一个提供了灵活编排能力和底层控制的框架。其观点鲜明，分析细致，对于理解Agent框架的本质和选择合适的工具具有很高的参考价值。

以下是这篇文章的正文，文章较长，感兴趣的小伙伴可以先收藏以后再精读。文中已经附带了该文提到了所有资源链接，不方便上网的朋友，可以后台回复 250423 获取相关资源。

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

声明式与非声明式

有些框架采用声明式方法，要求开发者提前通过由节点（智能体）和边（确定性或动态交接）组成的图，明确地定义工作流中的每一个分支、循环和条件判断。这种方法虽然在视觉上清晰明了，但随着工作流变得更加动态和复杂，很快就会变得繁琐且具有挑战性，往往还需要开发者学习专门的特定领域语言。

相比之下，智能体软件开发工具包（Agents SDK）采用了更灵活的代码优先方法。开发者可以直接使用熟悉的编程结构来表达工作流逻辑，无需提前完整地定义整个图，从而实现更动态、更具适应性的智能体编排。

这个观点最初让我很生气，但开始写回应时我意识到：思考agentic框架是很复杂的事情！大概有100种不同的智能体框架，从很多不同维度去比较它们，有时候它们会被混为一谈（就像在这句引用中那样）。外界有很多炒作、故作姿态和干扰信息。关于智能体框架，目前鲜有人进行精确的分析或深入思考。我们撰写这篇博客就是为了尝试进行这样的分析。我们将涵盖以下内容：

背景信息

• 什么是agent？
• 构建agent有什么难点？
• 什么是LangGraph？

Agentic框架的风格

• “Agents”与“工作流”
• 声明式与非声明式
• Agent封装
• 多agent（Multi agent）

常见问题

• 框架的价值是什么？
• 随着模型不断优化，一切是否会从工作流转变为智能体？
• OpenAI 在其观点中出现了哪些失误？
• 所有agentic框架如何比较？

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

• OpenAI的构建agents指南（我认为不是特别好）：https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf?ref=blog.langchain.dev
• Anthropic关于构建有效agents的指南（我非常喜欢）：https://www.anthropic.com/engineering/building-effective-agents?ref=blog.langchain.dev
• LangGraph（我们构建可靠agents的框架）：https://github.com/langchain-ai/langgraph?ref=blog.langchain.dev

背景信息

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

 什么是agent

Agents没有一致的定义，它们通常通过不同的视角提供。OpenAI采用更高层次、更具思想引领性的方法来定义agent。

Agents是代表您独立完成任务的系统。

我个人不喜欢这个。这是一个模糊的陈述，并不能真正帮助我理解什么是agents。这只是思想领导力，根本不实用。

将此与Anthropic的定义进行比较：

“Agents”可以通过多种方式定义。一些客户将agents定义为完全自主的系统，这些系统在较长时间内独立运行，使用各种工具完成复杂的任务。其他人使用该术语来描述遵循预定义工作流的更规范的实施。在Anthropic，我们将所有这些变体归类为agentic系统，但在工作流和agents之间划定了一个重要的架构区别：

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

另一方面，agents是LLM动态指导自己的流程和工具使用，保持对他们完成任务方式的控制的系统。

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

• 他们对agents的定义要精确得多，也要技术性得多。
• 他们还引用了“agentic systems”的概念，并将工作流和agents归类为此系统的变体。我喜欢这个。

我们在生产中看到的几乎所有“agentic系统”都是“工作流”和“agents”的组合。

在博客文章的后面，Anthropic将agents定义为“......通常只是使用基于环境反馈的工具的LLM循环。

尽管他们一开始对agents的定义很宏大，但这基本上也是OpenAI的意思。这类agent是通过以下参数进行定义的：

• 要使用的模型
• 要使用的说明（系统提示符）
• 要使用的工具

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

OpenAI和Anthropic都称工作流是与agents不同的设计模式。LLM在那里的控制较少，流程更具确定性。这是一个有用的区别！

OpenAI和Anthropic都明确指出，您并不总是需要agents。在许多情况下，工作流更简单、更可靠、更便宜、更快、性能更高。来自Anthropic帖子的一句话：

使用LLM构建应用程序时，我们建议找到尽可能简单的解决方案，并且仅在需要时增加复杂性。这可能意味着根本不构建agentic系统。agentic系统通常会以延迟和成本为代价来获得更好的任务性能，您应该考虑何时进行这种权衡是有意义的。

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

OpenAI说了类似的话：

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

在实践中，我们看到大多数“agentic系统”是工作流和agents的组合。这就是为什么我实际上讨厌谈论某物是否是agent，而更喜欢谈论一个系统的agentic性如何。感谢伟大的吴恩达（Andrew Ng）的这种思考方式：

我认为，与其以二元方式选择某物是否是agent，不如将系统视为在不同程度上类似agent会更有用。与名词“agent”不同，形容词“agentic”允许我们思考这样的系统，并将它们全部纳入这个不断增长的运动中。

  构建agents有什么难点？

我想大多数人都会同意构建agents很困难。或者更确切地说，将agents构建为原型很容易，但要可靠，可以为业务关键型应用程序提供支持？这很难。

棘手的部分正是使其可靠。您可以轻松地制作在Twitter上看起来不错的演示。但是，您能否运行它来支持业务关键型应用程序？并非没有大量的工作。

几个月前，我们对agent构建者进行了一项调查，并询问他们：“在生产中投入更多agents的最大限制是什么？到目前为止，排名第一的回答是“performance quality”，让这些agents工作仍然非常困难。

是什么导致agents有时表现不佳？因为LLM搞砸了。

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

根据我们的经验，它通常是第二种用例。这是什么原因造成的？

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

构建可靠的agentic系统的难点是确保LLM在每个步骤都有适当的上下文。这包括控制进入LLM的确切内容，以及运行适当的步骤来生成相关内容。

在讨论agentic框架时，记住这一点会很有帮助。任何使准确控制传递给LLM的内容变得更加困难的框架只会妨碍您。将正确的上下文传递给LLM已经够难的了，为什么要让自己更难呢？

什么是LangGraph

最好将LangGraph视为一个编排框架（具有声明式和命令式API），并在其上构建了一系列Agent封装。

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

• 基于图形的声明式语法
• Agent封装（构建在较低级别的框架之上）

LangGraph还支持功能性API（functional API）以及底层的事件驱动API（event-driven API）。存在Python和Typescript变体。

Agentic系统可以表示为节点和边。节点表示工作单元，而边缘表示过渡。节点和边只不过是普通的Python或TypeScript代码。因此，虽然图形的结构以声明性方式表示，但图形逻辑的内部功能是正常的命令式代码。边缘可以是固定的，也可以是有条件的。因此，虽然图形的结构是声明式的，但通过图形的路径可以是完全动态的。

LangGraph带有一个内置的持久层。这将启用容错、短期记忆和长期记忆。

此持久层还支持“人在环”和“人在环”模式，例如中断、批准、恢复和时间旅行。

LangGraph内置了对流的支持：of tokens、节点更新和任意事件。

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

Agentic框架的风格

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

工作流与Agents（Workflows vs Agents）

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

让我们记住构建可靠agents的难点：确保LLM具有正确的上下文。工作流有用的部分原因是，它们可以轻松地将正确的上下文传递给LLM。您可以决定数据的流动方式。

当您考虑要在“workflow”到“agent”的范围内构建应用程序时，需要考虑两件事：

• 可预测性vs能动性
• 低地板，高天花板

随着您的系统变得更加agents，它将变得难以预测。

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

可靠性并不能100%与可预测性相联系，但在实践中，它们可能密切相关。

您希望在此曲线上的位置因您的应用而异。LangGraph可用于在此曲线上的任何位置构建应用程序，允许您移动到曲线上您想要的点。

高门槛，低上限（High floor, low ceiling）

在考虑框架时，考虑它们的floors和ceilings可能会有所帮助：

• 低地板：低地板框架对初学者友好且易于上手
• 高楼层：具有高楼层的框架意味着它具有陡峭的学习曲线，需要大量知识或专业知识才能开始有效地使用它。
• 低天花板：天花板低的框架意味着它对它可以完成的事情有限制（你很快就会超越它）。
• 高天花板：高天花板框架为高级用例提供了广泛的功能和灵活性（它会与您一起成长？

工作流框架的上限很高，但门槛也很高，您必须自己编写大量agent逻辑。

Agentic框架的门槛较低，但上限较也-易于上手，但对于复杂的用例来说还不够。

LangGraph的目标是兼具低门槛（内置Agent封装，使其易于上手）和高上限（实现高级用例的低级功能）。

声明式与非声明式（Declarative vs non-declarative）

声明式框架有很多好处，但也有缺点。这是程序员之间看似无休止的争论，每个人都有自己的偏好。

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

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

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

其次，除了推荐的声明式API之外，我们实际上还支持其他API。具体来说，我们支持功能性API和事件驱动型API。虽然我们认为声明式API是一个有用的心智模型，但我们也认识到它并不适合所有人。

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

这是不正确的。像Agents SDK（以及最初的LangChain、CrewAI等）这样的框架既不是声明式的，也不是命令式的——它们只是封装。它们有一个Agent封装（一个Python类），它包含一堆运行agents的内部逻辑。它们并不是真正的编排框架。它们只是封装的。

 Agent封装（Agent Abstractions）

大多数agent框架都包含agent封装。它们通常从涉及提示、模型和工具的类开始。然后他们添加了更多参数...然后是更多......然后甚至更多。最终，您最终会得到一连串控制大量行为的参数，所有这些参数都封装在一个类后面。如果你想查看发生了什么，或者改变逻辑，你必须进入类并修改源代码。

这些封装最终使理解或控制LLM所有步骤中的内容变得非常非常困难。这很重要，拥有此控件对于构建可靠的agents至关重要（如上所述）。这就是Agent封装的危险。

我们从痛苦的过程中学到了这一点。这是原始LangChain链和agents的问题。他们提供了阻碍的封装概念。两年前的原始封装之一是接受模型、提示和工具的agent类。这并不是一个新概念。它当时没有提供足够的控制，现在也没有。

需要明确的是，这些Agent封装具有一定的价值。它使入门变得更加容易。但我认为这些Agent封装还不足以构建可靠的agents（也许永远）。

我们认为思考这些agent封装的最佳方式是像Keras一样。它们提供更高级别的封装，以便轻松入门。但至关重要的是，要确保它们构建在较低级别的框架之上，这样你就不会受其局限（不会因为其功能的局限性而无法进一步拓展）。

这就是我们在LangGraph上构建Agent封装的原因。这提供了一种开始使用agents的简单方法，但如果您需要转义到较低级别的LangGraph，则可以轻松实现。

 多agent（Multi Agent）

通常，agentic系统不只包含一个agent，而是包含多个agents。OpenAI在他们的报告中说：

对于许多复杂的工作流，将提示和工具拆分到多个agents中可以提高性能和可扩展性。当您的agents未能遵循复杂的说明或始终选择不正确的工具时，您可能需要进一步划分您的系统并引入更多不同的agents。

多agent系统的关键部分是它们如何通信。同样，构建agents的难点是获得LLM的正确上下文。这些agents之间的沟通很重要。

有很多方法可以做到这一点！交接是一种方式。这是我非常喜欢的Agents SDK的Agent封装。

但这些agents人员的最佳通信方式有时是工作流。获取Anthropic博客文章中的所有工作流程图，并将LLM调用替换为agents。工作流和agents的这种混合通常可提供最佳可靠性。

同样，agentic系统不仅仅是工作流，或者只是一个agent。它们可以而且通常是两者的组合。正如Anthropic在他们的博客文章中指出的那样：

组合和自定义这些模式

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

常见问题

在定义并探索了您应该评估框架的不同轴之后，现在让我们尝试回答一些常见问题。

框架的价值是什么？

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

Agent封装（Agent abstractions）

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

短期记忆（ Short term memory）

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

长期记忆（Long term memory）

虽然还处于早期阶段，但我非常看好agentic系统从他们的经验中学习（例如，在对话中记住事物）。LangGraph为跨线程内存提供生产就绪存储。

人机协同（Human-in-the-loop）

许多agentic系统通过一些人机协同组件变得更好。示例包括从用户那里获取反馈、批准工具调用或编辑工具调用参数。LangGraph提供内置支持，以在生产系统中启用这些工作流。

人工监督（Human-on-the-loop）

除了允许用户在agent运行时影响agent之外，允许用户在事后检查agent的轨迹，甚至返回到前面的步骤，然后从那里重新运行（有更改）也很有用。我们称之为Human-on-the-loop，LangGraph为此提供了内置支持。

流传输（Streaming）

大多数agentic应用程序需要一段时间才能运行，因此向最终用户提供更新对于提供良好的用户体验至关重要。LangGraph提供内置的Token、Graph steps和任意流的流式处理。

调试/可观察性（Debugging/observability）

构建可靠智能体的难点在于确保向大语言模型（LLM）传递正确的上下文。能够检查agents所采取的确切步骤，以及每个步骤中的确切输入和输出，对于构建可靠的agents至关重要。LangGraph 能与 LangSmith 无缝集成，以实现一流的调试和可观测性。

注意：人工智能可观测性与传统软件可观测性有所不同（这值得单独写一篇文章来探讨）。

容错能力（Fault tolerance）

容错能力是传统框架（如Temporal）用于构建分布式应用程序的一个关键组成部分。LangGraph凭借持久化工作流和可配置的重试机制，让实现容错变得更加容易。

优化（Optimization）

有时，定义评估数据集，然后根据此自动优化agents，有时比手动调整提示更容易。LangGraph目前不支持开箱即用，我们认为现在还为时过早。但我想包括这一点，因为我认为这是一个值得考虑的有趣维度，也是我们一直在关注的事情。是目前最好的框架。

所有这些价值属性（除了Agent封装）都为agents、工作流以及介于两者之间的所有内容提供了价值。

那么，您真的需要一个agentic框架吗？

如果您的应用程序不需要所有这些功能，并且/或者您想自己构建这些功能，那么您可能不需要这些功能。其中一些（如短期记忆）并不是非常复杂。其中其他方法（如Human-on-the-loop或LLM特定的可观察性）则更为复杂。

关于Agent封装：我同意Anthropic在他们的帖子中所说的：

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

随着模型变得更好，一切都会成为agents而不是工作流吗？

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

我认为有很多事情可能是真的：

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

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

使用LLM构建应用程序时，我们建议找到尽可能简单的解决方案，并且仅在需要时增加复杂性。这可能意味着根本不构建agentic系统。agentic系统通常会以延迟和成本为代价来获得更好的任务性能，您应该考虑何时进行这种权衡是有意义的。

来自OpenAI的帖子：

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

是否有应用程序需要这个简单的工具调用循环就足够了？我认为，只有当您对特定于您的用例的大量数据使用经过训练/微调/RL的模型时，这可能才是正确的。这可以通过两种方式发生：

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

（旁注：如果我在一个我的任务不独特的领域建立一家垂直创业公司，我会非常担心我的创业公司的长期生存能力）。

您的任务是独一无二的（Your task is unique）

我敢打赌，大多数用例（当然大多数企业用例）都属于这一类。AirBnb处理客户支持的方式与Klarna处理客户支持的方式不同，后者与Rakuten处理客户支持的方式不同。这些任务中有很多微妙之处。Sierra作为客户支持领域的领先agent公司，不是构建单个客户支持agent，而是构建客户支持agent平台：

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

他们需要这样做，因为每家公司的客户支持体验都足够独特，而通用agent的性能不够。

Agent的一个示例是一个简单的工具调用循环，使用针对特定任务训练的模型：OpenAI的Deep Research。所以这是可以做到的，而且它可以产生惊人的agents。

如果您可以在特定任务上训练SOTA模型，那么是的，您可能不需要支持任意工作流的框架，您只需使用一个简单的工具调用循环。在这种情况下，agents将优先于工作流。

我心中一个非常开放的问题是：有多少agent公司将拥有数据、工具或知识来为他们的任务训练SOTA模型？此时此刻，我认为只有大型模型实验室才能做到这一点。但这种情况会改变吗？小型垂直初创公司能否为他们的任务训练SOTA模型？我对这个问题很感兴趣。如果您目前正在执行此作，请联系我们！

您的任务不是唯一的（Your task is not unique）

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

OpenAI通过API发布了他们的计算机使用模型，该模型是在通用计算机使用数据上微调的模型，旨在在该通用任务中足够好。（旁注：我认为它还不够好）。

Code就是一个有趣的例子。编码相对通用，到目前为止，编码绝对是agents的一个突破性用例。Claude代码和OpenAI的Codex CLI是使用这个简单工具调用循环的编码agents的两个示例。我敢打赌，基本模型经过了大量编码数据和任务的训练。

这篇文档，证明Anthropic是这样做的：https://docs.anthropic.com/en/docs/build-with-claude/tool-use/text-editor-tool?ref=blog.langchain.dev

有趣的是——当通用模型基于这些数据进行训练时，这些数据的具体形态有多重要呢？Ben Hylak前几天发了一条有趣的推文，似乎引起了很多人的共鸣。

• 模型不再知道如何使用Cursor。
• 它们都针对终端进行了优化。这就是为什么Claude 3.7和OpenAI o3在Cursor中如此糟糕，而在Cursor之外又如此令人惊叹。

这可能表明两件事：

• 你的任务必须与通用模型所接受的训练任务高度相似。你的任务与通用模型的训练任务相似度越低，通用模型适用于你的使用场景的可能性就越小。
• 用其他特定任务的数据来训练通用模型，可能会降低其在你任务上的表现。我敢肯定，在训练新模型时，使用了大量（甚至更多）与Cursor使用场景相似的数据。但如果突然涌入大量稍有不同形式的新数据，那么这些新数据的影响力就会超过其他任何类型的数据。这意味着，目前通用模型很难在众多任务上都表现得极为出色。

即使是在那些更倾向于使用智能体（而非类似工作流的方式）的应用场景中，你仍然能够从框架的某些特性中获益，而这些特性与低级别的工作流控制并无关联，比如短期记忆存储、长期记忆存储、人在回路（实时参与决策等）、人在环上（定期监督等）、流式处理、容错能力以及调试/可观测性。

 OpenAI的观点中有什么地方是错误的？

如果我们重新审视OpenAI的立场，我们会发现它以错误的二分法为前提，这些二分法将“agentic框架”的不同维度混为一谈，以夸大其单一封装的价值。具体来说，它将“声明式与命令式”与“Agent封装”以及“工作流与agents”混为一谈。

最终，它错过了构建生产agentic系统的主要挑战以及框架应该提供的主要价值，即：一个可靠的编排层，使开发人员能够明确控制到达其LLM的上下文，同时无缝处理持久性、容错和人机交互等生产问题。

让我们分析一下我认为他们观点有争议的具体部分：

声明式VS非声明式（Declarative vs non-declarative graph）

有些框架采用声明式方法，要求开发者提前通过由节点（agents）和边（确定性或动态交接点）组成的图，明确地定义工作流中的每一个分支、循环和条件判断。虽然这种方法在视觉呈现上较为清晰，但随着工作流变得更加动态和复杂，它很快就会变得繁琐且具有挑战性，往往还需要开发者学习专门的特定领域语言。

相比之下，Agents SDK采用了更灵活的“代码优先”方法。开发者可以直接使用熟悉的编程结构来表达工作流逻辑，而无需提前完整地预定义整个图，从而实现更动态、更具适应性的智能体编排。

“声明式VS非声明式”（Declarative vs non-declarative graph）

LangGraph不是完全声明式的，但它足够声明性，所以这不是我的主要抱怨。我的主要抱怨是“非声明式”做了很多工作并且具有误导性。通常，当人们批评声明式框架时，他们更喜欢一个更命令式的框架。

但Agents SDK不是一个强制性框架。这是一个封装的概念。更合适的标题是“声明式vs命令式”或“是否需要编排框架”或“为什么Agent封装就是你所需要的”或“工作流与agents”，这取决于他们想要争论的内容（他们似乎在下面争论了两者）。

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

这与声明式或非声明式没有任何关系。这与工作流与agents有关。您可以轻松地将Agents SDK中的agent逻辑表示为声明式，并且该图形与Agents SDK一样动态和灵活。

关于工作流程与agents的点。许多工作流不需要这种级别的动态性和复杂性。OpenAI和Anthropic都承认这一点。当您可以使用工作流时，您应该使用工作流。大多数agentic系统是组合。是的，如果工作流确实是动态且复杂的，请使用agent。但不要对所有事情都使用agent。OpenAI在论文的前面就字面地说了这一点。

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

同样Agents SDK不是一个命令性框架，而是一个封装的概念。它还具有特定于域的语言（它的封装）。我认为，在这一点上，必须学习和解决Agents SDK封装问题比必须学习LangGraph封装更糟糕。主要是因为构建可靠agents的难点是确保agent具有正确的上下文，而Agents SDK比LangGraph更能混淆这一点。

“更灵活”

这绝对不是真的。这与事实相反。您可以使用Agents SDK执行的所有作，以及LangGraph执行的所有作。Agents SDK只允许您执行LangGraph所能执行的作的10%。

“代码优先”

使用Agents SDK，您可以编写其封装。使用LangGraph，您可以编写大量普通代码。我不明白Agents SDK如何更注重代码优先。

“使用熟悉的编程结构”

使用Agents SDK，您必须学习一组全新的封装。使用LangGraph，您可以编写大量普通代码。还有什么比这更熟悉的呢？

“实现更动态和适应性更强的agents编排”

同样地这与声明式与非声明式无关。这与工作流与agents有关。见上一点。

 比较agentic框架

我们已经讨论了agentic框架的许多不同组件：

• 它们是灵活的编排层，还是只是一个Agent封装？
• 如果它们是灵活的编排层，它们是声明式的还是其他的？
• 这个框架提供了哪些功能（除了Agent封装）？

我认为尝试在电子表格中列出这些维度会很有趣。我试图在这个问题上尽可能公正。

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

在线链接：https://docs.google.com/spreadsheets/d/1B37VxTBuGLeTSPVWtz7UMsCdtXrqV5hCjWkbHN8tfAo/edit?ref=blog.langchain.dev&gid=0#gid=0

结论

• 构建可靠的agentic系统的难点是确保LLM在每个步骤都有适当的上下文。这包括控制进入LLM的确切内容，以及运行适当的步骤来生成相关内容。
• Agentic系统由工作流和agents（以及介于两者之间的所有内容）组成。
• 大多数agentic框架既不是声明式也不是命令式编排框架，而只是一组Agent封装。
• Agent封装可以使入门变得容易，但它们通常会混淆，并且难以确保LLM在每个步骤中都有适当的上下文。
• 各种形状和大小的agentic系统（agents或工作流）都受益于同一组有用的功能，这些功能可以由框架提供，也可以从头开始构建。
• 最好将LangGraph视为一个编排框架（具有声明式和命令式API），并在其上构建了一系列Agent封装。

参考来源：​​​​https://blog.langchain.dev/how-to-think-about-agent-frameworks/​​​

本文转载自​​​​​王吉伟​​​​​，作者：王吉伟​