核心概念：拓扑 × 协调 × 通信

1.1三轴总览

拓扑、协调、通信是三条互不绑定的轴；一套多 agent 系统就是在三条轴上各取一值的组合。

底层机制：为什么这三条轴是"正交"的

正交在这里有一个可验证的含义——固定其中两条轴的取值，第三条仍可独立改变，而系统照常成立。逐对验证一遍：

• 固定拓扑 supervisor + 通信共享 state，协调可以是"中心调度派活"，也可以换成"协调者只在 state 里放下一步标记、由 agent 自行轮询"——拓扑没变，连接形状没变，决策权位置变了。
• 固定拓扑 supervisor + 协调中心调度，通信可以走全员可见的 group chat，也可以走只读写共享 state——谁说了算没变，信息载体变了。
• 固定协调中心调度 + 通信共享 state，拓扑可以是单层 supervisor，也可以叠成 hierarchical 多层——决策权与信息载体没变，连接的层数变了。

三对都能"固定二者、独立改第三",这就是正交的操作性定义。它的实践后果：一套系统不是"是 LangGraph 还是 AutoGen"，而是三个独立选择叠出来的一个点，组合数远多于框架数。下面这张图把三条轴画成一个坐标，每个框架是这个坐标里的一块区域，而不是一条轴。

1.2拓扑结构

拓扑 = agent 之间连成什么形状——三种基本形状：supervisor、hierarchical、network/swarm。

底层机制：形状的差别落在"边"上

把每个 agent 看成节点、"谁能把控制权交给谁"看成有向边，三种拓扑的差别就是边的连法不同，比文档常说的"集中 vs 分散"更具体：

• supervisor：边是星形——所有边从中心节点出、再收回中心。worker 之间没有边，彼此不可达。控制流每一跳都经过中心，于是中心的 trace 里能看见全过程。
• hierarchical：边是树形——星形的递归，每个 worker 自己又可以是下一层的中心。控制权沿树往下分发、结果沿树往上汇聚；层数 = 决策被转手的次数。
• network/swarm：边是任意有向图——任一 agent 都允许有指向其它 agent 的边，没有必经的中心节点。在 LangGraph 里，这条"边"被实现成 handoff 工具返回的 Command(goto=..., graph=Command.PARENT)——agent 调用该工具，运行时就跳到父图的另一个节点，等于自己画了一条边。

"边"这个视角能直接读出代价：星形的中心是单点瓶颈也是单点可观测；任意图省掉了中心那一跳所以更快，但没有一处能看见全局，调试要把多段 trace 拼起来。这条权衡 02 章和 04 章会反复回引。

类比 · 带边界

把三种拓扑类比成公司的汇报线：supervisor 像一个经理带一组互不沟通的下属，所有协调经过经理；hierarchical 像总监—经理—员工的多级汇报；network/swarm 像一群同级同事，谁手上有合适的活就直接转给旁边的人。类比在这里断裂：公司的汇报线是为了"权责"，而 agent 拓扑是为了"控制流与上下文边界"——经理换人不影响下属的记忆，但 supervisor 这一跳决定了 worker 能不能看见彼此的上下文。把拓扑当组织架构图去想会漏掉"上下文在哪分隔"这个 agent 独有的维度，那正是 1.4 的主题。

场景走查

需求："给定一个城市，产出一份含天气、交通、3 个景点的一日游建议"。天气查询、交通查询、景点检索三件事彼此独立、可同时进行，最后拼成一份建议——边从一个协调点发出去、结果收回来，supervisor 星形正好贴合。若再要求"景点检索内部再按'美食/历史/自然'三类分头查"，那就是在 worker 之下再开一层，星形递归成hierarchical。若需求变成"客服对话，账单问题转账单专员、技术问题转技术专员、专员之间还能互转"，没有必经中心、agent 之间直接交接，那是network/swarm。

1.3协调机制

协调 = 谁持有"下一步决策权"——中心调度（协调者决定）vs 去中心 handoff（agent 自行决定交给谁）。

底层机制：决策权 = "下一步是谁"这个决定由谁的 LLM 调用产生

把它落到代码层面，决策权的位置就是一个很具体的问题——"下一步该轮到哪个 agent"这个判断，是哪一次 LLM 调用的输出？

