Agent框架委派原语收敛实测

到 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 这一年，这些临时方案全部坍缩进了三个稳定的原语形态：

这个三分法是 2026 选型的真正起点：你需要的不是「哪个框架更强」，而是「我的任务该用哪种委派语义」。

二、六栈委派原语多维对比

三、深度实测

1. OpenAI Agents SDK：Handoff 原语的命名者

原语	控制权	上下文	代表实现
Handoff（交接）	永久转移，不返还	整段历史透传	OpenAI Agents SDK、Google ADK transfer
Agent-as-Tool（智能体即工具）	调用即返还	仅传入参数，结果回灌	Strands、PydanticAI、Mastra
Sub-graph（子图/嵌套）	显式 goto + return	共享状态对象	LangGraph、AutoGen nested team

框架	委派原语	控制返还	路由方式	首个 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	极简、模型优先

OpenAI 把 Swarm 实验里朴素的 transfer_to_agent 提炼成了 SDK 的一等公民，并借 Assistants API 将于 2026 年 8 月 26 日退场的窗口，把它推成了事实标准。SDK 只暴露极少原语：Agent、Tool、Handoff、Guardrail、Runner，加上内建 trace。委派有两种姿态，且语义泾渭分明。

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，所以它既是图、又不完全确定。

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）是顶层编排单元。

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」。

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。

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 的工具，调用即返还，控制权永不丢失。这是六个框架里对「委派」最克制的设计。

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 既可以自治循环，也可以作为图节点。

# 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」课程的好素材。

四、委派原语工作流

下图刻画三原语的运行时差异——同一句「查我的发票」在三种委派语义下，控制权与上下文的流向截然不同：

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 的确定性路径，这是它生产壁垒的来源。

六、场景化推荐

一句话决策：任务需要「永不回头的分诊」选 handoff 类（OpenAI/ADK），需要「按需咨询的主从」选 agent-as-tool 类（Strands/PydanticAI/Mastra），需要「可审计的回流」选 sub-graph 类（LangGraph）——框架不是选最强的，而是选那条与你委派语义最贴合的默认路径。