《AI Agent原理与实战》2026版 第22课 编排实战：Supervisor 与 Orchestrator-Worker

本文收录于专栏《AI Agent原理与实战》2026版—— 专栏系统覆盖 AI Agent 的记忆、工具、插件与实战，点击订阅可跟踪后续更新。

本课定位：组织学落地为两种主力编排：Supervisor 串行调度与 Orchestrator-Worker 并行分发。本课深挖 Anthropic 多 Agent 研究系统的八条生产教训，然后亲手复刻 mini Deep Research——本课程项目线的第三级。

阶段 4｜多智能体系统 ｜ 来源：【补 ｜ Anthropic《How we built our multi-agent research system》】+ 微软第 8 课模式映射

关键字：Agent编排、Supervisor模式、Orchestrator-Worker、串行调度、并行分发、Deep Research、多Agent实战、结果汇总

本节目录

• 22.1 两种编排模式的分工逻辑
• 22.2 Supervisor：串行调度，按需分派
• 22.3 Orchestrator-Worker：并行分治，压缩回传
• 22.4 Anthropic 多 Agent 研究系统：架构与数据
• 22.5 八条工程教训（生产经验全文提炼）

概念讲解

22.1 两种编排模式的分工逻辑

22.2 Supervisor：串行调度，按需分派

Supervisor 是一个"只会派活和收活"的中央 Agent。它维护任务清单，每一轮决定下一步交给谁、带上什么上下文；worker 完成后结果回到 Supervisor，再决定下一步。特点：

• 控制点集中：所有信息流经一处，天然适合加审批、限流、人工确认闸门（第 25 课）。
• 串行为主：worker 依次发言，适合流程有依赖、需要逐步推进的任务。
• 弱点：Supervisor 的上下文窗口是全系统瓶颈——所有中间结果都要在这里汇总；worker 数量多、任务长时会被窗口和 token 双重挤压。

22.3 Orchestrator-Worker：并行分治，压缩回传

Orchestrator 同样是中央 Agent，但派活方式是"一把撒出去"：把任务切成 N 份同时派给 N 个子 Agent，各自在独立上下文窗口里探索，完成后只回传压缩后的发现。特点：

• 并行度最高：Anthropic 实测两类并行化（主 Agent 并行起 3-5 个子 Agent + 子 Agent 每轮并行调 3+ 个工具）让复杂研究耗时下降最高 90%。
• 上下文隔离彻底：子 Agent 的海量探索过程（搜索、翻页、筛选）都消耗在自己的窗口里，主 Agent 只接收结论。
• 弱点：结果合并难（多份结论可能有矛盾）；子 Agent 失控风险（简单问题起 50 个子 Agent 就是 Anthropic 早期真实翻车现场）。

选择口径：流程依赖重、需要逐步确认 → Supervisor；子任务独立、追求吞吐 → Orchestrator-Worker。研究类任务（广度优先、多方向并行探索）是后者典型场景；编码类任务（强依赖、共享代码上下文）更适合单 Agent 或 Supervisor 轻量协调。

与微软第 8 课的模式语言对照（微软·8）：微软的Hand-off（移交）模式——每个 Agent 代表工作流一步、按预定义规则交接任务——正是 Supervisor 拓扑在业务流程里的具象化（客服转技术支持就是最典型 hand-off 链）；微软的Group chat（群聊）模式（可集中路由也可去中心互发）对应"worker 共享一条对话流"的 supervisor 变体；而"集中式/去中心式/混合怎么选"本身就是微软六大构建块里的第五块"多 Agent 模式选择"（微软·8）——本课两种模式就是这个决策在编排层的答案。微软还提醒编排设计别漏了第六块人机回路（微软·8）：Supervisor 的集中控制点天然适合挂人工确认闸门（用户指定要某家酒店、下单前确认），这在第 25 课会展开成完整的边界设计。

22.4 Anthropic 多 Agent 研究系统：架构与数据

Anthropic 2025 年 6 月公开的 Research 功能架构是 Orchestrator-Worker 的生产级范本，完整流程：

用户提问 │ ▼ LeadResearcher（主Agent） 1. 思考并制定策略 → 计划写入外部 Memory（防 200K 窗口截断丢计划） 2. 并行创建 3-5 个 Subagent（每个带四要素任务说明：目标/输出格式/工具指引/边界） 3. Subagent 各自: 并行 web 搜索 → interleaved thinking 评估结果 → 补查 → 回传压缩发现 4. LeadResearcher 综合结果, 判断是否需要追加子Agent (研究循环) 5. 信息充分 → 退出循环, 全部发现交给 CitationAgent 6. CitationAgent 为报告逐条定位引用来源 │ ▼ 带引用的最终研究报告

