子智能体模式对比

深入解析 · 多智能体系统

三个框架里 sub-agent / handoff / agent-as-tool 的差异，都映射到同一个底层问题——谁拥有轨迹——回答它就决定了你要哪种形态。

LangGraph 有 supervisor、层级、协作三种图。OpenAI Agents SDK 提供 handoff 与 agent-as-tool。deepagents 有 sub-agent。各家词汇掩盖的是同一个底层差异：控制权交出去后，谁拥有轨迹。Handoff 完全交出去；agent-as-tool 保留；supervisor 委派后回收。为任务选错形态，就会要么丢失上下文（handoff 到专家智能体，专家再也不回来），要么把上下文预算烧穿（agent-as-tool 把完整会话记录塞回来）。本文把三套词汇对齐到那唯一重要的一根轴上，再走一遍每种形态藏着的失败模式。

STEP 1

三家厂商，三套词汇，底下是同一批原语。

词汇混乱是第一笔税。LangGraph 的 supervisor 图是一个协调者节点，向工作者节点派发并在其返回时收回控制权；层级图把 supervisor 嵌套；协作图允许对等体互相路由，没有中心所有者。OpenAI 的 Agents SDK 把空间压到两个原语：handoff——控制权转给另一个智能体，由它继续面向用户的对话；agent-as-tool——一个智能体像调用任何工具那样调用另一个，收到返回值后自己继续。deepagents 把 sub-agent 打包为"上下文隔离的委派工作者"，由始终掌控计划的"主"智能体派发。

vocabulary map                       trajectory ownership      return semantics
─────────────────────────────────────────────────────────────────────────────
LangGraph supervisor      →          caller keeps it           structured worker result
LangGraph hierarchical    →          per-subtree owner         summary up each level
LangGraph collaborative   →          transfers on each hop     whichever peer holds it
OpenAI SDK handoff        →          callee takes it           conversation continues there
OpenAI SDK agent-as-tool  →          caller keeps it           tool-shaped return value
deepagents sub-agent      →          main agent keeps it       filtered artifact only

把三套词汇叠一起就能看出来：LangGraph supervisor、OpenAI agent-as-tool、deepagents sub-agent 是同一个原语的三个名字——调用方保留轨迹的委派。LangGraph collaborative 与 OpenAI handoff 是同一个原语的两个名字——完整的轨迹转移。LangGraph hierarchical 就是 supervisor/worker 嵌套一层，关于"这多出来的一跳何时值那份有损摘要"，多智能体拓扑一文已经讲过。六个词里真正在变的差别，只有"下一轮由谁持有轨迹"。

STEP 2

轨迹所有权就是那根轴；其余所有取舍都由它决定。

"轨迹"指的是当前正在进行的对话状态、用户尚未消化的期待，以及"生成下一条用户可见回复"的责任。如果调用方保留轨迹，被调用方就是子例程：在自己的作用域内运行、返回一个值，调用方继续拼装自己的答案。如果被调用方接过轨迹，调用方就结束了——这一回合它的上下文不再被查阅（往往从此不再查阅），它维系的任何推理线索都会消失，除非显式记下来。

其他人们争论的一切——上下文共享、工具可见性、预算核算、追踪——都是所有权的下游。调用方保留式委派让调用方能在入口过滤子智能体看到什么、在出口过滤它回传什么；子智能体自身的推理轨迹留在其作用域内。轨迹转移式委派把调用方拥有的（或其副本）交给被调用方，并且不期待有回程——被调用方现在就是那位对用户说话的人。你想要哪一种，等价于你能吸收哪种失败：丢失调用方的计划，还是丢失被调用方的专业推理。

STEP 3

Handoff 藏着回程问题：控制权干净转出去了，往往并不能干净地回来。

Handoff 的诱人形态是"路由到懂这类事的专家智能体"。退款相关问题去退款智能体、账单相关问题去账单。剧本化流程里这行得通。但在智能体化流程里，第一个模糊案例就会失手：专家做完了事，需要把控制权交回给某人，可"回给谁"是欠定义的。路由器要不要重新评估？专家要不要返回一个状态对象让路由器解析？还是对话就在专家这一回合结束了？各家框架给一个默认，每个默认都打破某种情况——OpenAI SDK 默认在接收方结束对话，除非接收方自己再 handoff，于是就会出现"卡在专家上"的会话：用户问一个与退款无关的后续问题，仍然拿到一个退款答案。

