AI 代理電子郵件自動化：建立能分類、起草和追蹤的 Gmail/Outlook 代理——無需程式碼

沒有人解決的電子郵件問題

你有 147 封未讀電子郵件。32 封是昨晚到的。9 封今天需要回覆。其中 2 封真的很緊急，但它們被埋在電子報、自動通知、你因「提高能見度」而被加入的副本郵件串，以及一個關於午餐計劃的「回覆所有人」串中。

這不過是普通的星期二。

一般專業人士每天花費28% 的工作時間管理電子郵件——每天大約 2.5 小時用於閱讀、整理、回覆和追蹤。儘管生產力工具、Gmail 篩選器、Outlook 規則和「清空收件匣」方法論大爆炸，這個數字在十年內幾乎沒有改變。原因很簡單：傳統電子郵件自動化是基於規則的，而人類溝通不是。篩選器可以將電子報移到資料夾，但它無法讀取來自你最大客戶的四段訊息、理解隱含的截止日期、起草適當的回覆，並在他們星期四前沒有回覆時提醒你追蹤。

AI 電子郵件代理可以做到。

本指南涵蓋你建立真正有效的電子郵件自動化系統所需的一切——一個能智慧分類收件匣、起草情境回覆，並跨 Gmail、Outlook 或兩者管理追蹤排程的系統。不需要程式設計。我們將介紹架構、特定工作流程、Gmail 和 Outlook 整合的差異，以及工作區範本如何將這一切打包成你可以在一個下午部署的東西。

AI 電子郵件代理實際上做什麼

在深入設定之前，讓我們定義我們要建立什麼。AI 電子郵件代理不是更智慧的垃圾郵件篩選器或預定回覆機器人。它是一個持續執行三個核心功能的自主系統：

1. 智慧分類

代理讀取每封傳入的電子郵件，按類別和緊急程度分類，並顯示重要的內容。與匹配關鍵字的靜態規則不同，代理能理解情境。它知道副總裁發來的「你能在今天下班前發送更新後的數據嗎？」是緊急的，即使它不包含驚嘆號或「緊急」主旨標籤。

分類類別通常包括：

優先級	類別	範例	代理行動
P0 — 緊急	影響收益，今天截止	今天到期的客戶合約問題	立即通知 + 起草回覆
P1 — 高	需在 24 小時內回覆	主管要求專案更新	排入起草回覆佇列 + 標記
P2 — 正常	資訊性，有空時回覆	同事分享會議記錄	摘要 + 歸檔
P3 — 低	不需要回覆	電子報、自動通知	封存或資料夾排序
P4 — 雜訊	垃圾郵件、促銷、無關副本	行銷電子郵件、回覆所有人串	自動封存

代理使用基於規則的訊號（發件人白名單、網域模式、主旨關鍵字）和大語言模型推理（讀取實際訊息正文以評估意圖和緊急性）的組合來應用這些類別。結果是將優先排序的收件匣摘要傳送到你偏好的頻道——Slack、Telegram 或每日摘要電子郵件——讓你每天都清楚知道什麼需要注意。

2. 情境回覆起草

對於需要回覆的訊息，代理起草符合你寫作風格、語氣和對話情境的回覆。這遠超過範本回應。代理：

讀取完整的電子郵件串，不只是最新訊息
引用與同一發件人的相關先前對話
匹配你的溝通風格（對客戶正式，對隊友輕鬆）
包含訊息正文中的具體細節（「關於你提到的第二季預測……」）
尊重組織情境（知道誰是你的主管，你在做哪些專案）

起草的回覆在審核佇列中等待。你閱讀草稿，如需要做少量編輯後批准——或拒絕並自己撰寫。隨著時間推移，代理從你的編輯中學習你的偏好，草稿變得更好，你的編輯率下降。

3. 追蹤排程

最隱伏的電子郵件問題不是傳入的訊息——而是你發出但從未收到回覆的那些。你上週二發送的提案。你轉發給會計的發票。雙方都沉默下去的介紹電子郵件。

AI 電子郵件代理追蹤傳出訊息並排程自動追蹤：

基於時間： 如果 3 個工作日內沒有回覆，起草追蹤訊息
條件式： 如果收件人在 48 小時內開啟了電子郵件但沒有回覆，輕輕地提醒
升級： 如果兩次追蹤都沒有回應，標記為人工介入或建議替代頻道

