第7章：Multi-Agent Collaboration

虽然单体 Agent 架构能够有效应对定义明确的问题，但当面对复杂的多领域任务时，其能力往往会受到限制。Multi-Agent Collaboration 模式通过将系统构建为由不同专用 Agent 组成的协作整体来应对这些局限性。这种方法建立在任务分解的原则之上，即将一个高层级目标拆分为多个离散的子问题。每个子问题随后被分配给一个 Agent，该 Agent 拥有最适合该任务的特定工具、数据访问权限或推理能力。

例如，一个复杂的研究查询可能会被分解并分配给一个 Research Agent 用于信息检索、一个 Data Analysis Agent 用于统计处理，以及一个 Synthesis Agent 用于生成最终报告。这样一个系统的功效不仅源于劳动分工，更关键地取决于 Agent 间通信的机制。这需要标准化的通信协议和共享的本体论，使 Agent 能够交换数据、委派子任务并协调行动，以确保最终输出具有连贯性。

这种分布式架构具有若干优势，包括增强的模块化、可扩展性和鲁棒性，因为单个 Agent 的失败不一定会导致整个系统的故障。协作能够产生协同效应，即 Multi-Agent 系统的整体性能超越了系统中任何单个 Agent 的潜在能力。

Multi-Agent Collaboration 模式概述

Multi-Agent Collaboration 模式涉及设计多个独立或半独立的 Agent 协同工作以实现共同目标的系统。每个 Agent 通常具有定义明确的角色、与总体目标一致的特定子目标，并可能访问不同的工具或知识库。这一模式的力量在于这些 Agent 之间的交互和协同。

协作可以采取多种形式：

顺序交接（Sequential Handoffs）：一个 Agent 完成任务后，将其输出传递给另一个 Agent 继续执行流水线中的下一步（类似于 Planning 模式，但明确涉及不同的 Agent）。
并行处理（Parallel Processing）：多个 Agent 同时处理问题的不同部分，然后将结果合并。
辩论与共识（Debate and Consensus）：具有不同视角和信息来源的 Agent 参与讨论以评估选项，最终达成共识或更具信息量的决策。
层级结构（Hierarchical Structures）：一个管理者 Agent 可能会根据下属 Agent 的工具访问权限或插件能力动态委派任务，并综合它们的结果。每个 Agent 还可以处理相关的工具组，而不是由单个 Agent 处理所有工具。
专家团队（Expert Teams）：具有不同领域专长的 Agent（例如研究员、撰稿人、编辑）协作产出复杂的输出。
Critic-Reviewer：一些 Agent 创建初始输出（如计划、草稿或答案），另一组 Agent 随后根据对政策、安全、合规性、正确性、质量以及与组织目标一致性的标准，对这些输出进行严格评估。原始创建者或一个最终 Agent 根据此反馈修订输出。这种模式在代码生成、研究写作、逻辑检查和确保伦理一致性方面特别有效。这种方法的优势包括提高鲁棒性、提升质量，以及降低幻觉或错误的可能性。

Multi-Agent 系统（见图 1）的基本组成包括 Agent 角色和职责的界定、建立 Agent 之间信息交换的通信渠道，以及制定指导其协作努力的任务流或交互协议。

图1：Multi-Agent 系统示例

诸如 Crew AI 和 Google ADK 之类的框架正是为促进这一范式而设计的，它们提供了用于规范 Agent、任务及其交互程序的结构。这种方法对需要多种专业知识、涵盖多个离散阶段或利用并发处理和信息交叉验证优势的挑战尤为有效。

实际应用与用例

Multi-Agent Collaboration 是一种可在众多领域中应用的强大模式：

