域名邮箱的尴尬，通常不是不会买域名。
一边是自建：DNS、反垃圾、投递率、证书、磁盘，任何一环生锈，信就进垃圾箱。另一边是托管：开箱即用，搜索好用，然后发现导出痛苦、规则搬不走、AI功能还得再买一层。
想要you@yourdomain.com，又不想把整个通信史交给某一家邮箱品牌——这事一直两难。
Cloudflare把一份参考应用开源出来，名字就叫 Agentic Inbox：自托管邮件客户端，整套跑在Workers上，附带一个只许起草、不许擅自点击发送的AI助手。
仓库：https://github.com/cloudflare/agentic-inbox
协议Apache-2.0。官方博客里把它和Email Service公测放在一起，定位很清楚：示范如何用Email Routing收信、Email Sending发信、Workers AI分类和起草、R2存附件、Agents SDK管状态。
折中点在哪
它不是让你在家养一台邮件服务器，也不是再注册一个Gmail替代品牌。
入站走Cloudflare Email Routing，catch-all把信转到Worker。每个邮箱落在独立的Durable Object里，SQLite存会话，附件进R2。出站用Workers上的发送绑定。网页端是完整客户端：写信、回复、转发、文件夹、搜索。
数据因此留在你的Cloudflare账户闭环里，归属比“信在某家邮箱产品的黑盒里”清晰。但要说绝对物理隔离，并不成立——计算和存储仍在Cloudflare的边缘上。比起自建，你换来的是少运维；比起Gmail，你换来的是规则和代码能跟着仓库走。
认证在非本地环境依赖Cloudflare Access。部署到网上给自己用，先把谁能打开这个收件箱讲清楚，否则域名邮箱会变成一个挂在公网的草稿箱。
AI的分寸，比会不会写回信更重要
亮点不是“自动回邮件”。亮点是：到信后先读、再起草，发送必须你点头。
侧栏Agent可以搜历史、整理对话、按邮箱配置不同系统提示词。客服邮箱、个人邮箱、账单邮箱不该共用同一张嘴。流式输出和工具调用可见，方便你判断它有没有把报价或承诺写飞。
自动发送是邮箱Agent里最贵的错误。一封语气礼貌的错回复，够毁掉一单或一次面试。Agentic Inbox把这道闸留在人手里，是产品判断，不是功能没写完。
官方还提到可接MCP，让外部Agent起草、仍由你在收件箱里复核再发。方向是“邮件成为Agent的工具”，而不是“Agent成为你的秘书并拥有公章”。
部署低，不等于邮箱问题消失
帖子说门槛低到几乎一键。对已经把域名放在Cloudflare、会用Workers的人，这接近事实：部署流程会拉起R2、Durable Object、Workers AI，再设收信域名。
你仍要自己准备：
- 一个已托管在Cloudflare的域名
- Email Routing（收）和Email Sending（发）
- Workers AI
- 生产环境的Access策略
- 发信声誉：新域名冷启动、反垃圾、SPF/DKIM/DMARC，不会因为换了Worker就自动变好
这是客户端加路由加Agent，不是把你的域名瞬间变成高投递率的企业邮。重要通知、银行信、政府信，迁移前要双线并行一段时间。
配额和模型也要心里有数。默认走Workers AI上的模型，成本和长度限制跟账号计划走。附件、搜索、长期归档是否够用，以你的体量为准；它首先是参考实现，不是十年老邮箱的替代验收清单。
适合谁，不适合谁
值得试的人：
- 已有Cloudflare域名，想要
@自己的域，又不想养Postfix - 需要AI分拣和草稿，但不能接受自动外发
- 想研究“邮件作为Agent工具”的工程样本
可以继续用现成邮箱的人：
- 只要一个能用的收件箱，不想碰DNS和Access
- 团队协同、多端原生App、复杂过滤规则已经绑在Google或微软上
- 把“自托管”理解成数据离开所有云厂商
写在最后
自建和托管的两难，本质是控制权与省心无法同时最大化。Agentic Inbox把收件箱搬进你的Workers账户，让模型当参谋而不是法人，算是目前比较诚实的折中：代码开源，闸门在人，基础设施仍来自同一家边缘网络。
仓库在这里：
https://github.com/cloudflare/agentic-inbox
先用一个不重要的别名跑通收信和草稿。真把主邮箱迁过去之前，确认你能打开Access、能发出不被扔进垃圾箱的信，也确认那份AI草稿在你没点发送之前，永远只是草稿。
No comments yet