构建协作智能体团队¶
某些复杂的任务可能需要多个职责明确的智能体协同工作。对于包含多个实质性子任务的迭代过程，协作智能体团队能够从这种结构化且灵活的过程中受益。在 ADK 的协作架构中，一个协调者智能体 (Coordinator Agent) 负责将具体任务委派给一个或多个子智能体 (Sub-agents)。这种方法降低了构建自我管理式复杂系统的门槛：子智能体被定义为处理特定专项任务，并在任务完成后自动将控制权交回给父级。
为了管理子智能体的行为并限制其工作范围，你可以为它们分配特定的运行模式 (Modes)。这些模式为子智能体设定了通用的行为准则，从而打造出更可预测、更可靠的多智能体工作流。ADK 提供了以下协作模式：
- 聊天 (Chat)：完整的用户交互模式，需要手动将控制权返回给父智能体（这是默认行为）。
- 任务 (Task)：仅在需要澄清或补充信息时与用户交互，任务完成后自动返回父智能体。
- 单次对话 (Single-turn)：禁止用户交互，自动返回结果，且支持任务并行运行。
本指南将向你介绍如何为子智能体配置这些模式，以及这些模式如何影响系统的整体行为。
Alpha 发布版说明
ADK 2.0 目前处于 Alpha 阶段，与早期版本相比可能存在破坏性变更。如果你对向后兼容性（如生产环境）有严格要求，请谨慎使用。我们非常欢迎你测试该版本并提供你的反馈意见！
快速入门¶
以下示例展示了如何为一个小型智能体团队设置运行模式，并将其分配给一个协调者智能体：
from google.adk.workflow.agents.llm_agent import Agent
# 天气查询智能体：仅执行查询，不与用户交互
weather_agent = Agent(
name="weather_checker",
mode="single_turn", # 单次对话模式：无用户交互
tools=[get_weather, user_info, geocode_address],
)
# 航班预订智能体：处理预订流程，必要时可询问用户
flight_agent = Agent(
name="flight_booker",
mode="task", # 任务模式：允许向用户提问以澄清信息
input_schema=FlightInput,
output_schema=FlightResult,
tools=[search_flights, book_flight],
)
# 根智能体（充当协调者的角色）
root = Agent(
name="travel_planner", # 协调者智能体
sub_agents=[weather_agent, flight_agent],
# 系统将自动注入：request_task_weather_checker, request_task_flight_booker 等工具
)
当你运行此工作流时，travel_planner 协调者智能体将自动识别任务并将其分配给相应的子智能体。子智能体完成其任务后，系统会自动将逻辑链路切回至协调者。
关于如何通过 input_schema 和 output_schema 进行结构化数据处理的更多信息，请参阅智能体工作流中的数据处理。
模式配置与行为比较¶
每种协作模式都有其特定的行为规范和局限性。下表对不同模式下的子智能体属性进行了对比：
注意：模式设置仅对子智能体生效
mode 参数专门用于由协调者（父级）调用的子智能体。请不要在根智能体（入口点）上配置此属性。
| 核心维度 \ 模式 | chat (默认) |
task |
single_turn |
|---|---|---|---|
| 人机协同 (HITL) | 完全交互 | 仅用于澄清事实 | 禁止交互 |
| 用户交互感 | 用户可与该子智能体自由对话 | 智能体仅在有疑问时主动提问 | 对用户透明（静默运行） |
| 控制流逻辑 | 归属于智能体，直至手动释放 | 归属于智能体，直至任务完成 | 任务产出结果后立即返回 |
| 并行执行支持 | 不支持 | 不支持 | 支持（多个任务并发运行） |
| 返回父级机制 | 需要调用 transfer 手动交回 |
自动交回 (通过 complete_task) |
自动交回 (携带执行结果) |
表 1. ADK 协作模式行为与限制对比表。
运行考量¶
在使用协作模式时，你需要特别关注控制权转移和上下文隔离的管理。
工作流节点与智能体转移¶
配置为 任务 (Task) 或 单次对话 (Single-turn) 模式的智能体不仅可以作为独立的 LlmAgent 实例使用，还可以充当工作流图中的节点。其具体的控制权流转行为取决于调用方：
- 作为图节点 (Graph Node)：当任务智能体被放置在工作流图中（如在
SequentialAgent或ParallelAgent中）时，它会执行分配的任务。完成后，控制权会按照图定义的逻辑自动流转至下一个节点。 - 作为 LlmAgent 的转移目标：当父级
LlmAgent通过request_task将控制权交给任务智能体时，该智能体会持续运行直至调用complete_task。由于 ADK 的自动化机制，完成后控制权会自动重定向回发起任务的原始父级智能体。这显著优于默认的chat模式，后者需要显式的transfer_to_agent调用才能实现逻辑闭环。
| 调用上下文环境 | 任务完成后的行为 |
|---|---|
| 作为工作流图节点 | 自动推进到图中的邻接节点 |
| 由 LlmAgent 转移调用 | 自动将控制权交还给发起方 |
这种设计允许你在不修改任何代码的情况下，在不同场景中复用同一个任务智能体，运行时会自动识别调用上下文并匹配最优的控制流。
智能体上下文隔离¶
在 任务 (Task) 或 单次对话 (Single-turn) 模式下工作的智能体均在独立的会话分支 (Session Branch) 中运行。这意味着在任务并发期间，各个智能体只能访问其自身分支内的事件流，无法“感知”到对等智能体的实时动作。这种隔离机制确保了任务的独立性与安全性。一旦所有分支执行完毕，父级协调者将收到汇总后的多路执行结果，并据此决定后续的全局动作。
已知局限性¶
目前协作模式存在以下已知限制：
- 层级限制：处于 任务 (Task) 模式的智能体必须作为末梢智能体 (Leaf Agent)，暂不支持配置下属的子智能体。