AI Agent 开发实战：LangChain vs LlamaIndex vs CrewAI 深度对比

我见过不少团队的真实经历：Demo 阶段用某个框架三天跑通，觉得挺好；上了生产环境之后发现性能扛不住、调试困难、或者复杂流程编排根本做不到，想换的时候发现调用链全都渗透到业务代码里了。也有团队反过来，一上来就用最重的方案做内部工具，结果开发周期拖了两三个月，其实需求就是一个简单的检索增强问答。

目前社区里讨论度最高的三个框架——LangChain（含 LangGraph）、LlamaIndex 和 CrewAI——各自的设计哲学差异很大。它们不是同一件事的三个实现，而是面向不同核心问题的三套工具。理解这种差异，比记住 API 用法重要得多。

三个框架的核心设计哲学：它们到底在解决什么问题

在动手写代码之前，先搞清楚每个框架的”基因”是什么。这决定了它们在什么场景下天然顺手，在什么场景下需要你跟框架”对抗”。

LangChain / LangGraph：工具箱最全的通用编排平台

LangChain 最早是一个 LLM 应用开发工具包，提供了 Chain、Agent、Memory 等抽象层。后来团队发现，单纯的链式调用无法满足复杂 Agent 流程的需求，于是推出了 LangGraph——把 Agent 的决策过程建模为有向图，每个节点是一次状态更新（比如调用工具、思考推理），边代表状态转移条件。

这种设计的核心优势在于显式流程控制：你用代码定义决策路径，而不是完全依赖 prompt 来引导大模型自己决定下一步做什么。这意味着循环、条件分支、人工中断这些复杂模式都可以精确实现。LangGraph 还内置了 checkpoint 机制，每次节点执行后会持久化完整状态，支持时间旅行（从任意检查点恢复执行）、回溯调试和审计追踪。

到 2026 年中，LangChain 生态已经集成了上百个 LLM、向量数据库和工具，配套的 LangSmith 提供从 trace 追踪、评估到部署监控的闭环能力。可以说，如果你的目标是从 Demo 一路走到生产级 Agent，LangChain 是生态最完整的选择。

LlamaIndex：以数据检索为核心的 Agent 工作流引擎

LlamaIndex 的起点不是 Agent，而是 RAG。它最早解决的问题是：如何高效地把各种数据源（文档、数据库、API）索引化，然后让 LLM 能够精准检索和推理。后来团队在数据层的基础上逐步扩展了 Agent 能力，提供了 FunctionAgent、ReActAgent、CodeActAgent 等预置智能体，以及 AgentWorkflow 来支持多智能体协作。

这个发展路径决定了 LlamaIndex 的强项：当 Agent 的核心任务是围绕数据检索、文档问答和知识推理展开时，它的体验最顺手。索引、分块、嵌入、检索这些环节在 LlamaIndex 里是一等公民，配置灵活且深度可控。相比之下，如果用 LangChain 做 RAG，虽然也能做，但你往往需要自己拼接更多组件。

LlamaIndex 的多智能体模式有三种：AgentWorkflow（内置的线性交接模式）、Orchestrator 模式（把子 Agent 作为工具暴露给一个总控 Agent）、以及完全自定义的规划器。这种分层设计让开发者可以在”省事”和”灵活”之间做选择。

CrewAI：角色驱动的多智能体协作框架

CrewAI 走的是完全不同的路线。它的核心抽象是角色（Role）-目标（Goal）-工具（Tools），你像导演安排演员一样定义多个具备专业技能的 AI 代理——研究员负责搜索资料，写手负责起草初稿，审稿人负责质量把关——框架自动把它们串联起来完成复杂任务。

这种设计的上手成本极低，几乎不需要理解什么是图、什么是状态机。你只需要用自然语言描述每个角色的职责，CrewAI 就会处理任务分配、交接和结果汇总。到 2026 年，CrewAI 已有超过 5 万 GitHub Star，月均处理 14 亿次智能体自动化任务，被 PwC、IBM、NVIDIA 等企业采用。

2026 年 5 月 CrewAI 还推出了 Discovery 引擎，通过多信号匹配和队列分析帮助企业把 Agent 落地到生产环境。同时 CrewAI Flows 作为生产级应用结构的推荐方式，让开发者可以在 Flows 中管理状态和执行顺序，而 Agent 在 crew 内部完成具体工作。

三框架核心维度对比

光说设计哲学还不够具体，下面这张表把三个框架在关键维度上的差异拉出来做横向对比：

同一任务在三个框架里的写法差异

为了更直观地感受三个框架的风格差异，我们来看一个经典场景：构建一个”研究员→写手→审稿人”的三人协作 Agent，处理研究报告生成任务。

CrewAI 的写法：声明式角色定义

CrewAI 的代码最直观，几乎就是用自然语言描述角色和任务：

from crewai import Agent, Task, Crew

researcher = Agent(
    role="研究员",
    goal="收集指定主题的资料并整理要点",
    backstory="你是一位经验丰富的研究员，擅长从多渠道快速提取关键信息",
    tools=[search_tool],
    llm=llm
)

