第21章 多智能体协作架构

本章来源：综合自 Agentic Design Patterns 第七章（协作模式与拓扑结构分析）、Hello-Agents 第六章（框架实战与编排策略）

核心问题 —— 本章要解答什么

前两章解决了"智能体如何与工具通信"和"智能体如何与智能体通信"的协议层问题。本章上升一层，讨论多智能体系统的架构设计：当我们需要多个智能体协作完成复杂任务时，应该如何组织它们之间的关系、分配它们的角色、编排它们的工作流？

单体智能体在面对多领域、多步骤的复杂任务时存在根本性的能力瓶颈。多智能体协作模式通过任务分解和角色专业化来突破这一限制 [Wu et al., 2023; Hong et al., 2023; Li et al., 2023]。但"多个智能体一起工作"并不自动等于"比一个更好"——系统的效能取决于拓扑结构的选择、协作模式的设计以及编排策略的实现。

设计空间 —— 可选方案与取舍

21.1 为何需要多智能体协作

单体智能体模型面临三个结构性约束：

工具过载：当一个智能体需要管理数十种工具时，工具描述本身就会消耗大量上下文窗口，导致工具选择准确率下降。多智能体架构允许每个智能体只管理一组相关工具。

专业化需求：不同子任务可能需要不同的提示词策略、不同的模型能力，甚至不同的推理模式。将它们硬塞进单一智能体的系统提示词中会导致角色混乱和能力稀释。

可靠性要求：单个智能体的失败会导致整个任务失败。分布式架构中，单个智能体的故障不一定导致系统级失败，提高了整体鲁棒性。

21.2 协作形式的设计谱系

多智能体协作可以采取多种形式，每种形式适用于不同的任务特征：

顺序交接（Sequential Handoffs）：一个智能体完成任务后将输出传递给下一个智能体。适用于具有清晰阶段划分的线性工作流，如"研究→撰写→审核"。

并行处理（Parallel Processing）：多个智能体同时处理问题的不同部分，结果稍后被组合。适用于可以独立分解的子任务。

辩论与共识（Debate and Consensus）：持有不同观点的智能体通过讨论评估选项，最终达成共识。适用于需要多角度分析的决策场景。

层级委派（Hierarchical Delegation）：管理者智能体动态将任务委托给工作者智能体并综合结果。适用于需要灵活调度的复杂任务。

专家团队（Expert Teams）：不同领域的专家智能体协作产生复杂输出。如研究员、作家、编辑协作完成一份报告。

批评者-审查者（Critic-Reviewer）：一组智能体生成初始输出，另一组智能体评估其质量。对代码生成、研究写作特别有效，能减少幻觉和错误。

架构解析 —— 拓扑结构深度分析

21.3 六种拓扑模型

多智能体系统的拓扑结构是其最核心的架构决策。不同的拓扑直接决定了系统的通信模式、故障特性和扩展性。

1. 单智能体（Single Agent）

最基本的模型，不涉及多智能体交互。适用于可以由单个自给自足的智能体独立处理的任务。优点是实现简单，缺点是能力受限于单个智能体的资源和工具集。

2. 网络（Network）

多个智能体以去中心化方式直接相互交互，通信以点对点方式进行。优点是弹性强（单点故障不会瘫痪系统），缺点是管理通信开销和确保决策连贯性具有挑战性。

3. 监督者（Supervisor）

一个专用的监督者智能体监督和协调一组下属智能体，充当通信、任务分配和冲突解决的中心枢纽。优点是权限清晰、管理简单，缺点是引入单点故障和潜在的性能瓶颈。

4. 监督者作为工具（Supervisor as Tool）

监督者的角色从"直接命令控制"转变为"提供资源和指导"。监督者提供工具、数据或计算服务帮助其他智能体更有效地执行任务，而不强制规定每个操作。这种方式在利用监督者能力的同时避免了严格的自上而下控制。

5. 层级化（Hierarchical）

在监督者概念上创建多层组织结构，涉及多级监督者，最低层有一组操作智能体。适合可以层层分解的复杂问题，提供了结构化的可扩展性管理方法。

6. 自定义（Custom）

代表终极灵活性，允许混合前述模型或创建全新设计。通常源于需要针对特定性能指标优化、处理高度动态环境或纳入领域特定知识的需求。

21.4 拓扑选择的决策矩阵

选择拓扑时需要考虑的关键因素：

因素	网络	监督者	层级化
任务可分解性	低（自组织）	中（集中分配）	高（层层分解）
智能体数量	少量（<10）	中等（10-50）	大量（50+）
故障容忍度	高	低（单点故障）	中
通信开销	高（O(n^2)）	低（O(n)）	低（O(n)）
决策连贯性	低	高	高
实现复杂度	中	低	高

关键实现决策 —— 编排策略与框架实践

21.5 顺序编排模式

