Agent 框架对比：LangChain / LlamaIndex / AutoGen / CrewAI

《大模型知识与部署》系列 · No.28 / 35
适合人群：AI 工程师、应用架构师
阅读时间：约 28 分钟

---

写在前面

上一篇我们讲了 Tool Use——让 LLM 能「调工具」。这一篇升一级：让 LLM 自主完成多步任务——也就是 Agent。

2025-2026 业界普遍把这两年称为「Agent 元年」。原因有几个：

• Claude 4 / GPT-5 / o3 推理能力突破 → 多步规划可靠
• Tool Use 标准化（MCP） → 工具生态成熟
• Cursor / Devin / Manus 等爆款 → 验证商业价值
• Computer Use / Browser Use → 突破纯文字交互

但 Agent 应用的工程化复杂度极高。这就是 Agent 框架存在的意义——把"让 LLM 完成任务"这件事工程化。

下面这些问题你一定遇到过：

• LangChain 写起来很麻烦，但又很流行——到底要不要用？
• LangGraph、AutoGen、CrewAI、Smolagents 都是什么？怎么选？
• 多 Agent 协作真的比单 Agent 强吗？
• Agent 跑着跑着就跑飞了，怎么治？
• 想做一个生产级 Agent 服务，从哪里开始？

读完本文你将能：

1. 区分 5 大主流 Agent 框架的差异
2. 理解 Agent 的 4 大设计模式
3. 根据业务选对框架
4. 跑通一个端到端 Agent 应用
5. 避免 Agent 工程化的常见陷阱

我们开始。

---

一、Agent 是什么：从概念到工程

1.1 Agent 的精确定义

Anthropic 给的定义（很好用）：

Agent = LLM + Tools + Loop

Agent = 一个 LLM
        + 一组工具
        + 一个循环（自主决定下一步做什么）
        + 目标（停止条件）

和 Tool Use 的区别：

• Tool Use：单次调用工具（用户控制流程）
• Agent：LLM 控制流程（自主多步）

1.2 Agent 的关键特征

特征	含义
自主性	不需要每步都人工介入
目标导向	给一个目标，自己想办法
工具使用	调用各种工具完成任务
状态管理	跨多步记住上下文
错误恢复	失败了能自己重试 / 换策略

1.3 2026 年 Agent 应用版图

应用	类型
Cursor / Windsurf	AI Code 助手
Devin	全自主软件工程师
Claude Code	终端 AI Coding
Manus	通用任务 Agent
OpenAI Operator	浏览器自动化
AI 客服 Agent	客户支持
Multi-Agent 研究助手	学术研究
GitHub Copilot Workspace	项目级开发

这些应用全部需要 Agent 框架支撑。

---

二、五大 Agent 框架介绍

2.1 LangChain / LangGraph（生态最广）

LangChain 是 2022.10 出现的 LLM 应用框架，生态最丰富。但传统 LangChain 写代码繁琐，2024 推出了 LangGraph 作为 Agent 专用框架。

LangChain 特点

• 覆盖广：RAG、Agent、向量库、LLM 接入全包
• 集成多：几百个工具 / 模型 / 向量库
• 文档全：但内容多到容易迷失
• 抽象重：很多 wrapper 层

LangGraph 特点

• 基于状态图：每个节点是一个步骤，边定义流转
• 可循环：天然支持 Agent loop
• 可中断：人在循环（Human-in-the-loop）
• 持久化：状态可存可恢复

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

class AgentState(TypedDict):
    messages: Annotated[list, operator.add]

def call_model(state):
    response = llm.invoke(state["messages"])
    return {"messages": [response]}

def should_continue(state):
    last = state["messages"][-1]
    if last.tool_calls:
        return "tools"
    return END

# 构建图
workflow = StateGraph(AgentState)
workflow.add_node("agent", call_model)
workflow.add_node("tools", tool_node)
workflow.set_entry_point("agent")
workflow.add_conditional_edges("agent", should_continue)
workflow.add_edge("tools", "agent")  # 工具完了回到 agent

app = workflow.compile()
result = app.invoke({"messages": [HumanMessage("...")]})

适合：