复杂研究与分析：一个 Agent 团队可以就一个研究项目进行协作。一个 Agent 可能专门搜索学术数据库，另一个专门总结发现，第三个负责识别趋势，第四个负责将信息综合成报告。这类似于人类研究团队的运作方式。
软件开发：设想 Agent 协作构建软件。一个 Agent 可以是需求分析师，另一个是代码生成器，第三个是测试人员，第四个是文档撰写者。它们可以在彼此之间传递输出，以构建和验证组件。
创意内容生成：创建一个营销活动可能涉及市场研究 Agent、文案 Agent、图形设计 Agent（使用图像生成工具）以及社交媒体排期 Agent，它们共同协作。
金融分析：Multi-Agent 系统可以分析金融市场。Agent 可能专门负责获取股票数据、分析新闻情绪、执行技术分析以及生成投资建议。
客户支持升级：一线支持 Agent 可以处理初始查询，将复杂问题升级给专家 Agent（例如技术专家或账单专员），这展示了基于问题复杂度的顺序交接。
供应链优化：Agent 可以代表供应链中的不同节点（供应商、制造商、分销商），并协作优化库存水平、物流和排程，以应对需求变化或中断。
网络分析与修复：自治操作极大地受益于 Agent 架构，尤其是在故障定位方面。多个 Agent 可以协作进行故障排除和修复，提出最优行动建议。这些 Agent 还可以与传统的机器学习模型和工具集成，既利用现有系统，又同时享有生成式 AI 的优势。

描绘专用 Agent 并精细编排它们之间相互关系的能力，使开发者能够构建具有更强模块化、可扩展性的系统，并能够应对对于单个集成 Agent 而言难以克服的复杂性。

Multi-Agent Collaboration：探索相互关系与通信结构

理解 Agent 交互和通信的复杂方式是设计有效的 Multi-Agent 系统的基础。如图 2 所示，存在着一系列相互关系和通信模型，从最简单的单 Agent 场景到复杂的、自定义设计的协作框架。每种模型都有其独特的优势和挑战，影响着 Multi-Agent 系统的整体效率、鲁棒性和适应性。

单 Agent（Single Agent）：在最基本层面上，"Single Agent" 自主运行，不与其他实体直接交互或通信。虽然这种模型易于实现和管理，但其能力固有地受限于单个 Agent 的范围和资源。它适用于可分解为独立子问题的任务，每个子问题可由单个自给自足的 Agent 解决。
网络（Network）："Network" 模型代表了向协作迈出的重要一步，其中多个 Agent 以去中心化的方式彼此直接交互。通信通常以点对点方式进行，允许共享信息、资源甚至任务。这种模型促进了韧性，因为一个 Agent 的失败不一定会瘫痪整个系统。然而，在大型非结构化网络中管理通信开销并确保一致的决策可能具有挑战性。
监督者（Supervisor）：在"Supervisor"模型中，一个专门的 Agent——"supervisor"——监督并协调一组下属 Agent 的活动。Supervisor 充当通信、任务分配和冲突解决的中心枢纽。这种层级结构提供了清晰的权力线，并能简化管理和控制。然而，它引入了单点故障（supervisor），如果 supervisor 被大量下属的庞大数量或复杂任务压垮，则可能成为瓶颈。
作为工具的 Supervisor（Supervisor as a Tool）：这种模型是"Supervisor"概念的一个微妙扩展，其中 supervisor 的角色较少涉及直接指挥和控制，而更多是向其他 Agent 提供资源、指导或分析支持。Supervisor 可能提供工具、数据或计算服务，使其他 Agent 能够更有效地执行任务，而无需规定其每一个行动。这种方法旨在利用 supervisor 的能力，而不强加严格的顶层控制。
层级（Hierarchical）："Hierarchical"模型在 supervisor 概念的基础上扩展，创建了一个多层的组织结构。这涉及多个级别的 supervisor，较高级别的 supervisor 监督较低级别的 supervisor，最终是最低层的一组操作 Agent。这种结构非常适合那些可以分解为子问题的复杂问题，每个子问题由层级的特定层管理。它为可扩展性和复杂性管理提供了一种结构化的方法，允许在定义边界内进行分布式决策。

图2：Agent 以各种方式进行通信和交互

自定义（Custom）："Custom"模型代表了 Multi-Agent 系统设计的终极灵活性。它允许创建独特的相互关系和通信结构，精确地针对特定问题或应用的需求量身定制。这可以涉及混合方法，结合前述模型的元素，或者根据环境的独特约束和机会而出现的全新设计。自定义模型通常源于优化特定性能指标、处理高度动态环境、或将特定领域知识融入系统架构的需求。设计和实现自定义模型通常需要对 Multi-Agent 系统原理有深入理解，并仔细考虑通信协议、协调机制和涌现行为。

总之，为 Multi-Agent 系统选择相互关系和通信模型是一个关键的设计决策。每种模型都有其独特的优势和劣势，最优选择取决于任务复杂性、Agent 数量、期望的自主程度、鲁棒性需求以及可接受的通信开销等因素。Multi-Agent 系统的未来进展可能会继续探索和完善这些模型，并发展协作智能的新范式。

