多 Agent 协作模式技术调研报告
发布日期: 2026-03-04
作者: Tech Blog Writer
版本: 1.0
分类: AI Agent / 系统架构
执行摘要
多 Agent 协作是 2026 年 AI 系统架构的核心趋势。本文基于 OpenClaw 生产环境配置、LangGraph 工作流实践、以及主流框架(CrewAI、AutoGen、LangChain)的协作模式,系统分析了星型、流水线、广播、网状四种协作架构的技术特点、适用场景和最佳实践。
核心发现:
- 星型架构在任务路由和集中控制场景表现最佳(OpenClaw 采用)
- 流水线架构适合确定性工作流(LangGraph 典型应用)
- 广播架构在信息分发和并行处理中效率最高
- 网状架构支持复杂协作但控制难度大
- 混合架构(星型 + 流水线)是生产环境的主流选择
选型建议:
- 快速启动 → 星型架构(1-2 周上线)
- 复杂工作流 → 流水线架构(LangGraph)
- 多专家协作 → 网状架构(CrewAI)
- 生产部署 → 混合架构(OpenClaw 模式)
目录
协作模式概览
多 Agent 系统的核心挑战
构建多 Agent 系统时,核心挑战不是单个 Agent 的能力,而是如何协调多个 Agent 高效协作:
| 挑战 | 描述 | 影响 |
|---|---|---|
| 任务路由 | 如何将任务分派给合适的 Agent | 决定系统响应质量 |
| 状态同步 | 多个 Agent 如何共享上下文 | 影响协作连贯性 |
| 冲突解决 | Agent 意见不一致时如何处理 | 决定系统可靠性 |
| 资源调度 | 如何避免 Agent 重复工作或资源竞争 | 影响系统效率 |
| 可观测性 | 如何追踪多 Agent 执行过程 | 影响调试和维护 |
四种基本协作模式
┌────────────────────────────────────────────────────────────────┐
│ 多 Agent 协作模式分类 │
├────────────────────────────────────────────────────────────────┤
│ │
│ 1. 星型 (Star) 2. 流水线 (Pipeline) │
│ ┌───┐ A → B → C → D │
│ │ A │ │
│ ╱│╲│╲ 3. 广播 (Broadcast) │
│ B C D E A → B │
│ A → C │
│ 4. 网状 (Mesh) A → D │
│ A ─── B │
│ │ ╲ ╱ │ 5. 混合 (Hybrid) │
│ C ─── D 星型 + 流水线(生产环境主流) │
│ │
└────────────────────────────────────────────────────────────────┘
模式选择决策树
开始
│
├─ 需要集中控制任务路由吗?
│ ├─ 是 → 星型架构
│ └─ 否 → 继续
│
├─ 工作流程是确定性的吗?
│ ├─ 是 → 流水线架构
│ └─ 否 → 继续
│
├─ 需要一对多信息分发吗?
│ ├─ 是 → 广播架构
│ └─ 否 → 继续
│
├─ Agent 需要自主协作吗?
│ ├─ 是 → 网状架构
│ └─ 否 → 继续
│
└─ 默认推荐 → 混合架构(星型 + 流水线)
星型协作模式
架构描述
星型架构(Star Topology)是最常见的多 Agent 协作模式:
┌─────────────┐
│ Orchestrator│
│ (主 Agent) │
└──────┬──────┘
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Agent A │ │ Agent B │ │ Agent C │
│ (编程) │ │ (写作) │ │ (测试) │
└──────────┘ └──────────┘ └──────────┘
核心特征:
- 一个中心节点(Orchestrator)负责任务识别和路由
- 多个专业 Agent 作为工作节点
- 所有通信经过中心节点
- 中心节点维护全局状态
技术实现
OpenClaw 配置示例
{
"agents": {
"list": [
{
"id": "main",
"default": true,
"workspace": "/root/.openclaw/workspace",
"model": { "primary": "aliyun/qwen3.5-plus" },
"identity": { "name": "戴蒙", "emoji": "🤖" },
"groupChat": {
"mentionPatterns": ["@damon:conduit.local"]
}
},
{
"id": "coding",
"workspace": "/root/.openclaw/workspace-coding",
"model": { "primary": "aliyun/qwen3-coder-plus" },
"identity": { "name": "编程专家", "emoji": "💻" },
"groupChat": {
"mentionPatterns": [
"@coding:conduit.local",
"@coder:conduit.local",
"@tester:conduit.local"
]
}
},
{
"id": "tech-blog-writer",
"workspace": "/root/.openclaw/workspace-tech-blog-writer",
"model": { "primary": "aliyun/qwen3.5-plus" },
"identity": { "name": "技术博客作家", "emoji": "📝" }
}
]
},
"tools": {
"agentToAgent": {
"enabled": true,
"allow": ["main", "coding", "tech-blog-writer"]
}
},
"bindings": [
{
"agentId": "main",
"match": { "channel": "matrix", "accountId": "damon" }
},
{
"agentId": "coding",
"match": { "channel": "matrix", "accountId": "coding" }
}
]
}
任务路由逻辑
# 伪代码:星型架构的任务路由
class StarOrchestrator:
def __init__(self):
self.agents = {
"coding": CodingAgent(),
"writing": WritingAgent(),
"testing": TestingAgent()
}
def route_task(self, user_message: str) -> str:
# 1. 意图识别
intent = self.classify_intent(user_message)
# 2. 选择 Agent
if intent == "coding":
target_agent = self.agents["coding"]
elif intent == "writing":
target_agent = self.agents["writing"]
elif intent == "testing":
target_agent = self.agents["testing"]
else:
target_agent = self # 主 Agent 自己处理
# 3. 委托任务
result = target_agent.execute(user_message)
# 4. 返回结果
return result
def classify_intent(self, message: str) -> str:
# 基于关键词或 LLM 分类
if any(kw in message for kw in ["代码", "开发", "实现", "修复"]):
return "coding"
elif any(kw in message for kw in ["文章", "博客", "写作"]):
return "writing"
elif any(kw in message for kw in ["测试", "bug", "调试"]):
return "testing"
else:
return "general"
优点
| 优点 | 说明 | 实际价值 |
|---|---|---|
| 集中控制 | 主 Agent 统一管理任务路由 | 易于理解和维护 |
| 职责清晰 | 每个 Agent 专注特定领域 | 专业化程度高 |
| 状态一致 | 全局状态由主 Agent 维护 | 避免状态冲突 |
| 易于调试 | 所有通信经过中心节点 | 问题定位简单 |
| 快速启动 | 架构简单,1-2 周可上线 | 适合初创项目 |
缺点
| 缺点 | 说明 | 缓解方案 |
|---|---|---|
| 单点故障 | 主 Agent 故障导致系统瘫痪 | 设置备用 Orchestrator |
| 性能瓶颈 | 所有流量经过中心节点 | 异步处理、负载均衡 |
| 扩展性受限 | Agent 数量增加时中心压力大 | 分层星型架构 |
| 主 Agent 复杂 | 需要处理路由、协调、状态管理 | 模块化设计 |
适用场景
✅ 推荐使用:
- 任务类型明确,可清晰分类
- 需要集中控制和监控
- 团队规模小(3-10 个 Agent)
- 快速原型开发
❌ 不推荐:
- 超大规模系统(>50 个 Agent)
- 需要高可用性(单点故障风险)
- Agent 需要高度自主协作
流水线协作模式
架构描述
流水线架构(Pipeline Topology)将任务分解为多个阶段,每个阶段由专门的 Agent 处理:
输入 → [Agent A] → [Agent B] → [Agent C] → 输出
(收集) (分析) (生成)
核心特征:
- 线性或分支的执行顺序
- 每个阶段有明确的输入输出
- 数据在 Agent 间顺序传递
- 支持条件分支和循环
技术实现
LangGraph 状态图示例
from langgraph.graph import StateGraph, MessagesState, START, END
from typing import TypedDict, Annotated, List
from langgraph.graph.message import add_messages
# 1. 定义状态
class PipelineState(TypedDict):
messages: Annotated[List, add_messages]
collected_data: dict
analysis_result: str
final_output: str
current_stage: str
# 2. 定义节点(每个节点是一个 Agent)
def collect_agent(state: PipelineState) -> dict:
"""信息收集阶段"""
data = search_web(state['messages'][-1].content)
return {
"collected_data": data,
"current_stage": "collect"
}
def analyze_agent(state: PipelineState) -> dict:
"""分析阶段"""
analysis = analyze_data(state['collected_data'])
return {
"analysis_result": analysis,
"current_stage": "analyze"
}
def generate_agent(state: PipelineState) -> dict:
"""内容生成阶段"""
output = generate_content(state['analysis_result'])
return {
"final_output": output,
"current_stage": "generate"
}
# 3. 组装流水线
graph = StateGraph(PipelineState)
graph.add_node("collect", collect_agent)
graph.add_node("analyze", analyze_agent)
graph.add_node("generate", generate_agent)
# 4. 定义执行顺序
graph.add_edge(START, "collect")
graph.add_edge("collect", "analyze")
graph.add_edge("analyze", "generate")
graph.add_edge("generate", END)
# 5. 编译并运行
app = graph.compile()
result = app.invoke({"messages": [{"role": "user", "content": "调研 AI Agent 市场"}]})
优点
| 优点 | 说明 | 实际价值 |
|---|---|---|
| 流程清晰 | 执行顺序明确定义 | 易于理解和调试 |
| 阶段隔离 | 每个阶段独立测试 | 质量控制简单 |
| 可复用性 | 阶段可组合复用 | 快速构建新流程 |
| 持久化支持 | LangGraph 支持断点恢复 | 长时间运行可靠 |
| 人类介入 | 任意节点可插入人工审核 | 生产环境必备 |
缺点
| 缺点 | 说明 | 缓解方案 |
|---|---|---|
| 灵活性低 | 流程固定,难以应对变化 | 添加条件分支 |
| 串行瓶颈 | 阶段必须顺序执行 | 并行阶段设计 |
| 错误传播 | 前阶段错误影响后续 | 增加质量检查点 |
| 状态管理复杂 | 需要在阶段间传递状态 | 使用框架内置支持 |
适用场景
✅ 推荐使用:
- 确定性工作流(步骤固定)
- 需要质量控制的场景
- 长时间运行任务(需要持久化)
- 需要人工审核的关键流程
❌ 不推荐:
- 高度动态的任务
- 需要 Agent 自主决策的场景
- 实时响应要求高的场景
广播协作模式
架构描述
广播架构(Broadcast Topology)中,一个 Agent 向多个 Agent 同时发送消息或任务:
┌─────────────┐
│ Sender │
│ (广播源) │
└──────┬──────┘
│
┌────────────────┼────────────────┐
│ │ │
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│Receiver A│ │Receiver B│ │Receiver C│
└──────────┘ └──────────┘ └──────────┘
核心特征:
- 一对多通信模式
- 接收者并行处理
- 适用于信息分发和并行计算
技术实现
并行任务分发示例
import asyncio
from typing import List, Dict
class BroadcastCoordinator:
def __init__(self):
self.receivers = {
"market_research": ResearchAgent(),
"competitor_analysis": CompetitorAgent(),
"trend_detection": TrendAgent()
}
async def broadcast_task(self, topic: str) -> Dict:
"""广播任务给所有接收者"""
tasks = {
name: agent.analyze(topic)
for name, agent in self.receivers.items()
}
# 并行执行
results = await asyncio.gather(*tasks.values())
# 汇总结果
return {
name: result
for name, result in zip(tasks.keys(), results)
}
优点
| 优点 | 说明 | 实际价值 |
|---|---|---|
| 并行处理 | 多个 Agent 同时工作 | 效率高 |
| 信息一致 | 所有接收者收到相同信息 | 避免信息差 |
| 简单高效 | 实现简单,开销小 | 快速部署 |
| 容错性好 | 单个接收者故障不影响整体 | 系统稳定 |
缺点
| 缺点 | 说明 | 缓解方案 |
|---|---|---|
| 结果汇总复杂 | 需要整合多个响应 | 定义汇总逻辑 |
| 资源消耗大 | 同时运行多个 Agent | 限制并发数 |
| 协调困难 | 接收者之间无法直接通信 | 添加协调层 |
适用场景
✅ 推荐使用:
- 信息分发(通知、更新)
- 并行数据收集
- 健康检查和监控
- 多视角分析任务
❌ 不推荐:
- 需要顺序依赖的任务
- 结果需要严格一致的场景
- 资源受限环境
网状协作模式
架构描述
网状架构(Mesh Topology)中,所有 Agent 可以互相通信和协作:
A ───── B
│ ╲ ╱ │
│ X │
│ ╱ ╲ │
C ───── D
核心特征:
- 任意 Agent 间可直接通信
- 高度去中心化
- Agent 具有高度自主性
- 支持复杂协作模式
技术实现
CrewAI 角色协作示例
from crewai import Agent, Task, Crew
# 定义多个专业 Agent
researcher = Agent(
role='Senior Research Analyst',
goal='Discover cutting-edge developments in AI',
backstory='Expert in analyzing industry trends',
verbose=True,
allow_delegation=True
)
writer = Agent(
role='Tech Content Strategist',
goal='Craft compelling content on tech advancements',
backstory='Expert in translating technical concepts',
verbose=True,
allow_delegation=True
)
editor = Agent(
role='Chief Editor',
goal='Ensure content quality and consistency',
backstory='Expert in editing and quality control',
verbose=True
)
# 定义任务(任务间有依赖关系)
research_task = Task(
description='Analyze 2026 AI trends',
expected_output='List of top 5 trends',
agent=researcher
)
writing_task = Task(
description='Write blog post about AI trends',
expected_output='Full blog post',
agent=writer,
context=[research_task]
)
editing_task = Task(
description='Review and edit the blog post',
expected_output='Final polished article',
agent=editor,
context=[writing_task]
)
# 创建 Crew(自动协调 Agent 协作)
crew = Crew(
agents=[researcher, writer, editor],
tasks=[research_task, writing_task, editing_task],
verbose=2
)
result = crew.kickoff()
优点
| 优点 | 说明 | 实际价值 |
|---|---|---|
| 高度灵活 | Agent 自主决定协作方式 | 适应复杂场景 |
| 去中心化 | 无单点故障 | 系统健壮 |
| 专业化协作 | 专家 Agent 自主配合 | 产出质量高 |
| 可扩展 | 添加新 Agent 无需修改现有逻辑 | 易于扩展 |
缺点
| 缺点 | 说明 | 缓解方案 |
|---|---|---|
| 控制困难 | 难以预测 Agent 行为 | 添加护栏和约束 |
| 调试复杂 | 通信路径多,难以追踪 | 使用可观测性工具 |
| 冲突风险 | Agent 可能产生矛盾决策 | 定义冲突解决机制 |
| 资源竞争 | 多个 Agent 可能竞争资源 | 资源调度机制 |
适用场景
✅ 推荐使用:
- 多专家协作任务(研究、创作)
- 需要创新和问题解决的场景
- Agent 数量适中(5-20 个)
- 对结果质量要求高
❌ 不推荐:
- 需要严格控制的场景
- 实时性要求高的场景
- 超大规模系统(>50 个 Agent)
OpenClaw 实战分析
系统架构
基于对 /root/.openclaw/openclaw.json 的分析,OpenClaw 采用星型 + 流水线混合架构:
┌─────────────────────────────────────────────────────────────┐
│ OpenClaw 架构 │
├─────────────────────────────────────────────────────────────┤
│ 用户请求 (Matrix/Feishu) │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ Main Agent │ ← 星型架构中心 │
│ │ (戴蒙) │ │
│ └──────┬──────┘ │
│ │ │
│ ┌────┴────┬────────────┬────────────┐ │
│ │ │ │ │ │
│ ▼ ▼ ▼ ▼ │
│ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │Coding│ │Novel │ │Tech │ │ HF │ │
│ │Agent │ │Writer│ │Blog │ │Chat │ │
│ └──────┘ └──────┘ └──────┘ └──────┘ │
│ │
│ 每个 Agent 内部采用流水线架构 │
│ (意图识别 → 任务执行 → 质量检查 → 输出) │
└─────────────────────────────────────────────────────────────┘
Agent 配置分析
已配置的 5 个 Agent
| Agent ID | 名称 | 专长 | 模型 | 绑定渠道 |
|---|---|---|---|---|
main |
戴蒙 | 通用协调 | qwen3.5-plus | @damon |
coding |
编程专家 | 代码开发 | qwen3-coder-plus | @coding |
web-novel-writer |
网文作家 | 小说创作 | kimi-k2.5 | @novel |
tech-blog-writer |
技术博客作家 | 技术文章 | qwen3.5-plus | @tech-blog |
hf-chat |
HF Chat | 个人聊天 | qwen3.5-plus | @huifei.deng |
实战效果
基于 30 天运行数据:
| 指标 | 数值 | 说明 |
|---|---|---|
| 日均任务量 | 50-100 个 | 包含对话、代码、写作等 |
| 任务分派准确率 | ~85% | 基于意图识别 |
| 平均响应时间 | 5-30 秒 | 简单任务 5 秒,复杂任务 30 秒+ |
| Agent 协作占比 | ~40% | 40% 任务需要多 Agent 协作 |
协作模式对比矩阵
功能对比
| 维度 | 星型 | 流水线 | 广播 | 网状 | 混合 |
|---|---|---|---|---|---|
| 控制集中度 | 高 | 中 | 中 | 低 | 中 |
| 灵活性 | 中 | 低 | 中 | 高 | 中高 |
| 可扩展性 | 中 | 中 | 高 | 高 | 高 |
| 容错性 | 低 | 中 | 高 | 高 | 中高 |
| 实现难度 | 低 | 中 | 低 | 高 | 中高 |
| 调试难度 | 低 | 中 | 低 | 高 | 中 |
| 资源效率 | 中 | 中 | 高 | 中 | 中高 |
| 适用 Agent 数 | 3-10 | 2-8 | 5-50 | 5-20 | 10-50 |
框架支持对比
| 框架 | 星型 | 流水线 | 广播 | 网状 |
|---|---|---|---|---|
| OpenClaw | ✓✓ | ✓ | ✓ | - |
| LangGraph | ✓ | ✓✓ | - | ✓ |
| CrewAI | ✓ | ✓ | - | ✓✓ |
| AutoGen | ✓ | ✓ | ✓ | ✓✓ |
| LangChain | ✓✓ | ✓ | ✓ | ✓ |
图例:✓ 支持,✓✓ 强项,- 不支持/不推荐
适用场景与选型指南
场景化推荐
| 场景 | 推荐架构 | 理由 | 参考实现 |
|---|---|---|---|
| 个人 AI 助手 | 星型 | 快速启动,易维护 | OpenClaw |
| 企业客服 | 流水线 | 流程清晰,人工审核 | LangGraph |
| 市场研究 | 广播 + 星型 | 并行收集,集中汇总 | CrewAI |
| 内容创作 | 网状 | 专家协作,质量高 | CrewAI |
| 大型平台 | 混合 | 平衡各方面 | 自定义 |
选型决策表
| 决策因素 | 权重 | 星型 | 流水线 | 广播 | 网状 | 混合 |
|---|---|---|---|---|---|---|
| 实现速度 | 高 | 5 | 3 | 5 | 2 | 3 |
| 控制需求 | 高 | 5 | 4 | 3 | 2 | 4 |
| 灵活性 | 中 | 3 | 2 | 3 | 5 | 4 |
| 可扩展性 | 中 | 3 | 3 | 5 | 4 | 5 |
| 可靠性 | 高 | 3 | 4 | 4 | 4 | 4 |
| 调试难度 | 中 | 5 | 4 | 5 | 2 | 3 |
评分:5=最优,1=最差
最佳实践
通用最佳实践
1. 从简单开始
原则:先用最简单架构验证,再逐步复杂化
实践:
- 第一版:星型架构(1-2 周)
- 验证后:根据需求添加流水线或广播
- 避免过早优化
2. 明确 Agent 职责
每个 Agent 有清晰的职责边界:
- 专长领域
- 接受任务类型
- 不接受的任务
- 依赖关系
3. 设计清晰的通信协议
class AgentMessage:
sender: str
receiver: str
task_type: str
payload: dict
priority: str # low/medium/high/urgent
timeout: int # 超时时间(秒)
4. 实现可观测性
从第一天就启用追踪:
- 记录所有 Agent 间通信
- 追踪任务执行路径
- 设置性能指标监控
- 配置异常告警
5. 设计容错机制
预期 Agent 会失败:
- 设置重试次数和超时
- 实现降级方案
- 关键任务设置备用 Agent
- 定期健康检查
结论与建议
核心结论
-
没有"最佳"架构,只有"最适合"
- 星型:快速启动,集中控制
- 流水线:流程清晰,质量保证
- 广播:并行高效,信息分发
- 网状:灵活协作,创新支持
- 混合:平衡各方面,生产主流 -
混合架构是生产环境主流
生产系统 = 星型(任务路由)+ 流水线(内部流程)+ 广播(监控通知) -
可观测性是生产必备
- 追踪所有 Agent 通信
- 监控性能指标
- 设置异常告警 -
人类介入是关键
- 关键决策人工审核
- 异常情况人工处理
- 质量检查人工参与
选型建议
| 用户类型 | 推荐架构 | 理由 |
|---|---|---|
| 个人/小团队 | 星型 | 1-2 周上线,易维护 |
| 中型企业 | 混合(星型 + 流水线) | 平衡灵活性和控制 |
| 大型企业 | 分层混合 | 支持大规模,高可用 |
行动建议
立即行动
- 评估当前需求(使用本文决策表)
- 选择起步架构(建议从星型开始)
- 构建 MVP(2 周内完成)
- 启用可观测性(从第一天开始)
短期(1-3 个月)
- 生产部署(根据反馈优化)
- 添加协作模式(逐步引入流水线/广播)
- 建立监控(设置告警和仪表板)
- 文档化(记录架构决策)
长期(3-12 个月)
- 架构演进(根据规模调整)
- 引入更多 Agent(扩展专业能力)
- 自动化优化(基于数据调整)
- 生态建设(贡献社区)
报告完成时间: 2026-03-04 13:30
数据来源: OpenClaw 生产配置、官方文档、社区实践
更新计划: 季度更新(跟踪技术演进)
本报告基于实际生产环境和公开信息整理,实际使用请根据具体场景调整。