协作：合鸣之美，多 Agent 之间如何传 token

07.1何时上多 Agent：先用最简方案

单 Agent 是默认，多 Agent 是一笔"花 token 换并行与隔离"的交易——只在任务能拆成独立并行支线、且超出单窗口容量时才划算。

底层机制（比"多个脑子更聪明"深一层）：多 Agent 的增益主要不是来自架构，而是来自烧更多 token 做更多并行探索。Anthropic 的内部 research eval 里，Opus lead + Sonnet 子 Agent 的多 Agent 系统比单 Opus 高 90.2%；但回归分析显示 token 用量单独解释 80% 的性能方差，加上工具调用数与模型选择三因子合计解释 95%。换句话说，多 Agent 赢，是因为它花了 4× 单 agent、约 15× chat 的 token 去并行铺开搜索面，不是"分工 = 更聪明"。判据因此落在任务结构：仅当任务能拆成独立并行支线、且单个 context window 装不下时，并行才值回这 15× 成本。Anthropic 内部有团队花数月搭精巧多 Agent 架构，最后发现把单 Agent 的 prompt 改好就追平——这是反复出现的教训。

# L31：把"要不要上多 Agent"做成一个显式判据，而非默认
def should_go_multi_agent(task):
    # 三判据全为否 → 单 Agent，省 15× token
    context_pollution = task.needs_many_subqueries        # 污染会降质
    parallelizable    = task.has_independent_branches      # 支线可并行
    specialization    = task.benefits_from_distinct_tools  # 专业化改善工具选择

    if not (context_pollution or parallelizable or specialization):
        return single_agent                               # 默认路径

    # 紧耦合（写操作有依赖，如 coding）→ 仍走单 Agent
    if task.is_tightly_coupled:                            # 子任务依赖太多
        return single_agent                               # Cognition 的立场

    return orchestrator_workers   # 仅在确实划算时才付 ~15× chat token 的并行预算
# 不变式：增益的 80% 由 token 用量解释 —— 多 Agent 是用算力换探索，不是免费红利

07.2层级委派：orchestrator-worker 的上岗培训

一个 lead agent 动态拆解任务、把子任务派给各有独立 context window 的 worker，worker 只回传 1–2k 压缩摘要——隔离防污染，但隔离也切断了子 Agent 间的中间决策共享。

底层机制（两件工艺：上岗培训 + 上下文隔离）：其一，每个子 Agent 必须收到一份完整的任务说明书——目标、输出格式、工具/来源指引、清晰任务边界，缺一项就退化成重复劳动或漏报。还要把投入度规则写进 prompt 当启发式：简单查证用 1 个 Agent 跑 3–10 次工具调用；直接对比用 2–4 个子 Agent 各 10–15 次；复杂研究可起 >10 个子 Agent。其二，上下文隔离：子 Agent 各有独立 context window 并行探索，只把最重要的 token 压缩成 1–2k 摘要回传，重物件用 artifact 系统传"轻量引用"而非全文，避免多级处理中的信息丢失。这正是 03 章 context rot 的对策——把每条支线关进自己的窗口，lead 的窗口就不被子任务的噪声撑爆。但隔离是双刃：子 Agent 看不到彼此的中间决策，这正是 Cognition 抨击的断点。最后用一个单独的 CitationAgent 跑一遍，把每条声明绑回来源。

07.3扇出聚合：fan-out / fan-in 与它的两个子型

把可并行的子问题同时派出去（fan-out）再综合（fan-in）；它和 orchestrator 拓扑同构，唯一区别是这里的子任务可以预定义，不必由 LLM 临场决定。

底层机制（拓扑同构，但语义不同）：扇出与 07.2 的 orchestrator-worker 画出来是同一张图，差别只在一处——parallelization 的子任务可事先静态定义，orchestrator 的子任务由 LLM 临场决定。Anthropic 的《Building Effective Agents》把它细分成两个子型。sectioning（分段）：把任务拆成独立子任务并行，目的是纯提速或做护栏——比如一个 Agent 答用户、另一个并行筛查违规内容。voting（投票）：同一个任务跑多次取多样输出或共识，用于需要冗余校验的场景——安全代码审查、内容审核。两个子型共享"扇出—扇入"的骨架，分歧只在扇出的是不同子任务还是同一任务的多次复跑。

07.4对抗评审：用结构对抗共识偏误

专门设计会唱反调的 Agent 来制衡共识偏误；但对抗本身有失效模式——朴素 debate 会因附和把对的答案带偏成错的，且成本随 Agent×轮数二次方膨胀。

