一、为什么需要多 Agent？

单 Agent 的天然瓶颈：

• 上下文过载：一个 Agent 要同时理解代码、业务、部署，上下文窗口被稀释
• 指令冲突：不同任务需要的 system prompt 互相矛盾（如"保守审查" vs "大胆生成"）
• 权限不可分：一个 Agent 拥有全部工具权限，安全性差
• 无法并行：单 Agent 是串行决策，无法并发执行独立子任务

多 Agent 本质上是用拆分换专注：每个 Agent 只关心一个小世界。

---

二、多 Agent 框架的架构模式

1. 层级式（Manager-Worker）

                  ┌──────────────┐
                  │   Manager    │  ← 拆解任务、分配、汇总
                  └──────┬───────┘
           ┌─────────────┼─────────────┐
           ▼             ▼             ▼
    ┌──────────┐  ┌──────────┐  ┌──────────┐
    │ Coder    │  │ Reviewer │  │ Tester   │
    └──────────┘  └──────────┘  └──────────┘

• Manager 不执行业务逻辑，只做编排
• Worker 之间不直接通信，结果回传 Manager
• 适用场景：任务可清晰分解、有明确主次关系

2. 对等式（Peer-to-Peer / Debate）

    ┌──────────┐       ┌──────────┐
    │ Agent A  │◄─────►│ Agent B  │
    └──────────┘       └──────────┘
          ▲                 ▲
          └────────┬────────┘
                   │
            ┌──────────┐
            │ Agent C  │
            └──────────┘

• 每个 Agent 地位平等，通过消息互相协作
• 通过辩论/协商达成共识
• 适用场景：需要多方视角校验的决策（代码审查、方案评审）

3. 中枢路由式（Hub-and-Spoke / Router）

                  ┌──────────────┐
                  │    Router    │  ← 意图识别 + 路由
                  └──────┬───────┘
           ┌─────────────┼─────────────┐
           ▼             ▼             ▼
    ┌──────────┐  ┌──────────┐  ┌──────────┐
    │ 前端Agent │  │ 后端Agent │  │ 运维Agent │
    └──────────┘  └──────────┘  └──────────┘

• Router 根据用户意图分发到对应 Agent
• Agent 之间通常不通信
• 适用场景：按领域划分、请求独立、无需协作

与层级式的核心区别：

	中枢路由式	层级式
顶层角色	调度员（只做意图识别 + 分发）	管理者（制定计划 + 分配 + 汇总决策）
是否参与执行	不参与，分完就结束	参与全过程，动态调整计划
子节点关系	平行、互不感知	从属、向管理者汇报
是否有"计划"概念	无，来一个请求分一个	有，先拆解再分配
典型类比	电话总机接线员	公司经理带团队

简单说：Router 是"你去找谁"，Manager 是"我来安排怎么做"。

4. 图编排式（Graph / DAG）

     ┌──────────┐
     │  Entry   │
     └────┬─────┘
          ▼
     ┌──────────┐
     │  Planner │
     └────┬─────┘
          ▼
   ┌──────────────────┐
   │ Parallel Fork     │
   ├────────┬─────────┤
   ▼        ▼         ▼
┌─────┐ ┌─────┐  ┌─────┐
│Agent│ │Agent│  │Agent│
│  A  │ │  B  │  │  C  │
└──┬──┘ └──┬──┘  └──┬──┘
   └───────┼────────┘
           ▼
     ┌──────────┐
     │ Merger   │ ← 条件路由/循环
     └────┬─────┘
          ▼
     ┌──────────┐
     │   Exit   │
     └──────────┘

• 用有向图定义 Agent 的执行流，支持并行、条件分支、循环
• 典型实现：LangGraph、CrewAI Flow
• 适用场景：复杂的多步骤流水线，需要精细控制执行顺序

---

三、划分 Agent 的依据

这是多 Agent 设计中最关键的问题。以下是核心判断维度：

1. 按领域/专业知识划分

