Antigravity 讀不了 Gmail？用對話幫它開通讀信權限，不用自己點 Console

你把 Antigravity 接上 Gmail，興沖沖打了一句「幫我看一下今天有什麼重要的信」，結果它回你一串紅字：403 ACCESS_TOKEN_SCOPE_INSUFFICIENT。奇怪，前幾天叫它寄信明明好好的，怎麼換成讀信就翻臉？我們在課堂上帶學員接 AI email 自動化時，這一關幾乎每個人都會卡，卡點不在 AI，在 Google 給的權限範圍。

原因一句話講完：Antigravity 內建的 Gmail 技能預設只申請了「寄信」權限（gmail.send），沒有「讀信」權限（gmail.readonly）。要解決得補上讀信權限、重新換一張授權金鑰、更新到設定檔。有趣的是，這一整串設定你不必自己一格一格點。Antigravity 本來就能開瀏覽器、填表單、改自己的設定檔，所以大部分機械操作可以直接交給它，你只要出一張嘴，外加在少數幾個「Google 要確認是你本人」的關卡親自接手。這篇就示範怎麼用對話帶著 Antigravity 把權限開起來。還沒裝好的先看安裝入門指南。

先搞懂：為什麼會跳 403？

Google 的 API 權限是「一個蘿蔔一個坑」，你申請什麼範圍（Scope），就只能做那個範圍內的事。Antigravity 的 send-gmail-email 技能出廠只要了發信權限：

• 發信：https://www.googleapis.com/auth/gmail.send
• 讀信與查詢收件匣：https://www.googleapis.com/auth/gmail.readonly（這條預設沒有）

當你要求 AI「看今天的信」，它會去呼叫 Gmail 的 messages.list、messages.get 這類讀取 API，但手上的存取權杖只帶著 gmail.send，Google 一看權限不夠就退回 403 PERMISSION_DENIED。這不是 bug，是權限設計本來就這樣，補上 gmail.readonly 重新授權即可。這種「AI 能不能動手，取決於你開了哪些權限」的邏輯，是所有 AI agent 接外部工具的共同基礎，我們在 MCP、API 與 CLI 的差異解析談得更完整。

先講清楚：哪些交給 Antigravity，哪些你自己來

進入操作前，先把分工說白，你才知道什麼時候該接手，什麼時候放手讓它做。

一句話原則：機械操作放手給它，牽涉你身分與授權的關卡自己接手。下面四個階段都照這個分工走。

階段一：讓 Antigravity 帶你設定 Cloud Console

直接把目標告訴它，讓它開路。你可以這樣說：

幫我開啟 Google Cloud Console，我要設定 Gmail API 的讀信權限。請先幫我導航到建立專案的頁面，需要我登入或授權時就停下來提醒我。

Antigravity 會開好瀏覽器、導到 Cloud Console。登入畫面出現時它會停下來，這時換你親自登入。登入後接著指揮它：

幫我建立一個新專案叫 Antigravity-Gmail-Skill，建好後啟用 Gmail API，然後到 OAuth 同意畫面把這兩個 scope 加進去：gmail.send 和 gmail.readonly，測試使用者填我的 Gmail。最後建立一個 Web 應用程式類型的 OAuth 憑證，重新導向 URI 設成 OAuth Playground 那個網址。

它會一頁一頁幫你點完：建專案、啟用 API、填同意畫面、加 scope、建憑證。過程中你只需要在它問「測試使用者填哪個信箱」時回答，其餘看著它做。憑證建好會跳出 Client ID 和 Client Secret，讓 Antigravity 幫你複製記下來（這兩個值只在你本機流動，不會外傳）。重新導向 URI 這條一個字都不能錯，可以請它核對：

https://developers.google.com/oauthplayground

階段二：請它到 OAuth Playground 換 Refresh Token

Cloud Console 只是挖好權限的坑，真正的鑰匙要在 Playground 拿。繼續對話：

接下來幫我開 Google OAuth 2.0 Playground，用剛剛那組 Client ID 和 Secret 設定好，Step 1 填入 gmail.send 和 gmail.readonly 兩條 scope，然後按 Authorize。跳到 Google 授權頁時停下來讓我自己點同意。

