Agent 开发框架对比:LangChain、LlamaIndex、CrewAI、AutoGen 与 LangGraph

当大模型(LLM)从「会聊天的接口」走向「能干活的系统」时,开发者面临的核心问题不再是「怎么调用一次模型」,而是「怎么让模型持续地规划、调用工具、记忆上下文、并与其他智能体协作」。Agent 开发框架正是为这套编排复杂度而生的基础设施。本文逐一拆解五个主流框架的定位与取舍,并给出可落地的选型思路。

一、为什么需要 Agent 框架

直接从 HTTP 接口调用模型,在大模型应用早期足够应付「一次提问、一段回答」。但一旦进入 Agent 场景,裸调用会迅速暴露三类短板:

  • 工具调用的编排:Agent 需要根据上下文决定「下一步该调哪个工具」,并把工具返回结果喂回模型。手写这套循环(解析函数声明、执行、回填、再推理)既冗长又易错。
  • 记忆与状态:多轮对话、跨会话的长期记忆、中间步骤的持久化,都需要在模型调用之外维护状态。框架通常提供统一的记忆抽象,避免开发者自己管理字符串拼接与缓存。
  • 多步规划与反思:可靠的 Agent 往往要「先计划、再执行、遇到失败再重试」,这背后是规划器(planner)、反思器(reflector)与执行器的协同。框架把这些可复用的模式沉淀为组件。

换句话说,Agent 框架的价值在于:把「模型调用」升级为「带工具、带记忆、可循环、可观测的执行流程」,让开发者把精力放在业务编排而非底层胶水上。

二、主流框架逐一介绍

LangChain 及其 LCEL 表达式

LangChain 是覆盖面最广的 Agent 框架之一,提供模型、提示词、工具、检索、记忆等大量可组合组件,并通过社区集成连接数百种外部服务。它的核心抽象是「链(Chain)」——把若干步骤串成流水线。

为了解决早期 LLMChain 过度封装、难以调试的问题,LangChain 推出了 LCEL(LangChain Expression Language,表达式语言)。LCEL 用管道符 | 把组件声明式地组合,并原生支持流式输出、并行与异步:

# 用 LCEL 声明一条「提示词 -> 模型 -> 字符串解析」的链
chain = prompt | model | StrOutputParser()

LCEL 的直观收益是「写起来像一条数据管道,调试时能逐段观察中间结果」。当链路变复杂、需要循环或人工介入时,官方通常建议迁移到更可控的 LangGraph。

LlamaIndex:RAG 导向

LlamaIndex 的起点是检索增强生成(RAG),即把外部文档索引进来,让模型基于「检索到的真实内容」作答。它在数据接入(数十种数据源与文件格式)、索引(向量、树、摘要、关键词等)、检索策略上积累了极深的能力,适合「让模型读得懂你的私有资料」这类场景。

随着 RAG 走向「Agentic RAG」,LlamaIndex 也提供了 Agent 与 Workflow 能力,但其重心始终是「以数据/检索为核心」的问答与知识工作流,而非通用的多智能体协作。

CrewAI:多智能体角色协作

CrewAI 的设计隐喻是「团队(Crew)」:你把任务拆给若干扮演不同角色的 Agent(如研究员、作家、审稿人),每个 Agent 有独立的角色设定、目标与可调用工具;框架按流程(Flow)把它们编排成协作流水线。

它的卖点在于「角色分工 + 流程化编排」足够贴近真实团队工作,且既支持代码优先,也提供可视化构建与治理(运行时追踪、成本审计、人工审批闸门)。适合「把一个大任务分解成多个专家角色并行或串行完成」的运营型场景。

Microsoft AutoGen:对话式多 Agent

AutoGen 由微软提出,核心范式是「多智能体对话(Multi-Agent Conversation)」:多个可对话的 Agent 通过互相发消息来协作完成任务,消息既可以是自然语言,也可以是代码(例如一个 Agent 生成代码、另一个 Agent 负责执行并返回结果)。

其奠基性论文 AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent Conversation(arXiv:2308.08155)明确指出,AutoGen 是一个开源框架,允许开发者通过「彼此对话以完成任务」的多个 Agent 来构建 LLM 应用;这些 Agent 可定制、可对话,并能组合 LLM、人类输入与工具运行于不同模式。

当前 AutoGen 的架构分层为 Studio(可视化原型)、AgentChat(对话式单/多 Agent 编程框架)、Core(事件驱动的底层运行时)与 Extensions(对接外部服务的扩展),对「认真构建多智能体系统」的场景尤为合适。