writer = Agent(
    role="报告撰写人",
    goal="根据研究资料撰写结构清晰的报告",
    backstory="你是一位专业写手，擅长把复杂信息组织成易读的报告",
    llm=llm
)

reviewer = Agent(
    role="审稿人",
    goal="审查报告质量并提出修改建议",
    backstory="你是一位严谨的编辑，注重逻辑性和准确性",
    llm=llm
)

research_task = Task(
    description="研究主题：{topic}，整理关键发现和趋势",
    expected_output="包含 5-8 个要点的结构化研究笔记",
    agent=researcher
)

write_task = Task(
    description="基于研究笔记撰写 800-1200 字报告",
    expected_output="结构清晰的 Markdown 报告",
    agent=writer
)

review_task = Task(
    description="审查报告并给出修改建议或确认通过",
    expected_output="审查意见和最终报告",
    agent=reviewer
)

crew = Crew(
    agents=[researcher, writer, reviewer],
    tasks=[research_task, write_task, review_task],
    process=Process.sequential
)

result = crew.kickoff(inputs={"topic": "2026 年 AI Agent 框架发展趋势"})

这段代码的直觉性很强——你定义三个角色、三个任务，框架按顺序串联执行。但问题也在这里：如果你想在第 2 步和第 3 步之间插入一个条件判断（比如”如果报告长度不足 500 字就返回重写”），在 CrewAI 里就需要切换到 Flows 模式，复杂度会上一个台阶。

LlamaIndex 的写法：Agent 交接 + 状态共享

LlamaIndex 的多智能体写法更偏工程化，通过 can_handoff_to 显式声明 Agent 之间的交接关系：

from llama_index.core.agent.workflow import AgentWorkflow, FunctionAgent

research_agent = FunctionAgent(
    name="ResearchAgent",
    description="搜索网络并记录研究笔记",
    system_prompt="你是研究员，完成后交接给 WriteAgent",
    llm=llm,
    tools=[search_web, record_notes],
    can_handoff_to=["WriteAgent"],
)

write_agent = FunctionAgent(
    name="WriteAgent",
    description="根据笔记撰写报告",
    system_prompt="你是写手，完成后交接给 ReviewAgent",
    llm=llm,
    tools=[write_report],
    can_handoff_to=["ReviewAgent", "ResearchAgent"],
)

review_agent = FunctionAgent(
    name="ReviewAgent",
    description="审查报告质量并反馈",
    system_prompt="你是审稿人，给出修改建议或确认通过",
    llm=llm,
    tools=[review_report],
    can_handoff_to=["WriteAgent"],
)

workflow = AgentWorkflow(
    agents=[research_agent, write_agent, review_agent],
    root_agent="ResearchAgent",
    initial_state={"research_notes": {}, "report_content": "", "review": ""},
)

resp = await workflow.run(user_msg="撰写 2026 年 AI Agent 框架趋势报告")

相比 CrewAI，LlamaIndex 多了 initial_state 和 can_handoff_to 的显式控制，交接关系更透明，也更容易做单元测试。代价是代码量更多一些，上手时需要理解 Workflow 和 Context 的概念。

LangGraph 的写法：图模型 + 条件路由

LangGraph 的写法最显式，你直接定义图的节点和边：

from typing import TypedDict
from langgraph.graph import StateGraph, END

class ReportState(TypedDict):
    topic: str
    research_notes: str
    report_content: str
    review_result: str

def research_node(state: ReportState) -> dict:
    notes = search_and_summarize(state["topic"])
    return {"research_notes": notes}

def write_node(state: ReportState) -> dict:
    report = generate_report(state["research_notes"])
    return {"report_content": report}

def review_node(state: ReportState) -> dict:
    feedback = review_report(state["report_content"])
    return {"review_result": feedback}

def should_revise(state: ReportState) -> str:
    if "需要修改" in state["review_result"]:
        return "write"
    return END

workflow = StateGraph(ReportState)
workflow.add_node("research", research_node)
workflow.add_node("write", write_node)
workflow.add_node("review", review_node)

workflow.set_entry_point("research")
workflow.add_edge("research", "write")
workflow.add_edge("write", "review")
workflow.add_conditional_edges("review", should_revise)

graph = workflow.compile()
result = graph.invoke({"topic": "2026 年 AI Agent 框架趋势"})

这段代码量最大，但也是最灵活的——should_revise 函数实现了”审稿不通过就回到写作环节重写”的条件循环，这在另外两个框架里都不容易直接做到。而且 LangGraph 的每个节点执行后都会自动生成 checkpoint，你可以从任意一步回溯状态。

真实项目里最容易踩的坑

坑一：CrewAI 角色边界模糊导致死循环

这是 CrewAI 用户反馈最多的问题。如果你定义了多个角色但职责边界不够清晰——比如研究员和写手的 goal 有重叠——Agent 之间就会互相踢皮球，任务在几个角色之间来回转但永远不结束，Token 成本飞速飙升。

