Supervisor架构：当一群Agent需要「经理」——多Agent系统的最优组织方式

现状之痛：你按A2A的思路拆了5个Agent——邮件、报价、报告、财务、客服。它们各干各的没问题，但一旦要协作完成一个复杂任务，谁来决定顺序？谁来协调冲突？谁在出问题时兜底？群龙无首，协作变成混乱。

读完你将：理解Supervisor架构——多Agent系统的最优组织方式，以及「一个经理+一群工人」为什么比「平级协作」更可靠。

---

〇、热点背景：为什么2026年Supervisor模式成了主流

2026年，企业级多Agent系统的主流架构，已经从「平级协作」转向了「Supervisor + Worker」模式。

为什么？三个原因：

1. 平级协作的「决策真空」：5个Agent平级，遇到「谁先做、谁后做」的冲突，没有裁决者——要么死锁，要么都做
2. 单一职责的极限：一个Agent既要干活又要决策，上下文被决策逻辑污染，干活质量下降
3. 可观测性的需求：企业需要一个「总控」来统一审计所有Agent的行为——Supervisor就是那个总控

一句话：Agent越多，越需要「经理」。Supervisor架构是2026年多Agent系统的组织学答案。

---

一、问题：平级协作的「三个坑」

 *平级协作 vs Supervisor架构*

我一开始按「平级协作」拆了5个Agent——每个Agent都能看到其他Agent，谁需要什么就自己调用。结果遇到三个问题：

坑1：谁先谁后？

用户：查运费 → 更新报价 → 发邮件给客户

平级协作：
  报价Agent：我先算运费（它去调了运费Agent）
  邮件Agent：我先发邮件（它发现报价还没更新，卡住了）
  报告Agent：我也来（它想顺便记录一下）

  三个Agent同时开工，互相等，最后乱成一锅粥

坑2：谁来裁决？

运费Agent算出的结果有两种可能（海运/空运）
  报价Agent：用海运的
  财务Agent：用空运的（因为历史报价都用的空运）

  两个Agent意见冲突，没有仲裁者，各算各的

坑3：谁来兜底？

邮件Agent发送失败（客户邮箱格式变了）
  它重试了3次，还是失败
  然后呢？没人管——任务就卡死在那里

根因：平级协作把「干活」和「决策」混在一起，每个Agent既是工人又是经理，结果都干不好。

---

二、Supervisor架构：一个经理，一群工人

 *Supervisor架构：一个经理+一群工人*

Supervisor架构的核心：一个「经理Agent」负责调度，多个「工人Agent」负责干活。经理不干活，工人不决策。

┌─────────────────────────────┐
│      Supervisor Agent        │
│  （经理：决策/调度/协调/兜底）│
└──────┬──────┬──────┬────────┘
       │      │      │
   ┌───▼──┐┌──▼───┐┌▼────┐
   │邮件Agent││报价Agent││报告Agent│
   │ 工人  ││ 工人  ││ 工人  │
   └───────┘└──────┘└─────┘

职责分离：

Agent	职责	不做什么
Supervisor	拆解任务、排顺序、协调冲突、兜底重试	不干活（不查数据、不发邮件）
Worker	只做自己的专业活	不决策（不判断顺序、不协调）

---

三、我的实践：物流系统的Supervisor

我给物流系统加了一个「调度Agent」作为Supervisor：

class SupervisorAgent:
    """经理Agent：只做调度，不干活"""
    
    def handle(self, user_request: str):
        """收到用户请求 → 拆解 → 调度 → 汇总"""
        # 1. 拆解任务（LLM判断需要哪些Worker）
        plan = self.plan(user_request)   # [{"worker": "quoting", "action": "calc_rate", "params": {...}}, ...]
        
        # 2. 按序调度（前一步结果喂给后一步）
        results = {}
        for step in plan:
            worker = self.workers[step["worker"]]
            # 把上一步结果并入参数
            step["params"].update(results)
            result = worker.handle(step["action"], step["params"])
            results[step["action"]] = result
            # 失败则兜底重试
            if result["status"] == "failed" and result["retryable"]:
                result = self.retry(worker, step, 3)
        
        # 3. 汇总返回
        return self.summarize(results)
    
    def retry(self, worker, step, max_retries):
        """兜底：失败重试，重试仍失败则上报"""
        for i in range(max_retries):
            result = worker.handle(step["action"], step["params"])
            if result["status"] == "ok":
                return result
        return {"status": "failed", "error": f"worker {step['worker']} failed after {max_retries} retries"}

关键设计：

• Supervisor的上下文只装「调度逻辑」（怎么拆、怎么排、怎么协调），不装「业务知识」（怎么算运费）
• Worker的上下文只装「业务知识」，不装「调度逻辑」
• 两者上下文各自干净，互不污染

---

四、收益：从「混乱协作」到「有序流水线」

维度	平级协作	Supervisor架构
执行顺序	混乱（抢跑）	有序（经理排）
冲突处理	无仲裁	经理裁决
失败兜底	无（卡死）	经理重试
任务追踪	难	经理统一记录
上下文干净度	低（混决策）	高（职责分离）

实践结论：Supervisor架构的价值不是「多一层」，而是「把决策从工人手里拿回来，交给专职经理」——每个Agent上下文更干净，整个系统更可控。

---

五、何时用Supervisor，何时平级就行

平级就够了：2-3个Agent，任务简单，无复杂依赖——平级省一层

必须Supervisor：

1. 5+个Agent（人多必须管理）
2. 任务有先后依赖（顺序错了全错）
3. 需要统一审计/追踪（企业要求）
4. 冲突可能频繁发生

---

六、此刻的你

此刻的你，已经从「拆了一堆Agent让他们自己商量」的天真，进化到「给Agent团队配了经理」的成熟。

Supervisor架构，是多Agent系统从「能协作」到「可靠协作」的分水岭。它不复杂——就是一个「只调度不干活」的Agent——但正是这个「什么都不干」的经理，让整个系统变得有序、可控、可追踪。

记住：Agent团队和人类团队一样——不是人越多越好，是有序组织才有效率。Supervisor就是那个让「多」变「有序」的经理。

---

️ 实体：Supervisor, Worker, 调度Agent, 任务编排 价值：有序执行, 冲突裁决, 失败兜底, 统一追踪 认知：从「平级协作」到「经理+工人」——多Agent系统的组织学