当多个智能体协作时，最贵的不是工具调用，而是**控制权在智能体之间移动的那一瞬间**——也就是"交接"（handoff）。2025年OpenAI把Handoffs做进Agents SDK的一等原语、AutoGen 0.4把Swarm的handoff称为"OpenAI引入的模式"、Google ADK用`transfer_to_agent`搭子智能体树，三家表面各异，内核却指向同一个被严重低估的成本中心：**交接瞬间，下一个智能体到底看到多少上下文**。本期沿着这条主轴实测六大主流框架，结论是交接上下文只有三种稳定形态——**全量传递、折叠裁剪、隔离返回**——而绝大多数框架默认落在最贵的那一态，且开发者几乎从不显式降档。 ## 交接税的本质：三态划分 所谓"交接"，指一次运行（run）内，控制权从Agent A转移到Agent B时，B的输入窗口里被塞进了什么。看似一个细节，实则决定了多智能体链路的token成本曲线、保真度与安全边界。把所有框架的实现摊开，能精确归约到三态： - **全量传递态（Full Transfer）**：B看到A产生的完整对话历史，"仿佛B接管了整段会话"。保真最高，但B的上下文随链长线性甚至二次膨胀。 - **折叠裁剪态（Collapsed/Pruned）**：B只看到经过过滤或摘要后的历史，例如剥掉所有工具调用、或把整段历史压成一条``摘要。成本可控，但裁剪即丢信息。 - **隔离返回态（Isolated Return）**：B在独立上下文里跑完，只把**最终结果/摘要**回传给A。上下文零污染、成本最低，但A必须从B的返回值里重新提取需要的信息，保真损耗最大。 这三态不是抽象分类，而是六大框架的真实默认行为与可配置项。理解它们，就理解了多智能体"为什么这么烧钱"的根因。 ## 六栈交接上下文默认态对比 | 框架 | 默认交接态 | 显式降档手段 | 链长成本曲线 | 控制粒度 | |------|-----------|-------------|-------------|---------| | 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 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标签区分，链一长，串话与误归因的概率随之上升。 ## 折叠裁剪态：input_filter与nest_handoff_history OpenAI显然意识到了全量的代价，因此给了两道显式裁剪闸门。第一道是`input_filter`——一个接收`HandoffInputData`（含`input_history`、`pre_handoff_items`、`new_items`、`input_items`、`run_context`）并返回新`HandoffInputData`的函数。SDK内置了常用模式，例如`handoff_filters.remove_all_tools`，会在交接瞬间把历史里所有工具调用剥离，只留文本： ```python 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摘要消息**，包进``块，并在同一次run里多次交接时持续追加。若只想改包装文本而不写完整filter，可用`RunConfig.handoff_history_mapper`注入自定义映射函数。LangGraph走的是更显式的路子：交接"上下文"就是共享state（TypedDict），你往state里放`messages`就是全量、放摘要字段就是折叠、把子agent当tool调用就是隔离——**裁剪决策被编码进state schema，而不是临时塞进运行时参数**，可读性与可测试性都更高。 折叠态的权衡是**压缩即损失**。摘要丢掉了中间推理、工具返回的原始数据、边界条件；一旦后续agent需要回头核对某个具体数字，它只能凭摘要里的二次表述。这把多智能体系统推向了一个新的故障面：**摘要幻觉在交接边界上传染**——A把不确定的结论压进摘要，B据此继续推理，错误被链条放大且极难归因。 ## 隔离返回态：subagent、as_tool与CrewAI委托 第三态是"父不读子"。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（粗略）： - 全量传递：近似O(K²)，因为第i个agent要重读前i-1段的累积输出，K=5时上下文已是单agent的5倍以上。 - 折叠裁剪：近似O(K)，每跳只携带固定大小的摘要+本跳新输出。 - 隔离返回：近似O(1)（父视角），子agent内部成本独立，主链上下文不随K增长。 ```mermaid 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基本不支持。 ## handoff死循环与终止税 交接的上下文税之外，还有一个常被忽略的**控制流税**：交接链何时停。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），但硬上限触发后的恢复路径——是从头重跑、回滚到某一跳、还是人工介入——六大框架几乎没有现成方案，这把"交接"从协作模式逼成了"需要独立设计的故障域"。 ## A2A vs MCP：交接税的协议层外溢 当交接跨越进程甚至厂商边界时，上下文税会从框架内部外溢到协议层。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 | 辩论需要共享完整上下文 | 一句话收口：**多智能体的交接，是"全量—折叠—隔离"三态的逐跳编排问题，而不是一个框架选型问题**。把默认落在全量态当成"框架的免费午餐"，是多智能体账单失控最常见的根因；把每一跳的上下文传递当成一次显式设计决策，才是把交接从成本中心变成可控工程变量的开始。 ```mermaid flowchart TD Q["任务进入多智能体链"] --> R{"这一跳需要
无损原文?"} R -- 是 --> F["全量传递态
handoff(默认)"] R -- 否 --> R2{"需要专家
独立深挖?"} R2 -- 是 --> I["隔离返回态
subagent/as_tool"] R2 -- 否 --> C["折叠裁剪态
input_filter/nest"] F --> G{"链长>3跳?"} I --> G C --> G G -- 是 --> N["强制nest_handoff_history
+移除工具历史"] G -- 否 --> OUT["输出"] N --> OUT OUT --> T["终止: 显式max-rounds
+ on_handoff补护栏"] style F fill:#ffe0e0 style I fill:#e0f5e0 style C fill:#fff6e0 ``` ## 参考来源 1. [Handoffs — OpenAI Agents SDK](https://openai.github.io/openai-agents-python/handoffs/) — 交接原语的权威定义，含`input_filter`、`nest_handoff_history`、`as_tool`三态机制与默认全量传递行为 2. [Orchestration and handoffs | OpenAI API](https://developers.openai.com/api/docs/guides/agents/orchestration) — 官方对handoff与agents-as-tools两种编排模式的对比指南 3. [Handoffs — AutoGen](https://microsoft.github.io/autogen/dev/user-guide/core-user-guide/design-patterns/handoffs.html) — AutoGen 0.4对Swarm handoff模式与共享会话上下文的说明 4. [langgraph-supervisor-py](https://github.com/langchain-ai/langgraph-supervisor-py) — LangGraph多智能体supervisor模式，显式state驱动的逐跳上下文控制 5. [The 2026 Multi-Agent Framework Landscape](https://agentmarketcap.ai/blog/2026/04/11/langgraph-autogen-crewai-dspy-multi-agent-orchestration-2026) — LangGraph/AutoGen/CrewAI/DSPy 2026编排架构与性能基准横向对比 > [!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 等场景全覆盖。