追蹤草稿是情境感知的。它們引用原始訊息、承認已過去的時間，並相應地調整語氣。第一次追蹤是禮貌的問候；第二次更直接；第三次建議電話或替代方案。

電子郵件自動化工作流程：端到端

以下是從電子郵件到達到追蹤發出的完整工作流程如何運作：

傳入電子郵件
      |
      v
[1. 擷取] ---- Gmail API / Microsoft Graph API ---- 輪詢或 Webhook
      |
      v
[2. 解析] ---- 提取發件人、主旨、正文、附件、對話情境
      |
      v
[3. 分類] ---- 大語言模型分類：優先級、類別、所需行動
      |
      +---> P3/P4：自動封存、資料夾排序、不通知
      |
      +---> P2：摘要、歸檔、納入每日摘要
      |
      +---> P0/P1：起草回覆 + 立即通知
                |
                v
[4. 起草] ---- 使用對話歷史 + 風格模型生成情境回覆
                |
                v
[5. 審核佇列] ---- 人工批准、編輯或拒絕
                |
                v
[6. 發送] ---- 透過電子郵件 API 傳遞，如已連接則記錄到 CRM
                |
                v
[7. 追蹤追蹤器] ---- 監控回覆，如需要則排程追蹤
                |
                v
[8. 追蹤草稿] ---- 在設定的間隔發送情境感知追蹤
                |
                v
          [回到步驟 5：審核佇列]

每個步驟由工作區範本中的特定元件處理。關鍵設計原則：人類在發送時保持參與，而代理自主處理其他一切。 讀取、分類、起草、追蹤和排程全部自動化。唯一需要你注意的是對傳出訊息的是/否批准。

Gmail vs Outlook：AI 代理的 API 比較

Gmail 和 Outlook 都可以作為你 AI 代理的電子郵件後端，但它們在設定複雜度、功能可用性和持續維護方面有意義的差異。

Gmail（Google Workspace / 個人 Gmail）

API： Gmail API（RESTful，Google Cloud Platform 的一部分）

認證： OAuth 2.0 配合 Google Cloud Console 專案。需要建立 GCP 專案、啟用 Gmail API、設定 OAuth 同意書面，以及生成客戶端憑證。

AI 代理的主要能力：

推播通知： Gmail 透過 users.watch() 支援 Cloud Pub/Sub 推播通知，這意味著你的代理可以在新訊息到達時接收近即時警報，而不是輪詢。這將延遲從幾分鐘縮短到幾秒鐘。
標籤管理： Gmail 的標籤系統靈活，允許代理為分類類別建立自訂標籤（例如 AI/Urgent、AI/NeedsReply、AI/FollowUp）。標籤是非破壞性的，不會將訊息移出收件匣，除非你這樣設定。
對話串模型： Gmail 自動將相關訊息分組為對話串，讓代理透過單個 API 呼叫輕鬆擷取完整的對話情境。
批次操作： Gmail API 支援批次請求，允許代理在單個 HTTP 呼叫中擷取、標記和修改多條訊息。

限制：

Google 的 OAuth 同意書面審核流程對於請求電子郵件存取等「敏感」範圍的應用程式可能需要數週時間。對於個人使用，你可以在最多 100 個測試用戶的「測試」模式下執行，對於單用戶代理來說這就夠了。
速率限制：每個用戶每秒 250 個配額單位，不同操作消耗不同的單位數量。實際上，對於單用戶代理來說很寬鬆，但對於多帳號設定需要節流。

你需要的範圍：

範圍	目的
`gmail.readonly`	讀取電子郵件進行分類（如果你只需要分類 + 起草而不自動發送，使用此範圍）
`gmail.modify`	讀取 + 標記 + 封存（加入此範圍以實現完整分類自動化）
`gmail.send`	發送電子郵件（只有在你希望代理發送已批准草稿時才加入）
`gmail.compose`	建立草稿（加入此範圍以實現審核佇列工作流程）

Outlook（Microsoft 365 / 個人 Outlook.com）

API： Microsoft Graph API（RESTful，所有 Microsoft 365 服務的統一端點）

