开发AI Agent到底用什么框架——LangGraph VS. LlamaIndex

AI Agent开发框架到底怎么选？这可能是很多从业者最近都在纠结的问题。今天咱们就拿LangGraph和LlamaIndex这两个主流框架，做一次深度的、硬核的对比，帮你把思路彻底理清。

核心内容主要有三点：

1. LangGraph和LlamaIndex对Agent的不同抽象方式，以及背后的设计哲学。
2. 基于这两个框架搭建Multi-Agent系统的具体实现路径。
3. 在状态管理、接口易用性、并发支持这些关键维度上的直接碰撞。

如何开发AI Agent，市面上已经进化出了不同的工程体系。现在这个阶段，就像是AI时代的“战国”时代，各路豪强纷纷登场，但局面也颇为混乱。在这种“乱局”之下，AI从业者做选择，必须要比以往任何时候都更审慎。

今天咱们集中精力，把三件事聊透：

• LangGraph和LlamaIndex各自对agent的抽象是什么？这背后反映的是它们底层的设计哲学和世界观。
• 在这两个框架之上，分别如何搭建一个真正的Multi-Agent系统？
• 最后，在几个关键特性上（比如状态管理、接口易用性、对并发及流式输出的支持），来个简要的正面硬刚。

两个框架对于Agent的抽象

根据之前的讨论，业界对于agent的理解，已经初步形成了一个共识：Workflow和Autonomous Agent之间，并没有一条“非黑即白”的界限。只不过，出于以前约定俗成的语言习惯，当人们提到Workflow时，倾向于理解成那种提前定义好、每一步都按计划精准执行的流程；而提到Agent，则更容易理解为那种高度自主、能独立决策的系统。所以，有人发明了一个新词——AgenticSystem，用来统称所有具备一定自主程度的系统，这个概念既包含了Workflow，也包含了Agent，以及中间状态的各类变体。

在关于Agentic System这一统一概念的认知上，LangGraph和LlamaIndex是基本一致的。但具体到实现机制层面，两者则采取了完全不同的抽象方式。

先说LangGraph。

LangGraph是LangChain团队在LangChain之后，全新设计的一套框架和平台，代表了他们全新的思维模式。在推进Workflow和Agent的融合这件事上，LangGraph可以说是“革命到底”了。它在底层构建了一套基于“图”的编排框架，上层不管是简单的Workflow，还是复杂的Multi-Agent系统，都可以基于这个“图”来编排出来。

为什么一定要抽象成“图”？传统的Workflow，大部分情况下用一个DAG（有向无环图）就能表达。但复杂的控制流，尤其是带有自主性的Agent，必然会产成执行循环。这可不是一个DAG能搞定的。

图是由节点和边组成的。在Agentic System的构建中，节点可以执行任意逻辑，既包括精确的程序逻辑，也包括由LLM驱动的动态决策逻辑。而边则表达了节点之间的执行顺序，一种偏序关系。

底层统一成一个基于“图”的编排框架，上层创生出各种各样的Agentic System，这听起来很美好。但要实现这个目标，这个图的编排框架必须具备几个关键能力：

• 能够指定节点之间的偏序执行关系。
• 能够在节点之间传递或共享数据。
• 能够让某些节点并发执行，并在结束后同步执行结果。
• 还有最重要的一点：能够执行动态的逻辑，甚至动态地产生偏序关系，这样才能出现循环。

LlamaIndex的情况则要复杂一些。

在LlamaIndex的官方文档中，它把Agentic System严格分成了两类：一类是高度自主的系统，直接叫Agent；另一类是开发者可以精确控制和自定义的系统，叫Workflow。乍一看，LlamaIndex的“Agent”和“Workflow”似乎是两套完全不同的系统，可能是基于不同的底层架构构建的。

但LlamaIndex可能正处于演变之中，这让问题变得复杂了一些。我们来看一个具体的例子。基于ReAct模式的Agent，通常被认为是高度自主的。它在一个agent loop中循环迭代，靠LLM动态决策，自动调用合适的工具并存取记忆。作为高度自主系统的典型代表，ReActAgent在LlamaIndex中居然存在三种不同的实现：