底层机制（对抗有效，但对抗自己会反噬）：multi-agent debate（Du 等，ICML 2024）实测把传记事实准确率从单 LLM 的 60% 提到 74%（异质自适应辩论可到 80.6%），显著降幻觉。但机制有两道反噬。其一成本：每个 Agent 要持完整辩论史作上下文，token 随 Agent×轮数二次方膨胀——8 Agent×4 轮涨 36–49×；而准确率在 2–3 轮、2–4 Agent 就 plateau，再加边际收益与算力效率双降。其二更危险（2025《Talk Isn't Always Cheap》）：模型常因同伴推理从对的改成错的，宁可附和也不挑战错误论证，即便强模型在数量上压过弱模型仍会掉分。根因是 Agent 缺乏对抗"有说服力但错误论证"的激励与防御。所以 red-team / devil's-advocate 要显式给对抗 Agent"挑刺"的角色与激励，否则辩论退化成趋同——这与 06 章"自评无外部信号会更差"是同一个故障的群体版本。

07.5交接链：handoff 与 swarm vs supervisor

handoff 让 Agent 间直接转移控制权而非经中心中转；LangGraph 的 Command 把"改 state"和"换节点"合并成一次原子返回——goto + update + graph=PARENT。

底层机制（Command 把两件事合并成原子返回）：LangGraph 的 create_handoff_tool 返回一个 Command 对象，单次返回里同时做三件事——goto=目标 Agent 节点 决定跳到哪、update={messages, active_agent, ...} 决定带什么 state 过去、graph=Command.PARENT 让子图节点能跳到父图的兄弟 Agent。swarm 在持久化 state 里记一个 active_agent，下一轮直接从该 Agent 续上，无需每次回中心。这与 03 章把状态外化到外部是同一招——控制权的"游标"写进 state，崩溃或换轮后照样续得上。network/swarm vs supervisor 的实测差异（LangChain 改造版 τ-bench，航空域 + 干扰项）：单 Agent 在 2+ 干扰域时急剧掉分；swarm 全场最佳，因为子 Agent 直接答用户、避开了 supervisor 在子 Agent 与用户之间"传话（telephone game）"的翻译损耗。但 supervisor 不是没救：去掉 handoff 噪声消息、给 supervisor 一个 forward_message 工具原样透传子 Agent 回复、把工具命名从 transfer_to 调成 delegate_to，三招让它在该 benchmark 上性能涨近 50%。结论不是"swarm 永远赢"，而是从成功定义与约束反推架构。

# L35：Command 把"改 state"和"换节点"合并成一次原子返回（LangGraph 风格）
def make_handoff(target):
    @tool
    def transfer_to(state):
        return Command(
            goto=target,                                  # 跳到目标 Agent 节点
            update={"active_agent": target,               # swarm 记住谁在掌权
                    "messages": state["messages"]},       # 带什么 state 过去
            graph=Command.PARENT)                         # 子图跳到父图的兄弟 Agent
    return transfer_to

# swarm：对等 Agent 互相直接 handoff，下一轮从 active_agent 续上，不回中心
# supervisor 想补回差距：forward_message 原样透传，避开"传话"翻译损耗
def forward_message(state):
    return state["last_subagent_reply"]   # 不让中心 Agent 转述 → 该 benchmark 涨近 50%

# 把五课串起来的最小骨架：lead 编排 + 扇出 + 隔离回传 + 对抗评审 + handoff
def lead_agent(query):
    # 07.1：先判断要不要上多 Agent —— 简单任务直接单 Agent 返回
    if is_simple(query):                       # 简单查证：单 Agent 更省更快
        return single_agent(query)

    # 07.2 + 07.3：动态拆解 → 扇出给隔离的子 Agent（map）
    subtasks  = lead.decompose(query)          # 子任务临场决定，非预定义
    summaries = parallel_map(                   # fan-out：各子 Agent 独立 context window
        lambda t: run_subagent(spec=t),        # spec={目标, 输出格式, 工具, 边界}
        subtasks)                              # 子 Agent 只回传 1–2k 压缩摘要，不回全轨迹

    draft = lead.synthesize(summaries)         # fan-in / reduce

    # 07.4：对抗评审 —— 显式 devil's advocate，给它"挑刺"的角色
    critique = critic_agent.attack(draft, role="找出最致命的反例与漏洞")
    if critique.has_blocking_issues:
        draft = lead.revise(draft, critique)   # 限 1–2 轮，避免 plateau 与成本爆炸

    citations = citation_agent(draft, summaries)  # 单独跑：把每条声明绑回来源
    return draft, citations