認證： OAuth 2.0 配合 Azure Active Directory 應用程式註冊。需要 Azure AD 租戶、具有郵件權限的應用程式註冊，以及組織帳號的管理員同意。

AI 代理的主要能力：

Webhook 訂閱： Microsoft Graph 支援新訊息的變更通知（Webhook），提供類似 Gmail Pub/Sub 的推播更新。訂閱必須每 3 天更新一次（最大生命週期）。
類別系統： Outlook 使用顏色編碼的類別，可以很好地對應到分類優先級。代理可以以程式設計方式分配類別。
資料夾管理： 與 Gmail 的標籤系統不同，Outlook 使用傳統的資料夾層次結構。代理可以建立和管理像 AI Triage/Urgent 這樣的資料夾並相應移動訊息。
豐富篩選： Graph API 支援伺服器端篩選的 OData 查詢參數，減少傳輸的資料量。代理可以只請求特定發件人的未讀訊息。

限制：

每 3 天更新一次的 Webhook 訂閱增加了操作複雜性。代理需要後台任務在訂閱到期前更新它們。
Azure AD 應用程式註冊和管理員同意可能比 Google 的設定更複雜，特別是在 IT 控制 Azure AD 政策的企業環境中。
節流限制是按每個應用程式和租戶計算的，對於大量操作比 Gmail 限制更嚴格。

你需要的權限：

權限	目的
`Mail.Read`	讀取電子郵件進行分類
`Mail.ReadWrite`	讀取 + 分類 + 移到資料夾
`Mail.Send`	透過代理發送電子郵件

頭對頭摘要

功能	Gmail API	Microsoft Graph API
推播通知	Cloud Pub/Sub（可靠，無需更新）	Webhook（每 3 天更新一次）
訊息分組	原生對話串	對話 ID（可靠性較低）
整理方式	標籤（每條訊息可多個）	資料夾（每條訊息一個）+ 類別
認證複雜性	中等（GCP 專案 + OAuth）	較高（Azure AD + 管理員同意）
速率限制	每用戶較寬鬆	每應用程式/租戶較嚴格
附件處理	訊息酬載中的 Base64	獨立的附件端點
最適合	個人/小團隊代理	企業/大型組織環境

實際要點： 如果你有選擇，Gmail 的 API 對於 AI 代理來說稍微容易處理，因為它有原生對話串、持久推播通知和更簡單的認證。如果你的組織在 Microsoft 365 上運行，Graph API 完全可用——只是需要更多 Webhook 更新和 Azure AD 設定的操作開銷。

電子郵件自動化工作區範本包含什麼

工作區範本將整個電子郵件代理打包成可部署的設定。你不必從頭建立每個元件，而是獲得一個預先連接的系統，其中分類規則、起草提示、追蹤排程和 API 連接已經結構化並測試過。

以下是設計良好的電子郵件自動化工作區範本通常包含的內容：

核心代理設定

代理的系統提示定義其個性、角色邊界和行為規則。對於電子郵件代理，這包括：

身份和範圍： 「你是電子郵件管理助理。你讀取、分類並起草電子郵件回覆。未經明確人工批准，你絕不發送電子郵件。」
分類規則： 優先級定義、VIP 發件人清單、關鍵字升級模式和類別分類。
起草指導原則： 每種收件人類型的語氣偏好、簽名格式、最大回覆長度，以及代理不應自主處理的主題（法律、人資、財務承諾）。
追蹤政策： 預設追蹤間隔、最大追蹤次數、升級規則，以及封鎖期（週末/假日不追蹤）。

技能和整合

技能是代理的工具——它可以調用以與外部系統互動的特定能力。電子郵件工作區範本通常包括：

電子郵件讀取技能： 連接到 Gmail API 或 Microsoft Graph API，擷取新訊息，獲取對話串歷史。
電子郵件發送技能： 透過電子郵件 API 發送已批准的草稿。需要明確調用（代理在未批准的情況下無法呼叫此功能）。
行事曆技能： 查看你的行事曆以獲取排程情境（因此代理在回覆草稿中建議會議時間時知道你星期四下午有空）。
CRM 技能（可選）： 將電子郵件互動記錄到你的 CRM，查找聯絡人歷史，並用關係情境豐富分類。
通知技能： 將分類摘要和批准請求發送到 Slack、Telegram 或另一個訊息頻道。