• 中心调度：有一个固定的协调者节点，每一跳都先回到它，由它的 LLM 调用（或一段路由逻辑）产出"下一步是谁"。决策权集中在这一个节点。代价：协调者是必经跳，多一次往返、多一份 token；好处：下一步永远有据可查。
• 去中心 handoff：没有固定协调者，"下一步是谁"由当前正在跑的那个 agent自己的 LLM 调用产出——它在自己的工具列表里挑一个 handoff 工具调用，把控制权连同上下文交出去。决策权随控制权一起移动。代价：没有一处能集中看见"为什么走到了这一步"，misroute（交错对象）只能事后从各段 trace 拼。

这条机制有一个反直觉处：决策权位置和拓扑不是一一对应。supervisor 拓扑通常配中心调度，但也能配 handoff（协调者只做入口，之后 agent 互相交接）；network 拓扑通常配 handoff，但塞一个裁判节点就成了事实上的中心调度。所以面试里"画个 supervisor"不等于答完了——还得说清决策权在不在中心。

类比 · 带边界

中心调度像航空的塔台——每架飞机的下一步动作都由塔台统一指挥；去中心 handoff 像接力赛——棒在谁手里，谁决定何时交给下一棒。断裂点：塔台和接力都假设"下一个上场的人"基本确定，而 agent 的 handoff 是由 LLM 现场判断的，存在判断错对象的风险（接力赛不会把棒交错跑道，agent 会）。所以去中心 handoff 真正的工程难点不在"交接"这个动作，而在"判断交给谁"这个易错的 LLM 决策——这正是 04 章 misroute 类失败的根。

场景走查

需求："一个研究助手，先检索资料再写报告"。若让一个固定的协调者每步决定"现在该检索还是该写"，决策可追溯、便于在中间插入人审，这是中心调度。需求变成"客服系统，账单专员处理到一半发现是技术问题，直接转给技术专员"——由当前专员自己判断该不该转、转给谁，没有回中心绕一圈，这是去中心 handoff。注意同一个客服系统，如果改成"每条消息都先回到一个分诊节点再分发"，它又变回中心调度了——决策权的位置是被设计出来的，不是被场景唯一决定的。

1.4通信方式

通信 = 信息怎么在 agent 间流——共享 state（都读写同一状态）vs 消息传递（显式传消息）；外加 per-subagent 上下文隔离。

底层机制：两种载体，差别在"默认可见范围"

• 共享 state：所有 agent 读写同一个状态对象（LangGraph 的 State 就是这种——它同时充当各 agent 之间的"公告板"）。一个 agent 写进 state 的东西，别的 agent 默认读得到。好处：不用显式搬运信息；代价：state 越大，每个 agent 的上下文越臃肿，且容易读到与自己无关的内容。
• 消息传递：信息以显式消息流动——group chat（全员可见，如 AG2 的 GroupChat）或 handoff 时携带的上下文（点对点，如 OpenAI Agents SDK 把对话上下文随交接一起带过去）。可见范围由"发给谁"显式决定，但要自己保证"传够了"。

per-subagent 上下文隔离：为什么要把 subagent 的上下文分开

这是多 agent 区别于"一个长对话"的关键一招，也是 Anthropic 的 multi-agent research 系统反复强调的设计：给每个 subagent 一份独立、干净的上下文，而不是把所有 agent 塞进同一个不断膨胀的对话历史。两个动机，正好一推一拉：

• 推：防 context clash（上下文打架）。若所有 subagent 共享一条历史，A 的中间推理、B 的失败尝试、C 的无关检索全混在一起，每个 agent 都被迫读一堆与自己任务无关的内容——既烧 token，又容易被别人的错误结论带偏。隔离让每个 subagent 只看自己那一摊。
• 拉：但必须"传够信息"。隔离的代价是 subagent 看不到全局，于是协调者派活时要把"这个子任务需要的背景"明确打包进去——任务目标、约束、已知事实。Anthropic 的经验是：subagent 表现差，常常不是模型不行，而是派活时上下文给得不够。隔离和"传够"是一对必须同时拿捏的力。

所以上下文隔离不是"少给信息"，而是"精确地给"——切断无关的，打包必需的。这条拿捏失手的两个方向（给太多 = clash、给太少 = subagent 抓瞎），04 章都各有一个失败模式对应。

# A. 共享 state —— agent 读写同一个 State，彼此默认可见
class ResearchState(TypedDict):
    topic: str
    findings: list[str]      # 多个 agent 往这里 append，互相读得到

def worker(state: ResearchState) -> dict:
    note = search(state["topic"])
    return {"findings": [note]}   # 写回共享 state，其他节点能读到

