多Agent 协作——Supervisor-Worker 模式的实战经验

一、为什么要从单 Agent 走向多 Agent

单 Agent 能解决很多问题。但当任务变复杂时，一个 Agent 什么都要管，会遇到三个瓶颈。

瓶颈 1：上下文膨胀

假设你让一个 Agent 同时做三件事：查询数据库获取报表 → 分析数据找出异常 → 写一份分析报告。

每件事有自己的中间结果。这三件事的上下文全部挤在同一个上下文窗口里。Token 很快涨到上限，Agent 开始丢信息——它在写报告时"忘记"了 SQL 查出来的关键数据点。

更糟的是： 即使上下文窗口够大（128K、1M），注意力衰减也在起作用。模型对窗口中间部分的关注度远低于开头和结尾。大量有用信息实际上处于"存了但看不到"的状态。

瓶颈 2：工具集冲突

Agent 的工具越多，调用正确工具的难度越大。数据库查询、数据库写入、文件读取、文件写入、Web 搜索、代码执行——混合使用时，Agent 可能在执行一个"只查数据"的任务时意外调用了写入工具。

经验： 工具集超过 6 个时，误调用率明显上升。

瓶颈 3：关注点混杂

业务逻辑、工具调用、输出格式化——全在同一个推理过程中。改一个地方的影响不可控。关注点分离不仅适用于代码设计，也适用于 Agent 设计。

二、Supervisor-Worker 模式详解

Supervisor（总设计师）的职责：

• 任务拆解： 把一个大目标拆成多个独立的子任务。好的拆解：每个子任务边界清晰、产出明确、不重叠。
• 工具集配置： 给每个 Worker 只分配它需要的工具。
• 结果回收： 等所有 Worker 完成后，把结果组合成一致的输出。
• 异常处理： 如果 Worker 失败，决定是重试、换人、还是降级处理。

Worker 的职责只有一个：完成分配给它的任务，返回结果。它不需要知道其他 Worker 在做什么。

实战案例：entos.top 网站改造

在今天（2026.07.07）的 entos.top 改造中，这个模式反复使用：

Supervisor（Hermes Agent）
  用户需求："创建学习路径、Harness、记忆系统三个页面"

  ├── Worker A：创建学习路径页面（四阶段路线图）
  ├── Worker B：创建 Harness 落地页（四维卡片+案例）
  └── Worker C：创建记忆系统落地页（三层模型+文章规划）

  三个 Worker 并行工作。
  完成后 Supervisor 做一致性检查：
  - 导航链接是否正确
  - 风格是否统一
  - 有没有重复或遗漏

结果：三个页面在约 2 分钟内全部完成，0 处返工。每个 Worker 的上下文只有自己那一个页面的信息。

三、三种协作模式

1. 并行分发（Fan-out）

Supervisor 同时启动多个 Worker，等到全部完成后汇总。适合多个独立子任务。

真实场景： 多个独立页面并行创建、同时查询多个数据源、批量生成多份文档。

2. 流水线（Pipeline）

前一个 Worker 的输出作为下一个的输入。适合有明确前后依赖的任务。

真实场景： ETL 流程（提取→转换→加载）、数据处理流水线（抓取→清洗→分析→可视化）。

3. 动态委派（Dynamic Delegation）

Supervisor 根据执行结果动态决定下一步谁来做。适合需要容错的场景。

真实场景： 调试排查（先查日志→没找到再查DB→再没找到查上游API）、需要权限分级的操作。

四、三个关键问题

怎么分任务

好的任务单元：边界清晰、产出明确、自包含。

怎么汇总结果

在任务拆解阶段就约定输出格式。让所有 Worker 用同一套模板返回结果。

出错怎么办

可恢复错误（超时、临时故障）→ 重试。不可恢复（没权限、数据不存在）→ 降级用默认值替代。可选任务失败 → 跳过。

五、什么时候用多Agent

关联阅读： MCP 协议 · 三种编排模式