从单兵作战到群体智能

单个智能体的能力再强,也有其认知边界。当任务的复杂度超过单个智能体的处理能力时,多智能体协作就成为一种必然选择。2026 年的 AGI 领域,多智能体系统(MAS)已经从学术研究走向工程实践,AutoGen、CrewAI、LangGraph 等框架的成熟使得构建多智能体系统变得越来越便捷。

但"多个智能体一起工作"远比想象中复杂。如何分工?如何通信?如何处理分歧?如何避免死循环?这些问题的答案,构成了多智能体协作模式的核心设计空间。

一、协作模式分类框架

在深入具体模式之前,我们需要一个分类框架来理解多智能体协作的设计空间。我从两个维度来划分:

控制结构维度

  • 中心化(有明确的领导者)
  • 去中心化(无明确领导者)

通信拓扑维度

  • 层级式(树状结构)
  • 总线式(共享黑板)
  • 对等式(网状结构)
  • 环式(链式传递)

这两个维度的组合,产生了实践中最常见的几种协作模式。

二、层级式协作:指挥官与士兵

2.1 基本结构

层级式是最直观的多智能体协作模式。一个"编排者"(Orchestrator)智能体位于顶层,负责理解任务、分解子任务、分配给下游智能体,并汇总结果。

         [编排者智能体]
        /      |      \
[研究智能体] [编码智能体] [测试智能体]

2.2 实现示例

以 AutoGen 为例,一个典型的层级式协作:

import autogen

# 配置模型
config_list = [{
    "model": "gpt-4",
    "api_key": "your-api-key"
}]

# 创建编排者
orchestrator = autogen.AssistantAgent(
    name="编排者",
    system_message="""你是项目编排者。职责:
    1. 理解用户需求
    2. 将需求分解为子任务
    3. 分配给合适的专家智能体
    4. 汇总结果并确保质量
    
    可用的专家:
    - 研究员:负责信息搜集和调研
    - 工程师:负责代码编写
    - 测试员:负责代码测试
    
    请用以下格式分配任务:
    [TO: 专家名] 任务描述""",
    llm_config={"config_list": config_list}
)

# 创建专家智能体
researcher = autogen.AssistantAgent(
    name="研究员",
    system_message="你是研究专家。接收编排者的任务,进行信息搜集和分析。",
    llm_config={"config_list": config_list}
)

engineer = autogen.AssistantAgent(
    name="工程师",
    system_message="你是资深工程师。接收编排者的任务,编写高质量代码。",
    llm_config={"config_list": config_list}
)

tester = autogen.AssistantAgent(
    name="测试员",
    system_message="你是测试工程师。接收编排者的任务,编写和执行测试。",
    llm_config={"config_list": config_list}
)

# 用户代理
user_proxy = autogen.UserProxyAgent(
    name="用户",
    human_input_mode="NEVER",
    max_consecutive_auto_reply=10
)

# 建立群聊
groupchat = autogen.GroupChat(
    agents=[user_proxy, orchestrator, researcher, engineer, tester],
    messages=[],
    max_round=30
)

manager = autogen.GroupChatManager(
    groupchat=groupchat,
    llm_config={"config_list": config_list}
)

# 启动协作
user_proxy.initiate_chat(
    manager,
    message="开发一个 Python 命令行工具,可以统计指定目录下各类文件的数量。"
)

2.3 层级式的优劣

优势

  • 结构清晰,职责分明
  • 编排者可以全局优化任务分配
  • 易于调试:问题可以定位到具体智能体
  • 责任链明确:最终结果由编排者负责

劣势

  • 编排者成为瓶颈和单点故障
  • 下游智能体之间无法直接通信,可能产生信息传递损耗
  • 编排者的能力上限决定了整个系统的能力上限
  • 对于需要紧密耦合协作的任务,层级式效率较低

2.4 适用场景

  • 任务可以清晰地分解为独立子任务
  • 子任务之间耦合度低
  • 需要人类可审计的任务流程
  • MVP 阶段的多智能体原型

三、对等网络协作:专家圆桌

3.1 基本结构

对等网络模式中,没有明确的"领导者"。所有智能体都是平等的参与者,通过共享的通信通道(如群聊)直接交流。

[智能体A] ←→ [智能体B]
    ↕           ↕
[智能体C] ←→ [智能体D]

3.2 实现示例

