程序员必看｜10 大流行 Agent 框架深度分析（万字），手把手教你落地

关注

原创最新推荐文章于 2026-10-26 19:11:26 发布 1k 阅读 AI 写同款· GEO 优化 ›

全网最深度｜万字拆解 Coding Agent 的架构演进与 o3 推理革命本文深度解析了Coding Agent从代码补全到自主规划的演进历程，以及OpenAI o3推理革命带来的模型能力范式转移。文章详细探讨了Coding Agent的四个发展阶段，o3模型在链式思维和推理即服务方面的突破，以及轻量级Agent框架的崛起。通过实际案例和数据，展示了AI编程如何重塑软件开发流程和组织形态，显著提升开发效率和代码质量。阅读详情

本文深入探讨Agent框架本质，指出构建可靠系统的核心是确保大模型获得适当上下文。分析Agent与工作流的区别，强调生产系统常为两者混合。批评多数框架仅提供抽象而非真正编排能力，LangGraph同时提供声明式和命令式API。无论何种Agent系统，都能从记忆、人机协作、调试等功能中受益。建议根据用例选择适当方案，而非盲目追求Agent化。

1、什么是 Agent

Agent 并无统一定义，不同视角下有不同解读。 OpenAI 采用更高层次、更具思想领导力的方式来定义 Agent：

Agent 是能独立代表你完成任务的技术系统。

我个人并不认同这种定义。这种模糊表述无助于真正理解 Agent 本质，只是思想领导力的空谈，毫无实践价值。

对比 Anthropic 的定义：

"Agent"有多种定义方式。有些客户将其视为能长期自主运行、使用多种工具完成复杂任务的完全自治系统；另一些则指遵循预定义流程的规范性实现。在 Anthropic，我们将这些变体统称为Agent 系统，但在架构上区分工作流和Agent：

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

Agent则是大模型动态自主控制流程和工具使用的系统，自主决定任务完成方式。

我更认同 Anthropic 的定义，原因如下：

他们的定义更精确且技术导向
提出了"Agent 系统"概念，并将工作流和 Agent 都归入其中——这一点我非常欣赏

实际生产环境中，几乎所有的Agent 系统都是工作流和Agent的混合体。

在后文中，Anthropic 将 Agent 定义为"…本质上只是大模型在循环中基于环境反馈使用工具的系统"。

在这里插入图片描述

尽管 OpenAI 最初给出了宏大的定义，但实际所指与 Anthropic 基本一致。

这类 Agent 的参数包括：

使用的大模型
系统提示词
可用工具

工作原理是循环调用大模型：当它决定调用工具时，执行该工具并获取观察结果/反馈，再传回大模型。循环持续直到大模型决定不再调用工具（或触发了停止条件）。

OpenAI 和 Anthropic 都将工作流视为与 Agent 不同的设计模式——在前者中，大模型的控制权更小，流程更确定。这种区分很有价值！

两家公司都明确指出：并非所有场景都需要 Agent。在许多情况下，工作流更简单、可靠、经济、快速且高效。Anthropic 文章中有段精彩论述：

构建大模型应用时，我们建议先寻找最简单的解决方案，仅在必要时增加复杂度。有时这意味着完全不构建 Agent 系统。Agent 系统通常以延迟和成本为代价换取更好的任务性能，需要谨慎权衡。当确实需要更高复杂度时，工作流能为明确定义的任务提供可预测性，而 Agent 更适合需要灵活性和模型驱动决策的场景。

OpenAI 也有类似表述：

在决定构建 Agent 前，请明确验证你的用例是否符合这些标准。否则，确定性解决方案可能就已足够。

实践中，大多数Agent 系统都是工作流和 Agent 的组合。这正是我反感讨论"某物是否是 Agent"，而更倾向于讨论"系统的 Agent 化程度"的原因。感谢 Andrew Ng 提出的这种思考方式[5]：

与其二元化地判断某物是否是 Agent，不如将系统视为具有不同程度的 Agent 特性。"Agent 化"这个形容词让我们能够涵盖所有这些系统，纳入这场不断发展的运动。

2、构建 Agent 的难点何在？

多数人会认同构建 Agent 具有挑战性。更准确地说——构建一个 Agent 原型很容易，但要打造能支撑关键业务应用的可靠系统？这非常困难。

真正的难点在于可靠性。在 Twitter 上展示一个光鲜的 demo 很容易，但要让其支撑关键业务？不经过大量工作根本无法实现。