分類規則引擎

分類設定是大多數客製化發生的地方。範本提供合理的預設值，你隨時間調整：

triage:
  vip_senders:
    - "*@yourcompany.com"
    - "ceo@importantclient.com"
    - "billing@vendor.com"

  priority_rules:
    - condition: "sender in vip_senders AND body contains deadline language"
      priority: P0
      action: "notify_immediate + draft_reply"

    - condition: "sender in vip_senders"
      priority: P1
      action: "draft_reply + flag"

    - condition: "is_newsletter OR is_automated_notification"
      priority: P4
      action: "auto_archive"

    - condition: "recipient is CC (not TO)"
      priority: P3
      action: "summarize + digest"

  digest:
    schedule: "08:00 weekdays"
    channel: "slack"
    include_priorities: [P1, P2]
    format: "summary_with_draft_links"

追蹤追蹤器設定

followup:
  default_interval: "3 business days"
  max_attempts: 3
  escalation_after: 2

  intervals:
    - attempt: 1
      delay: "3 business days"
      tone: "polite_checkin"
    - attempt: 2
      delay: "5 business days"
      tone: "direct_reminder"
    - attempt: 3
      delay: "7 business days"
      tone: "suggest_alternative_channel"

  excluded_categories:
    - "newsletter"
    - "automated_notification"
    - "internal_fyi"

  blackout:
    days: ["Saturday", "Sunday"]
    hours_before: 8
    hours_after: 18

記憶和情境

工作區範本設定代理跨會話記住的內容：

發件人檔案： 溝通歷史、偏好語氣、典型回應時間和關係情境。
草稿回饋迴路： 當你在批准前編輯草稿時，代理記錄其草稿和你最終版本之間的差異，隨時間學習你的偏好。
分類更正： 當你重新排定代理分類錯誤的訊息優先級時，更正會訓練未來的分類。

這種持久記憶將 AI 電子郵件代理與無狀態電子郵件篩選器區分開來。代理使用得越多就越好，因為每次更正都能精煉它對你工作方式的模型。

設定你的電子郵件代理：逐步說明

步驟 1：選擇你的部署路徑

你有兩個選項：

自行託管 OpenClaw： 在你自己的伺服器上安裝 OpenClaw，手動設定電子郵件技能，並自行管理基礎設施。費用較低（VPS 每月 $6-$48），完全控制，但需要對 API 憑證、YAML 設定和伺服器維護有技術能力。

使用工作區範本的托管服務： 使用像 ClawAgora 這樣的平台，提供預建電子郵件自動化範本並處理基礎設施。每月費用較高，但你完全跳過伺服器設定，從可用的設定開始而不是空白起點。

無論哪種方式，工作流程都是一樣的——差異在於你自己做多少設定，以及有多少是預設配置好的。

步驟 2：連接你的電子郵件帳號

對於 Gmail：

建立 Google Cloud Platform 專案（或使用現有的）
在 API 庫中啟用 Gmail API
設定 OAuth 同意書面（個人使用選「外部」，Google Workspace 選「內部」）
建立 OAuth 2.0 客戶端憑證（自行託管選桌面應用程式類型，托管服務選網頁應用程式）
執行 OAuth 流程以生成更新令牌
將憑證新增到你的 OpenClaw 電子郵件技能設定

對於 Outlook：

在 Azure Active Directory 中註冊應用程式
新增 Mail.Read 和 Mail.Send（如需要）API 權限
授予管理員同意（組織帳號需要）
生成客戶端密鑰或憑證
執行 OAuth 流程以獲取令牌
將憑證新增到你的 OpenClaw 電子郵件技能設定

如果你使用來自社群市場的工作區範本，大部分這些都有引導——範本包含針對每個電子郵件提供商的特定設定說明，而一些托管平台透過網頁 UI 處理 OAuth 流程。

步驟 3：設定你的分類規則

從範本的預設值開始，立即自訂三件事：