Hands-On Code（Crew AI）

以下 Python 代码使用 CrewAI 框架定义了一个 AI 驱动的 crew，用于生成关于 AI 趋势的博客文章。它首先设置环境，从 .env 文件中加载 API 密钥。应用的核心涉及定义两个 Agent：一个 researcher 负责寻找和总结 AI 趋势，一个 writer 负责基于研究撰写博客文章。

相应地定义了两个 Task：一个用于研究趋势，另一个用于撰写博客文章，其中写作任务依赖于研究任务的输出。这些 Agent 和 Task 随后被组装成一个 Crew，指定一个顺序流程，即任务按顺序执行。Crew 使用 Agent、Task 和一个语言模型（具体为 "gemini-2.0-flash" 模型）初始化。主函数使用 kickoff() 方法执行此 crew，编排 Agent 之间的协作以生成所需的输出。最后，代码打印 crew 执行的最终结果，即生成的博客文章。

python

import os
from dotenv import load_dotenv
from crewai import Agent, Task, Crew, Process
from langchain_google_genai import ChatGoogleGenerativeAI

def setup_environment():
    """Loads environment variables and checks for the required API
    key."""
    load_dotenv()
    if not os.getenv("GOOGLE_API_KEY"):
        raise ValueError("GOOGLE_API_KEY not found. Please set it in
        your .env file.")

def main():
    """
    Initializes and runs the AI crew for content creation using the
    latest Gemini model.
    """
    setup_environment()
    
    # Define the language model to use.
    # Updated to a model from the Gemini 2.0 series for better
    # performance and features.
    # For cutting-edge (preview) capabilities, you could use
    # "gemini-2.5-flash".
    llm = ChatGoogleGenerativeAI(model="gemini-2.0-flash")

    # Define Agents with specific roles and goals
    researcher = Agent(
        role='Senior Research Analyst',
        goal='Find and summarize the latest trends in AI.',
        backstory="You are an experienced research analyst with a
        knack for identifying key trends and synthesizing information.",
        verbose=True,
        allow_delegation=False,
    )

    writer = Agent(
        role='Technical Content Writer',
        goal='Write a clear and engaging blog post based on research
        findings.',
        backstory="You are a skilled writer who can translate complex
        technical topics into accessible content.",
        verbose=True,
        allow_delegation=False,
    )

    # Define Tasks for the agents
    research_task = Task(
        description="Research the top 3 emerging trends in Artificial
        Intelligence in 2024-2025. Focus on practical applications and
        potential impact.",
        expected_output="A detailed summary of the top 3 AI trends,
        including key points and sources.",
        agent=researcher,
    )

    writing_task = Task(
        description="Write a 500-word blog post based on the research
        findings. The post should be engaging and easy for a general audience
        to understand.",
        expected_output="A complete 500-word blog post about the
        latest AI trends.",
        agent=writer,
        context=[research_task],
    )

    # Create the Crew
    blog_creation_crew = Crew(
        agents=[researcher, writer],
        tasks=[research_task, writing_task],
        process=Process.sequential,
        llm=llm,
        verbose=2  # Set verbosity for detailed crew execution logs
    )

    # Execute the Crew
    print("## Running the blog creation crew with Gemini 2.0 Flash...
    ##")
    try:
        result = blog_creation_crew.kickoff()
        print("\n------------------\n")
        print("## Crew Final Output ##")
        print(result)
    except Exception as e:
        print(f"\nAn unexpected error occurred: {e}")

if __name__ == "__main__":
    main()

现在我们将深入探讨 Google ADK 框架中的更多示例，特别强调层级、并行和顺序协调范式，以及将 Agent 实现为操作工具。

Hands-On Code（Google ADK）

以下代码示例演示了在 Google ADK 中通过创建父子关系建立层级 Agent 结构。该代码定义了两种类型的 Agent：LlmAgent 和一个从 BaseAgent 派生的自定义 TaskExecutor Agent。TaskExecutor 专为特定的非 LLM 任务设计，在此示例中，它简单地产生一个 "Task finished successfully" 事件。一个名为 greeter 的 LlmAgent 使用指定的模型和指令初始化，充当友好的问候者。自定义 TaskExecutor 被实例化为 task_doer。一个名为 coordinator 的父 LlmAgent 也被创建，同样具有模型和指令。coordinator 的指令指导它将问候任务委派给 greeter，将任务执行委派给 task_doer。greeter 和 task_doer 作为子 Agent 添加到 coordinator 中，建立了父子关系。代码随后断言此关系已正确设置。最后，它打印一条消息，表明 Agent 层级已成功创建。

python

from google.adk.agents import LlmAgent, BaseAgent
from google.adk.agents.invocation_context import InvocationContext
from google.adk.events import Event
from typing import AsyncGenerator

# Correctly implement a custom agent by extending BaseAgent
class TaskExecutor(BaseAgent):
    """A specialized agent with custom, non-LLM behavior."""
    name: str = "TaskExecutor"
    description: str = "Executes a predefined task."

    async def _run_async_impl(self, context: InvocationContext) -> AsyncGenerator[Event, None]:
        """Custom implementation logic for the task."""
        # This is where your custom logic would go.
        # For this example, we'll just yield a simple event.
        yield Event(author=self.name, content="Task finished successfully.")

# Define individual agents with proper initialization
# LlmAgent requires a model to be specified.
greeter = LlmAgent(
    name="Greeter",
    model="gemini-2.0-flash-exp",
    instruction="You are a friendly greeter."
)

task_doer = TaskExecutor()  # Instantiate our concrete custom agent

# Create a parent agent and assign its sub-agents
# The parent agent's description and instructions should guide its delegation logic.
coordinator = LlmAgent(
    name="Coordinator",
    model="gemini-2.0-flash-exp",
    description="A coordinator that can greet users and execute tasks.",
    instruction="When asked to greet, delegate to the Greeter. When asked to perform a task, delegate to the TaskExecutor.",
    sub_agents=[
        greeter,
        task_doer
    ]
)

# The ADK framework automatically establishes the parent-child relationships.
# These assertions will pass if checked after initialization.
assert greeter.parent_agent == coordinator
assert task_doer.parent_agent == coordinator

print("Agent hierarchy created successfully.")

以下代码摘录展示了在 Google ADK 框架中使用 LoopAgent 建立迭代工作流程。代码定义了两个 Agent：ConditionChecker 和 ProcessingStep。ConditionChecker 是一个自定义 Agent，检查会话状态中的 "status" 值。如果 "status" 为 "completed"，ConditionChecker 会提升（escalate）一个事件以停止循环；否则，它产生一个事件以继续循环。ProcessingStep 是一个使用 "gemini-2.0-flash-exp" 模型的 LlmAgent，其指令是执行一项任务，如果这是最后一步，则将会话 "status" 设置为 "completed"。创建了一个名为 StatusPoller 的 LoopAgent，配置为 max_iterations=10。StatusPoller 包含 ProcessingStep 和一个 ConditionChecker 实例作为子 Agent。LoopAgent 将按顺序执行子 Agent 最多 10 次迭代，如果 ConditionChecker 发现状态为 "completed" 则停止。

python

import asyncio
from typing import AsyncGenerator
from google.adk.agents import LoopAgent, LlmAgent, BaseAgent
from google.adk.events import Event, EventActions
from google.adk.agents.invocation_context import InvocationContext

# Best Practice: Define custom agents as complete, self-describing classes.
class ConditionChecker(BaseAgent):
    """A custom agent that checks for a 'completed' status in the session state."""
    name: str = "ConditionChecker"
    description: str = "Checks if a process is complete and signals the loop to stop."

    async def _run_async_impl(
        self, context: InvocationContext
    ) -> AsyncGenerator[Event, None]:
        """Checks state and yields an event to either continue or stop the loop."""
        status = context.session.state.get("status", "pending")
        is_done = (status == "completed")
        
        if is_done:
            # Escalate to terminate the loop when the condition is met.
            yield Event(author=self.name,
                       actions=EventActions(escalate=True))
        else:
            # Yield a simple event to continue the loop.
            yield Event(author=self.name, content="Condition not met, continuing loop.")

# Correction: The LlmAgent must have a model and clear instructions.
process_step = LlmAgent(
    name="ProcessingStep",
    model="gemini-2.0-flash-exp",
    instruction="You are a step in a longer process. Perform your task. If you are the final step, update session state by setting 'status' to 'completed'."
)

# The LoopAgent orchestrates the workflow.
poller = LoopAgent(
    name="StatusPoller",
    max_iterations=10,
    sub_agents=[
        process_step,
        ConditionChecker()  # Instantiating the well-defined custom agent.
    ]
)

# This poller will now execute 'process_step'
# and then 'ConditionChecker'
# repeatedly until the status is 'completed' or 10 iterations
# have passed.

以下代码摘录阐明了 Google ADK 中的 SequentialAgent 模式，该模式专为构建线性工作流而设计。该代码使用 google.adk.agents 库定义了一个顺序 Agent 管道。管道由两个 Agent 组成：step1 和 step2。step1 名为 "Step1_Fetch"，其输出将存储在会话状态的 "data" 键下。step2 名为 "Step2_Process"，被指示分析存储在 session.state["data"] 中的信息并提供摘要。名为 "MyPipeline" 的 SequentialAgent 协调这些子 Agent 的执行。当管道以初始输入运行时，step1 首先执行。step1 的响应将以键 "data" 保存到会话状态中。随后，step2 将执行，根据其指令利用 step1 放入状态中的信息。这种结构允许构建一个 Agent 的输出成为下一个 Agent 的输入的工作流。这是创建多步 AI 或数据处理管道中的常见模式。

python

from google.adk.agents import SequentialAgent, Agent

# This agent's output will be saved to session.state["data"]
step1 = Agent(name="Step1_Fetch", output_key="data")

# This agent will use the data from the previous step.
# We instruct it on how to find and use this 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]
)

# When the pipeline is run with an initial input, Step1 will execute,
# its response will be stored in session.state["data"], and then
# Step2 will execute, using the information from the state as instructed.

以下代码示例展示了 Google ADK 中的 ParallelAgent 模式，该模式支持多个 Agent 任务的并发执行。data_gatherer 被设计为同时运行两个子 Agent：weather_fetcher 和 news_fetcher。weather_fetcher Agent 被指示获取给定位置的天气，并将结果存储在 session.state["weather_data"] 中。类似地，news_fetcher Agent 被指示获取给定主题的头条新闻，并将其存储在 session.state["news_data"] 中。每个子 Agent 都配置为使用 "gemini-2.0-flash-exp" 模型。ParallelAgent 协调这些子 Agent 的执行，允许它们并行工作。来自 weather_fetcher 和 news_fetcher 的结果将被收集并存储在会话状态中。最后，示例展示了如何在 Agent 执行完成后从 final_state 访问收集到的天气和新闻数据。

python

from google.adk.agents import Agent, ParallelAgent

# It's better to define the fetching logic as tools for the agents
# For simplicity in this example, we'll embed the logic in the agent's instruction.
# In a real-world scenario, you would use tools.

# Define the individual agents that will run in parallel
weather_fetcher = Agent(
    name="weather_fetcher",
    model="gemini-2.0-flash-exp",
    instruction="Fetch the weather for the given location and return only the weather report.",
    output_key="weather_data"  # The result will be stored in session.state["weather_data"]
)

news_fetcher = Agent(
    name="news_fetcher",
    model="gemini-2.0-flash-exp",
    instruction="Fetch the top news story for the given topic and return only that story.",
    output_key="news_data"  # The result will be stored in session.state["news_data"]
)

# Create the ParallelAgent to orchestrate the sub-agents
data_gatherer = ParallelAgent(
    name="data_gatherer",
    sub_agents=[
        weather_fetcher,
        news_fetcher
    ]
)

提供的代码段体现了 Google ADK 中的 "Agent as a Tool" 范式，使一个 Agent 能够以类似于函数调用的方式利用另一个 Agent 的能力。具体来说，该代码使用 Google 的 LlmAgent 和 AgentTool 类定义了一个图像生成系统。它包含两个 Agent：一个父 artist_agent 和一个子 Agent image_generator_agent。generate_image 函数是一个简单的工具，模拟图像创建，返回模拟图像数据。image_generator_agent 负责根据其接收到的文本提示使用此工具。artist_agent 的角色是首先构思一个创意图像提示，然后通过 AgentTool 包装器调用 image_generator_agent。AgentTool 充当桥梁，允许一个 Agent 将另一个 Agent 用作工具。当 artist_agent 调用 image_tool 时，AgentTool 使用 artist 构思的提示调用 image_generator_agent，后者随后使用该提示调用 generate_image 函数。最后，生成的图像（或模拟数据）通过 Agent 返回。这种架构展示了一个分层 Agent 系统，其中较高级别的 Agent 协调较低级别的专用 Agent 来执行任务。

python

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

# 1. A simple function tool for the core capability.
# This follows the best practice of separating actions from reasoning.
def generate_image(prompt: str) -> dict:
    """
    Generates an image based on a textual prompt.
    Args:
        prompt: A detailed description of the image to generate.
    Returns:
        A dictionary with the status and the generated image bytes.
    """
    print(f"TOOL: Generating image for prompt: '{prompt}'")
    # In a real implementation, this would call an image generation API.
    # For this example, we return mock image data.
    mock_image_bytes = b"mock_image_data_for_a_cat_wearing_a_hat"
    return {
        "status": "success",
        # The tool returns the raw bytes, the agent will handle the Part creation.
        "image_bytes": mock_image_bytes,
        "mime_type": "image/png"
    }

# 2. Refactor the ImageGeneratorAgent into an LlmAgent.
# It now correctly uses the input passed to it.
image_generator_agent = LlmAgent(
    name="ImageGen",
    model="gemini-2.0-flash",
    description="Generates an image based on a detailed text prompt.",
    instruction=(
        "You are an image generation specialist. Your task is to take the user's request "
        "and use the `generate_image` tool to create the image. "
        "The user's entire request should be used as the 'prompt' argument for the tool. "
        "After the tool returns the image bytes, you MUST output the image."
    ),
    tools=[generate_image]
)

# 3. Wrap the corrected agent in an AgentTool.
# The description here is what the parent agent sees.
image_tool = agent_tool.AgentTool(
    agent=image_generator_agent,
    description="Use this tool to generate an image. The input should be a descriptive prompt of the desired image."
)

# 4. The parent agent remains unchanged. Its logic was correct.
artist_agent = LlmAgent(
    name="Artist",
    model="gemini-2.0-flash",
    instruction=(
        "You are a creative artist. First, invent a creative and descriptive prompt for an image. "
        "Then, use the `ImageGen` tool to generate the image using your prompt."
    ),
    tools=[image_tool]
)

At a Glance

What（问题）：复杂问题往往超出单个单体 LLM-based Agent 的能力范围。一个孤立的 Agent 可能缺乏解决多方面任务所有部分所需的多样化专业技能或特定工具的访问权限。这种局限性造成了瓶颈，降低了系统的整体有效性和可扩展性。因此，处理复杂的多领域目标变得低效，并可能导致不完整或次优的结果。

Why（解决方案）：Multi-Agent Collaboration 模式通过创建多个协作 Agent 组成的系统，提供了标准化解决方案。复杂问题被分解为更小、更易管理的子问题，每个子问题随后被分配给具有解决它所需的精确工具和能力的专用 Agent。这些 Agent 通过定义的通信协议和交互模型协同工作，如顺序交接、并行工作流或层级委派。这种 Agent 化的分布式方法创造了协同效应，使团队能够实现任何单个 Agent 都无法达到的结果。

经验法则（Rule of thumb）：当任务对单个 Agent 而言过于复杂，且可以分解为需要专业技能或工具的不同子任务时，使用此模式。它非常适合受益于多样化专业知识、并行处理或多阶段结构化工作流的问题，例如复杂研究与分析、软件开发或创意内容生成。

视觉总结

图3：Multi-Agent 设计模式

Key Takeaways

Multi-Agent Collaboration 涉及多个 Agent 协同工作以实现共同目标。
此模式利用专门角色、分布式任务和 Agent 间通信。
协作可以采用顺序交接、并行处理、辩论或层级结构等形式。
此模式非常适合需要多样化专业知识或多个不同阶段的复杂问题。

结论

本章探讨了 Multi-Agent Collaboration 模式，展示了在系统中编排多个专用 Agent 的好处。我们研究了各种协作模型，强调了该模式在解决跨多个领域的复杂多方面问题中的重要角色。理解 Agent 协作自然会引导我们探究它们与外部环境的交互。

参考文献

Multi-Agent Collaboration Mechanisms: A Survey of LLMs, https://arxiv.org/abs/2501.06322
Multi-Agent System — The Power of Collaboration, https://aravindakumar.medium.com/introducing-multi-agent-frameworks-the-power-of-collaboration-e9db31bba1b6