几个月前我们对 Agent 构建者进行了调研，问题是："将更多 Agent 投入生产的最大障碍是什么？“压倒性的首要答案是"性能质量”——要让这些 Agent 可靠工作仍然非常困难。

在这里插入图片描述

什么导致 Agent 有时表现不佳？大模型出错。

为什么大模型会出错？两个原因：(a) 模型能力不足，(b) 传入模型的上下文错误或不完整。

根据我们的经验，后者更常见。具体诱因包括：

不完整或过于简略的系统消息
模糊的用户输入
缺乏恰当的工具
工具描述质量差
未传入正确的上下文
工具响应格式不当

构建可靠 Agent 系统的核心难点在于确保大模型在每一步都能获得适当的上下文。这既包括严格控制输入大模型的内容，也包括运行必要的步骤来生成相关内容。

在讨论 Agent 框架时，请牢记这一点。任何让控制大模型输入内容变得更困难的框架，都是在帮倒忙。确保正确上下文传入大模型本就足够困难——何必自找麻烦？

3、什么是 LangGraph

LangGraph 最准确的定位是编排框架（同时提供声明式和命令式 API），并在其上构建了一系列 Agent 抽象。

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

声明式的基于图的语法[6]
Agent 抽象[7]（构建在底层框架之上）

LangGraph 还支持函数式 API[8]和底层事件驱动 API[9]，提供Python[10]和TypeScript[11]版本。

Agent 系统可以表示为节点[12]和边[13]。节点代表工作单元，边代表转移关系。节点和边本质上就是普通的 Python/TypeScript 代码——虽然图结构是声明式表达的，但图内部的逻辑仍是常规的命令式代码。边可以是固定[14]或条件[15]的。因此，虽然图结构是声明式的，但图的遍历路径可以完全动态。

LangGraph 内置持久化层[16]，支持容错[17]、短期记忆[18]和长期记忆[19]。

该持久化层还支持"人在回路[20]"和"人在环上[21]"模式，如中断、审批、恢复和时间旅行。

LangGraph 内置支持流式传输[22]：包括 token 流、节点更新流和任意事件流。

LangGraph 与LangSmith[23]无缝集成，提供调试、评估和可观测性支持。

4、Agent 框架的类型

Agent 框架在多个维度上存在差异。理解——而非混淆——这些维度，是正确比较框架的关键。

工作流 vs Agent

大多数框架包含高级 Agent 抽象，部分框架还包含常见工作流抽象。LangGraph 则是用于构建 Agent 系统的底层编排框架，支持工作流、Agent 及介于两者之间的所有形态[24]。我们认为这至关重要——如前所述，生产环境中的 Agent 系统大多是工作流和 Agent 的组合。生产级框架必须同时支持两者。

请记住构建可靠 Agent 的难点：确保大模型获得正确的上下文。工作流的价值之一就在于它能简化上下文传递过程——你可以精确控制数据流向。

在设计系统时，需要在"工作流"到"Agent"的频谱上定位，需考虑两个因素：

可预测性 vs 自主性
低门槛 vs 高上限

可预测性 vs 自主性

系统越趋向 Agent，可预测性就越低。

有时出于用户信任、监管要求等原因，你需要系统保持可预测性。

可靠性虽不完全等同于可预测性，但实践中二者密切相关。

在频谱上的理想位置取决于具体应用。LangGraph 可用于构建频谱上任意位置的系统，让你自由调整。

在这里插入图片描述

高门槛 vs 低上限

评估框架时可参考其门槛和上限：

低门槛：框架易上手，适合初学者
高门槛：需要专业知识才能有效使用
低上限：能力有限（很快会触达天花板）
高上限：支持高级用例，扩展性强（能伴随需求成长）

工作流框架提供高上限，但门槛也高——需要自行实现大量 Agent 逻辑。

Agent 框架门槛低但上限也低——容易入门，但难以应对复杂场景。

LangGraph 旨在兼具低门槛（通过内置 Agent 抽象[25]降低入门难度）和高上限（通过底层功能[26]支持高级用例）。

声明式 vs 非声明式

声明式框架有其优势，也有不足。这是程序员间永无止境的争论，各有所好。当人们说"非声明式"时，通常暗指"命令式"作为替代。多数人会认为 LangGraph 是声明式框架，但这只对了一半。

首先——虽然节点和边的连接方式是声明式的，但节点和边本身只是普通的 Python/TypeScript 函数。因此 LangGraph 实际融合了声明式和命令式。

其次——我们实际上支持声明式 API 之外的其他接口，特别是函数式[27]和事件驱动 API[28]。虽然我们认为声明式 API 是有用的心智模型，但也理解它并非适合所有人。