VIP 發件人： 新增那些訊息應該始終顯示為高優先級的人的電子郵件地址——你的主管、關鍵客戶、重要供應商。
雜訊來源： 識別應該自動封存的發件人和模式——你從不閱讀的電子報、自動構建通知、行銷電子郵件。
通知頻道： 設定你希望分類摘要傳送到哪裡。Slack 和 Telegram 是即時通知最常見的選擇。電子郵件摘要適合你偏好將一切保持在同一個地方的情況。

步驟 4：訓練起草風格

代理需要你寫作的範例來匹配你的語氣。大多數範本以兩種方式之一處理：

範例庫： 你提供 10-20 個你在不同情境下寫的電子郵件範例（客戶回覆、內部更新、會議排程、追蹤）。代理使用這些作為風格參考。
透過更正學習： 你立即開始使用代理。當它起草回覆時，你在批准前將其編輯為你偏好的風格。幾十次更正後，代理的草稿將接近你的聲音。

第二種方法更快開始且長期更準確。第一種方法從第一天起提供更好的初始草稿。

步驟 5：設定追蹤政策

設定哪些傳出電子郵件應該追蹤：

始終追蹤： 發給外部收件人的電子郵件、提案、發票、行動請求
絕不追蹤： 內部通知、電子報訂閱、自動系統回覆
自訂規則： 追蹤發給特定網域或具有特定主旨模式的電子郵件

設定你偏好的追蹤間隔。第一次追蹤三個工作日是合理的預設值。兩次追蹤後升級可防止騷擾，同時確保沒有事情被遺漏。

步驟 6：在唯讀模式下測試

在啟用任何發送能力之前，以唯讀模式執行代理一到兩週。在此期間，代理：

分類每封傳入的電子郵件並向你發送分類摘要
起草回覆但只在本地儲存（不排入發送佇列）
追蹤傳出電子郵件並生成追蹤建議，但不實際發送

這個測試期讓你在沒有代理發送你不打算發送的東西的風險下評估分類準確性、草稿品質和追蹤時機。每天審核代理的決定並提供更正。兩週結束時，你將對系統的判斷有很高的信心——或者你將清楚了解需要調整哪些規則。

常見陷阱及如何避免

第一天過度自動化

誘惑是立即打開自動發送並完全自動化收件匣。不要這樣做。先只做分類。一週後添加起草。兩週後啟用排入佇列的發送。一個月後開啟追蹤自動化。每個層次都建立在前一個層次確立的信任基礎上。

忽視回饋迴路

如果你編輯草稿並批准它，但代理沒有記錄更正，你做了工作卻沒有獲得長期好處。確保你的工作區範本捕捉草稿 vs 已發送的差異，這樣代理隨時間改進。來自社群庫的範本通常預設包含此回饋機制。

使用過於廣泛的 OAuth 範圍

請求你的工作流程需要的最小權限。如果你只需要分類，使用 gmail.readonly 或 Mail.Read。在準備好使用之前不要請求發送權限。這在你的憑證被洩露時限制曝露。

忘記對話串情境

不讀取完整對話串而回應個別訊息的代理會產生令人尷尬的草稿。確保你的電子郵件技能在生成回覆之前擷取完整的對話串。Gmail 的原生對話串讓這很簡單；Outlook 需要明確的對話 ID 查詢。

不設定封鎖期

在星期六凌晨 2 點發送的追蹤電子郵件讓你看起來像機器人（因為你是一個）。設定辦公時間和假日行事曆，讓追蹤只在適當的時間視窗內發送。

超越單一收件匣的擴展

一旦你的電子郵件代理在一個帳號上順利運行，自然的下一步是擴展：

多個電子郵件帳號： 將你的個人 Gmail 和工作 Outlook 連接到同一個代理。代理對每個帳號應用不同的分類規則和起草風格，但在統一的優先級視圖中顯示所有內容。

團隊部署： 在你的團隊中分享工作區範本。每個人連接自己的電子郵件帳號，但分類分類法、起草指導原則和追蹤政策是標準化的。這對面向客戶的團隊特別有價值，因為一致的回應品質很重要。

CRM 整合： 將電子郵件代理連接到你的 CRM，讓每次客戶互動都自動記錄。代理用 CRM 資料豐富其分類——來自你銷售管道中的潛在客戶的訊息獲得與不在你系統中的人發送的相同訊息不同的優先級。

