<!-- title: 交即失忆：多智能体交接四式实测 -->

## 概述

2026 年多智能体协作系统已收敛到一条主线：**谁接管对话**比"谁说了什么"更决定系统成败。控制权在智能体之间的转移（handoff/交接）是 OpenAI Agents SDK、LangGraph、CrewAI、AutoGen 共有的核心原语，但四栈对"交接时携带什么状态"给出了完全不同的答案——从全量历史透传到彻底失忆，跨度极大。实测发现：交接不是简单的"消息转发"，而是一场**状态保真度与上下文成本的零和博弈**。带得太多，下游被冗余淹没、token 爆炸；带得太少，下游重复劳动、偏离主线。本文拆解四式交接机制的状态迁移策略、代价与适用边界，并给出"该忘多少"的设计判据。

## 核心对比：四式交接机制

| 维度 | OpenAI Agents SDK | LangGraph Command | CrewAI 委派 | AutoGen 嵌套对话 |
|------|-------------------|-------------------|-------------|------------------|
| 主权转移 | 整单移交 | 图节点跳转 | 任务下沉 | 子会话隔离 |
| 携带状态 | 全量消息历史 | 结构化通道合并 | 仅任务上下文 | 子会话自建上下文 |
| 保真度 | 最高（无失忆） | 可控（按通道） | 低（重度失忆） | 最低（彻底失忆） |
| 回流方式 | 返回即终态 | 回到 supervisor | 结果回填 task | 摘要回灌父级 |
| Token 成本 | 高 | 中 | 低 | 低（但易重算） |
| 循环风险 | 需 handoff 上限 | 需 visited 集合 | 需 delegation 限制 | 需 max_round |
| 典型规模 | 2–8 智能体 | 3–8 智能体 | 3–15 智能体 | 2–15 智能体 |

## 深度分析

### 一、OpenAI Agents SDK：全量透传，零失忆但高税

OpenAI Agents SDK（Swarm 的生产继任者）的 handoff 是最"诚实"的交接：当 triage 智能体决定把用户交给 tech 智能体时，整段对话历史连同当前消息一并转入新智能体的上下文窗口，新智能体就像从一开始就在场。

```python
from agents import Agent, handoff, Runner

triage = Agent(name="Triage", instructions="分流技术或订单问题")
tech   = Agent(name="Tech", instructions="解决技术问题")
triage = Agent(
    name="Triage",
    instructions="技术问题转 Tech，订单问题转 Order",
    handoffs=[handoff(tech), handoff(order)],
)
# Runner 在 handoff 触发后，把 messages 全量带过去
```

**优点**：失忆为零，tech 智能体能引用用户三句前提；语义连续，无需重复提问。**代价**：每次交接都是一次"上下文膨胀"，长对话里历史反复重读，token 成本随交接次数线性堆叠；更隐蔽的风险是"历史污染"——triage 阶段的无关试探会一直跟到终点，干扰下游判断。**变现评估**：客服路由训练营的黄金范式，可包装为"零断裂多轮客服"卖点，但必须在 handoff 前做一次摘要裁剪才能控制成本，否则账单不可控。

### 二、LangGraph Command：结构化通道，按字段决定遗忘

LangGraph v1.0 用 `Command(goto=..., update={...})` 显式控制交接，状态不是"一坨历史"而是**分通道的结构化字典**。supervisor 把控制权交给 researcher 时，只更新 `research_output` 字段，而 `messages` 通道是否累加由通道定义决定——这就是"可控失忆"。

```python
def researcher_node(state) -> Command:
    resp = llm.invoke([{"role":"system","content":"研究专家"},
                       {"role":"user","content":state["messages"][-1]["content"]}])
    return Command(goto="supervisor", update={
        "research_output": resp.content,
        "messages": state["messages"] + [{"role":"assistant","content":resp.content}]
    })
```

**优点**：遗忘是设计决策而非副作用。把"原始对话"和"提炼结论"分通道，下游只读结论通道就能避免污染；配合 Checkpointer 还能"时间旅行"回溯每一次交接。**代价**：通道 schema 是新的认知负担，设计不当（比如所有东西塞进 messages 通道）会退化成全量透传；`Command` 的 goto 若无 visited 集合保护，会在 supervisor↔worker 间反复横跳。**变现评估**：最适合做企业级"可审计编排"产品卖点——每一步交接都有 checkpoint、可回放，是金融/合规场景的天然契合点。

