通信人家园

标题: OpenAI“Agent 圣经”翻车？LangChain 创始人怒怼“全是坑” [查看完整版帖子] [打印本页]

时间: 2025-4-23 10:03

作者: ttxx 标题: OpenAI“Agent 圣经”翻车？LangChain 创始人怒怼“全是坑”

当前，AI 领域呈现出一种近乎“追星式”的热情氛围，每当有新的东西发布，便迅速引发广泛关注与高度评价，仿佛技术变革即将一触即发。同时大家情绪也波动剧烈，从“危机论”到“爆发论”频繁切换。OpenAI 最近出的《A Practical guide to building AI agents》的指南，就是他们最近捧上天的“神作”。它直接被捧成了“圣经”，一时间风头无两。

这份 34 页的指南被誉为“市面上最优秀的资源”，旨在为产品和工程团队提供构建 AI 智能体的实用方法，涵盖了 Agent 的定义、识别 Agent 应用场景、设计框架、逻辑和编排模式等关键方面。

不过，以冷静理性著称的 LangChain 创始人 Harrison Chase 对 OpenAI 的这份指南中提出的一些核心观点表达了强烈异议，甚至表示该指南一开始就让人感到“恼火”。他公开批评这份指南“具有误导性”，并罕见地进行了逐字逐句的分析。

他认为，OpenAI 在定义 Agent 时采取了一种过于僵硬的“二元对立”方法。实际上，目前大多数“Agentic 系统”都是 Workflows 和 Agents 的有机结合。而理想的 Agent 框架应当能够支持从“结构化工作流”向“由大模型驱动”的模式逐步过渡，并且在两者之间灵活切换。

所以，可以说这场争论的核心依然是一个老问题：究竟是应该让“大模型直接掌控一切”，还是坚持“依然需要自己写代码”？（过去叫“Chains”，现在更多人用“Workflows”来表达。）

为什么路线之争至关重要？

在构建与大模型相关的应用过程中，越来越多的人逐渐认识到一个残酷的现实：数百个工程师小时投入的精细流程和手动调优，往往在下一次大型模型更新后，一夜之间就被彻底摧毁。

比如说早期使用 GPT-2 开源模型的工程师，当时因为模型本身能力差，能处理的上下文窗口又小，推理能力也很弱，开发者不得不在模型外手写大量代码，让其尽可能的可靠地工作起来。但随着模型逐渐变得聪明，大家又不得不一段段地删掉原先写的那些复杂代码。这种反复被打击、被迫重新适应的经历，正在成为 AI 工程师们必须经历的一次又一次的惨痛教训。

传统的软件系统设计，大多遵循清晰的请求 - 响应模式。前端发送请求，后端接收请求，访问数据库，执行变更，再返回结果。这种模式在过去几十年里构建了无数成功的系统。而即便引入了自动化或代码生成工具，本质上，真正起作用的仍是工程师在开发阶段对代码的精细打磨。代码一旦部署到生产环境，执行的就是确定性的、静态的计算过程。

但今天，越来越多的系统开始引入模糊计算（fuzzy compute），依靠大模型进行动态推理和生成响应。以 OpenAI 为例，全球数以万计的应用正在调用其模型服务，每次调用并不是简单的 CRUD 操作，而是依赖模型的推理能力在运行时做出决策。这种变化意味着，应用程序的行为不再由静态代码全权决定，而是由不断进化的模型能力动态驱动。而且，不论你是否持续优化自己本地的代码，只要大模型在背后不断进化，调用这些模型的应用自然也会获益。

与此同时，大模型自身的进步速度远超预期。今年 OpenAI 和 Gemini 的 Deep Research 项目的成功，就是充分利用 O3 进行研究规划和推理执行的例子；随后 Bolt 和 Manus AI 也基于 Claude 做出了类似实践，而且几乎未使用复杂的工作流工程。

