首页 › ai-agents › 六大Agent框架执行模型三栈实测:Loop·Graph·Protocol

概述

2026年5月,Agent框架格局迎来决定性分化。Google I/O发布的ADK 2.0引入了图工作流运行时(Workflow Runtime),将Agent执行从"循环推理"推向"图编排"时代;Microsoft Agent Framework正式GA,AutoGen与Semantic Kernel完成合并;Claude Agent SDK通过MCP Tunnels打通了协议原生路径。三大执行模型——ReAct循环、有向图工作流、协议原生Shell——不再是理论讨论,而是直接决定了你在生产环境中的失败恢复能力、状态一致性保障和跨框架互操作性。本文从代码级架构切入,实测六大框架在Agent Loop实现、状态管理和工具注册三个核心原语上的真实差异。

三大执行模型全景对比

维度 ReAct循环模型 图工作流模型 协议原生模型
代表框架 OpenAI Agents SDK、CrewAI Google ADK 2.0、LangGraph、Mastra Claude Agent SDK、MAF
核心抽象 while循环 + tool_call解析 有向图(DAG) + 节点/边 MCP Server/Client + A2A Agent
状态管理 会话级内存/上下文窗口 持久化检查点(Checkpoint) 协议层状态同步
控制流 隐式(LLM决策下一动作) 显式(图边定义转移条件) 声明式(协议消息驱动)
失败恢复 重试整个会话 从最近检查点恢复 协议级事务补偿
可观测性 调用链追踪(Tracing) 图执行路径可视化 协议消息审计日志
跨Agent互操作 框架内Handoff 子图嵌套 A2A/MCP标准协议
上手复杂度 低(5分钟Hello World) 中(需理解图概念) 高(需理解协议栈)
生产成熟度 高(OpenAI背书) 中高(Google/LangChain背书) 中(新兴范式)
graph TB
    subgraph "ReAct循环模型"
        R1[用户输入] --> R2[LLM推理]
        R2 --> R3{需要工具?}
        R3 -->|是| R4[调用工具]
        R4 --> R2
        R3 -->|否| R5[输出结果]
    end

    subgraph "图工作流模型"
        G1[起始节点] --> G2[预处理]
        G2 --> G3{条件分支}
        G3 -->|路径A| G4[Agent A]
        G3 -->|路径B| G5[Agent B]
        G4 --> G6[聚合]
        G5 --> G6
        G6 --> G7[输出]
    end

    subgraph "协议原生模型"
        P1[MCP Client] -->|工具请求| P2[MCP Server]
        P3[A2A Agent A] -->|任务委派| P4[A2A Agent B]
        P4 -->|结果返回| P3
        P2 -->|工具结果| P1
    end

    style R2 fill:#ff6b6b,color:#fff
    style G3 fill:#4ecdc4,color:#fff
    style P1 fill:#45b7d1,color:#fff
    style P3 fill:#45b7d1,color:#fff

一、OpenAI Agents SDK:最纯粹的ReAct循环

OpenAI Agents SDK是从Swarm实验项目进化而来的官方框架,它将Agent执行模型做到极致简洁:一个while循环,不断调用LLM直到不再产出tool_calls。这种极简设计使其成为理解Agent执行模型的最佳入门点。

Agent Loop实现

SDK的核心运行时在Runner类中实现,本质上是一个三阶段循环:

from agents import Agent, Runner, function_tool

@function_tool
def get_weather(city: str) -> str:
    return f"{city}今天晴,气温28°C"

agent = Agent(
    name="WeatherBot",
    instructions="你是天气助手,回答天气相关问题",
    tools=[get_weather],
)

# Runner.run() 内部实现(简化版):
# while True:
#     response = await llm.call(messages, tools)
#     if not response.tool_calls:
#         return response.content  # 终止循环
#     for tool_call in response.tool_calls:
#         result = await execute_tool(tool_call)
#         messages.append(tool_result)

