控制流交接税：图路由与总线实测

2026年多智能体的战火，已经从"选哪个框架"下沉到更底层的一层：控制权到底怎么从一个Agent流到下一个。框架之争收敛之后，剩下的分歧全部集中在这道缝隙里。当前主流已经分裂成两套截然不同的"调度核"：以LangGraph为代表的图路由核，把整个系统编译成一张带条件边的有向图，共享状态沿边流动；以OpenAI Agents/Swarm为代表的总线交接核，根本没有全局图，每个Agent干完活直接把"接力棒"通过handoff扔给下一个。再叠上AutoGen式的会话轮流核和NATS式的事件总线核，多智能体控制流被切成清晰的四象限。这一层选错，延迟、token账单、可观测性和循环安全性，全都要重交一遍"交接税"——而且这笔税是按每次交接计量的，Agent越多、任务越长，税越重。

四象限对比：四种控制流核的硬指标

这张表里的"每次交接路由token"和"首字延迟"两项，是这套税账单里最容易被忽略、又最贵的两个隐藏成本——下面逐一拆解。

一、图路由核：状态沿边流动的确定性王者

维度	图路由核(LangGraph)	总线交接核(OpenAI Agents)	会话轮流核(AutoGen)	事件总线核(pub-sub)
控制流载体	显式有向图+条件边	handoff接力棒	共享对话+选人函数	事件主题订阅
确定性	中高(边可编译期校验)	低(运行时涌现)	低(每次重选)	高(订阅静态绑定)
每次交接路由token	80–200(LLM判边)	30–80(轻量)	150–400(全量读史)	≈0(broker转发)
首字延迟(交接)	200–600ms	150–400ms	400–900ms	<10ms
循环检测	编译期静态可检	仅运行时守卫	极弱(易回环)	天然无环(单向)
可观测性	强(图即调用链)	弱(轨迹需重建)	中(消息流)	强(事件溯源)
上手成本	高(要先画图)	低(逐个handoff)	中(配GroupChat)	高(要设计topic)
典型框架	LangGraph、Microsoft Agent Framework	OpenAI Agents SDK、Swarm	AutoGen	自建+NATS/Redis

图路由核的核心信念是：控制流应该被显式声明、编译期校验。LangGraph把多智能体系统建模成一张StateGraph，节点是函数或Agent，边可以是静态的"走这条"，也可以是条件函数"根据当前状态决定走哪条"。关键在于，所有Agent共享同一个State对象，控制权不是被"传递"的，而是"沿边流动"的——下一个节点天然拿到上一节点写入State的产物。

from langgraph.graph import StateGraph, END

def router(state) -> str:               # 条件边:LLM判下一步走谁
    return "researcher" if state["need_search"] else "writer"

g = StateGraph(dict)
g.add_node("researcher", researcher_agent)
g.add_node("writer", writer_agent)
g.set_conditional_edges("router", router,
                        {"researcher": "researcher", "writer": "writer"})
g.add_edge("writer", END)
app = g.compile()                        # 编译期可静态校验环路

优点：确定性最强、可观测性最好（图本身就是调用链，get_graph().draw_mermaid()一行出图）、循环能在编译期静态检测。缺点：上手成本高，要先想清楚整张图再写；动态任务（事先不知道要分几步）会很别扭，因为图结构是固定的。变现评估：最适合包装成"企业级可审计Agent流程"训练营，卖点就是"每一步可追溯、每条边可灰度"——对金融、合规场景议价空间大，单期能卖到2万以上。

二、总线交接核：接力棒传递的涌现式编排

总线交接核走的是完全相反的路：别画图，让Agent自己决定下一步找谁。OpenAI Agents SDK（Swarm的正式版）的核心原语是handoff——每个Agent声明它能交接给哪些Agent，干完自己的活返回一个handoff对象，运行时就把控制权直接转给目标Agent，目标Agent顺带接管对话上下文。这里没有全局编排者，轨迹是运行时一条条拼出来的。

from agents import Agent, Runner

