多 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 模式)


目录

  1. 协作模式概览
  2. 星型协作模式
  3. 流水线协作模式
  4. 广播协作模式
  5. 网状协作模式
  6. OpenClaw 实战分析
  7. 协作模式对比矩阵
  8. 适用场景与选型指南
  9. 最佳实践
  10. 结论与建议

协作模式概览

多 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
- 定期健康检查


结论与建议

核心结论

  1. 没有"最佳"架构,只有"最适合"
    - 星型:快速启动,集中控制
    - 流水线:流程清晰,质量保证
    - 广播:并行高效,信息分发
    - 网状:灵活协作,创新支持
    - 混合:平衡各方面,生产主流

  2. 混合架构是生产环境主流
    生产系统 = 星型(任务路由)+ 流水线(内部流程)+ 广播(监控通知)

  3. 可观测性是生产必备
    - 追踪所有 Agent 通信
    - 监控性能指标
    - 设置异常告警

  4. 人类介入是关键
    - 关键决策人工审核
    - 异常情况人工处理
    - 质量检查人工参与

选型建议

用户类型 推荐架构 理由
个人/小团队 星型 1-2 周上线,易维护
中型企业 混合(星型 + 流水线) 平衡灵活性和控制
大型企业 分层混合 支持大规模,高可用

行动建议

立即行动

  1. 评估当前需求(使用本文决策表)
  2. 选择起步架构(建议从星型开始)
  3. 构建 MVP(2 周内完成)
  4. 启用可观测性(从第一天开始)

短期(1-3 个月)

  1. 生产部署(根据反馈优化)
  2. 添加协作模式(逐步引入流水线/广播)
  3. 建立监控(设置告警和仪表板)
  4. 文档化(记录架构决策)

长期(3-12 个月)

  1. 架构演进(根据规模调整)
  2. 引入更多 Agent(扩展专业能力)
  3. 自动化优化(基于数据调整)
  4. 生态建设(贡献社区)

报告完成时间: 2026-03-04 13:30
数据来源: OpenClaw 生产配置、官方文档、社区实践
更新计划: 季度更新(跟踪技术演进)


本报告基于实际生产环境和公开信息整理,实际使用请根据具体场景调整。