几个关键实测数据（均出自原文，检索日 2026-10-01）：

「token 用量解释 80% 方差」这条发现值得单独展开：它说明多 Agent 系统提升性能的第一性原理是用并行窗口把有效 token 花够，而非"多个智能体涌现出群体智慧"。这直接解释了为什么多 Agent 对"广度型"任务（如"列出标普 500 信息技术板块所有公司的董事会成员"）提升巨大——单 Agent 串行搜索慢到超时，多 Agent 分解后每个子 Agent 只需查几家公司；而对深度依赖型任务收益有限。

22.5 八条工程教训（生产经验全文提炼）

Anthropic 文章的主体是八条提示工程教训，逐条提炼并标注课程回指：

1. 像你的 Agent 一样思考（Think like your agents）：在 Console 里用与生产完全相同的提示+工具跑模拟，逐步观察 Agent 行为。失败模式当场可见：结果已够还在继续搜、查询词过长过窄、选错工具。
2. 教协调者如何委派（Teach the orchestrator how to delegate）：子任务说明必须含目标、输出格式、工具与来源指引、任务边界四要素（第 21 课因子 1）。指令太短 → 子 Agent 重复劳动或漏查。
3. 努力程度随复杂度缩放（Scale effort to query complexity）：把缩放规则写进提示——简单事实查询用 1 个 Agent 调 3-10 次工具；直接对比类 2-4 个子 Agent 各 10-15 次；复杂研究 10+ 个子 Agent 分工明确。早期版本对简单问题过度投入是高频失败模式。
4. 工具设计与选择是关键（Tool design and selection are critical）：给 Agent 显式启发式——先看全部可用工具、工具匹配用户意图、外部大范围探索用 web 搜索、专用工具优先于通用工具。差工具描述会把 Agent 带进完全错误的方向（量化：修复后 -40% 完成时间）。
5. 让 Agent 自我改进（Let agents improve themselves）：Claude 4 系模型给一份提示+失败模式就能诊断原因并改提示；Anthropic 甚至建了"工具测试 Agent"反复试用有缺陷的 MCP 工具并重写其描述。
6. 先广后窄（Start wide, then narrow down）：Agent 默认写又长又窄的查询导致结果寥寥。提示里要求先短而宽的查询、评估可得信息、再逐步收窄——模仿人类专家的检索策略。
7. 引导思考过程（Guide the thinking process）：扩展思考（extended thinking）当可控草稿纸。主 Agent 用思考做规划（选工具、判断复杂度、定子 Agent 数量与分工）；子 Agent 在工具结果后用 interleaved thinking 评估质量、找缺口、定下一步查询。
8. 并行工具调用改变速度与性能（Parallel tool calling transforms speed and performance）：两级并行化（见上表 -90%）。这是架构级决策，不是提示技巧。

八条之外，附录里三条补充同样生产级：终态评估（评最终状态对不对而非逐步骤对不对——Agent 可能走不同但同样有效的路径）；长对话管理（阶段总结落盘外部记忆，接近窗口上限时用干净上下文的子 Agent + 精心交接续命）；产物落文件系统（子 Agent 大产出直接写外部存储、回传轻引用，绕开"传话游戏"）。

生产可靠性一节的三条教训（错误复合需断点恢复、全链路 tracing 才能定位"为什么没找到"、彩虹部署避免更新杀死运行中 Agent）将在第 26 课展开。注意这里的"全链路 tracing"正是微软第 8 课可观测性三件套（日志监控/可视化/性能指标，微软·8）的生产级升级版：微软的"每个 Agent 动作记一条日志（谁/什么动作/何时/结果）"落到 Anthropic 这里就是全量事件 trace；微软的"信息流可视化"对应 Anthropic 监控 Agent 决策模式与交互结构；微软的"性能指标"对应研究时长、token 消耗、评测胜率。两套话语指向同一个工程事实：多 Agent 系统没有可观测性就没有可调试性（微软·8 + Anthropic）。

案例实战：mini Deep Research

