用自己的域名当邮箱：Cloudflare 开源了一个自带 AI 管家的邮件系统
你有没有想过,为什么这么多年过去了,邮箱这个东西居然还是没被淘汰?
微信、Slack、飞书轮番上阵,大家天天喊"邮件已死",可现实是——你注册任何一个网站都要填邮箱,银行通知走邮箱,合同走邮箱,连找工作投简历都得靠邮箱。它土,但它是全世界唯一一个不需要下载任何 App、不需要对方也用同一个软件、随便一个地址就能触达任何人的通信方式。而且更关键的是,邮箱地址天然带着"域名"这个身份标识——hello@你的公司.com 这种地址,本身就是一张免费的信任状。
正因为这一点,Cloudflare 最近干了一件挺有意思的事:他们开源了一个叫 Agentic Inbox 的项目——一个自带 AI 助理的邮箱客户端,而且整套系统完全跑在 Cloudflare Workers 上。更重要的是,它天生就是为"自己的域名"设计的:你不是去注册一个 [email protected] 这样的平台账号,而是直接把自己已经拥有的域名接进来,变成 hello@你的域名.com、support@你的域名.com 这种真正属于你的地址。你点一个部署按钮,几分钟后就拥有了一个用自己域名收发邮件、还会自己读邮件、自己写回复草稿的邮箱系统。
GitHub项目地址：https://github.com/cloudflare/agentic-inbox
它到底能干嘛
想象一下这个场景:你给自己的公司或者项目搞了个客服邮箱 [email protected]。以前的流程是,客户发邮件进来,你或者你的同事得一封封打开看、一封封回。人少的时候还行,邮件一多,漏回、回错、回晚是家常便饭。
装上 Agentic Inbox 之后,画风变成这样:客户邮件一进来,系统自动读取内容,侧边栏里的 AI 助理会自己搜一下过往的沟通记录、理解上下文,然后主动帮你写好一份回复草稿。你要做的只是扫一眼草稿,觉得没问题就点发送,觉得不对就改两笔或者让 AI 重写。它绝对不会替你偷偷把邮件发出去——这是项目里明确写死的规则,每一封回信都必须经过人工确认。
除了自动写草稿,这个 AI 助理本身也是个能对话的邮箱助手,你可以直接跟它说"帮我翻一下上周和某某公司的邮件往来""把这封邮件的附件下载并总结一下""给这个客户起草一封催款邮件",它会调用内置的工具去邮箱里翻找、读取、汇总,然后给你结果。
说白了,它想解决的就是那个所有做客服、做销售、做运营的人都懂的痛点:邮件多到回不过来,但又不敢完全交给 AI 自己处理,怕出岔子。Agentic Inbox 的解法是"AI 打草稿,人来把关",既省了体力活,又保住了最后一道安全阀。
重点来了:怎么把自己的域名装进去
这大概是很多人第一眼看到这个项目最关心的问题——我能不能直接用公司现成的域名?答案是可以,而且这本来就是整个项目的设计前提。它不是那种"注册个账号送你一个平台邮箱"的玩法,而是要求你先有一个域名,再把这个域名的收发信权限交给它。具体是这几步:
第一步,域名的 DNS 必须托管在 Cloudflare 上。 如果你的域名是在阿里云、GoDaddy 这些地方买的,得先把它的名称服务器(NS)改成指向 Cloudflare,或者直接把域名转到 Cloudflare 注册——这一步完全免费,不需要升级任何付费套餐。
第二步,在这个域名上开启 Email Routing(邮件路由)。 这一步会自动帮你在 DNS 里加好 MX 记录,把发到这个域名的邮件交给 Cloudflare 处理,而不是投递到某个真实的邮箱服务商那里。
第三步,一个域名可以开无数个地址。 sales@、support@、hello@、ceo@,只要是同一个域名下的前缀,理论上想开多少个都行。每一个地址在 Agentic Inbox 后台都是一个完全独立的"邮箱实例",数据、聊天记录、附件互不干扰,你甚至可以给不同的地址配置不同性格的 AI 助理——客服邮箱走温和耐心的风格,销售邮箱走主动追单的风格。
不过这里有个坑必须提前说清楚:如果你这个域名目前已经在用别的正经邮箱服务(比如企业用的是腾讯企业邮、飞书邮箱、Google Workspace、Outlook 365),直接开启 Email Routing 会覆盖掉原来的 MX 记录,导致老邮箱系统突然收不到信,员工日常办公邮箱直接瘫痪。所以稳妥的做法是两选一:
- 这个域名本来就没配过正经邮箱,专门腾出来给 Agentic Inbox 用;
- 或者干脆用一个子域名(比如
mail.你的域名.com,或者单独注册一个新域名专门跑这套系统),这样就不会跟公司现有的办公邮箱打架,两套系统各走各的路。
想清楚这一点之后,剩下的部分——部署、AI 怎么工作、要不要花钱——才有意义。
为什么是 Cloudflare 来做这件事
这就得说说背景了。Cloudflare 最近搞了个"Agents Week"(智能体周),集中发布了一堆围绕"如何让 AI 智能体真正能干活"的基础设施,其中一块拼图就是邮件服务。
<cite index="2-1">在 Cloudflare 看来,邮件是世界上最容易触达的接口——它无处不在,不需要专门的聊天应用,也不需要为每个渠道搭一套独立的 SDK,因为几乎每个人都已经有邮箱地址了,这意味着任何应用或智能体都能借助邮件和任何人互动。</cite>过去大半年他们和不少开发者聊下来,发现<cite index="2-1">客服智能体、发票处理流程、账户验证流程、多智能体协作系统,几乎都绕不开邮件这个渠道</cite>。
但问题是,以前 Cloudflare 的 Agents SDK 虽然支持智能体"接收"邮件(有个叫 onEmail 的钩子函数),却没法让智能体"主动发"邮件给收件人账号体系之外的人。这就好比一个客服只能被动等你发消息,却不能主动给你回信——功能是残缺的。
随着 Cloudflare 的邮件发送服务(Email Sending)进入公测,这个限制被打通了。<cite index="2-1">这被认为是聊天机器人和真正的智能体之间的分水岭:聊天机器人只能当场回复或者压根不回复,而智能体可以按自己的节奏思考、行动、沟通</cite>——它可以先花一个小时处理数据、去核对三个不同系统的信息,然后才回复一个完整的答案;它可以安排后续跟进,遇到异常情况还能上报升级。
而 Agentic Inbox,就是 Cloudflare 拿出来"秀肌肉"顺便"给示范"的一个参考项目——一个真刀真枪、完整能跑的邮箱应用,证明这套"用自己域名收发邮件+AI 智能体"的基础设施到底能拼出个什么样的东西。
拆开看看它是怎么搭起来的
这部分聊点技术细节,不写代码,尽量说人话。
收信这条路:邮件是通过前面说的 Email Routing 进来的。你在自己域名的 DNS 上配好规则后,发到 [email protected] 的所有邮件都会被转发给这个 Worker 程序处理,而不是转发到某个真实的邮箱账户。
每个邮箱都是"独立小房间":项目里每一个邮箱地址,后台对应的是一个独立的 Durable Object(可以理解成一个自带小型 SQLite 数据库、能长期保存状态的轻量级服务实例)。这意味着 [email protected] 和 [email protected] 的邮件、聊天记录、附件互不干扰,各自关在自己的房间里,数据结构上是天然隔离的。
附件去哪儿了:邮件里的图片、PDF、压缩包这些附件,不会塞进数据库,而是丢进 R2(Cloudflare 的对象存储,类似轻量版的 S3)里存着,数据库里只留一个索引指针。
AI 助理这部分:这是最有意思的地方。侧边栏那个能聊天的 AI 助理,底层用的是 Cloudflare 的 Agents SDK 里一个叫 AIChatAgent 的组件,调用的模型是 Workers AI 上跑的 kimi-k2.5(月之暗面的开源模型)。这个助理身上挂了九个邮件相关的工具——读邮件、搜索会话、写草稿、发送邮件等等一整套操作,它就是靠这些工具去实际"动手"操作邮箱,而不是凭空瞎编。而且它的对话历史是持久化保存的,不是聊完就忘,每个邮箱可以设置不同的系统提示词(说白了就是可以给客服邮箱和销售邮箱设定不同的"性格"和职责范围)。
架构长这样:一个 React 写的网页前端(用户在浏览器里看到的收件箱界面),通过 WebSocket 连着一个用 Hono 框架写的 Worker 后端。这个后端一边管理各个独立的邮箱 Durable Object,一边管理智能体的 Durable Object,两边互不越界又能协同工作。
技术栈上前端是 React 19 + React Router v7 + Tailwind CSS,富文本编辑器用的是 TipTap(很多现代邮件、笔记应用都在用这个);后端是 Hono + Durable Objects + R2;鉴权靠 Cloudflare Access 来做身份校验。整个仓库 99.8% 都是 TypeScript 写的,算是一套挺现代化的技术选型。
部署这事儿有多简单
理论上讲,你不需要自己开服务器、装数据库、配邮件网关,大致流程是:
- 确认你的域名 DNS 已经托管在 Cloudflare(没有的话先把 NS 改过去或者直接转入,免费)。
- 点一下项目 README 里的"Deploy to Cloudflare"按钮,它会自动帮你把 R2 存储桶、Durable Objects、Workers AI 这些依赖都配好。
- 回到 Cloudflare 控制台,在你的域名上开启 Email Routing,并把规则设置成"全部转发到这个 Worker"。
- 打开你部署好的网页,给你想要的邮箱地址(比如
[email protected])创建一个邮箱实例。 - 配置一下 Cloudflare Access,这是用来限制"谁能登录看这个邮箱后台"的门禁系统。
前后加起来,一个熟悉 Cloudflare 的开发者大概十几分钟就能把整套东西跑起来。
顺带说一句成本:项目代码本身完全免费开源。跑起来之后,收信(Email Routing)在任何套餐上都免费;发信给你账户里"已验证"的地址每月有 3000 封免费额度;但如果要像真实客服场景那样回复任意陌生人的邮件,就得升级到 Workers 付费套餐,起步价每月 5 美元,再加上 Durable Objects、R2、Workers AI 超出免费额度部分的用量计费。简单说就是"个人小范围试玩基本免费,真要对外提供服务,一个月几美元起"。
说句实在话:它也有需要留意的地方
项目的文档里其实很坦诚地写了一条安全提示,我觉得挺值得单独拎出来说说:只要通过了 Cloudflare Access 的登录验证,任何人都能看到这个系统里的所有邮箱,包括通过 MCP 协议接进来的外部工具(比如 Claude Code、Cursor 这类编程助手)。也就是说,它目前是"整个系统一道门",而不是"每个邮箱单独一道门"——没有做到按邮箱粒度的权限隔离。
这对个人用、小团队用问题不大,但如果你打算拿它去放好几个客户、好几个部门的邮箱,一人一把钥匙的模式暂时是没有的,想上生产环境的话这点得自己额外加一层权限控制,或者干脆按团队/客户拆分成多个独立部署(这也是为什么前面建议用子域名区分不同用途)。作为一个"参考实现"项目,这种取舍其实挺合理——它本来的定位就是给开发者一个可以照着改的骨架,而不是开箱即用的成品 SaaS。
顺带一提:它还能接进 Claude Code 这类工具
因为内置了 MCP(Model Context Protocol)服务器,这意味着像 Claude Code、Cursor 这样的编程 AI 工具,理论上可以直接连接到你部署的这个邮箱系统上,让它们代你起草邮件、查询邮件内容,草稿写好之后还是要回到 Agentic Inbox 的界面里人工确认再发送。这也呼应了前面说的那个设计哲学:AI 可以插手很多环节,但"点发送"这个最后的按钮,始终留给人来按。
GitHub项目地址：https://github.com/cloudflare/agentic-inbox
写在最后
Agentic Inbox 本身不是什么颠覆性的产品,它更像是一份"作业示范"——Cloudflare 想告诉所有开发者:你完全可以拿自己手头现成的域名,配合邮件路由、Durable Objects、R2 和 AI 模型这几块积木,搭出一个真正能用的、有记忆、会干活的邮件智能体系统,而且全程不用自己管服务器。
如果你正好有一个闲置的域名,又在琢磨怎么给自己的产品接一个能自动处理邮件的 AI 客服,或者单纯好奇现在的 Serverless + AI Agent 组合能玩出什么花样,这个项目值得拉下来跑一跑、读一读源码。毕竟比起看十篇讲"智能体架构"的理论文章,直接打开一个几千行代码、真能用自己域名收发邮件的项目,理解起来快多了。
