多智能体协作模式与 Python 实现选型

一、先看代价：多智能体不是"免费的更强"

2025 年 6 月 13 日，Anthropic 公开了他们的多智能体研究系统（Research 功能）的工程细节。里面有两组数字，几乎决定了你该不该上多智能体：

• 收益：以 Claude Opus 4 作主 Agent、Claude Sonnet 4 作子 Agent 的多智能体系统，在他们内部的 research 评测上，比单 Agent 的 Claude Opus 4 高出 90.2%。
• 代价：在他们的数据里，单个 Agent 消耗的 token 大约是普通对话的 4 倍，而多智能体系统是普通对话的 约 15 倍。

更值得琢磨的是他们对"为什么有效"的解释。在 BrowseComp 评测上，三个因素解释了性能方差的 95%，其中单独一项 token 使用量就解释了 80%。换句话说，多智能体系统在很大程度上是一种把 token 预算并行铺开的机制——它赢在能同时开多个上下文窗口去啃广度优先的问题，而不是赢在架构本身有多聪明。

这个结论直接划出了适用边界：

• 适合：可以拆成大量独立子问题、需要广度搜索、子任务之间有信息隔离价值的工作（深度研究、大规模代码审计、多源信息汇总）。
• 不适合：子任务之间强耦合、上下文必须完全共享、需要严格顺序推理的工作。Anthropic 也承认，多智能体在需要所有 Agent 共享同一上下文或存在大量相互依赖的场景里表现不佳。

下面按协作拓扑把主流模式过一遍，再讲 Python 侧的选型和代码。

二、四种基本协作模式

2.1 流水线模式（Sequential / Pipeline）

最简单也最容易被低估的一种：Agent A 的输出直接作为 Agent B 的输入，依次推进。典型是"写稿 → 审稿 → 定稿"。

# 微软 Agent Framework 1.0 的写法（2026-04-03 GA）
from agent_framework import Agent
from agent_framework.orchestrations import SequentialBuilder

writer = Agent(client=client, name="writer",
               instructions="你是简洁的文案，输出一句话标语。")
reviewer = Agent(client=client, name="reviewer",
                 instructions="你是审稿人，对上一句话给出简短反馈。")

workflow = SequentialBuilder(participants=[writer, reviewer]).build()
async for event in workflow.run("给 Agent 框架写一句标语", stream=True):
    if event.type == "output":
        print(event.data)

它的优点是确定性强、好调试、成本可预测；缺点是没有任何动态性——步骤在编译期就固定了。凡是"步骤能提前写死"的任务，优先用这个，不要因为多智能体听起来更高级就上主管模式。

2.2 主管-工人模式（Supervisor / Orchestrator-Workers）

一个主管 Agent 负责规划与分派，若干工人 Agent 各自执行、各自持有独立的上下文窗口，最后把结论压缩回主管。这是目前生产环境里最常见的一种。

它有效的原因在 Anthropic 那篇文章里说得很清楚：搜索的本质是压缩。子 Agent 在各自独立的上下文窗口里并行探索问题的不同侧面，只把最重要的那部分结论交回来。这同时带来了关注点分离——不同的工具、不同的 prompt、不同的探索路径，降低了单一 Agent 的路径依赖。

LangGraph 生态里，过去用 langgraph-supervisor 这个独立库实现主管模式。但注意官方现在的态度变了：langgraph-supervisor 0.0.31 版本的 PyPI 说明里明确写着——大多数场景推荐直接用工具调用的方式实现主管模式，而不是用这个库，理由是工具调用方式对上下文工程有更强的控制力。这个库现在主要是为了兼容 LangChain 1.0 才继续维护。

# 推荐做法：主管就是一个持有"worker 工具"的普通 Agent
from langchain.agents import create_agent
from langchain.tools import tool

@tool
def research_market(topic: str) -> str:
    """派一个子 Agent 去调研某个细分市场，返回压缩后的结论摘要。"""
    return run_worker_agent(topic, max_tokens=4000)

@tool
def research_competitors(product: str) -> str:
    """派一个子 Agent 去调研竞品，返回压缩后的结论摘要。"""
    return run_worker_agent(product, max_tokens=4000)

supervisor = create_agent(
    model="anthropic:claude-sonnet-4-5",
    tools=[research_market, research_competitors],
    system_prompt=(
        "你是研究主管。先拆解任务，再为每个子问题独立调用一次调研工具，"
        "最后把各份结论合并成一份报告。不要自己上网搜索。"
    ),
)

2.3 交接模式（Handoff / Swarm）

OpenAI 的 Swarm 项目（2024 年 10 月）把多智能体压缩成两个原语：routine（指令 + 工具，就是一个 system prompt）和 handoff（一个普通的工具调用，返回另一个 Agent）。没有状态机、没有分支 DSL，路由完全交给 LLM 自己决定调哪个交接工具。

