【AI 手把手教學】Google Agent Development Kit（ADK）多代理架構完整指南：以 Travel Concierge 旅遊服務業為例（上）

ADK 多代理架構是什麼？

ADK 的運作方式

ADK 是一套專為開發 AI 代理應用而設計的強大框架，讓開發者能夠構建複雜、可協作的智能代理系統。其核心的技術特點在於：

• 將複雜問題分解為可由專職代理處理的子任務
• 透過狀態共享和控制轉移實現代理間的無縫協作
• 利用回調機制（callbacks）靈活擴展代理功能
• 使用標準化的工具介面與外部系統互動

ADK 的四大優勢

採用 ADK 多代理架構帶來諸多優勢：

• 專業分工：每個 AI 代理專注於特定任務
• 流程靈活性：根據用戶需求和旅程階段，動態切換及控制代理
• 可擴展性：新功能可以透過添加新代理或擴展現有代理實現
• 狀態管理：所有代理共享統一的狀態，確保資訊一致性

Google Cloud 也在 Vertex AI 上的 Agent Garden（如下圖）中提供 ADK 的相關範例。接下來的文章內容，我們以常見的 Travel Concierge 案例來做 ADK 的說明範例。

ADK 應用解析：Travel Concierge 旅遊服務業

以旅遊服務產業為例，介紹 Google ADK 的多代理架構，探討如何透過 Agent 間的協作和職責劃分，如何使用 ADK 打造專屬的多代理服務，構建一個完整的智能服務系統。

Travel Concierge 多代理架構 [1] 是一個智能旅遊服務系統，能全方位滿足旅行者在規劃、預訂和旅途中的各種需求。這套系統透過多個專職代理的協作，模擬私人旅遊顧問的角色，提供從旅程構思到行程規劃，從機票與飯店預訂到目的地導覽的全程服務。

Travel Concierge 多代理架構的功能主要包括：

1. 旅遊前建議：提供目的地建議和活動推薦
2. 行程規劃：搜索航班、飯店預訂和景點規劃
3. 預訂支付：處理預訂流程和支付手續費
4. 旅遊前準備：提供簽證資訊、醫療要求、旅遊警告和天氣狀況
5. 旅途中支援：監控預訂變更、提供目的地資訊和交通協助
6. 旅遊後服務：收集反饋並識別用戶偏好

Agent 與 Sub-agents 的核心概念

在 ADK 中，代理（Agent）是具有特定功能和指令集的 AI 執行單元。Travel Concierge 展示如何透過 Agent 類構建代理間的階層關係：

Root Agent 作為系統的入口點，具有以下關鍵參數：

• model：指定使用的基礎模型
• name：代理的唯一標識符
• description：代理功能描述，用於幫助路由決策
• instruction：代理行為的詳細指令
• sub_agents：子代理列表，構成代理的階層結構
• before_agent_callback：在代理執行前調用的回調函數

這種樹狀結構使得複雜問題可以分解為可管理的小任務，而每個任務由專門的子代理處理。

Root Agent 的控制轉移機制

Root Agent 的指令明確定義控制轉移的規則：

此外，Root Agent 還能根據行程時間判斷旅行階段：

這種設計允許系統根據用戶需求和旅行階段動態切換處理單元，實現靈活的對話流程。

專職 Sub-agents 與職責劃分

Travel Concierge 的代理架構展示「分而治之」的設計原則：

每個子代理各有明確職責：

• inspiration_agent：提供目的地靈感和活動建議
• planning_agent：處理航班搜索、座位選擇、酒店搜索和房間選擇
• booking_agent：處理預訂支付流程
• pre_trip_agent：提供旅遊前資訊，如簽證、醫療要求等
• in_trip_agent：提供旅途中的支援
• post_trip_agent：收集反饋和用戶偏好

以 planning_agent 為例，它也有自己的子代理：

這裡的 AgentTool 將子代理包裝為工具，讓 planning_agent 可以在需要時調用這些專門的子代理。

最下層代理的職責限制與輸出控制

以 flight_search_agent 為例，它專注於完成單一任務 — 生成航班搜索結果，並透過 prompt 和輸出格式限制確保其職責明確：

flight_search_agent 透過以下機制限制其職責範圍和輸出形式：

1. 明確的輸出格式：FLIGHT_SEARCH_INSTR 中定義了詳細的 JSON 回應結構

2. 控制轉移限制：使用disallow_transfer_to_parent=True 和 disallow_transfer_to_peers=True 防止代理將控制權轉移給其他代理

3. 模型配置：使用 types.json_response_config 優化生成參數，以產生符合預期格式的 JSON 回應

4. 結構化輸出：透過 output_schema=types.FlightsSelection 強制輸出符合預定義的格式