上面第一个ReActAgent，已经标记为“legacy”（遗留）。而第三个ReActAgent，已经被放到了“workflow”的package下面。这或许说明，LlamaIndex正在逐步将它的agent实现迁移到一个统一的Workflow系统上。这听起来有点奇怪，需要解释一下。

LlamaIndex的Workflow系统，其实也是一个相当完备的编排系统。按官方文档的描述，LlamaIndex的Workflow是一个事件驱动的系统，每个Workflow由多个step组成，每个step负责处理一些事件，同时发出新的事件。通过一个具体的例子会看得更清楚：

很明显，根据上图，LlamaIndex的Workflow实际上也是一个由节点和边组成的图。图中圆角矩形的节点，对应的是step，代表某种执行逻辑；而椭圆形的绿色节点，则对应事件，指明了执行节点之间的偏序关系。由此可见，LlamaIndex所说的“Workflow”，和我们通常理解的主流概念不太一样。它本质上是一套通用的、基于图的编排框架，各种不同自主程度的Agentic System都可以基于这个Workflow框架来构建，只是官方文档的指引上显得有点误导人。

简单总结一下：

• LlamaIndex对Agentic System的抽象，可以概括为：上层把高度自主的Agent和精确控制+自定义的Workflow区分开来，但底层趋向于统一成一个事件驱动的编排系统，每个执行节点叫一个step，事件传递的方向指明了step之间的偏序关系（没有显式定义“边”的概念）。
• LangGraph对Agentic System的抽象，可以概括为：从设计之初就追求底层基于统一的编排系统，这个系统显式地定义了节点和边的概念，节点负责执行，边则指明了节点之间的偏序关系。

按照这个总结，LlamaIndex和LangGraph底层的编排系统似乎大同小异，实则不然。从概念抽象到实现细节，差异都很大。

LangGraph严格参考了谷歌的Pregel分布式图计算架构，它的整体驱动逻辑是这样的：节点之间可以发送消息，执行过程分成若干个superstep。在每个superstep内，收到消息的所有节点完成执行，执行过程中可能发出新消息，新消息直到下一个superstep才能被接收节点看到。系统就这样一个superstep一个superstep地运行，直到没有任何节点收到消息，系统停止。

在Pregel的执行模式下，有时会出现一些出人意料的执行结果，比如下面这个图：

这个图的执行顺序是：

你会发现，node_4被执行了两次。因此，这个图并不是一个简单的DAG。

如果你希望node_4等到node_2和node_3都执行完才执行（且只执行一次），那么需要显式地指明这个等待关系。

而LlamaIndex的编排系统，则是由事件驱动的。一个事件会驱动一个step执行，而step执行时可能发出新的事件，继而又驱动其他step执行。它没有显式定义“边”的概念。

如果继续追问：为什么LangGraph和LlamaIndex都可以做到用一个统一的底层编排系统来支持各种自主程度的Agentic System？这就要回到一个根本问题：不同程度的自主性，本质到底意味着什么？按照之前的讨论，本质在于系统编排的执行路径是在什么时候决策的。静态编排的执行路径是完全提前确定的，不具备太多自主性。而自主性，必然要求某种程度的动态编排特性才能支持。

再回来看LangGraph和LlamaIndex的编排系统，它们都有一个重要特性：能够在执行过程中动态地改变节点偏序关系。在LangGraph中，通过节点在superstep末尾发送动态消息实现；在LlamaIndex中，则通过每个step节点动态地发送事件实现。换句话说，它们都具有动态编排的特性。相比之下，像dify那样，在程序执行前就靠可视化编排好整个Workflow的系统，对自主系统的支持就非常有限。

当深入到这一抽象层次，LangGraph和LlamaIndex的编排系统，虽然暴露的编程接口、实现的完备程度、对概念的抽象都完全不同，但最最底层的逻辑，其实是殊途同归的。

