第 31 章・串接外部服務篇

串接 Gmail：AI 郵件助手

前面三十章，AI 都在 Dify 裡「說話」。這一章讓它真的動手做事——把工作流接上你的 Gmail：填幾個要點，AI 擴寫成一封得體的信，然後直接從你的信箱寄出去。這是「串接外部服務」的第一課，重點有兩個：怎麼完成 Google OAuth 授權，以及怎麼在工作流裡用 Gmail 工具。

業界痛點
職場每天都在寫重複性的信：會議確認、報價跟進、通知提醒、客服回覆。內容八成是套路，卻還是要一封封親手打、找收件人、寄出。更麻煩的是——AI 就算幫你寫好了，你還是得複製貼上到信箱再寄。如果能讓工作流「寫完直接寄」，把整條龍打通，就能把大量的郵件雜務自動化，人只需要在需要判斷時介入。

本章目標

解決什麼
填收件人與要點，AI 擴寫成完整信件並直接透過你的 Gmail 寄出
用到的技術
Gmail 外掛（OAuth 授權）＋工作流的 Gmail 工具節點；開始 → LLM → Gmail → 輸出
難度
★★★★☆　第一次讓 Dify 連上你自己的外部帳號、真的執行對外動作
✨ 成果搶先看

先看做完長什麼樣——填三格、按執行，一封 AI 寫好的信就從你的 Gmail 寄出去了：

① 使用者填寫的欄位
收件人：someone@example.com
主旨：關於下週會議時間確認
內容要點：想跟對方確認下週三下午2點的會議是否方便，地點在公司會議室，議題是專案進度，請對方回覆確認。
↓　AI 處理，產出 ↓

AI 依「要點」擴寫、並透過 Gmail 寄出的信：

您好：

冒昧來信打擾，希望您一切順利。

想與您確認下週三（__月__日）下午 2 點的會議時間是否方便，地點預計安排在公司會議室，主要議題為專案進度討論，屆時將與您一同檢視目前的執行狀況並討論後續規劃。

若上述時間與地點皆無問題，麻煩您回覆確認；若有任何時間衝突或需要調整之處，也請不吝告知，我會盡快協調安排。

感謝您撥冗確認，期待與您於會議中討論。

祝順心

使用者只填「收件人／主旨／要點」三格，AI 就擴寫成完整信件並直接從你的 Gmail 寄出（回傳 Email sent successfully!）。

👇 在 Dify 裡實際執行、長這樣

執行結果：AI 撰寫的會議確認信，最後顯示 Email sent successfully
成品輸入「收件人、主旨、要點」後，AI 把要點擴寫成一封得體的會議確認信，最後回傳 Email sent successfully!——信已經真的寄出，對方的收件匣就會收到。
效益速覽（估算）
省時間
寫信＋寄出→秒完成
要點擴寫、一鍵送出
省人力
例行信件自動化
人只在需判斷時介入
創造價值
AI 真的動手做事
從「會說」到「會做」
⬇ 把這個工作流帶走，直接用
下載本章 DSL，到你的 Dify「匯入 DSL 檔案」即可複製這個範例。注意：匯入後要在你自己的工作區完成 Gmail 授權（見下方 31.1），Gmail 節點才能寄信。
下載 DSL 檔

31.1前置：完成 Gmail 的 Google OAuth 授權

要讓 Dify 用「你的」Gmail 帳號寄信，得先完成 Google 的 OAuth 授權。自架的 Dify 沒有內建可用的 Google 用戶端，所以你要自己建一組 Google Cloud OAuth 用戶端填進 Dify。一次設定，之後所有 Gmail 節點都能用。

31.1.1在 Google Cloud Console 建 OAuth 用戶端

  1. 啟用 Gmail API到 console.cloud.google.com 建立（或選）一個專案 → 在「API 和服務 → 程式庫」搜尋並啟用 Gmail API。（這步常被漏掉，漏了會授權成功卻收不到權限。）
  2. 設定 OAuth 同意畫面User Type 選「外部」，填應用名稱與支援信箱；在「測試使用者」加入你要用來寄信的 Google 帳號——這一步是關鍵，未驗證的應用只有測試使用者能授權，否則會被 Google 擋下（Access blocked）。
  3. 建立 OAuth 用戶端 ID「憑證 → 建立憑證 → OAuth 用戶端 ID」，類型選「網頁應用程式」。
    ・已授權的 JavaScript 來源：http://localhost
    ・已授權的重新導向 URI（一字不差）：
    http://localhost/console/api/oauth/plugin/langgenius/dify-gmail/dify-gmail/tool/callback
  4. 複製憑證建立後把 Client ID 與 Client Secret 複製下來。