Swarm 现在已经被 OpenAI Agents SDK 取代。仓库首页的提示很直白：Swarm 已由 Agents SDK 替代，后者是生产就绪的演进版本，所有生产场景建议迁移。Agents SDK 在 PyPI 上持续迭代，openai-agents 0.22.0 于 2026 年 8 月 19 日发布。

# OpenAI Agents SDK：handoff 就是一个工具
from agents import Agent, Runner

spanish_agent = Agent(
    name="Spanish agent",
    instructions="你只用西班牙语回答。",
)
english_agent = Agent(
    name="English agent",
    instructions="You only respond in English.",
)

triage_agent = Agent(
    name="Triage agent",
    instructions="判断用户使用的语言，然后交接给对应的 Agent。",
    handoffs=[spanish_agent, english_agent],
)

result = Runner.run_sync(triage_agent, "Hola, ¿cómo estás?")
print(result.final_output)

LangGraph 侧对应的实现是 langgraph-swarm（PyPI 0.1.0），它提供一个 create_handoff_tool，并会记住最后一次活跃的 Agent，下次对话直接从那个 Agent 续上。这个"记住上次是谁在场"的设计在客服类场景里很实用。

群聊模式（Group Chat）可以看成交接模式的一个变体：多个 Agent 在同一个共享消息池里轮流发言，由一个发言人选择策略（轮询、自动选择、手动指定）决定下一个说话的是谁。AG2（AutoGen 社区分支）和微软 Agent Framework 都内置了这个模式，经典写法是 GroupChat + GroupChatManager。它的优势是所有 Agent 看到同一份上下文，适合需要反复互相打岔、互相纠正的场景；代价是 token 消耗随轮次线性增长，而且很容易变成几个人礼貌地重复彼此。

2.4 辩论模式（Multi-Agent Debate）

让多个 Agent 就同一问题各自作答，再多轮互相质疑，最后投票或收敛。这个方向在学术上的结论比宣传里更微妙，值得单独说。

• ACL 2025 Findings 的《Voting or Consensus? Decision-Making in Multi-Agent Debate》只改了一个变量——决策协议，结论是决策协议本身对最终答案有显著影响，不是所有场景都适合投票，也不是都适合共识。
• arXiv:2511.07784《Can LLM Agents Really Debate?》在逻辑推理任务上做了受控研究，问题是"辩论到底有没有真的在起作用"，而不是"辩论分数高不高"。
• arXiv:2509.05396《Talk Isn't Always Cheap》专门分析多智能体辩论的失败模式。

落到工程上：辩论模式的主要成本不是钱，是收敛判定。如果两个 Agent 各执一词，谁来判断谁对？实践中比较靠得住的做法是把辩论限制在可验证的子任务上（有测试用例、有可查证的事实），让最终裁决由代码或外部验证器来做，而不是让第三个 LLM 拍板。

三、四种模式的横向对比

四、Python 侧的选型现状

2026 年这个时间点上，Python 多智能体框架大致是五家，各有明确分工：

几个容易踩的坑：

1. AutoGen 有三个名字。现在 PyPI 上装到的 autogen 是 AG2 Classic，社区分支维护；微软官方的 AutoGen 走的是另一条路，并且已经和 Semantic Kernel 合并成了 Microsoft Agent Framework。1.0 的 AG2 里，ConversableAgent、GroupChat 这些经典类已经搬到独立仓库。选型前先去 PyPI 页面确认自己要装的是哪个包，别照着 2024 年的教程敲。
2. 框架的"多智能体"标签不代表架构。很多框架提供的是"用角色 prompt 包装多个 Agent 顺序执行"，本质上还是流水线。要确认它是否真的支持独立的上下文窗口——这决定了你能不能拿到并行压缩的收益。
3. 能单 Agent 就别上多 Agent。先从单 Agent 加工具开始，只有当出现明确的瓶颈（上下文爆掉、需要并行探索、需要不同的工具集隔离）时再拆。Anthropic 自己也是这么建议的。

五、代价、失败模式与最新的实测数据

2026 年 8 月 13 日，Anthropic 前沿红队发布了一篇《Patterns and problems in emerging multiagent systems》，给了一组很难得的大规模实测数据。他们启动了 45 个 Agent，每个分配一台独立虚拟机、一个共享论坛用于协调，任务是在 15 个开源项目里找漏洞，并要求 Agent 之间互相评审发现、另设一个仲裁 Agent 判定漏洞是否真实且新增。