这些都说明，随着大模型能力越来越强，传统那套“人精细打磨、模型配合执行”的模式正在变得越来越吃力，而让模型自主推理、动态决策的系统，反而越来越有优势。

因此这也决定了我们到底是继续靠人手设计复杂的工作流，让模型在框架里跑，还是直接利用大模型越来越强的推理能力，搭建更灵活、更通用的 Agent。

Workflows 和 Agents 应该怎么选？

Agent 的定义

Harrison Chase 认为目前 Agent 并没有一个统一的或大家公认的定义，不同的人常常从不同的角度来定义它。

OpenAI 认为，Agent 是“能代表你独立完成任务的系统”，但这种说法较为笼统、务虚，一点也不实用。Harrison Chase 更喜欢 Anthropic 的定义，认为他们的定义更精确，更技术化：

不同客户对 Agent 的认知存在差异。有些人将 Agent 视为完全自主的系统，能够长时间独立运行，灵活使用各种工具来完成复杂任务。也有些人认为 Agent 是遵循预设规则、按照固定 Workflows 运作的系统。在 Anthropic，我们把所有这些变体都归类为 Agentic 系统，但在架构上，我们明确区分 Workflows 和 Agents：

Workflows：依靠预先编写好的代码路径，协调 LLM 和工具完成任务； Agents：由 LLM 动态推理，自主决定任务流程与工具使用，拥有更大的决策自由度。

对于 Agent 的配置，通常包括模型、指令和工具，且多在循环中执行任务。两者的主要区别在于，Workflows 更为确定性和可控，适合简单任务；而 Agents 更灵活、适合复杂的、需要动态决策的场景。

大多数情况下，简单的 Workflows 就足够用，只有在任务复杂且需要更高灵活性时，才需要构建 Agentic 系统。正如 Anthropic 提到的：“在开始构建 Agent 之前，确保你的用例确实需要它。” 因此，Harrison Chase 指出，我们不需要像 OpenAI 那样，去纠结某个系统“是不是”一个 Agent：

“在实际应用中，我们发现大多数‘Agentic 系统’其实是 Workflows 和 Agents 的结合。这也是为什么我更倾向于讨论一个系统‘有多 Agentic’。”

另外，搭建一个 Agent 原型并不难，真正的挑战在于，如何构建一个稳定可靠、能支撑关键业务的 Agent 系统。如今，做一个在 Twitter 上好看的 demo 很容易，但要支撑实际业务，“没有大量工作是做不到的”。

Harrison Chase 表示他们之前做过一次针对 Agent 开发者的调查，调查显示“性能质量（performance quality）”被认为是将 Agents 投入生产的最大障碍。也就是说，让 Agents 稳定可靠地工作，依然是个巨大的挑战。

LLM 本身能力存在局限性，且在上下文信息传递方面常出现错误或不完整的情况，后者在实践中更为普遍。导致 Agent 效果不佳的常见原因包括：System Message 不完整或过于简短、用户输入模糊不清、未向 LLM 提供正确的工具、工具描述不清晰、缺乏恰当的上下文信息以及工具返回的响应格式不正确。

Workflows 和 Agents 混合模式更为可靠

Agentic 框架主要分为提供高级别 Agent 封装和常见 Workflow 封装两种类型。而像 LangGraph 这样的底层编排框架，则可同时支持 Workflows、Agents 以及二者之间的混合形态，这对于构建生产级 Agentic 系统至关重要。

构建可靠 Agents 的关键挑战在于确保大模型接收到正确的上下文信息，而 Workflows 的优势在于它们能够将正确的上下文传递给给 LLMs ，可以精确地决定数据如何流动。

构建应用时，需要在“可预测性 vs 自主性”和“低门槛 vs 高上限”之间找到平衡。当系统越偏向 Agentic，其可预测性就会越低。Workflow 框架提供了高上限，但门槛也高，但需要自己编写很多 Agent 的逻辑。Agent 框架则是低门槛，但上限也低——虽然容易上手，但不足以应对复杂的用例。像 LangGraph 这样的框架，目标是兼具低门槛（提供内置的 Agent 封装，方便快速启动）和高上限（提供低层功能，支持实现高级用例）。

