OpenAI“Agent万能论”遭打脸！LangChain创始人：Deep Search恰恰证明Workflows不可取代
仅用于站内搜索，没有排版格式，具体信息请跳转上方微信公众号内链接
整理|Tina
当前，AI领域呈现出一种近乎“追星式”的热情氛围，每当有新的东西发布，便迅速引发广泛关注与高度评价，仿佛技术变革即将一触即发。同时大家情绪也波动剧烈，从“危机论”到“爆发论”频繁切换。OpenAI最近出的《APracticalguidetobuildingAIagents》的指南，就是他们最近捧上天的“神作”。它直接被捧成了“圣经”，一时间风头无两。
这份34页的指南被誉为“市面上最优秀的资源”，旨在为产品和工程团队提供构建AI智能体的实用方法，涵盖了Agent的定义、识别Agent应用场景、设计框架、逻辑和编排模式等关键方面。
不过，以冷静理性著称的LangChain创始人HarrisonChase对OpenAI的这份指南中提出的一些核心观点表达了强烈异议，甚至表示该指南一开始就让人感到“恼火”。他公开批评这份指南“具有误导性”，并罕见地进行了逐字逐句的分析。
他认为，OpenAI在定义Agent时采取了一种过于僵硬的“二元对立”方法。实际上，目前大多数“Agentic系统”都是Workflows和Agents的有机结合。而理想的Agent框架应当能够支持从“结构化工作流”向“由大模型驱动”的模式逐步过渡，并且在两者之间灵活切换。
所以，可以说这场争论的核心依然是一个老问题：究竟是应该让“大模型直接掌控一切”，还是坚持“依然需要自己写代码”？（过去叫“Chains”，现在更多人用“Workflows”来表达。）
为什么路线之争至关重要？
在构建与大模型相关的应用过程中，越来越多的人逐渐认识到一个残酷的现实：数百个工程师小时投入的精细流程和手动调优，往往在下一次大型模型更新后，一夜之间就被彻底摧毁。
比如说早期使用GPT-2开源模型的工程师，当时因为模型本身能力差，能处理的上下文窗口又小，推理能力也很弱，开发者不得不在模型外手写大量代码，让其尽可能的可靠地工作起来。但随着模型逐渐变得聪明，大家又不得不一段段地删掉原先写的那些复杂代码。这种反复被打击、被迫重新适应的经历，正在成为AI工程师们必须经历的一次又一次的惨痛教训。
传统的软件系统设计，大多遵循清晰的请求-响应模式。前端发送请求，后端接收请求，访问数据库，执行变更，再返回结果。这种模式在过去几十年里构建了无数成功的系统。而即便引入了自动化或代码生成工具，本质上，真正起作用的仍是工程师在开发阶段对代码的精细打磨。代码一旦部署到生产环境，执行的就是确定性的、静态的计算过程。
但今天，越来越多的系统开始引入模糊计算（fuzzycompute），依靠大模型进行动态推理和生成响应。以OpenAI为例，全球数以万计的应用正在调用其模型服务，每次调用并不是简单的CRUD操作，而是依赖模型的推理能力在运行时做出决策。这种变化意味着，应用程序的行为不再由静态代码全权决定，而是由不断进化的模型能力动态驱动。而且，不论你是否持续优化自己本地的代码，只要大模型在背后不断进化，调用这些模型的应用自然也会获益。
与此同时，大模型自身的进步速度远超预期。今年OpenAI和Gemini的DeepResearch项目的成功，就是充分利用O3进行研究规划和推理执行的例子；随后Bolt和ManusAI也基于Claude做出了类似实践，而且几乎未使用复杂的工作流工程。
这些都说明，随着大模型能力越来越强，传统那套“人精细打磨、模型配合执行”的模式正在变得越来越吃力，而让模型自主推理、动态决策的系统，反而越来越有优势。
因此这也决定了我们到底是继续靠人手设计复杂的工作流，让模型在框架里跑，还是直接利用大模型越来越强的推理能力，搭建更灵活、更通用的Agent。
Workflows和Agents应该怎么选？
Agent的定义
HarrisonChase认为目前Agent并没有一个统一的或大家公认的定义，不同的人常常从不同的角度来定义它。
OpenAI认为，Agent是“能代表你独立完成任务的系统”，但这种说法较为笼统、务虚，一点也不实用。HarrisonChase更喜欢Anthropic的定义，认为他们的定义更精确，更技术化：
不同客户对Agent的认知存在差异。有些人将Agent视为完全自主的系统，能够长时间独立运行，灵活使用各种工具来完成复杂任务。也有些人认为Agent是遵循预设规则、按照固定Workflows运作的系统。在Anthropic，我们把所有这些变体都归类为Agentic系统，但在架构上，我们明确区分Workflows和Agents：
Workflows：依靠预先编写好的代码路径，协调LLM和工具完成任务；Agents：由LLM动态推理，自主决定任务流程与工具使用，拥有更大的决策自由度。
对于Agent的配置，通常包括模型、指令和工具，且多在循环中执行任务。两者的主要区别在于，Workflows更为确定性和可控，适合简单任务；而Agents更灵活、适合复杂的、需要动态决策的场景。
大多数情况下，简单的Workflows就足够用，只有在任务复杂且需要更高灵活性时，才需要构建Agentic系统。正如Anthropic提到的：“在开始构建Agent之前，确保你的用例确实需要它。”因此，HarrisonChase指出，我们不需要像OpenAI那样，去纠结某个系统“是不是”一个Agent：
“在实际应用中，我们发现大多数‘Agentic系统’其实是Workflows和Agents的结合。这也是为什么我更倾向于讨论一个系统‘有多Agentic’。”
另外，搭建一个Agent原型并不难，真正的挑战在于，如何构建一个稳定可靠、能支撑关键业务的Agent系统。如今，做一个在Twitter上好看的demo很容易，但要支撑实际业务，“没有大量工作是做不到的”。
HarrisonChase表示他们之前做过一次针对Agent开发者的调查，调查显示“性能质量（performancequality）”被认为是将Agents投入生产的最大障碍。也就是说，让Agents稳定可靠地工作，依然是个巨大的挑战。
LLM本身能力存在局限性，且在上下文信息传递方面常出现错误或不完整的情况，后者在实践中更为普遍。导致Agent效果不佳的常见原因包括：SystemMessage不完整或过于简短、用户输入模糊不清、未向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也曾面临类似问题，“它们提供的封装反而成了障碍”。
像AgentsSDK（以及早期的LangChain，CrewAI等）这样的框架，既不是声明式的也不是命令式的，它们只是封装。它们提供一个Agent封装（一个Python类），这个类里面封装了很多用于运行Agent的内部逻辑。它们算不上真正的编排框架，仅仅是一种封装。
这些封装最终会让你非常非常难以理解或控制到底在每一步传递给LLM的具体内容是什么。这一点非常重要，拥有这种控制能力对于构建可靠的Agents至关重要。这就是Agent封装的危险之处。
在实际应用中，Agentic系统往往并非由单一Agent组成，而是由多个Agent协作完成。在多Agent系统中，通信机制至关重要。因为构建可靠Agent的核心，依然是确保LLM能接收到正确、充分的上下文信息。为了实现高效通信，常见的方法包括「Handoffs」（交接）等模式，像AgentsSDK就提供了这种风格的封装。
但有时候，这些Agents之间最好的通讯方式是Workflows。而Workflows和Agents的混合模式，往往能带来最好的可靠性，因此Agentic系统往往是Workflows与Agents的结合体。如Anthropic所总结的：“这些构建模块并非一成不变的指令，而是可以根据具体用例自由调整和组合的常见模式”。
而Agent框架则通过提供统一封装、记忆管理、人机协作、流式处理、可观测性和容错机制，大幅降低构建可靠Agentic系统的复杂度，但前提是开发者需理解其底层机制。
如果你的应用不需要所有这些功能，并且/或者你愿意自己去构建它们，那么你可能就不需要框架。其中一些功能（比如Shorttermmemory）并不是特别复杂。但另一些功能（比如Human-on-the-loop，或LLM特定的可观测性）则更为复杂。
大模型越来越厉害，那么是不是都会变成Agents？
Chase认为，未来所有应用都将由简单的、能够调用工具的Agents主导的观点是值得商榷的。虽然工具调用Agents的性能在提升，但“能够控制输入给LLM的内容依然会非常重要（垃圾进，垃圾出）”，简单的Agent循环并不能覆盖所有应用需求。
实际上，对于很多企业级应用来说，任务本身具有大量细微差异，难以靠单一、通用的Agent处理。“每家公司的客户支持体验都足够独特，以至于一个通用Agent无法达到所需的性能”，这也是Sierra选择构建客户支持Agent平台而非单一Agent的原因。
OpenAI的DeepResearch项目是Agent的一个好例子，这同时也证明了针对特定任务训练的模型可以只用简单Agent循环。它的成功前提是：“你能针对你的特定任务训练一个SOTA模型”，而当前只有大型模型实验室能够做到这一点。对于大多数初创公司或企业用户来说，这并不现实。
在通用任务领域，Claudecode和OpenAI的CodexCLI是两个代码Agents的例子，它们都使用了简单的工具调用循环。但Chase认为，其基础模型在训练时使用了大量的编程数据和任务，这些领域数据的确切形态也影响巨大。正如Chase引用BenHylak的观察：
当前的模型已经不再擅长在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并不是完全声明式的——但它已经足够声明式了，主要的问题是，“非声明式”这个说法承担了太多含义，而且具有误导性。通常，当人们批评声明式框架时，他们倾向于更偏好命令式框架。“但AgentsSDK并不是一个命令式框架，它是一种封装”。
错误归因Workflows的局限性
OpenAI声称：“随着Workflows变得越来越动态和复杂，这种方法会迅速变得笨拙和具有挑战性。”
但实际上，这与声明式或非声明式无关，而是Workflows和Agents的应用场景问题。你完全可以用声明式的图来表达AgentsSDK中的Agent逻辑，而且这个图的动态性和灵活性，和AgentsSDK本身是一样的。
更重要的是，大部分应用场景下，Workflows足够简单直接，OpenAI和Anthropic自己也承认这一点。因此，我们应该尽可能使用Workflows，大多数Agentic系统都是两者的结合。只有在确实需要时才引入更复杂的Agent，但不要什么都用Agent。
低估了AgentsSDK本身的学习复杂度
OpenAI暗示使用框架会引入新的领域特定语言，增加学习成本。但实际上：“AgentsSDK本身就是一种新的封装，它也需要学习，而且学习曲线更陡峭。”特别是在确保正确上下文传递这一关键点上，AgentsSDK比LangGraph反而增加了开发难度。
关于“灵活性”的错误陈述
OpenAI宣称AgentsSDK更灵活，但实际情况是：“用AgentsSDK能做到的事情，只是LangGraph能力范围的10%。”LangGraph提供了更通用、更强大的编排能力，而不是简单封装特定模式。
关于“实现更动态和适应性强的Agent编排”的误导
最后，OpenAI认为AgentsSDK可以实现更动态、更适应性的编排，但这本质上还是一个“WorkflowsvsAgents”的设计权衡问题。
最后，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 ://www.youtube.com/watch?v=-rsTkYgnNzM
声明：本文为AI前线整理，不代表平台观点，未经许可禁止对全文或部分内容进行转载。
直播预告
4月28日20:00，白鲸开源CEO郭炜·Kong中国区总裁戴冠兰·GMICloud中国VP蒋剑彪，三位专家深度剖析出海实战要点，欢迎扫码预约或点击下方预约卡片。
今日荐文
“DeepSeek不是万能的”，李彦宏今年押注AI应用：模型价再“打骨折”，重点布局多智能体、多模态
AI智能体老“崩”？DeepSeek前员工联手李飞飞等大佬开源新框架，教会模型真正推理
Cursor、Devin等爆款系统提示词曝光，Github上斩获近2.5万颗星！官方给AI工具“洗脑”：你是编程奇才
95后中国开发者刚刚发布“摸鱼神器”，比Manus快4倍！实测结果能否让打工人逆袭？
你也「在看」吗？👇
