Deno 团队加入 Cloudflare 的消息，于 2026 年 10 月 9 日由 Deno 创始人 Ryan Dahl 在 Deno 官方博客公布，Cloudflare 官方博客同日刊文确认了后续计划。这不是一次普通的人才流动：整支团队并入的同时，Deno 自家的托管服务 Deno Deploy 进入关停倒计时，独立运行时也只剩一年官方维护期。
Cloudflare 真正缺的，是能自托管的 Durable Objects
Cloudflare 在同日刊文中把短板说得很直接：开源运行时 workerd 虽然与它的生产环境同源，但其中的 Durable Objects 只实现了单实例版本，够本地测试，却撑不起规模化自托管；它自家生产用的对象路由系统又依赖遍布全球的节点和一整套外部服务，不适合搬进客户自己的机房。Deno 团队 2026 年 8 月发布的 celld 正好补上这一块，它是 Workers 与 Durable Objects 的开源实现，从设计上就面向自托管和横向扩展。接下来 Ryan Dahl 与 Bert Belder 将牵头把 celld 的代码与思路并回 workerd，让自托管成为 Workers 编程模型的一等公民，更多细节会在接下来几个月公布。
两个倒计时：Deploy 半年，运行时一年
对正在用 Deno 的团队来说，时间表比愿景更要紧。Deno Deploy 还会运行六个月，随后关停，付费用户会得到迁往 Cloudflare Workers 的迁移支持；Deno 运行时在接下来一年里继续按月发布缺陷与安全修复，之后原团队停止开发，代码仍保持开源，社区可以接手；包注册表 JSR 继续运营，基础设施迁到 Cloudflare；底层组件 rusty_v8 也会继续维护，目标是并入 workerd。按六个月推算，2027 年 4 月前后还跑在 Deploy 上的服务必须完成迁移，这个窗口从公布之日就已经开始计算。
为什么智能体开发者也在看这件事
Dahl 在公布文中专门点到了智能体场景：Durable Objects 把廉价的无服务器执行、持久状态和 WebSocket 实时连接装进一个对象里，恰好是长时间运行的智能体框架需要的底座，他还邀请正在规模化构建智能体的团队直接与他联系。结合本站此前报道的 Cloudflare 智能体流量数据——智能体流量已经反超人类流量——执行层往哪里收拢，直接决定智能体产品的成本结构和部署边界。如果 Workers 能无差别地跑在 Cloudflare 网络和客户自有服务器上，智能体厂商就不必在“用平台的便利”和“让数据不出内网”之间二选一。
当然，承诺兑现之前，一切都还是路线图：workerd 的自托管周边工具此前恰恰是 Cloudflare 自己承认没做好的部分，Deno 团队的加入能不能补上，要看接下来几个月的实际交付。对 Deno 用户来说，判断可以更简单：先按 Deploy 的关停时间表准备迁移，再观察 workerd 的自托管版本是否值得跟进。