• 以 Claude Mythos Preview 为例：协调型 Agent 集群在约 2700 万 token 的运行中发现 266 个漏洞；而完全独立的并行 Agent在约 650 万 token 的运行中发现 21 个。
• 但把这个数字拆开看就没那么耸动了：协调集群找到的漏洞里大约一半位于简单并行方案被指定聚焦的核心目录之外。如果只看核心目录内的漏洞，两种方法每找到一个漏洞的 token 成本大体相当。
• 两种方法的重合度很低——只有 12 个漏洞是共同发现的。作者认为它们是互补的，而不是谁替代谁。
• 观察到的现象是：集群里的 Agent 会自己造工具、并逐渐分化出专精某类漏洞的方向，而独立并行的 Agent 只能被预先指派到固定位置搜索。Anthropic 判断这种专精与协调会在未来压过无协调的暴力搜索。

同一篇里还有一个更值得警惕的结论：当 Agent 之间开始互相依赖时，协调会难得多的。在"多个 Agent 集群协作开发一个游戏"的实验里，子任务之间的耦合会让整体表现明显波动。这也解释了为什么主管-工人模式（子任务相对独立）比群聊模式（全员共享状态）更容易做出稳定结果。

如果你只从这一节带走一句话：多智能体擅长的是"把独立的工作并行铺开"，不擅长"让强耦合的工作配合起来"。选错这一条，加再多 Agent 也只是把账单放大。

六、一个可落地的最小主管-工人骨架

下面这段不依赖具体框架，把主管-工人的关键结构抽出来。真实项目里换成 LangGraph 或 Agents SDK 都可以，重要的是这三个约束。

from dataclasses import dataclass, field
import asyncio

@dataclass
class WorkerBrief:
    role: str
    goal: str
    output_schema: dict          # 子 Agent 必须按这个结构返回
    token_budget: int = 8_000

@dataclass
class WorkerResult:
    brief: WorkerBrief
    payload: dict
    tokens_used: int
    citations: list = field(default_factory=list)

async def run_supervisor(task: str, plan_fn, run_worker_fn) -> str:
    # 1. 主管只做规划，不接触原始工具返回，保证自己的上下文干净
    briefs: list[WorkerBrief] = await plan_fn(task)

    # 2. 工人并行执行，各自独立的上下文窗口
    results: list[WorkerResult] = await asyncio.gather(
        *(run_worker_fn(b) for b in briefs)
    )

    # 3. 只把结构化结论 + 引用回传主管，不回传原始抓取内容
    condensed = [
        {"role": r.brief.role, "goal": r.brief.goal,
         "findings": r.payload, "citations": r.citations}
        for r in results
    ]

    # 4. 主管合并。此处单独计数，方便监控 15 倍成本是否真的换来收益
    total = sum(r.tokens_used for r in results)
    report = await synthesize(condensed, budget_hint=total)
    return report

三个约束值得单独强调：

1. 主管绝不接触原始工具返回。子 Agent 交回来的是压缩过的结构化结论。这是拿到"并行压缩"收益的前提，也是控住 token 的唯一阀门。Anthropic 的实践里，子 Agent 的职责就是"在自己的窗口里探索，然后把最重要的 token 压缩出来"。
2. 子 Agent 必须有输出 schema 和 token 预算。没有 schema，主管拿到的是几段散文，等于把上下文污染问题推迟了一步。
3. 单独统计并上报 token 消耗。多智能体的成本是 15 倍量级，不测量就无法判断这笔钱花得值不值。

七、小结

多智能体在 2026 年已经从"研究美学"变成了一个真实的架构选择。做这个选择的判断标准可以简化成两条：任务能不能拆成相对独立的子问题，以及多花的 token 能不能被准确率或时延的收益覆盖。两条都成立，主管-工人模式是首选；只成立第一条，考虑流水线；一条都不成立，老老实实优化单 Agent 的上下文工程，收益往往比加 Agent 大。

工程上建议按这个顺序推进：先让单 Agent 带工具跑通并测出基线指标，再把它包成子 Agent 暴露成工具给主管调用，最后才考虑并行化和专精分工。跨过前两步直接搭 swarm，得到的通常是一个贵且难调的演示品。

参考来源

• Anthropic Engineering，《How we built our multi-agent research system》（2025-06-13）
• Anthropic Frontier Red Team，《Patterns and problems in emerging multiagent systems》（2026-08-13）
• Python 官方文档与 PyPI：agent-framework、ag2、openai-agents、langgraph-supervisor、langgraph-swarm、crewai
• Microsoft DevBlogs，《Microsoft Agent Framework Version 1.0》（2026-04-03）
• OpenAI Agents SDK 官方文档与 GitHub Releases（v0.22.0，2026-08-19）
• openai/swarm 仓库 README（已标记由 Agents SDK 取代）
• Kaesberg 等，《Voting or Consensus? Decision-Making in Multi-Agent Debate》，ACL 2025 Findings
• Wu 等，《Can LLM Agents Really Debate? A Controlled Study of Multi-Agent Debate in Logical Reasoning》，arXiv:2511.07784
• 《Talk Isn't Always Cheap: Understanding Failure Modes in Multi-Agent Debate》，arXiv:2509.05396