• 需要复杂控制流（条件分支、循环、人工介入）
• 已经用 LangChain 生态
• 团队想要高度可控

不适合：

• 简单单线程 Agent（杀鸡用牛刀）
• 追求极简代码

2.2 LlamaIndex（RAG + Agent 友好）

LlamaIndex 起家于 RAG（第 26 篇用过），后来加入了 Agent 能力。

特点

• RAG 集成天然好
• Workflow 引擎：事件驱动的 Agent 设计
• Agentic RAG：Agent + RAG 一体化

from llama_index.core.workflow import Workflow, step, Event

class ResearchAgent(Workflow):
    @step
    async def plan(self, ctx, event: StartEvent) -> SearchEvent:
        # 拆解任务
        plan = await llm.acomplete(f"Plan: {event.query}")
        return SearchEvent(plan=plan)
    
    @step
    async def search(self, ctx, event: SearchEvent) -> AnalyzeEvent:
        results = await retriever.aretrieve(event.plan)
        return AnalyzeEvent(results=results)
    
    @step
    async def analyze(self, ctx, event: AnalyzeEvent) -> StopEvent:
        answer = await llm.acomplete(f"基于：{event.results} 回答")
        return StopEvent(result=answer)

agent = ResearchAgent()
result = await agent.run(query="...")

适合：

• RAG 为主的应用 + Agent 能力
• 事件驱动的工作流

不适合：

• 不需要 RAG 的纯 Agent 应用

2.3 AutoGen / Microsoft AG2（多 Agent 之王）

AutoGen 是微软 2023 推出的多 Agent 协作框架。2024 末分叉出社区版 AG2，2025 微软推出 AutoGen v0.4。

特点

• 多 Agent 对话：多个 LLM 互相聊天解决问题
• 角色化：定义不同 Agent 的角色和工具
• 可配置工作流：从两人对话到群聊

from autogen_agentchat.agents import AssistantAgent
from autogen_agentchat.teams import RoundRobinGroupChat

# 定义两个 Agent
coder = AssistantAgent(
    name="Coder",
    model_client=client,
    system_message="你是一个 Python 程序员",
)

reviewer = AssistantAgent(
    name="Reviewer",
    model_client=client,
    system_message="你是一个 Code reviewer",
)

# 创建团队
team = RoundRobinGroupChat([coder, reviewer], max_turns=10)

result = await team.run(task="写一个二分查找算法并 review")

适合：

• 任务可以被分解为不同角色
• 需要 Agent 之间互相批评 / 协作
• 科研类多步推理

不适合：

• 简单单线任务
• 对成本敏感（多 Agent 调用 API 次数翻倍）

2.4 CrewAI（声明式多 Agent）

CrewAI 是 2024 年的"明星"——比 AutoGen 更直观、声明式。

特点

• 简洁优雅：YAML / 装饰器风格
• 角色 / 任务 / 流程清晰：Agent + Task + Crew + Process
• 新手友好：上手最快

from crewai import Agent, Task, Crew, Process

# 定义 Agent
researcher = Agent(
    role="Research Analyst",
    goal="深入研究指定话题",
    backstory="你是该领域 10 年经验的专家",
    tools=[search_tool, browser_tool],
    llm=llm,
)

writer = Agent(
    role="Tech Writer",
    goal="把研究结果写成清晰的文章",
    backstory="你是技术博客作者",
    llm=llm,
)

# 定义任务
research_task = Task(
    description="研究 {topic}",
    agent=researcher,
    expected_output="一份详细研究报告",
)

write_task = Task(
    description="基于研究写一篇文章",
    agent=writer,
    expected_output="2000 字博客文章",
    context=[research_task],   # 依赖关系
)

# 组成 Crew
crew = Crew(
    agents=[researcher, writer],
    tasks=[research_task, write_task],
    process=Process.sequential,
)

result = crew.kickoff(inputs={"topic": "大模型推理优化"})

适合：

• 业务流程明确（先 A 后 B 再 C）
• 角色分工清晰
• 团队希望可读性高

不适合：

• 高度动态的任务流
• 需要复杂状态管理