務必注意
重新導向 URI 必須是上面那條完整路徑（不是 http://localhost/）。另外你的 Dify 需設定 CONSOLE_API_URL（如 http://localhost），OAuth 才組得出正確的絕對回呼網址；若是用官方 docker-compose，記得在 .env 設好並重啟。

31.1.2在 Dify 填入用戶端並授權

  1. 填自訂 OAuth 用戶端Dify →「Integrations（整合）→ Tools」→ 點 Gmail → 在「自訂 OAuth 用戶端」貼上剛剛的 Client ID 與 Client Secret → 儲存。這一步讓 Dify 改用你的用戶端。
  2. 授權點「授權 / Authorize」→ 用你設為測試使用者的 Google 帳號登入 → 若跳「未驗證」畫面就點「繼續（前往，不安全）」→ 完成。
Gmail 寄送工具節點設定：工作區授權、To/Subject/Body 對應變數
圖 31-1授權成功後，Gmail 工具就能用了。上圖是後面要用的 Gmail 節點——右上顯示「工作區默認」（綠點，代表已授權），下方把 To／Subject／Body 對應到流程變數。授權好了，這個節點才寄得出信。

31.2逐節點：四個節點怎麼設

授權完成後，建一個「工作流」應用，串四個節點：開始 → 撰寫郵件內文（LLM）→ Gmail 寄送 → 輸出。

AI 郵件助手工作流：開始 → LLM → Gmail 寄送 → 輸出
圖 31-2四節點全貌。開始收表單、LLM 寫內文、Gmail 節點寄出、輸出回傳結果——AI 從「會寫」到「會寄」，就差中間那個 Gmail 工具節點。

31.2.1節點①「開始」：收件人、主旨、要點

開始節點設三個輸入欄位：to（收件人信箱，短文字）、subject（郵件主旨，短文字）、points（內容要點，段落——使用者只要條列幾句，AI 會擴寫）。

開始節點：to、subject、points 三個輸入欄位
圖 31-3　開始節點三個欄位就是使用者要填的表單：收件人、主旨、要點。

31.2.2節點②「撰寫郵件內文」LLM：把要點擴寫成信

LLM 節點的提示詞用 {{#開始.subject#}} 與 {{#開始.points#}} 帶入主旨與要點，要求它寫出得體、完整的繁體中文信件內文（開頭稱呼、正文有禮、結尾署名留空），並下規則「只輸出內文、不要冗長」。

LLM 節點：依主旨與要點撰寫信件內文
圖 31-4　撰寫郵件內文 LLM系統提示詞引用開始節點的主旨與要點，把幾句要點擴寫成一封完整的信。輸出變數 text 就是信件內文。

31.2.3節點③「Gmail 寄送」：真的把信寄出去

新增一個 Gmail 工具節點，選 Send Gmail Message。三個必填參數對應變數：To ← {{#開始.to#}}、Subject ← {{#開始.subject#}}、Email Body ← {{#撰寫郵件內文.text#}}（CC／BCC／Reply-To 選填）。右上的授權選「工作區默認」用剛授權好的帳號。設定面板見上方圖 31-1。

31.3執行：一封信真的寄出

發布後執行，填收件人、主旨、要點（例如「跟對方確認下週三下午 2 點的會議」）。工作流跑完，Gmail 節點回傳 Email sent successfully!，對方的收件匣立刻收到這封 AI 寫的信（見章首圖）。從輸入到寄達，全程幾秒、零複製貼上。

帶來的改變
AI 從「幫你寫好、你自己去寄」升級成「寫完直接寄」；例行郵件（會議確認、跟進、通知）真正自動化。再往前一步：把這個工作流接上第 9 章的 API，讓你的系統在特定事件時自動呼叫它寄信；或接上排程觸發，定時寄出報表通知。
務必注意
寄信是真的對外送出的動作，測試時建議先寄給自己，確認內容與收件人無誤再對外使用。正式流程可加一個「人工確認」關卡（例如先產草稿 draft_message、由人看過再 send_draft 寄出），避免自動寄錯。Gmail 授權綁的是你個人帳號，寄件者就是你，請留意用途與頻率。

31.4延伸：其他外部服務也是同套路

輸出、發布與使用：把成果交付出去

做好的應用要能發布、分享給別人用才有價值。以下是這個應用的輸出設定與發布／使用畫面：

發佈選單
發佈選單做好後按右上「發佈 → 發布更新」即上線；選單還提供『運行』獨立網頁、『訪問 API』、『嵌入網站』與『工作流程作為工具』等交付方式——這就是把應用分享給別人使用的入口。

31.5本章回顧