系统复杂度一旦突破单Agent的承载上限，多Agent架构便成为必然选项。核心挑战在于拆分策略：如何划分边界？形成何种结构？怎样编排协作？这些才是决定成败的关键。
一、为什么需要多Agent？
单Agent的固有瓶颈相当显著，只需罗列几项即可看清：
- **上下文窗口超限**：一个Agent同时处理代码、业务、部署，上下文被严重稀释，关键细节难以留存。
- **prompt指令对抗**：不同任务所需的system prompt相互冲突——例如要求“保守审查”与“大胆生成”并存，Agent直接陷入逻辑混乱。
- **权限无法隔离**：单一Agent拥有全部工具权限，安全毫无保障，一旦出现漏洞便全局沦陷。
- **串行瓶颈**：单Agent做串行决策，独立子任务只能排队等候，吞吐效率低下。
多Agent的核心逻辑是以拆分换取聚焦。每个Agent仅需专注自身职责域，认知清晰后，产出质量自然提升。
二、多Agent框架的架构模式
1. 层级式（Manager-Worker）
┌──────────────┐
│ Manager │← 任务分解、分派与结果聚合
└──────┬───────┘
┌─────────────┼─────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Coder │ │ Reviewer │ │ Tester │
└──────────┘ └──────────┘ └──────────┘
- Manager不插手具体执行，只负责编排——拆解任务、分配子项、回收成果。
- Worker之间不直接通信，各自独立执行，结果统一回传Manager。
- **适用场景**：任务可清晰分解，具备明确的主从关系。例如一个软件需求，拆分为前端、后端、测试，Manager依据清单指挥。
2. 对等式（Peer-to-Peer / Debate）
┌──────────┐ ┌──────────┐
│ Agent A │◄────►│ Agent B │
└──────────┘ └──────────┘
▲ ▲
└────────┬────────┘
│
┌──────────┐
│ Agent C │
└──────────┘
- 各Agent地位对等，借助消息互相协作，不存在指挥关系。
- 通过辩论或协商达成共识——例如让两个Agent分别提出方案，然后互评。
- **适用场景**：需要多方视角校验的决策，如代码审查、方案评审。一个Agent写代码，另一个Agent审查，在争论中产出最佳结果。
3. 中枢路由式（Hub-and-Spoke / Router）
┌──────────────┐
│ Router │← 意图识别 → 路由
└──────┬───────┘
┌─────────────┼─────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ 前端Agent │ │ 后端Agent │ │ 运维Agent │
└──────────┘ └──────────┘ └──────────┘
- Router根据用户意图识别，将请求分发给对应的专业Agent。
- Agent之间通常不交互，各司其职。
- **适用场景**：按领域划分，请求相互独立、无需协作。例如客服系统：订单问题→订单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
归根结底，设计多Agent系统并非越复杂越好，而是在“专注”与“成本”之间寻找平衡点。先划定边界，再约定通信规则，剩下的交给Agent自主运转即可。