5. 命名輸出存取：透過 output_key="flight" 將輸出結果存儲在特定的鍵下，便於上層代理使用

這些限制確保 flight_search_agent 能夠專注於其核心任務，而不會嘗試處理超出其職責範圍的請求。

使用 Pydantic 定義輸出結構

Pydantic 在 ADK 中的應用

在結構化輸出那邊提到 output_schema=types.FlightsSelection，這也是使用者可以自己定義的實作。在 ADK 中，輸出結構通常使用 Pydantic 的 BaseModel 和 Field 來定義。Pydantic 是一個強大的資料驗證和序列化庫，它透過 Python 的類型提示，確保資料符合預期格式。在 Travel Concierge 範例中，types.py 文件定義各種結構化輸出模型，用於確保代理生成的資料符合預期格式。

BaseModel 和 Field 的基礎用法

Pydantic 的核心是 BaseModel 類，它是所有模型的基礎。透過繼承 BaseModel，我們可以創建能自動驗證資料的類別：

在這個例子中：

• id 是必填的整數欄位
• name 有預設值 "John Doe"
• email 是必填欄位（使用 ... 表示），且必須符合特定的正則表達式格式
• age 是可選欄位，但如果提供，必須是介於 0 到 120 之間的整數

Flight 和 FlightsSelection 模型範例

在 Travel Concierge 的 types.py 中，Flight 和 FlightsSelection 類是 Pydantic 模型的絕佳範例。這些類別定義結構化的航班資訊，確保 flight_search_agent 生成的資料符合預期格式：

這個定義展示 Pydantic 的幾個核心特性：

1. 嵌套模型：Flight 包含 FlightLocation 類型的欄位，使得可以建立複雜的資料結構層次
2. 類型驗證：每個欄位都有特定類型，如 str、float、int、datetime 等
3. 約束條件：使用 Field 參數如 gt=0（大於 0）和 ge=0（大於等於 0）來設定驗證規則
4. 詳細描述：每個欄位都帶有 description 參數，提供明確的文檔說明
5. 可選欄位：使用 Optional 和 default=None 指定非必填欄位

這種結構化定義的優勢包括：

• 自動驗證：確保生成的資料符合預期的格式和約束
• 明確的格式要求：為 LLM 模型提供清晰的輸出準則
• 型別安全：在編譯時就能發現潛在的類型錯誤
• 文檔化：Field 描述提供了自文檔化的代碼
• JSON Schema 生成：可自動生成 JSON Schema 用於文檔或 API 定義

在 ADK 中的整合應用

在 ADK 的架構中，透過 output_schema=types.FlightsSelection 參數，flight_search_agent 被指示生成符合 FlightsSelection 模型的輸出。這確保了：

1. 代理生成的 JSON 必須符合預定義的模型結構
2. 輸出將被自動驗證，確保所有必填欄位存在且符合類型要求
3. 上層代理（如 planning_agent）可以安全地使用這些結構化資料

當 flight_search_agent 生成輸出時，ADK 會將結果存儲在 flight 鍵下（透過 output_key="flight"），使得 planning_agent 可以輕鬆訪問這些資料：

這種整合實現了代理間高效的資料交換，同時確保資料的完整性和一致性。

子代理的 Prompt 設計與流程控制

Planning Agent 的 prompt 設計展示如何透過詳細的指令控制代理行為以及處理的流程：

針對不同的用戶旅程，提供特定的處理指引，例如 FULL_ITINERARY 部分：

這種設計使得子代理能夠：

• 識別用戶意圖和需求
• 執行特定的處理流程
• 處理必要的上下文資訊
• 協調子任務執行順序
• 生成符合預期的回應

六大技術核心打造高效 AI 代理協作

Travel Concierge 的多代理架構展示 Google ADK 如何支持複雜的代理協作系統。上集主要介紹以下核心概念：

1. 分層代理結構：Root Agent 作為系統入口，調配各個專職子代理處理特定任務
2. 控制轉移機制：根據用戶需求和旅行階段，動態轉移控制權到合適的代理
3. 職責明確劃分：每個代理都有明確定義的職責範圍，從而實現高效協作
4. 輸出控制技術：通過參數和 prompt 設計限制代理的輸出格式和行為範圍
5. Pydantic 結構化輸出：透過 BaseModel 和 Field 定義清晰的資料模型，確保代理輸出的一致性和可靠性
6. 流程設計模式：通過精心設計的 prompt 指引代理處理特定類型的用戶需求

此設計方法不僅提高系統的模組化程度和可維護性，還實現了子代理的專業化和效能最大化。在下集中，我們將深入探討 Travel Concierge 的記憶系統實現，包括如何透過 ToolContext 和 CallbackContext 自定義工具，實現更複雜的功能。

參考資料

[1]: https://github.com/google/adk-samples/tree/main/python/agents/travel-concierge