# B. 消息传递 / handoff —— 控制权 + 上下文显式交给下一个 agent
#    （OpenAI Agents SDK：handoffs= 声明可交接对象，上下文随交接带过去）
billing = Agent(name="Billing", instructions="处理账单")
tech    = Agent(name="Tech",    instructions="处理技术故障")
triage  = Agent(name="Triage", instructions="按问题类型交接",
                handoffs=[billing, tech])   # 交接时携带对话上下文

# C. per-subagent 上下文隔离 —— 协调者给每个 subagent 一份"打包好的"干净任务
def spawn_subagent(subtask: str, packed_context: str):
    # 关键：不传整条全局历史，只传这个子任务需要的背景（精确地给）
    return run_agent(system=packed_context, task=subtask)

类比 · 带边界

共享 state 像团队共用一块白板，谁都能写、谁都能看；消息传递像发邮件，收件人明确。上下文隔离像"给每个外包只发与他那块活相关的需求文档，不把整个项目历史甩给他"。断裂点：白板/邮件的内容是人写的、稳定的，而 agent 写进共享 state 的常常是没核实的中间结论——别的 agent 读到后会当真，错误就这样传染（白板上的错字不会主动误导同事，state 里的错误结论会）。所以共享 state 的便利伴随"错误广播"的风险，这也是为什么高价值并行任务反而偏向隔离上下文。

场景走查

需求："3 个 subagent 并行查同一主题的不同侧面，最后汇总"。若它们写进同一个 findings 列表、协调者读全部来汇总——共享 state，简单。但若其中一个 subagent 查岔了、把错误结论写进 state，另外两个读到后会顺着错下去——这时改成每个 subagent 隔离上下文、只把最终 finding 交回协调者，错误就被关在单个 subagent 里不外溢。需求若是"客服账单专员转技术专员"，转过去时要带上"用户已经说过 API key 失效、已确认账户正常"这些上文——这是消息传递里"传够信息"的具体体现，少带一句用户就得重复说一遍。

1.5单 agent + 工具 vs 多 agent 的分界

默认单 agent + 多工具；只有"子任务独立可并行且价值高"才上多 agent——这是全教程最重要的判断闸。

底层机制：多 agent 买的是什么、付的是什么

多 agent 不是免费的抽象，它是一笔有明确收支的交易：

• 买到：① 并行——独立子任务同时跑，省墙钟时间；② 上下文隔离——每个 subagent 专注一摊，防 clash；③ 专业化——不同角色不同 prompt/工具，提质。
• 付出：① token 成本——Anthropic 公布其 research 系统的多 agent 架构消耗约为单 agent 聊天的 15×；② 协调复杂度——多一层"派活—汇总"要写、要调；③ 可观测性下降——跨多个 agent 拼 trace 才看得清一次运行。

这笔账只有在子任务真的独立可并行、且任务价值足够高到撑得起 15× 量级的 token时才划算。Anthropic 给的边界很直白：multi-agent 适合"价值高到能吃下 token 开销、且广度优先（breadth-first）可并行探索"的任务，典型是开放式深度检索；反过来，大多数任务、尤其是写代码这种串行依赖强的任务，单 agent 更合适——这也是 Cognition 在《Don't Build Multi-Agents》里的核心主张。这条 read-heavy 可并行 vs write-heavy 强依赖的分界，02 章第一节（§2.1）会展开成一条主原理。

类比 · 带边界

类比成"一个人干 vs 组个团队"：能一个人按时干完的活，组团队只会增加沟通成本（开会、对齐、合并）；只有活大到一个人来不及、且能切成互不依赖的几块时，团队才真正提速。断裂点：人组团队还能靠默契和临场沟通补救切分不当，agent 之间没有默契——切分不当（本该串行却并行）不会被运行时自动修复，只会原样放大成发散和冲突。所以"能不能切成独立的几块"对 agent 是硬约束，比对人更不容妥协。

场景走查

需求 A："调研 5 家竞品的定价并出一张对比表"——5 家彼此独立、可同时查、调研结论有商业价值，三道闸全过，多 agent（每家一个 subagent 并行检索）合理。需求 B："把这份调研写成一篇连贯的分析报告"——写作前后强依赖、要风格统一，第一道闸就"否"，回到单 agent。需求 C："回答一个用户的简单产品问题"——单 agent 配一个检索工具就够，价值也撑不起多 agent 开销，根本不必进后面两道闸。三个需求摆在一起，正好是 1.5 这道闸的日常用法：先判该不该，再谈怎么搭。