「Subagent 和多 Agent 有什么区别」这个问题本身就问偏了——它们不是竞争方案，而是同一根轴上的三个刻度。轴的两端是：控制权在谁手里，信息怎么流动。

剥掉营销词汇，所有多 agent 架构只回答两个问题：

• 谁持有最终答案的所有权？——主管始终持有（subagent）、移交给专家（handoff）、还是分散给团队（agent teams）
• 信息走什么拓扑？——星型（一切经主管中转）、链式（对话整体移交）、网状（成员点对点直连）

OpenAI 在 Agents SDK 文档里把前两种说得很直白：agents-as-tools 模式下「主管保留答复所有权」，handoff 模式下「控制权转移给专家 agent」。而 Claude Code 2026 年推出的实验特性 Agent Teams 则补上了第三格——teammate 是完全独立的实例，互相直接发消息，甚至可以绕过 lead 私下协商。

本手册以三家一手资料为底：Anthropic 工程博客《How we built our multi-agent research system》（2025-06）、《When and how to use multi-agent systems》（2026）、Claude Code 官方文档 Agent Teams 章节、OpenAI 官方 Orchestration 文档。所有数字都来自官方原文。

Subagent 是 orchestrator-worker 模式的基本单元：主 Agent 把任务派出去，sub agents 在自己的独立上下文窗口里干活，跑完只有最终结论被传回——中间过程随销毁一起消失。

Orchestrator-worker（编排者-工人）是从分布式系统借来的经典架构：一个 orchestrator 拿着完整任务，负责拆解、派发、汇总；多个 worker 各领一块子任务，干完只交结果。MapReduce 的 master-slave、微服务里的任务队列，骨子里都是这个形状。LLM Agent 把它借了过来，只是「工人」从进程换成了上下文窗口：

• Orchestrator = 主 Agent：唯一持有全局上下文的角色，对用户始终保有最终答案的所有权
• Worker = sub agent：领到一段 prompt 和受限工具集，在自己的隔离上下文里自主执行，交付结论后即销毁

Anthropic 对它的价值有个精辟概括：搜索的本质是压缩。sub agents 并行探索海量信息，各自完成蒸馏，只把最重要的 token 送回主管。这就是 context isolation 的全部意义。

一次派发的完整生命周期

// ① 主 Agent 决定拆解：目标 + 输出格式 + 工具白名单 + 任务边界
const result = await Agent({
  subagent_type: "Explore",          // 预定义角色（受限工具集）
  prompt: "调查 auth 模块的登录流程，输出 ≤500 字结论",
});
// ② sub agents 启动：全新空上下文，只有这段 prompt + 角色的工具集
// ③ sub agents 自主循环调工具 N 轮 —— 中间结果全部留在它自己的上下文里
// ④ sub agents 结束：只有 final message 作为 tool result 返回主 Agent
// ⑤ sub agents 销毁，上下文释放；主 Agent 上下文只增加了一段结论

OpenAI Agents SDK 里的等价物叫 as_tool()：把一个专家 agent 包装成主管手里的一个普通工具调用。发起调用、拿到返回值、继续掌控对话——sub agents 从头到尾只是主管的「有界能力」（bounded capability），而不是对话的接管者。

真正的多 Agent 系统里，每个成员都是独立的长生命周期实例。关键差异不在「有几个 agent」，而在成员之间能不能点对点直接通信。

Claude Code 的 Agent Teams 是最好的官方标本。它由四个组件构成：

实现上非常「工程师味儿」：发送消息 = 成功写入对方的 JSON inbox 文件。任务依赖自动管理——某队友完成任务后，依赖它的任务自动解锁。没有消息总线，没有中间件，就是文件读写。

官方对照表（Claude Code Docs 原文翻译）

官方立场一句话：要快速专注的打工仔，用 subagent；要能互相讨论、互相挑战的真团队，用 agent teams。

from langchain.agents import create_agent
from langchain_openai import ChatOpenAI
from langgraph_supervisor import create_supervisor

model = ChatOpenAI(model="gpt-4o")

# ① 先造各领域专家：普通 agent，各带各的工具
research_agent = create_agent(
    model, tools=[web_search],
    name="research_expert",
    prompt="You are a researcher. Do not do any math.",
)
math_agent = create_agent(
    model, tools=[add, multiply],
    name="math_expert",
    prompt="You are a math expert.",
)

# ② supervisor 把每个 worker 注册成一个 handoff 工具，挂到主管自己手里
workflow = create_supervisor(
    [research_agent, math_agent],
    model=model,
    prompt="You are a team supervisor routing work to the right expert.",
    output_mode="last_message",   # worker 只回传最后一条消息（默认值）
    parallel_tool_calls=False,    # True = 主管可一轮并行派多个 worker
)
app = workflow.compile()