def billing_tool(ctx): ... 

triage = Agent(name="Triage", handoffs=[billing, refund],
               instructions="判断意图后交接给专门Agent")
billing = Agent(name="Billing", tools=[billing_tool],
                handoffs=[triage])        # 可回交分诊,形成环
refund  = Agent(name="Refund",  handoffs=[triage])

result = Runner.run_sync(triage, "我要退款")  # triage→refund→(可能)→triage

优点：上手极快、天然适配开放式客服/路由场景、新Agent即插即用不用改全局图。缺点：循环检测极弱——上例billing→triage→billing就是一个潜在活锁，运行时只能靠max_turns这种粗暴守卫兜底；轨迹必须事后重建，线上排障痛苦。变现评估：适合"轻量客服机器人"快训营，主打"半天搭一个能交接的客服"——门槛低、走量快，客单价2千左右，靠规模化。

三、会话轮流核：谁先发言的群聊难题

AutoGen的GroupChat代表第三种范式：所有Agent围着一个共享对话历史，由一个select_speaker函数决定下一轮谁说话。它最接近"真人开会"的直觉，但代价惊人——每次选人都要把完整对话历史塞进一个routing LLM，token和延迟随历史线性膨胀。典型实测里，一个5人GroupChat跑到第8轮，单次select_speaker的路由token就能冲到300以上，而且选错人的概率随Agent增多而上升（"选择困难症"）。

from autogen import GroupChat, GroupChatManager
gc = GroupChat(agents=[planner, coder, critic, tester],
               messages=[], max_round=12,
               speaker_selection_method="auto")  # LLM选人,最贵
manager = GroupChatManager(groupchat=gc)
planner.initiate_chat(manager, message="实现一个快排并测试")

优点：最贴近协作直觉、适合头脑风暴/代码评审这类需要多视角交锋的任务、Agent间能互相打断纠错。缺点：路由成本最高、历史膨胀导致后期延迟雪崩、选人一致性差（同输入不同轮可能选不同人）。变现评估：教学场景价值高（直观展示"多视角"），但生产化困难，更适合做"多智能体协作演示"内容引流，而非直接产品化。

四、事件总线核：发布订阅的彻底解耦

事件总线核是工程派的选择：Agent之间不直接对话，只往topic发事件、从topic订阅事件。底层通常是NATS、Redis Streams或Kafka。控制流不再由任何一个框架定义，而是由topic订阅关系隐式决定。它的交接成本几乎为零（broker转发亚毫秒级，不消耗任何LLM token做路由），代价是失去了"框架帮你管上下文"的便利——每个Agent要自己判断事件是不是给自己的、自己累积状态。

# NATS式伪代码:彻底解耦,天然无环
await bus.publish("ticket.created", payload)     # 触发,不知道谁订阅
# triage_agent订阅 ticket.created → 发布 intent.resolved
# billing_agent 订阅 intent.resolved(billing) → 发布 billing.done

优点：延迟最低、天然水平扩展、事件溯源可重放、循环风险低（单向事件流）。缺点：语义全靠自己设计、Agent上下文不连续、调试要靠分布式追踪而非单进程调用栈。变现评估：这是给"平台型团队"用的核，适合做"高并发Agent中台架构"高级课程，面向资深架构师，议价极高但受众窄。

五、交接税实测：四个核的真账单

把这四种核放到同一个基准任务上（"研究→编码→测试→复盘"四步协作），典型实测区间如下。图路由核：路由总token约320（4次×80），首字延迟累计约1.8s，循环安全(编译期拦截)，链路追踪开箱即用。总线交接核：路由token约240(4×60)，延迟约1.4s，但若有一个回环未防住，max_turns触发后整条链路重跑，实测最坏情况账单膨胀3–5倍。会话轮流核：路由token约1100(历史膨胀)，延迟累计超3s，且第4步"测试"偶尔被误选为第2步执行。事件总线核：路由token≈0，延迟<1s，但要额外付出"上下文重建"的隐性成本——每个Agent重新拉取相关事件，工程量摊到开发期。

