152 lines
5.4 KiB
Markdown
152 lines
5.4 KiB
Markdown
|
---
|
|||
|
|
tags: [ai/agent, multi-agent, supervisor, critic-pattern, planner]
|
|||
|
|
create time: 2026-08-08 18:43
|
|||
|
|
update time: 2026-08-08 18:43
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
# 多智能体协作模式
|
|||
|
|
|
|||
|
|
## 概述
|
|||
|
|
|
|||
|
|
单个 Agent 的能力受限于上下文窗口和工具集。多智能体系统通过让多个专业化的 Agent 分工协作，实现复杂任务的可扩展解耦。核心挑战在于通信协议设计、任务分解质量和冲突消解机制。
|
|||
|
|
|
|||
|
|
## 详解
|
|||
|
|
|
|||
|
|
### Supervisor 模式 — 主从分发
|
|||
|
|
|
|||
|
|
Supervisor 作为中央调度器，接收用户请求后将任务拆解为子任务，分配给专业子 Agent，最后整合结果。
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
sequenceDiagram
|
|||
|
|
participant User as 用户
|
|||
|
|
participant S as Supervisor Agent
|
|||
|
|
participant A as Writer Agent
|
|||
|
|
participant B as Researcher Agent
|
|||
|
|
participant C as Editor Agent
|
|||
|
|
|
|||
|
|
User->>S: 提交复合需求
|
|||
|
|
S->>S: 任务分解与规划
|
|||
|
|
S->>B: 子任务1: 调研背景资料
|
|||
|
|
B-->>S: 返回调研报告
|
|||
|
|
S->>A: 子任务2: 撰写初稿
|
|||
|
|
A-->>S: 返回初稿
|
|||
|
|
S->>C: 子任务3: 审校编辑
|
|||
|
|
C-->>S: 返回定稿
|
|||
|
|
S-->>User: 交付最终结果
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**关键设计决策：**
|
|||
|
|
- **任务粒度**：子任务拆得太细导致通信开销过大；太粗则失去并行价值。一般 3-7 个粒度最合适——匹配人类短期记忆容量（Miller 法则）。
|
|||
|
|
- **状态一致性**：所有中间产物存储在共享 State 中，Supervisor 负责读取每个阶段的产出并构造下一轮输入。
|
|||
|
|
|
|||
|
|
```go
|
|||
|
|
// Go 示例：Supervisor 路由到子 Agent
|
|||
|
|
type Supervisor struct {
|
|||
|
|
agents map[string]*Agent // agentId → Agent实例
|
|||
|
|
router ModelRouter // LLM 驱动的路由决策
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
func (s *Supervisor) Dispatch(task string) string {
|
|||
|
|
intent := s.router.Classify(task) // 调用 LLM 判断意图类型
|
|||
|
|
resultChan := make(chan Result)
|
|||
|
|
|
|||
|
|
for _, subtask := range s.Decompose(intent, task) {
|
|||
|
|
go func(st SubTask) {
|
|||
|
|
agent := s.agents[st.AgentID]
|
|||
|
|
resultChan <- agent.Execute(st)
|
|||
|
|
}(subtask)
|
|||
|
|
}
|
|||
|
|
|
|||
|
|
return s.Aggregate(resultChan, len(subtasks))
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
### Critic 模式 — 审查反馈循环
|
|||
|
|
|
|||
|
|
Critic Agent 不生产内容，只评估已有内容的质量，给出评分和改进建议。形成 Producer-Critic 的对抗循环。
|
|||
|
|
|
|||
|
|
```mermaid
|
|||
|
|
graph TD
|
|||
|
|
A["Producer Agent\n生成候选方案"] --> B["Critic Agent\n质量评分"]
|
|||
|
|
B --> C{"分数 ≥ 阈值?"}
|
|||
|
|
C -->|"否"| D["Feedback\n具体改进意见"]
|
|||
|
|
D --> A
|
|||
|
|
C -->|"是"| E["接受输出"]
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**适用场景：**代码审查、文章校对、Prompt 优化验证、安全策略校验。
|
|||
|
|
|
|||
|
|
> [!NOTE]
|
|||
|
|
> Critic 的质量取决于它的评估标准是否量化。纯自然语言的评判主观性太强，应该定义结构化评分维度：准确性、完整性、安全性各占权重。
|
|||
|
|
|
|||
|
|
### Planner 模式 — 规划先行
|
|||
|
|
|
|||
|
|
Planner Agent 先输出一串有序的步骤序列，Executors 按步骤逐个执行。Plan 可静态制定，也可动态调整。
|
|||
|
|
|
|||
|
|
**静态 Planning：**
|
|||
|
|
```
|
|||
|
|
Step 1: 搜索「XX 技术栈的性能基准」
|
|||
|
|
Step 2: 汇总三个数据源的对比表
|
|||
|
|
Step 3: 针对劣势项提出优化建议
|
|||
|
|
Step 4: 生成总结报告
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**动态 Planning（Replan）：** 当某一步失败或结果不符合预期时，Planner 重新规划后续步骤。例如搜索结果为空时，自动调整为「扩大搜索范围 → 使用同义词 → 切换到备选信息源」。
|
|||
|
|
|
|||
|
|
### 消息传递协议
|
|||
|
|
|
|||
|
|
多 Agent 之间通过结构化消息通信，推荐基于 JSON Schema 定义契约：
|
|||
|
|
|
|||
|
|
```json
|
|||
|
|
{
|
|||
|
|
"type": "task_assignment",
|
|||
|
|
"id": "task_001",
|
|||
|
|
"from": "supervisor",
|
|||
|
|
"to": "researcher",
|
|||
|
|
"payload": {
|
|||
|
|
"instruction": "检索 Golang gc 在 1.21 中的改动",
|
|||
|
|
"timeout_ms": 30000,
|
|||
|
|
"format": "structured_summary"
|
|||
|
|
}
|
|||
|
|
}
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
**消息类型体系：**
|
|||
|
|
|
|||
|
|
| 类型 | 方向 | 用途 |
|
|||
|
|
|------|------|------|
|
|||
|
|
| `task_assignment` | S→Agent | 分配子任务 |
|
|||
|
|
| `result_report` | Agent→S | 汇报完成结果 |
|
|||
|
|
| `feedback_request` | C→Agent | 要求重新生成 |
|
|||
|
|
| `escalation` | Agent→S | 上报异常求决策 |
|
|||
|
|
| `cancellation` | S→All | 全局取消信号 |
|
|||
|
|
|
|||
|
|
### 各模式对比
|
|||
|
|
|
|||
|
|
| 模式 | 优点 | 缺点 | 最佳适用场景 |
|
|||
|
|
|------|------|------|-------------|
|
|||
|
|
| Supervisor | 架构清晰、便于监控 | 单点瓶颈、上下文窗口压力大 | 复杂长链路任务，如研究报告生成 |
|
|||
|
|
| Critic | 显著提升输出质量 | 增加延迟和 token 消耗 | 对准确性要求高的场景 |
|
|||
|
|
| Planner | 解耦规划与执行、支持重试 | Plan 可能不合理需 Replan | 步骤依赖明确的流水任务 |
|
|||
|
|
| Swarm | 简洁灵活、天然并行 | 缺乏全局协调、易产生不一致 | 探索性、发散性头脑风暴 |
|
|||
|
|
|
|||
|
|
> [!TIP]
|
|||
|
|
> 面试高频题：为什么不做一个超级大的 Agent？答案：① 上下文窗口有限，塞入太多能力会稀释注意力；② 工具冲突概率随数量增加而上升；③ 调试困难——出问题时无法定位是哪个模块的问题；④ 迭代成本高，改一个能力可能需要重新微调整个模型。
|
|||
|
|
|
|||
|
|
## 实践场景
|
|||
|
|
|
|||
|
|
**项目复盘：Gen2D 项目中的多 Agent 设计**
|
|||
|
|
|
|||
|
|
Gen2D 项目中采用了 Supervisor + Planner 混合模式：
|
|||
|
|
1. 入口 Agent 将用户需求分解为前端/后端/测试三条线
|
|||
|
|
2. 每条线内由 Planner 制定步骤序列
|
|||
|
|
3. Executor Agent 按步骤执行，每次执行后写入共享日志
|
|||
|
|
4. Reviewer Agent 做最终交叉检查
|
|||
|
|
|
|||
|
|
这种分层设计避免了单层 DAG 节点过多导致的管理复杂度。
|
|||
|
|
|
|||
|
|
## 扩展阅读
|
|||
|
|
|
|||
|
|
- [[Eino DAG 工作流设计]]
|
|||
|
|
- [[上下文工程与记忆管理]]
|