Google 5 月 4 日於 Gemini API 上線 Webhooks 功能、解決長任務（long-running jobs）開發者痛點。Google 官方部落格說明、Webhooks 是事件驅動的推送通知機制、開發者不必再用輪詢（polling）方式持續向 Gemini API 詢問任務狀態—API 完成後會主動把結果推送到開發者指定的 endpoint。Google AI 開發者關係主管 Logan Kilpatrick（@OfficialLoganK）在 X 上稱這是「對長任務 DevX 的重要一步」。
解決什麼問題：batch、影片生成、長 reasoning 的輪詢成本
過去 Gemini API 開發者面對 batch（批次處理）、影片生成（Veo 2）、長 reasoning 任務時、必須每隔幾秒呼叫一次 status endpoint 確認任務進度。這種模式在資源消耗、API quota、延遲三個層面都不理想：
資源浪費—大量無意義的 status check 呼叫、占用 API quota
延遲不可控—polling 間隔太短燒 quota、太長則得知結果延後
程式碼複雜—需要在客戶端寫狀態機管理多個並行任務的輪詢
Webhooks 把這個模式翻轉：開發者註冊一個 callback URL、Gemini API 完成任務時主動 POST 結果到該 URL、客戶端只需處理推送即可。
適用情境：Batch API、Veo 2 影片、長 context 推理
本次推出的 Webhooks 主要適用三類非同步任務：
Batch API—Gemini 的批次處理 endpoint、用於大量文字、嵌入向量、分類任務、官方提供 50% 的折扣價、目標 24 小時回應、實際多在數小時內完成
影片生成（Veo 2）—單支影片生成需要分鐘級時間、過去開發者要不停輪詢
長 context 推理—1M token 以上的長文件分析、Gemini 內部處理可能需數十秒至數分鐘
對開發者實作而言、註冊 webhook 後、客戶端可以「丟出任務、忘記它」、結果完成時自然由 Gemini 主動通知。這個模式特別適合無伺服器（serverless）架構、後端只在事件到達時被喚醒、不必維持輪詢進程。
對 OpenAI、Anthropic 的對位：誰先做、誰後做
長任務 webhook 在三大 AI 平台的進度：
Google Gemini：5 月 4 日推出 Webhooks（本案）、batch、影片、長 reasoning 全部覆蓋
OpenAI：Codex、Sora 2 等長任務目前主要靠 SSE（Server-Sent Events）串流、批次任務有獨立 endpoint 但無原生 webhook
Anthropic：Claude API 暫無原生 webhook、Claude Code 內部用 polling 機制處理長任務
Google 在 DevX（developer experience）這條軸線上、過去 12 個月明顯加大投資—從 Gemini 2.5 Pro 的 1M context、AI Studio 的視覺化開發、Cloud Next 2026 推出的 Agent Designer、Memory Bank、到本次的 Webhooks—相對於 OpenAI 對「直接消費端產品」（ChatGPT、Operator）的優先序、Google 走的是「企業／開發者基建」路線。Webhooks 是這條路線的具體一塊。
後續觀察：webhook 安全機制、適用模型範圍
下一階段的觀察重點：
Webhook 安全機制—Gemini 是否提供 HMAC 簽章驗證、避免 callback URL 被偽造請求轟炸
適用模型擴展—目前涵蓋 batch、Veo 2、長 reasoning、未來 Imagen 影像生成、Speech-to-Speech、Gemini Live 是否一併支援
OpenAI、Anthropic 的回應—當 Google 把 DevX 拉到這個水平、競爭對手是否跟進
對台灣開發者實務而言、若你正在用 Gemini API 做 batch 任務（例如批次處理客戶資料分類、文件摘要）、Webhooks 是值得立即整合的功能、可大幅降低 API quota 消耗與系統複雜度。
這篇文章 Gemini API 推 Webhooks：Google 解決長任務輪詢痛點、Batch／Veo 可即時推送 最早出現於 鏈新聞 ABMedia。
相關文章