关于 LangGraph 的常见误解是将其比作 Tensorflow（声明式深度学习框架），而将 Agents SDK 比作 Pytorch（命令式框架）。

这是完全错误的。Agents SDK（以及原始 LangChain、CrewAI 等）既非声明式也非命令式——它们只是抽象层。它们提供 Agent 抽象（Python 类），内含运行 Agent 的逻辑。这些并非真正的编排框架，仅仅是抽象层。

Agent 抽象

大多数 Agent 框架都包含 Agent 抽象。通常始于一个包含提示词、模型和工具的类，然后不断添加参数…最终你会面对一个控制多种行为的冗长参数列表，全部隐藏在类抽象之后。要了解运行机制或修改逻辑，必须深入源代码。

这些抽象最终会让你难以理解或控制在每一步传入大模型的具体内容。这一点至关重要——正如前文所述，保持这种控制力是构建可靠 Agent 的关键。这正是 Agent 抽象的危险之处。

我们有过惨痛教训。这正是原始 LangChain 链和 Agent 的问题所在——它们的抽象反而成了障碍。两年前的一个原始抽象就是接收模型、提示词和工具的 Agent 类。这不是新概念，当时就无法提供足够控制力，现在依然如此。

明确地说，Agent 抽象确实有其价值——能降低入门门槛。但我认为这些抽象还不足以（或许永远不足以）构建可靠的 Agent。

我们认为最佳方式是将这些抽象视为类似 Keras 的存在——提供高级抽象来简化入门。但关键是确保它们构建在底层框架之上，避免过早触及天花板。

这正是我们在 LangGraph 之上构建 Agent 抽象的原因。这既提供了简单的 Agent 入门方式，又能在需要时轻松切换到底层 LangGraph。

多 Agent 系统

Agent 系统往往不只有一个 Agent，而是包含多个。OpenAI 在报告中指出：

对于复杂工作流，将提示词和工具分配给多个 Agent 可以提高性能和扩展性。当你的 Agent 无法遵循复杂指令或持续选择错误工具时，可能需要进一步拆分系统并引入更多独立 Agent。

多 Agent 系统的关键在于通信机制。再次强调，构建 Agent 的难点在于为大模型提供正确上下文。Agent 间的通信方式至关重要。

实现方式多种多样！交接(handoffs)是一种方式——这是 Agents SDK 中我相当欣赏的一个 Agent 抽象。

但有时最佳通信方式可能是工作流。想象 Anthropic 博文中所有工作流图表，将其中的大模型调用替换为 Agent。这种工作流与 Agent 的混合往往能提供最佳可靠性。

在这里插入图片描述

重申一下，Agent 系统不仅是工作流或仅是 Agent，它们可以是（也经常是）两者的组合。正如 Anthropic 在博文中所说：

组合与定制这些模式
这些构建模块并非铁律，而是开发者可以根据不同用例调整组合的常见模式。

5、常见问题

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

框架的价值是什么？

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

Agent 抽象

框架的通用价值在于提供有用的抽象，既降低入门门槛，又为工程师提供统一的构建方式，简化项目维护。但如前所述，Agent 抽象也有明显缺陷。对大多数 Agent 框架而言，这是它们提供的唯一价值。我们努力确保 LangGraph 不限于此。

短期记忆

