# 5.1 协作架构：层级、扁平与动态

## 5.1.1 为什么需要多智能体

正如一个人无法同时精通产品设计、后端架构、前端绘图和法律合规一样，指望单个智能体完成所有复杂任务是不现实的。**单体智能体** 面临以下瓶颈：

1. **上下文限制**：所有角色的指令都塞进一个系统提示词 (System Prompt)，会导致逻辑混乱，注意力分散
2. **幻觉风险**：缺乏检查机制，自己产生的错误自己信以为真
3. **能力专业化**：不同的任务需要不同的工具和提示词策略
4. **Token 经济性**：单一智能体处理复杂任务时，上下文膨胀导致 Token 成本激增

**多智能体系统** 通过 **分工** 和 **协作** 解决这些问题，实现“1+1>2”的涌现效果。

```mermaid
graph TD
    %% Agentic Design System
    classDef agent fill:#e6f7ff,stroke:#1890ff,stroke-width:2px;
    classDef error fill:#fff1f0,stroke:#ff4d4f,stroke-width:2px,stroke-dasharray: 5 5;
    classDef tool fill:#f6ffed,stroke:#52c41a,stroke-width:2px;

    subgraph mono["单体 Agent"]
        A["一个智能体处理所有任务"]
        A --> B["上下文膨胀"]
        A --> C["角色混乱"]
        A --> D["错误累积"]
    end

    subgraph multi["多智能体系统"]
        E["协调者 (Coordinator)"] --> F["研究智能体 (Research Agent)"]
        E --> G["写作智能体 (Writer Agent)"]
        E --> H["审阅智能体 (Reviewer Agent)"]
        F --> I["专注搜索"]
        G --> J["专注写作"]
        H --> K["专注质检"]
    end

    class A error;
    class B,C,D error;
    class E agent;
    class F,G,H tool;
    class I,J,K tool;
```

图 5-1：单体智能体与多智能体系统对比

## 5.1.2 角色定义与身份构建

每个智能体是一个独立的实体，拥有完整的“身份档案”：

| 属性              | 说明      | 示例                         |
| --------------- | ------- | -------------------------- |
| **Role**        | 职位定义    | “首席架构师”                    |
| **Goal**        | 具体的 KPI | “设计可扩展的微服务架构”              |
| **Backstory**   | 背景故事    | “你长期从事大型系统开发，崇尚简洁可维护的代码风格” |
| **Tools**       | 专属工具权限  | HR 智能体可读工资单，Coding 智能体不可   |
| **Constraints** | 行为边界    | “不得讨论竞争对手产品”               |

背景故事的设计尤为重要——它能显著影响 LLM 的输出风格。一个“资深律师”背景的智能体会比“实习生”输出更谨慎、更规范的文本。

## 5.1.3 主流协作拓扑

### 顺序式架构

这是最简单的流水线模式，类似于传统的瀑布开发模型。

```bash
User → Product Manager → Tech Lead → Developer → Tester → Result
```

**工作机制**：

* 上一个智能体的 Output 直接成为下一个智能体的 Input
* 每个智能体完成其专属任务后，将结果传递给下游
* 整个流程是线性的、确定性的

**适用场景**：

* SOP 非常明确的任务
* 如“写一篇文章并翻译成三种语言”
* 静态工作流，步骤固定

**局限性**：

* 这是一个开环系统
* 如果源头（PM）的需求理解错了，后面全错
* 缺乏反馈修正机制

### 层级式架构

引入一个 **监督者** 角色来动态分派任务。

```mermaid
graph TD
    %% Agentic Design System
    classDef user fill:#fff7e6,stroke:#fa8c16,stroke-width:2px;
    classDef agent fill:#e6f7ff,stroke:#1890ff,stroke-width:2px;
    classDef tool fill:#f6ffed,stroke:#52c41a,stroke-width:2px;

    User(["用户请求"]) --> Supervisor["监管智能体 (Supervisor Agent)"]
    Supervisor -->|"分配任务"| Search["搜索智能体"]
    Supervisor -->|"分配任务"| Write["写作智能体"]
    Supervisor -->|"分配任务"| Code["编码智能体"]
    Search -->|"汇报结果"| Supervisor
    Write -->|"汇报结果"| Supervisor
    Code -->|"汇报结果"| Supervisor
    Supervisor --> Result(["最终结果"])

    class User,Result user;
    class Supervisor agent;
    class Search,Write,Code tool;
```

图 5-2：层级式监督者架构

**核心角色**：

* **监管者 (Supervisor)**：大脑角色，不干具体的活。分析用户需求，决定任务路由
* **执行者 (Worker)**：执行者角色，只负责执行 Supervisor 分配的具体指令