• 目标：无框架复刻 Anthropic Research 功能的最小骨架——LeadResearcher 规划 → 并行 Subagent 检索（模拟工具）→ CitationAgent 引用 → 综合。总代码约 130 行，OpenAI 兼容 API 即可跑。
• 运行环境：Windows 10/11 / macOS / Linux 均可；Python ≥ 3.10；pip install "openai>=1.30"。模型三选一（2026-10 实测可通）：DeepSeekhttps://api.deepseek.com（deepseek-chat）/ MiniMaxhttps://api.minimaxi.com/v1（MiniMax-M2）/ 智谱 GLMhttps://api.z.ai/api/coding/paas/v4（glm-4.7-flash）——接入方式与坑同第 21 课案例（brotli 头、reasoning_content降级、429 重试，此处复用ask()实现不再重复）。
• 与第 21 课案例的差异：并行（asyncio.gather）+ 努力程度缩放规则 + 引用定位。这里检索用模拟工具（返回预置文本），把重点放在编排结构上；接真实搜索 API 是第 7 课工具调用模式的直接套用。第 24 课综合项目会用 DeepSeek 实测版跑真实 LLM 决策。

# mini Deep Research【已实测——2026-10 于 Linux (Ubuntu 22.04, Python 3.10, openai 3.6.0)# deepseek-chat 全流程跑通 (规划→并行检索→综合→引用); 模型接入层与第21课案例共用】# 依赖：openai>=1.30；Python>=3.10；编排模式=Anthropic orchestrator-worker 复刻importjson,asynciofromopenaiimportAsyncOpenAI client=AsyncOpenAI(api_key="YOUR_API_KEY",# env: DEEPSEEK_API_KEY / MINIMAX_CN_API_KEY / GLM_API_KEYbase_url="https://api.deepseek.com",default_headers={"Accept-Encoding":"gzip, deflate"})MODEL="deepseek-chat"MAX_SUBAGENTS,MAX_TOOL_CALLS,TOKEN_BUDGET=5,10,200_000# 失控防控三闸门# ── 模拟检索工具（替换成真实 search API 即为完整版） ──────────────FAKE_CORPUS={"multi-agent framework":"AutoGen 0.4+ (微软) 事件驱动架构; CrewAI 角色制; MetaGPT SOP制 (检索日 2026-10 口径)","orchestrator-worker":"Anthropic Research: 并行3-5子Agent, 计划先落Memory, CitationAgent负责引用","token cost":"Anthropic 实测: 多Agent约为普通对话15倍token; 单Agent约4倍",}asyncdefweb_search(query:str)->str:hits=[vfork,vinFAKE_CORPUS.items()ifk.split()[0].lower()inquery.lower()]return"\n".join(f"[{i+1}]{h}"fori,hinenumerate(hits))or"[1] (无相关结果)"asyncdefask(system:str,user:str)->str:r=awaitclient.chat.completions.create(model=MODEL,temperature=0.2,messages=[{"role":"system","content":system},{"role":"user","content":user}])returnr.choices[0].message.content# ── 1. LeadResearcher: 规划 + 缩放规则 ────────────────────────────LEAD=f"""你是研究主Agent。分析用户问题复杂度并制定子Agent分工。 努力程度缩放规则: 简单事实→1个子Agent; 对比类→2-3个; 复杂研究→最多{MAX_SUBAGENTS}个。 输出 JSON: {{"complexity":"simple|compare|complex","plan":"一句话策略","subtasks":["每个含目标/输出格式/工具指引/边界"]}}"""# ── 2. Subagent: 并行检索 + 压缩回传 ──────────────────────────────SUB="""你是研究子Agent。任务：{task} 循环最多 {max_calls} 次工具调用: 生成宽查询→调 web_search→评估→必要时收窄再查。 完成后只回传: 1)关键发现(每条带来源编号) 2)信息缺口。不超过200字。"""asyncdefsubagent(task:str)->str:findings,calls=[],0q=task[:40]# 先宽后窄的宽起点whilecalls<MAX_TOOL_CALLS:# 失控防控: 单子Agent工具调用上限calls+=1result=awaitweb_search(q)findings.append(result)ev=awaitask("评估检索结果是否已覆盖任务目标, 只输出 enough 或 narrow:<新查询>",f"任务:{task}\n结果:{result[-500:]}")ifev.startswith("enough"):breakq=ev.split(":",1)[-1]# 收窄再查returnawaitask("综合以下检索记录回传关键发现+缺口","\n".join(findings))# ── 3. 主流程: 并行 fan-out → 综合 → 引用 ─────────────────────────asyncdefresearch(question:str)->str:plan=json.loads(awaitask(LEAD,question))# 教训1/3: 规划+缩放subs=plan["subtasks"][:MAX_SUBAGENTS]# 失控防控: 子Agent数量上限found=awaitasyncio.gather(*(subagent(t)fortinsubs))# 教训8: 并行 fan-outdraft=awaitask("你是综合器。基于子Agent发现写研究报告草稿, 每条事实标注[子任务#]。",json.dumps({"q":question,"findings":found},ensure_ascii=False))cited=awaitask("你是CitationAgent。检查草稿中每个[来源]标记是否真实存在于发现列表, ""移除无依据论断, 输出终稿+引用列表。",draft)returncitedif__name__=="__main__":print(asyncio.run(research("多Agent系统的token成本与并行收益如何权衡?")))

