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

在第一篇 ADK 完整指南的文章中，我們介紹 Travel Concierge 的多代理架構，包括 Root Agent 的控制轉移機制、專職子代理的職責劃分，以及最下層代理的職責限制與輸出控制。這篇文章將著重探討 Travel Concierge 的核心技術特色，並且聚焦於自定義工具的實現和狀態管理系統。

從內建到擴展，掌握 ADK 的內建工具與自定義能力

ADK 內建多項實用工具，可直接應用於各類常見情境。例如透過內建的驗證工具，簡化與外部 API 的串接流程，方便與外部 API 整合：

透過這些內建工具，開發者能更輕鬆處理常見功能，專注於核心業務邏輯的開發。
當 ADK 提供的工具不足以滿足特定需求時，開發者可以透過 google.adk.tools 的 ToolContext 製作符合需求的工具。Travel Concierge 的記憶系統就是自定義工具的一個典型應用。

ToolContext：打造自定義工具的核心

ToolContext 是 ADK 中用於自定義工具的關鍵類別，它賦予工具存取系統狀態的能力。在 Travel Concierge 中，記憶系統正是透過 ToolContext 自行實現狀態的讀寫功能：

在這個例子中，tool_context.state 提供對系統共享狀態的存取能力，使工具能夠：

讀取當前系統狀態
寫入或更新狀態值
回傳操作結果

甚至實現更進階的記憶操作，例如列表型記憶：

以及記憶刪除：

這些操作展示了如何透過 ToolContext 實現靈活的狀態管理，以支援系統的長期記憶需求。

CallbackContext：掌握代理生命週期的核心

Travel Concierge 的 Root Agent 可以自定義一個 _load_precreated_itinerary 回調函數。在每次 agent callback 之前執行，這個 callback 函數必須為 CallbackContext 類別。

CallbackContext 是一個重要的上下文類別，允許開發者在代理生命週期的關鍵節點執行自定義邏輯。以下將詳細說明 _load_precreated_itinerary 回調函數的實作內容：

這個回調函數在 Root Agent 啟動前執行，透過 callback_context.state 初始化系統狀態。進一步觀察 _set_initial_states 函數：

這個函數展示了如何：

設置系統時間
初始化標誌位
更新系統狀態
提取並設置關鍵行程資訊

透過 CallbackContext，開發者可以在代理執行前後插入自定義邏輯，實現更靈活的控制。

透過 ToolContext 與 CallbackContext 實現 AI 代理的狀態共享機制

在 Travel Concierge 中，狀態共享是實現代理協作的關鍵機制。狀態的讀寫透過 ToolContext 和 CallbackContext 來完成，並且可以透過自定義常量對狀態鍵進行統一管理。

狀態鍵值的標準化定義

Travel Concierge 使用專門的常量檔案來集中管理所有狀態鍵，提升程式碼的可維護性與一致性。以下為 travel_concierge/shared_librabies/constants.py 的實作範例：

以上這些常數，在 root agent 的 before_agent_callback 中時常被 load_precreated_itinerary 作為鍵值使用。

記憶系統與 Prompt 的配合

記憶系統的真正價值體現在與 prompt 的緊密結合。在 planning_agent 的 prompt 中，我們可以看到記憶系統是如何被用來協助完成任務的：

這個 prompt 指導代理：

檢查現有資訊
獲取缺失資訊
推斷隱含資訊
使用 memorize 工具存儲關鍵資訊
採用鏈式調用確保操作順序

這種配合使得記憶系統能夠有效支持代理的任務執行，確保必要的資訊被正確存儲和使用。

穩定 AI 代理記憶系統的實作要點與最佳實踐指南

在設計和實現類似 Travel Concierge 的記憶系統時，有幾點值得注意：

1. 狀態一致性

當多個代理共享同一狀態時，需要特別注意狀態的一致性。Travel Concierge 透過以下方法確保一致性：

使用回調函數初始化狀態
採用標準化的記憶操作
明確的鍵名命名規則（通過常量定義）
鏈式調用確保操作順序

2. 錯誤處理

在 Travel Concierge 的記憶函數中，包含基本的錯誤處理：

這種防禦性編程避免了可能的運行時錯誤，提高系統的穩定性。

3. 狀態持久化

對於生產系統，狀態的持久化是一個重要考慮。Travel Concierge 的示例提到可能的擴展方向：

在這個例子中，我們使用 session states 作為 concierge 的記憶，儲存行程、中介代理/工具/使用者偏好回應。在現實應用情境中，使用者設定檔的來源應為外部資料庫，且工具寫入 session states 的對應寫入也應作為寫透（write-through）儲存至專用於使用者設定檔和行程的外部資料庫中。

這種方法可以確保系統狀態在不同會話間保持，提供更連續的用戶體驗。