从 Agent 群聊到 Task OS：多 Agent 协作的产品设计范式

多 Agent 正在成为 AI 产品设计中的高频概念，但它经常被误解。

很多团队一提到 Multi-Agent，就会下意识地创建一组“数字员工”：产品经理 Agent、工程师 Agent、设计师 Agent、运营 Agent、增长 Agent，然后让它们像人类团队一样开会、讨论、分工、交付。

这不是生产级多 Agent 设计。

真正的多 Agent 产品设计，核心不是“造多少个 Agent”，也不是“角色名字是否像一个团队”，而是：

在任务复杂度、上下文隔离、工具边界、并行收益、状态管理、质量控制和风险治理之间做架构选择。

Microsoft 的 AI Agent Orchestration Patterns 明确把多 Agent 编排拆成 sequential、concurrent、group chat、handoff、magentic 等模式，并强调应该选择能满足需求的最低复杂度，而不是默认上复杂编排。OpenAI Agents SDK 也把多 Agent orchestration 定义为多个 Agent 如何运行、以什么顺序运行、如何决定下一步的控制流问题，而不是简单角色堆叠。

LangChain 的多 Agent 文档进一步指出，多 Agent 的核心是 context engineering：决定每个 Agent 能看到什么上下文、拥有什么工具、承担什么边界。Anthropic 在 Claude Research 的工程复盘中也强调，多 Agent 特别适合开放式研究、广度探索和多个方向并行推进，但它会显著增加 token 消耗，因此只适合价值足够高的任务。

所以，多 Agent 的第一原则不是“越多越好”，而是：

能用 Prompt 解决，就不要上 Agent；能用单 Agent 解决，就不要上多 Agent；能用 Pipeline 解决，就不要上 Swarm；能用状态机解决，就不要让 Agent 自由发挥。

Swarm 只是多 Agent 协作的一种形态，而且不是默认答案。真正成熟的产品形态，不是 Agent 群聊，而是 Multi-Agent Task OS。

从 Agent 群聊到 Multi-Agent Task OS：多 Agent 产品设计不是让数字员工开会，而是让复杂任务进入可控系统。 — 一张图看清楚：Swarm 是一种协作形态，但 Task OS 才是产品形态。

一、先给结论：12 种多 Agent 协作模式总表

#	模式	控制权结构	最适合场景	不适合场景	产品成熟度
1	Virtual Board	单 Agent 内模拟多角色视角	方案评审、战略判断、文章分析	真实并行、工具隔离、长任务	高
2	Pipeline / Sequential	按固定步骤顺序流转	内容生产、视频生产、SOP 流程	路径不确定、需要动态探索	很高
3	Router / Triage	入口分诊，路由到合适 Agent	客服、企业助理、多入口平台	深度执行、复杂长任务	高
4	Handoff / Swarm	Agent 之间动态转交控制权	客服、顾问、多能力 Copilot	强审计、高风险、严格流程	中
5	Orchestrator-Worker	主控拆解，Worker 执行	研究、代码、复杂任务	小任务、边界不清、低价值任务	很高
6	Hierarchical Orchestrator	多层主控逐级分发	大项目、多仓库、多团队流程	轻任务、无可观测系统	中
7	Fan-out / Fan-in	并行分头做，最后汇总	深度研究、投研、竞品、论文解析	强顺序依赖、共享写状态	很高
8	Council / Debate	多角色讨论，裁判收敛	产品评审、架构评审、风险判断	工具执行、高频低价值任务	中
9	Maker-Checker	生成者 + 审查者闭环	代码、合同、SQL、外发内容	验收标准不清、低价值任务	很高
10	Blackboard / Workboard	多 Agent 围绕共享状态协作	长任务、项目执行、异步协作	简单问答、一次性任务	高
11	Workflow / State Machine	状态机驱动 Agent 执行	企业流程、可恢复长任务、有 SLA 任务	创意发散、开放讨论	很高
12	Free Swarm	多 Agent 自由协作	创意探索、仿真、实验	生产交付、高风险、成本敏感任务	低

