当一个自主智能体（autonomous agent）把子任务甩给"子智能体"去办，看起来是在做分工，实质是在做一件极危险的事——主动让渡控制权。我们对 2026 年主流的四种委派实现做了横向实测：Claude Agent SDK 的 subagent、OpenAI Agents SDK 的 handoff / agents-as-tools、LangGraph 的 subgraph、AutoGen 的嵌套会话。结果指向同一个结论：委派不是免费的。子智能体一旦离开父级上下文，就会在失联、失真、失声、失控四个点上把父级的判断力一点点掏空。业界数据显示多智能体在生产中的失败率高达 41%–86%，成本是单智能体的 3–10 倍——这笔账，几乎都记在"委派"头上。本文拆解四栈各自的控制权模型，给出"什么时候该委派、什么时候必须自己做"的实战判据。
| 框架 | 委派原语 | 上下文如何进入子体 | 结果如何回到父级 | 最易失控的点 |
|---|---|---|---|---|
| Claude Agent SDK | Task / subagent |
零继承：干净上下文，仅靠 prompt 显式传入 | 仅回传最终文本摘要 | 父级忘了传关键信息→子体盲飞 |
| OpenAI Agents SDK | handoff / agents-as-tools | handoff 全量接管；as-tools 仅传 inputType 参数 | handoff 不返回；as-tools 回传结构化值 | handoff 后父级彻底失去发言权 |
| LangGraph | subgraph | 状态通道显式映射（可完全独立） | 通过共享 channel 写回父状态 | 状态 schema 不匹配→静默丢失字段 |
| AutoGen | nested chat / GroupChat | 会话历史拼接传入 | 子体在群里发消息即"返回" | 结果淹没在对话流中，父级难裁剪 |
很多人把"委派子智能体"理解成函数调用——child = spawn(); result = child.run(task)。但实测四栈后你会发现，它和函数调用有本质区别：函数调用让渡的是计算，而委派让渡的是三样不可见的东西。
第一是上下文。函数运行在调用者的作用域里，能看见所有局部变量；子智能体运行在自己的上下文窗口里，默认什么也看不见。Claude 文档用一句话点破这件事："子智能体看不到父级的任何东西，必须显式传入。"我们见过一个真实案例：父级让子体"分析这个文件里的错误"，却没在 prompt 里写文件路径，子体只好重新 Glob/Grep 自己找，不仅多烧了 token，还因为路径解析方式不同找错了文件。
第二是判断权。一旦子体开始执行，父级对"它怎么做"几乎没有干预手段。OpenAI 的 handoff 模式最为彻底——它把整个会话控制权交给子体，父级连继续说话的机会都没有，直到子体主动交还。
第三是验证权。子体返回什么，父级就得信什么。子体读了 2000 行代码、跑了测试、做了推理，最后只回传 3 句话结论——父级无法复查它的中间过程，只能基于这 3 句话做下一步决策。这就是"失真"的根源。
记住这条判据：凡是你需要复查中间过程的子任务，就不该委派；凡是结论自洽、过程可丢弃的子任务，才适合委派。
Claude 的 subagent 走的是最纯净的隔离路线。每个 subagent 拥有独立的上下文窗口、独立的系统提示、独立的工具白名单，执行结束后只把最终结果文本回传给父级，中间的思考、工具调用、读到的文件内容全部不进父级上下文。
这种设计的好处是上下文保护极强——父级不会被子体探索过程中产生的几千行 Grep/Read 输出污染，长任务能保持窗口干净。官方建议也正源于此："用子体做研究、并行探索、独立审查，把脏活隔离掉。"
# Claude Agent SDK：委派只回传最终文本
result = agent.run(
"审查 src/auth/ 下的鉴权逻辑，找出越权风险",
subagents=[code_review_agent] # 子体独立上下文，独立工具集
)
# result 只含子体最终结论，不含其探索过程
但它也埋下了最深的失控点：单点回传 + 零继承。有个被广泛引用的生产案例：系统给子体塞了 25000 token 的上下文，子体消化后只合成出约 8000 token 的发现回传——也就是说，超过三分之二的上下文在委派边界被永久丢弃。如果父级下一步的推理依赖被丢弃的那部分，它根本无从知晓自己缺了什么。
实测建议：用 Claude subagent 时，prompt 必须明确要求子体"返回结构化结论 + 关键证据引用 + 不确定项"，把单点回传的信息密度逼到最高，否则父级拿到的就是一份"自信但残缺"的报告。
OpenAI 是四栈里唯一内置两种委派语义的，也是最容易踩坑的。它把"让渡控制权"做成了两个截然不同的开关：
handoff（交接）——彻底让渡。SDK 为每个 handoff 自动生成一个特殊工具，父级一旦调用，整个对话控制权连同全部历史一起转交给子体，父级退场，子体接管直到完成。这是"失声"的重灾区：交接之后父级连"暂停、改方向、补充信息"的入口都没有了。
agents-as-tools（智能体即工具）——委派但保留控制。父级把子体当成普通工具调用，传入 inputType 描述的参数，子体算完返回一个结构化值，父级继续主导。这才是大多数生产场景真正想要的"委派"。
# OpenAI Agents SDK：两种语义截然不同
triage = Agent(name="分诊", handoffs=[billing_agent, tech_agent]) # 交接：父级退场
orchestrator = Agent(name="总调度",
tools=[research_agent.as_tool(tool_name="research",
tool_description="做联网调研",
custom_output_extraction=lambda ctx: ctx["findings"])]) # 委派：父级主导
实测发现两者的成本曲线完全不同：handoff 因为全量历史搬运，单次交接的输入 token 接近父级整个会话长度；agents-as-tools 则只搬参数，token 增量可控。一个常见的翻车是把本该用 as-tools 的"调研子任务"误配成 handoff，结果每次委派都重新编码几万 token 历史，成本直接翻几倍。
判据：需要父级后续继续推理的，用 agents-as-tools；明确是"交给专家收尾、父级不再插手"的，才用 handoff。 现场多数误用，都是把 handoff 当成了通用的委派按钮。
LangGraph 的 subgraph 是四栈里最像函数调用的——但它把"参数传递"升级成了显式的状态契约，这反而是最工程化的设计。
子图可以有自己独立的状态 schema，与父图完全解耦；父图调用子图时，需要提供一个转换函数把父状态映射成子状态，子图跑完再把结果写回父状态的共享 channel。
# LangGraph：委派即状态映射契约
def parent_to_child(state: ParentState) -> ChildState:
return {"query": state["question"], "history": state["summary"]} # 显式裁剪
def child_to_parent(state: ChildState) -> ParentState:
return {"findings": state["result"]} # 显式回写
graph.add_node("delegate", subgraph.transform(parent_to_child, child_to_parent))
这种"显式契约"的优势是可追溯、可测试——你能精确知道子图收到了什么、回了什么，不像会话式框架那样全靠 prompt 模糊传递。劣势是极易因 schema 不匹配而静默丢字段：父图某个 channel 名拼错、或转换函数漏映射一个字段，子图会拿不到数据，但不会报错，只会用空值安静地跑出一个错误结果。这正是"失声"在 LangGraph 里的变体——错误被类型系统的灵活性吞掉了。
实测建议：给每个子图配输入校验断言，在 parent_to_child 里强制检查关键字段非空，把"静默丢失"变成"显式失败"。
AutoGen 的委派建立在对话之上。它的 nested chat 把一个子任务包装成一段独立会话，由一组角色（coder、reviewer、executor）协作完成，再把会话结论带回去；GroupChat 则把多个 agent 放进同一个聊天室，靠一个 manager agent 做路由委派。
# AutoGen：把委派包装成一段嵌套会话
nested = {"recipient": team, "message": "重构这段鉴权代码",
"summary_method": "reflection_with_llm"} # 关键：摘要方法
user_proxy.register_nested_chats([nested], trigger=lambda _: True)
AutoGen 的失控点最特别——结果淹没。子任务在群里产生几十轮对话，最后靠 summary_method 压缩成一段摘要回传。摘要质量直接决定父级能看到什么：last_msg 只给最后一句话，reflection_with_llm 会再花一次 LLM 调用做总结。如果摘要漏掉了关键约束（比如"reviewer 指出这里有 SQL 注入风险"），父级拿到的是一份"干净但危险"的成品。
更深的问题是角色越权：群聊里任何一个 agent 都可能不经 manager 直接插话，父级设想的"委派给 coder"实际上变成了"coder、reviewer、executor 各自发挥"，控制权在对话流中悄然分散。
把四栈放在一起测，失控收敛为四种可复现的失效模式，每种都有明确的成因和对策。
① 失联（context drop）——子体拿不到关键信息。Claude 最典型：零继承设计下，父级 prompt 漏传路径/约束/上下文，子体就盲飞。对策：把委派 prompt 当成"远程函数签名"写，参数化、必填化，宁可啰嗦。
② 失真（result distortion）——子体回传的摘要丢了关键数据。Claude 的单点回传和 AutoGen 的 summary_method 都是重灾区。对策：强制子体返回结构化 JSON + 证据引用 + 不确定项声明，而不是自由文本。
③ 失声（silent error）——子体失败，父级继续。OpenAI agents-as-tools 把子体失败变成一段错误文本而非异常；LangGraph 的 schema 不匹配静默丢字段；AutoGen 的角色越权悄无声息。对策：在委派边界强制做成功/失败校验，把"看起来成功"变成"确实成功"。
④ 失控（cost blowup）——token 倍增。多智能体成本是单体的 3–10 倍，嵌套委派会指数级放大。Stanford 的 DeLM 方案证明，去掉中心化编排、改用去中心化协调可省约 50% 推理成本。对策：给每次委派设 token 预算上限，禁止无界递归委派（子体不能再无限制地生子体）。
flowchart TD
P[父级智能体] -->|① 显式传上下文/参数| D{委派边界}
D -->|Claude: 零继承 prompt| C1[子体盲飞风险<br/>失联]
D -->|OpenAI handoff: 全量交接| C2[父级退场<br/>失声]
D -->|LangGraph: 状态映射| C3[schema 静默丢字段]
D -->|AutoGen: 群聊淹没| C4[摘要漏关键约束<br/>失真]
C1 & C2 & C3 & C4 --> R[单点回传结果]
R -->|无中间过程可复查| P
R -.->|token 倍增 3-10x| COST[成本失控]
style C1 fill:#ffd6d6
style C2 fill:#ffd6d6
style C3 fill:#ffe9d6
style C4 fill:#ffd6d6
style COST fill:#ffd6d6
场景一：长任务探索（代码审查、资料调研、并行搜索）——首选 Claude Agent SDK 的 subagent。它的纯净隔离最适合"过程可丢弃、只要结论"的任务，但务必把委派 prompt 写成参数化签名，并强制结构化回传。
场景二：明确分工的流水线（分诊→专家收尾）——首选 OpenAI Agents SDK，且只在"父级不再插手"时用 handoff，其余一律 agents-as-tools。绝大多数翻车都源于把 handoff 当通用委派按钮。
场景三：需要强工程契约、可测试、可回放——首选 LangGraph subgraph。显式状态契约让委派变成可调试的函数调用，代价是要为每个子图写转换函数和输入校验断言。
场景四：复杂协作、需要多角色辩论——首选 AutoGen nested chat，但必须锁定 summary_method 为 reflection_with_llm，并限制群聊角色的发言权限，防止结果淹没和角色越权。
通用红线：无论哪个栈，都给委派配三道闸——上下文必填校验、结果结构化回传、token 预算上限。把"让渡控制权"变成"有边界的让渡"，是自主智能体从 demo 走向生产的最后一公里。
[!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 等场景全覆盖。