Handoff 的另一种失败在于上下文继承。若接收方继承完整对话，其自己的系统提示会与路由器已经建立的一切竞争——人设漂移、工具选择漂移，以及"中途换个人设"这种令用户困惑的 UX。若它什么都不继承，用户就得把上下文重述一遍。两者都不舒服。2026 年 handoff 的纪律是：传一份紧凑的 handoff 消息——路由智能体对"用户想要什么"以及"已确立的事项"的摘要——并显式定义回程升级路径，而不是指望接收方察觉自己应该再转出去。

STEP 4

Agent-as-tool 藏着上下文预算问题：返回值大到不像一个工具返回该有的样子。

Agent-as-tool 看起来更安全，因为调用方保留轨迹。失败模式出在被调用方回传的东西。一位花了 3 万 token 研究话题的专家智能体想把学到的东西交回去；朴素的返回就是完整会话记录，调用方随后把它并入自己的上下文。两次这样的调用后，调用方的上下文里塞满了子智能体的会话记录，而不是它本该执行的计划。团队上线一个"第 1 次跑好用"的 demo，然后发现"第 3 次上下文溢出"就是这个模式。

缓解办法是在调用方与被调用方之间画一条硬接口。子智能体的输入是一份限定范围的指令与"仅它需要的那点上下文"（不是调用方的完整状态）；子智能体的输出是一份结构化产物——摘要、发现清单、决定——不是会话记录。deepagents 把这做成默认：主智能体只看到子智能体过滤后的产物，看不到它的中间工作。LangGraph 的 supervisor 图通过显式定义 worker 返回类型达到同样的效果。OpenAI 的 agent-as-tool 默认返回被调用方最后一条消息，这也是为什么在其上做产品的团队最终都要写包装器"回传前先摘要"。上下文预算的一般规则——向上传的是紧凑的结构化产物，原始会话记录留在作用域内——正是让 agent-as-tool 在扇出下仍能存活的原因。

# Three shapes, one task: research a topic and write a summary.

# 1. Handoff (OpenAI SDK): trajectory transfers, no return.
@agent.handoff_to(research_agent)
def route(query): return handoff_message(intent="research", brief=query)

# 2. Agent-as-tool (OpenAI SDK / LangGraph supervisor):
#    caller keeps trajectory, callee returns a structured artifact.
@tool
def research(query: str) -> Findings:
    result = research_agent.run(query, budget=15_000)
    return result.to_artifact()   # NOT the full transcript

# 3. Sub-agent (deepagents): main agent dispatches with a scoped brief;
#    filtered artifact returns, intermediate reasoning stays isolated.
main.dispatch(sub="researcher", brief=query, success="3-bullet summary")

STEP 5

Supervisor 委派是真正能上线的形态；其上限就是 supervisor 自己。

LangGraph supervisor、deepagents 的 sub-agent，以及 OpenAI 的 agent-as-tool 在同一个操作模式上收敛：调用方拥有计划、把限定范围的子任务派发给工作者、并把工作者的回传汇合为一个连贯答案。supervisor/worker 一文对这一形态做了深入处理，而生产级多智能体系统反复落到的也是它。上限是通用的：在聚合时刻，supervisor 的上下文必须容纳"计划 + 每个 worker 的结构化结果"，其自身推理还两次落在关键路径上。当扇出超过一位 supervisor 能调和的上限时，就转层级——supervisor 的 worker 本身也是 supervisor——并有意接受多出来的那份有损摘要。

三套词汇在这里收敛，是因为"调用方保留式委派"是唯一能扛住真实负载的形态。Handoff 适合那种狭窄场景：轨迹确实应该在会话余下部分归属专家（路由进领域专家并留其把守整轮）；agent-as-tool 加结构化产物则是任务为"做这件专家的事、把结果交回给我"时你会伸手拿的东西。其余都是变体。

STEP 6

选择形态：两个问题就够。

问题一：被调用方的工作是"继续那段面向用户的对话"，还是"产出一个供调用方使用的结果"？继续对话 → handoff（LangGraph 协作、OpenAI handoff）。产出结果 → 调用方保留式委派（supervisor、agent-as-tool、sub-agent）。问题二，仅当你选了调用方保留式：被调用方的回传是否能装进一份"调用方一回合就读完"的结构化产物，还是调用方需要跨多回合与被调用方交互？一次性产物 → 带显式返回 schema 的 agent-as-tool。多回合 → 带中间状态检查点的 supervisor 图。若两个问题里任一个你说不清一句话，那么在框架选择还没开始之前，任务分解就已经错了。至于"要不要拆"本身是更上游的问题——为"多加一位智能体"付什么价，先看单智能体 vs 多智能体一文。一旦决定拆，形态就由轨迹所有权来选，其余一切随之而来。