2.5 Smolagents（HuggingFace 极简）

HuggingFace 在 2025 推出的极简 Agent 框架，主打"用代码而非 JSON 调工具"。

特点

• 代码即工具调用：让 LLM 直接生成 Python 代码
• 极简：< 1000 行核心代码
• HF 生态：原生集成 Transformers / Hub

from smolagents import CodeAgent, HfApiModel

agent = CodeAgent(
    tools=[search_web, calculate],
    model=HfApiModel("Qwen/Qwen3-32B-Instruct"),
)

result = agent.run("查一下上海和北京的常住人口，告诉我哪个多")

Code Agent 的特殊优势：

LLM 直接写 Python 代码：

shanghai = search_web("上海常住人口")
beijing = search_web("北京常住人口")
print(f"上海 {shanghai}, 北京 {beijing}")
print(f"差异：{shanghai - beijing}")

比传统 Function Calling 更灵活——能做循环、条件、计算。

适合：

• 数据处理 / 分析类任务
• 想用代码替代 JSON 工具调用
• HuggingFace 生态用户

不适合：

• 安全敏感（执行 LLM 生成代码有风险）
• 简单确定流程

2.6 一表速看

框架	强项	学习曲线	适合
LangGraph	控制流	陡	复杂工作流 ⭐
LlamaIndex	RAG + Agent	中	Agentic RAG
AutoGen	多 Agent	中	协作场景
CrewAI	易用	平	业务流程 ⭐
Smolagents	极简	平	数据分析

---

三、Agent 的 4 大设计模式

无论用什么框架，Agent 的"设计模式"就那几种。

3.1 ReAct（Reasoning + Acting）

第 27 篇讲过。最基础的模式：

Thought → Action → Observation → Thought → ...

适合：单线任务、迭代式探索。

3.2 Plan-and-Execute

先规划再执行：

Step 1：规划（Planner LLM）
  → 把任务拆成子任务列表
  
Step 2：执行（Executor）
  → 逐个执行子任务
  → 中间可重新规划

def plan_and_execute(task):
    plan = planner.invoke(f"拆解任务：{task}")
    # plan = ["search X", "analyze Y", "write Z"]
    
    results = {}
    for step in plan:
        result = executor.invoke(step, context=results)
        results[step] = result
        
        # 中途重规划（如果发现需要）
        if needs_replan(result):
            new_plan = planner.invoke(...)
    
    return final_aggregate(results)

适合：复杂多步任务、长程规划。

3.3 Reflection（自反思）

Agent 自我批评 + 改进：

1. Agent 生成初版结果
2. Critic（同一个 LLM 不同角色）批评
3. Agent 基于批评改进
4. 直到满足质量标准

适合：高质量输出场景（写作、代码）。

3.4 Multi-Agent Collaboration

多个 Agent 分工协作：

┌────────────┐
│ Manager    │ ── 分配任务
└─────┬──────┘
      ├──→ Researcher（查资料）
      ├──→ Coder（写代码）
      ├──→ Tester（测试）
      └──→ Writer（写报告）

经典案例：MetaGPT 的"软件公司"模拟。

适合：复杂任务可分解、各 Agent 有明确角色。

警告：多 Agent 不一定比单 Agent 好。Anthropic 2024 一份研究发现，很多场景下单 Agent + 好的 prompt 比多 Agent 更稳定且便宜。

3.5 设计模式选择

场景	推荐
简单工具调用	ReAct
长程规划	Plan-and-Execute
高质量写作 / 代码	Reflection
角色明确的流程	Multi-Agent

经验：从简单到复杂渐进——先 ReAct，发现不够再上 Plan-and-Execute。

---

四、Agent 选型决策

4.1 按业务场景

业务	推荐框架
Code Agent（写代码 / 修 bug）	LangGraph / 自研
客服 Agent	CrewAI / LangGraph
研究助手	AutoGen / LangGraph
数据分析师	Smolagents
文档 RAG Agent	LlamaIndex
浏览器自动化	自研 + Browser-use 库
业务流程自动化	CrewAI

4.2 按团队规模

