第九篇：驾驭复杂AI——Google ADK如何赋能多代理系统设计与实践

随着人工智能（AI）应用的复杂性日益增加，单一代理（Agent）往往难以胜任。多代理系统（Multi-Agent Systems, MAS）通过将复杂问题分解，并由多个具有特定技能的代理协同工作来解决，展现出巨大的潜力。Google 的 Agent Development Kit (ADK) 为构建和管理此类复杂的多代理系统提供了强大的开源框架。本文作为 Google Agent Development Kit 系列的第九篇，将深入探讨多代理系统的设计原则，涵盖协作架构、通信机制、任务分配、子任务委派与结果整合，并通过一个团队协作型项目管理代理的实例，展示如何使用 ADK 构建实际的多代理应用。

1. 多代理协作架构设计

构建高效的多代理系统，首先需要精心设计其协作架构。不同的架构模式适用于不同的应用场景，ADK 提供了灵活的构建模块以支持这些模式。

1.1. 常见多代理架构模式

在多代理系统领域，已沉淀出多种成熟的协作架构模式，理解这些模式及其适用场景对于设计高效的 MAS至关重要：

• 层级式/协调器-工作者模式 (Hierarchical/Coordinator-Worker Pattern): 在此模式中，代理被组织成层级结构，上层代理（协调器）负责任务分解、分配，并监督下层代理（工作者）的执行。这种模式清晰了指挥链，易于管理复杂任务，但也可能在协调器处形成瓶颈。ADK 通过其父子代理层级结构和 LlmAgent 作为协调者的能力，天然支持此模式。

• 顺序管道模式 (Sequential Pipeline Pattern): 任务按预定顺序流经一系列专业代理，每个代理完成特定阶段的处理，并将结果传递给下一个代理。此模式适用于具有明确线性流程的任务。ADK 的 SequentialAgent 是实现此模式的直接工具。

• 并行扇出/聚合模式 (Parallel Fan-Out/Gather Pattern): 一个任务被分解成多个可以并行处理的子任务，分配给不同的代理同时执行，最后将各个子任务的结果汇聚整合。这能显著提高处理效率。ADK 的 ParallelAgent 专为此类场景设计。

• 黑板模式 (Blackboard Pattern): 代理们围绕一个共享的知识库（黑板）进行协作。代理可以向黑板读取信息、发布中间结果或解决方案，实现异步松耦合通信。此模式适用于需要增量式、多方贡献解决的复杂问题。虽然 ADK 没有直接名为“黑板”的组件，但可以通过共享状态管理（如外部数据库结合自定义代理逻辑）或利用消息队列等方式实现类似机制。

• 评审/批评模式（生成 - 评论者）(Review/Critique Pattern 或 Generator-Critic): 通常包含一个生成器代理和一个批判者代理。生成器负责产出解决方案或内容，批判者则对其进行评估、提供反馈，生成器再根据反馈进行修正。这种迭代改进的模式有助于提升产出质量。

• 迭代改进模式 (Iterative Refinement Pattern): 代理或代理组通过多次迭代来逐步完善解决方案。每次迭代都可能涉及新的信息获取、处理或与其他代理的协商。

• 人机协作模式 (Human-in-the-Loop Pattern): 在关键决策点或代理能力不足时，引入人类用户进行干预、确认或提供输入。ADK 支持与用户的交互，包括通过其流式音视频能力实现更自然的对话，这为实现人在回路提供了基础。

选择合适的架构模式，或组合多种模式，取决于具体应用的需求，如任务的可分解性、代理间的依赖关系、对实时性的要求以及系统的可扩展性等。

1.2. ADK 中的架构支持

ADK 通过其核心原语为构建上述及其他自定义的多代理协作架构提供了坚实的基础。

