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

Agent智能体的发展正步入黄金时代。随着新框架层出不穷，加上持续高涨的投入热情，这个领域已经逐渐摆脱了初期的混沌状态，迅速崛起为开发者眼中的“当红炸子鸡”——甚至超越了RAG，成为首选技术方向。那么问题来了：2024年，Agent智能体系统会全面接管撰写邮件、预订航班、数据分析这些日常任务吗？这当然有可能，但距离那个目标，中间还横亘着不少硬骨头要啃。

开发者们在构建Agent时，不仅要掂量用哪个大模型、选什么应用场景、搭什么样的技术架构，还得在众多开发框架之间做出抉择。是继续沿着LangGraph这条相对成熟的路走，还是拥抱新兴的LlamaIndex Workflows？或者，干脆回归传统，自己动手写所有代码？

为了帮你更轻松地做出这个决定，我们在过去几周用几个主流框架搭建了相同的智能体，并从技术角度梳理了各自的优劣势。接下来的内容，就是这次实践的核心发现。

Code-Based Agent：不依赖框架，全凭手艺

在着手开发Agent应用时，你完全可以不依赖任何框架，一切从零开始构建。整个流程大致是这样的：

这个完全由代码构建的Agent，核心是一个由OpenAI技术支撑的“技能调度器”。它通过函数调用机制来决定激活哪项技能。当技能操作完成后，控制权会重新交回调度器手中，以便它继续调度其他技能，或者直接向用户反馈。在交互过程中，Agent会不断记录用户的提问和自身的回答，并在每次技能调用时，把整段对话历史完整地传递给调度器，以此保证交互的连贯性和上下文的完整性。

LangGraph：最早出现的框架，专为循环而生

LangGraph是众多Agent框架中最早亮相的那一批，2024年1月首次发布。创建它的初衷，是为了打破传统流程和链条中那层“非循环”的天花板——通过引入Pregel图模型，利用节点、边和条件边的概念，大大简化了在智能体内部构建循环流程的步骤，让图结构的遍历变得非常直观。LangGraph建立在LangChain之上，自然沿用了LangChain的对象和类型系统。

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

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

每当“agent”节点（相当于基于代码智能体里的技能路由器）被激活后，“should_continue”这条边会决定：是把输出直接送给用户，还是传递给ToolNode去调用工具。在每个节点内部，“state”负责存储和OpenAI之间的交互消息及响应历史，这一点和基于代码的智能体在维持上下文方面的做法很相似。

LlamaIndex Workflows：后来者，主打异步操作

Workflows是Agent框架领域的新锐，今年夏天初才首次发布。和LangGraph类似，它的目标是简化循环智能体的构建流程。但Workflows特别强调了异步操作的能力——这也是它的一大特色。

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

两个框架在结构上高度相似，但Workflows多了一个专门的“初始化步骤”，用于设置智能体的环境上下文。尽管结构相近，它们所依赖的代码基础却完全不同。

下面的代码展示了Workflow的结构。与LangGraph类似，我们在这里设定了状态信息，并把各种技能和LLM对象关联起来。

我们还定义了一个附加步骤——“prepare_agent”。它负责把用户输入转换成ChatMessage格式，存入工作流的历史记忆中。把转换过程独立为一个步骤，意味着智能体在执行工作流步骤时，可以多次回到这里，避免了反复把用户信息加载到记忆存储中的重复劳动。在LangGraph的实现中，我们用了图结构之外的run_agent方法来达到同样目的。从结构上看，把这一逻辑融入Workflow和图中，整体会变得更清晰、更高效。

配置完Workflow后，路由代码和工具调用的处理代码分别如下：

三种开发框架的横向比较

把三种方法放在一起对比，各自的特点就出来了。

最直接——所有抽象层都由开发者自定义，管理类型和对象相对简单。但隐患也很明显：随着Agent复杂性增加，缺乏结构可能导致代码越来越难管理。

则提供了明确的Agent结构，有利于团队协作和规范统一。对于不熟悉结构的开发者来说，也相对容易上手。不过，它可能需要更多调试时间，如果开发者本身就不是很适应框架的思维，反而会感到有些束缚。

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

核心问题其实在于：你目前是否已经用了LlamaIndex或LangChain？LangGraph和Workflows与各自的依赖框架紧密集成，如果本身已经在用，它们带来的额外优势或许并不足以支撑你“换道”。而纯代码方案始终有它的吸引力——只要你能严格记录和执行抽象概念，就能确保外部框架永远不会成为你的瓶颈。

到底怎么选？三个问题帮你敲定

当然，光说“看情况”是不够的。下面这三个问题，或许能帮你为下一个Agent项目找到最合适的框架。

• 你的项目是否已经和LlamaIndex或LangChain深度绑定了？
  
  如果是，那这两个框架自然就是首选，没有太多犹豫的必要。

• 你对Agent的标准架构熟悉吗？还是更希望有人给你指个方向？
  
  如果你希望得到一些引导，Workflows可能是个不错的选择；如果你急需一变钱成的结构指引，LangGraph可能更适合你。

• 你手头有现成的Agent示例可以参考吗？
  
  框架的一大优势就在于提供了丰富的教程和案例供你参考。而纯代码构建的智能体，这方面资源可能就比较匮乏了。