团队	推荐
1-3 人	CrewAI / Smolagents（快速验证）
4-15 人	LangGraph / LlamaIndex（生产级）
大厂	自研 + 借鉴 LangGraph 思想

4.3 按业务阶段

原型期：CrewAI / Smolagents
  ↓
MVP：CrewAI / LangGraph
  ↓
生产：LangGraph（控制粒度细）
  ↓
规模化：自研 + 工程化

4.4 「不用框架」的选项

很多大厂的 Agent 应用其实不用框架——直接写循环 + Tool Use：

async def custom_agent(task):
    messages = [{"role": "user", "content": task}]
    
    for _ in range(max_iter):
        response = await llm.acomplete(messages=messages, tools=tools)
        messages.append(response.message)
        
        if not response.tool_calls:
            return response.content
        
        # 执行工具
        for tc in response.tool_calls:
            result = await execute_tool(tc)
            messages.append({"role": "tool", "content": result})
    
    return "Max iterations reached"

什么时候自研而非用框架：

• 业务流程极特殊
• 性能极其敏感
• 团队不想吃框架更新的亏
• 已经在用了，迁移代价大

---

五、生产实战：完整 Agent 系统

下面用 LangGraph 实现一个真实业务案例。

5.1 案例：技术支持 Agent

业务需求：用户提工单 → Agent 自动诊断 → 给出解决方案 / 升级到人工。

from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated, List
import operator

class TicketState(TypedDict):
    ticket: dict
    diagnosis: str
    relevant_kb: List[str]
    suggested_solution: str
    needs_human: bool
    messages: Annotated[list, operator.add]

# 节点 1：分类
async def classify_ticket(state):
    response = await llm.acomplete(
        f"对工单分类：{state['ticket']}\n类别：[bug, how-to, billing, other]"
    )
    state["category"] = parse_category(response)
    return state

# 节点 2：RAG 查文档
async def search_kb(state):
    docs = await rag.search(state["ticket"]["title"], top_k=5)
    state["relevant_kb"] = docs
    return state

# 节点 3：诊断
async def diagnose(state):
    response = await llm.acomplete(
        f"""基于工单：{state['ticket']}
        和文档：{state['relevant_kb']}
        诊断问题原因"""
    )
    state["diagnosis"] = response
    return state

# 节点 4：生成方案
async def generate_solution(state):
    response = await llm.acomplete(
        f"基于诊断：{state['diagnosis']} 给出解决方案"
    )
    state["suggested_solution"] = response
    
    # 自我评估：能否独立解决
    state["needs_human"] = needs_human_check(response)
    return state

# 节点 5：升级人工
async def escalate(state):
    await notify_engineer(state["ticket"], state["diagnosis"])
    return state

# 构建图
workflow = StateGraph(TicketState)
workflow.add_node("classify", classify_ticket)
workflow.add_node("search", search_kb)
workflow.add_node("diagnose", diagnose)
workflow.add_node("solve", generate_solution)
workflow.add_node("escalate", escalate)

workflow.set_entry_point("classify")
workflow.add_edge("classify", "search")
workflow.add_edge("search", "diagnose")
workflow.add_edge("diagnose", "solve")

workflow.add_conditional_edges(
    "solve",
    lambda s: "escalate" if s["needs_human"] else END
)
workflow.add_edge("escalate", END)

app = workflow.compile(checkpointer=memory_saver)

关键设计点：

1. 状态机清晰：每个节点单一职责
2. 条件分支：根据信心度路由到人工
3. 持久化：checkpointer 保存状态
4. 可观测：LangSmith 追踪每步

5.2 工程化实践

Human-in-the-loop

workflow = StateGraph(...)
workflow.add_node("propose_action", ...)
workflow.add_node("human_review", lambda s: s)  # 等人审批
workflow.add_edge("propose_action", "human_review")

# 编译时插入中断点
app = workflow.compile(
    interrupt_before=["human_review"],
    checkpointer=memory_saver,
)

允许中断 → 等人审批 → 继续。关键场景：发邮件、改数据库、付钱。

状态持久化

from langgraph.checkpoint.postgres import PostgresSaver

checkpointer = PostgresSaver(conn=psycopg_conn)
app = workflow.compile(checkpointer=checkpointer)