两个框架对于multi-agent的支持方式

当用某个框架实现一个具体的multi-agent系统时，需要把上层系统的概念和底层抽象概念有效对应起来。

LangGraph支持multi-agent的方案，可以参考官方文档。简单来说，就是下面这个图：

在这个图中，节点可以表示LLM，可以表示某个Tool，可以表示任意一段程序执行逻辑，也可以表示一个完整的Agentic System子图（也就是支持嵌套子图）。

而LlamaIndex支持multi-agent的方案，可以参考官方的一个repo。这是一个使用LlamaIndex的Workflow系统来构建multi-agent的例子。虽然代码比较繁琐，但确实构建出来了。对应的可视化step执行图，我们之前已经见过：

在这个图中，调用工具、调用模型、做路由分发等逻辑，都使用一个step来实现。在具体代码层面，就是在方法上标注一个@step的装饰器。

对比两个框架的一些关键特性

（这部分涉及一些编程细节，可按需阅读）

接口易用性

LlamaIndex的Workflow，只需在方法上标注@step就能创建一个step，非常灵活易用。但对于step之间的执行偏序关系，没法直接指定，只能通过声明和匹配事件类型来隐式指定，略显不便。

而LangGraph要求开发者显式地调用add_node、add_edge来构建执行图。这些构建图的代码，对开发者的代码有一定侵入性，你需要去理解node、edge这些和你的业务逻辑无关的概念，并在代码中穿插调用它们。

另外，不管是LlamaIndex还是LangGraph，对于multi-agent的上层封装都还不够充分。

状态管理

LangGraph使用全局状态在节点之间共享数据；而LlamaIndex一方面用event在step之间传递数据，另一方面也支持通过全局状态来共享数据（以Context的形式）。这里有个潜在风险：对于复杂系统来说，全局状态通常容易引发状态管理的混乱，开发者需要自己多加小心。

另外，LangGraph对于全局状态的更新，采用了一套基于reducer的通用方案，初学者往往不容易理解。

并发

LangGraph和LlamaIndex的Workflow，都天然支持并发。因为它们都是异步驱动的，在每一个step或superstep执行期间，具备执行条件的多个节点天然就是并发执行的。

而在多个节点并发执行结束后，同步等待执行结果的操作，两者采取了完全不同的方案。

在LangGraph中，需要通过特定形式的调用来指定框架内部的waiting_edge；而在LlamaIndex的Workflow中，则需要使用Context来指明同时等待多个事件（Context同时承载了太多逻辑）。

对streaming的支持

LangGraph和LlamaIndex的Workflow，都允许通过async for的方式来深入到执行过程中去，这个能力被称为“streaming”。一些常见的功能，比如汇报执行进度，就可以通过这种方式实现。

在LangGraph中，可以通过async for逐步遍历各个superstep；而在LlamaIndex的Workflow中，则可以通过async for遍历各个事件。对streaming的支持，本质上是对执行过程按时间线性分步进行追踪的一种方式。这种在时间维度上展开的线性遍历，在LangGraph中体现为superstep，在LlamaIndex的Workflow中则体现为每一步的驱动事件。

小结

LangGraph和LlamaIndex都是比较庞大的项目，今天只是讨论了各自关于agent开发的核心逻辑部分。而关于agent开发，值得探讨的话题还有很多。

从某种程度说，底层的设计哲学和世界观，基本定义了一个框架、项目或平台的边界。业界对agent的认知，一直存在两条主线：一条是充满理想色彩的期待，希望AI能带来全方位的自我规划能力，充分释放AI的决策潜力，彻底碘伏传统软件的生产方式；另一条则是更为务实的路线，把AI当成升级改造传统Workflow的工具，让AI在可控的、有监管的规则框架内运转。

现在，随着AI向产业落地的进程不断深入，这两条路线正在以某种方式融合成一种新的东西。理想固然美好，但同时也需要坚实的解决方案来支撑。