这 12 种模式不是互斥的。真正的产品系统往往会组合使用它们：

Router 判断任务类型
→ Pipeline 处理确定流程
→ Orchestrator 拆复杂任务
→ Fan-out 并行研究
→ Maker-Checker 做质量闭环
→ Blackboard 管理长任务状态
→ Workflow 负责恢复、重试和交付

这就是本文所谓的 Task OS。

12 种多 Agent 协作模式：Virtual Board、Pipeline、Router、Handoff、Orchestrator、Hierarchical、Fan-out、Council、Maker-Checker、Blackboard、Workflow、Free Swarm。 — 12 种模式的关键不是“哪个更酷”，而是哪个复杂度刚好够用。

二、为什么多 Agent 有价值？

在产品设计中，多 Agent 的价值不是“人多力量大”，而是解决单 Agent 在复杂任务中的五个瓶颈。

1. 专业化

单 Agent 同时承担太多能力、工具和知识时，prompt 会膨胀，工具选择会变差，行为边界会模糊。多 Agent 可以把任务拆成更小的专业单元，比如 Research Agent 只负责检索，Code Agent 只负责代码，Review Agent 只负责审查，Delivery Agent 只负责交付整理。

2. 上下文隔离

多 Agent 设计的中心是 context engineering，也就是决定每个 Agent 应该看到什么信息。这个判断非常关键：多 Agent 不是为了模拟组织，而是为了控制上下文边界。

例如：

Research Agent：只看研究问题和来源
Code Agent：只看仓库、issue、测试结果
Review Agent：只看产物、验收标准、风险清单
Delivery Agent：只看最终结构和交付格式

上下文越窄，行为越稳定。

3. 并行探索

多 Agent 尤其适合 breadth-first research，因为多个 subagent 可以用各自独立的上下文窗口同时探索不同方向，再由 lead agent 汇总。这个收益不是“开会讨论”带来的，而是来自并行搜索路径、上下文窗口和工具调用预算的扩展。

4. 工具边界隔离

当一个 Agent 拥有太多工具时，模型容易选错工具。把工具拆给不同 Agent，不只是架构清晰，也是安全边界。

5. 质量控制

多 Agent 可以通过 Maker-Checker、Debate、Reviewer、Human-in-the-loop 等机制提升交付质量。一个 Agent 生成，另一个 Agent 按明确标准审查，并设置最大迭代次数和失败兜底。

三、多 Agent 的缺陷：为什么不是越多越好？

多 Agent 不是免费智能。它会带来新的系统复杂度。

1. 成本更高

Anthropic 的工程复盘中有一个非常重要的数据：普通 agent 通常比 chat interaction 多用约 4 倍 token，多 Agent 系统约 15 倍。因此，多 Agent 只有在任务价值足够高、性能收益能够覆盖成本时才经济可行。

这意味着：

简单问答不该多 Agent
低价值任务不该多 Agent
用户只要快答时不该多 Agent
成本敏感任务不该默认多 Agent

2. 延迟更高

多个 Agent 之间需要分发、等待、汇总、审查，必然增加延迟。多跳通信是多 Agent 常见问题之一。

3. 状态更复杂

一旦多个 Agent 并行执行，系统就必须回答：谁拥有任务？谁能写状态？谁负责最终输出？哪个中间结果可信？哪个 Agent 失败后应该重试？

4. 更难调试和评估

单 Agent 出错，只需要看一个上下文。多 Agent 出错，要检查任务拆解、Agent 选择、子任务描述、工具调用、中间产物、汇总逻辑、审查逻辑和停止条件。

5. 容易过度设计

使用不必要的复杂编排、添加没有真实专业化价值的 Agent、对确定性任务使用非确定性模式，都是常见反模式。

所以，多 Agent 设计的底线是：

不要为了展示多 Agent 而多 Agent。

多 Agent 会带来成本、延迟和状态复杂度上升，必须有日志、任务状态、产物、成本、错误和 owner。 — 没有 run log、task state、artifact、cost、error、ownership 的多 Agent 产品，本质上是黑箱。

