地址要自有，苦力可以外包

一个开源项目把"邮箱"重新对准了 agent 时代：自部署到 Cloudflare 的邮箱系统，设计目标就写在简介里——人和 agent 一起使用。仓库：github.com/wong2/cf-mailr…

"人和 agent 共用"这五个字，值得从今晚的收件格那条接起来读。此前讲"一个入口全收"，解决的是人的收件分散；这次的野心更大——收件人本身不再只是人：agent 也需要一个能收、能读、能回的地址，去接验证码、通知、任务回执、另一个 agent 发来的协作请求。

当邮件从人际通道变成机际通道，"收件箱"就从人类的待办清单，升格成了系统的事件总线——这与"记录是触发的入口"是同一判断的另一种实现：谁的邮箱谁触发，agent 有了邮箱，就有了自己的触发源。

"自部署到 Cloudflare"这个选法同样想得清楚。邮箱系统的传统痛点是运维：域名、DKIM、SPF、收发服务，一套下来是专职活计；压到 Cloudflare 之上，等于把基础设施的重活交给平台、把地址的所有权留给自己——这与今晚"装自己家才敢喂真资料""平台是租来的摊位、域名才是地契"是一脉相承的选择：地址要自有，苦力可以外包。对个人与小团队，这是把"拥有一个收件系统"的成本压到了能接受的量级。

安全的账也因此要重新算。agent 能读的邮箱，就是 agent 能被诱导执行的入口——每一封进来的邮件都可能是一次 prompt 注入的投递；今晨刚发过"自我复制注入"的警告，摆在这里格外刺眼：人机共用收件箱意味着过滤器必须按"有人可能替机器读信"的标准来设计——外发链接、陌生发件人、带指令的正文，这些在人眼里是可疑、在 agent 眼里可能就是命令。共用的前提，是给机器那半边装上人早就有的直觉。

给要部署的人一句落地的：装完先做一次"agent 视角"的收件测试——让 agent 读一封你故意写脏的邮件（内含一条让它执行操作的指令），看它会不会照办；这封测试信不过关，你的邮箱就还不能给 agent 用。过关之后再开最小权限：只读某个标签、只回执不外发——先把信任的闸门拧到最小，再一格格放。