跨頻道協調： 將電子郵件代理與你的行事曆、任務管理和訊息代理連接。當客戶發送電子郵件要求會議時，代理查看你的行事曆，在草稿中建議可用時間，並在兩天內未確認排程時建立追蹤任務。

支援這些擴展的工作區範本可以在像 ClawAgora 這樣的社群市場中找到，開發者在那裡分享特定整合和使用案例的設定。

為什麼工作區範本優於自己動手設定

你可以從頭建立所有這些。安裝 OpenClaw、寫系統提示、個別設定每個技能、手動設定分類規則，並自行測試一切。它有效。但需要 20-40 小時的設定和迭代。

電子郵件自動化工作區範本將這壓縮到一個下午。以下是你獲得的：

預測試的分類規則，能立即處理 80% 的情況（電子報、通知、副本串、直接請求）
起草提示，經過社群回饋精煉，產生自然、非機器人式的回覆
追蹤排程，根據專業規範校準（不太積極，不太消極）
安全預設值，從唯讀存取開始，啟用批准閘道，並使用窄 OAuth 範圍
升級路徑，帶有 CRM 整合、行事曆協調和多帳號支援的可選模組

範本是起點，不是天花板。你自訂一切——但你從可用的系統而不是空白設定檔案開始。

常見問題

AI 電子郵件代理可以同時處理 Gmail 和 Outlook 嗎？

可以。OpenClaw 工作區範本可以透過各自的 API（Gmail API 和 Microsoft Graph API）同時連接多個電子郵件提供商。代理將每個信箱視為輸入頻道，並在兩者中應用相同的分類規則、起草邏輯和追蹤排程。這對於管理個人 Gmail 和企業 Outlook 帳號的專業人士特別有用。

AI 電子郵件代理會在未經我批准的情況下發送訊息嗎？

除非你明確允許，否則不會。設計良好的電子郵件自動化工作區範本預設包含人工審核閘道。代理起草回覆並排入待審佇列，在發送前供你審核。隨著時間增進對代理判斷的信任，你可以選擇性地為低風險類別（如會議確認或自動回覆）啟用自動發送，同時對客戶往來或財務相關信件保持人工審核。

電子郵件分類 AI 如何判斷什麼是緊急的？

電子郵件分類代理使用基於規則的訊號和大語言模型推理的組合。基於規則的訊號包括發件人 VIP 清單、主旨關鍵字、副本 vs 直接收件模式，以及「EOD」或「ASAP」等時效性標記。大語言模型層讀取完整的電子郵件正文來評估情境緊急性——例如，即使訊息中沒有明顯的關鍵字觸發，也能識別出關於合約截止日期的訊息是緊急的。你在工作區範本的分類規則中設定優先級層次和標準。

我應該從哪個電子郵件自動化工作區範本開始？

從通用電子郵件分類和起草範本開始。這些涵蓋最高影響力的工作流程——收件匣分類、優先事項顯示和回覆起草——而不需要連接電子郵件帳號以外的複雜整合設定。基本分類運行後，你可以將追蹤排程和 CRM 同步作為獨立模組加入。像 ClawAgora 這樣的社群市場提供預設配置這些元件的範本。

讓 AI 代理存取我的電子郵件安全嗎？

安全性取決於你的部署模型。自行託管的 OpenClaw 執行個體將所有電子郵件資料保留在你自己的基礎設施上——沒有任何東西離開你的伺服器。托管服務提供商應提供靜態加密、隔離運算環境，以及不儲存你電子郵件密碼的 OAuth 存取。使用最窄的 OAuth 範圍（只需分類時用唯讀，只需自動發送時才用讀寫），啟用審核閘道，並在部署前審核工作區範本的技能設定。來自社群市場的經過審查範本包含安全性文件，讓你可以確切審核請求了哪些權限。

尋找預建電子郵件自動化工作區？瀏覽 ClawAgora 社群範本，尋找準備好連接到你的 Gmail 或 Outlook 帳號的電子郵件分類、起草和追蹤設定。

相關閱讀： 有關將代理連接到電子郵件旁邊的 Google Drive 的說明，請參閱 AI 代理 Google Drive 文件存取。有關在外出途中透過 Telegram 語音委派電子郵件任務，請閱讀透過 Telegram 語音優先 AI 代理委派。