langgraph crewai google-adk agents python comparison

LangGraph、CrewAI还是Google ADK？同一项双智能体任务，三种框架。

通过构建相同的研究者-作者配对来比较LangGraph、CrewAI和Google ADK，然后通过关于控制、速度及A2A方面的五个有序问题进行选择。

发布者：REACTAPP.TOP加入本站 2026年10月28日阅读约 6 分钟1464 词

来源: LangGraph vs CrewAI vs Google ADK: I Built the Same Agent Three Times

框架对比通常采用相同的模板：功能列表，每列一个段落，以及避免给出具体推荐的结论。这对于那些正处于选择十字路口、需要做出决定并继续前进的人并无帮助。此处的对比则是通过用LangGraph、CrewAI和Google ADK实现同一个小型系统来展开的，因此差异源于代码实现与权衡取舍，而非规格说明。

三种思维模型

在编写代码之前先明确几个概念：

LangGraph就像一盒乐高积木。每个节点、边和条件分支都需要明确定义。它提供了最大的控制力，但学习曲线也最为陡峭。
CrewAI是一个预先组建好的团队，它会询问自己该做什么。团队中的角色和目标已被明确，框架负责协调工作。这是最快打造出可用原型的方法，但对智能体之间如何协作则干预较少。
Google ADK的思维方式类似资深后端工程师。它采用事件驱动且具有状态管理功能，内置了可观测性、可测试性以及优雅的故障处理机制，同时还与Google Cloud和Gemini深度集成。

这些并非批评，只是针对大多数开发者最常需要的功能所采取的不同设计思路。

测试任务

每个框架的任务都相同：研究人员收集资料，然后由撰写者将其转化为最终结果，因此撰写者必须等到研究人员完成工作才能开始。类似监督器的路由器正好可以处理这类任务，这便成为衡量不同工具在表达相同流程时差异程度的公平标准。

LangGraph

首先导入：

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

接着是带类型的状态、节点以及显式的边：

class State(TypedDict):
    query: str
    research: str
    final_answer: str
def research_node(state: State) -> State:
    # Call your research agent/tool here
    state["research"] = f"Research findings for: {state['query']}"
    return state
def writer_node(state: State) -> State:
    # Call your writer agent, using state["research"]
    state["final_answer"] = f"Final answer using: {state['research']}"
    return state
graph = StateGraph(State)
graph.add_node("research", research_node)
graph.add_node("writer", writer_node)
graph.set_entry_point("research")
graph.add_edge("research", "writer")
graph.add_edge("writer", END)
app = graph.compile()
result = app.invoke({"query": "What is agentic AI?"})

这里的所有边都是手工绘制的。每一步该执行什么一目了然，而这正是 LangGraph 的代价与优势：需要预先编写更多代码，以此换取框架永远不会即兴变动的控制流。

CrewAI

from crewai import Agent, Task, Crew

接下来是代理和任务：

researcher = Agent(
    role="Research Specialist",
    goal="Find accurate information on the given topic",
    backstory="An expert at gathering and synthesizing information."
)
writer = Agent(
    role="Content Writer",
    goal="Write a clear final answer using research findings",
    backstory="An expert at turning research into clear prose."
)
research_task = Task(
    description="Research: {query}",
    agent=researcher,
    expected_output="A summary of relevant findings"
)
writing_task = Task(
    description="Write a final answer using the research",
    agent=writer,
    expected_output="A clear, well-written final answer",
    context=[research_task]
)
crew = Crew(agents=[researcher, writer], tasks=[research_task, writing_task])
result = crew.kickoff(inputs={"query": "What is agentic AI?"})

注意LangGraph旁边缺少了什么：没有人绘制图表或连接边。代码明确了每个人的职责，CrewAI的流程逻辑会自动将研究任务的结果应用到写作任务中。一旦熟悉了这种模式，开发出可用的版本所需时间会大大缩短，大约二十分钟即可完成。

Google ADK

from google.adk.agents import Agent
from google.adk.runners import Runner

research_agent = Agent(
    name="researcher",
    model="gemini-2.0-flash",
    instruction="Research the given topic thoroughly and return findings.",
)
writer_agent = Agent(
    name="writer",
    model="gemini-2.0-flash",
    instruction="Write a clear final answer using the research findings provided.",
    sub_agents=[research_agent]  # hierarchical relationship
)
runner = Runner(agent=writer_agent, app_name="research_writer_app")
result = runner.run(user_id="user1", session_id="session1",
                     new_message="What is agentic AI?")

