大家好！歡迎來到「Build on Google AI」工程挑戰的第 12 天。

在昨天的實戰中，我們透過 Gemini 成功將格式破碎的髒數據轉化為結構化的 JSON。然而，如果我們的 PM Agent 每次對話結束後就把剛剛整理好的專案狀態忘得一乾二淨，它在真實專案中就只能處理單次問答，無法勝任長期的專案追蹤任務。

在「研發與工程創新 (AI for Engineering)」的系統設計中，上下文管理 (Context Management) 與 狀態持久化 (State & Memory) 是決定 AI 能否從玩具晉升為企業級系統的關鍵分水嶺。今天，我們將深入 Google ADK 的會話與記憶核心，讓 PM Agent 擁有連貫的長短期記憶！

第一步：拆解 ADK 的記憶體系 (Sessions & State)
在 Google ADK 架構中，系統將上下文狀態切分為清晰的階層，避免了傳統把所有歷史對話硬塞進 Prompt 的效能與費用浪費：

• Session (會話)：代表單一使用者或任務的完整互動生命週期，提供獨立的隔離環境。

• Events (事件流)：依序記錄使用者輸入、模型思考過程、工具調用結果等不可變 (Immutable) 歷程。

• State (狀態儲存)：一個 Key-Value 結構的上下文資料區塊，代理人可以在對話過程中讀取或更新狀態（例如當前鎖定的專案 ID）。

• Memory (長期記憶)：跨越單一 Session 的資訊保留機制，負責檢索過往的重要決策或偏好。

第二步：實作具備狀態追蹤的 PM Agent
在 Python ADK 中，我們可以透過自定義工具或 Session Hook 直接讀寫 Session 的 state，讓 PM 在多輪對話中保持對特定專案的追蹤。

打開 agent.py，加入狀態記憶邏輯：

from google.adk.agents.llm_agent import Agent

# 1. 支援狀態更新的記憶工具
def update_project_context(project_id: str, priority_level: str, tool_context=None) -> dict:
    """
    更新當前對話關注的專案狀態至 Session State。
    
    Args:
        project_id: 專案識別碼，例如 'core-api-v2'。
        priority_level: 優先級別，如 'P0', 'P1'。
    """
    # 將關鍵變數寫入 session 狀態
    if tool_context and hasattr(tool_context, "state"):
        tool_context.state["active_project"] = project_id
        tool_context.state["priority"] = priority_level
    
    return {
        "status": "success",
        "message": f"專案 {project_id} 已設為當前關注焦點，優先級為 {priority_level}。"
    }

# 2. 定義具備記憶引導的 Instruction
pm_instruction = """
你是資深技術專案經理 (Technical PM)。
當使用者提及要切換或重點跟進某個專案時，請呼叫 'update_project_context' 記錄狀態。
在後續的交談中，若使用者未指定專案名稱，請優先沿用當前狀態 (active_project) 進行回答。
"""

root_agent = Agent(
    model='gemini-flash-latest',
    name='stateful_pm_agent',
    description="Maintains project context and manages workflows across turns.",
    instruction=pm_instruction,
    tools=[update_project_context],
)

第三步：多輪對話狀態驗證
當我們在本機或 Web 戰情室進行多輪對話時，PM Agent 的反應會呈現顯著的工程進化：

第四步：無狀態 Cloud Run 與有狀態 Agent 的工程解耦
在 Day 05 中，我們將服務部署到了 Cloud Run。身為無伺服器 (Serverless) 容器，Cloud Run 本質上是無狀態的 (Stateless)，隨時可能縮容至零或重啟。

為了實現「高可用性與可維護性」，生產環境中的 ADK 狀態管理應採取外置持久化架構：

• 本機除錯：使用預設的 InMemorySessionService，速度最快、開箱即用。

• 生產環境：替換為持久化後端（例如 Cloud Storage、Firestore 或 Redis）。當 Cloud Run 實例重啟或負載平衡將請求路由至不同容器時，ADK 能依據 session_id 從集中式儲存庫還原記憶，確保對話不中斷。

小結
今天我們打通了 ADK 的會話狀態與記憶機制，讓 PM Agent 徹底擺脫「金魚腦」，具備跨輪次維持專案焦點的能力。