### 三、CrewAI 委派：任务上下文，重度失忆换轻量

CrewAI 的 hierarchical process 里，manager 智能体把任务委派给 worker 时，worker 看到的不是整段对话，而是**被裁剪过的任务描述**（task 的 description + context 列表）。这是一种激进的"失忆换轻量"策略——worker 只需知道"要做什么"，不需要知道"为什么"。

```python
crew = Crew(
    agents=[research_lead, web_researcher, data_analyst],
    tasks=[research_task, implementation_task],
    process=Process.hierarchical,
    manager_llm="gpt-4o-mini",  # 中间层用小模型省 80% 成本
)
```

**优点**：worker 上下文极小、调用便宜、可大规模并行；中间层用小模型做路由，成本结构优秀。**代价**：失忆是双刃剑——当任务边界模糊时，worker 缺少背景会反复返工；`allow_delegation=True` 链路过深会导致"传话游戏"式信息衰减。**变现评估**：内容流水线（研究→起草→审核→定稿）训练营的最佳载体，10 分钟从 pip install 到首个多智能体流，"上手即变现"门槛最低。

### 四、AutoGen 嵌套对话：子会话隔离，彻底失忆但难回流

AutoGen v0.4+ 的 nested chat 是最极端的交接——父智能体把问题抛给一个**全新隔离的 GroupChat 子会话**，子会话内部自行讨论出结论，再把**摘要**回灌父级。子会话的中间过程对父级完全不可见。

```python
top_chat = AutoGenGroupChat({
    agents:[project_manager, research_lead],
    nestedChats: {ResearchLead: research_team},  # 隔离子团队
    maxRound: 10,
})
```

**优点**：上下文彻底隔离，父级不被子级的长讨论拖累；适合"专家闭门会商"型任务。**代价**：回流只有摘要，细节全丢；若摘要质量差，父级拿着失真结论继续决策，误差被放大；调试时子会话是黑盒，定位错误极难。**变现评估**：研究型/辩论型产品的范式（如多模型 Council），但"彻底失忆"要求摘要质量极高，否则沦为"高成本猜结论"。

## 关键判据：该忘多少？

四式交接本质上是在回答同一个问题：**控制权转移时，前序状态要带多少过去？** 这不是越多越好或越少越好，而是一条倒 U 型曲线——

- **带太多**（OpenAI 全量透传）：保真高，但 token 膨胀 + 历史污染，长链路里成本失控；
- **带太少**（AutoGen 彻底隔离）：成本低，但下游失忆重算、结论失真；
- **最优解**：结构化提炼（LangGraph 通道 / CrewAI 任务上下文），让"该记的结论"过桥、"该忘的过程"留在原地。

2026 年的生产共识正在向**中段收敛**：OpenAI 的全量透传开始引入 summary handoff 选项，CrewAI 开始支持 task context 显式注入更多背景——两端正向中间靠拢。

## 代价图谱：协调税是隐藏大头

跳出交接机制本身，整个多智能体系统的成本结构里，**协调决策（路由/handoff/裁决）本身就是 LLM 调用**，这笔"协调税"常被低估：

| 模式 | 相对成本（单模型=1.0×） | 协调税来源 |
|------|------------------------|-----------|
| 单模型 | 1.0× | 无 |
| Pipeline / Fan-out | ~N× | 仅聚合，无逐次路由税 |
| Supervisor | ~(N+1)× | 每次交接前的路由调用 |
| Debate（Critique） | ~1.2× | 单次复审 |
| Debate（Council） | ~2.5× | 多模型 + judge 仲裁 |
| Swarm | 变量 | 按人口规模无界增长 |

实测要点：Supervisor 的"路由调用"和 worker 的"执行调用"是等量齐观的成本——一个 4 智能体 supervisor 任务，路由开销往往占到总 token 的 30%–40%。这也是为什么 2026 年生产默认收敛到 Supervisor 但**强烈要求小模型做路由**：用 gpt-4o-mini 做 supervisor 路由、用强模型做 worker 执行，是当前最优成本结构。