四、12 种多 Agent 协作模式详解

1. Virtual Board：虚拟圆桌模式

Virtual Board 不一定是真多 Agent，而是在一个 Agent 内部模拟多个专家视角。

产品架构师
技术架构师
商业化分析师
反方审查员
最终裁判

它适合“需要多角度思考，但不需要真实并行执行”的任务：产品方案评审、战略判断、架构讨论、文章深度分析、投资 memo 初筛、论文解析、需求 Review。

Virtual Board 是最低成本的“多 Agent 感”。如果用户只是想获得多角度判断，不要真的创建多个 Agent。

2. Pipeline / Sequential：流水线模式

Pipeline 是多个 Agent 按固定顺序接力。

Agent A → Agent B → Agent C → Agent D → 交付

只要业务流程能画成 SOP，就优先用 Pipeline，而不是 Swarm。

Pipeline 是最容易产品化的多 Agent 模式之一，因为它稳定、可调试、可复用、可交付。

3. Router / Triage：路由分诊模式

Router 不负责重任务，只负责判断“这个请求该交给谁”。

用户输入
 ↓
Router / Triage Agent
 ├─ Knowledge Agent
 ├─ Writing Agent
 ├─ Code Agent
 ├─ Ops Agent
 └─ Human Support

Router 是入口治理，不是智能核心。它要轻、快、稳。产品上必须有置信度判断、fallback agent、澄清问题、路由日志、人工接管和重新路由。

4. Handoff / Swarm：动态接力模式

Handoff 是 Agent 之间动态转交控制权。

用户 → Agent A → Agent B → Agent C → 用户

Swarm 不能没有控制机制。至少要有当前 owner、handoff reason、handoff summary、最大 handoff 次数、fallback agent 和人工接管入口。

Handoff / Swarm 适合前台体验，不适合作为后台任务编排核心。

5. Orchestrator-Worker：主控-执行器模式

一个 Orchestrator 负责理解目标、拆解任务、分配任务、综合结果；多个 Worker 负责局部执行。

User
 ↓
Orchestrator
 ├─ Research Worker
 ├─ Code Worker
 ├─ Review Worker
 └─ Writer Worker
 ↓
Orchestrator 汇总交付

Orchestrator-Worker 是复杂任务的默认优选模式。它比 Pipeline 灵活，比 Free Swarm 稳定。关键不是“派出去”，而是“收回来并能验收”。

每个 Worker 都应该有明确的任务目标、输入边界、工具权限、输出格式、停止条件和失败兜底。

6. Hierarchical Orchestrator：分层主控模式

Hierarchical Orchestrator 是多层主控逐级分发。

Root Orchestrator
 ├─ Research Orchestrator
 │   ├─ Search Worker
 │   └─ Fact Check Worker
 ├─ Code Orchestrator
 │   ├─ Modify Worker
 │   └─ Test Worker
 └─ Delivery Orchestrator
     ├─ Writer Worker
     └─ Reviewer Worker

分层主控只适合大项目，而且必须限制层级。

建议产品上最多两层：

Main Orchestrator → Domain Orchestrator → Worker

不要让 Agent 无限递归创建 Agent。层级越深，责任链越长，成本越高，调试越难。

7. Fan-out / Fan-in：并行探索模式

Fan-out / Fan-in 是把任务拆成多个并行方向，多个 Agent 同时处理，最后由 Aggregator 汇总。

任务
 ↓
Fan-out
 ├─ Agent A
 ├─ Agent B
 ├─ Agent C
 └─ Agent D
 ↓
Fan-in
 ↓
Aggregator 汇总

它适合深度研究、投研、竞品、论文解析、多候选生成、多模型评测。

它的价值不是“模拟团队”，而是用多个上下文窗口并行探索问题空间。

8. Council / Debate：圆桌评审模式

Council / Debate 是多个 Agent 围绕同一个问题讨论、质询、反驳，最后由 Moderator 或 Judge 输出结论。

