Multi-Agent协作

核心论点：与其让一个 Agent 做所有事，不如让多个 Agent 各自擅长一件事，然后协作完成。

Multi-Agent 不是简单的"多开 Agent"，而是有分工、有编排、有信息流向的协作架构。它是单 Agent 之上的一层抽象，跟 Agent vs Workflow 是不同维度的设计选择——Multi-Agent 既可以是 Agent 式（动态编排）也可以是 Workflow 式（固定路由）。

典型架构：Lead Researcher + Subagent

Claude.ai 的 Multi-Agent Research System 是当前最经典的实现——

                ┌──────────────────────────────────────────────┐
                │  Lead Agent (Orchestrator)                   │
                │  ← 理解需求、制定计划、协调子 Agent           │
                │  Tools: search tools + MCP tools             │
   User    →    │       + memory + run_subagent                │  →   Final
   request      │       + complete_task                        │      report
                └─────┬──────┬───────────┬──────────┬──────────┘
                      ↓      ↓           ↓          ↓
                   Citations Search    Search     Search
                   subagent  subagent  subagent   subagent
                   ← 各自独立 context，专注一个子任务

角色分工

角色	类比	职责
Lead Researcher Agent	PM 型 Agent	理解需求 → 制定计划 → 协调子 Agent → 整合结果 → 评估质量 → 输出最终报告
Subagent	各专业方向的执行者	各自独立 context，专注一个子任务（搜索专家 / 分析专家 / 协作专家）
Citations Subagent	引用专家	专门做引用追踪和来源标注

信息流向（以 Claude.ai 的 Multi-Agent Research 为例）

User: "what are all the companies in the united states working on AI agents in 2025?
       make a list of at least 100, for each company, include the name, website,
       product, description of what they do, type of agents they build, and their
       vertical/industry."

1. Lead Agent 接到 user request，拆解为子任务：
   - 子任务 A：搜索"AI agent startups 2025"
   - 子任务 B：搜索"enterprise AI agent companies"
   - 子任务 C：搜索"vertical AI agents by industry"
   - 子任务 D：……

2. Lead Agent 分别派给 N 个 Search Subagent，各自独立 context 执行

3. Subagent 执行完返回结构化结果给 Lead Agent

4. Lead Agent 整合 → 评估质量 → 决定是否再补充检索

5. Citations Subagent 介入做引用追踪

6. Lead Agent 输出 Final Report

为什么要 Multi-Agent

单 Agent 的痛点	Multi-Agent 怎么解
Context Window 有限	子任务分散到不同 Subagent，各自独立 context，主 Agent 不被淹没
任务太杂导致迷失	每个 Subagent 只做一件事，专注度高，错误率低
没法并行	多个 Subagent 可以并行执行，缩短总耗时
角色冲突	"生成"和"批评"放在同一个 Agent 里容易自我认同，分成两个角色更客观（参考 Agent规划与反思双 Agent Reflection）

与 Workflow 中 Orchestrator-Workers 的关系

Agent vs Workflow 里的 Orchestrator-Workers Workflow 跟 Multi-Agent 长得很像——都是一个主控分发任务给多个工人。

区别在哪？

	Orchestrator-Workers Workflow	Multi-Agent 协作
拆解方式	主控用固定模板拆解	Lead Agent 用 LLM 动态推理拆解
子节点	LLM Call（一次性调用）	Subagent（完整的 Agent，有自己的 Tools/Memory/Planning）
子节点能力	单次推理	多步推理 + 调用工具 + 维护自己的 context
主控介入	编排完就执行，不动态调整	Lead Agent 持续评估，可以再派活、再补充

简单说：Orchestrator-Workers 是"一次性拆任务"，Multi-Agent 是"持续协作"。

PM 决策框架

什么时候用 Multi-Agent？看决策树（来自 Agent vs Workflow）的最后一档：

任务复杂 + 已经决定上 Agent
        │
        ↓
   Context 不够？      → +Multi-Agent
   有明确分工？        → +Multi-Agent
   可以并行加速？      → +Multi-Agent

不要默认上 Multi-Agent——它的成本是单 Agent 的 N 倍（N 个 Subagent 各自烧 Token），编排复杂度也指数级上升。只在以下场景明确需要时才用：

深度调研类任务（需要多源信息整合）
大规模代码库分析（需要多个 Subagent 看不同模块）
跨领域任务（每个 Subagent 是不同领域专家）