当前大多数 Agent 应用都涉及多轮（如聊天）交互。LangGraph 提供[支持多轮会话(threads)的生产级存储](https://langchain-ai.github.io/langgraph/concepts/memory/?ref=blog.langchain.dev#short-term-memory “支持多轮会话(threads “支持多轮会话(threads)的生产级存储”)的生产级存储”)。

长期记忆

虽然尚处早期，但我非常看好 Agent 系统从经验中学习的能力（如跨对话记忆）。LangGraph 提供跨会话长期记忆的生产级存储[29]。

人机协作

许多 Agent 系统通过引入「人机协作」获得提升，例如获取用户反馈、审批工具调用或编辑工具参数。LangGraph 提供在生产系统中实现这些工作流的内置支持[30]。

事后回溯

除了允许用户实时影响 Agent，让用户在事后检查 Agent 运行轨迹，甚至回到早期步骤修改后重新执行也非常有用。我们称之为「时间旅行」，LangGraph 提供对此的内置支持[31]。

流式传输

大多数 Agent 应用运行耗时较长，因此向终端用户提供实时更新对用户体验至关重要。LangGraph 内置支持token 流、图步骤流和任意事件流[32]。

调试/可观测性

构建可靠 Agent 的难点在于确保传入大模型的上下文正确。能够检查 Agent 的具体执行步骤及每一步的精确输入/输出至关重要。LangGraph 与LangSmith[33]无缝集成，提供顶尖的调试和可观测性支持。（注：AI 可观测性与传统软件可观测性不同，这值得另文探讨）

容错性

容错是构建分布式应用的传统框架（如 Temporal）的关键特性。LangGraph 通过持久化工作流[34]和可配置重试[35]简化容错实现。

优化

相比手动调整提示词，有时定义评估数据集并自动优化 Agent 更高效。LangGraph 目前未原生支持此功能——我们认为时机尚早。但提及此维度是因为它值得关注，我们也在持续观察。dspy是目前这方面最优秀的框架。

所有这些价值主张（除 Agent 抽象外）对 Agent、工作流及其中间形态都有同等价值。

那么——你真的需要 Agent 框架吗？

如果你的应用不需要全部这些功能，或者你希望自行实现，那么可能不需要。其中部分功能（如短期记忆）实现并不复杂，但其他（如人在环上或大模型专属可观测性）则复杂得多。

关于 Agent 抽象，我完全同意 Anthropic 文中的观点：

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

随着模型进步，所有系统都会变成 Agent 而非工作流吗？

支持 Agent（相对工作流）的常见论点是：虽然当前效果不佳，但未来会改善，因此你只需要简单的工具调用型 Agent。

我认为以下几点可能同时成立：

这类工具调用型 Agent 的性能会提升
控制大模型输入内容仍然至关重要（垃圾进，垃圾出）
对某些应用，这种工具调用循环就足够
对其他应用，工作流仍会更简单、经济、快速和优秀
对大多数应用，生产级 Agent 系统将是工作流和 Agent 的组合

我不认为 OpenAI 或 Anthropic 会反对这些观点。Anthropic 文中说：

构建大模型应用时，我们建议先寻找最简单的解决方案，仅在必要时增加复杂度。有时这意味着完全不构建 Agent 系统。

OpenAI 文中也说：

在决定构建 Agent 前，请明确验证你的用例是否符合这些标准。否则，确定性解决方案可能就已足够。

是否存在简单工具调用循环就足够的场景？我认为只有当使用针对特定用例进行充分训练/微调/强化学习的大模型时才会成立。这有两种实现路径：

你的任务具有独特性。你收集大量数据并训练/微调/强化学习自己的模型。
你的任务具有普遍性。大型模型实验室正在训练/微调/强化学习与你的任务相似的数据。

（旁注：如果我正在某个垂直领域创业，而我的任务并不独特，我会非常担忧公司的长期生存能力）

你的任务具有独特性

我打赌大多数用例（当然包括大多数企业用例）属于此类。AirBnb 的客户支持方式与 Klarna 不同，与 Rakuten 也不同。这些任务存在大量细微差别。Sierra——客户支持领域的领先 Agent 公司——并非在构建单一的客户支持 Agent，而是客户支持 Agent 平台：

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

他们需要这样做，因为每家公司的客户支持体验都独特到通用 Agent 无法满足性能要求。

一个使用针对特定任务训练模型的简单工具调用型 Agent 案例是：OpenAI 的 Deep Research[36]。这说明确实可行，并能产出卓越的 Agent。

如果你能为特定任务训练顶尖模型——那么确实，你可能不需要支持任意工作流的框架，简单工具调用循环就足够。此时 Agent 会比工作流更受青睐。

我心中非常开放的问题是：有多少 Agent 公司会拥有为其任务训练顶尖模型所需的数据、工具或知识？目前我认为只有大型模型实验室能做到。但这会改变吗？小型垂直创业公司能否为其任务训练顶尖模型？我对这个问题非常感兴趣。如果你正在做这件事——请联系我！

你的任务具有普遍性

我认为某些任务足够通用，大型模型实验室能提供适用于简单工具调用循环的模型。

OpenAI 通过 API 发布了他们的计算机使用模型，这是针对通用计算机使用数据微调的模型，旨在胜任该通用任务。（旁注：我认为它目前远未达标）

编程是个有趣的例子。编码相对通用，绝对是当前 Agent 的突破性用例。Claude 代码和 OpenAI 的 Codex CLI 就是使用简单工具调用循环的编程 Agent 案例。我敢打赌基础模型训练使用了大量编码数据和任务（Anthropic 的这篇文档[37]就是证据）。

有趣的是——随着通用模型在这些数据上训练，数据的具体形态有多重要？Ben Hylak 日前发了条引发共鸣的推文[38]：

模型不再会使用 Cursor 了。它们全被优化为终端使用。这就是为什么 3.7 和 o3 在 Cursor 中表现极差，而在外部却惊人的原因。

这可能说明两点：

你的任务必须与通用模型训练的任务高度相似。相似度越低，通用模型适合你用例的可能性越小。
通用模型在其他特定任务上的训练可能会降低对你任务的性能。我相信用于训练新模型的数据中，与 Cursor 用例相似的数据量只多不少。但如果涌入的形态略有不同的新数据占优，就会压制其他类型数据。这意味着当前通用模型很难在大量任务上都表现出色。

即使对于 Agent 明显优于任何工作流方案的应用，你仍会受益于框架提供的与底层工作流控制无关的功能：短期记忆存储、长期记忆存储、人在回路、人在环上、流式传输、容错性和调试/可观测性。

OpenAI 的观点有哪些谬误？

重新审视 OpenAI 的立场，我们发现其基于错误的二分法，混淆了"Agent 框架"的不同维度，从而夸大其单一抽象的价值。具体而言，它将"声明式 vs 命令式"与"Agent 抽象"以及"工作流 vsAgent"混为一谈。

根本上，它误解了构建生产级 Agent 系统的主要挑战，以及框架应提供的核心价值：可靠的编排层，让开发者能精确控制传入大模型的上下文，同时无缝处理持久化、容错和人机协作等生产环境问题。

让我们分析我反对的具体部分：

在这里插入图片描述

“声明式 vs 非声明式”

LangGraph 并非完全声明式——但这并非我的主要异议。关键在于"非声明式"这个表述含糊且有误导性。通常当人们批评声明式框架时，他们会偏好更命令式的框架。但 Agents SDK 并非命令式框架，它只是个抽象层。更恰当的标题应是"声明式 vs 命令式"或"你需要编排框架吗"或"为什么 Agent 抽象就足够"或"工作流 vsAgent"（取决于他们想论证什么，下文似乎两者都想论证）。

“随着工作流变得更动态复杂，这种方法会迅速变得繁琐困难”

这与声明式或非声明式无关，完全关乎工作流 vsAgent。你可以轻松将 Agents SDK 的 Agent 逻辑表示为声明式图，且该图与 Agents SDK 同样动态灵活。

关于工作流 vsAgent 的观点：许多工作流并不需要这种程度的动态性和复杂性。OpenAI 和 Anthropic 都承认这点。能用工作流时就该用工作流。大多数 Agent 系统都是两者的组合。是的，如果工作流确实非常动态复杂，那就用 Agent。但不要在所有场景都用 Agent。OpenAI 在文章前段其实也这么说。

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

再次强调——Agents SDK 不是命令式框架，而是抽象层。它也有领域专用语言（即它的抽象）。我认为在当前阶段，学习和适应 Agents SDK 的抽象比学习 LangGraph 抽象更糟糕。因为构建可靠 Agent 的难点在于确保 Agent 获得正确上下文，而 Agents SDK 在这方面比 LangGraph 模糊得多。

“更灵活”

这完全不属实。事实恰恰相反。Agents SDK 能做的，LangGraph 都能做。而 LangGraph 能做的，Agents SDK 只能实现 10%。

“代码优先”

使用 Agents SDK 你需要编写他们的抽象，而使用 LangGraph 你编写的是大量常规代码。我不明白 Agents SDK 如何更"代码优先"。

“使用熟悉的编程结构”

使用 Agents SDK 你必须学习整套新抽象，而使用 LangGraph 你编写的是大量常规代码。还有什么比这更熟悉？

“支持更动态适应的 Agent 编排”

再次说明——这与声明式或非声明式无关，完全关乎工作流 vs Agent。见上文论述。

Agent 框架比较

我们已经讨论了 Agent 框架的多个组件：

它们是灵活的编排层，还是仅提供 Agent 抽象？
如果是灵活的编排层，它们是声明式还是其他形式？
除了 Agent 抽象，框架还提供哪些功能？

尝试将这些维度整理成表格会很有趣。当前表格包含与 Agents SDK、Google 的 ADK、LangChain、Crew AI、LlamaIndex、Agno AI、Mastra、Pydantic AI、AutoGen、Temporal、SmolAgents、DSPy 的比较。后台回复「Agent 框架」，获取 Agent 框架详细比较表格。

如果觉得内容不错，欢迎点个关注，分享和在看～，点击阅读原文获得更好阅读体验。