n8n Google Calendar 預約 Agent 怎麼部署？2026 教學

2026 年 10 月 7 日 · AI Agent · 約 12 分鐘閱讀

這篇部署教學適合負責客戶預約流程的營運人員、n8n 開發者與自動化環境管理者。文章依照實作時間軸，說明如何限制 Agent 權限、連接測試日曆、處理時區和衝突、加入人工確認，並驗證執行結果與維護流程。

Google Calendar 的 events.insert 建立事件時，開始與結束時間是兩個必要欄位；因此，n8n Google Calendar 預約 Agent 應先把時間解析成明確值，再查詢可用時段，最後只在人工確認後建立事件，而不是直接授權 Agent 任意修改日曆。Google Calendar events.insert 欄位說明

這篇適合需要減少客戶預約來回確認的營運人員、負責 n8n 流程的開發者，以及評估自動化任務執行環境與憑證管理的技術負責人。

先界定預約 Agent 可以做什麼

預約流程出錯，通常不只因為節點設定不正確。自然語言的「下週下午」、未指定時長、跨時區參與者，或同一請求被重試，都可能讓流程做出錯誤判斷。若 Agent 同時可讀取多個私人日曆並任意修改、取消事件，影響範圍也會超出單一預約。

開始配置前，先把工作範圍寫成可驗收的條件：

讀取範圍：指定可查詢的日曆，不要讓工作流程以「全部可存取日曆」作為預設。
建立條件：確認請求包含參與者、日期、開始時間、時區、時長與事件標題；缺少必要資料時，要求補充，不要自行猜測。
操作限制：Agent 只負責讀取可用時段、提出候選時間；改期、取消或不明確的時間表達交由人工處理。
寫入門檻：使用者確認參與者與時間後才建立事件；確認前不得呼叫建立事件的操作。
資料留存：決定執行記錄可保存哪些預約資料、誰能檢視，以及失敗通知是否包含個人資訊。

Google OAuth 授權範圍決定應用程式能要求哪些資料存取權；設計時應挑選完成讀取與建立事件所需的範圍，而非為方便而擴大權限。Google OAuth 2.0 授權範圍說明

這類流程需要讓 Agent 自行取消或改期嗎？
若需求只是安排新會面，通常不需要。取消與改期會牽涉既有事件、參與者通知及誤操作復原，宜先交由人工確認，再另外設計流程，不要混進首次部署的寫入權限。

動手前準備測試日曆與驗收案例

先建立專用測試日曆，並使用虛構參與者與測試標題。這樣可以把授權、時間解析和事件寫入問題與實際客戶日程分開；流程通過測試後，再重新檢查目標日曆與授權範圍，才接入正式預約。

在打開 n8n 前，先列出要驗證的情況：

請求欄位齊全，且候選時段沒有重疊。
同一時段已存在事件，流程應提出其他時段，而非照常寫入。
請求只提供模糊日期或缺少時長，流程應停止並要求澄清。
請求者與日曆使用不同時區，顯示時間和實際事件時間應符合預期。
日曆權限不足或服務呼叫失敗時，流程應回報失敗，不可把「解析成功」當成「預約完成」。

提醒：測試日曆驗證的是流程行為，不代表正式日曆已有相同權限或設定。接入正式日曆前，應再次核對憑證所屬帳戶、目標日曆及可執行的操作。

第一階段：連接 n8n 與 Google Calendar

先查閱 n8n Google Calendar 節點的操作清單，確認目前文件列出的讀取、建立或更新操作，再依實際需求選擇節點動作。不要只憑舊版教學截圖設定，因為介面名稱、可用操作與授權流程可能隨文件更新。

接著依照 n8n Google OAuth2 憑證設定說明完成連線。授權完成後，先確認憑證連到預期帳戶，再用測試日曆執行一次讀取；讀不到目標日曆時，先處理帳戶或分享權限，不要直接進入寫入測試。

n8n Google Calendar 整合要如何避免測試時動到真實行程？
在流程的憑證與日曆選擇上明確指定測試日曆，使用虛構參與者及可辨識的測試標題。確認讀取結果來自測試日曆後，再測試建立事件；不要把真實客戶日曆當成初次連線的試跑資料。

第二階段：解析時間，再檢查衝突

Agent 收到文字請求後，先把內容整理成結構化資料：日期、開始時間、結束時間或時長、時區、參與者與標題。若時間資訊不足，流程應回到補問，而非自行採用伺服器時區或預設時長。這一步也要明確區分「使用者輸入的當地時間」與工作流程內部用來查詢的時間表示方式。

