Google 在 2026 年 6 月 22 日宣布 Interactions API 已進入 general availability，並把它定位成 Gemini 模型與 agents 的主要 API。新的 Gemini 專案若會碰到長任務、狀態保存或 agent 能力，應把這條 API 當成預設起點，而非 generateContent 旁邊的替代語法。
對開發者最務實的判斷是：如果你只是做一次性文字生成，既有 generateContent 還能繼續用；如果你要做會跑多步驟、會用工具、可能需要背景執行、需要保留任務狀態的 agent，就應該開始用 Interactions API 設計。Google 官方也說，legacy generateContent 會繼續支援並取得主線 Gemini 模型，但長任務與 agent 相關的前沿能力，會越來越集中到 Interactions API。
這次 GA 把開發入口往 agent 任務推進
Interactions API 在 2025 年 12 月先以 public beta 推出。這次 GA 的重點有三個：schema 穩定、官方文件預設改用 Interactions API，以及 Google 開始把 Managed Agents、background execution、工具混用與未來的 Gemini Omni 放進同一條介面。
這對產品團隊很重要。過去用 Gemini API 做應用時，常見心智模型是「送一段內容給模型，拿回一段回覆」。這種模式適合摘要、分類、生成文案或單次工具呼叫；但 agent 產品的問題通常更長：它要記住前一步做了什麼、等待背景工作完成、在同一個任務裡混合 Google Search、Google Maps、自訂函式、檔案與多模態輸出。
Google 這次把 Interactions API 描述成 Gemini 模型與 agents 的 unified interface，就是要讓「模型回覆」和「agent 任務」共用同一個工作單位。開發者可以傳 model ID 做推論，也可以傳 agent ID 跑自主任務；長時間任務則透過 background=True 讓伺服器端繼續執行，不必把所有狀態都塞回用戶端。
什麼情境該優先遷到 Interactions API？
優先判斷的焦點應放在應用是否開始像 agent，而非只估改動行數。
如果產品只是在表單送出後產生一段說明、把客服訊息分類、把會議逐字稿整理成摘要，短期內不必恐慌遷移。這些任務的狀態少、風險低、回覆通常一次完成，legacy API 的支援仍然足夠。
但如果你正在做內部自動化、coding assistant、資料整理、研究 agent、前端除錯 agent 或長時間的營運助理，就應該把新功能放到 Interactions API 上。這些任務會遇到同一組問題：工具呼叫要串起來、檔案狀態要保留、執行時間可能超過一般請求、錯誤要能續跑，最後還要留下足夠的紀錄讓人審查。
Managed Agents 是這裡最明顯的例子。Google 官方描述的方向是：一次 API call 就能 provision 一個遠端 Linux sandbox，讓 agent 推理、執行程式、瀏覽網頁與管理檔案。Antigravity agent 會是預設選項，團隊也可以用 instructions、skills 與 data sources 定義自己的 agent。這和 Mason 先前整理的 Google Antigravity 2.0 是同一條產品線：Google 想把 agent runtime、開發工具與 API 入口逐步接起來。
導入時先拆成三層：模型、任務、治理
把 Interactions API 放進架構時，建議先把問題拆成三層。
第一層是模型呼叫。這一層仍然關心 prompt、輸入輸出格式、模型選擇、串流、結構化輸出與成本。若你的產品只停在這裡，遷移壓力最低，可以等官方 SDK、範例與內部封裝穩定後再排進 roadmap。
第二層是任務執行。這裡才是 Interactions API 的主場。背景執行、server-side state、過去 interactions 的查詢、內建工具與自訂函式混用，都能降低自建 orchestration 的負擔。開發者不必每一步都把狀態從伺服器拉回應用端，也不必把長任務拆成一堆脆弱的輪詢與手動重試。
第三層是治理。這也是最容易被忽略的一層。Agent 只要能讀檔、寫檔、跑程式或呼叫工具，就必須有權限邊界、成本上限、輸出審查與稽核紀錄。Mason 在 AI agent production deployment 的判斷也一樣：能跑起來只是 demo，能被限制、觀測、回復與接管，才是 production readiness。
不要把 generateContent 當成立刻淘汰
這次更新容易被誤讀成「Google 要淘汰 generateContent」。官方說法比較精準：legacy generateContent 會繼續完整支援，並在可預見期間繼續取得新的主線 Gemini 模型；只是長時間模型與 agent 的 frontier capabilities，會越來越常只出現在 Interactions API。
因此既有產品不必用一次大改版冒險。比較健康的做法是先替新功能選路線：一次性生成繼續走既有封裝，新的 agent 類功能直接用 Interactions API；等內部觀測、成本與錯誤處理成熟後，再把高價值舊流程逐步遷過去。
這樣做有兩個好處。第一，團隊能保留已經穩定的 production 路徑，不會為了追新版 API 破壞現有服務。第二，新的 agent 能力不會被舊抽象綁住。很多舊封裝只假設「request in, response out」，遇到背景執行、server-side state 或多工具步驟時，會越改越像臨時補丁。
一週內可以做的導入檢查
這週不一定要立刻遷移全部程式碼，但可以先完成一個小範圍盤點。
先找出所有 Gemini API 使用點，分成一次性生成、工具輔助、長任務與 agent 四類。一次性生成先保持穩定；長任務與 agent 類功能列為 Interactions API 優先候選。接著選一個低風險任務做試點，例如內部文件轉換、資料清理、測試摘要或非 production repo 的 coding helper。
試點不要只看 agent 是否完成任務，還要記錄四件事：每次 interaction 花多少時間、觸發多少模型與工具呼叫、失敗後是否能續跑、輸出是否能被人或 deterministic 檢查器驗證。若任務需要瀏覽器除錯，還可以把 Chrome DevTools for agents 這類工具放進後續評估；若任務需要連接公司系統，則要同步檢查 MCP 或既有 API 權限邊界。
最後要替每個 agent 任務寫清楚停損線：最長執行時間、最大工具呼叫次數、最大輸出檔案大小、哪些動作必須人工批准、什麼情況要轉人工。這些看起來不像 API 遷移，卻會決定 Interactions API 上線後是提升交付效率，還是製造更難 debug 的自動化噪音。
Mason 的判斷：把它當成 agent 平台遷移
Interactions API GA 的訊號很清楚：Google 正在讓 Gemini API 從聊天式模型呼叫，延伸成能承載模型、agent、工具、背景工作與狀態保存的同一條開發路徑。
對新專案來說，最安全的預設是從 Interactions API 開始，尤其是任何會跨多步驟執行的功能。對既有專案來說，短期內應避免恐慌式重寫；先把長任務與 agent 功能切出來，用一個可觀測、可停損的試點驗證，再決定遷移節奏。
真正的風險不在於少改了幾個 endpoint，而在於把 agent 當成一般 API wrapper。當模型開始能保留狀態、使用工具、跑程式與背景執行，產品設計就必須同步回答：它能碰什麼資料、誰批准高風險動作、失敗時怎麼回復、成本暴衝時怎麼停止，以及使用者如何知道它做過什麼。
常見問題
Interactions API GA 後，generateContent 還能用嗎？
可以。Google 官方說 legacy generateContent 仍會完整支援，也會繼續取得新的主線 Gemini 模型。差別在於長時間任務、agent workflow 與 frontier agent capabilities，會越來越偏向 Interactions API。
Managed Agents 適合直接接 production 嗎？
不建議一開始就接高風險 production。比較好的順序是先從內部工具、非敏感資料、可回復任務與人工審核流程開始。若任務會改資料庫、呼叫金流、發送正式通知或處理醫療／法律／資安高風險內容，agent 應先停在建議層或草稿層。
團隊現在該先學哪一件事？
先學 Interactions API 的工作單位與背景執行模型，再學 Managed Agents。只改 SDK 呼叫方式不夠，真正要建立的是「長任務如何被觀測、限制、續跑與審查」的工程習慣。