选择智能体AI框架:LangGraph、CrewAI、OpenAI SDK、ADK
跳过功能表。将您的项目归类为五种类型之一,比较四种编排风格,并查看LangGraph、CrewAI和OpenAI SDK的最简示例。
在2026年选择代理框架似乎比应有的难度要大。一旦开始寻找,就会遇到LangGraph、CrewAI、OpenAI Agents SDK、谷歌的Agent Development Kit、Claude Agent SDK、AG2、PydanticAI以及更多类似产品,它们都宣称自己是最合理的默认选择。
这种困惑并非你的研究失败所致。该领域已经出现分化,选择更多属于哲学层面的考量而非技术层面,因为每个框架都体现了不同的理念——即你对代理执行过程应保留多大的控制权,以及代理之间应如何交互。IBM的一份说明中有一句话很好地概括了正确的思考方式:别再问哪个框架最好,而应先明确自己正在构建的是何种类型的代理系统。
以下内容面向已了解智能体概念的中高级开发人员及架构师:智能体是一种拥有工具、指令和一定内存的模型,能够通过多步操作来实现目标。本文假设您能阅读Python代码,并且至少尝试过基于单个智能体的工具调用循环。内容首先将项目分为五种类型,接着比较四种编排理念,最后提供三个最简代码示例,以便您在投入实际开发前感受不同编程模型之间的差异。
框架究竟能帮您避免什么
为了演示目的,您可以不借助任何框架来构建智能体。不过,在几乎所有成熟的系统中都会出现一些常见问题,而框架的存在主要是为了让您不必重复解决这些问题:
- 推理循环。调用模型,执行其选择的工具,将结果反馈回去,如此反复直至满足停止条件。
这里列出的所有框架都涵盖了这四个方面,不同之处在于它们在推行自身解决方案时的力度大小。
从应用场景出发
在比较各种功能之前,先明确自己真正要构建什么。大多数项目可归为五类,每类都会推荐不同的候选框架列表。
- 线性工作流。各步骤按可预测的、基本固定的顺序执行:客服人员先在知识库中查找信息,起草回复,可能还会创建工单。这种情况下无需工作人员之间进行讨论,只需要可靠性即可。LangChain适用于序列处理,LlamaIndex适合以检索为主的工作,而当序列需要条件判断或循环结构时,LangGraph则能发挥作用。
- 自主多智能体团队。将目标任务分配后,一组智能体会共同商讨执行方案,比如由规划者、程序员和审核员共同完成一项编程任务。这类问题本质上是开放式的。AG2(AutoGen的后续维护版本)和CrewAI是常见的解决方案。
这样的排序方式将“选择哪种框架?”这一问题简化了。该流程是可预测的、探索性的、受角色限制的、面向生产环境的,还是仅仅是一个假设?
框架实现协作的四种方式
在候选框架中,它们在表示协作的方式上仍存在差异。大致而言,这些框架遵循四种理念之一。
- 基于图的结构。智能体与逻辑是有向图中的节点,而显式的边——无论是条件性的还是循环的——决定了下一步该执行什么操作。LangGraph就是最典型的例子,实际上就是在定义状态机。
- 基于角色的结构。每个智能体都是具有特定角色、目标及背景故事的团队成员,而上层流程则负责决定任务如何在它们之间流转。CrewAI正是基于这一理念构建的。
没有哪种理念能完全占据优势。您的选择应基于团队对问题的现有认知模型,以及您希望对执行路径施加的多大的显式控制程度。
框架在技术栈中的定位
每个框架都构建在一个或多个模型提供者之上,并负责管理推理循环。在其之上是工具调用功能,这一功能正通过MCP逐步实现标准化。有消息称,自2025年12月以来该标准一直由Linux基金会的Agentic AI基金会负责管理,这里的每个框架都以某种形式支持该标准。当智能体需要在不同流程或服务之间进行通信时,Agent2Agent(A2A)协议正逐渐成为类似的行业标准,ADK已内置对该协议的支持,其他平台也在陆续加入。
下面涉及状态持久化机制,例如 LangGraph 将数据保存到数据库或使用简单的内存聊天历史记录,以及可观测性层,比如 LangGraph 的 LangSmith 或 OpenAI Agents SDK 内置的追踪功能。当智能体面对真实用户时,这些机制的重要性远超过在笔记本环境中的使用。这些框架均不绑定于特定的云服务。OpenAI Agents SDK 和 Google ADK 更倾向于使用各自供应商的模型,而 LangGraph 和 CrewAI 则力求保持对模型的无关性。
三个最简示例
这些示例刻意设计得非常简短,仅用于展示各框架的编程模型,并非实际生产系统。该领域的软件包名称和安装步骤变化较快,因此请先查阅每个项目的最新文档。
LangGraph:双节点图结构
# pip install langgraph
from langgraph.graph import StateGraph, END
from typing import TypedDict
class State(TypedDict):
question: str
answer: str
def research(state: State) -> State:
state["answer"] = f"Researched: {state['question']}"
return state
def write(state: State) -> State:
state["answer"] = f"Written up: {state['answer']}"
return state
graph = StateGraph(State)
graph.add_node("research", research)
graph.add_node("write", write)
graph.set_entry_point("research")
graph.add_edge("research", "write")
graph.add_edge("write", END)
app = graph.compile()
result = app.invoke({"question": "What is agentic AI?", "answer": ""})
print(result["answer"])
# Output: Written up: Researched: What is agentic AI?
该代码定义了节点间共享的带类型的状态,通过普通的 Python 函数添加两个节点,并用显式的边将它们连接起来。此处并未调用任何大型语言模型。LangGraph 在这方面刻意保持中立,因此你可以在每个节点上插入任意喜欢的模型客户端。
CrewAI:双智能体团队
# pip install crewai
from crewai import Agent, Task, Crew
researcher = Agent(
role="Researcher",
goal="Find accurate information on the given topic",
backstory="An experienced analyst who values accuracy over speed."
)
writer = Agent(
role="Writer",
goal="Turn research into a clear summary",
backstory="A technical writer who favours plain language."
)
research_task = Task(
description="Research agentic AI frameworks",
expected_output="A short list of key considerations",
agent=researcher
)
write_task = Task(
description="Summarise the research for a developer audience",
expected_output="A concise paragraph",
agent=writer
)
crew = Crew(agents=[researcher, writer], tasks=[research_task, write_task])
result = crew.kickoff()
没有需要连接的节点或边。两个智能体通过角色和目标来定义,每个都会被分配一项任务。默认情况下,该系统会依次执行这些任务,并将每项任务的输出传递给下一项。CrewAI负责进行协调工作,而LangGraph则要求用户显式地对这些协调过程进行建模。
OpenAI Agents SDK:在智能体之间传递对话内容
# pip install openai-agents
from agents import Agent, Runner
billing_agent = Agent(
name="Billing",
instructions="Handle billing questions concisely."
)
triage_agent = Agent(
name="Triage",
instructions="Answer general questions; hand off billing questions to Billing.",
handoffs=[billing_agent]
)
result = Runner.run_sync(triage_agent, "Why was I charged twice this month?")
print(result.final_output)
在示例中,分诊代理会被告知一个可以将其任务转交的另一个代理。如果模型判断消息与计费相关,SDK的运行器会自动将对话转交给计费代理。没有图表,也没有角色隐喻:仅有代理以及他们可以使用的工具和任务转交方式。Google ADK在规模上类似,有一个带有sub_agents的根代理,但其子代理构成了一棵明确的树结构,可以通过A2A方式包含远程代理,而上述的任务转交列表则是扁平的。
根据您的需求选择合适的框架
以下情况可选择LangGraph:
- 您的工作流包含循环、重试或需要明确建模的条件分支;
- 您需要能够在重启后仍然保留的状态,或进行时间回溯式调试;
- 您的团队已经在使用LangChain组件。
以下情况可选择CrewAI:
- 该问题可自然地划分为不同角色,这样的划分方式有助于非工程领域的人员理解;
- 你希望相关功能能在几小时内运行起来;
- 如果基于角色的执行顺序已无法满足需求,你愿意将关键部分迁移到更低层次的框架中;
何时选择 OpenAI Agents SDK:
- 你主要基于 OpenAI 模型进行开发,并希望在推理流程之上添加最简洁且实用的层;
- 你的协调需求仅需在少数专家之间进行任务分配。
何时选择 Google ADK:
- 你已经在使用 Google Cloud 或 Gemini 生态系统;
- 智能体需要跨团队或服务协作,此时 A2A 的远程智能体模型更为合适。
其他情况可考虑其他方案:
- 类型安全比编排灵活性更为重要,在这种情况下,能够利用 Pydantic 模型验证智能体输入与输出的 PydanticAI 可能优于其他四种方案;
- 如果你正处于五种应用场景中的某一种的原型阶段,那么在编写任何框架代码之前先使用 LangFlow 或 Flowise 会是更好的起点。
团队常犯的错误
- 先选择后定义。团队往往会挑选评分最高的框架,然后试图将问题解决思路强行套用到该框架中。事先明确分类标准通常能让候选方案一目了然,远比阅读四套文档有效。
- 忽视转换成本。提示词、智能体逻辑以及编排模式很少能轻松移植到其他框架中。如果你预感到最初的选择会无法满足后续需求,应提前规划部分重写方案,而不要指望能快速更换框架。
接下来的行动
- 在查阅任何框架的文档之前,先确定你的项目属于哪一类:线性型、自主多智能体型、基于角色的型、生产级编排型还是快速原型型。
- 安装上述某个框架,然后根据你自己的使用场景而非示例来重新构建一个简单案例。
- 为你需要连接的系统寻找现有的MCP工具服务器,若有现成的工具接口则无需自行编写连接代码。
- 提前约定切换规则,例如当分支数量满足三个条件时即切换到LangGraph。
简版总结
在询问哪种框架最佳之前,先思考你的项目符合五种常见模式中的哪一种:可预测的线性流程、开放式的自主团队、有明确职责分工的小组、生产调度任务,还是处于原型阶段的想法。
回答这个问题就能在查看任何功能对比表之前缩小选择范围。之后剩下的主要就是理念问题了。如果需要明确控制分支结构,可选择LangGraph;若追求基于角色的思维模式与快速迭代,则选CrewAI;想要在OpenAI模型上实现简单操作,可用OpenAI Agents SDK;而如果你已身处Google生态系统,则适合选择ADK。MCP和A2A正逐渐成为工具及智能体间通信的通用标准,因此日后更换方案带来的影响会稍小一些,但依然不会毫无代价。