**路由决策示例**：

```json
{
  "thought": "用户需要查询最新股价并生成分析报告",
  "next_agent": "FinanceSearchAgent",
  "args": {"ticker": "AAPL", "period": "1Y"}
}
```

**适用场景**：

* 复杂的、非线性的任务
* 需要根据中间结果动态调整下一步
* 任务优先级和资源分配需要集中控制

### 联合协作式架构

类似于头脑风暴会议的模式，多个智能体在共享空间中自由交流。**工作机制**：

* **广播通信**：智能体 A 发言，其他所有智能体都能接收
* **轮次控制**：需要 Controller 决定发言顺序（如“CEO 发言后必须是 CTO”）
* **共识达成**：通过多轮讨论形成最终决策

**优势与风险**：

* ✅ 利用群体智慧涌现出意想不到的创意
* ✅ 模拟真实团队协作动态
* ❌ 容易跑题或陷入死循环争论
* ❌ Token 消耗较高

### 混合智能体架构

这是一种前沿的 **模型级协作（MoA）**：一种常见思路是“多提议 + 再聚合”。

* **提议层**：多个模型/策略并行生成候选解（不同视角、不同温度或不同工具集）。
* **聚合层**：由一个聚合器对候选解做对比、去噪、融合，输出最终答案。

这种结构的价值主要在于提升稳健性与覆盖面，但会带来更高的成本与编排复杂度。

## 5.1.4 两种最常见的工程协作模式

虽然协作拓扑很多，但在真实工程里最常见、也最值得先掌握的是两种：

### Orchestrator-Subagent

这是当前最主流的多智能体工程模式。

* **Orchestrator**：负责理解总目标、拆解任务、分派子任务、汇总结果
* **Subagent**：只处理自己负责的子问题，不直接接管全局流程

它的优势在于：

1. 全局目标不容易漂移
2. 可以按角色做专业化分工
3. 更容易做权限控制、验收和回放

它的代价也很明确：

1. Orchestrator 容易成为瓶颈
2. 所有子任务都要经过中心节点，通信开销较高
3. 如果 Orchestrator 拆解得不好，下游再优秀也会偏题

### 生产级案例：Anthropic Research 系统

Anthropic 在 2025 年 6 月 13 日公开的工程文章《How we built our multi-agent research system》中，介绍了其 Research 功能采用的 LeadResearcher-Subagent 模式。这是 Orchestrator-Subagent 架构在开放式研究任务中的一个公开案例。

**架构设计**：

* **LeadResearcher**：负责理解用户查询、制定研究策略、拆解子任务、综合发现，并在存在信息缺口时继续追加研究。
* **Subagent**（多个）：各自独立执行网页搜索、阅读结果、评估证据质量，再把发现返回给 LeadResearcher。
* **并行粒度**：Anthropic 公开写到，LeadResearcher 会先并行拉起 **3-5 个** subagents；配图里只画了两个，但原文明确说明数量并不固定。

**性能与成本权衡**：

* **性能提升**：在 Anthropic 的内部 research eval 中，多智能体 Research 系统相对单智能体 Claude Opus 4 提升 **90.2%**。这是该案例的内部评测结果，不应当外推成行业通用基准。
* **Token 成本**：Anthropic 同时披露，其数据里普通 agent 流程大约消耗 chat interaction 的 **4 倍** token，而 multi-agent research 大约是 **15 倍**。这说明性能收益来自更高的“推理预算”，而不是免费提升。
* **适用范围**：该架构特别适合宽度优先查询，以及信息量明显超出单一上下文窗口的任务。

**关键工程实践**：

1. **明确任务边界**：LeadResearcher 给每个 subagent 指定清晰目标，减少重复搜索和无效重叠。
2. **并行搜索 + 中心综合**：并行扩展信息覆盖面，再由中心节点统一做取舍和汇总。
3. **结果不够就继续扩展**：LeadResearcher 会根据返回结果决定是否继续增补子任务，而不是一次性固定完整流程。

### Peer-to-Peer

这是更“去中心化”的协作方式。智能体之间处于相对平等的关系，通过协商、辩论、投票或相互审查来达成结论。

它适合：

* 需要多视角碰撞的任务
* 需要互相纠错的任务
* 更强调探索性而非确定性流程的任务

但它的工程难点也更大：

* 发言顺序和仲裁机制更难设计
* 更容易出现重复讨论和责任不清
* 观测、调试、计费都比层级式更复杂

经验上，如果你的任务属于“必须交付结果、必须可控回放、必须可审计”，优先从 **Orchestrator-Subagent** 开始；只有在确实需要多方博弈时，再引入 Peer-to-Peer 元素。