维度	说明	示例
技术栈	不同技术领域需要不同的专业 prompt	前端 Agent（React） vs 后端 Agent（Go）
业务领域	不同业务逻辑无法共用上下文	订单 Agent vs 支付 Agent vs 物流 Agent
数据源	不同数据源需要不同的解析能力	SQL Agent vs 日志 Agent vs API Agent

判断标准：如果你需要给同一个 Agent 写两套完全不同的 system prompt，就该拆了。

2. 按功能角色划分

这是经典的三段式拆分：

Planner ──→ Executor ──→ Reviewer
  │                         │
  └────── 反馈循环 ─────────┘

角色	职责	特点
Planner	理解需求，拆解子任务，制定计划	重推理，轻工具调用
Executor	执行具体子任务，调用工具	重工具调用，轻规划
Reviewer	检验结果，发现问题，反馈修正	重批判性思维，轻创造

判断标准：如果一个 Agent 既要"想"又要"做"还要"检查"，三个阶段的注意力会互相干扰。

3. 按工具/资源边界划分

维度	说明
权限隔离	部署 Agent 有生产权限，代码生成 Agent 没有
资源绑定	每个 Agent 只挂载自己需要的工具，减少 prompt 膨胀
安全边界	敏感操作（删库、退款）只能由特定 Agent 执行

判断标准：如果两个操作需要的权限级别不同，应该分到不同 Agent。

4. 按上下文隔离需求划分

这是最容易被忽略但最重要的依据：

Agent A: 处理用户 A 的请求（上下文含用户 A 的敏感数据）
Agent B: 处理用户 B 的请求（上下文含用户 B 的敏感数据）

→ 如果合并为一个 Agent，有上下文泄露风险

同样的道理适用于：

• 不同的代码库（代码 Agent A 不应看到代码 Agent B 的项目上下文）
• 不同的客户/租户

判断标准：如果上下文中包含不应互通的信息，必须拆分。

5. 按任务粒度划分

粒度	示例	优缺点
粗粒度	一个 Agent 负责整个"用户注册"流程	简单，但上下文长
细粒度	校验 Agent + 存储 Agent + 通知 Agent	灵活可复用，但通信开销大

判断标准：子任务之间是否需要频繁交换中间结果？

• 需要频繁交换 → 合并为一个 Agent（减少通信开销）
• 交换很少 → 拆分为多个 Agent（独立并行）

---

四、Agent 间通信机制

方式	说明	适用场景
共享内存/状态	所有 Agent 读写同一个状态对象	简单场景，强一致性
消息队列	Agent 之间通过消息异步通信	解耦、可扩展
回调/事件	Agent 完成某个阶段后触发回调	流水线式处理
直接输出传递	Agent A 的输出作为 Agent B 的输入	简单直连
黑板模式	所有 Agent 往共享空间读写中间产物	协作探索型任务

---

五、设计决策框架

面对一个系统，按以下顺序做决策：

1. 任务是否可并行？
   ├─ 是 → 考虑多个 Executor Agent 并行
   └─ 否 →
           2. 是否需要专业分工？
           ├─ 是 → 按领域/功能拆分
           └─ 否 →
                   3. 上下文是否包含隔离信息？
                   ├─ 是 → 必须拆分
                   └─ 否 → 单 Agent 即可，不要过度设计

原则：能用单 Agent 解决的，不要引入多 Agent。

多 Agent 的隐性成本：

• 通信开销：Agent 之间传递信息的 token 消耗
• 协调复杂度：出错时难以定位是哪个 Agent 的问题
• 延迟累积：串行 Agent 的延迟是叠加的

---

六、总结

划分 Agent 的核心原则 = 职责单一（Single Responsibility）× 上下文隔离 × 权限最小化

推荐的起步架构：

用户请求 → Router（意图识别）
              │
    ┌─────────┼─────────┐
    ▼         ▼         ▼
 Planner  Executor  Reviewer
    │         │         │
    └─────────┼─────────┘
              ▼
        共享状态 / 黑板

• Router 决定走哪个流程
• Planner 拆解任务
• Executor 执行（可多实例并行）
• Reviewer 校验，不通过则回退到 Planner/Executor