跳到主要内容

Supervisor模式

1. 定义与边界​

Supervisor 模式是由一个中央调度者负责理解任务、选择子 Agent、分配子任务、汇总结果、处理失败和控制预算的多 Agent 架构。子 Agent 通常被包装成工具或受控 worker，Supervisor 决定何时调用它们。

它适合需要集中控制和审计的场景，但不适合所有协作问题。如果 Supervisor 承担了全部推理、全部上下文和全部工具选择，系统实际会退化为一个复杂单 Agent。

2. 为什么重要​

Supervisor 的价值：

  • 限制子 Agent 只看到必要上下文。
  • 按职责隔离工具和权限。
  • 统一预算、重试、超时和错误处理。
  • 集中记录 trace，便于审计。
  • 对多 Agent 输出做裁决和汇总。

代价：

  • Supervisor 成为单点瓶颈。
  • 路由错误会影响整体结果。
  • 子 Agent 输出质量差时，Supervisor 可能无法发现。
  • 中央上下文容易膨胀。

3. 核心机制​

Supervisor 通常执行以下循环：

  1. 解析用户目标和约束。
  2. 生成或选择计划。
  3. 根据计划选择子 Agent。
  4. 向子 Agent 发送结构化任务。
  5. 验证子 Agent 输出和 artifact。
  6. 汇总、继续调用、重试或请求人工输入。
  7. 输出最终结果并记录 trace。

4. 架构/流程​

两种实现方式：

方式说明适用
子 Agent 工具化Supervisor 把每个子 Agent 当作可调用工具集中控制强、子任务边界清晰
显式状态图每个 Agent 是图节点，Supervisor 或规则决定边需要可视化流程、复杂状态恢复

LangChain/LangGraph 文档中常见的 supervisor pattern 是“中心 Agent 调用子 Agent 工具”；Google ADK 文档也描述了 LLM-driven delegation 和 workflow agents；Microsoft AutoGen 的 Teams 提供了 RoundRobin、Selector 等多 Agent 组织方式。

5. 工程实现​

Supervisor 子 Agent 工具化示例：

class Supervisor:
    def __init__(self, workers, policy, trace):
        self.workers = workers
        self.policy = policy
        self.trace = trace

    async def run(self, task):
        state = init_state(task)
        while not done(state):
            action = await self.select_action(state)
            self.policy.authorize(action, state)

            if action.type == "call_worker":
                result = await self.workers[action.worker].run(action.input)
                self.trace.record_worker_result(action.worker, result)
                state = merge_result(state, result)
            elif action.type == "ask_human":
                return ask_human(state, action)
            elif action.type == "final":
                return finalize(state)
        return finalize(state)

Supervisor 输出结构：

{
  "next_action": "call_worker",
  "worker": "researcher",
  "reason": "缺少官方来源，需要先核对",
  "input": {
    "question": "核对 AutoGen Teams 的官方能力",
    "source_policy": "official_only"
  },
  "budget": {
    "max_tool_calls": 4,
    "timeout_ms": 45000
  }
}

6. 生产实践​

  • Supervisor 不要接收所有原始资料全文，只接收摘要和 artifact 引用。
  • 子 Agent 输出必须带状态：done、partial、failed、needs_input。
  • 子 Agent 失败时区分可重试错误、输入不足和安全拒绝。
  • 对每个 worker 设置单独 SLO 和预算。
  • 对 Supervisor 的路由决策做离线评测。
  • 对高风险 worker 调用加入策略审批或人类在环。
  • 如果 Supervisor 依赖 LLM 选择工具，必须有最大轮数和 fallback。

7. 常见反模式​

反模式风险修正
Supervisor 负责所有细节中央上下文爆炸子 Agent 产出结构化摘要
子 Agent 没有独立评测无法知道瓶颈在哪每个 worker 单独 eval
Supervisor 相信 worker错误被汇总放大增加验证和 Reviewer
只用自然语言路由不稳定、难复盘结构化 action schema
没有单 Agent 降级依赖故障时不可用保留简化路径

8. 评测方法​

Supervisor 评测关注路由和汇总：

  • 路由准确率：是否选择正确 worker。
  • 计划有效率：子任务是否覆盖目标且无明显冗余。
  • 汇总忠实度：最终答案是否忠实于 worker artifact。
  • 恢复能力：worker 失败后是否能重试、替代或请求人类。
  • 预算遵守率：是否超 token、工具调用、时间或成本预算。
  • 单点风险：Supervisor 故障时是否有降级路径。

评测集应包含跨领域任务、模糊任务、worker 返回错误、worker 返回冲突结论、工具超时和恶意工具结果。

9. 安全与治理​

  • Supervisor 必须执行最小权限策略，而不是让 worker 自行决定权限。
  • 高权限 worker 调用前要检查用户身份、动作类型、数据范围和审批状态。
  • Supervisor 不应把所有敏感上下文传给所有 worker。
  • Worker 返回的外部内容不能直接进入最终结果，应标注来源并由 Reviewer 复核。
  • Trace 中要记录 Supervisor 的路由理由，便于事故复盘。

10. 工程手册补充​

10.1 Supervisor 上线边界​

Supervisor 模式适合“中心调度、分工明确、需要统一裁决”的任务；不适合只是给小任务套多个角色。

supervisor_policy:
  max_workers_per_run: 4
  max_handoffs: 8
  require_artifact_for_completion: true
  conflict_resolution: evidence_first
  worker_context:
    mode: scoped
    include_shared_facts: true
    include_other_worker_private_notes: false
观测点用途
assignment_reason解释为什么分给某个 worker
worker_artifact_count判断 worker 是否产生有效工作
merge_decision审计为什么接受或拒绝结果
handoff_count发现调度空转
supervisor_override记录中心裁决

失败恢复：

  • Worker 失败：重试同 worker、换 worker、缩小任务或人工接管。
  • Supervisor 裁决不稳定：冻结自动 merge，进入人工 review。
  • 共享状态污染：回滚到上一 checkpoint，重放 accepted artifacts。
  • 成本超预算：保留已完成 artifact，降级为单 Agent 汇总。

11. 权威资料​