```mermaid
flowchart LR
    U[用户请求] --> SUP[Supervisor 路由<br/>小模型]
    SUP -->|Command/handoff| R[Researcher]
    SUP -->|Command/handoff| C[Coder]
    R -->|结论回填通道| SUP
    C -->|结论回填通道| SUP
    SUP --> OUT[聚合输出]

    U -.全量透传.-> R2[OpenAI: 零失忆/高税]
    U -.任务上下文.-> C2[CrewAI: 重失忆/低税]
    U -.隔离子会话.-> A2[AutoGen: 彻底失忆]

    style SUP fill:#ffe4b5
    style R2 fill:#ffd6d6
    style C2 fill:#d6ffd6
    style A2 fill:#d6e4ff
```

## 循环防护：交接是无限回路的温床

无论哪一式，交接都天然倾向于"踢皮球"循环。三栈防护缺一不可：

1. **全局 handoff 上限**：max_handoffs ≤ 10（Swarm 经验值），Claude Agent SDK 默认每子智能体约 25 轮；
2. **visited 智能体集合**：handoff 函数维护已访问集，禁止回访形成环；
3. **兜底出口**：`escalate_to_human` 作为最后逃生阀，避免死循环烧 token。

缺失任一层，多智能体系统在边界 case 下会陷入"智能体 A→B→A→B"的无限接力，账单与延迟同时爆炸。

## 推荐方案：按主权需求选交接式

**场景一：客服 / 多轮对话路由** → 选 OpenAI Agents SDK handoff。用户主权连续性最高优先，全量透传保证不重复提问，配合 summary 裁剪控成本。

**场景二：可审计企业流水线（金融/合规）** → 选 LangGraph Command + 通道。结构化状态 + Checkpointer 提供完整回放，每个交接点可审计，是合规场景的硬需求。

**场景三：内容/研究流水线（重并行、轻背景）** → 选 CrewAI hierarchical。任务边界清晰时失忆换轻量，中间层小模型控成本，从安装到首跑 10 分钟，最适合训练营快速交付。

**场景四：专家会商/多模型辩论** → 选 AutoGen nested chat。需要"闭门讨论再汇报"的隔离性，但必须投入工程保证摘要质量，否则结论失真。

**场景五：3–8 智能体的通用默认** → Supervisor 起步，路由用小模型、执行用强模型。这是 2026 年生产默认——大厂（Claude Code subagent、LangGraph Supervisor、OpenAI handoffs）全部收敛于此。

**避坑红线**：智能体数 < 5 且任务有依赖时，别上 Swarm/Fan-out；任务需要看到彼此中间状态时，别用 Supervisor；低成本场景别用 Council 辩论（2.5× 税率不划算）。编排复杂度永远应跟随负载复杂度，而非反过来。

## 参考来源

1. [Multi-Agent Orchestration: 5 Patterns That Work in 2026](https://www.digitalapplied.com/blog/multi-agent-orchestration-5-patterns-that-work) — 五式编排模式（fan-out/pipeline/debate/supervisor/swarm）的成本倍率、反模式与 9 框架兼容矩阵，含 Council 辩论 ~2.5×、Kimi K2.6 三百智能体群等关键数据
2. [Multi-Agent Orchestration Patterns: Supervisor vs Swarm vs Hierarchical](https://qubittool.com/blog/multi-agent-orchestration-patterns) — 三种编排拓扑的 LangGraph/OpenAI Swarm/CrewAI 完整可运行实现，含延迟对比（Supervisor ~13.5s / Swarm ~6s / 层级 ~10.5s）与循环防护三层策略
3. [Multi-Agent Orchestration in 2026: Patterns, Frameworks, and When to Use Each](https://agentbrisk.com/blog/multi-agent-orchestration-guide-2026/) — 2026 模式选型实践指南，supervisor 作为生产默认的论证与 fan-out/swarm 适用边界
4. [LangGraph Multi-Agent Patterns in 2026 — Supervisor, Hierarchical](https://www.pyinns.com/python/data-sciences/langgraph-multi-agent-patterns-2026-supervisor-hierarchical) — LangGraph v1.0 `create_agent`/`Command` 控制流原语与状态通道机制的代码示例
5. [Definitive Guide to Agentic Frameworks in 2026](https://softmaxdata.com/blog/definitive-guide-to-agentic-frameworks-in-2026-langgraph-crewai-ag2-openai-and-more/) — LangGraph/CrewAI/AG2/OpenAI Agents SDK 的架构、API 演进（含 @anthropic-ai/claude-agent-sdk 2025-09-29 重命名、create_react_agent→create_agent 迁移）与生产权衡

> [!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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)