「Email is the most accessible interface in the world.」這句話出自 Cloudflare 的官方部落格，點出了一個事實：電子郵件仍然是最普及的數位介面。現在，這個最古老的網路協議正在成為 AI agents 的新溝通管道。
2026 年 4 月 16 日，Cloudflare 宣布 Email Service 進入公開測試版（public beta），專門為 AI agents 設計。這不只是一個新的電子郵件服務，而是一個完整的基礎設施層，讓 agents 可以原生地發送、接收和處理電子郵件。
為什麼是電子郵件？
在 Slack、Discord、WhatsApp 各種通訊工具競爭激烈的今天，為什麼 Cloudflare 選擇了電子郵件？
答案很簡單：無處不在。每個人都有電子郵件地址，不需要安裝自定義的聊天應用程式，不需要為每個頻道學習新的 SDK。對於需要與任何人互動的 agents 來說，電子郵件是最佳的通用介面。
根據 Cloudflare 的觀察，開發者們正在電子郵件上建設各種應用：客戶支援 agents、發票處理流程、帳號驗證流程、多 agent 工作流程。這些都建立在電子郵件之上。這個模式很清楚：電子郵件正在成為 agents 的核心介面。
電子郵件的另一個優勢是它的異步性質。聊天應用程式期望即時回應，但真實世界中的許多任務需要時間。客戶支援調查、發票處理、資料分析——這些都無法在幾秒鐘內完成。電子郵件的特性完美契合這種需求，讓 agents 可以在需要的時間內完成工作，然後回覆。
Cloudflare Email Service 的三大支柱
這個服務包含三個核心功能，共同構成一個完整的 email agent 生態系統：
Email Routing：接收郵件
讓你的應用程式或 agent 接收電子郵件。這個功能已經免費提供多年，現在被整合到 agents 生態系統中。透過 Email Routing，你可以設定路由規則，將傳入的電子郵件引導到正確的 agent 實例。
Email Sending：發送郵件
這是今天進入公開測試版的新功能。你可以從 Workers 直接發送交易式電子郵件，無需 API keys，無需管理 secrets。這是一個看似簡單但意義重大的改變。
傳統上，發送電子郵件意味著：註冊服務、獲取 API key、管理 secrets、設定域名驗證、配置 SPF/DKIM/DMARC、監控送達率…這些都是開發者必須處理的繁瑣工作。Email Service 將這些複雜性全部抽象化了。
Agents SDK 整合
完整的 email agent 管線：接收、保存、處理、回覆——全部在一個平台上完成。這才是真正讓 agents 成為「email 原生」的關鍵。
Email Sending：進入公開測試版
Email Sending 從私有測試版畢業，現在任何人都可以使用。這個功能的最大特色是簡潔。
你可以在 Workers 中直接使用：
export default {
async fetch(request, env, ctx) {
await env.EMAIL.send({
to: "user@example.com",
from: "notifications@your-domain.com",
subject: "Your order has shipped",
text: "Your order #1234 has shipped and is on its way."
});
return new Response("Email sent");
},
};
或者使用 REST API 和 SDK，支援 TypeScript、Python 和 Go：
curl "https://api.cloudflare.com/client/v4/accounts/{account_id}/email-service/send" \
--header "Authorization: Bearer <API_TOKEN>" \
--header "Content-Type: application/json" \
--data '{
"to": "user@example.com",
"from": "notifications@your-domain.com",
"subject": "Your order has shipped",
"text": "Your order #1234 has shipped and is on its way."
}'
自動化 DNS 配置
這聽起來很像一般的電子郵件服務，但關鍵差異在於：當你加入 Email Service 時，Cloudflare 會自動配置 SPF、DKIM 和 DMARC 記錄。這些確保你的電子郵件被驗證並送達收件箱，而不是被標記為垃圾郵件。
對於不熟悉電子郵件協議的開發者來說，這是一個巨大的便利。SPF（Sender Policy Framework）、DKIM（DomainKeys Identified Mail）、DMARC（Domain-based Message Authentication, Reporting, and Conformance）——這些術語聽起來就很複雜，而配置它們更是一場噩夢。Cloudflare 把這個過程變成一鍵完成。
全球低延遲分發
此外，因為 Email Service 建立在 Cloudflare 的全球網路上，你的電子郵件可以在世界各地以低延遲送達。這對於需要即時通知的應用程式特別重要——例如訂單狀態更新、安全警報、系統通知。
結合 Email Routing，你現在在一個平台上擁有完整的雙向電子郵件功能。接收電子郵件，在 Worker 中處理，然後回覆——全部在 Cloudflare 範圍內完成。
Agents SDK：讓你的 Agent 成為 Email 原生
Agents SDK 原本就有一流的 onEmail hook 用來接收和處理傳入的電子郵件。但直到現在，你的 agent 只能同步回覆，或者只發送電子郵件給 Cloudflare 帳號的成員。
有了 Email Sending，這個限制消失了。這就是聊天機器人和 agent 之間的區別。
聊天機器人 vs. Agent
Email agents 接收訊息，在平台上協調工作，並異步回覆。
聊天機器人在當下回覆，或者完全不回覆。它的思考空間受限於上下文視窗，它的行動受限於即時回應的期望。
Agent 則思考、行動，並按照自己的時間表溝通。有了 Email Sending，你的 agent 可以接收訊息，花一小時處理資料，檢查三個其他系統，然後回覆完整的答案。它可以安排後續追蹤。它可以在偵測到邊緣情況時升級處理。它可以獨立運作。換句話說：它可以實際做工作，而不只是回答問題。
完整的支援 Agent 管線
這是一個完整的支援 agent 管線範例：
import { Agent, routeAgentEmail } from "agents";
import { createAddressBasedEmailResolver, type AgentEmail } from "agents/email";
import PostalMime from "postal-mime";
export class SupportAgent extends Agent {
async onEmail(email: AgentEmail) {
const raw = await email.getRaw();
const parsed = await PostalMime.parse(raw);
// 保存到 agent 狀態
this.setState({
...this.state,
ticket: {
from: email.from,
subject: parsed.subject,
body: parsed.text,
messageId: parsed.messageId
},
});
// 啟動長時間運行的背景 agent 任務
// 或者將訊息放入 Queue 交給另一個 Worker 處理
// 在這裡回覆或在其他 Worker handler 中回覆，例如 Queue handler
await this.sendEmail({
binding: this.env.EMAIL,
fromName: "Support Agent",
from: "support@yourdomain.com",
to: this.state.ticket.from,
inReplyTo: this.state.ticket.messageId,
subject: `Re: ${this.state.ticket.subject}`,
text: `Thanks for reaching out. We received your message about "${this.state.ticket.subject}" and will follow up shortly.`
});
}
}
export default {
async email(message, env) {
await routeAgentEmail(message, env, {
resolver: createAddressBasedEmailResolver("SupportAgent"),
});
},
} satisfies ExportedHandler<Env>;
這段程式碼展示了幾個關鍵能力：
- 解析電子郵件：使用 PostalMime 函式庫解析原始電子郵件內容
- 狀態持久化：透過
this.setState()保存資料到 Durable Objects - 異步處理：可以在背景任務中處理複雜邏輯
- 回覆郵件：使用正確的標頭（inReplyTo, subject）回覆
每個 Agent 都有自己的身份
地址基礎的解析器（address-based resolver）會將 support@yourdomain.com 路由到 “support” agent 實例，sales@yourdomain.com 路由到 “sales” 實例，以此類推。你不需要配置分開的收件匣——路由就建在地址中。你甚至可以使用子地址（NotificationAgent+user123@yourdomain.com）路由到不同的 agent 命名空間和實例。
這意味著你可以在一個域名下運行多個 agents，每個都有專用的電子郵件地址。支援 agent 可以是 support@，銷售 agent 可以是 sales@，開票 agent 可以是 billing@——全部整合在一個平台上。
狀態持續跨越電子郵件
因為 agents 由 Durable Objects 支援，呼叫 this.setState() 意味著你的 agent 會記住對話歷史、聯絡資訊和跨會話的上下文。收件匣成為 agent 的記憶，不需要分開的資料庫或向量儲存。
這是一個重要的區別。傳統的聊天機器人需要維護對話歷史，通常使用向量資料庫或資料庫。但在 Email Service 中，歷史自動持久化在 Durable Objects 中，你的 agent 可以跨時間、跨會話記住資訊。
想像一下客戶支援 agent：它會記得客戶的過往問題、解決方案、偏好。當客戶再次發送電子郵件時，agent 可以立即訪問完整的歷史，提供更個人化的支援。
安全的回覆路由
當你的 agent 發送電子郵件並期待回覆時，你可以使用 HMAC-SHA256 對路由標頭進行簽名，讓回覆路由回到發送原始訊息的確切 agent 實例。這可以防止攻擊者偽造標頭將電子郵件路由到任意的 agent 實例——這是一個安全問題，大多數「email for agents」解決方案都沒有處理。
為什麼這很重要？想像一個攻擊者試圖將惡意電子郵件路由到你的 agent。如果他們能夠偽造標頭，他們可能會讓你的 agent 接收本不應該處理的訊息。HMAC 簽名防止了這種攻擊向量，確保只有合法的回覆才能到達正確的 agent 實例。
這是團隊在其他地方從零開始建設的完整 email agent 管線：接收電子郵件，解析它，分類它，保存狀態，啟動異步工作流程，回覆或升級——全部在一個單一的 Agent 類別中，部署在全球的 Cloudflare 網路上。
Email 工具：MCP 伺服器、Wrangler CLI 和 Skills
Email Service 不只適合在 Cloudflare 上運行的 agents。Agents 到處運行，無論是在本機或遠端環境運行的 coding agents 像 Claude Code、Cursor 或 Copilot，還是在容器或外部雲端運行的生產 agents。它們都需要從那些環境發送電子郵件。
Cloudflare 推出了三個整合，讓 Email Service 對任何 agent 都可存取，無論它在哪裡運行。
Email MCP 伺服器
電子郵件現在透過 Cloudflare MCP 伺服器可用，這是同一個 Code Mode 驅動的伺服器，讓 agents 可以存取整個 Cloudflare API。有了這個 MCP 伺服器，你的 agent 可以發現並呼叫 Email 端點來發送和配置電子郵件。你可以用一個簡單的提示發送電子郵件：
「Send me a notification email at hello@example.com from my staging domain when the build completes」
MCP（Model Context Protocol）是一種讓 LLM agents 與工具互動的標準協議。透過 MCP 伺服器，你的 agent 可以動態發現和呼叫 Cloudflare 的 Email API，而不需要硬編碼工具定義。這使得 agents 更靈活、更容易擴展。
Wrangler CLI：解決上下文視窗問題
對於在電腦或沙盒上運行並有 bash 存取權的 agents，Wrangler CLI 解決了我們在 Code Mode 部落格中討論的 MCP 上下文視窗問題——工具定義在你的 agent 開始處理單一訊息之前就可能消耗數萬個 tokens。
有了 Wrangler，你的 agent 從接近零的上下文開銷開始，並透過 –help 命令按需發現能力。
你的 agent 可以透過 Wrangler 發送電子郵件：
wrangler email send \
--to "teammate@example.com" \
--from "agent@your-domain.com" \
--subject "Build completed" \
--text "The build completed successfully."
這個方法特別適合本地運行的 coding agents。agent 可以透過 CLI 執行命令，而不是透過 API 調用，這減少了上下文視窗的壓力，讓 agent 可以專注於實際任務而不是工具定義。
Coding Agents 的 Skills
Cloudflare 還為 coding agents 提供了特定的 skills，讓它們可以透過 CLI 直接發送電子郵件。這些 skills 是預定義的能力集合，讓 agents 可以快速學習和使用，而不需要從零開始探索。
Skills 的概念類似於 LLM 的「插件」——預訓練的能力，agent 可以直接呼叫。對於常用任務如發送電子郵件，這大大提高了效率和可靠性。
開源參考應用
Cloudflare 還發布了一個開源的 agentic inbox 參考應用，展示如何建設完整的 email agent。這是一個有用的起點，讓開發者可以學習如何在自己的專案中實現這些模式。
參考應用的重要性在於：它不只是一個「hello world」範例，而是一個生產就緒的實現，包含錯誤處理、狀態管理、安全路由等真實世界需要的特性。開發者可以從這個基礎開始，擴展到自己的需求。
實際應用場景
讓我們看看 Email Service 在現實世界中的幾個應用場景：
客戶支援自動化
一個客戶支援 agent 可以透過 email 接收問題，自動分類，嘗試解決常見問題，對於複雜問題升級給人工支援。所有這些都透過電子郵件完成，用戶不需要安裝任何新工具。
客戶發送 email 到 support@，agent 接收並分析。如果是常見問題如「如何重設密碼」，agent 可以立即回覆詳細步驟。如果是複雜問題如系統異常，agent 可以收集資訊、日誌、截圖，然後創建工單並通知工程團隊。
發票和財務處理
發票處理 agent 可以接收發票郵件，自動提取關鍵資訊（金額、日期、發票號碼），驗證格式和有效性，然後將資料輸入到會計系統。處理完成後，發送確認郵件給發送者。
這個流程節省了財務團隊大量的時間，減少了錯誤，並提高了處理速度。而且，因為 agent 有狀態，它會記住每個供應商的發票模式，逐漸變得更智能。
通知和警報系統
監控和警報系統可以透過 email 發送警報，agent 接收後可以分析嚴重性，決定是否需要立即通知 on-call 工程師，或是在每日報告中彙總。
agent 可以學習哪些警報是誤報，哪些是真正需要處理的問題。它還可以協調多個警報，識別潛在的模式或趨勢，提供更深入的分析。
多 Agent 協作
不同的 agents 可以透過 email 協作。一個 agent 完成任務後，發送 email 給下一個 agent，觸發下一個步驟。這實現了真正的多 agent 工作流程，全部透過標準的電子郵件協議。
例如：資料收集 agent 完成後，發送 email 給分析 agent；分析 agent 完成後，發送 email 給報告 agent；報告 agent 生成報告，發送給相關人員。這整個流程可以自動化，無需人工介入。
安全性和隱私考慮
當 agents 處理電子郵件時，安全性和隱私變得特別重要。Cloudflare Email Service 在這方面做了幾個關鍵的設計決定：
HMAC-SHA256 路由簽名
如前所述，HMAC 簽名確保只有合法的回覆才能到達正確的 agent 實例。這防止了路由偽造攻擊。
Durable Objects 的隔離
每個 agent 實例運行在隔離的 Durable Object 中，這意味著狀態不會洩露給其他 agents。這對於處理敏感資料的 agents 特別重要。
端到端加密
雖然 Cloudflare 沒有明確提到端到端加密，但透過其全球網路和標準的電子郵件協議（TLS），電子郵件在傳輸過程中是加密的。
合規性和法規
對於處理個人資料的 agents（如在客戶支援場景中），開發者需要確保符合 GDPR、CCPA 等隱私法規。Cloudflare Email Service 提供了基礎設施，但合規性最終是使用者的責任。
與其他解決方案的比較
市面上已經有許多電子郵件服務：SendGrid、Mailgun、Amazon SES、Postmark。Cloudflare Email Service 有什麼不同？
與傳統電子郵件服務
傳統服務專注於發送電子郵件。它們提供高送達率、良好的模板編輯器、詳細的分析報告。但它們不是為 agents 設計的。
Cloudflare Email Service 的重點是：agent 原生。它整合了接收、處理、狀態管理、安全路由——這些都是 agents 需要但傳統服務不提供的。
與其他「Email for Agents」解決方案
有一些新興的解決方案聲稱支援「email for agents」，但它們通常只是提供簡單的 webhook 整合。Cloudflare Email Service 提供的是一個完整的 agent 平台，包括狀態管理、安全路由、全球部署。
與聊天機器人平台
聊天機器人平台如 Dialogflow、Rasa 專注於對話管理，但通常是同步的。Cloudflare Email Service 讓 agents 可以異步運行，這對於真實世界的任務是必要的。
對開發者的影響
對於開發者來說，這個服務解決了幾個長期存在的痛點：
第一，簡化了電子郵件發送的複雜性。你不需要管理 API keys、設定 SPF/DKIM/DMARC、擔心送達率。Cloudflare 全部自動處理。
第二，為 agents 提供了一個原生且可靠的溝通管道。你的 agent 可以接收訊息、處理複雜任務、然後異步回覆——這是真正的 agent 行為，而不是同步聊天機器人。
第三，整合了狀態管理和路由。你的 agent 會記住上下文，不需要額外的資料庫。這大大降低了構建 agents 的複雜度。
第四，全球部署和低延遲。Cloudflare 的全球網路意味著你的 agents 可以在離用戶最近的地方運行，提供更好的響應時間。
對 AI 生態的影響
這個發布反映了 AI agents 發展的一個重要趨勢：agents 正在變成多頻道的。它們需要能在用戶所在的地方運行——包括收件匣。
電子郵件的普遍性使其成為 agents 的理想介面。任何人都已經有電子郵件地址，任何 agent 都可以與任何人溝通。這打破了專用聊天應用程式的限制。
這也改變了我們思考 agents 的方式。agents 不再只是回答問題的聊天機器人；它們是可以實際執行工作、持續運行、在不同時間回覆的實體。電子郵件的異步本質完美契合這個模式。
更重要的是，這降低了 agents 的采用門檻。用戶不需要學習新的工具或界面，他們已經會用電子郵件。這對於企業尤其重要——他們可以將 agents 整合到現有的工作流程中，而不需要重新培訓員工。
未來發展方向
Cloudflare Email Service 進入公開測試版只是開始。未來我們可能會看到：
豐富的整合
更多與其他服務的整合，如 CRM、ERP、專案管理工具。agents 可以透過 email 這個通用介面與這些系統互動。
進階的安全功能
如數位簽名、加密電子郵件、細粒度的存取控制。這些對於處理敏感資料的 agents 是必要的。
AI 增強的電子郵件處理
自動分類、情感分析、意圖識別——這些可以讓 agents 更智能地處理電子郵件。
視覺化工具
dashboard、分析報告、調試工具——讓開發者更容易監控和管理 agents。
未來幾年，我們會看到這個趨勢繼續發展
但真正的變化，或許不是技術本身，而是我們對技術的態度。
當 agents 可以用電子郵件溝通，它們就可以與任何人、任何系統互動。這意味著 agents 可以成為業務流程的一部分，而不只是附加的聊天介面。它們可以處理客戶支援、管理發票、協調工作流程——而不需要用戶學習新的工具。
這也意味著企業需要重新思考他們的自動化策略。不是如何將人工流程機器化，而是如何設計真正由 agents 驅動的工作流程。
對開發者來說，這是一個機會，也是一個挑戰。機會在於你可以建設更強大、更自主的應用程式。挑戰在於你需要學會如何設計 agents，而不只是應用程式。
Email Service 走出了重要的一步。它提供了一個可靠、安全、易用的基礎設施，讓 agents 可以透過最普及的介面溝通。現在，輪到開發者想像如何利用這個能力了。
電子郵件已經存在了幾十年，經歷了從革命性的通訊工具到商務標準的演變。現在，它正在進入新的階段——成為 AI agents 的原生介面。這不是電子郵件的終結，而是它的重生。