Moderator
 ├─ Pro Agent
 ├─ Con Agent
 ├─ Technical Agent
 ├─ Business Agent
 └─ Risk Agent
 ↓
Final Judge

Council / Debate 适合决策前的判断增强，不适合执行中替代流程控制。

必须有 Moderator、回合数限制、议题边界、最终裁判、输出格式和停止条件。不要让一堆 Agent 开无限会议。

9. Maker-Checker：生成-审查模式

一个 Agent 生成，另一个 Agent 审查。

Maker → Checker → Maker 修正 → Checker 通过

Maker-Checker 是生产级 Agent 最应该默认内置的质量模式。

代码、合同、SQL、部署、外发邮件、品牌内容，不应该只有 Maker，没有 Checker。

10. Blackboard / Workboard：共享状态板模式

多个 Agent 不直接互相聊天，而是围绕一个共享任务板 / 状态板工作。

Shared Blackboard
 ├─ 当前目标
 ├─ 任务列表
 ├─ 已知事实
 ├─ 未解决问题
 ├─ 中间产物
 ├─ 决策记录
 ├─ 阻塞项
 └─ 下一步动作

Blackboard 是多 Agent 从“聊天”走向“协作系统”的关键。

如果没有共享状态板，所有任务状态都会埋在聊天记录里，系统无法追踪、恢复、审计和运营。

11. Workflow / State Machine：状态机模式

Workflow / State Machine 不是 Agent 主导流程，而是状态机主导流程。Agent 只是执行某个状态下的动作。

created
 → queued
 → running
 → waiting_for_user
 → reviewing
 → failed / retrying
 → delivered
 → archived

生产级多 Agent 最终都会收敛到 Workflow / State Machine。

Agent 负责智能，Workflow 负责秩序，Task Manager 负责生命周期，人类负责最终风险。

12. Free Swarm：自由蜂群模式

Free Swarm 是多个 Agent 自由协作、互相通信、动态形成任务分工。

Agent A ↔ Agent B ↔ Agent C ↔ Agent D

它最像“群体智能”，也最容易失控。

Free Swarm 适合实验和演示，不适合默认生产架构。

它的问题很明确：

成本不可控
延迟不可控
状态不可控
责任不清楚
容易循环
容易互相强化错误
难以调试
难以归因

产品里可以保留 Free Swarm 作为“探索模式”，但不要把它作为主要执行模式。

五、什么时候该用多 Agent？

可以用这张选型表判断。

判断问题	推荐模式
只是需要多角度思考？	Virtual Board
有固定 SOP？	Pipeline / Sequential
需要质量控制？	Maker-Checker
用户意图不清？	Router / Triage
任务复杂但可拆？	Orchestrator-Worker
任务特别大，包含多个子项目？	Hierarchical Orchestrator
需要多个方向并行探索？	Fan-out / Fan-in
处理过程中才知道该交给谁？	Handoff / Swarm
需要争论和审查？	Council / Debate
长任务、状态多、要恢复？	Blackboard + Workflow
只是创意探索或仿真？	Free Swarm

这张表的核心不是“选择最复杂的模式”，而是选择最低可行复杂度。

多 Agent 模式选型指南：按任务复杂度选择 Virtual Board、Pipeline、Router、Orchestrator、Fan-out、Council、Maker-Checker、Blackboard Workflow。 — 选型原则：模式越自由，越需要 owner、日志、状态机、预算、审查和人工接管。

六、什么时候不该用多 Agent？

以下场景不建议上多 Agent。

1. 单次 Prompt 就能完成

分类、改写、摘要、翻译、短问答，直接模型调用即可。

2. 一个 Agent 加工具就能完成

查订单、查库存、建日程、简单知识库问答，单 Agent 更低成本、更低延迟、更好调试。

3. 任务路径高度确定

如果任务就是标准流程，优先 Pipeline 或 Workflow / State Machine，不要用 Free Swarm。

4. 任务价值太低

如果任务价值不足以覆盖多 Agent 带来的 token、延迟和调试成本，就不该多 Agent。

5. 需要强一致状态写入