真实场景：一个团队用 CrewAI 搭了一个内容生产流水线，5 个 Agent 的角色定义都是”根据需求完成XX任务”这种模糊表述。上线后某些复杂话题会触发 Agent 反复交接，最长的一次跑了 47 轮才超时退出。后来他们做了三件事来修复：

• 每个 Agent 只负责一件明确的事，goal 写到具体动作级别
• 设置最大轮次限制，超过 10 轮强制退出
• 给每个 Agent 的 expected_output 加格式约束，减少”模糊地带”

坑二：LangChain 抽象层太厚，调试像黑盒

LangChain 的设计哲学是”高抽象、广覆盖”，这带来了快速上手的好处，但代价是中间层太多。你在 Chain 里调用一个工具，背后可能经过 Runnable 序列化、Callback Manager、Memory 检索、Tool Router 等好几层处理。当某个环节出错时，堆栈信息可能穿越七八层 LangChain 内部代码，定位问题非常痛苦。

一个常见误区是把所有逻辑都塞进 LangChain 的抽象里，包括业务逻辑。一旦你发现某个 Chain 的行为不符合预期，想要加一行 print 看看中间状态，可能发现根本找不到合适的插入点——因为整个执行流程被 Runnable 接口封装了。

经验建议是：用 LangChain 做编排，但把核心业务逻辑放在框架之外。用接口隔离框架调用和业务逻辑，这样即使需要换框架，迁移成本也可控。

坑三：LlamaIndex 多智能体交接不稳定

LlamaIndex 的 AgentWorkflow 依赖 LLM 自己判断什么时候交接、交接给谁。在简单场景下这没问题，但当 Agent 数量超过 3-4 个时，LLM 可能会做出奇怪的交接决策——比如跳过中间步骤直接把任务交回给第一个 Agent，或者在不需要交接的时候频繁切换。

如果你发现交接行为不稳定，可以考虑切换到 Orchestrator 模式——用一个总控 Agent 来显式决定调用哪个子 Agent，而不是让子 Agent 之间自主交接。这牺牲了一些灵活性，但换来了更稳定的执行路径。

生产环境需要关注但 Demo 阶段容易忽略的问题

以下几件事在写 Demo 时几乎不会被注意到，但一旦上了生产环境就会变成核心痛点：

• 错误处理与重试：LLM API 偶尔超时或返回格式错误。每个 LLM 调用都需要超时机制和重试策略，关键路径要有降级方案。LangGraph 的 checkpoint 可以从失败点恢复，CrewAI 和 LlamaIndex 需要自己处理。
• Token 成本控制：多智能体场景下 Token 消耗可能呈指数增长。需要监控每个 Agent 的调用次数和 Token 用量，设置每日预算上限。
• 可观测性：生产环境必须能看到完整的 Agent 执行链路——哪一步调了什么工具、花了多少时间、返回了什么结果。LangSmith 在这方面最成熟，LlamaIndex 有内置的事件流追踪，CrewAI 依赖第三方或自己的 Enterprise 方案。
• 并发与限流：多个用户同时使用 Agent 时，LLM API 的并发限制会成为瓶颈。需要设计请求队列和限流策略。
• Prompt 注入防护：如果 Agent 有工具调用能力（特别是能执行代码或访问数据库），必须对用户输入做安全过滤，防止恶意 Prompt 指令劫持 Agent 行为。

选型建议：什么情况用哪个框架

经过上面的分析，我的选型建议可以浓缩为以下几条判断逻辑。这不是非黑即白的规则，而是一个优先级排序：

一个比较务实的做法是混合使用：用 LlamaIndex 做数据检索层，用 CrewAI 做多 Agent 编排，用 LangGraph 做核心流程控制。但前提是团队有能力处理多框架集成的复杂度。如果团队规模不大、经验有限，建议先选一个框架用到底，把精力放在业务逻辑和 Prompt 工程上，而不是框架集成上。

框架在演进，但核心判断逻辑不会变

到 2026 年下半年，这三个框架都在快速迭代。LangChain 在向 LangGraph 迁移、加强 LangSmith 闭环；LlamaIndex 在 AgentWorkflow 上持续投入，多智能体模式越来越成熟；CrewAI 推出了 Discovery 引擎和可视化 Agent 构建器，向企业级靠拢。框架的具体 API 会变，但选型的底层逻辑——你的核心问题是什么、团队处于什么阶段、生产化需求有多强——不会变。

与其纠结”哪个框架最好”，不如先问自己三个问题：你的 Agent 核心任务是数据处理、流程编排还是角色协作？你的团队有没有能力驾驭框架的复杂度？你打算什么时候上生产环境，生产环境对稳定性和可观测性的要求是什么？想清楚这三点，答案往往就浮出水面了。

一个容易忽略的建议：不管选哪个框架，在 Demo 阶段就把业务逻辑和框架调用做接口隔离。这样即使后期需要换框架或混合使用，迁移成本也可以控制在合理范围内。