看看sub_agents字段。ADK基于以事件为驱动的父子层级结构构建，其运行时机制负责处理在传入请求、模型调用和工具执行之间的循环流程。它介于LangGraph的手动连接方式与CrewAI的隐式协调机制之间：虽然也存在层级结构，但相比LangGraph，更多底层细节已由系统自动处理。

它们真正的差异所在

简单的示例看起来颇为相似，但实际差异会在原型阶段之后显现出来。

控制性与可观测性。LangGraph被广泛认为是处理复杂、分支化工作流时最成熟的解决方案。它内置了检查点机制和持久化执行功能，据称Klarna正在为8500万用户使用该技术。这样的实际应用场景本身就比任何功能列表都更具说服力。唯一的缺点是学习曲线较陡，而在三者中恰恰因为其控制机制最为明确，所以学习难度最高。

快速构建首个原型。CrewAI始终占据优势。对于首个多智能体系统或快速验证想法的场景，其基于角色的抽象机制能让系统更快运行起来。但缺点是，当协调逻辑变得复杂时，同样的高级抽象机制会成为限制，因为难以对智能体何时以及如何交接任务进行更精细的控制。

企业级需求与语言支持。ADK于2026年正式推出，期间对其设计进行了调整，用基于图的引擎取代了原有的分层执行器，而这正是LangGraph从一开始就采用的设计理念。它的真正优势在于其他方面：它支持的语言种类比其他竞争对手更多（包括Python、TypeScript、Go、Java、Kotlin），能够直接与已使用Gemini和Google Cloud的团队集成，同时还配备了LangGraph和CrewAI所没有的评估工具。

跨框架通信。很少有比较会提及这一点。ADK原生支持Agent2Agent（A2A）协议，因此用完全不同框架编写的智能体也能与其交换消息，而经过签名的智能体卡片则可提供加密验证。当系统需要调用供应商或合作伙伴拥有的智能体时，A2A为智能体实现了与MCP为工具所实现的功能类似的作用：它标准化了两个智能体之间的交互，而非智能体与工具之间的交互。

令牌效率。这方面也存在可测量的差异。通过LangGraph和CrewAI执行相同任务的基准测试显示，LangGraph消耗的令牌明显更少。其原因很可能在于LangGraph是沿着明确的边进行处理的，而CrewAI则依赖大语言模型来路由任务，每一次这种隐式的路由选择都会产生少量的模型调用成本。无论哪种方式，总有人要为这些决策付出代价。

按顺序进行选择

不必查看功能列表，只需依次思考以下问题：

需要快速构建原型，还是这是个首个多智能体系统？选择CrewAI。这是最快实现功能的方法，一旦发现协调逻辑过于复杂，还可以再考虑其他选项。
需要最大程度的分支控制、明确的错误处理路径，或是人工干预的检查点？选择LangGraph。当路由逻辑较为复杂时，您希望亲自掌控每一条路径，而非让框架逻辑来决定。
已经在使用 Google Cloud，或者需要除 Python 之外的其他语言？选择Google ADK。其与 Gemini 和 Cloud 的原生集成能极大降低该生态系统中团队的使用门槛，而且其支持的语言种类也是最丰富的。

不同框架或供应商的代理必须互相通信吗？如需端到端支持，请选择Google ADK，因为另外两种方案均未将此作为核心功能。

以上选项均不适用？选择您的团队最熟悉的方案即可。这三种方案在2026年都已具备生产环境使用能力，更重要的是上层状态管理、路由机制及工具层的设计思路。

没有绝对的胜出者

没有哪种框架适合所有人，声称某种框架最适合所有人的比较往往带有商业目的。对于需要复杂工作流控制及生产环境强化的场景，可选择LangGraph；若希望最快获得可运行的原型，可选择CrewAI；而对于以Google Cloud为中心的团队以及需要真正实现跨框架通信的场景，则适合选择Google ADK。

应根据实际约束条件来决定，比如团队已掌握的信息、系统运行的云平台，或是协调逻辑的复杂程度，而非看哪个框架最近发布了最炫酷的公告。框架只是辅助工具而已。合理的智能体设计适用于以下三种模式：循环处理、信息检索、路由分配、工具标准、可观测性，以及定期评估结果的习惯。