首页 / 文章

选择智能体AI框架:LangGraph、CrewAI、OpenAI SDK、ADK

跳过功能表。将您的项目归类为五种类型之一,比较四种编排风格,并查看LangGraph、CrewAI和OpenAI SDK的最简示例。

发布者:REACTAPP.TOP阅读约 9 分钟2024 词

来源: A Guide to Choosing an Agentic AI Framework

在2026年选择代理框架似乎比应有的难度要大。一旦开始寻找,就会遇到LangGraph、CrewAI、OpenAI Agents SDK、谷歌的Agent Development Kit、Claude Agent SDK、AG2、PydanticAI以及更多类似产品,它们都宣称自己是最合理的默认选择。

这种困惑并非你的研究失败所致。该领域已经出现分化,选择更多属于哲学层面的考量而非技术层面,因为每个框架都体现了不同的理念——即你对代理执行过程应保留多大的控制权,以及代理之间应如何交互。IBM的一份说明中有一句话很好地概括了正确的思考方式:别再问哪个框架最好,而应先明确自己正在构建的是何种类型的代理系统。

以下内容面向已了解智能体概念的中高级开发人员及架构师:智能体是一种拥有工具、指令和一定内存的模型,能够通过多步操作来实现目标。本文假设您能阅读Python代码,并且至少尝试过基于单个智能体的工具调用循环。内容首先将项目分为五种类型,接着比较四种编排理念,最后提供三个最简代码示例,以便您在投入实际开发前感受不同编程模型之间的差异。

框架究竟能帮您避免什么

为了演示目的,您可以不借助任何框架来构建智能体。不过,在几乎所有成熟的系统中都会出现一些常见问题,而框架的存在主要是为了让您不必重复解决这些问题:

  • 推理循环。调用模型,执行其选择的工具,将结果反馈回去,如此反复直至满足停止条件。
  • 状态与内存。在多个步骤之间保持上下文一致,对于生命周期较长的智能体,则需在进程重启后仍能保持状态一致性。
  • 智能体间的协调。确定智能体如何相互发现、传递任务以及如何共享或隔离状态。
  • 可观测性。能够了解智能体为何会采取某种行动。在演示环境中这几乎无关紧要,但一旦在生产环境中出现故障,这一点就至关重要。
  • 这里列出的所有框架都涵盖了这四个方面,不同之处在于它们在推行自身解决方案时的力度大小。

    从应用场景出发

    在比较各种功能之前,先明确自己真正要构建什么。大多数项目可归为五类,每类都会推荐不同的候选框架列表。

    • 线性工作流。各步骤按可预测的、基本固定的顺序执行:客服人员先在知识库中查找信息,起草回复,可能还会创建工单。这种情况下无需工作人员之间进行讨论,只需要可靠性即可。LangChain适用于序列处理,LlamaIndex适合以检索为主的工作,而当序列需要条件判断或循环结构时,LangGraph则能发挥作用。
    • 自主多智能体团队。将目标任务分配后,一组智能体会共同商讨执行方案,比如由规划者、程序员和审核员共同完成一项编程任务。这类问题本质上是开放式的。AG2(AutoGen的后续维护版本)和CrewAI是常见的解决方案。
  • 基于角色的系统。与前者类似,不同之处在于每个智能体都固定在明确定义的角色中,如研究员、作家和编辑,而非自行发挥。CrewAI是这类系统的理想选择,此外还有诸如ChatDev这样的专用工具,用于软件开发场景的角色扮演。
  • 生产流程编排。这类系统已发展到使用真正的API、数据库和业务流程,例如能够对警报进行分类处理、查阅操作手册并执行修复操作的智能体。候选方案包括LangGraph、Google ADK以及微软的Agent Framework,后者还整合了AutoGen和Semantic Kernel。这三者在设计时都考虑到了系统的稳定性与深度集成。
  • 快速原型设计。有时你只需要快速得到某个想法的“是”或“否”答案。像LangFlow和Flowise这样的拖放式构建工具允许你在编写任何代码之前就在画布上勾勒出流程图。
  • 这样的排序方式将“选择哪种框架?”这一问题简化了。该流程是可预测的、探索性的、受角色限制的、面向生产环境的,还是仅仅是一个假设?

    框架实现协作的四种方式

    在候选框架中,它们在表示协作的方式上仍存在差异。大致而言,这些框架遵循四种理念之一。

    • 基于图的结构。智能体与逻辑是有向图中的节点,而显式的边——无论是条件性的还是循环的——决定了下一步该执行什么操作。LangGraph就是最典型的例子,实际上就是在定义状态机。
    • 基于角色的结构。每个智能体都是具有特定角色、目标及背景故事的团队成员,而上层流程则负责决定任务如何在它们之间流转。CrewAI正是基于这一理念构建的。
  • 基于任务交接。仅提供少量基础元素,即智能体、其工具以及将对话转交给另一智能体的功能,实现方式极为简单。OpenAI Agents SDK就是采用这种设计。
  • 分层结构。一个根智能体将任务分配给以树形结构组织的子智能体,这些子智能体可以本地运行或作为远程服务存在。Google的ADK采用的就是这种架构。
  • 没有哪种理念能完全占据优势。您的选择应基于团队对问题的现有认知模型,以及您希望对执行路径施加的多大的显式控制程度。

    框架在技术栈中的定位

    每个框架都构建在一个或多个模型提供者之上,并负责管理推理循环。在其之上是工具调用功能,这一功能正通过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正逐渐成为工具及智能体间通信的通用标准,因此日后更换方案带来的影响会稍小一些,但依然不会毫无代价。