• BaseAgent 层级结构: ADK 中所有代理都派生自 BaseAgent。通过在初始化父代理时传递一个代理实例列表给 sub_agents 参数，可以构建代理的树状层级结构。ADK 会自动在子代理上设置 parent_agent 属性。这种层级结构是 WorkflowAgent 作用范围的基础，并影响 LlmAgent 的委派目标。一个代理实例只能拥有一个父代理，确保了层级关系的清晰。

• WorkflowAgent: ADK 提供了一组专门的 WorkflowAgent（如 SequentialAgent, ParallelAgent, LoopAgent）来管理其子代理的执行流程。

• SequentialAgent: 按照定义的顺序依次执行其子代理。前一个子代理的输出可以通过状态共享，作为后一个子代理的输入。

• ParallelAgent: 并行执行其所有子代理，并在所有子代理完成后汇聚结果。

• LoopAgent: 根据特定条件或次数重复执行其子代理。 这些工作流代理使得开发者可以定义结构化的、可预测的控制流。

• LlmAgent 作为动态协调器: LlmAgent 由大型语言模型驱动，能够基于自然语言指令和上下文进行推理和规划。它可以动态地决定调用哪个工具（包括其他代理封装成的工具）或将任务委派给哪个子代理。这使得 LlmAgent 非常适合作为多代理系统中的协调器或调度器，实现更灵活和自适应的协作行为。

• 模块化与可重用性: 将复杂应用分解为多个小型、专业的代理，增强了系统的模块化程度。每个代理可以专注于特定功能，易于独立开发、测试和维护。这些专业代理也更容易在不同的多代理系统中被复用。

ADK 的这些设计使得开发者能够像搭积木一样构建复杂的多代理系统，同时保持对代理行为的精确控制。

2. 代理间通信与任务分配

代理间的有效通信和合理的任务分配是多代理系统成功的关键。ADK 提供了多种机制来支持代理间的交互。

2.1. ADK 内部通信机制

在 ADK 构建的单个多代理系统内部，代理间的通信主要依赖于层级结构和共享上下文。

• 状态管理与上下文共享: ADK 中的代理在执行过程中可以访问和修改会话状态（Session State）。在层级结构中，父代理和子代理可以共享部分上下文信息。例如，WorkflowAgent 会管理其子代理的执行上下文。当一个 LlmAgent 调用一个封装为 AgentTool 的子代理时，子代理的最终响应以及状态或工件（artifact）的变更会被传递回父代理的上下文中。

• output_key: 在 SequentialAgent 中，子代理可以通过指定 output_key 参数，将其执行结果保存到会话状态的特定键下。后续的子代理则可以从该键读取数据作为输入，实现数据的有序传递 。

• LLM 驱动的委派 (LLM-Driven Delegation) 与 AgentTool: 这是 ADK 中一种重要的内部通信和任务委派方式。可以将一个 BaseAgent 实例（包括 LlmAgent 或 CustomAgent）包装成一个 AgentTool，并将其添加到另一个父 LlmAgent 的工具列表中。父 LlmAgent 在接收到用户请求或需要执行特定子任务时，其内部的 LLM 可以决定调用这个 AgentTool。框架会执行该工具（即运行目标代理），捕获其最终响应，并将任何状态或工件的更改转发回父代理的上下文，然后将响应作为工具调用的结果返回给父 LLM。这种调用本质上是同步的（在父代理的流程内），显式的，并且像调用任何其他工具一样受到控制。

2.2. 跨框架/系统通信：Agent2Agent (A2A) 协议

当需要让不同框架构建的代理，甚至不同供应商提供的代理系统进行协作时，就需要一个标准的通信协议。Google 联合业界伙伴推出的 Agent2Agent (A2A) 协议旨在解决这一挑战。

• A2A 协议的目标: A2A 是一个开放标准，旨在促进独立、可能不透明的 AI 代理系统之间的通信和互操作性。它使得代理能够：

• 发现彼此的能力。

• 协商交互模式（文本、文件、结构化数据，甚至双向音视频）。

• 管理协作任务。

• 安全地交换信息以实现用户目标，而无需访问彼此的内部状态、内存或工具。