许多 Agent 框架提供的 Agent 封装（如包含 prompt、model 和 tools 的类）虽然易于上手，但可能限制对 LLM 输入输出的控制，从而影响可靠性，早期的 LangChain 也曾面临类似问题，“它们提供的封装反而成了障碍”。

像 Agents SDK（以及早期的 LangChain， CrewAI 等）这样的框架，既不是声明式的也不是命令式的，它们只是封装。它们提供一个 Agent 封装（一个 Python 类），这个类里面封装了很多用于运行 Agent 的内部逻辑。它们算不上真正的编排框架，仅仅是一种封装。

这些封装最终会让你非常非常难以理解或控制到底在每一步传递给 LLM 的具体内容是什么。这一点非常重要，拥有这种控制能力对于构建可靠的 Agents 至关重要。这就是 Agent 封装的危险之处。

在实际应用中，Agentic 系统往往并非由单一 Agent 组成，而是由多个 Agent 协作完成。在多 Agent 系统中，通信机制至关重要。因为构建可靠 Agent 的核心，依然是确保 LLM 能接收到正确、充分的上下文信息。为了实现高效通信，常见的方法包括「Handoffs」（交接）等模式，像 Agents SDK 就提供了这种风格的封装。

但有时候，这些 Agents 之间最好的通讯方式是 Workflows。而 Workflows 和 Agents 的混合模式，往往能带来最好的可靠性，因此 Agentic 系统往往是 Workflows 与 Agents 的结合体。如 Anthropic 所总结的：“这些构建模块并非一成不变的指令，而是可以根据具体用例自由调整和组合的常见模式”。

而 Agent 框架则通过提供统一封装、记忆管理、人机协作、流式处理、可观测性和容错机制，大幅降低构建可靠 Agentic 系统的复杂度，但前提是开发者需理解其底层机制。

如果你的应用不需要所有这些功能，并且/或者你愿意自己去构建它们，那么你可能就不需要框架。其中一些功能（比如 Short term memory）并不是特别复杂。但另一些功能（比如 Human-on-the-loop，或 LLM 特定的可观测性）则更为复杂。

大模型越来越厉害，那么是不是都会变成 Agents？

Chase 认为，未来所有应用都将由简单的、能够调用工具的 Agents 主导的观点是值得商榷的。虽然工具调用 Agents 的性能在提升，但“能够控制输入给 LLM 的内容依然会非常重要（垃圾进，垃圾出）”，简单的 Agent 循环并不能覆盖所有应用需求。

实际上，对于很多企业级应用来说，任务本身具有大量细微差异，难以靠单一、通用的 Agent 处理。“每家公司的客户支持体验都足够独特，以至于一个通用 Agent 无法达到所需的性能”，这也是 Sierra 选择构建客户支持 Agent 平台而非单一 Agent 的原因。

OpenAI 的 Deep Research 项目是 Agent 的一个好例子，这同时也证明了针对特定任务训练的模型可以只用简单 Agent 循环。它的成功前提是：“你能针对你的特定任务训练一个 SOTA 模型”，而当前只有大型模型实验室能够做到这一点。对于大多数初创公司或企业用户来说，这并不现实。

在通用任务领域，Claude code 和 OpenAI 的 Codex CLI 是两个代码 Agents 的例子，它们都使用了简单的工具调用循环。但 Chase 认为，其基础模型在训练时使用了大量的编程数据和任务，这些领域数据的确切形态也影响巨大。正如 Chase 引用 Ben Hylak 的观察：

当前的模型已经不再擅长在 Cursor 中工作了。

它们的优化方向主要是针对终端环境，这也是为什么 3.7 和 o3 在 Cursor 里体验较差，但在其他环境中表现出色的原因。