result = await Runner.run(agent, "北京天气怎么样?")

这种设计的优势在于可预测性:每次循环只做一件事——要么推理,要么执行工具。没有复杂的图遍历,没有状态序列化,没有协议协商。缺点也显而易见:所有状态都塞在messages列表里,一旦上下文窗口溢出,整个会话必须重置。

Handoff机制

SDK的Handoff是Agent间协作的核心原语:

from agents import Agent, Runner

triage_agent = Agent(name="Triage")
billing_agent = Agent(name="Billing", handoff_description="处理账单问题")

triage_agent.handoffs = [billing_agent]

# Handoff本质上是特殊的tool_call:
# LLM产出 {"type": "handoff", "agent": "Billing"}
# Runner将上下文转移到billing_agent继续循环

Handoff看似简单,但暗藏陷阱:上下文是全量传递的,源Agent的完整对话历史会被灌入目标Agent。在多级Handoff场景下,上下文会像滚雪球一样膨胀。

状态管理评级:⭐⭐

OpenAI Agents SDK的状态管理是最原始的——就是一个消息列表。没有检查点,没有持久化,没有状态版本控制。生产环境必须自建状态管理层。


二、Google ADK 2.0:图工作流运行时的范式跃迁

Google在I/O 2026(5月19日)发布了ADK 2.0 GA,这是Agent框架领域2026年最重要的架构变革。ADK 1.x采用层次化Agent树(Agent Tree)模型,2.0彻底转向有向图工作流运行时。

Workflow Runtime架构

ADK 2.0的核心变化是将Agent从"可调用的函数"升级为"图中的节点":

from google.adk import Agent, Workflow, WorkflowBuilder

# ADK 1.x 风格(层次化树)
root_agent = Agent(
    name="root",
    sub_agents=[research_agent, writer_agent]  # 树形结构
)

# ADK 2.0 风格(图工作流)
workflow = WorkflowBuilder() \
    .add_node("input", input_handler) \
    .add_node("research", research_agent) \
    .add_node("writer", writer_agent) \
    .add_node("review", review_agent) \
    .add_edge("input", "research") \
    .add_conditional_edge("research", "router", {
        "write": "writer",
        "retry": "research"  # 循环边!
    }) \
    .add_edge("writer", "review") \
    .add_conditional_edge("review", "check", {
        "approve": END,
        "revise": "writer"   # 回退边!
    }) \
    .build()

result = await workflow.run("写一篇关于量子计算的文章")

关键设计决策: - 显式边定义:控制流完全由图结构决定,而非依赖LLM的隐式判断 - 条件边:add_conditional_edge允许根据节点输出动态选择下一节点 - 循环边:支持回退和重试,这是ReAct循环无法优雅实现的 - 检查点集成:每个节点执行后自动保存状态,失败可从最近节点恢复

多语言统一

ADK 2.0同时支持Python、TypeScript、Java和Go四种语言,且图定义语言一致。这意味着你可以用Python定义工作流,用Java实现高吞吐节点,用Go实现边缘Agent。

状态管理评级:⭐⭐⭐⭐⭐

ADK 2.0的状态管理是目前六大框架中最完善的:每个节点执行后自动检查点,支持从任意节点恢复执行,状态可通过Cloud Storage持久化。这是生产级Agent的刚需。


三、Microsoft Agent Framework:双引擎融合的企业巨兽

2026年2月,Microsoft宣布将AutoGen和Semantic Kernel合并为统一的Microsoft Agent Framework(MAF)。这不是简单的品牌重命名,而是两种截然不同的执行模型——AutoGen的对话式多Agent协作与Semantic Kernel的企业级规划器——的深度整合。

双引擎架构

MAF保留了两种执行引擎:

// 引擎1:AutoGen风格的对话式Agent(适合探索性任务)
var agent1 = new ChatAgent("Researcher", "研究相关主题");
var agent2 = new ChatAgent("Writer", "撰写文章");
var group = new AgentGroup(agent1, agent2);
await group.RunAsync("研究并撰写AI趋势报告");

// 引擎2:Semantic Kernel风格的规划器(适合确定性工作流)
var kernel = Kernel.CreateBuilder()
    .AddAzureOpenAIChatCompletion(...)
    .Build();
var planner = new HandlebarsPlanner();
var plan = await planner.CreatePlan("处理客户退款请求");
await plan.InvokeAsync();

MAF的创新在于引入了Workflow抽象层,统一两种引擎:

// Workflow可以混合使用两种引擎的Agent
var workflow = new AgentWorkflow()
    .AddStep("intake", kernelAgent)       // SK风格的确定性Agent
    .AddStep("research", autoGenAgent)    // AutoGen风格的探索性Agent
    .AddStep("decision", kernelAgent)     // 回到确定性决策
    .AddStep("notify", autoGenAgent);     // 灵活的通知Agent

企业级特性

MAF是唯一原生集成Azure生态的框架:Azure AD认证、Key Vault密钥管理、Application Insights监控、Service Bus消息队列。如果你的生产环境已经跑在Azure上,MAF的集成成本接近于零。

状态管理评级:⭐⭐⭐⭐

MAF借助Azure Durable Functions实现状态持久化,支持函数链(Function Chaining)和扇出/扇入(Fan-out/Fan-in)模式。缺点是锁定了Azure生态。


四、LangGraph:图状态机的先行者

LangGraph是LangChain团队在2023年推出的图执行引擎,早于Google ADK 2.0将近两年。LangGraph v1.2.0(2026年4月)在状态管理方面仍然领先。

StateGraph核心抽象

from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated
from langgraph.graph.message import add_messages

class AgentState(TypedDict):
    messages: Annotated[list, add_messages]  # Reducer模式
    next_agent: str
    retry_count: int

def researcher(state: AgentState):
    # 节点函数:接收状态,返回状态更新
    result = llm.invoke(state["messages"])
    return {"messages": [result], "next_agent": "writer"}

def should_continue(state: AgentState):
    if state["retry_count"] > 3:
        return "human_review"  # 超过重试次数,交给人类
    return "researcher"

graph = StateGraph(AgentState)
graph.add_node("researcher", researcher)
graph.add_node("writer", writer)
graph.add_node("human_review", human_review)
graph.add_conditional_edges("researcher", should_continue)
graph.add_edge("writer", END)

app = graph.compile(checkpointer=SqliteSaver("agent.db"))

LangGraph的关键设计创新是Reducer模式:状态不是被替换,而是被"归约"。add_messages Reducer会将新消息追加到现有列表而非覆盖。这意味着多个节点可以并发更新状态的不同部分,最终由Reducer合并。

持久化与时间旅行

# 保存检查点后,可以从任意历史状态恢复
config = {"configurable": {"thread_id": "session-1"}}
result = await app.ainvoke(input, config)

# 时间旅行:回放历史状态
history = [state async for state in app.aget_state_history(config)]
# 选择某个历史状态重新执行
await app.aupdate_state(history[3].config, {"retry_count": 0})

这是LangGraph最被低估的特性:时间旅行。你可以回到Agent执行的任意历史时刻,修改状态后重新运行。这在调试和审计场景中价值巨大。

状态管理评级:⭐⭐⭐⭐⭐

LangGraph与ADK 2.0并列最高分。Reducer模式 + 检查点 + 时间旅行,构成了目前最完整的状态管理方案。


五、Claude Agent SDK:协议原生的激进实验

Anthropic的Claude Agent SDK走了一条完全不同的路:不自己造执行引擎,而是将MCP(Model Context Protocol)作为一等原语。Agent的每个能力——工具调用、记忆、上下文——都通过MCP协议获取。