# 中断的会话能恢复
config = {"configurable": {"thread_id": "user-123"}}
result = app.invoke(input, config=config)

可观测性

import langsmith

# 自动追踪每一步
@langsmith.trace
async def agent_run(...):
    ...

# LangSmith UI 可看到完整 trace

错误处理

async def safe_node(state):
    try:
        return await actual_logic(state)
    except RetryableError:
        # 让 Agent 重试
        state["retry_count"] += 1
        if state["retry_count"] > 3:
            state["needs_human"] = True
        return state
    except FatalError as e:
        # 立即升级
        state["error"] = str(e)
        state["needs_human"] = True
        return state

5.3 性能与成本优化

优化 1：路由小模型 → 大模型

async def smart_route(state):
    # 用小模型判断复杂度
    complexity = await small_llm.classify(state["task"])
    
    if complexity == "simple":
        return await fast_model_handle(state)  # 7B 模型
    else:
        return await big_model_handle(state)   # 70B

混合后成本降 60-80%。

优化 2：缓存中间结果

@redis_cache(ttl=3600)
async def expensive_step(input):
    return await llm_heavy_compute(input)

优化 3：并行节点

# LangGraph 支持节点并行
workflow.add_node("search_kb", search_kb)
workflow.add_node("search_web", search_web)
workflow.add_node("merge", merge_results)

workflow.add_edge(START, "search_kb")
workflow.add_edge(START, "search_web")
workflow.add_edge("search_kb", "merge")
workflow.add_edge("search_web", "merge")

---

六、避坑 + 下一篇预告

6.1 Agent 6 大常见坑

坑 1：循环卡死

症状：Agent 反复调用同一工具。

对策：

• 设 max_iter
• 检测重复（相同工具相同参数 3 次 → 强制终止）
• prompt 中加"不要重复同样的调用"

坑 2：上下文爆炸

症状：多步后 context 越来越长 → OOM。

对策：

• 中间结果摘要
• 滑动窗口（只保留最近 N 步）
• 用 KV store 存中间状态，按需召回

坑 3：幻觉工具

症状：模型调用不存在的工具。

对策：

• 严格 schema 校验
• 失败时返回 “tool not found, available: […]”

坑 4：成本失控

症状：单次 Agent 任务花掉 $5。

对策：

• 设置 token / 调用次数预算
• 用小模型做路由
• 缓存常见操作

坑 5：不可观测

症状：Agent 出问题不知道哪一步坏。

对策：

• 必上 LangSmith / Langfuse / Phoenix
• 记录每步 input / output / token / 时间

坑 6：过度依赖多 Agent

症状：明明单 Agent 能解决，搞 5 个 Agent 协作。

对策：

• 从单 Agent 开始
• 验证瓶颈再加 Agent
• Anthropic 的建议：单 Agent + 好 prompt 优先

6.2 下一篇预告

• 第 29 篇：多模态部署 - VLM、语音、视频理解 —— Agent 走向多模态是下一步。我们会讲清主流多模态模型、部署难点、应用场景。
• 之后是 Prompt 工程方法论（第 30 篇），应用生态篇就完整收官。

---

结语：Agent 框架是「LLM 工程化」的当下答案

读完本文你应该明白：

• LangGraph 适合复杂控制流（生产首选）
• CrewAI 适合简洁业务流程（原型快）
• AutoGen 适合多 Agent 协作
• Smolagents 适合数据分析类
• 4 大设计模式：ReAct / Plan-Execute / Reflection / Multi-Agent
• 不一定要用框架——直接写循环也是合理选择
• 可观测 + 错误处理 + 成本控制 是生产 Agent 的三大要点

下一篇我们继续：

• 第 29 篇：多模态部署 —— 让 Agent 不只能"读写"，还能"看听"。

我们下篇见。

---

📮 关于「码海寻道」
这里是一个聚焦 AI 工程化、大模型部署、后端架构实战的技术专栏。
写最一线的踩坑经验，做最务实的技术拆解。

如果这篇文章对你有启发，欢迎点赞、转发、关注。我们下篇见。