因此，总结来看，简单 Agents 在特定条件下有效，但仅限于数据和任务极为匹配的场景。对绝大多数应用而言，Workflows 仍然不可或缺，且生产环境中的 Agentic 系统将是 Workflows 和 Agents 的结合。

OpenAI 的观点哪里不对？

Chase 指出，OpenAI 在讨论 Agentic 框架时，其观点建立在一些错误的二分法之上，混淆了“Agentic 框架”的不同维度，从而夸大了他们单一封装的价值。归根结底，他们没有准确把握生产级 Agentic 系统的核心挑战，也没有清晰认识到框架真正应该提供的价值——即一个可靠、透明的编排层，能够让开发者精确控制传递给 LLM 的上下文，同时无缝处理持久化、容错、Human-in-the-loop 等生产关键问题。

他认为 OpenAI 的论述中存在以下几方面的问题（除去一些王婆卖瓜的观点）：

OpenAI 将“声明式 vs 非声明式”与“是否需要编排框架”混为一谈

LangGraph 并不是完全声明式的 —— 但它已经足够声明式了，主要的问题是，“非声明式”这个说法承担了太多含义，而且具有误导性。通常，当人们批评声明式框架时，他们倾向于更偏好命令式框架。“但 Agents SDK 并不是一个命令式框架，它是一种封装”。

错误归因 Workflows 的局限性

OpenAI 声称：“随着 Workflows 变得越来越动态和复杂，这种方法会迅速变得笨拙和具有挑战性。”

但实际上，这与声明式或非声明式无关，而是 Workflows 和 Agents 的应用场景问题。你完全可以用声明式的图来表达 Agents SDK 中的 Agent 逻辑，而且这个图的动态性和灵活性，和 Agents SDK 本身是一样的。

更重要的是，大部分应用场景下，Workflows 足够简单直接，OpenAI 和 Anthropic 自己也承认这一点。因此，我们应该尽可能使用 Workflows，大多数 Agentic 系统都是两者的结合。只有在确实需要时才引入更复杂的 Agent，但不要什么都用 Agent。

低估了 Agents SDK 本身的学习复杂度

OpenAI 暗示使用框架会引入新的领域特定语言，增加学习成本。但实际上：“Agents SDK 本身就是一种新的封装，它也需要学习，而且学习曲线更陡峭。” 特别是在确保正确上下文传递这一关键点上，Agents SDK 比 LangGraph 反而增加了开发难度。

关于“灵活性”的错误陈述

OpenAI 宣称 Agents SDK 更灵活，但实际情况是：“用 Agents SDK 能做到的事情，只是 LangGraph 能力范围的 10%。” LangGraph 提供了更通用、更强大的编排能力，而不是简单封装特定模式。

关于“实现更动态和适应性强的 Agent 编排”的误导

最后，OpenAI 认为 Agents SDK 可以实现更动态、更适应性的编排，但这本质上还是一个“Workflows vs Agents”的设计权衡问题。

最后，Harrison 在他的文章中还做了一件很酷的事情，那就是他列了一个表格，把现在市上所有相关的 Agent 框架都拿出来做了个全面的比较。

对于想要深入了解和选择 Agent 框架的开发者来说，它提供了一个结构化的、易于理解的方式来比较不同框架的能力，帮助开发者做出更明智的决策，并认识到优秀 Agent 框架应该具备的关键特性。

参考链接：

https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf

https://blog.langchain.dev/how-to-think-about-agent-frameworks/

https://docs.google.com/spreadsheets/d/1jzgbANBVi6rNzZVsjZC2CSaCU-byXGlSs0bgy2v2GNQ/edit?gid=0#gid=0

https://www.youtube.com/watch?v=-rsTkYgnNzM

来源：36kr

时间: 2025-4-23 10:36

作者: laozhu

好好学习下

通信人家园 (https://www.txrjy.com/)