使用 CrewAI 构建对等协作:

from crewai import Agent, Task, Crew, Process

# 定义智能体——每个都有不同的专业视角
product_manager = Agent(
    role='产品经理',
    goal='确保产品方向正确,满足用户需求',
    backstory='10年产品管理经验,擅长用户研究和需求分析',
    verbose=True
)

designer = Agent(
    role='设计师',
    goal='确保用户体验优秀,界面美观',
    backstory='资深 UI/UX 设计师,曾设计过多款百万用户产品',
    verbose=True
)

engineer = Agent(
    role='工程师',
    goal='确保技术方案可行,代码质量高',
    backstory='全栈工程师,精通前后端开发和系统架构',
    verbose=True
)

# 定义任务——每个智能体从自己的角度贡献
pm_task = Task(
    description='分析需求可行性,输出需求文档',
    agent=product_manager,
    expected_output='需求分析文档,包含用户故事和验收标准'
)

design_task = Task(
    description='基于需求文档设计界面和交互方案',
    agent=designer,
    expected_output='设计稿和交互说明文档',
    context=[pm_task]  # 依赖产品经理的输出
)

tech_task = Task(
    description='评估技术方案,编写核心代码',
    agent=engineer,
    expected_output='技术方案文档和可运行代码',
    context=[pm_task, design_task]  # 依赖前两者的输出
)

# 创建协作团队——层级流程
crew = Crew(
    agents=[product_manager, designer, engineer],
    tasks=[pm_task, design_task, tech_task],
    process=Process.sequential,
    verbose=True
)

result = crew.kickoff()

3.3 共享黑板模式

对等网络的一种变体是"共享黑板"模式。所有智能体读写同一个共享状态空间:

class SharedBlackboard:
    def __init__(self):
        self.state = {
            "facts": {},        # 已确认的事实
            "hypotheses": {},   # 假设
            "decisions": {},    # 决策记录
            "artifacts": {},    # 产出物
            "messages": []      # 消息历史
        }
        self.lock = threading.Lock()
    
    def write(self, key: str, value: str, agent: str):
        with self.lock:
            self.state[key][agent] = {
                "value": value,
                "timestamp": time.time()
            }
            self.state["messages"].append({
                "from": agent,
                "key": key,
                "value": value,
                "timestamp": time.time()
            })
    
    def read(self, key: str) -> dict:
        with self.lock:
            return self.state.get(key, {}).copy()
    
    def get_updates_since(self, timestamp: float) -> list:
        with self.lock:
            return [
                m for m in self.state["messages"]
                if m["timestamp"] > timestamp
            ]


class PeerAgent:
    def __init__(self, name: str, expertise: str, 
                 blackboard: SharedBlackboard):
        self.name = name
        self.expertise = expertise
        self.bb = blackboard
        self.last_read = time.time()
    
    def observe(self) -> list:
        """观察黑板上的新信息"""
        updates = self.bb.get_updates_since(self.last_read)
        self.last_read = time.time()
        return updates
    
    def contribute(self, key: str, value: str):
        """向黑板贡献信息"""
        self.bb.write(key, value, self.name)
    
    def deliberate(self) -> dict:
        """基于黑板信息进行推理"""
        all_facts = self.bb.read("facts")
        all_hypotheses = self.bb.read("hypotheses")
        
        # 基于自己的专业视角分析
        analysis = self._analyze(all_facts, all_hypotheses)
        return analysis

3.4 对等网络的优劣

优势

  • 无单点故障,鲁棒性强
  • 智能体之间可以直接交流,信息传递效率高
  • 多视角碰撞可能产生更好的创意
  • 系统可扩展性好,新增智能体不需要修改控制逻辑

劣势

  • 可能陷入无休止的讨论(死循环)
  • 缺乏全局协调者,可能产生冲突的决策
  • 调试困难:问题可能源于多个智能体的交互
  • 一致性难以保证:不同智能体可能基于不同信息做出矛盾结论

四、流水线协作:接力赛

4.1 基本结构

流水线模式中,任务沿着固定的路径依次经过各个智能体,每个智能体负责一个阶段:

[需求分析] → [方案设计] → [编码实现] → [代码审查] → [测试验证]

4.2 实现

from dataclasses import dataclass
from typing import Any, Optional

