监督者模式

文档摘要

监督者模式本节摘要:一个首席 Agent 负责规划与派发,专职工人在各自干净的上下文里并行执行,再回报给首席综合——这就是监督者/编排者-工人(Supervisor/Orchestrator-Worker)模式,Anthropic 研究系统(Claude Opus 4 当首席、Sonnet 4 当子 Agent)的生产架构。它在内测研究评测上比单 Agent Opus 4 高 +90.2%,而 Anthropic 工程帖指出 BrowseComp 上 80% 的方差仅由 token 用量解释——多智能体赢,主要是因为每个子 Agent 拿到全新上下文窗口。

监督者模式

本节摘要:一个首席 Agent 负责规划与派发,专职工人在各自干净的上下文里并行执行,再回报给首席综合——这就是监督者/编排者-工人(Supervisor/Orchestrator-Worker)模式,Anthropic 研究系统(Claude Opus 4 当首席、Sonnet 4 当子 Agent)的生产架构。它在内测研究评测上比单 Agent Opus 4 高 +90.2%,而 Anthropic 工程帖指出 BrowseComp 上 80% 的方差仅由 token 用量解释——多智能体赢,主要是因为每个子 Agent 拿到全新上下文窗口。本节从原语搭出监督者模式,用 Python threading 实现三个并行工人,并覆盖 2026 年生产部署的工程教训:按查询复杂度伸缩、先宽后窄、彩虹部署、token 主导,以及三类典型失败(规划幻觉、过度探索、综合冲突)。

学习目标

阅读完本节,你应当能够:

解释监督者模式为什么赢(新鲜上下文、提示专精、并行)的三条机制。
用 Python threading 从零实现一个三工人监督者,并测量墙钟收益。
应用 Anthropic 的生产教训:按复杂度伸缩、先宽后窄、彩虹部署、token 主导。
识别三类失败(首席规划幻觉、工人过度探索、综合冲突)及其缓解。
判断何时不该用监督者(纯串行任务、简单查询、需严格确定性)。

一、问题与直觉

研究类任务是单 Agent 系统的典型翻车现场。你问「2023 到 2026 年多智能体系统有什么变化?」,单 Agent 顺序读五篇论文,把半张上下文塞满它们的原文,到第五篇时已忘了第一篇,且无法并行。

监督者模式修复它:一个首席 Agent 规划搜索,把每个子问题委派给一个工人,再综合。每个工人拿到自己的 20 万 token 窗口处理一个窄问题。首席从不见原始论文,只见工人摘要。

为什么赢:三条机制

每个子 Agent 拿新鲜上下文:探「FIPA-ACL 遗产」的工人不背首席规划时花的 4 万 token,它有 20 万窗口给一个问题。
用提示做专精:首席的提示是「分解与综合」,不是「研究」;每个工人的提示是窄的「找出 X 的变化」。聚焦提示产出聚焦输出。
并行:工人并发跑,墙钟约等于 max(工人耗时) + 规划 + 综合,而非 sum(工人耗时)。

工程教训(Anthropic 2025,2026 仍有效)

按查询复杂度伸缩:简单查询一个 Agent、3~10 次工具调用;复杂查询 10+ Agent。由首席估计,而非调用者。
先宽后窄:先分解成宽子问题,若答案值得深挖,再为子问题派生更多工人。
彩虹部署:Agent 长时运行且有状态,传统蓝绿不适用;Anthropic 用彩虹——新版本渐进上线、旧版本渐次排空。
token 主导:多智能体约为单 Agent 的 15 倍 token。仅当任务价值配得上成本时才跑。

⚠️ token 主导是这条模式的第一性约束:80% 的方差由 token 用量解释,而非模型选择。这意味着「上多智能体」本质是「花钱买上下文洁净度」——决策依据应是任务价值能否覆盖这 15 倍成本。

图原生的转向

LangGraph 原本提供 langgraph-supervisor 高层 create_supervisor 助手。2025 年 LangChain 把推荐改为直接用工具调用实现监督者,因为工具调用对「首席看到什么」(上下文工程)控制更细。库仍可用,文档现在推荐工具调用形式。

失败模式

首席规划幻觉:首席生成的子问题没真正分解原问题,工人对错误目标做了精确研究。
工人过度探索:没有显式作用域边界,工人漂出子问题、污染综合步骤。
综合冲突:两个工人返回矛盾事实。首席必须要么再问(加一轮),要么显式标注分歧。静默选一边是最坏失败——用户永远不知道发生过分歧。

何时监督者是错的

纯串行任务:步骤 2 字面依赖步骤 1 的输出时,并行毫无收益,用流水线(CrewAI Sequential、LangGraph 线性图)。
简单查询:单 Agent 更快更便宜。先过首席的「按复杂度伸缩」检查再派工人。
严格确定性:监督者用 LLM 选择委派;审计/重放比适应性重要时用静态图更好。

二、从零实现

code/main.py 用 threading 实现一个三并行工人的监督者,无真实 LLM——工人脚本化模拟「取数-摘要」。

