Gmail MCP 多帳號實戰：Claude Code 5…

四個 Gmail 帳號。918 封未讀信。40 秒做完晨報，還抓出 7 件要處理的事。這種數字很直接，也很誠實，因為它說的是省時間，不是講故事。

這篇來自 Build to Launch 的整理，重點放在 Claude Code 怎麼接 Gmail API，還能撐住多帳號。不會一直跳重認證，也不會把個人、商務、訂閱信混在一起。說白了，這才是實戰，不是 demo。

你可能會想問，郵件自動化有什麼好寫的。答案很簡單。當你有收據、付款通知、合作邀約、訂閱警報時，Gmail 早就不是信箱。它是你的營運層。這也是 Claude Code 和 MCP 真正能派上用場的地方。

Gmail MCP 到底做了什麼

很多人一聽到 Gmail MCP，就只想到搜尋。老實說，搜尋只是最無聊的那一段。真正有價值的是，Claude Code 可以直接讀信、分類、草擬回覆，還能把結果整理成你看得懂的格式。

這種做法的重點，不是把信件變成聊天記錄。重點是把郵件變成可處理的資料。當郵件可以被分類、萃取、標記，整個工作流就從「人工翻信」變成「機器先整理，人再決定」。

這篇文章提到幾個很貼地的任務。像是收據萃取、合作信件分流、訂閱暴增偵測，還有每天早上的跨帳號摘要。這些都不是花俏功能，都是會真的卡住人的日常。

• 4 個 Gmail 帳號：個人、Newsletter、商務、付款
• 918 封未讀信，外加 3,353 封總信件
• 103 封信在單次收據流程中被處理
• 1,986.41 美元被整理進支出與款項紀錄
• 40 秒內產出晨報，列出 7 件可行動項目

這些數字很有感。因為它不是「加快一點點」，而是直接把一堆人工步驟砍掉。對常常要報帳、追款、看合作信的人來說，這差很多。

多帳號為什麼最容易翻車

單一 Gmail 帳號很好處理。真正麻煩的是，你的工作本來就被拆散了。收入進一個信箱，Newsletter 進另一個，客戶信放第三個，個人消費又在第四個。這時候，如果工具還要你一直切來切去，那你只是把工作換成另一種手動操作。

這篇指南抓到一個很準的問題。失敗的地方通常不是「接不到」。失敗的是路由。Claude 如果讀錯帳號、一直要求重新授權、或把資料串錯，整個系統就會變得很煩。

作者 Jenny Ouyang 把三個常見問題講得很清楚：account bleed、re-auth friction、false confidence。講白了就是資料串流、授權卡住、和你以為它很穩但其實沒有。

“The hard part is not connecting one inbox. It is setting up multiple Gmail accounts without constant re-auth, account mixups, or broken routing.” — Jenny Ouyang

這句話很準。多帳號郵件自動化，本質上是基礎架構問題，不是提示詞問題。底層亂掉，上層就只能跟著亂。

而且這類問題很容易被 demo 騙過。第一次跑得動，不代表第十次、第 20 次還正常。OAuth token 到期、權限重設、帳號切換，這些才是日常會踩到的坑。

5 種工作流，才是這套東西的重點

這篇文章最實用的地方，是它沒有停在安裝教學。它直接給了 5 種工作流。收據萃取、合作信件初篩、Inbox zero 分類、訂閱暴增偵測、跨帳號晨報。這些都很像真實工作，而不是玩具範例。

我覺得這樣切很聰明。因為郵件問題本來就分兩類。一類是錢，像收據、付款、訂閱、工具費。另一類是注意力，像合作邀約、待回信、今天要不要處理。兩類混在一起時，最容易讓人整天卡住。

其中最有感的是數字對比。收據流程吃了 103 封信，整理出 6 個月的付款與訂閱紀錄。晨報則掃了 918 封未讀信，只留下 7 件值得處理的事。這種壓縮比很高，說明它不是單純搜尋，而是先過濾再輸出。

