原文Cloudflare Email Service: now in public beta. Ready for your agents邮件是世界上最通用的接口不需要下载特定 App不需要接入自定义 SDK不需要注册新平台。全球几十亿人都有邮箱任何人都可以通过一封邮件和你的应用交互。这种普遍性让邮件在 AI Agent 的时代重新变得重要。开发者已经在用邮件做注册确认、订单通知、账单发送——这是应用层面的使用。现在越来越多的团队开始把邮件接入 Agent 本身客服 Agent 通过邮件受理工单发票处理 Agent 通过邮件接收单据账号验证流程通过邮件完成核实多个 Agent 之间通过邮件协作传递信息。Cloudflare Email Service 正是为这个方向设计的基础设施。这次随 Agents Week 一起发布Email Sending 正式进入公开测试同时配套发布了 Email MCP Server、Wrangler CLI 邮件命令、技能文件Skills以及一个开源的参考应用 Agentic Inbox。Email Sending从 Worker 直接发邮件无需 API 密钥一行代码发送Email Sending 提供了一个原生的 Workers binding发邮件和调用其他 Cloudflare 服务没有区别exportdefault{asyncfetch(request,env,ctx){awaitenv.EMAIL.send({to:[email protected],from:[email protected],subject:Your order has shipped,text:Your order #1234 has shipped and is on its way.});returnnewResponse(Email sent);},};不需要管理 API 密钥不需要配置 Secrets直接通过 binding 调用。对于不在 Workers 上运行的场景也提供 REST API 以及 TypeScript、Python、Go 三个官方 SDK。邮件送达问题已经帮你解决了自己发事务性邮件最大的坑是 SPF、DKIM、DMARC 这三个认证记录的配置。配错了邮件直接进垃圾箱。把域名添加到 Email Service 之后这三条 DNS 记录会自动配置完毕不需要手动操作邮件认证通过、正常送达。收发双向已经闭环Email Routing 是 Cloudflare 已经免费提供多年的入站邮件能力——接收发给你域名的邮件在 Worker 里处理。现在 Email Sending 补上了出站能力收发两端都在同一个平台上不需要再接入第三方邮件服务商。聊天机器人和 Agent区别在哪里把这个问题说清楚有助于理解为什么 Email Sending 对 Agent 如此重要。聊天机器人的工作模式是用户发来消息机器人立刻回复或者干脆不回。它的时间线是用户的时间线它的能力范围是当前上下文能覆盖的范围。Agent的工作模式完全不同它可以接收一条消息花一个小时处理数据同时查询三个外部系统然后在工作完成后主动发送一封带完整答案的邮件给用户。它有自己的时间线可以调度后台任务可以在发现异常时主动上报可以设置定时跟进可以真正独立地把事情做完——而不只是回答问题。在拥有 Email Sending 能力之前Cloudflare 的 Agents SDK 里虽然有onEmailhook 可以接收入站邮件但 Agent 只能同步回复或者发邮件给 Cloudflare 账户内的成员。这个限制把 Agent 锁在了类似聊天机器人的模式里。Email Sending 解除了这个限制。Agent 现在可以向任何邮件地址发送邮件在任意时机主动触达异步通信能力完整了。Agents SDK让 Agent 原生理解邮件每个 Agent 实例都有自己的邮箱地址Agents SDK 里的地址路由器createAddressBasedEmailResolver把邮件地址的前缀映射到具体的 Agent 实例。发给supportyourdomain.com的邮件路由到 “support” Agent 实例发给salesyourdomain.com的路由到 “sales” 实例以此类推。不需要为每个 Agent 分别配置独立邮箱路由逻辑已经内置在地址里。子地址tag格式也支持supportvipyourdomain.com可以路由到不同的命名空间或实例粒度可以做得更细。对话历史自动持久化Agent 的状态由 Durable Objects 支撑。调用this.setState()更新状态后Agent 跨邮件会话都能记住对话历史、联系人信息和处理上下文不需要额外搭建数据库或向量存储。收件箱本身就成了 Agent 的记忆。安全的回复路由当 Agent 发出一封邮件并期待对方回复时如何确保回复能准确路由回发件的那个 Agent 实例Cloudflare 的做法是用 HMAC-SHA256 对路由头进行签名。收到回复时验证签名防止攻击者伪造路由头、把邮件导向其他 Agent 实例。这是大多数面向 Agent 的邮件方案没有解决的安全问题。完整代码接收、持久化、异步处理、回复以下是一个客服 Agent 的完整实现覆盖了整条流水线import{Agent,routeAgentEmail}fromagents;import{createAddressBasedEmailResolver,typeAgentEmail}fromagents/email;importPostalMimefrompostal-mime;exportclassSupportAgentextendsAgent{asynconEmail(email:AgentEmail){constrawawaitemail.getRaw();constparsedawaitPostalMime.parse(raw);// 持久化邮件状态this.setState({...this.state,ticket:{from:email.from,subject:parsed.subject,body:parsed.text,messageId:parsed.messageId},});// 在这里发起后台异步任务或者把消息推入 Queue 由其他 Worker 处理// 发送确认回复awaitthis.sendEmail({binding:this.env.EMAIL,fromName:Support Agent,from:[email protected],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.});}}exportdefault{asyncemail(message,env){awaitrouteAgentEmail(message,env,{resolver:createAddressBasedEmailResolver(SupportAgent),});},}satisfies ExportedHandlerEnv;整条流水线——接收邮件、解析内容、持久化状态、触发异步任务、回复确认——都在一个 Agent 类里完成部署到 Cloudflare 全球网络。面向 Agent 的邮件工具集Email Service 不只面向跑在 Cloudflare 上的 Agent。本地运行的编码 AgentClaude Code、Cursor、Copilot、跑在容器里的生产 Agent、部署在其他云上的 Agent也都需要发邮件的能力。Cloudflare 为这些场景配套发布了三个工具。MCP ServerEmail 能力已经接入了 Cloudflare MCP Server——同一个服务器还暴露了整套 Cloudflare API。Agent 通过 MCP 协议发现并调用 Email 相关的端点用自然语言就能触发发送当构建完成时从我的 staging 域名给 devexample.com 发一封通知邮件Wrangler CLI 邮件命令MCP 有一个已知的权衡工具定义本身会消耗上下文窗口在 Agent 处理任何实际内容之前工具描述可能已经用掉了数万个 Token。Wrangler CLI 是另一条路Agent 以几乎零开销启动需要什么能力就通过--help按需发现。发邮件只需一行命令wrangler email send\--to[email protected]\--from[email protected]\--subjectBuild completed\--textThe build passed. Deployed to staging.适合跑在有 bash 访问权限的计算机或沙箱里的 Agent。技能文件SkillsCloudflare 同时发布了一个专门面向编码 Agent 的邮件技能文件覆盖了从配置 Workers binding、通过 REST API 或 SDK 发送邮件、处理入站邮件的 Email Routing 配置到 Agents SDK 的使用方式以及通过 Wrangler 或 MCP 管理邮件——还包括邮件可达性最佳实践和如何写出不进垃圾箱的事务性邮件。把这个文件加入项目编码 Agent 就有了在 Cloudflare 上构建生产级邮件能力所需的完整上下文。开源参考应用Agentic Inbox在私测期间Cloudflare 自己也在试验邮件 Agent。他们发现了一个普遍存在的需求Agent 在处理邮件时人类往往需要保留一个审核窗口——能看到 Agent 在做什么在发送之前能介入确认。为此他们构建并开源了Agentic Inbox一个完整的邮件客户端参考实现完整的会话线程展示邮件内容渲染和附件存储入站邮件接收和自动回复内置 MCP Server外部 Agent 可以起草邮件等待人工审核后再发送技术栈清单Email Routing入站 Email Sending出站 Workers AI邮件分类 R2附件存储 Agents SDK有状态 Agent 逻辑。这个应用可以一键部署也可以 Fork 下来作为自己邮件 Agent 项目的起点不需要从零重建那套接收 → 分类 → 回复的基础流水线。小结从这次发布里有几个值得关注的判断邮件作为 Agent 接口的优势是零门槛触达。不需要用户安装 App、注册平台或接入 SDK任何有邮件地址的人都能和 Agent 交互。这对于面向已有用户群做 Agent 改造的产品来说是阻力最小的路径。异步是 Agent 和聊天机器人最本质的区别。一个能发邮件的 Agent才有条件真正做长时间运行的后台任务接收请求、处理、完成后主动告知。这个能力在很多场景里比实时响应更有实际价值——财务对账、数据导出、审批流程、定期报告都是如此。安全回复路由是容易被忽视的细节。HMAC 签名的路由头解决的问题很具体当 Agent 实例数量很多时如何保证回复精确路由回原始实例而不是被恶意构造的地址路由到其他地方。这个细节在业务规模扩大之后会变得重要。开源参考应用的定位是人机协作而非全自动。Agentic Inbox 的内置 MCP Server 设计允许外部 Agent 起草邮件、等待人工审核再发送——这个人在回路的设计在处理对外通信时往往是更稳妥的默认选择。参考链接原文https://blog.cloudflare.com/email-for-agents/Email Service 控制台https://dash.cloudflare.com/?to/:account/email-service/sendingEmail Service 文档https://developers.cloudflare.com/email-service/Agents SDK 邮件文档https://developers.cloudflare.com/agents/api-reference/emailAgentic Inbox 开源仓库https://github.com/cloudflare/agentic-inboxEmail MCP Serverhttps://github.com/cloudflare/mcp-server-cloudflare技能文件https://github.com/cloudflare/skills