例如多个 Agent 同时修改同一个数据库、同一个文件、同一个生产配置。此类任务必须有锁、队列、事务或中心化状态机。

6. 没有可观测系统

没有 run log、task state、artifact、cost、error、ownership 的多 Agent 产品，本质上是黑箱。

七、从 Agent 群聊到 Task OS

真正成熟的多 Agent 产品，不应该停留在 Agent 群聊，而应该走向 Task OS。

推荐架构如下：

User
 ↓
Router / Triage
 ↓
Task Classifier
 ├─ 轻任务 → Single Agent / Virtual Board
 ├─ 固定流程 → Pipeline
 ├─ 复杂任务 → Orchestrator-Worker
 ├─ 并行研究 → Fan-out / Fan-in
 ├─ 高质量交付 → Maker-Checker
 ├─ 长任务 → Blackboard + Workflow
 └─ 高风险任务 → Human Review
 ↓
Task Manager
 ↓
Artifact / Action / Delivery

这个系统里，Agent 不是全部。真正关键的是：

Agent Registry：管理 Agent 能力和权限
Skill Registry：沉淀可复用能力
Router：识别任务类型
Mode Selector：选择协作模式
Task Manager：管理任务生命周期
Workboard：沉淀状态、事实、阻塞和产物
Workflow Engine：管理流程推进、重试、恢复
Governance：管理权限、成本、审计和人工审批

也就是说：

Agent 是能力单元，Task 是生命周期单元，Workflow 是秩序单元，Workboard 是共享状态单元，Governance 是边界单元。

Multi-Agent Task OS 的最小系统：User、Router、Mode Selector、Task Manager、Agent Registry、Skill Registry、Workflow Engine、Workboard、Governance、Human Review 和 Artifact Delivery。 — 真正成熟的多 Agent 产品，核心不是 Agent 数量，而是任务、模式、状态、治理和交付系统。

八、产品设计原则：一套可复用判断框架

原则一：默认单 Agent，必要时多 Agent

多 Agent 是复杂性工具，不是默认配置。

原则二：按任务模式选架构，不按角色名堆 Agent

先判断任务是 SOP、并行探索、动态接力、质量审查，还是长任务状态机。

原则三：任何多 Agent 都必须有 owner

没有 owner，就没有责任归因。

原则四：任何长任务都必须脱离普通 Chat Session

长任务应该进入 Task Session，由 Task Manager 管理。

原则五：任何高风险动作都必须 Human-in-the-loop

发邮件、付款、删除、部署、合同、法律、金融，不要默认全自动。

原则六：任何生产交付都需要 Checker

Maker-Checker 是最小质量闭环。

原则七：Agent 可以自由推理，但系统不能自由失控

Agent 可以探索，系统必须管理流程、权限、成本、审计和状态。

多 Agent 产品设计的 7 条原则：默认单 Agent、按任务选架构、必须有 owner、长任务进入 Task Session、高风险人工确认、生产交付要 Checker、系统不能失控。 — Agent 可以自由推理，但系统必须管理流程、权限、成本、审计和状态。

九、最终结论

多 Agent 产品设计的关键，不是创建多少个 Agent，而是选择什么协作模式。

一句话总结：

要思考，用 Virtual Board；要流程，用 Pipeline；要分流，用 Router；要动态接力，用 Handoff / Swarm；要拆复杂任务，用 Orchestrator-Worker；要并行探索，用 Fan-out / Fan-in；要提高判断质量，用 Council；要保证交付质量，用 Maker-Checker；要管理长任务，用 Blackboard + Workflow；不到万不得已，不要用 Free Swarm。

真正成熟的多 Agent 产品，不会停留在 Agent 群聊，而会走向：

Multi-Agent Task OS

它不是让 Agent 自由发挥，而是把 Agent 放进任务、状态、权限、成本、审计和交付的系统里。

最终判断：

Swarm 是一种协作形态，但 Task OS 才是产品形态。

多 Agent 的价值，不是模拟一个热闹的数字团队，而是让复杂任务被稳定、可控、可审查、可恢复地完成。