Agent 智能体开发框架如何优雅选型？ 原创

1、Agent 智能体进入黄金发展期

Agent 智能体的发展正步入黄金时代。随着众多新框架的层出不穷和对该领域的持续投入，现在 Agent 智能体已逐步摆脱初期的动荡，迅速崛起，成为开发者的首选，超越了 RAG。那么，2024年是否会成为 Agent 智能体系统全面接管撰写邮件、预订航班、数据分析等任务的元年呢？

​

这或许有可能，但距离这一目标还有许多挑战需要克服。在构建 Agent 智能体的过程中，开发者们不仅要考虑选用哪种大模型、应用场景和技术架构，还需要在众多开发框架中做出抉择。是继续沿用较为成熟的 LangGraph，还是拥抱新兴的 LlamaIndex Workflows？或者回归传统，亲自编写所有代码？

本文旨在帮助您更轻松地做出决策。在过去几周，我们利用多个主流框架构建了相同的智能体，并从技术角度对它们的优势和不足进行了分析。

2、Code-Based Agent（不使用智能体框架）

在着手开发 Agent 智能体应用时，你可以选择不依赖任何框架，而是完全自主构建，整体流程如下所示：

以下 Agent 智能体应用完全由代码构建而成，其核心是一个由 OpenAI 技术支撑的技能调度器。该调度器通过函数调用机制来决定激活哪项技能。技能操作完成后，控制权将重新交还给技能调度器，以便于它能够继续调度其他技能或者直接对用户进行反馈。

在整个交互过程中，Agent 智能体不断记录用户的提问和自身的回答，并在每次技能调用时，将这一系列对话完整地传递给技能调度器，以此保证交互的连贯性和上下文的完整性。

3、LangGraph

LangGraph 是众多 Agent 智能体框架中最早出现的一个，它在 2024 年 1 月首次亮相。这个框架的创建目的是为了克服现有流程和链条中的非循环性挑战，通过运用 Pregel 图模型来应对这一难题。LangGraph 通过引入节点、边以及条件边的概念，简化了在智能体内部构建循环流程的步骤，使得图结构的遍历更为直观易懂。LangGraph 是建立在 LangChain 之上的，它沿用了 LangChain 的对象和类型系统。

乍一看，LangGraph 智能体与传统的基于代码的智能体似乎有共通之处，然而它们的底层实现却存在显著差异。尽管 LangGraph 也采用了“路由器”这一术语，指的是通过函数调用与 OpenAI 交互并利用其输出推动流程前进，但是它在不同技能间的切换逻辑却是独树一帜的。

在所描述的图结构中，我们定义了一个用于启动 OpenAI 调用的节点，即“agent”，以及一个用于执行工具处理步骤的节点，即“tools”。LangGraph 提供了一个名为 ToolNode 的内置对象，该对象能够接收并调用一系列工具，根据 ChatMessage 的反馈来激活这些工具，并在操作完成后返回到“agent”节点。

每当“agent”节点（在基于代码的智能体中相当于技能路由器）被激活后，should_continue 这条边将决定是将输出直接传送给用户，还是传递给 ToolNode 以进行工具调用。

在每个节点内部，“state” 负责存储与 OpenAI 之间的交互消息和响应历史，这一点与基于代码的智能体在维持上下文方面有着相似的做法。

4、LlamaIndex Workflows

Workflows 是 Agent 智能体框架领域的新加入者，它在今年夏天初首次发布。与 LangGraph 相似，其设计目标是简化循环智能体的构建流程。此外，Workflows 特别突出了其异步操作的功能。

在 Workflows 的设计中，某些概念似乎是为了直接与 LangGraph 竞争，尤其是它使用事件而不是边或条件边作为逻辑连接的手段。在 Workflows 中，智能体的逻辑被封装在“步骤”中（与 LangGraph 的“节点”相对应），而事件的触发和监听则负责在不同步骤之间传递信息。

这两个框架在结构上有着显著的相似性，但存在一个差异：为 Workflows 增加了一个专门的初始化步骤，用于设置智能体的环境上下文，这一点我将在后面详细说明。尽管它们的结构设计相近，但它们所依赖的代码基础却完全不同。

以下代码展示了 Workflow 的结构。与 LangGraph 类似，在此部分，我设定了状态信息，并将各种技能与 LLM 对象关联起来。

此外，我还定义了一个附加步骤——“prepare_agent”。这个步骤负责将用户的输入转换成 ChatMessage 格式，并将其存入工作流的历史记忆中。将这一转换过程独立为一个单独的步骤，意味着智能体在执行工作流步骤时，能够多次回到这个步骤，从而避免了重复将用户信息加载到记忆存储的必要性。

在 LangGraph 的实现中，我采用了位于图结构之外的 run_agent 方法来实现相同的目的。这种改变主要是基于个人编码风格的偏好，但我认为，将这一逻辑融合到 Workflow 和图中，会使整体结构更加清晰和高效。

在完成了 Workflow 的配置之后，我继续编写了以下路由代码：

以及工具调用的处理代码：

5、三种开发框架的比较

比较这三种方法，各有特色。

无框架方法最直接。所有抽象层由开发者自定义，管理类型和对象相对简单。但随着 Agent 智能体复杂性增加，缺乏结构可能导致难以管理。

LangGraph 提供了明确的 Agent 智能体结构，有利于团队协作和规范统一。对结构不熟悉的开发者也易于上手，但可能需要更多调试，若不适应框架则可能感到困扰。

Workflows 则介于两者之间，基于事件的架构在特定项目中有优势，对 LlamaIndex 依赖性低，给开发者更多自由。

核心问题在于是否已使用 LlamaIndex 或 LangChain。LangGraph 和 Workflows 与依赖框架紧密集成，其额外优势可能不足以成为转换的理由。

纯代码方法始终有吸引力。只要能严格记录和执行抽象概念，就能确保外部框架不会成为障碍。

6、三种开发框架如何选择？

当然，仅仅说“视具体情况而定”并不能完全满足我们的需求。以下三个问题可能有助于你为下一个智能体项目选择合适的框架。

你的项目是否已经与 LlamaIndex 或 LangChain 紧密集成？

如果是，那么这两个框架应该是你的首选。

你是否熟悉 Agent 智能体的标准架构，还是更希望得到构建 Agent 智能体结构的指导？

如果你偏向于得到指导，Workflows 可能是合适的选择。如果你非常需要指导，LangGraph 可能更合适。

你是否有现成的 Agent 智能体示例作为参考？

框架的一大优势在于提供了丰富的教程和案例供你参考，而纯代码构建的智能体可能缺乏这样的资源。

本文转载自公众号玄姐聊AGI  作者：玄姐

原文链接：​​https://mp.weixin.qq.com/s/7eYxEys84AnZRGCuOWbsfA​​