Google Calendar 事件包含時間與時區相關資訊，日曆本身也有時區設定；整合時應核對事件時間採用的時區，避免把參與者所在地時間誤當成日曆所在地時間。Google Calendar 事件與日曆時區說明

Google Calendar 自動預約如何處理時區？
先要求請求提供時區，或以已確認的參與者所在地作為解析依據，再將開始與結束時間連同時區送入查詢及建立事件的步驟。跨越夏令時間轉換的日期應特別測試；若時區不明或解析結果有歧義，先暫停寫入並要求確認。

接下來查詢候選時段是否忙碌。Google Calendar 的 FreeBusy API 可查詢指定時間範圍內的忙碌區間，適合用作建立前的檢查依據；查詢結果應與同一個目標日曆及解析後的時間範圍相符。Google Calendar FreeBusy 查詢說明

若查詢到重疊事件，流程應提出其他候選時間，或交由營運人員處理。若使用者送出的是重複預約，還要先釐清需求是建立一組重複事件，還是逐次確認後分別建立；Google Calendar 對重複事件有獨立的規則與事件表示方式，不宜把單次事件的處理直接套用到整組重複行程。Google Calendar 重複事件說明

第三階段：把人工確認放在寫入之前

衝突檢查通過後，先將待建立內容整理成確認訊息，至少顯示參與者、日期、開始與結束時間、時區、標題，以及所選日曆。使用者確認前，流程應停在等待或核准分支；只有收到明確確認，才呼叫建立事件的節點。

怎樣讓 AI 建立日曆事件前先經過人工確認？
將「產生候選內容」與「建立事件」分成兩個階段：第一階段送出可核對的預約摘要，第二階段只在收到確認後繼續。若使用者修改時間或參與者，應重新解析並再次檢查衝突，不能沿用舊查詢結果。

建立後，檢查節點回傳的事件識別資訊、日曆及時間欄位是否符合已確認內容。節點成功執行只表示呼叫有回應，不等於事件一定寫入預期日曆；應以建立結果與測試日曆中的實際事件互相核對。Google Calendar 建立事件 API 說明

首次試跑後的驗收與持續維護

將下列檢查逐項完成，再考慮接入正式預約流程：

[ ] 成功案例：測試日曆出現事件，回傳內容與已確認的參與者、標題及時間一致。
[ ] 衝突案例：候選時間重疊時，流程停止建立並回報可選的下一步。
[ ] 模糊請求：缺少日期、時區或時長時，流程要求補充，不自行補值。
[ ] 權限案例：憑證不能存取目標日曆時，流程回報錯誤，沒有誤寫入其他日曆。
[ ] 服務失敗案例：節點錯誤或逾時時，通知負責人並保留足以排查的執行記錄。
[ ] 重複觸發案例：同一預約請求再次執行時，先檢查是否已有對應事件，再決定是否建立，避免重試產生重複預約。
[ ] 憑證維護：記錄憑證負責人與更新流程；輪換或重新授權後，重新驗證讀取與建立操作。

n8n 的執行記錄可用於檢視流程成功或失敗的執行情況；發生問題時，應檢查是哪個節點失敗、輸入資料是否完整，以及是否需要人工重跑，而不是不加判斷地重複執行整條流程。n8n 執行記錄說明

AI Agent 部署教學中，為什麼要分開檢查解析和建立結果？
解析成功只代表流程把請求整理成可用欄位；它不代表衝突查詢通過、授權有效，或事件已寫入。驗收記錄應分別標示解析、查詢、人工核准與建立結果，出錯時才能知道要補資料、重新授權，還是檢查寫入操作。

若要進一步整理日曆授權及憑證的作業方式，可先參考 nuvcloud 使用說明；需要查看帳戶與服務管理入口時，則可由 nuvcloud 控制中心了解相關使用流程。

對只處理 Google Calendar API 的自動化，現有雲端工作流程環境通常更直接；若執行流程還依賴 macOS 專用工具或本機應用程式，則要另外評估環境是否支援、檔案是否持續保留，以及憑證如何安全交接。自管設備也有維護、長時間運作與更新責任，不適合每個工作負載。若預約 Agent 同時需要 macOS 測試或相關工具環境，可對照 nuvcloud 雲端 Mac 使用情境，再判斷是否需要租用；若只需執行一般日曆流程，則不必為此額外引入 Mac。