第18篇-多Agent协作模式全景
【AI Agent 与 Super Agent 构建实战】第 18 篇：多 Agent 协作模式全景
本系列定位：用 Go 语言从零构建各类 AI Agent，覆盖 ReAct、Plan-and-Execute、Multi-Agent、Super Agent 等核心设计模式的完整工程实现。
本篇你将学到
- 理解单 Agent 的本质局限，建立"为什么要多 Agent"的工程认知
- 掌握四种核心协作拓扑：星型、网状、层级、流水线
- 协作协议设计的基本要素：消息格式、路由、生命周期
- Agent 角色分工的 SOLID-R 原则与能力边界划分
- 单 Agent vs 多 Agent 的决策矩阵，学会在工程中选对模式
学完本篇，你将具备多 Agent 系统的"顶层设计视野"，为后续六篇（Orchestrator-Worker、通信协议、角色设计、辩论共识、Group Chat、AgentForge v0.4）打好理论地基。
一、单 Agent 的天花板：为什么需要多 Agent
1.1 一个真实的翻车案例
回顾前面三个模块，我们构建的 AgentForge 已经具备不弱的能力：Plan-and-Execute（第 13-14 篇）、DAG 任务调度（第 15 篇）、Tree of Thought 深度推理（第 16 篇）。但当你让它"独立完成一个需求分析 → 技术选型 → 编码 → 测试 → 审查"的闭环时，它会撞墙。
典型症状有三类：
| 症状 | 表现 | 根因 |
|---|---|---|
| 角色撕裂 | 同一个 System Prompt 既要"严谨编码"又要"挑刺审查"，自相矛盾 | 人格冲突 |
| 上下文爆炸 | 所有工具、所有历史塞进一个窗口，Token 预算瞬间耗尽 | 上下文过载 |
| 难以并发 | 一个 Agent 串行跑五步任务，耗时是并行的 5 倍 | 无并发结构 |
这三类问题不是"调参"能解决的——它们是架构问题。正如单体应用拆成微服务不是为了炫技，而是为了拆解复杂度，多 Agent 系统的本质是关注点分离。
1.2 单 Agent 的五道墙
记住一句话：当一个 Agent 的 System Prompt 超过 2000 Token 还在继续加规则时，就是该拆分的时候。
1.3 不是银弹：多 Agent 的代价
多 Agent 不是万能解药，它同样带来新成本：
- 通信开销：Agent 之间需要序列化/反序列化消息，每次"对话"都是一次 LLM 调用
- 编排复杂度：需要一个协调者（Orchestrator）管理生命周期，否则就是一团乱麻
- 调试困难：多 Agent 日志分散，链路追踪是必须的
- Token 倍增：N 个 Agent 各自带上下文，总 Token 消耗往往是单 Agent 的 3-10 倍
后续第 23 篇会专门讲 Token 成本管理，第 24 篇的 AgentForge v0.4 会给出容错与恢复的工程实现。
二、四种核心协作拓扑
拓扑结构决定了 Agent 之间"谁跟谁说话"。选错拓扑，再多 Worker 也跑不动。下面四种是工程上最常用的。
2.1 星型拓扑（Hub-and-Spoke）
- 结构：一个中心 Orchestrator，所有 Worker 只与中心通信
- 适用：任务可清晰拆分、Worker 之间无依赖（如多文档摘要、批量翻译）
- 优点：控制流简单，中心节点拥有全局视角
- 缺点：中心是性能瓶颈和单点故障
- 代表实现：第 19 篇的 Orchestrator-Worker 模式
2.2 网状拓扑（Mesh / Peer-to-Peer）
- 结构：任意两个 Agent 都可直接通信
- 适用：辩论、头脑风暴、协商场景（每个 Agent 是对等参与者）
- 优点：信息流动快、去中心化
- 缺点：N 个 Agent 有 O(N²) 的通信链路，Agent 一多就失控
- 代表实现：第 22 篇的多 Agent 辩论框架
2.3 层级拓扑（Hierarchical）
- 结构：树状，顶层下派任务，底层上报结果，中层既接收也分发
- 适用：复杂项目分解（如软件研发流水线：CEO Agent → 后端组/前端组 → 各角色 Worker）
- 优点：可伸缩性好，新增子树不影响其他分支
- 缺点：层级过深时延迟累积，底层结果可能失真
- 代表实现：AutoGPT 类项目的任务树分解
2.4 流水线拓扑（Pipeline / Sequential）
- 结构：线性，前一个的输出是后一个的输入
- 适用：阶段清晰、有明确产物流转的流程（研发流水线、数据处理管线）
- 优点：最易理解和实现，每阶段可独立优化
- 缺点：纯串行，无并发收益；某阶段阻塞则全链路停
- 代表实现：第 24 篇 AgentForge v0.4 的研发流水线 demo
2.5 四种拓扑对比矩阵
| 拓扑 | 通信复杂度 | 控制难度 | 适用规模 | 典型场景 |
|---|---|---|---|---|
| 星型 | O(N) | 低 | 2-20 Worker | 批量任务分发 |
| 网状 | O(N²) | 高 | 2-6 Agent | 辩论/协商 |
| 层级 | O(N) | 中 | 10-100 Agent | 复杂项目分解 |
| 流水线 | O(N) | 低 | 3-8 阶段 | 串行流程 |
工程实践中的"黄金组合"是层级 + 流水线：顶层用层级分解模块，模块内用流水线串联阶段。
三、协作协议设计基础
协议不是花架子——没有协议，多 Agent 系统就是"一群自说自话的 LLM"。一个最小可用的协作协议需要回答四个问题。
3.1 协议四要素
3.2 最小消息信封
第 20 篇会给出完整的 JSON-RPC 风格协议实现，这里先给出最小信封，让你有直观感受：
// internal/multiagent/message.go
package multiagent
import "time"
// Message 多 Agent 协作的最小消息信封
type Message struct {
ID string `json:"id"` // 消息唯一 ID（用于幂等与追踪）
TraceID string `json:"trace_id"` // 链路追踪 ID（贯穿一次协作）
From string `json:"from"` // 发送者 Agent ID
To string `json:"to"` // 接收者 Agent ID（"broadcast" 表示广播）
Type string `json:"type"` // 消息类型：task/result/event/error
Payload any `json:"payload"` // 消息体（结构由 Type 决定）
Timestamp time.Time `json:"timestamp"` // 发送时间
ReplyTo string `json:"reply_to"` // 关联的上一条消息 ID（请求-响应模式）
}
四个字段最关键：TraceID（链路追踪）、From/To（路由）、Type（分发）、ReplyTo（关联请求与响应）。第 20 篇会在这之上扩展异步通信、事件驱动、消息队列等机制。
3.3 消息类型约定
| Type | 含义 | 方向 |
|---|---|---|
task | 分配任务 | Orchestrator → Worker |
result | 返回结果 | Worker → Orchestrator |
event | 事件通知（如"任务开始"） | 任意 → 订阅者 |
error | 错误上报 | Worker → Orchestrator |
query | 询问信息 | Agent → Agent |
vote | 投票（辩论场景） | Agent → 仲裁者 |
3.4 协议设计的三条铁律
- 版本号必须前置：协议要支持演进，
Message加一个Version字段，老 Agent 收到新版本可以拒绝而不是乱解析。 - Payload 必须可序列化为 JSON：跨 Agent 通信的最低公约数是 JSON，别用 Go 特有的
chan、func当 Payload。 - TraceID 必须贯穿全程：没有 TraceID 的多 Agent 系统在生产环境无法调试。每个 Worker 的日志、每个 LLM 调用的 metadata 都要带上它。
四、Agent 角色分工原则
4.1 SOLID-R 原则
借鉴面向对象的 SOLID，多 Agent 角色设计有五条原则（简称 SOLID-R，R 代表 Role）：
| 原则 | 全称 | 核心要义 |
|---|---|---|
| S | Single Responsibility | 一个 Agent 只承担一类职责 |
| O | Open-Closed | 新增能力靠加 Agent，不靠改老 Agent |
| L | Liskov Substitution | 同角色的 Agent 可互换（如换不同 LLM 后端） |
| I | Interface Segregation | Agent 暴露最小接口，不强迫调用方依赖不需要的方法 |
| D | Dependency Inversion | Agent 之间通过协议/接口通信，不直接依赖具体实现 |
| R | Role Clarity | 每个角色必须有明确的能力边界和"不能做什么"清单 |
第 21 篇会给出完整的角色定义模板（能力矩阵、System Prompt 注入、知识共享与隔离），这里先看一个反面教材：
反面教材：一个叫 “FullStackDevAgent” 的角色，既写前端又写后端还做测试。这违反了 S 原则——前端、后端、测试的工具集和上下文是冲突的，塞进一个 Agent 必然上下文爆炸。
4.2 角色定义模板（精简版）
// internal/multiagent/role.go
package multiagent
// RoleSpec 角色规格定义
type RoleSpec struct {
Name string `json:"name"` // 角色名，如 "coder"
DisplayName string `json:"display_name"` // 展示名，如 "编码 Agent"
Capabilities []string `json:"capabilities"` // 能力清单，如 ["go","python"]
Tools []string `json:"tools"` // 可用工具名
CannotDo []string `json:"cannot_do"` // 明确禁止，如 ["部署生产环境"]
SystemPrompt string `json:"system_prompt"` // 人格注入
MaxTokens int `json:"max_tokens"` // 单轮 Token 上限
}
CannotDo 字段被很多教程忽略，但它极其重要——明确"不能做什么"比"能做什么"更能约束 Agent 行为。第 21 篇会展开。
4.3 典型角色组合：研发流水线
一个完整的多 Agent 软件研发系统通常有这些角色：
| 角色 | 职责 | 关键工具 |
|---|---|---|
| PM Agent | 需求分析、拆解任务 | 文档检索、需求模板 |
| Architect Agent | 技术选型、架构设计 | 知识库、技术雷达 |
| Coder Agent | 编码实现 | 代码生成、文件读写 |
| Tester Agent | 编写测试、执行测试 | 测试框架、覆盖率工具 |
| Reviewer Agent | 代码审查、质量把关 | 静态分析、规范检查 |
| DevOps Agent | 部署、监控 | CI/CD、容器编排 |
这六个角色用流水线拓扑串联，就是一条完整的研发流水线。第 24 篇会给出可运行 demo。
五、单 Agent vs 多 Agent 决策矩阵
什么时候该用多 Agent？这是一道工程经济学题。下面这个矩阵是前三模块踩坑后的总结。
5.1 决策矩阵
| 维度 | 倾向单 Agent | 倾向多 Agent |
|---|---|---|
| 任务类型 | 单一领域、对话式 | 跨领域、流水线 |
| 工具数量 | <5 个 | >10 个 |
| System Prompt 长度 | <800 Token | >2000 Token |
| 并发需求 | 无 | 多任务可并行 |
| 容错要求 | 失败重跑即可 | 局部失败不能拖全局 |
| Token 预算 | 紧张 | 充足（多 Agent 是 3-10 倍消耗） |
| 调试成本 | 容忍度高 | 需要链路追踪 |
5.2 一个简单的决策函数
把这个矩阵翻译成代码（伪决策，真实场景需结合业务权重）：
// internal/multiagent/decision.go
package multiagent
// MultiAgentDecision 输入任务特征，输出推荐模式
type MultiAgentDecision struct {
UseMultiAgent bool // 是否用多 Agent
Topology string // 推荐拓扑
Reason string // 决策理由
}
// DecideTopology 根据任务特征决策
func DecideTopology(
toolCount int,
promptTokens int,
needConcurrency bool,
crossDomain bool,
) MultiAgentDecision {
// 规则 1：工具多 + 跨领域 → 多 Agent
if toolCount > 10 && crossDomain {
if needConcurrency {
return MultiAgentDecision{
UseMultiAgent: true,
Topology: "hierarchical",
Reason: "工具多+跨领域+需并发，层级拓扑最合适",
}
}
return MultiAgentDecision{
UseMultiAgent: true,
Topology: "pipeline",
Reason: "工具多+跨领域但无需并发，流水线即可",
}
}
// 规则 2：Prompt 过长 → 拆分
if promptTokens > 2000 {
return MultiAgentDecision{
UseMultiAgent: true,
Topology: "pipeline",
Reason: "单 Agent Prompt 过载，按职责拆分",
}
}
// 规则 3：默认单 Agent
return MultiAgentDecision{
UseMultiAgent: false,
Topology: "single",
Reason: "任务复杂度未到拆分阈值",
}
}
这个函数不是用来"自动决策"的，而是用来强制团队在拆分前量化思考——很多时候，业务方说"我们要多 Agent"，但量化后会发现单 Agent 加几个工具就够了。
5.3 一个真实对比：文档摘要任务
假设任务是对 20 篇技术文档做摘要并合成总报告：
| 方案 | 实现 | Token 消耗 | 耗时 | 质量 |
|---|---|---|---|---|
| 单 Agent | 一个 Agent 顺序读 20 篇 | 高（上下文累积） | 慢（串行） | 后期上下文稀释，质量下降 |
| 星型多 Agent | 1 Orchestrator + 20 Worker 并行摘要 | 中（各 Worker 独立窗口） | 快（并行） | 各篇摘要质量稳定 |
| 流水线 | Worker 摘要 → Orchestrator 合成 | 中 | 中 | 质量最佳，有合成阶段 |
结论：这个任务用星型 + 流水线混合最佳——20 个 Worker 并行摘要（星型），Orchestrator 收集后做合成（流水线下游）。这就是"层级 + 流水线"黄金组合的体现。
六、模块 4 路线图
本篇是模块 4 的开篇，后续六篇会逐步把理论落地为可运行代码：
| 篇号 | 主题 | 产出 |
|---|---|---|
| 第 19 篇 | Orchestrator-Worker 模式 | 主从编排框架 Go 实现 |
| 第 20 篇 | Agent 间通信协议 | JSON-RPC 风格协议 + channel 异步通信 |
| 第 21 篇 | Agent 角色与人格设计 | 角色定义模板 + System Prompt 注入 |
| 第 22 篇 | 辩论与共识 | 多 Agent 协商框架 Go 实现 |
| 第 23 篇 | Group Chat 编排 | 群组调度 Manager + Token 成本控制 |
| 第 24 篇 | AgentForge v0.4 | 多 Agent 协作引擎整合 |
建议读者按顺序学习，因为第 19 篇的 Orchestrator-Worker 框架会被后续所有篇复用，第 20 篇的通信协议是第 22、23 篇的基础设施。
本篇小结
| 知识点 | 核心内容 |
|---|---|
| 单 Agent 局限 | 角色撕裂、上下文爆炸、无并发、难容错、难演化（五道墙） |
| 多 Agent 代价 | 通信开销、编排复杂度、调试困难、Token 倍增（不是银弹） |
| 星型拓扑 | 中心 Orchestrator，O(N) 通信，适合批量分发 |
| 网状拓扑 | 对等通信，O(N²) 链路，适合辩论，规模受限 |
| 层级拓扑 | 树状分解，可伸缩，适合复杂项目 |
| 流水线拓扑 | 线性流转，最易实现，适合阶段清晰的流程 |
| 协议四要素 | 消息格式、路由机制、生命周期、错误处理 |
| SOLID-R 原则 | 单一职责、开闭、替换、接口隔离、依赖倒置、角色清晰 |
| 决策矩阵 | 工具数、Prompt 长度、并发需求、跨领域四维度量化决策 |
| 黄金组合 | 层级 + 流水线，工程上最常用 |
下篇预告
第 19 篇：Orchestrator-Worker 模式 — 主从编排架构
本篇理论落地：我们将用 Go 实现一个完整的 Orchestrator-Worker 框架，覆盖任务分发策略（轮询/能力匹配/负载均衡）、结果聚合与冲突解决。这是模块 4 所有后续篇的基础设施，务必跟着代码敲一遍。
如果本篇内容对你有帮助，欢迎点赞收藏！有任何疑问，欢迎在评论区交流。
智能硬件社区聚焦AI智能硬件技术生态，汇聚嵌入式AI、物联网硬件开发者，打造交流分享平台，同步全国赛事资讯、开展 OPC 核心人才招募，助力技术落地与开发者成长。
更多推荐
11
0- 0
已为社区贡献5条内容
所有评论(0)