Google ADK的SequentialAgent是顺序编排的典型实现。智能体按照定义的顺序依次执行，前一个的输出通过会话状态传递给下一个。

from google.adk.agents import SequentialAgent, Agent

# 第一步：获取数据，输出存储到session.state["data"]
step1 = Agent(name="Step1_Fetch", output_key="data")

# 第二步：处理数据，使用前一步的输出
step2 = Agent(
    name="Step2_Process",
    instruction="Analyze the information found in state['data'] and provide a summary."
)

pipeline = SequentialAgent(
    name="MyPipeline",
    sub_agents=[step1, step2]
)

顺序编排的设计关键在于状态传递机制——output_key参数将智能体的输出存储到会话状态中，后续智能体通过state['key']访问。这种设计实现了智能体间的松耦合：每个智能体不需要知道它的输出将被谁消费，也不需要知道它的输入来自谁。

21.6 并行编排模式

当多个子任务之间没有依赖关系时，并行执行可以显著提高效率。Google ADK的ParallelAgent支持这种模式。

from google.adk.agents import ParallelAgent, Agent

weather_fetcher = Agent(
    name="weather_fetcher",
    model="gemini-2.0-flash-exp",
    instruction="Fetch the weather for the given location.",
    output_key="weather_data"
)

news_fetcher = Agent(
    name="news_fetcher",
    model="gemini-2.0-flash-exp",
    instruction="Fetch the top news story for the given topic.",
    output_key="news_data"
)

data_gatherer = ParallelAgent(
    name="data_gatherer",
    sub_agents=[weather_fetcher, news_fetcher]
)

并行编排需要注意的设计问题：子任务的结果如何合并？如果一个子任务失败，如何处理？是等待所有子任务完成还是采用"先到先用"策略？这些决策需要根据具体应用场景做出。

21.7 层级委派模式

层级委派通过父子关系实现任务的动态分配。协调者智能体根据任务特征选择合适的子智能体。

from google.adk.agents import LlmAgent

greeter = LlmAgent(
    name="Greeter",
    model="gemini-2.0-flash-exp",
    instruction="You are a friendly greeter."
)

task_doer = TaskExecutor()  # 自定义的非LLM智能体

coordinator = LlmAgent(
    name="Coordinator",
    model="gemini-2.0-flash-exp",
    instruction="When asked to greet, delegate to the Greeter. "
                "When asked to perform a task, delegate to the TaskExecutor.",
    sub_agents=[greeter, task_doer]
)

层级委派的核心设计决策是委派策略：协调者如何决定将任务分配给哪个子智能体？在上面的例子中，委派策略编码在协调者的指令中。更复杂的系统可能使用基于智能体能力描述的自动路由。

21.8 循环迭代模式

某些任务需要反复执行直到满足特定条件。Google ADK的LoopAgent支持这种"执行-检查-继续/停止"的迭代模式。

from google.adk.agents import LoopAgent

process_step = LlmAgent(
    name="ProcessingStep",
    model="gemini-2.0-flash-exp",
    instruction="Perform your task. If final step, set 'status' to 'completed'."
)

poller = LoopAgent(
    name="StatusPoller",
    max_iterations=10,
    sub_agents=[process_step, ConditionChecker()]
)

循环模式的设计关键在于终止条件——必须有明确的机制防止无限循环。max_iterations是硬性上限，而ConditionChecker提供了基于状态的智能终止。

21.9 智能体作为工具模式

一个更灵活的模式是将智能体本身包装为工具，供其他智能体调用。这在Google ADK中通过AgentTool实现。

from google.adk.agents import LlmAgent
from google.adk.tools import agent_tool

# 子智能体：图像生成专家
image_generator_agent = LlmAgent(
    name="ImageGen",
    model="gemini-2.0-flash",
    description="Generates an image based on a detailed text prompt.",
    instruction="Use the generate_image tool to create the image.",
    tools=[generate_image]
)

# 包装为工具
image_tool = agent_tool.AgentTool(
    agent=image_generator_agent,
    description="Use this tool to generate an image."
)

# 父智能体：使用子智能体作为工具
artist_agent = LlmAgent(
    name="Artist",
    model="gemini-2.0-flash",
    instruction="Invent a creative prompt, then use the ImageGen tool.",
    tools=[image_tool]
)

这种模式的优势在于组合性：任何智能体都可以被包装为工具，供更高层的智能体使用。这创建了一种递归的、可组合的架构，允许构建任意深度的智能体层次。

21.10 多框架协作实践

在多智能体协作的实证研究中，MetaGPT [Hong et al., 2023] 通过标准化操作程序（SOPs）将角色分工编码为工作流，在软件开发任务上相比 ChatDev 降低了 100% 的代码幻觉率；AutoGen [Wu et al., 2023] 的多智能体对话框架在数学推理（MATH 数据集）上通过 Agent 间的迭代讨论将准确率从单 Agent 的 68% 提升至 75%；CAMEL [Li et al., 2023] 的角色扮演框架则证明了即使没有人类干预，两个 Agent 通过 inception prompting 也能在 75% 以上的任务中达成有效协作。

