当多个智能体协作时，最贵的不是工具调用，而是控制权在智能体之间移动的那一瞬间——也就是"交接"（handoff）。2025年OpenAI把Handoffs做进Agents SDK的一等原语、AutoGen 0.4把Swarm的handoff称为"OpenAI引入的模式"、Google ADK用transfer_to_agent搭子智能体树，三家表面各异，内核却指向同一个被严重低估的成本中心：交接瞬间，下一个智能体到底看到多少上下文。本期沿着这条主轴实测六大主流框架，结论是交接上下文只有三种稳定形态——全量传递、折叠裁剪、隔离返回——而绝大多数框架默认落在最贵的那一态，且开发者几乎从不显式降档。
所谓"交接"，指一次运行（run）内，控制权从Agent A转移到Agent B时，B的输入窗口里被塞进了什么。看似一个细节，实则决定了多智能体链路的token成本曲线、保真度与安全边界。把所有框架的实现摊开，能精确归约到三态：
<CONVERSATION HISTORY>摘要。成本可控，但裁剪即丢信息。这三态不是抽象分类，而是六大框架的真实默认行为与可配置项。理解它们，就理解了多智能体"为什么这么烧钱"的根因。
| 框架 | 默认交接态 | 显式降档手段 | 链长成本曲线 | 控制粒度 |
|---|---|---|---|---|
| OpenAI Agents SDK（handoff） | 全量 | input_filter/nest_handoff_history/as_tool |
~O(K²) 无裁剪 | 极细（可按item过滤） |
| OpenAI Agents SDK（as_tool） | 隔离返回 | 内置即隔离 | O(1) | 中 |
| AutoGen 0.4 Swarm | 全量（共享会话） | 需手写裁剪/自定义handoff工具 | ~O(K²) | 粗 |
| LangGraph | 由共享state决定 | state里放messages=全量；放摘要=折叠；agent-as-tool=隔离 | 可控 | 极细（state schema） |
| CrewAI（Delegate Work） | 隔离返回 | 内置即隔离 | O(1) | 中 |
| Anthropic subagent（Task） | 隔离返回 | 内置即隔离 | O(1) | 中 |
| Google ADK（transfer_to_agent） | 全量/折叠（session state） | sub-agent树+session裁剪 | ~O(K)~O(K²) | 中 |
读表的关键发现：三态里只有"隔离返回"是天然省钱的，但它恰恰是信息损耗最大的；而最贵的"全量传递"是OpenAI handoff与AutoGen Swarm的默认。也就是说，两个最被推荐的多智能体协作范式，开箱即把开发者推向了最贵的一极，除非他们主动写裁剪代码。
OpenAI Agents SDK的Handoffs文档把默认行为写得非常直白：当交接发生，"新代理仿佛接管了会话，并能看到整段之前的对话历史"。在代码里，handoff被建模成一个工具（如transfer_to_refund_agent），LLM调用它之后，Runner把pre_handoff_items、new_items和input_history一并交给下一个agent。AutoGen 0.4的Swarm如出一辙——Swarm内的agents共享同一份会话上下文，handoff本质上只是把发言权交出去，历史并不重写。
这套设计的诱因是保真：B拿到A的全部推理与中间结果，不需要重新理解任务。代价是上下文随链长二次膨胀。考虑一条分诊→计费→退款→升级的四级handoff链：若不在每一跳裁剪，第四个agent的输入窗口里装着前三个agent各自的完整输出，加上用户原文。每多一跳，下游每个agent都要为前序历史付一次推理税。在100K窗口里这看似宽松，但每token都要过模型注意力，延迟与费用同步上行，且长历史会稀释关键信号——这是"全量"最隐蔽的隐性税：不是先爆窗口，而是先把信噪比拉低。AutoGen Swarm因共享同一份上下文，连"哪条消息属于哪个agent"都要靠speaker标签区分，链一长，串话与误归因的概率随之上升。
OpenAI显然意识到了全量的代价，因此给了两道显式裁剪闸门。第一道是input_filter——一个接收HandoffInputData（含input_history、pre_handoff_items、new_items、input_items、run_context）并返回新HandoffInputData的函数。SDK内置了常用模式，例如handoff_filters.remove_all_tools，会在交接瞬间把历史里所有工具调用剥离，只留文本：
from agents import Agent, handoff
from agents.extensions import handoff_filters
faq_agent = Agent(name="FAQ agent")
handoff_obj = handoff(
agent=faq_agent,
input_filter=handoff_filters.remove_all_tools, # 交接瞬间剥光工具调用
)
第二道是2025年转为opt-in beta的RunConfig.nest_handoff_history：开启后，Runner把交接前的整段对话折叠成一条assistant摘要消息，包进<CONVERSATION HISTORY>块，并在同一次run里多次交接时持续追加。若只想改包装文本而不写完整filter，可用RunConfig.handoff_history_mapper注入自定义映射函数。LangGraph走的是更显式的路子：交接"上下文"就是共享state（TypedDict），你往state里放messages就是全量、放摘要字段就是折叠、把子agent当tool调用就是隔离——裁剪决策被编码进state schema，而不是临时塞进运行时参数，可读性与可测试性都更高。
折叠态的权衡是压缩即损失。摘要丢掉了中间推理、工具返回的原始数据、边界条件；一旦后续agent需要回头核对某个具体数字，它只能凭摘要里的二次表述。这把多智能体系统推向了一个新的故障面：摘要幻觉在交接边界上传染——A把不确定的结论压进摘要，B据此继续推理，错误被链条放大且极难归因。
第三态是"父不读子"。Anthropic的subagent（Claude Agent SDK / claude-code里的Task工具）是教科书式的实现：orchestrator派生子agent时，子agent拿到一个独立的、与父隔离的上下文，跑完只把最终文本回传给父；子agent中途读了多少文档、调了多少工具，父一无所知。OpenAI的等价物是Agent.as_tool(parameters=...)——把专家agent包装成工具，调用它返回结构化结果，不转移会话历史；这与真正的handoff区别在于，handoff转移控制权与历史，as_tool只取结果。CrewAI的Delegate Work也属此态：委托时传的是任务描述，被委托agent在自身上下文完成，回传一份总结。
隔离返回的吸引力在于上下文零污染、成本O(1)。父agent的窗口只增加一条返回值，链长再大也不膨胀，这正是Anthropic多智能体研究系统能在子agent上烧大量token、却保持主上下文干净的根本机制。代价是信息漏斗：父agent必须把所有需要的细节提前让子agent放进返回值，否则一旦发现遗漏，只能整段重跑。因此隔离态的最佳实践是"返回结构化契约"——用pydantic schema约束子agent只回填必要字段，而非自由文本，把漏斗口收窄。这也意味着隔离态对接口设计能力的要求最高：三态里，它把成本从token域转移到了工程域。
把三态画在一张坐标上，横轴是交接链长K，纵轴是单次run的总推理token（粗略）：
graph LR
subgraph 全量传递["全量传递（默认/最贵）"]
A1["A 完整输出"] --> B1["B 重读A全部"]
B1 --> C1["C 重读A+B全部"]
end
subgraph 折叠裁剪["折叠裁剪"]
A2["A 输出"] --> S2["折叠成1条摘要"]
S2 --> B2["B 读摘要+自身"]
end
subgraph 隔离返回["隔离返回"]
A3["A 派生子agent"] --> SUB3["子agent 独立上下文"]
SUB3 --> R3["仅返回结果给A"]
end
style 全量传递 fill:#ffe0e0
style 折叠裁剪 fill:#fff6e0
style 隔离返回 fill:#e0f5e0
保真度则反序：全量最高、折叠次之、隔离最低。实战的难点不在于"选哪一态"，而在于同一条链上不同跳用不同态——分诊跳用全量（要把用户原话无损交给专家），专家跳内部用隔离（避免污染），回流跳用折叠（只把结论摘要交还编排者）。目前只有LangGraph的显式state模型能干净地表达这种"逐跳异构"，OpenAI需要为每个handoff单独写input_filter，AutoGen Swarm基本不支持。
交接的上下文税之外，还有一个常被忽略的控制流税：交接链何时停。OpenAI文档明确指出，"handoff停留在同一次run内"，且input guardrail只对链中第一个agent生效，output guardrail只对产出最终输出的agent生效。这意味着链中间的agent既没有入口校验也没有出口校验——一条四级handoff链，中间两级完全在护栏盲区里跑。AutoGen Swarm则要靠显式的Termination条件（如TextMentionTermination、MaxMessageTermination）来断链，否则两个互相handoff的agent会形成乒乓球死循环：A认为该B处理，B认为该A处理，token在两端来回烧直到命中max-message或预算上限。
这个"终止税"与上下文税叠加时尤其致命：在全量传递态下，乒乓球死循环每多一轮，双方上下文都增长（各自历史被对方重读），成本是指数式而非线性。工程上的兜底永远是硬上限（最大轮数、最大token、wall-clock），但硬上限触发后的恢复路径——是从头重跑、回滚到某一跳、还是人工介入——六大框架几乎没有现成方案，这把"交接"从协作模式逼成了"需要独立设计的故障域"。
当交接跨越进程甚至厂商边界时，上下文税会从框架内部外溢到协议层。MCP（Model Context Protocol）解决的是agent到工具/资源的连接，传递的是结构化的工具调用与返回；Google主推的A2A（Agent-to-Agent Protocol）解决的是agent到agent的协作，传递的是带Agent Card（描述能力与端点）的任务、JSON-RPC调用与SSE流式更新。二者的交接语义不同：MCP的"交接"天然是隔离返回态（工具只回结果），而A2A因为是agent间长时任务，默认更接近全量——双方都要把任务状态、中间产物对齐，消息体更大。
这造成了一个反直觉的现象：越是标准化的跨agent协作，单次交接的上下文开销越大，因为协议要求自描述、要求状态可恢复、要求对方未必同构。A2A的Agent Card本身就是一个常驻上下文成本，每次会话协商都要带上。对追求token效率的团队，这意味着"用A2A打通异构agent"会换来一个稳定的协议税——它换来了互操作性，但代价是交接永远落在全量态附近，很难再折叠或隔离。理解这一点，就能解释为何2026年大量团队在做完MCP集成后，仍坚持把核心多智能体链路留在同进程、同框架内：跨协议交接的税，比省下的开发成本还贵。
把三态与实测结论收口成可落地的工程清单，按链路角色逐跳选态是最有效的降税手段。第一跳（用户→分诊/编排者）保留全量，确保原意无损；中间专家跳优先隔离返回（subagent/as_tool），用结构化schema约束返回字段；专家回流到编排者用折叠，只保留决策依据摘要。链长超过3跳时强制开启nest_handoff_history或等价折叠，并对每个handoff注入最小input_filter（至少remove_all_tools）。护栏方面，承认中间跳是盲区，要么在每个handoff的on_handoff回调里补一道校验，要么用工具护栏（tool guardrails）逐次兜底。
从变现角度看，"交接税优化"是一个高度可产品化的切入点。它天然适配训练营与咨询服务：给企业做一次"多智能体交接税体检"——扫描handoff链长、默认态、是否裁剪、是否过盲区——就能直接量化token节省（实测中全量→隔离的切换常带来40%~70%的链路token降幅，视任务复杂度）。课程层面，"逐跳异构三态设计"是一个有深度、可演示、可上手的专题，比泛泛讲"多智能体架构"差异化得多。产品层面，一个"自动为handoff注入input_filter并生成裁剪策略"的中间件，正好卡在OpenAI/LangGraph生态的空白处。
| 场景 | 推荐交接态 | 推荐框架/原语 | 关键理由 |
|---|---|---|---|
| 客服分诊→专家（短链、要保真） | 全量传递 + 末跳折叠 | OpenAI handoff + nest_handoff_history |
用户原话必须无损交给专家 |
| 深度研究/多源检索（长链、易污染） | 隔离返回 | Anthropic subagent / as_tool |
主上下文必须保持干净 |
| 复杂工作流、逐跳异构 | 三态混合、显式state | LangGraph | state schema能干净表达逐跳策略 |
| 团队角色协作、任务委派 | 隔离返回 | CrewAI Delegate Work | 天然任务制、不传历史 |
| 跨厂商异构agent协作 | 折叠/全量（协议税） | A2A + MCP | 互操作性优先，接受协议税 |
| 纯推理增强、辩论共识 | 全量传递 | AutoGen Swarm | 辩论需要共享完整上下文 |
一句话收口：多智能体的交接，是"全量—折叠—隔离"三态的逐跳编排问题，而不是一个框架选型问题。把默认落在全量态当成"框架的免费午餐"，是多智能体账单失控最常见的根因；把每一跳的上下文传递当成一次显式设计决策，才是把交接从成本中心变成可控工程变量的开始。
flowchart TD
Q["任务进入多智能体链"] --> R{"这一跳需要<br/>无损原文?"}
R -- 是 --> F["全量传递态<br/>handoff(默认)"]
R -- 否 --> R2{"需要专家<br/>独立深挖?"}
R2 -- 是 --> I["隔离返回态<br/>subagent/as_tool"]
R2 -- 否 --> C["折叠裁剪态<br/>input_filter/nest"]
F --> G{"链长>3跳?"}
I --> G
C --> G
G -- 是 --> N["强制nest_handoff_history<br/>+移除工具历史"]
G -- 否 --> OUT["输出"]
N --> OUT
OUT --> T["终止: 显式max-rounds<br/>+ on_handoff补护栏"]
style F fill:#ffe0e0
style I fill:#e0f5e0
style C fill:#fff6e0
input_filter、nest_handoff_history、as_tool三态机制与默认全量传递行为[!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 等场景全覆盖。