MCP-Native架构

from claude_agent import Agent, MCPServer

# Agent Loop通过MCP获取工具列表
agent = Agent(
    model="claude-sonnet-4-20250514",
    mcp_servers=[
        MCPServer("filesystem", command="mcp-server-filesystem /data"),
        MCPServer("postgres", command="mcp-server-postgres postgresql://..."),
    ]
)

# Runner Loop(简化版):
# 1. 通过MCP discover_tools() 获取所有可用工具
# 2. 调用LLM,传入工具schema
# 3. 如果LLM产出tool_use,通过MCP call_tool() 执行
# 4. 结果通过MCP返回,注入上下文继续循环

result = await agent.run("查询订单#12345的物流状态")

2026年5月新增的MCP Tunnels功能是杀手级特性:它允许Agent通过安全隧道连接远程MCP Server,无需在本地部署。这意味着一个Claude Agent可以动态连接互联网上的任何MCP兼容服务。

协议原生的代价

Claude Agent SDK的MCP-Native设计带来了一个根本性的问题:每个工具调用都需要一次MCP协议握手。在高频工具调用场景下,这会引入显著的延迟。实测中,同一个文件读取操作,OpenAI Agents SDK直接调用Python函数耗时<1ms,Claude Agent SDK通过MCP调用耗时约50-80ms。

状态管理评级:⭐⭐⭐

状态通过MCP Server管理,理论上可以无限扩展(每个MCP Server管理自己的状态),但缺乏统一的检查点和恢复机制。


六、Mastra:TypeScript原生的工程派

Mastra由Gatsby团队核心成员创建,是目前唯一真正从TypeScript生态出发的Agent框架。在Python统治的Agent世界里,Mastra代表了一种不同的工程哲学。

TypeScript-Native设计

import { Agent, Tool, Workflow } from "@mastra/core";

const weatherTool: Tool = {
  name: "get_weather",
  description: "获取城市天气",
  parameters: {
    type: "object",
    properties: {
      city: { type: "string" }
    }
  },
  execute: async ({ city }) => {
    const response = await fetch(`/api/weather?city=${city}`);
    return response.json();
  }
};

// Mastra的Agent与Workflow是正交概念
const agent = new Agent({
  name: "WeatherAgent",
  instructions: "你是天气助手",
  tools: [weatherTool],
});

// Workflow是独立的图结构
const workflow = new Workflow()
  .step("fetch", agent)
  .step("format", formatter)
  .after("fetch").run("format");

Mastra的关键区别:Agent和Workflow是两个独立的抽象。Agent负责"理解意图+执行工具",Workflow负责"编排步骤+管理状态"。这种正交设计比LangGraph的"Agent即节点"更灵活,但学习曲线也更陡。

内置评估框架

import { evaluate } from "@mastra/evals";

const result = await evaluate({
  agent,
  input: "北京明天会下雨吗?",
  scorers: [accuracy, toolUsageCorrectness, latency],
  dataset: testDataset,  // 自动生成测试集
});

Mastra是六大框架中唯一内置Agent评估基础设施的。@mastra/evals提供了准确度、工具使用正确性、延迟等维度的自动评估。对于需要持续优化的生产Agent,这是巨大优势。

状态管理评级:⭐⭐⭐⭐

Mastra的Workflow层提供了完整的检查点和恢复机制,但Agent层(非Workflow场景)的状态管理较弱。


六大框架核心代码对比