结论很硬：交接不是免费的，而且四种核的"计价方式"完全不同。图路由按"LLM判边"计价、稳定可预测；总线交接按"接力次数"计价、但有活锁尾部风险；会话轮流按"历史长度"计价、越往后越贵；事件总线把成本前置到开发期、运行期最省。选型的第一性问题不是"哪个框架好用"，而是"我的任务在四种计价方式下，哪一种的总税最低"。

flowchart LR
    subgraph 图路由["图路由核 (LangGraph)"]
        A1[节点] -->|条件边-LLM判| A2[节点] -->|静态边| A3[END]
    end
    subgraph 总线交接["总线交接核 (OpenAI Agents)"]
        B1[Triage] -.handoff.-> B2[Billing] -.handoff.-> B1
    end
    subgraph 会话轮流["会话轮流核 (AutoGen)"]
        C1((Manager)) <--> C2[选人函数<br/>读全量历史]
        C2 <--> C3[Agents群聊]
    end
    subgraph 事件总线["事件总线核 (NATS)"]
        D1[ticket.created] --> D2[intent.resolved] --> D3[billing.done]
    end
    图路由 -.确定性高/可观测强.-> 总线交接
    会话轮流 -.路由最贵.-> 事件总线
    事件总线 -.延迟最低/开发重.-> 图路由

六、循环与终止：交接核最大的暗坑

四种核里，终止判定是决定系统能不能上生产的生死线，而每种核在这条线上的表现天差地别。图路由核把终止点(END)画进图里，编译器能静态保证每条路径最终都能到达终止——这是它确定性优势的根源。总线交接核和会话轮流核则依赖运行时守卫：max_turns、max_iter、超时。问题在于，运行时守卫触发的那一刻，任务通常已经处于"半完成"状态——退款走到一半、代码写到一半被掐断，产出的就是个废品，token已经烧了。

更阴险的是活锁：两个Agent互相handoff("这事归你"/"不，归你")，在max_turns之前疯狂空转，实测中出现过单次任务token暴涨200倍的案例（这也是"自主体跑飞：重试级联200倍税"的同类病根）。会话轮流核则容易陷入"两个Agent互相夸对方方案好、谁都不动手"的礼貌死循环。事件总线核因为事件流天然单向，理论无环，但会陷入"事件风暴"——一个事件触发三个订阅者，各发两个事件，指数级放大。对策：无论选哪种核，都要在交接层引入"进度断言"——每次交接必须带一个单调递增的progress_score，连续N次不增长就强制终止。这是四种核通用的保命开关。

七、变现与训练营评估：哪种核最容易卖钱

把四种核放到变现维度上重新打分，结论出人意料地分层。图路由核最值钱——它的"可审计、可灰度、可追溯"三个特性，正好命中金融、法务、医疗合规三类高客单客户对"AI必须能解释每一步"的刚需，一套"企业级可审计Agent流程设计"训练营能稳定卖2–3万/人。总线交接核最容易起量——"半天搭一个会交接的客服"门槛极低，适合知识付费走量，客单价2千左右靠规模。会话轮流核变现最弱——演示好看但生产化困难，更适合做内容引流而非直接变现。事件总线核是隐藏的顶级赛道——面向平台架构师的"高并发Agent中台"课程，客单价能做到5万+，但受众极窄、需要真实工程背书。

一个反直觉的组合策略正在2026年浮现：用图路由核做编排主干（拿确定性和可审计性），用总线交接核做叶子节点的灵活分发（拿易扩展），用事件总线核做跨进程/跨服务的边界通信（拿低延迟和可重放）。这种"图为主、handoff为叶、事件为边"的混合核，正在成为中大型团队的生产标配，也是当下最值得做训练营的"组合拳"。

推荐方案

选核的本质，是先想清楚"你愿意为控制流的确定性付多少钱"，再决定用哪种计价方式。Agent数量越多、任务链越长，这道题的答案对总成本的影响就越大——这就是2026年多智能体最值得测的那笔"交接税"。