# 委派即失控：子智能体委派四栈实测 ## 概述 当一个自主智能体（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 Agent SDK：纯净隔离与单点回传 Claude 的 subagent 走的是**最纯净的隔离路线**。每个 subagent 拥有独立的上下文窗口、独立的系统提示、独立的工具白名单，执行结束后**只把最终结果文本**回传给父级，中间的思考、工具调用、读到的文件内容全部不进父级上下文。 这种设计的好处是上下文保护极强——父级不会被子体探索过程中产生的几千行 Grep/Read 输出污染，长任务能保持窗口干净。官方建议也正源于此："用子体做研究、并行探索、独立审查，把脏活隔离掉。" ```python # Claude Agent SDK：委派只回传最终文本 result = agent.run( "审查 src/auth/ 下的鉴权逻辑，找出越权风险", subagents=[code_review_agent] # 子体独立上下文，独立工具集 ) # result 只含子体最终结论，不含其探索过程 ``` 但它也埋下了最深的失控点：**单点回传 + 零继承**。有个被广泛引用的生产案例：系统给子体塞了 25000 token 的上下文，子体消化后只合成出约 8000 token 的发现回传——也就是说，**超过三分之二的上下文在委派边界被永久丢弃**。如果父级下一步的推理依赖被丢弃的那部分，它根本无从知晓自己缺了什么。 实测建议：用 Claude subagent 时，**prompt 必须明确要求子体"返回结构化结论 + 关键证据引用 + 不确定项"**，把单点回传的信息密度逼到最高，否则父级拿到的就是一份"自信但残缺"的报告。 ## 三、OpenAI Agents SDK：handoff 与 agents-as-tools 的双模 OpenAI 是四栈里唯一**内置两种委派语义**的，也是最容易踩坑的。它把"让渡控制权"做成了两个截然不同的开关： **handoff（交接）**——彻底让渡。SDK 为每个 handoff 自动生成一个特殊工具，父级一旦调用，**整个对话控制权连同全部历史一起转交给子体**，父级退场，子体接管直到完成。这是"失声"的重灾区：交接之后父级连"暂停、改方向、补充信息"的入口都没有了。 **agents-as-tools（智能体即工具）**——委派但保留控制。父级把子体当成普通工具调用，传入 `inputType` 描述的参数，子体算完**返回一个结构化值**，父级继续主导。这才是大多数生产场景真正想要的"委派"。 ```python # 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：子图与状态通道的显式契约 LangGraph 的 subgraph 是四栈里**最像函数调用**的——但它把"参数传递"升级成了**显式的状态契约**，这反而是最工程化的设计。 子图可以有自己独立的状态 schema，与父图完全解耦；父图调用子图时，需要提供一个**转换函数**把父状态映射成子状态，子图跑完再把结果写回父状态的共享 channel。 ```python # 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：嵌套会话与群聊中的委派淹没 AutoGen 的委派建立在**对话之上**。它的 nested chat 把一个子任务包装成一段独立会话，由一组角色（coder、reviewer、executor）协作完成，再把会话结论带回去；GroupChat 则把多个 agent 放进同一个聊天室，靠一个 manager agent 做路由委派。 ```python # 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 预算上限，禁止无界递归委派（子体不能再无限制地生子体）。 ## 委派控制权流转图 ```mermaid flowchart TD P[父级智能体] -->|① 显式传上下文/参数| D{委派边界} D -->|Claude: 零继承 prompt| C1[子体盲飞风险
失联] D -->|OpenAI handoff: 全量交接| C2[父级退场
失声] D -->|LangGraph: 状态映射| C3[schema 静默丢字段] D -->|AutoGen: 群聊淹没| C4[摘要漏关键约束
失真] 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 走向生产的最后一公里。 ## 参考来源 1. [The AI Swarm Tax: Why Multi-Agent Workflows Cost 3-10x More](https://agentmarketcap.ai/blog/2026/04/23/multi-agent-token-economics-cost-multiplication) — 多智能体 token 经济学，量化 3-10 倍成本倍增的成因 2. [Subagents in the SDK – Claude Code Docs](https://code.claude.com/docs/en/agent-sdk/subagents) — Claude subagent 的隔离上下文、工具白名单与单点回传机制官方说明 3. [Handoffs – OpenAI Agents SDK](https://openai.github.io/openai-agents-python/handoffs/) — handoff 与 agents-as-tools 两种委派语义的官方定义 4. [Subgraphs – LangGraph Docs](https://docs.langchain.com/oss/python/langgraph/use-subgraphs) — 子图状态通道、显式状态映射与可独立 schema 的工程契约 5. [Why Multi-Agent LLM Systems Fail (41-86%) – FutureAGI](https://futureagi.substack.com/p/why-do-multi-agent-llm-systems-fail) — 多智能体生产失败率统计与协调缺口归因 > [!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 等场景全覆盖。