🤖 Gemini Interactions API 初探
Google 針對 Stateful AI 應用程式記憶體管理的方案...之一
Substack 的操作介面很不直覺啊, 不知道有沒有 API/MCP (該不會要自己搞一個吧)
Google 最近推出了 Gemini Interactions API，為開發者建構有狀態 AI 應用程式的方式帶來了範式轉移。與傳統需要自行管理對話歷史的方法不同，這個 API 提供了內建的對話狀態管理功能。雖然這簡化了開發流程，但也伴隨著值得仔細審視的架構影響和成本考量。
什麼是 Interactions API？
Interactions API 實現了具有持久狀態管理的多輪對話功能。開發者不需要手動追蹤對話歷史並在每次請求時傳遞，API 會透過 Interaction Objects 自動處理這一切——這些結構化記錄封裝了使用者訊息、模型回應、工具呼叫和工具結果。
核心功能
自動狀態管理：API 透過 `previous_interaction_id` 在多輪對話中維護對話上下文
工具編排：無縫整合函數呼叫、內建工具（Google 搜尋、程式碼執行）和 MCP 伺服器
長時間運行任務：支援背景執行的非同步操作（`background=true`）
內建記憶體：伺服器端儲存對話歷史
儲存架構：雖然文件中沒有明確說明，但這些 Interaction Objects 很可能儲存在 Google Cloud Storage (GCS) 或類似的持久化基礎設施中，這直接影響了資料保留政策和成本。
1 天 vs. 55 天保留期
免費方案
資料保留期: 1 天
場景: 快速示範、測試、無狀態應用
限制: 無法支援回訪使用者或需要持久記憶的應用
付費方案
資料保留期: 55 天
場景: 具有對話歷史的生產環境應用
限制: 儲存成本累積；必須管理資料生命週期
🚨 免費方案使用者的影響
24 小時保留限制從根本上限制了你能建構的應用類型。在 25 小時後，你無法使用 `previous_interaction_id` 來繼續對話——伺服器端的狀態已經消失。這迫使開發者必須：
- 只建構無狀態或短會話的應用程式
- 為超過 24 小時的使用者上下文實作外部記憶體儲存
- 在客戶端手動管理對話歷史（無狀態模式）
解決方案：如果你在免費方案上需要超過 24 小時的記憶，必須實作自己的解決方案，使用外部資料庫、向量儲存或類似的持久化層。
💸 付費方案的隱藏成本
升級到付費方案可獲得 55 天的保留期，但引入了新的成本維度：
傳統 LLM 成本：
1. 輸入 Token（提示處理）
2. 輸出 Token（回應生成）
Interactions API 的新成本：
3. 互動儲存成本
對於高流量應用，這會快速累積：
範例：客戶支援聊天機器人
- 每天 10,000 位使用者
- 平均每位使用者 5 次互動
- 每天 50,000 個互動物件
- 保留 55 天 = 275 萬個儲存物件
- 即使每個物件只需幾分錢，這也會累積成可觀的數字
控制儲存：Opt-in 選擇
關鍵是，你可以透過 `store` 參數控制要儲存什麼：
何時應該使用 `store=false`：
GDPR/HIPAA 合規要求
敏感的財務或醫療資料
臨時除錯會話
高頻率、低價值互動
限制：當 `store=false` 時，你無法在後續輪次中使用 `previous_interaction_id`，因為互動沒有在伺服器端持久化。你必須改為在客戶端管理狀態。
架構決策框架
在採用 Interactions API 之前，評估以下問題：
1. 記憶持續時間需求
如果所需記憶 ≤ 24 小時：
→ 免費方案可能足夠
如果 24 小時 < 所需記憶 ≤ 55 天：
→ 需要付費方案
如果所需記憶 > 55 天：
→ 需要混合方法（API + 外部儲存）2. 資料敏感性與合規性
高敏感性（財務、醫療、個人）：
考慮對所有互動使用 `store=false`
實作自己的加密安全儲存
仔細審查資料處理協議
中等敏感性（商業資料）：
審查 Google 的資料處理條款
考慮僅對敏感輪次選擇退出
實作生命週期管理
低敏感性（公開內容、示範）：
完全接受 API 便利性
標準保留政策即可滿足
3. 成本
計算每月總成本，包括：
Token 成本：輸入和輸出 token 使用量
儲存成本：互動數量 × 保留期 × 每次互動的儲存成本
平均儲存互動數：每日互動數 × 27.5（55 天的平均值）
對於每日互動量高的應用程式，儲存成本可能成為 API 總帳單的重要組成部分。
混合架構模式
對於具有多樣化需求的生產應用，混合方法提供了最佳平衡：
短期上下文（≤55 天）：
使用 Interactions API 與 `previous_interaction_id`
利用自動狀態管理
受益於隱式快取以提升效能
長期上下文（>55 天）：
在向量資料庫中儲存摘要
檢索相關上下文並注入新互動
維持對資料生命週期的控制
敏感資料：
對敏感互動使用 `store=false`
在你的安全資料庫中儲存加密版本
遵守監管要求
無狀態操作：
(待續)
進階功能
Interactions API 超越了簡單的對話：
多輪對話：同時支援有狀態（伺服器管理）和無狀態（客戶端管理）模式
工具整合：函數呼叫、內建工具（Google 搜尋、程式碼執行、URL 上下文）和遠端 MCP 伺服器
多模態：支援圖像理解、音訊處理、影片分析、PDF 文件和圖像生成
結構化輸出：JSON schema 強制執行以實現可靠的資料提取和分類
串流：在生成時逐步接收回應
背景執行：支援非同步輪詢的長時間運行任務（僅限代理, aka. Agent）
限制與考量
Beta 狀態：API 處於 beta 階段——schema 和功能可能會有破壞性更新
工具組合：混合使用 MCP、函數呼叫和內建工具有一些限制
輸出排序：某些內建工具的工具結果排序存在已知問題
模型支援：目前支援 Gemini 2.5 Flash、2.5 Pro 和 3 Pro Preview 模型，以及 Deep Research 代理
結論
Gemini Interactions API 為建構對話式 AI 應用提供了顯著的便利性，但它不是萬靈丹。內建的記憶體管理帶來了明確的權衡：
✅ 優勢：
- 簡化開發工作流程
- 自動狀態管理
- 無縫工具編排
- 減少基礎設施負擔
- 快取帶來的效能優勢
⚠️ 考量事項：
- 嚴格的保留限制（1 天或 55 天）
- 儲存成本捆綁到 API 使用中
- 資料主權和合規性影響
- 潛在的供應商鎖定
- Beta 期間可能出現破壞性變更
建議：將 Interactions API 視為你架構中的有價值工具，而非完整解決方案。對於大多數生產應用，混合方法提供了最佳平衡——利用 API 的便利性處理短期到中期狀態，同時維護你自己的系統來處理長期記憶、敏感資料和自訂分析。
關鍵在於提前理解這些限制並相應地設計你的架構。只有這樣，你才能在保持對成本、合規性和使用者體驗控制的同時，充分利用 API 的強大功能。
---
資源
[官方 Interactions API 文件](https://ai.google.dev/gemini-api/docs/interactions)
[使用 ADK 和 Interactions API 建構代理](https://developers.googleblog.com/building-agents-with-the-adk-and-the-new-interactions-api/)
[Google AI 部落格：Interactions API 公告](https://blog.google/technology/developers/interactions-api/)
[API 參考文件](https://ai.google.dev/api/interactions-api)