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

當我們的 PM Agent 成功上線並整合 Web UI 後，團隊成員開始瘋狂地把各種超長的專案規格書、Jira 工單和會議逐字稿丟給它。這時，系統很快就會面臨兩個殘酷的現實：Token 上限 與 API Rate Limit。

在「研發與工程創新 (AI for Engineering)」中，我們不能只停留在 Prototype。今天，我們將深入 Google ADK 的進階架構，看看如何優化上下文與驗證機制，讓 Agent 具備企業級的吞吐量！

第一步：超長文本的救星 (Context Caching & Compression)
當對話輪次增加或輸入文件過大時，每次 API 呼叫都重新傳遞完整的歷史紀錄會極度浪費 Token 並拖慢回應速度。
在 Google ADK 的框架設計中，原生的 Context (上下文) 模組提供了兩大核心解法：
- Context caching (上下文快取)：透過快取機制，系統可以將靜態的長文本暫存，避免在每次對話中重複計算 Token。
- Context compression (上下文壓縮)：當歷史紀錄龐大時，透過壓縮技術精煉關鍵資訊，確保 Agent 的長期記憶不會撐爆模型的上下文視窗。

第二步：突破 API 限制：從 Express Mode 轉向企業級身分驗證
在本地開發階段，我們通常依賴「Express Mode (快速模式)」，透過簡單的 API Key 來進行快速原型開發與測試。然而，這種模式在面對高頻繁的並發請求時，很容易觸發嚴格的 API Rate Limit。

為了讓 PM Agent 能在生產環境中穩定承受大流量，我們必須調整身分驗證策略：
- Service Account (服務帳戶) 部署：當我們將 Agent 部署到 Google Cloud 的安全託管環境（如 Cloud Run 或 GKE）時，環境會自動提供 Service Account 憑證，無需手動設定金鑰檔案。
- 啟用企業級平台：我們需要在環境變數中設定 GOOGLE_GENAI_USE_ENTERPRISE=TRUE，藉此正式啟用 Agent Platform 並掛載企業級專案的配額，大幅提升 API 的呼叫上限與穩定性。

第三步：透過多模型路由分散負載
如果單一模型的配額依然吃緊，我們還可以利用 ADK 廣泛支援多種 AI 模型的特性來進行分流。

除了強大的 Gemini 模型外，ADK 也支援串接 Agent Platform 上代管的 Claude 等第三方模型。透過模型路由策略，我們可以將簡單的日常意圖辨識交給輕量級模型，而將超長會議紀錄的深度摘要交給具備超大上下文視窗的旗艦模型（如 Claude 或 Gemini Pro）。藉由動態切換，不僅能最佳化 API 的消耗，還能完美控制系統成本。

實作程式碼：
請將以下的程式碼配置到你的 agent.py 中。這裡我們展示了如何透過環境變數無縫切換到 Google Cloud 企業配額，並設定專為處理海量議程草案與會議紀錄的長文本代理人：

import os
from google.adk.agents.llm_agent import Agent
# 若有自定義工具，可在此引入
# from tools import update_project_context, fetch_devfest_cfp

# 1. 啟用 Agent Platform (企業級身分驗證與配額)
# 透過 Service Account 部署至 Cloud Run 時，這些環境變數將自動生效
os.environ["GOOGLE_GENAI_USE_ENTERPRISE"] = "TRUE"
os.environ["GOOGLE_CLOUD_PROJECT"] = "your-gcp-project-id"
os.environ["GOOGLE_CLOUD_LOCATION"] = "us-central1"

# 2. 實例化具備長文本處理能力的 PM Agent
pm_agent = Agent(
    # 使用具備超大上下文視窗的旗艦模型來處理海量 CFP 與歷史紀錄
    model='gemini-1.5-pro',
    name='enterprise_pm_agent',
    description="負責統籌大型技術年會與系列工作坊的技術專案經理，具備處理長篇會議紀錄與合約的分析能力。",
    instruction="""
    你是資深技術專案經理 (Technical PM)。
    當接收到超過 50 份以上的講者提案 (CFP) 或歷年會議紀錄時，請優先進行關鍵字萃取與技術趨勢分類。
    若需要修改專案狀態，請呼叫 'update_project_context'。
    """,
    # 這裡可掛載 Day 12 開發的專案狀態工具
    tools=[], 
)

if __name__ == "__main__":
    # 開發階段仍可透過命令列進行本地驗證[cite: 6]
    print("啟動企業級 PM Agent 測試環境...")
    # 執行 adk web --port 8000 即可在網頁戰情室看到此 Agent[cite: 6]

程式碼解析
- 無痛切換企業配額：
我們只需在程式碼或環境變數中宣告 GOOGLE_GENAI_USE_ENTERPRISE=TRUE，系統底層就會自動捨棄
受限的 Express Mode API Key，轉而掛載 Google Cloud 的企業級專案配額[cite: 8]。
這不僅解決了 API Rate Limit 的痛點，更是未來順利部署至 Cloud Run 的關鍵步驟[cite: 8]。

- 模型路由與長文本適配：
  在 Agent 的宣告中，我們刻意將模型從輕量的 gemini-flash-latest 切換為具備更強大上下文處理
  能力的模型（如 Gemini Pro）[cite: 6]。結合 ADK 底層原生的 Context caching 與 Context 
  compression 運算優化，Agent 就能輕鬆吞下整場大會的歷史逐字稿而不會引發 Token 爆炸。  
  
- 開發與生產的一致性：
  即便我們加入了這些企業級的設定，你依然可以在終端機輸入 adk web --port 8000 來啟動 Web UI 
  戰情室進行視覺化除錯，這大幅降低了從開發到上線的摩擦力[cite: 6]。

小結
今天我們透過 ADK 的上下文快取機制與 Service Account 部署策略，成功幫 PM Agent 打通了處理大數據的任督二脈。