一个曾经想把 Node 重做一遍的项目，突然给自己写下了倒计时。

Deno 官方博客宣布，整个 Deno 团队加入 Cloudflare。

同一份公告里，时间表也很直接：Deno runtime 再维护一年，Deno Deploy 运营六个月后关闭。

如果只看标题，像一场收购。

往下看，更像一次开发者平台路线的换轨。

一个理想主义运行时，先学会了妥协

Deno 一开始想解决的问题很直接：服务器软件能不能更简单一点。

模块怎么分发，JavaScript 运行时能不能有安全保证，一个完整工具链应该包含什么，应用能不能直接打包成独立可执行文件。

这些问题，Deno 都碰过。

后来，兼容 Node.js 也成了重要工作。

原因不复杂，用户想要 Deno 的改进，也想继续接入现有 JS 生态。

老实讲，这一步很现实。

一个运行时再有理想，也要面对 npm 生态这座大山。

Deno 团队自己说，他们和社区一起做出了一个把这些能力整合起来的运行时，也挑战了 JS 开发原本的样子。

但挑战归挑战，故事走到这里，已经能看见一个信号：单靠一个运行时，不够了。

从 Deno 到 Deploy，再到 celld：真正想做的是少搭积木

Ryan Dahl 提到，他的野心从来不止于 runtime。

他写过 JavaScript Containers，核心想法是让计算、存储、通信协同工作，应用不必各自拼装基础设施。

Deno Deploy 就是这个方向的一步。

目标很明确：让运行应用尽可能简单。

但做 Deploy 的过程，反而让他们看见底层还有多少复杂。

于是有了 celld。

它建立在 Cloudflare Workers 编程模型上，让开发者从一开始就能构建分布式应用，同时把系统运维做得更简单。

Ryan Dahl 最兴奋的一点是，扩展能力被写进编程模型，而不是每个应用自己拼基础设施。

这句话很关键。

过去开发者关心的是代码怎么写。

现在平台关心的是状态、连接、扩展、故障、迁移，能不能一开始就藏在模型里。

表面是 Deno 被收购，真正的主角是 Workers 和 Durable Objects

这次加入 Cloudflare 后，Deno 团队会和 Workers 与 Durable Objects 团队合并工作。

他们想把这套编程模型变成构建服务器的默认方式。

注意，官方说的是无论跑在 Cloudflare 网络，还是自己的基础设施上。

这意味着他们想推的并不只是一个云服务。

更像一套可复制的分布式应用底座。

这也是整件事最有意思的反转。

Deno 的名字在公告里仍然显眼，但未来开发重心已经转向共享平台。

Deno runtime 进入维护期。

Deno Deploy 进入关停倒计时。

celld、Workers、Durable Objects 站到了舞台中央。

AI Agent 一来，后端抽象突然变得更急

公告里还有一个很直接的判断：AI 让更好抽象的需求变得更迫切。

Durable Objects 被点名，因为它把几类能力放在了一起。

便宜的 serverless 执行。

持久状态。

WebSockets。

高层 JavaScript 接口。

这些能力对 agent harness 很合适。

说白了，AI agent 不只要跑一段函数。

它要保存状态，要维持连接，要协调多个任务，还要能低成本扩展。

Ryan Dahl 说，这是他最想探索的方向，也是 celld 聚焦 Durable Objects 的原因。

个人觉得，这里比收购本身更值得盯住。

JS 运行时之争原本已经够卷。

AI agent 一来，竞争点又从跑代码，变成跑长期运行、带状态、可协调的分布式系统。

社区并不平静：有人告别，有人早就预感

热门评论里，情绪很复杂。

有人盯着官方时间表：

We will support the Deno runtime for another year with monthly releases containing bug fixes and security updates. After that year we will end our development of the Deno runtime.

这位网友补了一句：如果没有人接手开发，Deno 就不会再有人支持。

也有人说自己很难过。

I'm so bummed about this. Deno is by far my favourite JS runtime.

还有人喜欢早期 Deno，但在 npm 兼容成为优先事项后就停下了。

评论认为，Deno 的表面从漂亮简单变得臃肿，团队可能感受到 VC 资金压力，放弃了从第一性原理重建 Node 的路线。

这点我不太认同。

兼容生态未必是原罪，但它确实会改变一个项目的重心。

更尖锐的说法也在评论区出现：

"Deno development effectively shut down via a Cloudflare acquihire" would be a better headline.

这句话刺耳，但确实戳中了一个事实：Deno 作为独立产品路线，明显降权了。

当然，也有人把目光放在技术延续上。

有人关心 workerd 会不会吸收 Deno 的安全机制，成为更好的沙箱。

有人更关注 celld 模型并入 workerd，认为用对象存储引导持久化和协调，能简化自托管。

还有人说，Deno 直接从包仓库或 git 仓库导入、无需 package.json 的能力，真的很好用。

这些声音放在一起，很难不感慨。

一个项目被喜欢，往往因为它有棱角。

一个项目被收购，常常是因为棱角要装进更大的机器。

开发者真正要看的，是这几条时间表

对已经用 Deno 写项目的人，公告给了明确安排。

Deno runtime 还会支持一年。

这一年里，每月发布 bug 修复和安全更新。

一年之后，Deno 团队结束对 runtime 的开发。

Deno 仍然开源，也欢迎其他人继续开发。

Deno Deploy 会继续运营六个月，然后关闭。

付费客户迁移到 Cloudflare Workers 时，会获得迁移支持。

JSR 继续运营。

基础设施会迁移到 Cloudflare。

rusty_v8 继续支持。

团队还会推动它整合进 workerd。

说实话，这套安排不算突然断电。

但也不算宽松。

一年 runtime 维护，六个月 Deploy 过渡，对企业用户和独立开发者都不算长。

尤其那些把 Deno Deploy 当成托管平台的人，接下来要做的只有一件事：评估迁移。

Deno 仍然开源，JSR、rusty_v8 也还会继续。可它作为独立运行时和托管服务的主线，已经明显降权。

真正被推到前面的，是 Workers、Durable Objects、celld，以及 AI agent 时代的分布式应用平台。

如果没人接住开源社区，那个曾经让人眼前一亮的运行时，会不会慢慢只剩名字？

【锐评】：Deno 的退场不算意外，真正值得盯住的是 Cloudflare 想把 AI agent 后端标准握在手里。

参考链接：
https://deno.com/blog/cloudflare