LangGraph:基于状态图的可控编排

LangGraph 由 LangChain 团队推出,定位是「低层级、可持久化、有状态」的编排运行时。它把 Agent 流程建模成一张有向图:节点是处理逻辑,边是状态转移(含条件分支);框架负责持久化执行、流式输出、人工介入(human-in-the-loop)与记忆。

它的核心优势是「把确定性手写步骤与 LLM 驱动的智能步骤混在同一张图里」——需要可靠、可审计的地方用确定性节点,需要灵活决策的地方用模型节点,从而获得对行为的细粒度控制。适合长时运行、状态复杂、对可控性与可调试性要求高的生产级 Agent。

三、对比维度

下面从五个关键维度横向比较,便于按需求取舍:

维度LangChain / LCELLlamaIndexCrewAIAutoGenLangGraph
抽象层级中高,组件丰富中,偏数据/RAG中,角色即抽象中低,对话驱动低,状态图原语
可控性 / 可调试性中(LCEL 改善)中(流程可视化)中(对话流清晰)高(图与状态可观测)
学习曲线中(概念多)平缓(RAG 心智模型)平缓(团队隐喻)中(分层架构)较陡(需理解图模型)
生态成熟度高,集成最广高(RAG 领域深)成长快,企业向高(论文+微软)高(LangChain 系)
适用场景通用 Agent / 快速搭建知识问答 / RAG角色协作流程多 Agent 对话协作可控生产级编排

简要解读:

  • 抽象层级越高,写第一版越快,但「黑盒」越厚、越难精确干预内部行为。
  • 可控性越高,越容易做确定性约束与逐步调试,但上手成本通常更高。
  • 生态成熟度直接影响「接数据库、接向量库、接各种模型」的省心程度。

四、选型建议

没有「最好」的框架,只有「最贴合当前阶段与场景」的框架。可参考以下经验:

  • 想要快速验证一个想法、调用几个工具跑通原型:优先 LangChain(LCEL),用社区集成省去大量胶水代码。
  • 任务本质是「让模型读懂你的文档 / 私有知识库」:优先 LlamaIndex,把精力放在索引与检索质量上。
  • 任务可拆成「多个专家角色分工完成」(如调研-写作-审校):优先 CrewAI,用角色与流程直接映射团队工作。
  • 想要多个 Agent 通过相互对话来协作解题(含代码生成与执行闭环):优先 AutoGen,沿对话范式组织多智能体。
  • 进入生产、要求长时运行、可持久化、可人工介入、行为可精确约束:优先 LangGraph,用状态图把确定性逻辑与智能步骤显式分开。

实际项目常常「组合使用」:例如用 LlamaIndex 做检索、用 LangGraph 做编排、用 LangSmith 做观测,框架之间并非互斥。

五、最小可运行示例

下面是一段最小可运行的 LangChain LCEL 片段,演示如何把「提示词模板、模型、输出解析器」用管道符串成一条链。运行前需安装 langchain-openai 并配置 OPENAI_API_KEY

# 最小可运行的 LangChain LCEL 链:把模型与提示词用管道符串起来
from langchain_openai import ChatOpenAI
from langchain_core.prompts import ChatPromptTemplate
from langchain_core.output_parsers import StrOutputParser

prompt = ChatPromptTemplate.from_template("用一句话解释 {concept}。")
model = ChatOpenAI(model="gpt-4o-mini")
chain = prompt | model | StrOutputParser()

print(chain.invoke({"concept": "Agent 框架"}))

这段代码虽小,却体现了 LCEL 的核心思想:组件声明式组合、可流式、可替换。把它替换为带工具调用或检索的节点,就能逐步演化成完整 Agent。

小结

  • Agent 框架解决的是编排复杂度:工具调用、记忆状态、多步规划与可观测性,而非「能否调用模型」。
  • LangChain / LCEL 胜在组件全、上手快;LlamaIndex 胜在 RAG 与数据接入;CrewAI 胜在角色化协作;AutoGen 胜在对话式多 Agent;LangGraph 胜在可控、可持久化的状态图编排。
  • 抽象层级与可控性通常此消彼长:越高层越省心,越底层越精确。
  • 选型先看场景与阶段:原型用 LangChain,知识问答用 LlamaIndex,角色分工用 CrewAI,对话协作用 AutoGen,生产可控用 LangGraph。
  • 框架可组合:检索、编排、观测常常跨框架搭配,不必二选一。

参考与延伸阅读

本文累计阅读