到 2026 年中，AI Agent 框架的「能力之争」实质上已经结束。LangGraph、OpenAI Agents SDK、Google ADK、AutoGen、CrewAI、AWS Strands、PydanticAI、Mastra 这八大主流框架，在工具调用、记忆、规划、流式输出这些维度上已经没有代差——真正决定选型的，是它们如何实现同一个刚刚稳定下来的核心原语：**Agent 之间的委派（Delegation）**。本文实测六栈的委派原语实现，发现它们已收敛到三个共享形态：**Handoff（交接）、Agent-as-Tool（智能体即工具）、Sub-graph（子图）**，但控制返还语义、上下文传递方式、路由确定性这三处细节，划定了彼此无法逾越的红线。 ## 一、收敛的三个委派原语 过去两年，每个框架都发明过自己的多智能体胶水——OpenAI 的 Swarm 用 `transfer_to_agent`，AutoGen v0.3 用 `GroupChat`，CrewAI 用 `allow_delegation`。2025–2026 这一年，这些临时方案全部坍缩进了三个稳定的原语形态： | 原语 | 控制权 | 上下文 | 代表实现 | |------|--------|--------|----------| | **Handoff（交接）** | 永久转移，不返还 | 整段历史透传 | OpenAI Agents SDK、Google ADK transfer | | **Agent-as-Tool（智能体即工具）** | 调用即返还 | 仅传入参数，结果回灌 | Strands、PydanticAI、Mastra | | **Sub-graph（子图/嵌套）** | 显式 goto + return | 共享状态对象 | LangGraph、AutoGen nested team | 这个三分法是 2026 选型的真正起点：你需要的不是「哪个框架更强」，而是「我的任务该用哪种委派语义」。 ## 二、六栈委派原语多维对比 | 框架 | 委派原语 | 控制返还 | 路由方式 | 首个 Agent 耗时 | 语言 | 2026 定位 | |------|----------|----------|----------|------------------|------|-----------| | OpenAI Agents SDK | `handoffs` / agents-as-tools | 交接不返还 / 工具返还 | LLM 驱动 | ~5 min | Python/Node | 轻量 SDK 事实标准 | | Google ADK | `sub_agents` + transfer | 一次性子代理 | LLM 编排器 | ~10 min | Python | Gemini/云原生 | | Microsoft AutoGen v0.4 | 嵌套 team / `hand_off` | 显式 run 返回 | 轮询/选择器 | ~15 min | Python/.NET | 异步事件驱动 | | LangGraph | `Command(goto=)` + 子图 | 显式 goto 回流 | 图确定性 | ~25 min | Python/JS | 生产可控 | | CrewAI | `handoff()` / 委派工具 | 双向委派 | 角色层级 | ~8 min | Python | 业务流脚手架 | | AWS Strands | agent-as-tool | 调用即返还 | 模型驱动 | ~4 min | Python | 极简、模型优先 | > 注：首个 Agent 耗时指从 `pip install` 到跑通一个能委派给子智能体的示例，社区基准与文档实测中位数。 ## 三、深度实测 ### 1. OpenAI Agents SDK：Handoff 原语的命名者 OpenAI 把 Swarm 实验里朴素的 `transfer_to_agent` 提炼成了 SDK 的一等公民，并借 Assistants API 将于 2026 年 8 月 26 日退场的窗口，把它推成了事实标准。SDK 只暴露极少原语：Agent、Tool、Handoff、Guardrail、Runner，加上内建 trace。委派有两种姿态，且语义泾渭分明。 ```python from agents import Agent, Runner billing = Agent(name="Billing", tools=[lookup_invoice], handoffs=[refund]) triage = Agent( name="Triage", instructions="先判断意图，需要查账就交给 Billing", handoffs=[billing], # 永久交接，不返还 ) # 也可以把 billing 当工具调用，结果回灌、控制返还 triage_with_tool = Agent( name="Triage2", tools=[billing.as_tool(tool_name="ask_billing")], ) print(Runner.run_sync(triage, "我的发票在哪？").final_output) ``` 关键区别：`handoffs=[billing]` 一旦触发，控制权**整段转移**给 billing，Triage 退出舞台，对话历史原样透传；`billing.as_tool()` 则把 billing 压成一个函数调用，只传参数、拿结果、控制回到主代理。前者适合「分诊后不再回头」的客服流，后者适合「咨询一下再用」的编排流。**优点**：原语极少、心智负担低、trace 开箱即用、流式事件类型完备；**缺点**：handoff 不返还设计在复杂回环里会逼你退回 agent-as-tool，缺乏显式状态图，长程任务的可视化弱于 LangGraph。**变现**：原语少＝教学曲线平，是做「OpenAI 官方 Agent 训练营」最佳基底，但同时也意味着差异化只能拼工程，不拼框架。 ### 2. Google ADK：Sub-agents 与 LLM 编排器 Google ADK 把委派建模成一棵 `sub_agents` 树：根代理（通常是 LLM 编排器）按意图把请求转给叶子代理，叶子代理执行完一次性返回。它没有 OpenAI 那种「永久 handoff」的概念，更接近「显式函数路由 + 嵌套调用」，但路由决策本身交给一个 LLM orchestrator，所以它既是图、又不完全确定。 ```python from google.adk import Agent refund = Agent(name="refund", model="gemini-2.5-pro", tools=[process_refund]) billing = Agent(name="billing", model="gemini-2.5-pro", tools=[lookup_invoice], sub_agents=[refund]) triage = Agent( name="triage", model="gemini-2.5-pro", sub_agents=[billing], description="根编排器：按意图路由到子代理", ) ``` `sub_agents` 树让 ADK 天然适合「职能分层的客服中心」：退款挂在账务下，账务挂在分诊下，权限和上下文沿树下沉。**优点**：与 Vertex AI / Gemini 深度绑定，内置 eval、session、artifact，企业级工具链最全；**缺点**：树结构对「需要反复横跳」的任务不友好，LLM 编排器带来路由不确定性，强 Gemini 锁定。**变现**：适合面向 GCP 客户的私有化交付，但教学受众被云生态圈死。 ### 3. Microsoft AutoGen v0.4：异步事件驱动的嵌套团队 AutoGen 在 v0.4 完成了从「同步对话」到「异步事件流」的重写，这是六个框架里架构最彻底的一个。它不再把多智能体建模成对话，而是建模成一组订阅事件、彼此发消息的 actor，团队（Team）是顶层编排单元。 ```python import asyncio from autogen_agentchat.agents import AssistantAgent from autogen_agentchat.teams import SelectorGroupChat from autogen_agentchat.conditions import TextMentionTermination researcher = AssistantAgent("researcher", model_client=client, tools=[web_search]) writer = AssistantAgent("writer", model_client=client) team = SelectorGroupChat( participants=[researcher, writer], model_client=client, # 选择器模型决定下一个发言者 termination_condition=TextMentionTermination("APPROVED"), ) asyncio.run(team.run(task="写一篇 6G 太赫兹综述")) ``` `SelectorGroupChat` 用一个选择器模型决定下一棒，等价于「动态 handoff」；`RoundRobinGroupChat` 是确定性轮询；嵌套 team 则让一个团队的输出成为另一个团队的输入，实现层级委派。**优点**：真正异步、可横向扩展、事件流天然可观测、人机协同（UserProxy）成熟；**缺点**：概念多（agent/team/condition/termination/model_client），首个能跑的团队要 15 分钟，调试链路长。**变现**：研究型、需要复杂辩论/共识场景的最佳载体，但对训练营新手偏重。 ### 4. LangGraph：图确定性的回归 当其他框架都在让 LLM 决定路由时，LangGraph 走了一条反向路：把 Agent 编排画成显式状态图，节点是 Agent/函数，边是条件路由，`Command` 对象既更新状态又控制跳转。它的委派原语是「子图 + goto」。 ```python from langgraph.graph import StateGraph, START, END from langgraph.types import Command def supervisor(state): if state["intent"] == "billing": return Command(goto="billing", update={"handed": True}) return Command(goto="END") g = StateGraph(dict) g.add_node("supervisor", supervisor) g.add_node("billing", billing_agent) g.add_node("refund", refund_agent) g.add_conditional_edges("supervisor", lambda s: s.get("next")) g.add_edge("billing", "supervisor") # 子图执行完显式回流 app = g.compile() ``` `Command(goto=...)` 让控制权可以精确地「转过去再转回来」，这是 OpenAI handoff 做不到的；子图可以嵌套编译，状态对象在节点间显式流转，每个跳转都可审计。**优点**：路由可确定、可回放、可持久化（checkpoint）、HITL 插桩最干净；**缺点**：心智模型最重，图写错容易死循环，过度工程化的小任务性价比低。**变现**：生产级、受监管、需要审计回溯的复杂流程首选，是六栈里唯一能直接交付给金融/医疗的。 ### 5. CrewAI：角色委派的业务脚手架 CrewAI 不追求架构纯粹，它把多智能体包装成「船员 + 任务」的隐喻，委派挂在角色上，开箱即用面向业务流。它的 `handoff()` 是六栈里唯一支持双向委派的——A 可以委派给 B，B 完成后控制权回到 A。 ```python from crewai import Agent, Task, Crew, Process researcher = Agent(role="Researcher", goal="收集资料", backstory="资深分析师", tools=[search]) writer = Agent(role="Writer", goal="撰写初稿", backstory="技术作者", allow_delegation=True) crew = Crew( agents=[researcher, writer], process=Process.hierarchical, # 自动引入 manager 调度 tasks=[Task(description="写综述", expected_output="md", agent=writer)], ) result = crew.kickoff() ``` `Process.hierarchical` 会自动塞入一个 manager 负责分发任务；`allow_delegation=True` 让 writer 可以把子任务回委给 researcher。**优点**：业务隐喻直观、角色驱动、与外部工具（文件、搜索）集成度高，8 分钟可出 demo；**缺点**：架构黑盒，路由完全交给 LLM 难以审计，复杂分支容易失控，企业级可观测弱于 LangGraph。**变现**：最适合包装成「销售/内容/研究自动化训练营」，故事性强、上手快，但生产天花板低。 ### 6. AWS Strands Agents：agent-as-tool 的极简模型 Strands 是 AWS 2025 推出的极简 SDK，主打「模型优先、代码最少」。它没有独立 handoff 关键字，而是把委派统一成 agent-as-tool：把一个 Agent 注册成另一个 Agent 的工具，调用即返还，控制权永不丢失。这是六个框架里对「委派」最克制的设计。 ```python from strands import Agent, tool @tool def web_search(query: str) -> str: ... researcher = Agent(model="us.anthropic.claude-3-7", tools=[web_search]) @tool def ask_researcher(query: str) -> str: """委派给研究子代理，结果回灌，控制返还""" return str(researcher(query)) orchestrator = Agent(model="us.anthropic.claude-3-7", tools=[ask_researcher, write_draft]) print(str(orchestrator("写一篇综述"))) ``` Strands 的 agent loop 完全交给模型驱动，工具用原生函数签名 + docstring 描述，工具调用结果以 `Tool` 事件流入事件流。**优点**：代码量最少、4 分钟可跑、与 Bedrock 模型市场深度集成、抽象税极低；**缺点**：没有 handoff 原语意味着复杂任务编排要手写、确定性差、依赖模型的路由判断力。**变现**：极简＝适合做「一行代码起 Agent」的低门槛入门课，但深度有限。 ### 7. PydanticAI 与 Mastra：类型安全的两个极端 PydanticAI（Python）和 Mastra（TypeScript）代表「类型优先」流派。两者都不提供 handoff 关键字，而是用 agent-as-tool + 强类型结果来组织委派。PydanticAI 用 Pydantic 模型约束每个 Agent 的 `result_type`，工具签名直接成为 schema；Mastra 则把 ReAct agent 和 graph 工作流引擎合体，Agent 既可以自治循环，也可以作为图节点。 ```python # PydanticAI from pydantic_ai import Agent from pydantic import BaseModel class Invoice(BaseModel): id: str; amount: float billing = Agent("openai:gpt-4o", result_type=Invoice, system_prompt="只返回结构化发票") @billing.tool def lookup(ctx, id: str) -> Invoice: ... result = billing.run_sync("查 INV-001") result.data # 已校验的 Invoice 对象 ``` **优点**：编译期类型保障、结构化输出最可靠、适合需要 schema 强约束的金融/医疗接口；**缺点**：缺少一等委派原语，多智能体要手动拼。**变现**：面向重视类型与契约的工程团队（尤其 TS/Python 后端），是「工程化 Agent」课程的好素材。 ## 四、委派原语工作流 下图刻画三原语的运行时差异——同一句「查我的发票」在三种委派语义下，控制权与上下文的流向截然不同： ```mermaid flowchart LR User([用户:查发票]) --> Triage[分诊 Agent] subgraph Handoff["Handoff 原语 · 控制转移不返还"] H1[分诊] ==>|整段历史透传| H2[账务 Agent] H2 ==>|直接回复| HOut([用户]) end subgraph Tool["Agent-as-Tool 原语 · 调用即返还"] T1[分诊] -->|仅参数| T2[账务 子代理] T2 -->|结果回灌| T1 T1 --> TOut([用户]) end subgraph Graph["Sub-graph 原语 · 显式 goto/return"] G1[分诊] -->|Command goto| G2[账务子图] G2 -->|状态回流| G1 G1 -.必要时.-> G3[退款子图] G3 --> GOut([用户]) end Triage --> Handoff Triage --> Tool Triage --> Graph classDef kw fill:#2d6a4f,color:#fff,stroke:#1b4332 classDef rt fill:#e9ecef,color:#000,stroke:#adb5bd class Triage,H1,H2,T1,T2,G1,G2,G3 kw class User,HOut,TOut,GOut rt ``` 三条路径的取舍一目了然：**Handoff** 把后续全部甩给子代理，主代理下线，适合「分诊即转交」；**Agent-as-Tool** 主代理始终在线、按需咨询，适合「主从编排」；**Sub-graph** 在确定图结构里精确跳转并回流，适合「可审计的长流程」。框架选型，本质上是在这三条路径里选你的默认值。 ## 五、收敛背后的三处分歧 原语虽收敛，六栈在三处细节上互不兼容，构成迁移与选型的红线： **第一，控制返还语义。** OpenAI handoff 一旦触发不返还，要回流只能退回 agent-as-tool；LangGraph 的 `Command(goto=)` 支持任意回流；CrewAI 双向委派；ADK 子代理一次性返回。这意味着把一个 OpenAI handoff 流程迁到 LangGraph，必须重写控制流，不能简单平移。 **第二，上下文传递。** Handoff 整段历史透传（token 成本随对话线性增长）；agent-as-tool 只传参数；LangGraph 走显式状态对象。长对话里，handoff 的上下文膨胀会显著拉高成本，这是客服场景常被忽略的隐性税。 **第三，路由确定性。** LangGraph 走确定性条件边，路由可回放；OpenAI/Strands/CrewAI/ADK 全部 LLM 驱动，路由每次可能不同。受监管行业（金融、医疗）几乎只能选 LangGraph 的确定性路径，这是它生产壁垒的来源。 ## 六、场景化推荐 - **客服分诊转交（一次性）**：OpenAI Agents SDK 的 `handoffs` 或 ADK 的 `sub_agents`，控制一去不返最省 token。 - **研究/写作主从编排**：Strands 或 Mastra 的 agent-as-tool，主代理始终掌控全局，结果回流再决策。 - **受监管长流程（金融/医疗）**：LangGraph 的显式图 + `Command(goto=)`，确定性路由可审计、可回放、可 checkpoint。 - **多智能体辩论/共识**：AutoGen v0.4 的 SelectorGroupChat，异步事件流 + 选择器模型。 - **业务流快速原型/训练营**：CrewAI 的角色隐喻，8 分钟出 demo，故事性最强。 - **类型契约优先（接口/后端）**：PydanticAI 或 Mastra，schema 强约束降低对接成本。 一句话决策：**任务需要「永不回头的分诊」选 handoff 类（OpenAI/ADK），需要「按需咨询的主从」选 agent-as-tool 类（Strands/PydanticAI/Mastra），需要「可审计的回流」选 sub-graph 类（LangGraph）**——框架不是选最强的，而是选那条与你委派语义最贴合的默认路径。 ## 参考来源 1. [OpenAI Agents SDK 官方文档](https://openai.github.io/openai-agents-python/) — 原语定义（Agent/Tool/Handoff/Guardrail）与 streaming 事件流 2. [OpenAI Agents SDK: Architecture Patterns 2026 | APIScout](https://apiscout.dev/guides/openai-agents-sdk-architecture-patterns-2026) — handoff vs agent-as-tool 模式与 Assistants API 退场时间线 3. [AI Agents SDK Comparison 2026: Strands vs OpenAI SDK vs Mastra](https://baeseokjae.github.io/posts/ai-agents-sdk-comparison-2026/) — 厂商 SDK 架构对比与模型驱动 vs 代码驱动 4. [AI Agent Frameworks 2026 Deep Dive — youngju.dev](https://www.youngju.dev/blog/culture/2026-05-16-ai-agent-frameworks-langchain-langgraph-llamaindex-crewai-autogen-pydanticai-mastra-dspy-mcp-2026-deep-dive.en) — 2026 年 5 月市场全景与份额 5. [Agent SDK Platform Wars 2026 | agentmarketcap.ai](https://agentmarketcap.ai/blog/2026/04/07/agent-sdk-platform-wars-anthropic-openai-google-adk-aws-bedrock) — Anthropic/OpenAI/Google ADK/AWS Bedrock 选型矩阵 --- > 本文由「51学通信」原创出品，关注站长「爱卫生」（微信：gprshome201101）获取更多 AI Agent 与通信技术实战拆解。 > [!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 等场景全覆盖。