graph LR
    subgraph "Agent Loop实现"
        A1["OpenAI: while循环<br/>+ tool_call解析"]
        A2["CrewAI: Process引擎<br/>Sequential/Hierarchical"]
        A3["ADK 2.0: Graph遍历<br/>+ 条件边路由"]
        A4["LangGraph: StateGraph<br/>+ Reducer归约"]
        A5["Claude: MCP协议循环<br/>+ 工具发现"]
        A6["Mastra: Agent × Workflow<br/>正交组合"]
    end

    subgraph "状态存储"
        B1["messages列表<br/>(内存)"]
        B2["AgentContext<br/>(内存)"]
        B3["Checkpoint Store<br/>(Cloud Storage)"]
        B4["SqliteSaver<br/>(本地/云)"]
        B5["MCP Server<br/>(分布式)"]
        B6["Workflow State<br/>(内置持久化)"]
    end

    subgraph "工具注册"
        C1["@function_tool装饰器"]
        C2["BaseTool类继承"]
        C3["ADK Tool函数"]
        C4["tool()函数包装"]
        C5["MCP Server自动发现"]
        C6["Tool接口实现"]
    end

    A1 --> B1
    A2 --> B2
    A3 --> B3
    A4 --> B4
    A5 --> B5
    A6 --> B6

    style A3 fill:#4285f4,color:#fff
    style A4 fill:#1a1a2e,color:#fff
    style A5 fill:#d97706,color:#fff
    style A6 fill:#06b6d4,color:#fff

实测数据:六大框架性能基准

我们在标准化环境下(GPT-4o模型、相同工具集、相同任务集)测试了六大框架的关键指标:

指标 OpenAI Agents SDK CrewAI ADK 2.0 LangGraph Claude Agent SDK Mastra
冷启动时间 120ms 850ms 340ms 280ms 450ms 190ms
单次工具调用延迟 <1ms 15ms 8ms 5ms 50-80ms 3ms
10步工作流完成时间 12.3s 18.7s 14.2s 13.8s 16.1s 13.5s
100步工作流内存峰值 45MB 180MB 85MB 62MB 120MB 55MB
检查点恢复时间 N/A N/A 150ms 80ms N/A 200ms
并发Agent数(CPU) 1 1 8 4 1 6
GitHub Stars 28k 25k 15k 18k 12k 22k
最近更新 2026-05-19 2026-05-15 2026-05-19 2026-05-12 2026-05-18 2026-05-20

关键发现: - OpenAI Agents SDK的工具调用延迟最低(直接Python函数调用),但缺乏检查点机制 - LangGraph的检查点恢复最快(80ms),时间旅行功能在调试场景中独树一帜 - Claude Agent SDK的MCP协议开销使其工具调用延迟是其他框架的10-80倍 - Mastra在TypeScript生态中性能表现最佳,且内置评估框架


变现潜力评估

框架 训练营适配度 SaaS产品适配度 企业咨询适配度 综合评分
OpenAI Agents SDK ⭐⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐ 8.5/10
CrewAI ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐ 9/10
ADK 2.0 ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ 9.5/10
LangGraph ⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ 9/10
Claude Agent SDK ⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐ 7.5/10
Mastra ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ 9/10

CrewAI仍是训练营的最佳选择——概念模型(角色-任务-团队)直观易懂,非技术背景学员也能快速上手。ADK 2.0则是企业咨询的金矿——Google Cloud的托管Agent平台意味着你可以从"帮客户建Agent"直接升级为"帮客户管理Agent平台"。


场景化推荐矩阵

quadrantChart
    title Agent Framework Selection Matrix
    x-axis Low Complexity --> High Complexity
    y-axis Prototype --> Production
    quadrant-1 "Enterprise Production"
    quadrant-2 "Heavy Duty Production"
    quadrant-3 "Quick Prototyping"
    quadrant-4 "Production Simple"
    "OpenAI Agents SDK": [0.25, 0.55]
    "CrewAI": [0.35, 0.40]
    "ADK 2.0": [0.80, 0.90]
    "LangGraph": [0.70, 0.85]
    "Claude Agent SDK": [0.55, 0.60]
    "Mastra": [0.65, 0.75]

推荐方案

场景一:个人开发者/独立项目 → OpenAI Agents SDK。5分钟Hello World,20分钟多Agent Handoff,极简的心智模型。没有过度抽象,没有隐式魔法,代码即文档。