# ③ 控制权永远在 supervisor：worker 结果全部流回中心，由它答复用户
app.invoke({"messages": [
    {"role": "user", "content": "FAANG 2024 的总人数是多少？"},
]})

from langgraph.checkpoint.memory import InMemorySaver
from langchain.agents import create_agent
from langgraph_swarm import create_handoff_tool, create_swarm

# ① 转交工具的目标是彼此——没有中心节点
research = create_agent(
    model,
    tools=[web_search,
           create_handoff_tool(agent_name="math_expert")],
    name="research_expert",
)
math = create_agent(
    model,
    tools=[add,
           create_handoff_tool(agent_name="research_expert")],
    name="math_expert",
)

# ② active_agent 状态记住「现在谁活跃」，下一轮从 TA 继续
workflow = create_swarm(
    [research, math],
    default_active_agent="research_expert",
)
app = workflow.compile(checkpointer=InMemorySaver())  # 不带 checkpointer 会失忆

# ③ 第二轮请求直接命中上次的活跃 agent——省掉一次路由调用
app.invoke(
    {"messages": [{"role": "user", "content": "what's 5 + 7?"}]},
    {"configurable": {"thread_id": "1"}},
)

# langgraph_swarm/handoff.py —— 整个 swarm 的核心就是这一个返回值
@tool(f"transfer_to_{agent_name}")
def handoff_to_agent(state, tool_call_id):
    return Command(
        goto=agent_name,          # 图上直接跳到目标 agent 节点
        graph=Command.PARENT,     # 作用于父图（swarm 图），而非当前 agent 内部
        update={
            "messages": [state["messages"],
                         ToolMessage(f"Successfully transferred to {agent_name}")],
            "active_agent": agent_name,  # 记下「现在谁活跃」
        },
    )
# 下一轮请求进来时，add_active_agent_router 读 active_agent 直接路由——
# 这就是 swarm 重复请求比星型少跳的原因。

聊多 Agent 绕不开 OpenAI 的 handoff（交接）。它经常被误归进上面两类，但其实都不算：控制权交出去了（不是主从），但同一时刻只有一个活跃 agent（也不是团队）。

典型形态是客服分流：triage agent 判断意图后把整个对话移交给 billing 或 refund 专家，此后由专家直接面对用户，triage 不再参与。

Handoff 的限制也很明显：社区实践中 handoff 无法并行发生，一次只能交接一个专家，不适合需要并行跑工具的场景。OpenAI 文档给出的选型口诀：

• 专家应该接管对话分支 → handoff（控制权转移）
• 主管要合成最终答案、专家只做有界任务 → agents-as-tools（即 subagent）
• 成员需要互相讨论协商 → agent teams

Anthropic 公开了他们生产级多 agent 研究系统（Claude Research 功能背后）的核心指标——这是目前最有分量的一手证据。

结论很冷静：多 agent 不是银弹，是用 token 换覆盖面的架构。Anthropic 明确指出，编码任务比研究任务更少真正可并行的部分，LLM 实时协调委托又还不强，所以多 agent 目前最适合的是：高价值、重并行、信息量超单上下文窗口、需对接大量复杂工具的任务。

什么时候该拆，什么时候千万别拆

Anthropic 后续文章给出多 agent 一致优于 单 agent 的仅有的三种情况：

1. Context protection——子任务产生大量中间信息（>1000 token）但对主任务大部分无用。让 subagent 吃掉脏活，只回传几十 token 摘要。
2. Parallelization——广度优先的多方向探索。例：「列出标普 500 IT 板块所有公司董事会成员」，串行搜不完，必须分头并行。
3. Specialization——工具超过 15–20 个模型就选不准；不同任务需要互相冲突的系统提示词（共情客服 vs 严苛审查）；领域知识太深装不进通用 agent。

LangChain 的 Harrison Chase 给过一个好记的判断维度：Read 操作天然可并行适合多 agent；Write 操作耦合度高适合单 agent 收口。Anthropic 的研究系统就是典型——一堆 subagent 并行搜索阅读，报告由 lead 统一写。

不要先问「哪个框架最强」，先问控制权、信息流和上下文应该长什么样。先从下方最接近的场景反查，再用四道题确认边界。

六个高频场景，直接反查

把你的任务代入决策器

顺序有意设计成「用户控制权 → 并行与上下文 → 团队通信 → 可确定性」。只要前面的信号足够强，就不必为后面的能力付额外 token 账单。

全部出自上文与官方文档原文。答完看你是「架构明白人」还是「该回去复习」。