電子郵件是世界上最易於使用的介面。它無處不在。無需客製化的聊天應用程式，也無需為每個管道提供客製化的 SDK。每個人都已經擁有電子郵件地址，這意味著每個人都能與您的應用程式或代理程式互動。而您的代理程式也能與任何人互動。
如果您正在建構應用程式，您已經依賴電子郵件進行註冊、通知和發票。越來越多時候，不僅是您的應用程式邏輯需要這個管道。您的代理程式也需要。在我們的私人測試期間，我們與開發者交流，他們正在建構這些應用程式：客戶支援代理程式、發票處理流程、帳戶驗證流程、多代理程式工作流程。所有這些都建構在電子郵件之上。模式很清晰：電子郵件正成為代理程式的核心介面，而開發者需要專為此目的打造的基礎設施。
Cloudflare 電子郵件服務就是這個解決方案。透過電子郵件路由 (Email Routing)，您可以接收電子郵件到您的應用程式或代理程式。透過電子郵件發送 (Email Sending)，您可以回覆電子郵件或發送出站郵件，在您的代理程式完成工作時通知使用者。結合我們開發者平台的其他功能，您可以將電子郵件掛鉤 (onEmail hook) 作為原生功能，建構完整的電子郵件客戶端和代理程式 SDK。
今天，作為代理程式週 (Agents Week) 的一部分，Cloudflare 電子郵件服務進入公開測試，讓任何應用程式和任何代理程式都能發送電子郵件。我們也完成了建構電子郵件原生代理程式的工具包：
電子郵件發送功能今天從私人測試畢業進入公開測試。您現在可以直接從 Workers 發送交易性電子郵件，使用原生的 Workers 綁定 — 無需 API 金鑰，無需秘密管理。
或者使用 REST API 和我們的 TypeScript、Python 和 Go SDK 從任何平台、任何語言發送：
發送實際上能到達收件匣的電子郵件，通常意味著要處理 SPF、DKIM 和 DMARC 記錄。當您將網域添加到電子郵件服務時，我們會自動配置所有這些。您的電子郵件經過驗證並成功送達，不會被標記為垃圾郵件。而且由於電子郵件服務是建構在 Cloudflare 網路上的全球服務，您的電子郵件將以低延遲送達世界各地。
結合免費且已推出多年的電子郵件路由功能，您現在可以在單一平台上實現完整的雙向電子郵件通訊。接收電子郵件，在 Worker 中處理，然後回覆，所有這些都不離開 Cloudflare。
如需深入了解電子郵件發送的詳細資訊，請參閱我們的週年慶公告。本文的其餘部分將介紹電子郵件服務為代理程式帶來的可能性。
用於在 Cloudflare 上建構代理程式的代理程式 SDK，已經有一個一流的 onEmail 掛鉤，用於接收和處理入站電子郵件。但到目前為止，您的代理程式只能同步回覆，或向您的 Cloudflare 帳戶成員發送電子郵件。
有了電子郵件發送功能，這個限制就消失了。這就是聊天機器人和代理程式之間的區別。
電子郵件代理程式接收訊息，協調平台上的工作，並異步回應。
聊天機器人會立即回應，否則就不回應。代理程式會自行思考、行動並溝通。透過電子郵件發送功能，您的代理程式可以接收訊息，花一個小時處理數據，檢查三個其他系統，然後回覆一個完整的答案。它可以安排後續追蹤。當它偵測到邊緣案例時，它可以升級處理。它可以獨立運作。換句話說：它實際上可以完成工作，而不僅僅是回答問題。
以下是具有完整流程的支援代理程式的外觀 — 接收、持久化和回覆：
如果您不熟悉代理程式 SDK 的電子郵件功能，以下是其底層運作方式。
每個代理程式都從單一網域獲得自己的身份。基於地址的解析器將 [email protected] 路由到「支援」代理程式實例，將 [email protected] 路由到「銷售」實例，依此類推。您無需配置單獨的收件匣 — 路由內建在地址中。您甚至可以使用子地址 ([email protected]) 來路由到不同的代理程式命名空間和實例。
狀態跨電子郵件持久化。由於代理程式由 Durable Objects 支持，呼叫 this.setState() 表示您的代理程式會在會話之間記住對話歷史、聯絡資訊和上下文。收件匣成為代理程式的記憶，無需單獨的資料庫或向量儲存。
內建安全的回复路由。當您的代理程式發送電子郵件並預期收到回覆時，您可以使用 HMAC-SHA256 簽署路由標頭，以便回覆能夠路由回發送原始訊息的確切代理程式實例。這可以防止攻擊者偽造標頭將電子郵件路由到任意代理程式實例 — 這是大多數「代理程式電子郵件」解決方案尚未解決的安全問題。
這是團隊在其他地方從頭開始建構的完整電子郵件代理程式流程：接收電子郵件、解析、分類、持久化狀態、啟動異步工作流程、回覆或升級 — 所有這些都在單一 Agent 類別中完成，並在全球範圍內部署在 Cloudflare 的網路上。
電子郵件服務不僅適用於在 Cloudflare 上運行的代理程式。代理程式隨處運行，無論是本地運行或在遠端環境中運行的程式碼代理程式（如 Claude Code、Cursor 或 Copilot），還是運行在容器或外部雲中的生產代理程式。它們都需要從這些環境中發送電子郵件。我們正在發布三個整合，使任何代理程式都能夠存取電子郵件服務，無論其運行在哪裡。
電子郵件現在可透過 Cloudflare MCP 伺服器取得，這是賦予代理程式存取整個 Cloudflare API 的 Code Mode 支援伺服器。透過此 MCP 伺服器，您的代理程式可以發現並呼叫電子郵件端點來發送和配置電子郵件。您可以透過簡單的提示發送電子郵件：
對於運行在具有 bash 存取權限的電腦或沙盒中的代理程式，Wrangler CLI 解決了我們在 Code Mode 部落格文章中討論的 MCP 上下文窗口問題 — 在您的代理程式開始處理單一訊息之前，工具定義就可以消耗數萬個 token。透過 Wrangler，您的代理程式幾乎沒有上下文開銷，並透過 `--help` 命令按需發現功能。以下是您的代理程式如何透過 Wrangler 發送電子郵件：
無論您是將 Cloudflare MCP 還是 Wrangler CLI 提供給您的代理程式，您的代理程式現在都可以透過簡單的提示代表您發送電子郵件。
我們還將發布一個 Cloudflare 電子郵件服務技能。它為您的代理程式提供完整的指導：配置 Workers 綁定、透過 REST API 或 SDK 發送電子郵件、使用電子郵件路由配置處理入站電子郵件、使用代理程式 SDK 建構，以及透過 Wrangler CLI 或 MCP 管理電子郵件。它還涵蓋了可送達性最佳實踐，以及如何製作能夠到達收件匣而不是垃圾郵件的良好交易性電子郵件。將其放入您的專案中，您的程式碼代理程式將擁有在 Cloudflare 上建構生產級電子郵件所需的一切。
在私人測試期間，我們也嘗試了電子郵件代理程式。很明顯，您經常希望保留人工介入的元素來審查電子郵件並了解代理程式正在做什麼。最好的方法是擁有一個功能齊全的電子郵件客戶端，其中內建了代理程式自動化。
這就是我們建構 Agentic Inbox 的原因：一個參考應用程式，具有完整的對話串、電子郵件渲染、接收和儲存電子郵件及其附件，以及自動回覆電子郵件。它內建了一個專用的 MCP 伺服器，因此外部代理程式可以在您發送之前起草電子郵件供您審查。
我們將 Agentic Inbox 開源作為一個參考應用程式，展示如何使用電子郵件路由進行入站、電子郵件發送進行出站、Workers AI 進行分類、R2 進行附件，以及代理程式 SDK 進行有狀態代理程式邏輯來建構完整的電子郵件應用程式。您今天就可以部署它，只需點擊一下按鈕，即可獲得完整的收件匣、電子郵件客戶端和代理程式。
我們希望電子郵件代理程式工具能夠組合和重複使用。與其讓每個團隊重建相同的入站-分類-回覆流程，不如從這個參考應用程式開始。 fork 它、擴展它、將其用作適合您工作流程的電子郵件代理程式的起點。
電子郵件是世界上最重要的工作流程所在，但對於代理程式來說，它經常是一個難以觸及的管道。隨著電子郵件發送功能現已進入公開測試，Cloudflare 電子郵件服務成為一個完整的雙向通訊平台，使收件匣成為您代理程式的一流介面。
無論您是建構一個在收件匣中與客戶見面的支援代理程式，還是保持團隊即時更新的背景流程，您的代理程式現在都有一個無縫的方式在全球範圍內進行通訊。收件匣不再是一個孤島。現在它是您代理程式發揮作用的又一個地方。