## 5.1.5 实战案例：长期自主编码

在长周期的自主编码任务里，系统常见的挑战包括：并发冲突、任务选择偏好（只挑简单的做）、上下文漂移、以及质量与速度的权衡。

一个常见的演进路径是从“扁平协作（人人平等、靠共享状态协同）”走向“分层协作（规划/执行/评审分工）”：

* **扁平模式的风险**：需要复杂的锁/协同协议；一旦异常退出或忘记释放资源，吞吐量会显著下降；同时容易出现“困难任务无人负责”。
* **分层模式的优势**：规划者只做拆解与分派，执行者专注交付，评审者负责验收与回退；执行者之间尽量隔离，从结构上降低协调成本。

> 设计要点：如果系统出现“空转”（看似忙但无交付），优先收紧角色职责与交付接口，而不是继续堆叠协调机制。

在多智能体系统中，单纯增加 Agent 数量并不必然带来能力的线性提升，反而容易引入以下系统级失败节点：

1. **协同饥饿 (Coordination Starvation)**：多个 Agent 都在等待对方的前置输出，或因为共享资源竞争导致全局死锁。
2. **目标漂移 (Goal Drift)**：在多轮接力传导中，最初的用户意图被逐层稀释或扭曲，最终交付物虽“质量高”但完全偏题。
3. **无限回文 (Infinite Ping-Pong)**：审查者 Agent 与执行者 Agent 因为 Prompt 判定标准不一致（或缺乏仲裁机制），陷入“修改-打回-修改”的死循环。
4. **责任推诿 (Buck Passing)**：由于边界定义不清，Agent 错误判断某项模糊任务是“下游的职责”而直接跳过执行。

**防范措施**：清晰的角色定义和标准化的 SOP 流程是防止这些失败模式的关键。详见 [5.2 角色分工与 SOP 流程编排](/agentic_ai_guide/di-er-bu-fen-qun-ti-zhi-neng-yu-jin-hua/05_collaboration/5.2_roles_sop.md)，其中通过精心设计角色职责边界、输入输出接口和终止条件，可以有效降低这些系统级风险。

## 5.1.6 架构选型决策矩阵

| 架构类型  | 复杂度 | 延迟 | 成本 | 适用场景        |
| ----- | --- | -- | -- | ----------- |
| 顺序式   | 低   | 低  | 低  | 固定流程、SOP 任务 |
| 层级式   | 中   | 中  | 中  | 动态路由、复杂决策   |
| 联合协作式 | 高   | 高  | 高  | 创意生成、头脑风暴   |
| 混合架构  | 中   | 中  | 中  | 质量优先、模型集成   |

## 5.1.7 案例补充：编码场景中的协调器模式

编码任务同样常见“中心协调器 + 并行子任务”的协作方式：先把代码库分析、改动实施、验证检查拆成相对独立的子问题，再由上层节点做计划收敛与结果验收。

这里更稳妥的做法是抽象模式，而不是把某个具体产品的内部 worker 名册、swarm 上限或共享目录实现细节写成通用事实。对于公开资料不足的系统，应该只保留以下可迁移的工程原则：

1. **研究/分析阶段适合并行展开**：依赖扫描、风险识别、测试缺口分析往往可以分头进行。
2. **综合/决策阶段通常要收口**：当多个子任务结论互相冲突时，需要由协调器或人类做取舍。
3. **实施与验证可以再并行展开**：只要文件边界和验收接口清楚，编码与验证任务就能重新分片并行。
4. **可观测性比“多几个 agent”更重要**：没有清晰日志、回放和责任边界时，智能体数量越多，调试越困难。

## 5.1.8 本节小结

架构即政治。在设计智能体系统时，实际上是在设计一个人类组织的电子映射。选择 **顺序式** 还是 **层级式**，取决于你的业务流程是更像工厂流水线（追求效率），还是像咨询公司项目组（追求灵活）。

核心原则：

1. **专业化分工**：让每个智能体专注于其擅长的领域
2. **明确边界**：定义清晰的输入输出接口和责任范围
3. **容错机制**：设计失败处理和回退策略
4. **数字口径要回到具体案例**：性能提升、token 成本和并行规模都应绑定具体评测与公开来源，而不是写成放之四海而皆准的定律
5. **可观测性**：确保每个智能体的行为可追踪、可审计

***

**下一节**: [5.2 角色分工与 SOP 流程编排](/agentic_ai_guide/di-er-bu-fen-qun-ti-zhi-neng-yu-jin-hua/05_collaboration/5.2_roles_sop.md)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/agentic_ai_guide/di-er-bu-fen-qun-ti-zhi-neng-yu-jin-hua/05_collaboration/5.1_architectures.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.