CrewAI提供了另一种编排多智能体协作的范式——基于角色的团队协作。

from crewai import Agent, Task, Crew, Process

researcher = Agent(
    role='Senior Research Analyst',
    goal='Find and summarize the latest trends in AI.',
    backstory="Experienced research analyst with a knack for identifying trends.",
    allow_delegation=False,
)

writer = Agent(
    role='Technical Content Writer',
    goal='Write a clear and engaging blog post based on research findings.',
    backstory="Skilled writer who translates complex topics into accessible content.",
    allow_delegation=False,
)

research_task = Task(
    description="Research the top 3 emerging trends in AI.",
    expected_output="Detailed summary of top 3 AI trends.",
    agent=researcher,
)

writing_task = Task(
    description="Write a 500-word blog post based on the research findings.",
    expected_output="Complete 500-word blog post.",
    agent=writer,
    context=[research_task],  # 依赖研究任务的输出
)

crew = Crew(
    agents=[researcher, writer],
    tasks=[research_task, writing_task],
    process=Process.sequential,
)

CrewAI的设计理念是将多智能体系统类比为人类团队：每个Agent有角色（role）、目标（goal）和背景故事（backstory），Task定义了具体的工作内容和期望输出，Crew组装了团队并定义了工作流程（顺序或并行）。context参数显式声明任务间的依赖关系。

前沿动态 —— 最新进展

21.11 编排策略的演进

多智能体编排正在从"静态预定义"走向"动态自适应"。传统方法中，智能体之间的协作流程是开发者预先设计的。新兴的方法允许协调者智能体根据任务特征动态决定使用哪种协作模式——是顺序执行、并行处理还是层级委派。

LangGraph的图结构就是这一趋势的体现：将每步操作定义为图中的节点，用边定义跳转逻辑，天然支持循环和条件分支。这种"以图建模工作流"的方式比传统的链式结构更灵活，使实现如Reflection这样的迭代修正工作流变得直观。

21.12 通信效率的优化

随着智能体数量的增长，通信效率成为系统瓶颈。当前的研究方向包括：

选择性通信：智能体不必与所有其他智能体通信，而是只与任务相关的智能体交换信息。

压缩通信：智能体之间传递摘要而非完整上下文，减少通信开销。

异步解耦：使用消息队列将智能体间的通信解耦，提高系统的并发处理能力。

隐式通信（Implicit Communication）：一种更激进的优化方向。传统的多智能体通信是显式的——通过自然语言或结构化数据（如 MetaGPT 中的 UML/JSON 格式约束输出）在智能体间传递信息。隐式通信则绕过文本解码过程，直接在模型的隐藏层向量空间中交换信息。例如 LatentMAS 通过传输隐藏层向量（latent thoughts）进行多智能体协同，避免了文本序列化/反序列化的信息损失和 Token 开销。这种方式在通信带宽和语义保真度上优于文本通信，但要求参与协作的模型共享兼容的表示空间，目前仍处于研究阶段。

⚠️ 已知局限：多智能体系统在实践中面临三个结构性挑战。第一是协调开销递增——随着智能体数量增加，通信和同步成本呈超线性增长（网络拓扑为 O(n^2)），5 个以上智能体的系统中协调开销可能超过实际任务计算量。第二是角色退化与搭便车——在缺乏有效激励机制的系统中，部分智能体会逐渐偏离其指定角色，产生重复或低质量输出，CAMEL 框架的实验显示约 30% 的对话轮次存在角色一致性漂移。第三是级联失败放大——监督者拓扑中，协调者智能体的单次误判（如错误的任务分配或结果综合）会被传播到所有下游智能体，且当前缺乏有效的分布式错误回溯机制。

本章小结

多智能体协作架构的核心设计决策集中在三个层面：

拓扑选择决定了智能体间的组织关系——网络（去中心化）、监督者（集中式）、层级化（分层式）还是自定义混合。选择依据是任务可分解性、智能体数量、故障容忍需求和通信开销的权衡。

协作模式决定了智能体间的工作方式——顺序交接、并行处理、辩论共识、层级委派还是批评审查。选择依据是任务的阶段特征和子任务间的依赖关系。

编排策略决定了工作流的执行方式——静态预定义还是动态自适应、同步还是异步、框架原生还是跨框架协议。选择依据是系统的灵活性需求和工程复杂度的承受能力。

多智能体系统的价值不在于"多"本身，而在于通过合理的架构设计让多个专业化智能体形成协同效应——collective performance超越any single agent。这要求在任务分解粒度、角色专业化程度和通信开销之间找到恰当的平衡点。