首席与工人骨架


import threading, time

class Worker:
    def __init__(self, name): self.name = name
    def run(self, sub_q):
        time.sleep(0.3)                      # 模拟取数+摘要
        return {"sub_q": sub_q, "summary": f"{self.name} 对『{sub_q}』的发现"}

class Lead:
    def plan(self, query):
        # 分解成三个子问题(真实里是 LLM 调用)
        return [f"{query} · 维度{i}" for i in ("A","B","C")]
    def synthesize(self, results):
        return "综合: " + " | ".join(r["summary"] for r in results)
    def run(self, query, workers):
        sub_qs = self.plan(query)
        results = [None] * len(sub_qs)
        def task(i, w, q):
            results[i] = w.run(q)
        threads = [threading.Thread(target=task, args=(i, workers[i], sub_qs[i]))
                   for i in range(len(sub_qs))]
        for t in threads: t.start()
        for t in threads: t.join()           # 并行,墙钟≈max 而非 sum
        return self.synthesize(results)

设计要点:三个 0.3 秒的工人并行跑,墙钟约 0.35 秒而非 0.9 秒。但 spawn 有开销——工人太少时 spawn 成本可能吞掉并行收益(练习 1 会量化这个拐点)。

冲突检测(无 LLM 版)

综合前做一次轻量冲突检测,避免静默选边:


def detect_conflicts(results):
    # 简化:检测摘要中的数值互相矛盾(真实里可用嵌入相似度+差异)
    nums = [extract_numbers(r["summary"]) for r in results]
    # 若同一实体出现不同数值,标记冲突
    return find_contradictions(nums)

冲突存在时,综合里显式标注分歧而非悄悄挑一个——这是避免用户被蒙在鼓里的关键。

三、框架对比

实现	首席如何派发	工人如何回传	何时选
原生工具调用(2026 推荐)	首席的工具 schema 含「spawn_worker」,LLM 决定调谁、传什么	工具返回值即摘要,首席只见摘要不见原始上下文	想精细控制「首席看到什么」
LangGraph `create_supervisor`(legacy)	高层封装,自动接 LLM 选择	reducer 合并到共享状态	快速原型,接受其默认行为
CrewAI Hierarchical	manager LLM 派 Task 给 Agent	Task 输出链式进下一 Task	角色清晰、流程已建模
OpenAI Swarm 交接	首席通过交接工具转给工人	工人完成后交回首席	无状态、轻量协调
Anthropic 子 Agent(`Task`)	父 Agent spawn 子 Agent,scoped 任务	子 Agent 只回传摘要	主上下文需保持洁净

💡 心法:所有变体都遵循同一原则——首席只看摘要,不看原始上下文。 Anthropic 明确只把子答案(而非工人原始上下文)送进综合,这是 token 主导结论的工程落地:综合步骤的上下文越干净,质量越高。

四、可复用产物

outputs/skill-supervisor-designer.md:输入用户查询,产出监督者模式设计——首席系统提示、工人角色、子问题分解规则、综合模板。在构建新研究类 Agent 系统前先用它过一遍。

五、练习

拐点测量:跑 code/main.py,改首席派 5 个工人而非 3,观察墙钟。在演示中,工人数量到多少时 spawn 开销超过并行收益?
工人超时:实现工人超时——杀掉任何超过 0.5 秒的工人,首席综合剩余结果。要知道一个工人被砍,你需要哪些可观测性?
冲突检测:给综合加冲突检测步骤——两个工人返回矛盾答案时,首席标注分歧而非选一边。不用 LLM 如何检测矛盾?
读工程帖:读 Anthropic 研究系统工程帖,列出本玩具演示要跑进生产需采纳的三条实践。
工具调用 vs 库:对比 LangGraph create_supervisor(legacy)与新工具调用推荐。哪个对「首席看到什么」控制更好?为什么 Anthropic 只把子答案、不把工人原始上下文送进综合?

本节要点回顾

监督者模式 = 首席规划派发 + 工人并行执行 + 首席综合:首席从不见原始材料,工人各拿新鲜上下文。
三条赢的机制:新鲜上下文(主因)、提示专精、并行(墙钟 ≈ max 而非 sum)。
token 主导是第一性约束:80% 方差由 token 用量解释;上多智能体本质是花钱买上下文洁净度,决策看任务价值能否覆盖约 15 倍成本。
四条生产教训:按复杂度伸缩、先宽后窄、彩虹部署、token 主导。
图原生的转向:从高层 create_supervisor 库转向直接工具调用,以精细控制首席的可见上下文。
三类失败:规划幻觉(错目标精确研究)、过度探索(污染综合)、综合冲突(静默选边最坏)。
何时不用:纯串行任务(并行无收益)、简单查询(单 Agent 更快更便宜)、需严格确定性(用静态图)。
统一原则:首席只见摘要、不见原始上下文——这是 token 主导结论的工程落地。

下一节,我们延伸到层级架构——当监督者之上还有监督者,系统如何分层管理,以及这种层级固有的失败模式(信息逐级有损、级联错误)。