Google I/O 2025 一週年：哪些 AI 承諾落地了，哪些還在候場

重點一：Google I/O 2025 的 27 項以上 AI 公告，一年後呈現清楚的兩速落地：Gemini API 與 Workspace AI 在半年內廣泛可用，Project Astra 這類消費端即時 AI 仍無廣泛版本。

重點二：這個分布不是偶然——開發者 API 和生產力工具的承諾通常六個月內落地，消費端即時 AI 通常要十八個月以上才清晰。這是評估 Google 下一次 demo 時可以重用的框架。

重點三：給開發者的三條現在判斷：Gemini API 可以放進產品基礎設施；Jules 類非同步代理人現在就開始設計任務分類，不用等全面開放；Project Astra 繼續等正式版。

2025 年 5 月 20 日下午，Mountain View 的 Shoreline Amphitheatre，Sundar Pichai 為 Google I/O 2025 開場。接下來兩天，Google 把 27 項以上的 AI 公告塞進議程：Gemini 2.5 Pro 的百萬 token context window、Jules 的背景非同步代碼代理人（AI agent）、Project Astra 的手機即時視覺助理、Workspace 從 Gmail 到 Sheets 的全面 Gemini 整合、搜尋的 AI Mode——每一條線都有 demo、都有時間表，聽起來都很近。

一年後的今天是 2026 年 5 月 28 日。

這 27 項承諾裡，哪些進了每個 Workspace 帳號，哪些還在等候名單，哪些的 demo 還是那個 demo——答案不是平均分布的。更重要的是：這個分布告訴了你關於 Google AI 平台選擇的一件實用的事。

2025 年 5 月的 I/O 清單：27 項公告裡，哪幾條線最集中

去看 I/O 2025 的公告集，可以把它分成四條主線。

第一條：模型 API 與開發者工具線。 Gemini 2.5 Pro/Flash 發表、AI Studio 更新、Gemini API 長 context window 開放開發者測試——這條線上的每一個功能，都有明確的 API endpoint 和文件，開發者可以在幾天內開始實驗。

第二條：企業生產力線。 Gemini 深入 Google Workspace，包含 Docs 的文件起草協助、Gmail 的摘要與回覆建議、Sheets 的資料分析——全部走企業付費方案，有明確的採購路徑。NotebookLM 的 Audio Overview 擴充也在這條線上。

第三條：消費端搜尋與手機 AI 線。 Search AI Mode（對話式 AI 搜尋）在美國推出；Android 上的 Gemini 預告往系統層整合走。這條線的功能要透過大規模基礎設施推出，推進速度本來就比 API 慢。

第四條：未來展示線。 Jules（背景代碼代理人）、Project Astra（即時多模態助理）、Veo 2（影片生成）、Flow（AI 電影製作工具）——每一個都有令人印象深刻的 demo，但都伴隨著「coming soon」或「limited access」的標籤。

換句話說：I/O 2025 有兩種公告——一種是「現在有 API 文件、明天就可以試」的，一種是「我們展示了 demo、正式版之後」的。這兩種東西在同一個 keynote 裡，外觀一樣近。

「Google I/O 的規律是：開發者 API 和生產力工具的承諾通常在六個月內落地，消費端 AI 功能的承諾通常要等十八個月後才清晰。分辨這兩條線，是用 Google 技術建產品的第一個判斷動作。」

進了每個人帳號的那半邊：Gemini API、Workspace、Android 的一年現況

到 2026 年 5 月，I/O 2025 的第一條線和第二條線大致兌現了。先看對照表：

I/O 2025 主線	代表功能	發表時狀態	一年後（2026 年 5 月）
模型 API	Gemini 2.5 Pro / Flash	發表後數月內可用	廣泛可用；模型世代已繼續迭代
企業生產力	Workspace AI（Gmail / Docs / Sheets）	逐步推出	付費方案廣泛可用（約半年到位）
消費端搜尋	Search AI Mode	美國開始推出	美國持續擴大；其他地區需單獨確認
手機系統 AI	Gemini on Android	預告系統層整合	2026 年 5 月公布排程，夏天起分波推出
非同步代理人	Jules	等候名單有限存取	逐步開放中，未見全面開放公告（推估）
即時多模態	Project Astra	舞台 demo＋有限測試	仍無廣泛消費端版本（推估）
影片生成	Veo 2 / Flow	有限存取	仍以有限存取為主（推估）