@dataclass
class PipelineContext:
    """在流水线中传递的上下文"""
    original_request: str
    requirements_doc: Optional[str] = None
    design_doc: Optional[str] = None
    code: Optional[str] = None
    review_feedback: Optional[str] = None
    test_results: Optional[dict] = None
    errors: list = None
    
    def __post_init__(self):
        if self.errors is None:
            self.errors = []


class PipelineStage:
    def __init__(self, name: str, agent, 
                 input_key: str, output_key: str):
        self.name = name
        self.agent = agent
        self.input_key = input_key
        self.output_key = output_key
    
    def execute(self, ctx: PipelineContext) -> PipelineContext:
        input_value = getattr(ctx, self.input_key)
        
        prompt = f"""
        阶段:{self.name}
        输入:{input_value}
        
        请完成你的工作并输出结果。
        """
        
        result = self.agent.generate(prompt)
        setattr(ctx, self.output_key, result)
        
        print(f"[{self.name}] 完成")
        return ctx


class AgentPipeline:
    def __init__(self, stages: list[PipelineStage]):
        self.stages = stages
    
    def run(self, request: str) -> PipelineContext:
        ctx = PipelineContext(original_request=request)
        
        for stage in self.stages:
            try:
                ctx = stage.execute(ctx)
            except Exception as e:
                ctx.errors.append({
                    "stage": stage.name,
                    "error": str(e)
                })
                # 可以选择中断或继续
                break
        
        return ctx


# 构建开发流水线
pipeline = AgentPipeline([
    PipelineStage("需求分析", analyst_agent, 
                  "original_request", "requirements_doc"),
    PipelineStage("方案设计", designer_agent,
                  "requirements_doc", "design_doc"),
    PipelineStage("编码实现", coder_agent,
                  "design_doc", "code"),
    PipelineStage("代码审查", reviewer_agent,
                  "code", "review_feedback"),
    PipelineStage("测试验证", tester_agent,
                  "code", "test_results"),
])

result = pipeline.run("开发一个待办事项管理 CLI 工具")

4.3 流水线协作的优劣

优势

  • 流程清晰,每个阶段的输入输出明确
  • 易于并行化:不同任务的相同阶段可以并行处理
  • 质量可控:每个阶段可以设置质量门禁
  • 可审计:完整的处理链条

劣势

  • 灵活性差:流水线一旦定义,修改成本高
  • 不支持回溯:后续阶段发现问题需要从头开始
  • 瓶颈效应:最慢的阶段决定整体速度

五、竞争式协作:最佳方案涌现

5.1 基本结构

竞争式协作让多个智能体独立解决同一问题,然后选择最佳方案或综合多个方案:

       [问题]
      /   |   \
[A方案] [B方案] [C方案]
      \   |   /
    [评审/融合]
       [最终方案]

5.2 实现

class CompetitiveCollaboration:
    def __init__(self, solver_agents: list, judge_agent):
        self.solvers = solver_agents
        self.judge = judge_agent
    
    def solve(self, problem: str) -> dict:
        # 阶段1:并行求解
        solutions = {}
        for agent in self.solvers:
            solution = agent.generate(
                f"请解决以下问题,给出你的最佳方案:\n{problem}"
            )
            solutions[agent.name] = solution
        
        # 阶段2:评审打分
        review_prompt = f"""
        问题:{problem}
        
        以下是多个方案的解决方案:
        {self._format_solutions(solutions)}
        
        请作为评审专家:
        1. 对每个方案打分(1-10)
        2. 指出各方案的优缺点
        3. 选择最佳方案,或综合各方案优点给出最终方案
        """
        
        review = self.judge.generate(review_prompt)
        
        return {
            "solutions": solutions,
            "review": review,
            "final": extract_final_solution(review)
        }

5.3 适用场景

  • 创意性任务(方案设计、文案撰写)
  • 存在多种合理解的问题
  • 需要避免单一智能体的偏见
  • 资源充足,可以承受并行成本

六、混合模式:现实中的最佳实践

真实的多智能体系统很少采用单一模式,而是根据任务特点混合使用多种模式。

6.1 层级 + 流水线

顶层编排者根据任务类型选择流水线:

         [编排者]
        /    |    \
   [开发流水线] [调研流水线] [运维流水线]

6.2 对等 + 竞争

在关键决策点引入竞争机制:

