兩個更新解決兩個老問題
過去做 RAG 的開發者都遇過這個情境：客戶給的文件裡圖片、表格、文字混在一起，傳統 embedding 只能處理文字，圖片要嘛抽出 alt 文字（資訊損失）、要嘛走 OCR（不可靠）。另一個情境：呼叫一個會跑十幾分鐘的長任務，得每幾秒打一次 API 問「好了沒？」。
Google 這兩天的更新剛好打中這兩個痛點：5/4 推出 Webhooks，長任務完成主動推通知；5/5 File Search 升級多模態，圖文同一向量空間。
兩個更新看似不相關，但解的是同一類問題：把開發者重複造的輪子直接內建進 API。RAG 不用自己拼多模態 pipeline、長任務不用自己寫 polling 迴圈。
圖文同空間檢索
File Search 這次升級的核心是換上新的 Gemini Embedding 2 模型——把文字、圖片、文件全部映射到同一個向量空間。意思是你可以用「找紅色的折線圖」這種文字 query 去搜尋整批文件裡的圖片，不需要先給圖片打標。
圖文同 store
圖表、產品照、示意圖可以直接索引，跟文字文件放在同一個 store。圖片用 Embedding 2 編碼，不需要先轉成文字描述。
細緻過濾
每個檔案可以掛自訂 metadata（作者、部門、日期、版本）。檢索時可以加 filter，例如「只搜尋 2025 年之後的工程文件」。
內建引用
每個回答都附 grounding metadata，指到具體的文件、具體的頁數。多模態 store 還會附可下載的圖片參考——對需要稽核或合規的場景特別關鍵。
少寫 pipeline
過去要做多模態 RAG，得自己串 vision 模型 + text embedding + image embedding + 對齊邏輯。現在 File Search 一個 API 包進去。
長任務不再需要 polling
Webhooks 解決的是另一個老問題：呼叫一個 Long-Running Operation（LRO，例如批次處理、長文件分析）後，傳統做法是用一個迴圈每隔幾秒打 API 問「跑完了沒？」。這種 polling 既浪費 API quota 又有延遲，而且還得自己處理 timeout 和重試。
每秒鐘打一次 API
client 寫迴圈，每 5 秒呼叫 `getStatus()`。完成時間平均延遲 2.5 秒。浪費 quota、占用連線、寫起來囉嗦。
完成主動推 callback
事件發生時 Gemini API 直接 POST 你的端點。零延遲、零無謂呼叫。client code 從「主動拉」變「被動接」，邏輯更乾淨。
這個改變對 agent 框架特別有用——很多 agent 需要排程長任務，過去得另外架一套 job queue。現在用 Webhooks，任務完成直接觸發下一步，省下中間那層。
怎麼開始
RAG 與 agent 基礎設施的補強
把這兩個更新放在一起看，方向很清楚：Google 在補 Gemini API 作為「agent 平台」的基礎設施。File Search 多模態解決資料層、Webhooks 解決事件層——配合 4 月就有的 long-running operations，整個生產級 agent 需要的 plumbing 都在補齊。
對開發者來說，這代表用 Gemini API 做 RAG 或 agent 的「自己刻」成本下降了。少寫 multimodal pipeline、少寫 polling 迴圈、少寫 citation 抽取。能差異化的地方往上移——資料來源、prompt 設計、業務邏輯。
另一個訊號是這跟 Anthropic 5/6 的 Managed Agents、OpenAI 5/7 的 Realtime 三件套同週。三家在同一週各自把「平台化」的東西推上來，等於宣告 LLM 競爭的下一階段不只看模型本身，看誰的平台 plumbing 更完整。