Agentic Inbox 是 Cloudflare 开源的邮件客户端，Apache-2.0 许可，整个应用跑在 Cloudflare Workers 上。收件走 Cloudflare Email Routing，每个邮箱隔离在独立的 Durable Object 和 SQLite 里，附件存到 R2；AI Agent 用 Cloudflare Agents SDK 和 Workers AI 实现，可以读收件箱、搜索会话、起草回复。
把邮箱交给 Worker 和 Agent
在自有域名上收信，通常要么用托管邮箱，要么自己维护 SMTP、IMAP、反垃圾和存储。Agentic Inbox 提供了第三条路：域名和邮件路由交给 Cloudflare，界面和业务逻辑跑在 Worker 里，数据落在账号自己的 Durable Object 和 R2 中。想给邮箱加一个能读上下文、会起草回复的助手，又不想为此维护一台邮件服务器，这个项目就是为这种需求准备的。
部署链路
最省事的方式是从仓库的 Deploy to Cloudflare 按钮开始。部署流程会创建 R2、Durable Objects 和 Workers AI 绑定，并询问要接收邮件的域名。按钮只完成一半，后面还有几步：
- 在 Worker 的 Settings → Domains & Routes 里启用一键 Cloudflare Access，把弹窗里的
POLICY_AUD和TEAM_DOMAIN写成 Worker secret。 - 在域名的 Email Routing 里建一条 catch-all 规则，转发到这个 Worker。
- 确认 Worker 有
send_email绑定，否则只能收不能发。 - 打开部署好的应用，为域名下的地址创建邮箱，例如
hello@example.com。
本地开发需要 Node、Wrangler 和 Cloudflare 账号：
npm install |
以上步骤按官方 README 整理，未在本机完整实测。生产环境必须配置 Cloudflare Access，未配置时应用会直接报错，这是有意为之。
Agent 能做什么
邮件客户端该有的部分基本齐全：富文本编辑、回复与转发线程、文件夹、搜索和附件。AI 助手在侧边栏里，带 9 个邮件工具，覆盖读取、搜索、起草和发送。新邮件到达时可以自动生成草稿，但发送前始终需要人工确认，不会替你做最终决定。
每个邮箱可以配置自己的 system prompt，聊天记录持久保存，回复以流式 markdown 呈现，工具调用过程也可见。应用还暴露了 /mcp，Claude Code、Cursor 这类外部工具可以通过 MCP 操作邮箱，调用时传 mailboxId 指定目标。
一个小团队的共享收件箱
设想一个两三人团队，用 hello@ 接咨询、用 billing@ 接账单。Agent 先在侧边栏里总结当天的新邮件，把需要回复的挑出来，按邮箱的提示词起草一版；人看过、改完再发。重复问题可以快速处理，真正的判断仍留在人这边。因为所有邮箱共享同一个 Access 策略，这个方案更适合小团队内部互信的场景，不适合把不同客户的邮箱放在同一个实例里做隔离。
与自建邮件服务器、托管邮箱的区别
Mailcow、Postfix 这类方案要自己维护 SMTP/IMAP、反垃圾、证书和磁盘，换来完整的邮件协议控制。Agentic Inbox 的收发依赖 Cloudflare Email Routing 和 Email Service，本身不是通用邮件服务器，离开 Cloudflare 就跑不起来。和 Gmail 加 AI 插件相比，它把数据放在自己的 Cloudflare 账号里，代码可改；代价是要自己承担部署、域名和 Access 配置。
权限边界与锁定风险
README 明确说明：任何通过共享 Access 策略的用户都能访问应用里的所有邮箱，没有按邮箱的授权；MCP 端点同样可以操作任意邮箱，唯一信任边界就是 Cloudflare Access。这不是可以忽略的细节，部署前要先想清楚谁能进这个 Access 策略。
其他限制也很实际：需要自有域名和 Cloudflare 账号，Workers AI 的模型和额度受平台约束，邮件送达率取决于 Cloudflare 的邮件服务。AI 生成的摘要和草稿可能误读上下文，自动发送必须保持关闭。
适合的部署场景
适合已经在 Cloudflare 上管理域名、希望用自己账号收信并尝试 AI 邮件工作流的小团队或独立开发者。没有 Workers 经验、或需要严格按邮箱隔离权限的组织，应该先用测试域名验证，再考虑是否上线。
官方入口
- 仓库：cloudflare/agentic-inbox
- 背景文章：Email for Agents
- 许可：Apache-2.0