Antigravity 會到 OAuth Playground、開齒輪勾「Use your own OAuth credentials」、貼上你的憑證、把兩條 scope 填進 Step 1、按下 Authorize。它填的 scope 應該長這樣：

https://www.googleapis.com/auth/gmail.send https://www.googleapis.com/auth/gmail.readonly

‼️ 接下來這步一定是你本人：畫面跳到 Google 授權頁，選你的帳號、勾選同意「傳送電子郵件」與「檢視您的電子郵件訊息」、按繼續。如果跳出「Google 尚未驗證這個應用程式」，那是自建測試專案的正常現象，點「進階」→「前往…（不安全）」。授權完網頁自動跳回 Playground，再把方向盤交回給 Antigravity：

已經授權好了，幫我按 Exchange authorization code for tokens，然後把回傳的 Refresh Token 複製下來。

它會抓到那串 1//0g... 開頭的 Refresh Token，這就是能讓 Antigravity 長期自動刷新的關鍵金鑰。

階段三：讓它把金鑰寫進自己的設定檔

這一步最適合交給 Antigravity，因為要改的正是它自己的設定檔，路徑它比你熟。直接說：

把剛剛拿到的 Client ID、Client Secret、Refresh Token，寫進 send-gmail-email 技能的 config.json，覆蓋舊的值。

它會找到設定檔（Windows 上通常在 C:\Users\你的帳號\.gemini\antigravity\skills\send-gmail-email\config.json）並更新，改完長這樣：

{
  "clientId": "你的_CLIENT_ID.apps.googleusercontent.com",
  "clientSecret": "你的_CLIENT_SECRET",
  "refreshToken": "剛才在 Playground 取得的_REFRESH_TOKEN"
}

‼️ 安全提醒：這個 config.json 裝的是能讀你整個信箱的憑證。它只該待在你本機，別分享、別傳上 GitHub。也因為金鑰經過 Antigravity 的手，請確認你用的是自己信任的環境；真的外洩了，回 Cloud Console 把憑證撤銷重建即可，舊金鑰立刻失效。這種「把權限開給 AI 之前先想清楚邊界」的思路，我們在 AI 代理護欄設計裡有更完整的討論。

階段四：直接對話驗收

設定完不用另外跑什麼，直接下指令驗收兩件事：

1. 測發信：「幫我寄一封測試信到 you@gmail.com」→ 應該成功寄出、回傳 Message ID。
2. 測讀信：「幫我看一下今天有什麼重要的信」→ 這次應該成功列出寄件者、主旨與摘要，不再跳 403。

兩個都過，Antigravity 就從「只能幫你寄」升級成「能幫你讀、幫你整理」了。接下來就能玩更進階的：每天早上請它掃收件匣挑出重要的信、自動歸類、擬好草稿等你過目。想把這種 email 自動化接進團隊日常流程，正是我們替企業做 AI 導入時最常落地的場景之一。想看我們課堂上教的另一套對話驅動流程，可以參考用 Antigravity 四步做市場分析簡報。

資料來源與延伸閱讀

本文操作流程實測於 2026 年 7 月，Google 介面偶有調整，以官方為準：

• Google OAuth 2.0 Playground
• Google Cloud Console

站內延伸閱讀：

• Antigravity 安裝入門指南，第一次用先看這篇。
• 用 Antigravity 四步做市場分析簡報，另一套對話驅動的實戰流程。
• AI 代理護欄設計，把權限開給 AI 之前必讀。
• 把個人經驗沉澱成團隊技能，讓整組人都會這套設定。

權限開好了，然後呢

用對話把 scope 開起來只是第一步。真正難的是把 AI 讀信、分類、回覆這條線接進實際營運流程還不出錯，更麻煩的是出錯的時候要怎麼在客戶發現之前先發現。作品案例裡有我們把 AI 接進客戶既有流程的專案，做法與規模都攤在上面。AI 自動化開發是我們實際在做的事，想聊聊你們打算先自動化哪一段，隨時找我們。

本系列延伸閱讀

這篇是我們 Google Antigravity 系列的一部分，建議搭配延伸閱讀，完整掌握這套工具：

• Google Antigravity 安裝與設定完整指南