#Supervisor 调度式多 Agent

#提出问题

Supervisor 调度式多 Agent 是最常见的多 Agent 架构。

它的基本思路是：一个主控层接收用户目标，拆成多个子任务，分配给不同 Agent，收集结果，再决定下一步。这个主控层可以是一个 LLM Agent，也可以是程序化 Orchestrator，也可以是两者组合。

它解决的问题不是“让 Agent 互相聊天”，而是让复杂任务有一个明确的责任中心。

#场景

看一个研发自动化任务：

帮我给项目加一个团队成员邀请功能，包括接口、前端入口、权限校验和测试。

这个需求会牵涉多个区域：

• 后端接口和数据模型。
• 前端页面、表单和状态。
• 权限规则。
• 邮件或通知工具。
• 单元测试和集成测试。
• 最终代码审查。

如果一个 Agent 从头做到尾，容易出现两个问题：它要同时记住所有模块上下文，执行到后面可能忘记前面的约束；它也缺少独立审查视角。

Supervisor 可以这样组织：

这套架构里，Supervisor 不是简单转发消息。它负责决定任务边界、上下文切片、执行顺序、冲突处理和最终交付。

#分析问题

#Supervisor 的职责

Supervisor 至少承担六类职责。

Supervisor 可以是模型，但很多能力最好程序化实现，例如状态机、预算、权限、并发、重试和审计。模型更适合做任务理解、拆分建议和结果解释。

#任务拆分方式

Supervisor 拆任务时，不能只按“角色名”拆，要按依赖关系和写入边界拆。

研发任务通常适合“按模块 + 按阶段”混合拆分：先由 Architecture Agent 给出接口契约，再让 Backend 和 Frontend 并行，最后由 Test 和 Review 收尾。

#收益和成本判断

Supervisor 架构的收益是控制感强：

• 子任务边界清楚。
• 可并行执行。
• 每个 Agent 可以使用不同 prompt、模型和工具。
• Supervisor 可以统一记录状态和成本。
• Review 和执行可以分离。

成本也不低：

• 需要设计任务协议和输出格式。
• 需要解决子任务依赖和文件冲突。
• 需要合并不同 Agent 的结果。
• Supervisor 本身可能误拆任务。
• 多轮调度会增加延迟。

因此，Supervisor 架构适合中高复杂度任务，不适合短小问答或强实时链路。

#列举方案

#最小实现

最小 Supervisor 不需要一开始就做复杂框架。可以从结构化任务表开始。

type SubTask = {
  id: string;
  title: string;
  owner: "architect" | "backend" | "frontend" | "tester" | "reviewer";
  input: string;
  expectedOutput: string;
  dependencies: string[];
  allowedTools: string[];
  status: "pending" | "running" | "done" | "failed";
};

一次 run 的流程可以是：

1. 用户输入目标。
2. Supervisor 生成任务列表。
3. 程序校验任务是否越权、是否过大、是否有循环依赖。
4. 独立子任务并行执行。
5. 依赖任务等待上游结果。
6. Supervisor 合并输出。
7. Reviewer 检查最终结果。
8. 需要写入或发布时进入人工确认。

#程序化 Orchestrator

更稳的生产方案，是让程序控制主流程，让模型只在必要节点参与。

这种方式更像工作流系统：Agent 是 Worker，Supervisor 的关键控制逻辑在程序里。

#LLM Supervisor

如果任务拆分本身高度动态，可以让 LLM 参与 Supervisor 决策。但要限制它的输出格式。

Supervisor 不应该直接生成自由文本计划，而应该输出结构化任务图：

{
  "goal": "实现团队成员邀请功能",
  "tasks": [
    {
      "id": "design-api",
      "owner": "architecture",
      "expectedOutput": "接口契约、权限规则、数据影响",
      "dependencies": []
    },
    {
      "id": "backend-impl",
      "owner": "backend",
      "expectedOutput": "后端补丁和测试结果",
      "dependencies": ["design-api"]
    }
  ],
  "riskReviewRequired": true
}

程序再校验任务数量、依赖、工具权限和预算。LLM 可以建议，系统负责批准。

#混合 Supervisor

最常见的生产形态是混合：

• LLM 负责理解意图、建议拆分、解释结果。
• 程序负责状态机、权限、预算、任务队列、并发和审计。
• 人类负责高风险动作确认和最终方向调整。

这样既利用模型的灵活性，也避免把系统控制权完全交给模型。

#决策判断

#方案选型表

#反模式

第一种反模式：Supervisor 只负责转发，不负责决策。

如果主控层不处理任务边界、依赖、预算和冲突，它只是聊天中继。真正的复杂性仍然留给最后的人类。

第二种反模式：子 Agent 自己抢任务。

生产系统里，任务分配应该由 Orchestrator 控制。让多个 Agent 自行认领任务，容易重复劳动和遗漏关键节点。

第三种反模式：没有写入边界。

多个 Worker 同时修改同一文件、同一数据库对象或同一业务状态时，冲突会变成常态。任务拆分时要明确写入范围。

第四种反模式：Supervisor 过度相信子 Agent。

子 Agent 的输出应该包含证据、变更摘要、风险和测试结果。Supervisor 不能只看一句“完成了”。

第五种反模式：没有失败策略。

子 Agent 失败时，系统要知道是重试、换 Agent、缩小任务、降级为人工，还是终止整轮任务。

#结论收束

Supervisor 调度式多 Agent 的价值，是给复杂任务一个清楚的责任中心。

它适合任务可拆、依赖可表达、结果需要合并的场景。真正可靠的 Supervisor 不是一个“更聪明的主 Agent”，而是一个结合模型判断和程序控制的编排层。

#工程清单

• 任务图：子任务、依赖、状态、完成条件是否结构化。
• 角色定义：每个 Agent 的职责、输入、输出是否明确。
• 上下文切片：每个 Agent 是否只拿到必要信息。
• 工具权限：每个任务是否绑定允许工具，而不是 Agent 全局拥有工具。
• 并发策略：哪些任务可并行，哪些必须等待。
• 写入边界：文件、数据库、业务对象是否避免多人同时写。
• 输出契约：子 Agent 是否返回证据、风险、变更、测试结果。
• 合并策略：结果冲突时如何判断和处理。
• 失败策略：重试、降级、换 Agent、人工接管是否明确。
• 审计回放：能否还原 Supervisor 的拆分、分配和决策过程。