多 Agent 系统的三种协作模式：从 Orchestrator 到 Debate

多 Agent 系统的三种协作模式——Orchestrator、Supervisor 和 Debate，各自适合什么场景、有什么坑，以及我在实践中的真实选型建议。

三个 Agent 一起干活，比一个人干还乱

我最近在做一个多 Agent 知识库系统。最开始的想法很简单：让不同 Agent 各管一摊——一个查资料，一个写摘要，一个做审核，串起来就能跑。

结果第一个版本就翻车了。

A Agent 查完了资料，B Agent 说查得不够全，自己又查了一遍。C Agent 审核的时候觉得 A 和 B 都有道理，两个都采纳了，最后输出了一份自相矛盾的答案。

我发现一个尴尬的事实：多 Agent 系统的瓶颈，从来不是单个 Agent 的能力，而是它们之间怎么协作。 这个问题不解决，Agent 越多，产出质量越差。

这段时间我试了三种主流的协作模式，每种都有自己的脾气。

Orchestrator：有个组长

Orchestrator 模式是最直觉的方案。一个中心 Agent 充当"大脑"，负责拆解任务、分配给子 Agent、汇总结果。

我最早用的就是这个模式。主 Agent 收到用户问题后，先拆成子任务，派给不同的 Specialist Agent，最后收回来整合。

class OrchestratorAgent:
    def run(self, query: str):
        # 拆解任务
        subtasks = self.plan(query)  # ["retrieve_docs", "summarize", "check_facts"]
        results = []
        for task in subtasks:
            # 逐个指派
            specialist = self.assign(task)
            result = specialist.run(task)
            results.append(result)
        # 汇总
        return self.synthesize(results)

这个模式让我又爱又恨。

优点很直观：流程清晰，容易 debug。哪个环节出问题，看日志就能定位——"哦，第三步的事实核查 Agent 卡住了"。

但是有个隐藏的大坑：主 Agent 很容易变成瓶颈。它要先理解整个问题，再拆解，再等每个子 Agent 跑完，最后再整合。一个复杂的查询，光是等子 Agent 轮番跑完就能花掉几十秒。

更深层的问题是：Orchestrator 模式假设了"任务可以被预先拆解"。但对于开放性任务——"帮我研究一下这个技术方向"——你根本不知道要查哪些资料、做几步分析，拆解本身就变成了一个难题。

适合的场景其实很明确：流程固定的流水线任务。比如文档处理的"提取→翻译→审核→格式化"，每步明确，没有分支。

Supervisor：加个监工

Supervisor 模式比 Orchestrator 多了一层。不是一个大脑发号施令，而是多层监管——下层 Agent 各自干活，上层 Supervisor 观察、评估、决策。

我的第二版就改成了这个结构。几个 Specialist Agent 可以并行跑，结果送到一个 Supervisor Agent 那里做质量评估和冲突仲裁。

class SupervisorAgent:
    def review(self, results: list[AgentResult]):
        conflicts = self.find_conflicts(results)
        if conflicts:
            return self.arbitrate(conflicts)
        return self.merge(results)

这个模式解决了 Orchestrator 的两大痛点：

一是子 Agent 可以并行执行——查资料和算数据不需要依赖关系，直接一起跑。

二是Supervisor 可以动态决策——发现两个 Agent 给出了冲突的结论，它可以触发一次"对质"，让双方补充证据，而不是机械地投票。

代价是架构复杂度上了一个台阶。你需要管理 Agent 之间的通信，处理超时和异常，还要保证 Supervisor 不会变成新的瓶颈。

对于多 Agent 知识库系统来说，Supervisor 模式在实际项目里比较实用。用好了效果很好，但踩起坑来也毫不含糊——我就遇到过 Supervisor 来回仲裁，陷入死循环的情况。

Debate：让 Agent 自己吵出来

Debate/Collaboration 模式是最"平等"的方案。没有中心调度者，多个 Agent 各自独立给出结论，然后一轮一轮地辩论，直到达成共识。

这个模式我到现在也没在生产环境大规模用——它太慢了，也太不可控了。

def debate(agents, query, rounds=3):
    opinions = [a.respond(query) for a in agents]
    for r in range(rounds):
        for i, agent in enumerate(agents):
            counter_arguments = [o for j, o in enumerate(opinions) if j != i]
            opinions[i] = agent.rebut(counter_arguments)
    return vote(opinions)

但有一个场景我觉得 Debate 模式无可替代：需要多方视角的任务。比如做技术方案评审——架构师 Agent、安全 Agent、性能 Agent 各自出一份意见，互相 challenge，最后出来的方案比任何单个 Agent 的产出都更全面。

问题也很明显：收敛性差。Agent 可以一直吵下去，你不设轮次上限就能跑一整天。

我现在的选择

做下来之后，我的选型逻辑其实很朴素：

• 固定流程、步骤明确 → Orchestrator。别想太多，串起来就是最快最稳的。
• 任务开放、需要质量把关 → Supervisor。多一层监工能拦住灾难性输出。
• 需要多样性视角、探索性任务 → Debate。但要设硬性的轮次上限。

抽象一层看，这三个模式对应的其实是同一个核心矛盾：控制的粒度 vs 系统的弹性。

Orchestrator 把控制做到极致，但失去了弹性。Agent 只是执行器，遇到边界情况就懵了。Debate 把弹性拉满，但失去了控制。Agent 自由发挥，但你可能永远等不到结果。

Supervisor 在这两者之间找到了一个平衡点——代价是你要为这个平衡付出更多的工程成本。

选哪个，最终还是看你手里的是什么任务。

Published: https://betterpursue.blogspot.com/2026/05/2026-05-21-multi-agent-coordination.html