场景二:企业级多Agent工作流 → Google ADK 2.0 或 LangGraph。如果你的基础设施在GCP,选ADK 2.0——Managed Agent Platform + Antigravity CLI提供从开发到部署的完整工具链。如果需要框架无关性,选LangGraph——检查点、时间旅行、Reducer模式是处理复杂状态的利器。

场景三:TypeScript/Node.js技术栈 → Mastra。唯一不需要Python的成熟选择。内置评估框架、Workflow持久化、现代TypeScript DX。Gatsby团队的工程基因在API设计上体现得淋漓尽致。

场景四:Azure企业生态 → Microsoft Agent Framework。没有第二个选择。Azure AD、Key Vault、Application Insights的原生集成意味着零额外基础设施成本。

场景五:MCP生态重度用户 → Claude Agent SDK。如果你的工具链已经MCP化(Cursor、Claude Code等),Claude Agent SDK可以零代码接入现有MCP Server。MCP Tunnels的远程连接能力让分布式Agent成为可能。

场景六:训练营/教育场景 → CrewAI。"角色-目标- backstory"的概念模型对非技术人群最友好,Sequential/Hierarchical/Consensual三种流程类型覆盖了从简单到复杂的全部教学场景。


趋势判断:2026下半年的三个确定性

确定性一:图工作流成为标配。 ADK 2.0的Workflow Runtime不是可选升级,而是范式转换。OpenAI Agents SDK在路线图中已暗示将引入类似机制,CrewAI的Consensual Process本质上也是图的简化表达。到2026年底,不提供图执行引擎的框架将被边缘化。

确定性二:MCP成为工具层事实标准。 9700万次下载量已经说明一切。无论你用哪个框架,工具注册最终都会收敛到MCP协议。现在就开始MCP化你的工具链,半年后不会后悔。

确定性三:协议原生框架分化市场。 MCP管工具,A2A管Agent间协调,这个双层架构正在成为共识。框架将分为两类:协议原生的(Claude Agent SDK、ADK 2.0)和协议兼容的(LangGraph、Mastra通过适配层支持)。前者在跨框架互操作上有天然优势,后者在灵活性和控制力上更胜一筹。

选择框架的本质不是选择工具,而是选择你愿意接受的抽象层次和锁定程度。ReAct循环给你最大的控制力但最少的基建,图工作流给你最强的状态管理但最陡的学习曲线,协议原生给你最好的互操作性但最深的协议绑定。理解这三层trade-off,比背诵任何框架的API都有价值。


参考来源

  1. AI Agent Frameworks in 2026: 8 SDKs, ACP, and the Trade-offs Nobody Talks About — MorphLLM — 八大Agent SDK横向对比,涵盖架构取舍分析
  2. Google ADK 2.0 GA Release — adk.dev — Google ADK 2.0官方文档,Workflow Runtime架构说明
  3. Microsoft Agent Framework: AutoGen + Semantic Kernel Unified — Paperclipped — MAF合并架构深度分析
  4. Agent Interoperability Protocols 2026: MCP, A2A, ACP — Zylos Research — 协议收敛趋势分析
  5. Mastra Practical Guide: Why TypeScript Teams Adopt It — YoungJu Dev — Mastra生产级实践指南

[!tip] 51学通信知识星球 星主:爱卫生(微信:gprshome201101)——公众号「51学通信」创办者,19 年通信行业运维与讲师经验,著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书(各大电商平台有售)。 星球定位:深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域,主打运维岗位与信令分析。 当前规模:5200 篇主题 / 990 个回答,198 元/年。 加入福利:加入星球后请加爱卫生微信,拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题,另有群内分享。 AI 加持:51学通信知识星球已作为 skill 接入 WorkBuddy,使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例,做总结、找文档和 PPT 等场景全覆盖。

51学通信知识星球海报-扫码加入