表中標「推估」的項目，是依官方公開公告的軌跡整理——Google 沒有為這些產品發布過「現況總表」，狀態以最後一次官方公告為準。

Gemini API（I/O 2025 發表的 Gemini 2.5 Pro 和 Flash）在發表後數月內就透過 Google AI Studio 與 Gemini API 廣泛可用。百萬 token context window 是開發者可以直接叫用的功能，不是 demo——這對需要處理長文件、長對話歷史、或複雜多模態任務的開發者，是實際的基礎設施升級。Flash 是成本效率較高的版本，適合需要高頻呼叫的應用場景。一年後，這條 API 線的模型世代已經繼續往前迭代，但「長 context 加上 Flash 低價層」的產品結構沒有變。

Workspace AI 在付費方案（Business Standard 以上）廣泛可用。Gemini 在 Gmail 的摘要和起草建議、在 Docs 的段落補充、在 Sheets 的公式協助和資料解讀，已經是很多企業日常工作流程的一部分。

Search AI Mode 從 2025 年起在美國推出、持續擴大；其他地區的推出速度不一，台灣可用性需要單獨確認。Android 上的 Gemini 則在 2026 年 5 月 12 日等到了具體出貨計畫：Google 公布 Gemini Intelligence on Android（含跨 App 多步驟任務代辦、螢幕脈絡讀取）從 2026 年夏天起在最新 Samsung Galaxy 與 Pixel 裝置分波推出。

也就是說，I/O 2025 的執行節奏在這半邊看得很清楚：Gemini API 從發表到廣泛可用花了幾個月；Workspace AI 從公告到企業廣泛可用花了約半年；Android 深度整合從 I/O 2025 到公布出貨排程，花了大約一年。

Jules 的現實進度：AI 代碼代理人從 demo 到開發工作流

Jules 是 I/O 2025 裡設計邏輯最清晰的「未來產品」：你開一個 GitHub issue，把任務交給 Jules，Jules 在背景沙盒環境裡獨立工作，一段時間後回傳一個 pull request。你不需要等在旁邊，你去做別的事情。

這個設計和即時 AI 補完工具（GitHub Copilot 那種邊寫邊補的型態）是不同的範式。補完型工具是你的輸入速度加速器；Jules 是你的工作流程分叉器——它讓一件任務可以在你離開後推進。這個差別決定了它的使用場景：Jules 適合規格明確、可以用測試驗證的獨立任務，不適合需要即時判斷的設計決策或架構討論。

從公開公告的軌跡看，Jules 自發表以來走的是等候名單式的有限存取、逐步開放，一年後仍未見「所有開發者點開就能用」的全面開放公告。這個時間比許多人的預期長，但不意外：背景代理人（AI agent）的可靠性要求比即時補完高得多，因為它需要讀懂整個任務、規劃步驟、生成可執行的代碼、通過測試，然後回報——任何一步出錯，PR 就是廢的，還需要人工處理。

但這不影響你現在開始準備。Jules 的非同步任務分類，比 Jules 本身的開放進度更重要——在你的開發流程裡，哪些 issue 適合交給背景代理人（規格清楚、可測試、低風險），哪些一定要即時監督——這個分類框架是你用任何非同步 AI 代理人都需要的判斷基礎，現在就可以開始設計，不用等 Jules 全面開放。

Project Astra 為什麼最慢：即時多模態助理的產品化難題

I/O 2025 的 Project Astra demo 是印象最深的那個：在一台手機上，AI 可以透過鏡頭即時辨識眼前的環境、聽懂語音提問、記住這次對話之前問過的問題，近乎即時地給出有脈絡的回應。場面震撼，demo 很完整。

一年後，Project Astra 仍然沒有廣泛消費端版本。

