讓 Agent
收發真實的
電子郵件

Email 是世界上最普及的溝通介面。不需要安裝任何 SDK，不需要申請帳號，每個人都已經有一個地址。對開發者來說，Email 早已是基礎設施的一部分：用戶註冊驗證、訂單通知、發票寄送——這些場景無處不在。

但 agent 對 Email 的需求和過去的通知系統完全不同。客服 agent 需要接收客戶的問題並回覆；發票處理 agent 需要讀取附件、提取數字、更新系統；帳號驗證 agent 需要確認郵件內容是否符合規則。隨著 agent 承擔更多真實工作，Email 從「通知管道」變成了「工作介面」。

理解這個轉變，需要先釐清 chatbot 和 agent 最根本的差異：

Chatbot——現在回答，或什麼都不做。它活在即時對話的框架裡，你等它，它等你，沒有對話就沒有行動。

Agent——按自己的節奏工作。接到一封 Email，可以花一小時查三個系統、比對資料、評估風險，最後才回覆一封完整的答案。它可以排定後續任務、把邊緣案例轉交人工處理、在你睡覺的時候繼續工作。

Email 的非同步天性，剛好完美匹配 agent 的工作模式。這正是 Cloudflare 在 Agents Week 發布 Email Service 時強調的核心洞察。

Cloudflare Email Sending 在 Agents Week 正式從 Private Beta 升級為 Public Beta，任何人都可以申請使用。核心功能是讓 Workers 透過原生 binding 直接發送交易型 Email——不需要第三方 SMTP 服務，不需要管理 API 金鑰，不需要在 code 裡處理 credentials。

export default {
  async fetch(request, env, ctx) {
    await env.EMAIL.send({
      to: "user@example.com",
      from: "notifications@your-domain.com",
      subject: "訂單已出貨",
      text: "您的訂單 #1234 已出貨，預計 3 天內送達。"
    });
    return new Response("Email sent");
  },
};

SPF、DKIM、DMARC 全部自動配置。把 domain 加入 Cloudflare Email Service 後，系統自動設定所有必要的 DNS 記錄，不需要手動處理 email authentication——這三個縮寫困擾了無數開發者，現在 Cloudflare 把它們藏在抽象層之下。

Email Sending 加上 Email Routing（已免費提供多年），Cloudflare 現在提供了完整的雙向 Email 基礎設施：收信（Routing）+ 發信（Sending），都在同一個平台，都透過 Workers 控制，都不需要獨立的 Email 服務帳號。

對 agent 開發者來說，最重要的意義是：以前 agent 可以透過 Email Routing 接收郵件，但回覆只能同步回覆（轉送給 Cloudflare 帳號成員），無法自由寄出到任意地址。Email Sending 的 Public Beta 打破了這個限制——現在 agent 可以真正「收一封、思考、回一封」，循環完整閉合。

Cloudflare Agents SDK 早已內建 onEmail hook，讓 agent 以 first-class 的方式接收和處理 inbound Email。Email Sending 的加入，讓整個管線真正完整：接收、處理、持久化、回覆，全部在一個 Agent class 裡。

export class SupportAgent extends Agent {
  async onEmail(email: AgentEmail) {
    const raw = await email.getRaw();
    const parsed = await PostalMime.parse(raw);

    // 持久化狀態（跨 session 存活，Durable Objects 後端）
    this.setState({
      ticket: {
        from: email.from,
        subject: parsed.subject,
        body: parsed.text,
        messageId: parsed.messageId,
      },
    });

    // 踢起非同步任務（可以花幾小時處理）
    // await this.scheduleTask(...)

    // 回覆（可以在這裡，也可以在 Queue handler 裡）
    await this.sendEmail({
      binding: this.env.EMAIL,
      from: "support@yourdomain.com",
      to: this.state.ticket.from,
      inReplyTo: this.state.ticket.messageId,
      subject: `Re: ${this.state.ticket.subject}`,
      text: "已收到您的訊息，我們將盡快處理。",
    });
  }
}

這段 code 看起來直白，但背後藏著三個關鍵設計決策：

把這三個設計放在一起，你得到的不只是「能收發 Email 的 Worker」，而是一個真正具備對話記憶、安全隔離、可長期運作的 email agent 基礎設施。

Email Service 不是只給部署在 Cloudflare 上的 agent 用的。現實是：大量 agent 跑在其他地方——Claude Code、Cursor、Copilot 跑在本機；生產 agent 跑在 containers 或外部雲端。Cloudflare 提供了兩個接入路徑，讓任何有工具呼叫能力的 agent 都能使用 Email Service。

wrangler email send \
  --to "teammate@example.com" \
  --from "agent@your-domain.com" \
  --subject "Build completed" \
  --text "The build passed. Deployed to staging."

除了 MCP server 和 CLI，Cloudflare 同步發布了 Cloudflare Email Service Skill——一份給 coding agent 用的完整指引，涵蓋 Workers binding 配置、透過 REST API 發信、用 Email Routing 處理 inbound、用 Agents SDK 建構完整管線、透過 Wrangler 和 MCP 管理、以及 deliverability 最佳實踐。

Skill 的設計邏輯是：coding agent（Claude Code、Cursor 等）本身不知道怎麼正確使用 Email Service，但如果你把 Skill inject 進去，agent 就有了足夠的 context 做出正確的實作決策——包括什麼時候用 binding、什麼時候用 REST API、如何處理 bounce。

在 Private Beta 期間，Cloudflare 發現一個共同的需求：人們希望能看見 agent 在做什麼。最自然的方式是什麼？一個完整的 email client，但裡面有 agent automations 內建進去。這就是 Agentic Inbox——Cloudflare 開源的 Email Agent 參考實作。

Agentic Inbox 的技術棧展示了 Cloudflare 自家產品的整合能力：Email Routing（inbound 收信）+ Email Sending（outbound 發信）+ Workers AI（郵件分類與摘要）+ R2（附件儲存）+ Agents SDK（有狀態的業務邏輯）。每個元件都是標準的 Cloudflare 產品，沒有引入外部依賴。

根據你的使用場景，有三條不同的接入路徑：

{
  "send_email": [
    {
      "name": "EMAIL",
      "destination_address": "notifications@your-domain.com"
    }
  ]
}

加上 binding 後，你的 Worker 裡就有 env.EMAIL 可用——呼叫 env.EMAIL.send() 就能發信，SPF/DKIM/DMARC 全自動處理。配合 Email Routing 設定收信規則，雙向 Email 管線就完整了。