TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
Google Connected Apps 預覽：把 MCP 服務接進 Gemini 與搜尋
Google 於 10 月 28 日宣布 Connected Apps Platform 開發者預覽，服務可走遠端 MCP 伺服器或 Android AppFunctions 接進 Gemini 與 Google 搜尋。本文從官方文件整理九步上架流程、品類與連線類型不可改的早期決定、種子測試帳號與位置訊號等審核關卡，以及預覽階段還拿不到什麼。
用 AI 摘要這篇文章：
Google 於 2026 年 10 月 28 日在官方部落格宣布 Connected Apps Platform 進入開發者預覽。名字聽起來像又一個支援 MCP 的介面，但把公告和開發文件攤開對照，這次發布的重心其實不在模型也不在協定，而在治理：想讓服務出現在 Gemini 與 Google 搜尋的對話裡，開發者得先走完一套驗證網域、提交測試帳號、接受審核、按版本發布的流程。這套形態接近大家熟悉的手機應用程式上架，只是審核的對象從 App 換成了 MCP 工具伺服器。公告由搜尋產品線的群組產品經理 Chips Mistry 與 Gemini 應用程式的 Mai Lowe 具名發布。這篇從官方一手文件整理出三件事：平台實際要求什麼、哪些決定選了就回不去、預覽階段你還拿不到什麼。
從被挑中的夥伴，到排隊申請的開發者
Connected Apps 這個功能本身並不新。官方公告寫著，搜尋與 Gemini 合計已有超過 50 個 Connected Apps，領域涵蓋生產力、活動票務與健康健身。但這批應用是 Google 逐一挑選合作的成果：Adobe、Experian、Localiza 與 Peloton 的整合目前只在 Gemini 上可用，公告說接下來數週會帶到搜尋；Calm 則是另行預告的新整合，計畫同時上兩個入口。公告把這次平台描述成「讓更多應用開發者」把能力帶進 Gemini 與搜尋的統一途徑，對照之下，過去檯面上的 Connected Apps 走的都是 Google 挑選合作一途。配套的開發文件節奏也看得出是新東西：MCP 開發指南與前置需求頁的頁尾更新時間標在 10 月 27 日，九步流程頁標在 10 月 28 日，等於文件在公告前後腳剛就位。
平台預覽改變的就是這一點。開發者端的新工具是 Google Connected Console，官方文件描述它負責從工具註冊、使用分析到審核發布的整套管理；預覽階段採自助申請制，透過興趣表單登記，再由 Google 分階段核可。公告原文寫得明白：正在分階段開放近用，未來數個月會增加更多開發者、市場與 Google 產品。換句話說，看得到完整文件，不代表你的帳號已經取得平台資格；文件裡描述的每個 Console 畫面，都是「取得近用之後」才看得到的世界。這也是預覽階段最容易被誤讀的地方。
服務怎麼接進去：遠端 MCP 與 Android 的 AppFunctions
MCP 是讓 AI 模型照標準協定呼叫外部工具的開放規格，先前我們實測過 MCP 伺服器的收錄生態，也介紹過讓任何 LLM 直連 MCP 伺服器的開源庫。這次 Google 給的接法有兩種，而且官方文件把它們定位成互補而非替代。
遠端 MCP 伺服器是雲端代管的路徑。開發指南把它列為跨平台基礎能力的建議預設選項，一條整合可以觸及 Android、iOS 與網頁；已經有 Web API 或既有 MCP 伺服器的團隊，可以直接照規格整理工具，不必重寫服務。指南對伺服器端的要求也有具體內涵：初始化時要寫清楚描述自身領域與能力的伺服器指令，因為 AI 模型就是靠這段文字判斷什麼時候該把任務交給你；每個工具要標註唯讀或破壞性的安全註記；參數要有明確型別與說明，把允許的欄位值講清楚，模型呼叫工具的準確度才會跟上。
Android MCP 則走 Jetpack AppFunctions SDK，處理需要應用程式當下狀態或裝置上資料的操作，價值在與 Android 系統的深度整合。和 Google ARTEMIS 那類從外部操作 Android 真機的工具對照，AppFunctions 是官方提供給應用開發者的正向整合面，兩者方向不同。
這裡有個選了就回不去的決定：每一個 Connected App 在建立時只能選一種連線類型，官方文件明文事後不能更改。想兩種都做，就登記兩個應用，各自走各自的流程。
註冊到發布的九步流程，先過技術驗證再談審核
官方文件把 Console 端的流程拆成九步，技術門檻集中在前面幾步。MCP 端點必須是公開的 HTTPS 位址、走 Streamable HTTP 傳輸，而且每個應用只支援單一全域端點，分區資料中心網址不支援；地區專屬網域只有在整個應用只於該地區上市時才能用。多區部署的團隊，架構得先整併。網域驗證則要在自家伺服器託管 /.well-known/google-connected-apps 挑戰權杖檔案，直接回應 HTTP 200 而且不能轉址。
技術門檻之外還有兩項基礎建設要預先排好。若伺服器有防火牆限制來源，得先把 Google 的對外 IP 範圍加進允許清單，而且官方提醒這些範圍會變動，建議定期從 Google 公開的清單重新整理。組織帳號這邊，Connected Apps 條款必須由帳戶擁有者或管理員登入接受，一般成員即使有開發權限，也繞不過這道身分檢查。
應用本身的公開資訊也有明確規格，整理成下表：
| 項目 | 官方規定 |
|---|---|
| 圖示 | 512×512 像素，JPG 或 PNG，最大 1MB |
| 描述 | 30 個單字內的單句，寫給使用者看，不作為模型指令 |
| 能力 | 至少三項高價值任務，一項一條，不加編號 |
| 範例提示 | 至少三條，其中至少兩條以 @應用名稱 開頭 |
| 條款與隱私政策 | 兩個 URL 都是必填 |
| 網站 | 選填，作為出處標示 |
這些欄位還支援多語言：把各語系的文字用語系標籤包起來填入，Console 會自動驗證標籤並顯示偵測到的語言數。瞄準多市場的服務，一次就能把各語版的門面備齊。
存取憑證的設定分三種情況：伺服器完全公開、不需驗證的，直接確認即可；走機器對機器驗證的，填共用的用戶端 ID 與密鑰，讓 Google 與你的伺服器直接對接；需要以使用者身分授權的，則進入下一節的種子帳號義務。
流程後段是版本制。Google 會同步你的端點、為工具清單拍快照，發布時使用最新快照並就此凍結：工具、描述、伺服器細節通通不能再改，要更新就得開新版本。同步也不是每次都順利，文件提醒常見的錯誤包括缺少探索檔案、不支援的介面資源格式，或資源總量超過上限，Console 會用必須修正的卡片標出來，得先解決才能往下走。範圍設定這一步，開發者自選應用觸及的國家與地區、語言，以及要上架的 Google 產品。
送審之後的機制值得單獨看：受審版本會被鎖定，同時系統自動另建一份可編輯的草稿版本，讓測試者預覽不受影響、下一次的修改可以並行準備；審核有問題會列出具體發現，回到可編輯版本修正後重新送審；通過後狀態變成可發布，按不按下發布鈕由開發者自己決定。發布後的面板會顯示版本號、發布日期與觸及的國家、語言、產品數量。官方還給了一個測試環境的技巧：想在正式端點之外另測 staging 伺服器，可以用 Gemini 開發者模式，或另外登記一個永遠停在預覽階段的測試應用。
另外兩個小地方值得記住：應用品類同樣選定後不能改，要換品類只能整個應用重來；測試階段只有被加進清單的測試者看得到應用，而且測試者帳號必須是 @gmail.com，企業網域帳號進不了測試名單。
審核看什麼：種子帳號、位置訊號與政策紅線
審核環節有三道關卡，都寫在文件裡，不是推測。
走使用者委派授權的應用，必須提供種子測試帳號給 Google：帳號要預先植入有真實感的樣本資料、停用兩步驟驗證，還要附測試說明。官方理由說得很直白，這是為了讓審核與品質團隊不被空沙箱、付費牆或兩步驟驗證關卡擋住；如果 Google 無法完整測試，應用可能在審核被退回。對帳號系統裡全是空資料的團隊來說，這是實打實的準備工作。
位置與情境訊號有分級天花板。工具可以向 Google 要求三級訊號：帳號地區、涵蓋範圍大於等於 3 平方公里的概略位置、以及精確到 50 公尺內的精確位置。但文件同時警告，沒有明確需求就索取額外情境，應用可能過不了審核。工具若在 MCP 註記標了破壞性操作，主控台會自動預選「要求使用者確認」的開關。
政策頁則劃出紅線：持續回傳錯誤、崩潰、逾時或驗證失敗的應用被明文禁止；不得向使用者灌送訊息、抄襲其他應用、或建立多個高度相似的應用。違規的處置是階梯式的，從提交時直接拒絕、停權應用、下架，一路到停用開發者帳戶。授權規格方面，官方高度建議 OAuth 2.1 搭配 PKCE，而且 PKCE 在 2.1 是強制；權杖生命週期建議走持續連結管理，避免使用者隔一陣子就得重新連結一次帳號。
上線之後的日常：快照版本與 @ 觸發
發布不是終點，而是維運的起點。應用上線後，Console 提供流量、延遲與錯誤率的追蹤，品牌識別也留在開發者手上，包括驗證過的標誌與已驗證帳號。使用者端則靠明確觸發：可以在對話裡用 @應用名稱 直接呼叫，或自然地在查詢裡提到應用名稱，觸發之後應用會在該次工作階段的相關提示中保持可用。官方在公告裡對開發者的承諾是打造一次、同時觸及搜尋與 Gemini 兩個入口的高意圖使用者，至於實際能見度，文件裡沒有出現任何分發或推薦機制的條文。
有個功能點先別當主力賣點：在對話介面內渲染自訂互動介面的 MCP Apps 仍在測試階段，官方明言可能不開放，伺服器上偵測到的介面資源也可能被忽略。想把介面設計當差異化的團隊，得先把這條限制排進時程考量。
台灣開發者現在能做什麼、還不能做什麼
官方開發指南把準備工作拆成四個階段，而前三個階段完全不需要等 Google 核可：先打造遠端 MCP 伺服器，把伺服器指令、每個工具的唯讀或破壞性註記、強型別的參數結構寫清楚；接著用 MCP Inspector 在本機驗證工具宣告與介面渲染，逐個呼叫工具、檢查原始輸入輸出；然後部署到公開 HTTPS 端點，在 Gemini 開發者模式裡實測，用內建的事件記錄、工具結構、環境模擬與驗證設定找問題，託管環境自選，Google Cloud 的 Cloud Run 只是文件裡的示範之一。最後一個階段才是提交申請、進 Console 註冊。換句話說，從今天就能開始的整備工作有三個階段的量。
還拿不到的也要列清楚。審核時程與通過率，官方沒有公布任何資料；分階段開放的節奏，包括台灣開發者何時取得近用資格，公告與文件都沒有給日期，上架範圍雖然由開發者自選國家與語言，但前提仍是先拿到平台門票。既有夥伴應用要數週後才會出現在搜尋，測試階段的介面功能還在 beta。這幾項建議列入回查清單，未來幾個月值得回頭核對。
判斷題最後還是回到服務本身。如果你的服務本來就有可授權的帳號體系、而且核心任務適合在對話裡一步完成，這套平台給的是先行整備的機會：把 MCP 端點、帳號體質與工具描述先磨好，等資格核可就能送審。如果只是想多一個導流入口，成本要算清楚，種子帳號義務、版本維運、政策紅線與審核等待，都是入住門票之外要持續支付的代價。與 Krea 直接接進 Grok Bot 的做法對照，Google 這邊的路徑更長，差別在它把品質與安全的事前把關做成了制度，也把違規的後果寫進了條款。