這個落差不是 Google 的執行失敗，而是**即時多模態助理（real-time multimodal assistant）**這個類別的系統性難題。幾個問題必須同時解決：

1. 延遲：語音輸入、即時鏡頭影像要同時處理、即時回應——需要的推論基礎設施和模型最佳化，比純文字 API 複雜整整一個量級。
2. 成本：即時視覺理解的推論成本遠高於文字推論；要讓普通用戶用得起，需要大量最佳化才能把單次使用成本壓到合理範圍。
3. 裝置相容性：要在不同規格的 Android 裝置上流暢跑，不只是在旗艦 demo 機上。這牽涉到系統層整合的測試量級。
4. 使用場景包裝：這個助理應該在哪些時刻主動出現，哪些時刻退後——這是產品設計題，不是模型能力題，需要真實用戶測試才能收斂。

---

白話講，把幾條線的時間擺在一起看：Gemini API 廣泛可用，幾個月；Workspace AI 廣泛可用，約半年；Android Gemini 整合走到出貨排程，約一年。Project Astra 需要的基礎設施準備比這些都更複雜——十八個月以上是從這個執行記錄讀出來的合理預期，不是悲觀說法。

對開發者的一年後判斷：三條現在可以用的線

I/O 2025 的一年執行記錄給了我們足夠的數據點，可以給出三條具體的建議。

第一條：Gemini API 現在就可以放進你的產品基礎設施。

百萬 token 級的 context window 加上 Flash 級的低價層，讓長文件處理、長對話歷史維護、複雜的檢索增強生成（RAG）任務變成可行的日常 API 成本，不是實驗預算。如果你的工作流程有大量文件輸入（法律合約、研究報告、客服對話歷史），現在評估 Gemini API 是有依據的——這條線一年來的執行記錄證明它是正式版基礎設施，不是測試版賭注。

第二條：Jules 值得現在申請存取，同時開始設計非同步任務分類。

Jules 全面開放的時間還需要等，但「等它好了再想」這個策略會浪費你的適應時間。現在就思考：在你的開發流程裡，哪些 GitHub issue 適合交給背景代理人（規格明確、可測試、低耦合），哪些一定需要即時監督——這個分類框架是你用任何非同步 AI 代理人都需要的判斷基礎，Jules 只是第一個具體的測試對象。

第三條：Search AI Mode 改變了內容格式的優先順序，無論你現在能不能直接用它。

AI Mode 把搜尋結果變成直接回答問題的對話式格式。Google 沒有公開它挑選內容的細節，但結構清晰、直接回答問題、帶具體數字的內容，在這種格式下比依賴關鍵字密度的長文更容易被引用。如果你有維護網站或文件，現在調整內容結構（明確的 FAQ、直接的段落主題句、有具體數字的描述）是合理準備，而且這個調整對傳統搜尋排名也無害。

---

回看 Google I/O 2025，一年後的執行記錄提供了一個清晰的選品框架：Google 在開發者 API 和企業生產力工具上的執行速度快、可預測；在消費端即時 AI 功能上，不管 demo 多完整，產品化都需要更長的時間。

下一次 Google 展示一個令人印象深刻的 demo，你現在知道怎麼問了：這個功能在哪條線上？是有 API 文件的開發者工具，還是需要全球基礎設施就位的消費端功能？前者，現在就可以開始規劃。後者，繼續等正式版。Google 自己都還沒把它變成正式產品的東西，你等不是損失，你急才是。

資料來源：Google I/O 2025 Keynote（Sundar Pichai）；Google DeepMind Gemini 產品頁；Google Blog — Jules AI Coding Agent；Google Blog — Search AI Mode；Google Workspace Blog；Google Blog — Gemini Intelligence on Android；Signals「Google 把 Gemini 放進 Android 與 Chrome」

林子睿（編輯：廖玄同），《Google I/O 2025 一週年：哪些 AI 承諾落地了，哪些還在候場》，矽基前沿 [Si]gnals，2026-06-10。https://signals.tw/articles/google-io-2025-one-year/