• 实测记录（2026-10，Linux/Ubuntu 22.04 + Python 3.10 + openai 3.6.0 + deepseek-chat）：规划器把问题判为 complex 派出 5 个子 Agent 并行检索（asyncio.gatherfan-out 生效），综合器产出带[子任务#]标注的草稿，CitationAgent 完成逐条引用核对并在报告尾部输出引用列表——值得注意的是它还主动指出了"证据来源单一、高度重复"的缺口，这个行为与 Anthropic 系统的 CitationAgent 设计意图一致。
• 步骤：① Windows 下setx DEEPSEEK_API_KEY "sk-xxx"（Linux/macOS 用export）→ ②pip install "openai>=1.30"→ ③ 跑默认问题，对照上面的实测记录 → ④ 改问一个简单事实问题，观察缩放规则只派 1 个子 Agent → ⑤ 把FAKE_CORPUS换成真实搜索 API（第 7 课），即得完整 Deep Research。
• 预期输出：带[子任务#]标注的研究报告 + 引用核对后的终稿。终端无进度输出时，可在subagent里加print(task, calls)观察并行与先广后窄行为。
• 要点回看：计划四要素（教训 2）、缩放规则（教训 3）、先广后窄（教训 6）、两级并行（教训 8）、CitationAgent 独立角色（真实系统同款）全部落进代码。三闸门MAX_SUBAGENTS / MAX_TOOL_CALLS / TOKEN_BUDGET是失控防控的最低配置（第 24 课展开预算守卫实现，并附 DeepSeek 真实决策的实测记录）。

小结

• Supervisor 适合流程依赖重、要逐步确认的任务；Orchestrator-Worker 适合子任务独立、追求吞吐的任务——研究是后者的招牌场景。
• Anthropic 生产数据三记重锤：多 Agent +90.2% 研究评测、~15× token 成本、token 用量解释 80% 性能方差——多 Agent 的本质是用并行窗口把有效 token 花够，不是玄学涌现。
• 八条教训骨架：想 Agent 所想 / 委派四要素 / 努力缩放 / 工具即接口 / Agent 改提示 / 先广后窄 / 思考可控 / 两级并行。
• mini Deep Research 的最小骨架 = 规划（含缩放）→ 并行子 Agent（独立窗口+压缩回传）→ 综合 → 引用核对；失控防控三闸门（子 Agent 数、单 Agent 工具调用数、总 token 预算）从第一行代码就要有。
• 框架里对应的抽象（AutoGen 的 Teams、CrewAI 的 Crew、Agents SDK 的 agents-as-tools）见第 23 课；完整模拟项目见第 24 课。

扩展阅读

🌐 网络提示：anthropic.com 需代理（核心结论已摘进本课正文）；openai.com 系需代理（协议层知识已进正文，实测均可用国产端点替代）；pip 安装建议加清华镜像-i https://pypi.tuna.tsinghua.edu.cn/simple。详见总纲附录《国内网络访问与国产适配指南》。

• Anthropic《How we built our multi-agent research system》（本课主源，2025-06-13）：https://www.anthropic.com/engineering/multi-agent-research-system
• Anthropic 系统开源提示词（Cookbook，与本课架构配套）：https://platform.claude.com/cookbook/patterns-agents-basic-workflows
• Anthropic《Building effective agents》orchestrator-workers 模式：https://www.anthropic.com/engineering/building-effective-agents
• BrowseComp 基准（token 方差研究的评测源）：https://openai.com/index/browsecomp/

我的专栏