文章摘要
从架构到实战,全面对比主流 Agent 框架的优劣与适用场景,含 2026 年 5 月最新格局更新
1Agent 框架生态概览:为什么需要框架?
大语言模型本身只提供"文本补全"能力,要构建一个能自主完成任务的智能体,需要围绕 LLM 搭建完整的系统:状态管理、工具调用、记忆、多步规划、错误处理、多 Agent 协作。手写这些基础设施极其耗时,因此 Agent 框架应运而生。
2024 到 2026 年,Agent 框架经历了爆发式增长。主流框架可以分为三大流派:LangChain 生态派(LangChain + LangGraph)强调"从链到图"的渐进升级;多 Agent 协作派(CrewAI、AutoGen)专注于让多个智能体协同工作;以及轻量极简派(如 SmolAgent、LlamaIndex Agent)追求最小抽象、最大控制力。
选择框架时需要考虑:你的任务是线性流程还是复杂图结构?需要几个 Agent?对调试可观测性的要求有多高?社区支持和文档质量如何?本文将从架构原理、代码风格、扩展能力和生产成熟度四个维度,深入对比 LangGraph、CrewAI 和 AutoGen 三大框架。
在深入对比之前,先明确一个关键判断:没有完美的框架,只有适合的场景。LangGraph 的精确控制流在需要确定性流程的场景中无可替代,但这也意味着你必须花更多时间定义图和状态。CrewAI 的声明式 API 让开发速度极快,但在需要细粒度控制的场景中会显得不够灵活。AutoGen 的对话驱动模式在探索性任务中表现突出,但在生产环境中的不可预测性可能成为风险。
另一个常被忽视的维度是 社区成熟度。LangGraph 依托 LangChain 生态,拥有最丰富的文档、教程和社区讨论。CrewAI 虽然较新,但凭借极简的 API 设计快速积累了大量用户。AutoGen 有微软的背书,但 API 频繁变动导致社区代码碎片化严重。选择一个框架,不仅是选择技术栈,更是选择一个生态系统和社区。
框架的文档质量也是选型时不可忽视的因素。LangGraph 的文档结构清晰,每个概念都有独立页面和代码示例。CrewAI 的文档相对简略,但社区教程丰富。AutoGen 的文档由于版本碎片化问题,部分内容已经过时。OpenAI Agents SDK 和 Anthropic Agent SDK 作为新产品,文档还在快速完善中。
最后,不要忽视框架的退出策略。 如果你选择了某个框架,两年后发现它不再维护,迁移成本有多高?LangGraph 和 CrewAI 的架构相对模块化,迁移难度较低。AutoGen 的对话驱动范式迁移难度较高。官方 SDK 的迁移成本最高——因为它们与特定模型的 API 深度耦合。框架的版本管理策略也是选型时的参考因素。 LangGraph 遵循语义化版本规范,主版本升级通常伴随着 Breaking Changes 的明确文档。CrewAI 的版本更新频率较高但兼容性较好。AutoGen 的 0.x 版本历史中 Breaking Changes 较多,这是社区对其稳定性评价较低的主要原因。官方 SDK 作为新产品,版本管理规范尚未建立,但模型厂商通常会在 SDK 中保持向后兼容。
# Agent 框架的核心抽象层
from abc import ABC, abstractmethod
from typing import Any, Dict, List
class BaseAgent(ABC):
"""所有 Agent 框架的共同抽象"""
@abstractmethod
def execute(self, task: str, context: Dict = None) -> Any:
pass
class BaseTool(ABC):
"""工具接口的统一抽象"""
@property
@abstractmethod
def name(self) -> str:
pass
@abstractmethod
def run(self, *args, kwargs) -> Any:
pass
class AgentFramework(ABC):
"""框架级别的统一抽象"""
@abstractmethod
def create_agent(self, role: str, tools: List[BaseTool]) -> BaseAgent:
pass
@abstractmethod
def create_workflow(self, agents: List[BaseAgent], flow: str) -> Any:
pass# 各框架的设计哲学对比(伪代码)
# LangGraph 风格:图 = 节点 + 边
class LangGraphStyle:
def build(self):
graph = StateGraph(MyState)
graph.add_node("research", research_node)
graph.add_node("write", write_node)
graph.add_edge("research", "write") # 明确的控制流
graph.add_conditional_edges("write", should_continue)
return graph.compile()
# CrewAI 风格:角色 + 任务 + 流程
class CrewAIStyle:
def build(self):
crew = Crew(
agents=[researcher, writer],
tasks=[research_task, write_task],
process=Process.sequential # 或 Process.hierarchical
)
return crew.kickoff()
# AutoGen 风格:对话驱动
class AutoGenStyle:
def build(self):
groupchat = GroupChat(agents=[user_proxy, assistant, critic], messages=[])
manager = GroupChatManager(groupchat=groupchat, llm_config=llm_config)
user_proxy.initiate_chat(manager, message="帮我写一份报告")| 框架 | 维护方 | 核心范式 | 语言支持 | GitHub Stars |
|---|---|---|---|---|
LangGraph | LangChain | 有向图状态机 | Python/JS | 10K+ |
CrewAI | CrewAI Inc. | 角色驱动协作 | Python | 20K+ |
AutoGen | Microsoft | 多 Agent 对话 | Python/.NET | 30K+ |
OpenAI Agents SDK | OpenAI | Handoff 协议 | Python | 新开源 |
Anthropic Agent SDK | Anthropic | MCP 原生 | Python | 新发布 |
Mastra | 社区 | TypeScript Agent | TypeScript | 5K+ |
2LangGraph:图结构状态机的精妙设计
LangGraph 是 LangChain 团队推出的图结构 Agent 框架,它解决了 LangChain 最大的痛点:线性链无法表达复杂控制流。LangGraph 的核心思想是将 Agent 的执行过程建模为一个有向图,每个节点代表一个计算步骤(可以是 LLM 调用、工具执行、或者自定义逻辑),每条边代表状态流转。
与传统的 DAG 不同,LangGraph 支持循环,这使得 Agent 可以"反思-重试"。状态(State)是 LangGraph 的关键抽象——它定义了图中传递的数据结构,所有节点共享同一份状态,通过 TypedDict 管理。这种设计让调试和可观测性变得极其简单:你可以随时查看状态的快照。
LangGraph 还内置了 Checkpoint 机制,支持持久化和恢复。这对于生产环境至关重要——Agent 执行到一半崩溃了,可以从最后一个检查点恢复,而不是从头再来。
LangGraph 的设计还隐藏了一个重要的哲学:状态是 Agent 系统的单一真相来源。所有节点通过读写同一份状态来协作,这意味着你可以随时暂停 Agent 执行、查看当前状态、修改状态、然后继续执行。这种可中断、可检查、可恢复的特性在生产环境中极其宝贵——当 Agent 执行到一半遇到异常(如网络超时、API 限流),你可以从检查点恢复,而不是丢失所有中间结果。
值得注意的是,LangGraph 在 2026 年推出了 LangGraph Platform,将 LangGraph 从纯代码框架升级为包含部署、监控、调试的完整平台。这意味着 LangGraph 正在从开发工具向生产平台转型,直接对标 LangSmith 的可观测性和部署能力。
from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated
import operator
class AgentState(TypedDict):
messages: Annotated[list, operator.add]
current_step: str
retry_count: int
def research_node(state: AgentState) -> AgentState:
print("执行研究节点...")
return {"messages": ["研究完成"], "current_step": "writing"}
def writing_node(state: AgentState) -> AgentState:
print("执行写作节点...")
return {"messages": ["写作完成"], "current_step": "review"}
def should_retry(state: AgentState) -> str:
if state["retry_count"] < 3:
return "rewrite"
return END
# 构建图
graph = StateGraph(AgentState)
graph.add_node("research", research_node)
graph.add_node("write", writing_node)
graph.add_node("rewrite", writing_node)
graph.set_entry_point("research")
graph.add_edge("research", "write")
graph.add_conditional_edges("write", should_retry, {
"rewrite": "rewrite",
END: END,
})
app = graph.compile()
result = app.invoke({
"messages": [], "current_step": "start", "retry_count": 0
})# LangGraph 的检查点持久化
from langgraph.checkpoint.memory import MemorySaver
from langgraph.graph import StateGraph
class ArticleState(TypedDict):
topic: str
outline: list
draft: str
feedback: str
def generate_outline(state: ArticleState) -> ArticleState:
return {"outline": ["引言", "主体", "结论"]}
def generate_draft(state: ArticleState) -> ArticleState:
return {"draft": "这是草稿内容..."}
def review_draft(state: ArticleState) -> str:
if "好" in state.get("feedback", ""):
return "accept"
return "revise"
graph = StateGraph(ArticleState)
graph.add_node("outline", generate_outline)
graph.add_node("draft", generate_draft)
graph.set_entry_point("outline")
graph.add_edge("outline", "draft")
graph.add_edge("draft", END)
# 添加检查点保存器
checkpointer = MemorySaver()
app = graph.compile(checkpointer=checkpointer)
# 执行并自动保存状态
config = {"configurable": {"thread_id": "article-001"}}
result = app.invoke({"topic": "LangGraph教程", "outline": [], "draft": "", "feedback": ""}, config)
# 从检查点恢复
snapshot = app.get_state(config)
print(f"当前节点: {snapshot.next}")| 特性 | LangGraph | 说明 |
|---|---|---|
控制流 | 有向图(支持循环) | 比线性链更灵活 |
状态管理 | TypedDict + 共享状态 | 类型安全,调试友好 |
持久化 | Checkpoint 机制 | 支持 MemorySaver/SQLite/Postgres |
可观测性 | 内置 stream_events | 实时流式输出每个节点的状态 |
学习曲线 | 中等 | 需要理解图结构概念 |
⚠️ 常见踩坑
LangGraph 的状态是共享的,多个节点同时修改同一字段可能引发竞态条件。务必使用 Annotated 和 operator 来安全合并状态,避免直接覆盖。
3CrewAI:角色驱动的多 Agent 协作
CrewAI 的设计哲学与 LangGraph 截然不同。它不关注"流程怎么编排",而是关注"谁来做什么"。在 CrewAI 中,你首先定义角色(Agent),每个角色有明确的职责、背景和目标;然后定义任务(Task),将任务分配给合适的角色;最后选择流程(Process)来驱动执行。
CrewAI 支持两种流程模式:Sequential(顺序执行)——任务按照定义的顺序依次执行,前一个任务的输出作为后一个任务的上下文;Hierarchical(层级执行)——由一个 Manager Agent 负责任务分配和协调,Worker Agents 执行具体任务,Manager 会审查结果并决定是否需要返工。
这种"角色扮演"的隐喻让 CrewAI 的学习曲线非常低。你不需要理解图结构或状态机,只需要思考"这个任务需要什么样的专家来完成"。对于内容创作、研究分析、市场调研等场景,CrewAI 的 API 设计显得格外自然。
CrewAI 的另一个重要特性是工具集成生态系统。crewai_tools 提供了丰富的内置工具——搜索引擎、网页爬取、文件读写、数据库查询、代码执行等。这些工具通过统一的接口集成到 Agent 中,让 Agent 可以在执行任务时自主调用外部资源。工具的选择和使用策略直接决定了 Agent 的能力边界——一个配备了搜索工具的研究员 Agent 和一个没有搜索工具的 Agent,产出的质量差距可能是数量级的。
CrewAI 在 2026 年的一个重要更新是并行任务执行——在 Sequential 模式下,不相互依赖的任务可以并行执行,显著提升了吞吐效率。这对于内容创作等场景特别有用——研究员和研究分析师可以同时工作,而不是串行等待。
from crewai import Agent, Task, Crew, Process
from crewai_tools import SerperDevTool
# 定义角色
researcher = Agent(
role="高级研究分析师",
goal="深入调查 {topic} 的最新趋势和数据",
backstory="你是一位拥有 10 年经验的研究分析师,擅长从海量信息中提取关键洞察",
tools=[SerperDevTool()],
verbose=True,
allow_delegation=False,
)
writer = Agent(
role="科技内容作家",
goal="根据研究结果撰写高质量的 {topic} 分析报告",
backstory="你是顶尖科技媒体的资深编辑,擅长将复杂的技术概念转化为通俗易懂的文章",
tools=[],
verbose=True,
)
editor = Agent(
role="内容编辑",
goal="审查和润色报告,确保质量和一致性",
backstory="你是拥有 15 年经验的主编,对内容质量有着极高的标准",
tools=[],
verbose=True,
)
# 定义任务
research_task = Task(
description="研究 {topic} 的最新发展、市场规模、主要参与者",
expected_output="包含关键发现的结构化研究报告",
agent=researcher,
)
write_task = Task(
description="基于研究报告撰写 2000 字的深度分析文章",
expected_output="完整的分析报告,包含引言、分析和建议",
agent=writer,
)
edit_task = Task(
description="审查文章的事实准确性、逻辑性和可读性",
expected_output="润色后的最终版本",
agent=editor,
)
# 组建 Crew 并执行
crew = Crew(
agents=[researcher, writer, editor],
tasks=[research_task, write_task, edit_task],
process=Process.sequential,
verbose=2,
)
result = crew.kickoff(inputs={"topic": "AI Agent 框架"})# CrewAI 的层级流程(Hierarchical Process)
from crewai import Agent, Task, Crew, Process
# 定义 Manager Agent(自动创建,也可以手动指定)
manager = Agent(
role="项目经理",
goal="协调整个项目流程,分配任务给团队成员",
backstory="你是一位经验丰富的项目经理,擅长统筹规划和质量控制",
allow_delegation=True,
)
analyst = Agent(
role="数据分析师",
goal="分析数据并生成洞察",
backstory="你精通数据分析和可视化",
)
developer = Agent(
role="开发工程师",
goal="根据分析结果构建原型",
backstory="你是全栈开发工程师,擅长快速原型开发",
)
# 使用层级流程
crew = Crew(
agents=[manager, analyst, developer],
tasks=[
Task(description="分析用户数据集", expected_output="分析报告", agent=analyst),
Task(description="构建数据可视化原型", expected_output="可运行的原型", agent=developer),
],
process=Process.hierarchical,
manager_llm=manager, # 指定 Manager 使用的 LLM
verbose=True,
)
# 层级模式下,Manager 会:
# 1. 接收项目目标
# 2. 将任务分配给合适的 Agent
# 3. 审查结果
# 4. 决定是否需要返工或进入下一阶段
result = crew.kickoff()| 特性 | CrewAI | 说明 |
|---|---|---|
核心抽象 | Agent + Task + Crew | 角色驱动的声明式 API |
流程模式 | Sequential / Hierarchical | 顺序执行或 Manager 协调 |
工具集成 | crewai_tools | 丰富的内置工具集 |
回调系统 | 支持 | 可以在任务开始/完成时触发回调 |
记忆 | 短期记忆(上下文传递) | 任务间自动传递上下文 |
4AutoGen:微软的多 Agent 对话框架
AutoGen 由 Microsoft Research 团队开发,是三大框架中"学术味"最浓的一个。它的核心设计哲学是:Agent 之间的协作应该像人类团队一样——通过对话。在 AutoGen 中,每个 Agent 都是一个独立的对话参与者,它们可以一对一聊天,也可以组成群聊(GroupChat),由 Manager 协调。
AutoGen 最突出的特性是 Human-in-the-loop 支持。你可以轻松创建一个"用户代理",让它暂停执行、等待人类输入、然后根据人类反馈继续。这在需要人工审批、代码审查、或者交互式探索的场景中极其有用。
AutoGen 2.0 进行了重大重构,引入了更清晰的应用层(Application Layer)抽象。但需要注意的是,AutoGen 的 API 在 0.2 到 0.4 版本之间发生了剧烈变化,社区代码存在大量版本碎片化问题。新版本采用了更模块化的设计,但学习成本也相应增加。
AutoGen 的多 Agent 对话模式是其最具争议也最具创新的设计。在 GroupChat 中,多个 Agent 自由发言,由 Manager 决定谁在什么时候说话。这种模式的灵活性极高,但也带来了不可预测性——同样的输入可能产生完全不同的对话路径和结果。对于需要可复现性的生产环境,speaker_selection_method 参数的选择至关重要:auto 模式让 LLM 决定谁说话,round_robin 模式强制轮流发言,manual 模式由开发者完全控制。
AutoGen 2.0 的重大重构引入了应用层(Application Layer)抽象,将框架从底层对话管理解耦到更高层的任务驱动编程。这使得 AutoGen 2.0 的 API 与 0.x 版本完全不兼容,但也为长期发展奠定了更清晰的基础。对于新项目,建议直接使用 0.4+ 版本,避免陷入旧版本 API 的维护陷阱。
import autogen
# 配置 LLM
config_list = [
{"model": "gpt-4", "api_key": "sk-xxx"},
{"model": "qwen-plus", "api_key": "sk-xxx", "base_url": "https://dashscope.aliyuncs.com/compatible-mode/v1"},
]
llm_config = {"config_list": config_list, "temperature": 0.7}
# 创建 Agent
user_proxy = autogen.UserProxyAgent(
name="User",
human_input_mode="TERMINATE", # 需要人工确认才终止
max_consecutive_auto_reply=5,
code_execution_config={"work_dir": "coding", "use_docker": False},
)
coder = autogen.AssistantAgent(
name="Coder",
llm_config=llm_config,
system_message="你是一位资深 Python 工程师,擅长编写高质量代码。",
)
reviewer = autogen.AssistantAgent(
name="Reviewer",
llm_config=llm_config,
system_message="你是代码审查专家。检查代码的正确性、可读性和最佳实践。指出问题但不直接修改代码。",
)
# 创建群聊
groupchat = autogen.GroupChat(
agents=[user_proxy, coder, reviewer],
messages=[],
max_round=15,
speaker_selection_method="auto", # auto / round_robin / manual
)
manager = autogen.GroupChatManager(
groupchat=groupchat,
llm_config=llm_config,
)
# 启动对话
user_proxy.initiate_chat(
manager,
message="请用 Python 实现一个快速排序算法,包含类型注解和单元测试。",
)# AutoGen 2.0 新 API 风格(应用层抽象)
# 注意:需要安装 autogen-agentchat >= 0.4.0
from autogen_agentchat.agents import AssistantAgent
from autogen_agentchat.conditions import MaxMessageTermination
from autogen_agentchat.teams import RoundRobinGroupChat
from autogen_agentchat.ui import Console
from autogen_ext.models.openai import OpenAIChatCompletionClient
# 创建模型客户端
model_client = OpenAIChatCompletionClient(model="gpt-4")
# 创建 Agent
planner = AssistantAgent(
name="Planner",
model_client=model_client,
system_message="你是项目规划师,负责任务分解和优先级排序。",
)
executor = AssistantAgent(
name="Executor",
model_client=model_client,
system_message="你是执行者,负责编写和运行代码。",
)
evaluator = AssistantAgent(
name="Evaluator",
model_client=model_client,
system_message="你是评估者,负责审查结果并给出反馈。",
)
# 使用 RoundRobin 团队(轮流发言)
team = RoundRobinGroupChat(
[planner, executor, evaluator],
termination_condition=MaxMessageTermination(max_messages=20),
)
# 运行
async def run_team():
stream = team.run_stream(task="构建一个数据分析 Pipeline")
async for message in stream:
print(message)| 特性 | AutoGen | 说明 |
|---|---|---|
通信模式 | 对话驱动 | Agent 之间通过消息交互 |
人类参与 | Human-in-the-loop 原生支持 | 可暂停等待人工输入 |
代码执行 | 内置沙盒 | 支持 Docker 隔离执行 |
群聊管理 | GroupChat + Manager | 自动或手动选择发言者 |
API 稳定性 | 0.2→0.4 重大变化 | 版本碎片化严重 |
💡 一句话理解
AutoGen 的 code_execution_config 默认在本地运行代码,生产环境务必启用 Docker 沙盒隔离,防止恶意代码执行。
5架构对比:控制流、通信与状态管理
三大框架在架构设计上代表了三种不同的哲学。LangGraph 是"流程优先"——你定义图和状态,框架负责执行;CrewAI 是"角色优先"——你定义角色和任务,框架负责编排;AutoGen 是"对话优先"——你定义参与者和规则,框架负责调度对话。
在控制流方面,LangGraph 提供最精确的控制——你可以精确到每条边的条件和每个节点的实现。CrewAI 提供高层抽象——Sequential 和 Hierarchical 两种模式覆盖了 80% 的场景。AutoGen 最为灵活但也最不可预测——对话驱动意味着执行路径是动态生成的,难以提前预知。
通信模式上,LangGraph 通过共享状态实现节点间通信(隐式、结构化);CrewAI 通过任务上下文传递(显式、线性);AutoGen 通过消息传递(显式、异步、多对多)。状态管理方面,LangGraph 的 TypedDict 方案类型最安全,CrewAI 的上下文传递最直观,AutoGen 的消息历史最灵活。
三种架构的调试体验差异显著。LangGraph 的调试最为直接——因为状态是结构化的(TypedDict),你可以在任何时间点打印状态快照,看到每个字段的值如何变化。CrewAI 的调试依赖于任务输出的日志,虽然不如 LangGraph 精确,但对于大多数场景已经足够。AutoGen 的调试最为复杂——消息历史中可能包含数十轮对话,从中找出某个决策的具体原因需要仔细追踪消息流。
# 同一个任务:多步数据处理,三种框架的架构差异
# === LangGraph: 显式图结构 ===
from langgraph.graph import StateGraph
class DataState(TypedDict):
raw_data: str
cleaned_data: str
analysis: str
report: str
graph = StateGraph(DataState)
graph.add_node("fetch", fetch_node)
graph.add_node("clean", clean_node)
graph.add_node("analyze", analyze_node)
graph.add_node("report", report_node)
graph.add_edge("fetch", "clean")
graph.add_edge("clean", "analyze")
graph.add_edge("analyze", "report")
graph.set_entry_point("fetch")
app = graph.compile()
# 执行路径完全确定:fetch -> clean -> analyze -> report
# === CrewAI: 角色驱动 ===
from crewai import Agent, Task, Crew, Process
fetcher = Agent(role="数据获取专家", goal="获取原始数据")
cleaner = Agent(role="数据清洗专家", goal="清洗和标准化数据")
analyst = Agent(role="数据分析专家", goal="执行统计分析")
reporter = Agent(role="报告撰写人", goal="撰写分析报告")
crew = Crew(
agents=[fetcher, cleaner, analyst, reporter],
tasks=[
Task(description="获取数据", agent=fetcher),
Task(description="清洗数据", agent=cleaner),
Task(description="分析数据", agent=analyst),
Task(description="撰写报告", agent=reporter),
],
process=Process.sequential,
)
# 执行路径由任务顺序决定,但每个 Agent 自主决定如何完成
# === AutoGen: 对话驱动 ===
import autogen
# Agent 自主对话决定谁做什么、怎么做
# 没有预定义的流程图
groupchat = autogen.GroupChat(
agents=[user_proxy, data_engineer, analyst, reviewer],
messages=[], max_round=20,
)
# 执行路径完全动态,取决于对话内容# 三种框架的状态/上下文管理对比
# LangGraph: 全局共享状态(TypedDict)
class LGState(TypedDict):
messages: list
results: dict
step_count: int
# 所有节点读写同一份状态,支持 Annotated 合并
# CrewAI: 任务上下文链式传递
# Task N 的输出 → Task N+1 的上下文
# 每个 Agent 有自己的"记忆"(对话历史)
# 通过 context 参数显式指定依赖
task2 = Task(
description="分析数据",
context=[task1], # 依赖 task1 的输出
agent=analyst,
)
# AutoGen: 消息历史
# 每个 Agent 维护自己的消息列表
# GroupChat 维护全局消息列表
# 新消息自动广播给所有参与者
# 通过 system_message 控制 Agent 行为
# 通过 function_map 注册可调用工具| 维度 | LangGraph | CrewAI | AutoGen |
|---|---|---|---|
控制流 | 显式有向图 | 声明式流程 | 动态对话 |
可预测性 | 高(图结构确定) | 中(流程确定但执行自主) | 低(完全动态) |
调试难度 | 低(可追踪状态流) | 中(任务输出可追踪) | 高(对话路径不固定) |
状态管理 | TypedDict 共享 | 任务上下文传递 | 消息历史 |
循环/分支 | 原生支持 | 需自定义逻辑 | 通过对话规则实现 |
人在回路 | 需手动实现 | 需自定义 | 原生支持 |
⚠️ 常见踩坑
不要在一个项目中混用多个 Agent 框架——不同框架的状态管理和错误处理机制不兼容,会导致调试噩梦。选择一种框架并深入使用。
6性能与扩展性对比
性能是生产环境选型的关键因素。这里我们从三个维度分析:LLM 调用效率(token 消耗和延迟)、水平扩展能力(并发处理和分布式执行)、以及生态扩展性(工具集成、插件系统和社区支持)。
在 LLM 调用效率方面,LangGraph 通常最节省——因为控制流是确定的,不会产生多余的 Agent 对话轮次。CrewAI 居中——Sequential 模式效率接近 LangGraph,但 Hierarchical 模式因为 Manager 的额外调度调用,token 消耗增加约 30%。AutoGen 通常消耗最高——对话驱动的执行方式可能产生大量中间对话消息,特别是群聊模式下。
扩展性方面,LangGraph 支持多节点部署和分布式执行(通过 LangGraph Platform),CrewAI 通过并行任务执行提升吞吐,AutoGen 支持多进程 Agent 但配置复杂。
缓存策略是降低 Agent 成本的重要手段。对于重复性的工具调用(如查询同一个数据库记录、获取同一份文件),缓存结果可以避免不必要的 LLM 调用。LangGraph 的 Checkpoint 机制天然支持中间状态的持久化和复用。CrewAI 可以通过自定义回调实现缓存。AutoGen 的消息历史本身就是一种隐式缓存——Agent 会参考之前的对话结果。
# 性能对比:同一任务的 LLM 调用次数估算
# 场景:研究 + 写作 + 审查,3 步流程
# 假设每步需要 1 次 LLM 调用(不含重试)
benchmark = {
"LangGraph": {
"llm_calls": 3, # 每节点 1 次调用
"token_estimate": "约 8K", # 精确控制,无多余调用
"avg_latency": "~5s", # 顺序执行,无额外开销
"parallel_support": True, # 支持并行节点
},
"CrewAI_Sequential": {
"llm_calls": 3, # 每任务 1 次调用
"token_estimate": "约 9K", # 上下文传递增加少量 token
"avg_latency": "~6s",
"parallel_support": False, # Sequential 不支持并行
},
"CrewAI_Hierarchical": {
"llm_calls": 5, # 3 任务 + 2 次 Manager 调度
"token_estimate": "约 14K", # Manager 额外调用
"avg_latency": "~9s",
"parallel_support": True, # Manager 可并行分配
},
"AutoGen_GroupChat": {
"llm_calls": "8-15", # 动态对话,难以预估
"token_estimate": "约 20K+", # 群聊对话消耗大
"avg_latency": "~12s+",
"parallel_support": False, # 群聊本质是串行
},
}# LangGraph 的并行节点执行
from langgraph.graph import StateGraph
from typing import TypedDict
import asyncio
class ParallelState(TypedDict):
query: str
web_results: str
db_results: str
final_report: str
async def web_search(state: ParallelState) -> dict:
# 模拟网络搜索(可与其他节点并行)
await asyncio.sleep(2)
return {"web_results": "网络搜索结果..."}
async def db_query(state: ParallelState) -> dict:
# 模拟数据库查询(与 web_search 并行)
await asyncio.sleep(1.5)
return {"db_results": "数据库查询结果..."}
def combine(state: ParallelState) -> dict:
return {"final_report": f"Web: {state['web_results']}
DB: {state['db_results']}"}
graph = StateGraph(ParallelState)
graph.add_node("search", web_search)
graph.add_node("query", db_query)
graph.add_node("combine", combine)
graph.set_entry_point("search")
# 并行边:search 和 query 同时执行
graph.add_edge("search", "combine")
graph.add_edge("query", "combine")
graph.add_edge("combine", "__end__")
app = graph.compile()
# search 和 query 会被异步并行执行| 指标 | LangGraph | CrewAI | AutoGen |
|---|---|---|---|
LLM 调用次数(3步流程) | 3 次(确定性) | 3-5 次 | 8-15 次(动态) |
Token 消耗 | 低 | 中 | 高 |
并行执行 | 支持(并行边) | 部分(Hierarchical) | 不支持 |
分布式部署 | LangGraph Platform | 需自定义 | 多进程支持 |
流式输出 | stream_events | 支持 | 支持 |
成本可控性 | 高(流程确定) | 中 | 低(动态对话) |
💡 一句话理解
生产环境的成本优化技巧:① 用便宜的模型(如 GPT-4o-mini)做路由和简单判断,用贵的模型(GPT-4)做核心推理;② 缓存重复的工具调用结果;③ 设置合理的 max_round 防止无限对话。
7实战选型指南:场景匹配与代码示例
理论对比终究要落到实践。本节通过四个典型场景,展示如何选择合适的框架并快速落地。
场景一:内容创作 Pipeline(研究→写作→编辑)。这是 CrewAI 的甜蜜点。角色定义天然契合内容生产流程,每个角色有明确的专业背景和输出标准。
场景二:复杂的代码生成和调试流程。AutoGen 的人机协作能力在这里发挥最大价值——Agent 编写代码、自动执行测试、人类审查关键决策、循环迭代直到通过。
场景三:数据处理和分析流水线。LangGraph 的精确控制流最适合这类确定性强的任务。数据处理的每个步骤(提取→清洗→转换→加载→验证)都是明确的节点,状态传递清晰可追踪。
场景四:智能客服系统。需要结合框架外的工程能力(消息队列、会话管理、知识库),LangGraph 的流式输出和状态持久化能力最适合生产级部署。
# 场景一:内容创作 Pipeline(CrewAI 最佳实践)
from crewai import Agent, Task, Crew, Process
# 角色定义——越具体越好
researcher = Agent(
role="科技趋势研究员",
goal="发现并分析 {topic} 领域的最新技术趋势",
backstory="你在顶级科技媒体工作 8 年,对行业趋势有敏锐的洞察力",
tools=[SerperDevTool()],
)
writer = Agent(
role="深度报道撰稿人",
goal="撰写引人入胜的 {topic} 深度报道",
backstory="你擅长用故事化的方式讲述技术,让复杂的概念变得通俗易懂",
)
crew = Crew(
agents=[researcher, writer],
tasks=[
Task(
description="研究 {topic} 的 3 个最新趋势,每个趋势包含:技术原理、市场影响、代表公司",
expected_output="结构化的趋势研究报告,每个趋势 200 字",
agent=researcher,
),
Task(
description="基于研究报告撰写一篇面向技术管理者的深度文章",
expected_output="1500 字的深度报道,包含具体案例和行动建议",
agent=writer,
context=[research_task],
),
],
process=Process.sequential,
)
result = crew.kickoff(inputs={"topic": "AI Agent 框架"})# 场景三:数据处理流水线(LangGraph 最佳实践)
from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated
import operator
class DataPipelineState(TypedDict):
raw_data: str
cleaned_data: dict
transformed_data: dict
validation_result: str
errors: Annotated[list, operator.add]
def extract_node(state: DataPipelineState) -> DataPipelineState:
"""数据提取节点:从原始数据源获取"""
raw = state["raw_data"]
# 实际场景:读取数据库/API/文件
return {"raw_data": raw, "errors": []}
def clean_node(state: DataPipelineState) -> DataPipelineState:
"""数据清洗节点:去重、缺失值处理、类型转换"""
cleaned = {"records": 1000, "removed_duplicates": 23, "filled_missing": 15}
return {"cleaned_data": cleaned}
def validate_node(state: DataPipelineState) -> str:
"""验证节点:检查数据质量"""
quality_score = 0.95
if quality_score > 0.9:
return "approved"
return "rejected"
def transform_node(state: DataPipelineState) -> DataPipelineState:
"""数据转换节点:特征工程、聚合"""
return {"transformed_data": {"features": 50, "aggregations": 12}}
graph = StateGraph(DataPipelineState)
graph.add_node("extract", extract_node)
graph.add_node("clean", clean_node)
graph.add_node("validate", validate_node)
graph.add_node("transform", transform_node)
graph.set_entry_point("extract")
graph.add_edge("extract", "clean")
graph.add_edge("clean", "validate")
graph.add_conditional_edges("validate", validate_node, {
"approved": "transform",
"rejected": END,
})
graph.add_edge("transform", END)
app = graph.compile()| 场景 | 推荐框架 | 理由 | 备选方案 |
|---|---|---|---|
内容创作/研究 | CrewAI | 角色定义自然,API 优雅 | AutoGen(需要人机协作时) |
代码生成/调试 | AutoGen | 人在回路,代码执行沙盒 | LangGraph(流程固定时) |
数据处理流水线 | LangGraph | 精确控制流,类型安全 | 自定义脚本(简单场景) |
智能客服 | LangGraph | 流式输出,状态持久化 | OpenAI Assistants API |
多 Agent 研究 | AutoGen | 群聊对话,灵活交互 | CrewAI(简单协作) |
快速原型 | CrewAI | 学习曲线最低,5 分钟上手 | LangChain Chains |
💡 一句话理解
⚠️ 常见踩坑
框架只是工具,不要为了用框架而用框架。简单的任务用简单的方案——如果 50 行 Python 脚本就能解决问题,不需要引入任何 Agent 框架。框架的价值在于管理复杂度,而不要在不需要复杂度的地方制造复杂度。
82026 年 5 月最新格局:新玩家入局与选型建议更新
2026 年 5 月,Agent 框架领域发生了重大变化。OpenAI 和 Anthropic 分别发布了官方 Agent SDK,标志着模型厂商从"提供 API"向"提供完整 Agent 开发框架"的战略转变。
OpenAI Agents SDK引入了 Handoff 协议——一种轻量级的 Agent 间任务移交机制。它的核心优势是与 OpenAI 模型生态深度集成:Function Calling、Guardrails、Structured Outputs 全部原生支持。但代价是强绑定 OpenAI 模型,切换模型供应商的成本较高。
Anthropic Agent SDK的最大卖点是 MCP 原生——Agent 可以直接通过 MCP 协议连接外部工具和数据源,无需额外的适配代码。考虑到 MCP 已被捐赠给 Linux Foundation 并成为行业开放标准,Anthropic Agent SDK 的长期兼容性优势明显。Anthropic 在企业采纳率上以 34.4% 领先 OpenAI 的 32.1%(2026 年 5 月数据),这也为其 Agent SDK 的市场推广提供了有力背书。
2026 年选型决策树需要更新:如果你已经在使用 OpenAI 生态(GPT-5.5 API + ChatGPT Enterprise),Agents SDK 是最顺滑的选择;如果你重视工具集成的标准化和跨模型兼容性,Anthropic Agent SDK + MCP 是更长期的方案;如果你需要框架无关的灵活性,LangGraph 仍然是最佳选择。
一个值得关注的趋势是:模型厂商正在"垂直整合" Agent 开发栈——从底层模型到中间层框架到上层应用,全部由同一家公司提供。这对开发者而言意味着更低的集成成本,但也带来了供应商锁定的风险。AI Master 建议:在享受官方 SDK 便利的同时,保留一个框架无关的降级方案。
| 维度 | OpenAI Agents SDK | Anthropic Agent SDK | LangGraph |
|---|---|---|---|
模型绑定 | 强绑定 OpenAI | 优先 Claude,支持多模型 | 完全框架无关 |
工具集成 | Function Calling 原生 | MCP 原生 | 手动配置工具 |
供应商锁定风险 | 高 | 中 | 低 |
企业采纳率 | 32.1% | 34.4% | 框架不统计 |
适用场景 | OpenAI 生态深度集成 | MCP 标准化连接 | 灵活定制/跨模型 |
成熟度 | 新发布 | 新发布 | 成熟(2 年迭代) |
💡 一句话理解
2026 年的 Agent 框架选型需要考虑一个额外的维度:你对供应商锁定的容忍度。官方 SDK 开发效率最高,但也最容易锁定。LangGraph 虽然配置稍复杂,但保证了模型选择的自由度。
⚠️ 常见踩坑
OpenAI Agents SDK 和 Anthropic Agent SDK 都是 2026 年 5 月刚刚发布/更新的产品,API 稳定性尚未得到充分验证。在生产环境中使用这些新 SDK 时,务必做好降级方案——当 API 发生不兼容变更时,能够快速切换到备用框架。