• 收據萃取：整理 payouts、發票、訂閱與工具費
• 合作信初篩：把合作提案先分群，再集中看
• Inbox zero 分類：把未讀信分成回覆、封存、待查
• 訂閱暴增偵測：抓 newsletter 訂閱量異常變化
• 晨報：一次掃描 4 個帳號，只回傳需要處理的項目

還有一個細節很重要。作者提到 reader-reply 類型的觸發條件，最後可能什麼都不回傳。這不是失敗，這是設計正確。因為自動化最怕的，就是你明明不需要資訊，卻一直被空報表轟炸。

這種架構跟其他方案差在哪

這套設定用的是單一 Google Cloud project，再搭配多個 MCP connection，還有每個帳號各自獨立的 server。這聽起來很工程味，但其實很合理。你要的是隔離，不是把四個信箱攪成一鍋。

如果拿一般的 Gmail automation 來比，差別很明顯。一般方案常常只處理單帳號，或是靠一個 OAuth token 硬撐。這種做法在測試時看起來沒問題，等你真的把個人、商務、付款混進來，就開始出事。

這篇也提到他們對開源 Gmail MCP 做了小幅 fork，目的就是讓路由在重複使用下還能穩。這點我很買單。因為 AI 工具不是比第一次跑多漂亮，而是比第 50 次還能不能正常跑。

下面這個對比，很能看出差異。

• 單帳號方案：設定簡單，但容易把資料混在一起
• 多帳號獨立 server：設定較麻煩，但路由清楚
• 單一 OAuth token：維護快，但常見 re-auth 問題
• 分帳號授權：維護成本高一點，但比較不會串錯
• 傳統人工審信：最直覺，但最吃時間

如果你是開發者，這裡真正值得學的是邏輯，不是 Gmail 本身。任何有多來源資料的系統，都會遇到同樣問題。像客服信、付款通知、內部工單、甚至 Slack channel，都能套這種分流思路。

我也會提醒一件事。自動化不是把所有東西交給 AI。你要先定義邊界。哪個帳號能讀什麼，哪種信能進哪條流程，哪些結果要人工確認。邊界越清楚，系統越不容易失控。

這波其實是郵件工作方式在變

Gmail API 早就存在很久了。MCP 也不是什麼神秘新玩意。真正變的是，Claude Code 這類工具讓開發者可以直接把郵件接進工作流，而不用自己從頭寫一堆查詢、分類、排程和輸出格式。

這背後的產業脈絡很簡單。以前大家想做 email automation，通常得自己串 API、處理 token、寫 cron job。現在多了 MCP 這層，像是把工具接到同一個工作面板上。你不用每次都從零搭一套。

但這也不是說門檻消失了。相反地，門檻變成「你有沒有把資料邊界想清楚」。尤其是創作者、接案者、小團隊，常常同時有收入、合作、訂閱、客服四種信件。這時候，帳號結構本身就是流程設計。

再講白一點，郵件管理不是收件匣整理。它其實是在整理你的工作責任。誰要回、誰要存、誰要報帳、誰要追蹤，這些都跟資料結構有關，不只是跟 UI 有關。

我會怎麼看這件事

我覺得這篇文章最有價值的地方，不是它用了什麼酷工具，而是它把問題講對了。多帳號 Gmail 的難點，不是「能不能讀」。而是「能不能穩定地讀對」。

如果你現在也有 2 到 4 個 Gmail 帳號，我會建議你先做一件事：把帳號用途切乾淨。個人、工作、付款、訂閱，先分好，再談自動化。這樣你之後不管接 Claude、MCP，還是其他 LLM 工具，都比較不會亂。

我的預測很直接。接下來真正有用的 email AI，不會是最會聊天的那個，而是最會守規則的那個。誰能把帳號邊界、觸發條件、輸出格式定得最清楚，誰就能把郵件變成可控流程。你如果每天都在信箱裡打仗，這種工具就值得試。