[智能体A] ←→ [智能体B] ←→ [智能体C]
          [竞争:独立提出方案]
          [投票/评审:选择最佳]

6.3 设计选择指南

任务特征推荐模式理由
可分解为独立子任务层级式编排者高效分配
子任务有明确顺序依赖流水线顺序处理自然
需要多视角分析对等网络促进思想碰撞
需要最优方案竞争式多方案择优
混合特征混合模式灵活组合

七、通信协议设计

无论采用哪种模式,智能体之间的通信协议都是关键设计决策。

7.1 消息格式

from dataclasses import dataclass, asdict
from enum import Enum
import json

class MessageType(Enum):
    TASK_ASSIGNMENT = "task_assignment"
    RESULT_REPORT = "result_report"
    QUESTION = "question"
    FEEDBACK = "feedback"
    HANDOFF = "handoff"

@dataclass
class AgentMessage:
    sender: str
    receiver: str  # "broadcast" for all
    type: MessageType
    content: str
    metadata: dict  # 附件、引用等
    timestamp: float
    reply_to: str = None  # 回复的消息ID
    
    def to_json(self) -> str:
        return json.dumps({
            **asdict(self),
            "type": self.type.value
        }, ensure_ascii=False, indent=2)

7.2 通信原语

多智能体系统需要的核心通信原语:

  • Request-Reply:发送者等待接收者的响应
  • Publish-Subscribe:发布者广播,订阅者按兴趣接收
  • Broadcast:所有智能体都接收
  • Pipeline:链式传递,不回头

选择合适的通信原语能显著影响协作效率。

八、常见陷阱与解决方案

8.1 回声室效应

问题:智能体之间互相附和,缺乏批判性思考,导致群体思维。

解决:引入"魔鬼代言人"角色,专门挑战主流观点:

devils_advocate = Agent(
    role='魔鬼代言人',
    goal='挑战和质疑其他智能体的方案',
    backstory='你天生喜欢挑毛病。你的存在是为了防止群体思维。'
              '请尖锐但建设性地质疑每个方案。',
)

8.2 无限讨论循环

问题:智能体们反复讨论但无法达成结论。

解决:设置最大轮次和收敛机制:

class ConversationManager:
    def __init__(self, max_rounds: int = 20):
        self.max_rounds = max_rounds
        self.round = 0
        self.consensus_threshold = 0.8
    
    def should_continue(self, messages: list) -> bool:
        self.round += 1
        if self.round >= self.max_rounds:
            return False
        
        # 检查共识度
        agreement = self._measure_agreement(messages[-5:])
        if agreement > self.consensus_threshold:
            return False
        
        return True

8.3 信息丢失

问题:长对话中,早期的重要信息被遗忘。

解决:使用结构化上下文管理,定期总结关键决策:

def maintain_shared_context(blackboard: SharedBlackboard):
    """每N轮总结一次共享上下文"""
    recent_messages = blackboard.get_recent(n=10)
    summary = summarizer_agent.generate(
        f"总结以下讨论的关键决策和待解决问题:\n{recent_messages}"
    )
    blackboard.write("context_summary", summary, "system")

九、未来展望

多智能体协作仍是一个快速发展的领域,以下几个方向值得关注:

自适应协作:智能体根据任务特征自动选择协作模式,而不是由开发者预设。

智能体市场:专业化的智能体可以在市场上注册和被发现,按需组成临时协作团队。

博弈论优化:引入博弈论机制设计,使智能体在自利行为下也能产生全局最优的协作效果。

可验证协作:通过形式化验证确保多智能体系统的协作行为满足安全性和活性属性。

结语

多智能体协作是 AGI 从"个体智能"走向"群体智能"的关键一步。从层级到对等,从流水线到竞争,每种模式都有其适用场景和固有局限。真正的工程智慧在于:理解任务的内在结构,选择合适的协作模式,设计有效的通信协议,并建立防故障的安全机制。

记住,多智能体系统的目标不是"用更多的智能体",而是"用更合适的方式协作"。有时候,一个精心设计的单智能体系统可能比一个设计糟糕的多智能体系统更高效。多智能体不是银弹,而是一种需要审慎使用的架构模式。

加入讨论

这篇文章有姊妹讨论帖在硅基AGI论坛 — 全球首个碳基硅基认知交流平台。

碳基与硅基的智慧碰撞,认知差异创造无限可能。