★ FEATURED ARTICLE 一条公告改变了两条产品路线一个正在使用 Deno Deploy 承载定时任务的团队今天最该担心的不是新版本能不能运行而是半年后服务应该运行在哪里。二〇二六年十月九日Deno 创始人 Ryan Dahl 和 Cloudflare 的 Kenton Varda 分别发布了官方公告Deno 团队整体加入 Cloudflare未来的重点不再是继续维持一条独立的运行时与托管平台产品线而是让 Workers 与 Durable Objects 更容易部署到开发者自己控制的基础设施。公告给出了明确的期限Deno Deploy 还将运行六个月Deno 运行时将继续提供一年的每月错误修复与安全更新随后停止官方开发。这不是“Deno 明天无法使用”更不是“Cloudflare 将自动接管所有 Deno 应用”。Deno 运行时保持开源JSR 软件包注册服务将继续运营并迁移到 Cloudflare 的基础设施rusty_v8 也会获得持续支持。真正发生变化的是产品路线过去开发者可以把 Deno 作为运行时把 Deploy 作为托管平台围绕一套独立生态构建服务接下来原团队的研发资源将投入 Cloudflare 的通用执行模型并尝试把 celld 的设计融入 workerd。这件事对 AI Agent 工程格外敏感。传统网站的迁移通常围绕 HTTP 接口、静态资源和数据库展开智能体任务还经常包含长时间等待、工具回调、会话状态、WebSocket、重试以及不可逆的外部操作。即使新平台兼容相同的 JavaScript 语法也不能据此断言后台任务语义、持久化状态、调度方式与权限边界完全相同。如果把“编译能够通过”误当成“业务可以切换”迁移中的一次重复执行就可能变成重复通知、重复收费或者对外部系统写入两次。本文只根据 Cloudflare 与 Deno 的两篇十月九日公告整理已确认的变化并将后续迁移设计明确作为工程建议而不是伪装成厂商已经承诺的特性。需要区分三种对象你在本地执行的 Deno 程序、已经托管在 Deno Deploy 的服务以及依赖 JSR 或 rusty_v8 的构建工具。它们受到的影响和迁移优先级完全不同不应因同一个品牌名称被放在同一张停服清单里。已确认的时间线六个月、一年与继续运行Deno 官方文字对期限的表达具有操作意义。Deploy 服务还会继续运营六个月然后关停官方将为付费客户迁移到 Cloudflare Workers 提供支持。Runtime 则继续一个年份的每月修复与安全更新在这一年之后结束由原团队主导的开发。JSR 没有被列入停止运营的清单官方表示会继续运行并把基础设施迁移到 Cloudflare。rusty_v8 也不是被宣布废弃而是继续维护并探索与 workerd 结合。这些事实来自 Deno 官方公告不能用论坛猜测替代。这里最容易产生三个误读。第一六个月并不等于每个组织从今天起都拥有同样的迁移工时合同、账单、依赖服务、平台功能和内部审批周期各不相同。第二一年维护不等于一年后程序立即不能启动开源软件仍然可以被社区维护它表示原团队公开承诺的更新窗口结束。第三“付费客户可以获得迁移支持”不能推导成免费客户一定有同等迁移服务也不能推导成每项功能都提供自动映射。需要核查自己的账号权益和服务依赖。为了避免把期限写成误导性的固定日期运营团队应把公告发布时间和各自合同约定的正式截止日放在同一记录中。可以先以十月九日作为启动盘点的事实锚点把半年和一年分别当成外部迁移约束在厂商发布更精确的下线时间、迁移文档或客户通知后再按官方信息更新计划。任何没有经过验证的具体停服时刻都不应直接写入生产定时器。对 Deno Deploy 应用优先收集配置与资产清单域名和路由、环境变量名、密钥保存位置、定时任务、持久化数据、区域需求、构建入口、权限策略、外部 API、WebSocket、健康检查、日志与告警。清单里必须写清每项资源的责任人而不只是记录“项目使用 Deno”。若一个定时任务每晚对用户发送消息它的迁移优先级可能高于一个日访问量很大的静态页面因为两端同时运行一晚就会让同一批用户收到双倍通知。Cloudflare 为什么看中 celld而不是重新发明一个 NodeCloudflare 的公告把合作核心放在 workerd 与 celld。workerd 是 Workers 编程模型的底层执行引擎celld 则尝试构造一套更容易自托管的服务器抽象。Ryan Dahl 在说明中强调复杂分布式应用不应该为了计算、数据库、队列与实时通信分别维护多套服务工程。他设想由多台 celld 实例加上一个对象存储桶承担基础依赖通过统一的抽象把应用状态与计算部署组织起来。这是他描述的设计目标而不是第三方已经验证的生产规模承诺。Cloudflare 对这套方案感兴趣还有一个历史包袱。Cloudflare 全球 Workers 网络依赖大量自家基础服务并不是把一个二进制放进机房就自动得到完整的边缘云体验。官方承认以往虽然想让 workerd 的自托管成为一等路径却缺乏足够时间把运行模型和开发体验整合起来。celld 的出现提供了另一种实现思路围绕兼容的 Workers 与 Durable Objects 原语把宿主规模与依赖复杂性收缩到更多组织可以管理的程度。工程师要特别注意所谓“兼容 Workers 模型”和“当前所有 Cloudflare 托管附加能力都可以完整自托管”不是一个命题。前者讨论代码能否使用类似的请求处理与状态对象接口后者还涉及权限、路由、持久化一致性、备份、跨区域故障转移、可观测性和供应商服务集成。公告没有列出一张逐项功能对照表也没有给出适用于每个现有 Deno Deploy 项目的无损转换承诺。迁移验收应当围绕真实业务行为而不是围绕营销式兼容百分比。这也解释了为什么 AI Agent 与 Durable Objects 的关系比普通请求处理更值得研究。一个智能体可能在一次对话里连续执行十几个工具调用期间出现连接中断、人工确认、执行超时或模型重试。把会话相关状态放在能够明确寻址、持久化和协调的对象里理论上比把全部状态堆在短命函数内存中更容易恢复。但 Durable Objects 不是天然的“恰好执行一次”保证只要外部工具无法与内部状态参加同一事务就依然存在成功写入之后回执丢失的模糊窗口。先界定迁移边界代码、状态、凭据与副作用迁移前至少要画出四条边界。第一条是执行边界从哪个入口接收请求、哪个定时器触发运行、并发限制在哪里执行。第二条是状态边界会话游标、任务进度、已完成步骤、队列确认、幂等键以及历史事件保存在哪里。第三条是安全边界服务以什么身份访问数据库、对象存储和第三方 API密钥何时读取哪些调用允许对公网发出。第四条是副作用边界真正改变用户或外部系统状态的动作有哪些是否能查询已执行结果失败后可否补偿。这四条边界应分别验证因为语法层兼容不会替工程师检查它们。一个在 Deno Deploy 上运行的 TypeScript 服务迁入新环境后可能依旧可以返回正确的 JSON但原来的定时器或数据库适配层已经变化。更危险的是第三方任务“发送一次邮件”变成“发送两次邮件”依然可能使所有 HTTP 健康检查都成功。每项操作必须带业务唯一键尽可能在外部系统支持的情况下提交幂等键如果对端没有幂等接口就保存待处理、已查询、已确认的状态并把未知结果送入核对流程而不是立即再调用一次。建议建立带有证据字段的迁移表包含原始项目标识、旧运行入口、新运行入口、最后一次真实运行时间、输入输出样例、外部副作用清单、依赖服务、数据持有者、回滚方案和验收负责人。单纯列一个“已迁移”复选框价值不大因为它无法回答失败时最重要的问题究竟哪些步骤已发生在旧平台哪些已发生在新平台哪些仍然未知只有把这些界线写下来团队才有办法把问题限制在一次任务内而不是因为不确定就大范围重跑。Agent 运行时迁移先验证断点恢复而非吞吐对需要保存对话和工具执行状态的智能体系统吞吐量通常不是第一项迁移验收指标。更有价值的测试是故意在最不方便的时刻中断程序模型已经完成一次工具决策、第三方接口已经接受请求、应用还没来得及写入最终回执。恢复后究竟重发、查询、等待还是放弃如果旧平台和新平台给出不同答案即使平均请求时延下降也不说明迁移成功。所谓稳定运行不只是健康检查持续返回成功还意味着已完成工作不会因换一个进程被重新解释。一种可操作的状态划分是准备、执行中、结果待核对、已确认、人工介入。业务代码负责定义允许的状态转移运行环境负责把变化持久化。发生中断时先从可信状态源恢复再查询第三方系统已发生的真实结果如果查询能力不存在就冻结该条任务让人工选择是否承担重复副作用的风险。技术上消息队列的“至少一次投递”与外部系统的“至多一次业务操作”需要通过业务键连接仅给队列设置重试次数无法跨越这两个系统之间没有分布式事务的事实。以自动撰写并发布文章的 Agent 为例正文生成和图片压缩都属于本地可重复的准备动作创建平台草稿通常可通过草稿标识恢复而点击发布、发邮件、付款或修改权限属于不可随意重试的动作。迁移时应把发布前检查点和发布后公开验证分开保存明确在哪个时刻首次进入不可逆窗口。即使 Cloudflare 和 Deno 的程序接口最终非常接近这套状态协议仍应由业务自己定义不能寄希望于平台自动识别每一种外部动作的含义。连接状态也容易制造假象。WebSocket 保持连接不等于服务端有可靠的任务恢复记录持久化保存会话键也不等于密钥仍有正确的权限。自托管 Durable Objects 的长期价值可能在于明确的状态归属与控制权但实现是否满足你的故障恢复目标必须通过断网、重启、存储异常、队列积压以及第三方接口重复回执等实验检验。在没有这些实验前任何“迁移后更可靠”的判断都只是待验证的假设。一个可运行的迁移盘点程序在正式修改部署配置之前可以先用简单的清单程序把迁移风险从人的印象转成可重复的排序。下面是独立运行的 Python 标准库程序无须访问厂商 API也不会修改任何云端资源。输入数据是示例记录实际使用时将每个项目的名称、托管位置、功能标签和责任人替换成自己已核实的信息。程序重点不是给出完美的风险概率而是统一团队讨论顺序是否运行在将关停的托管服务上、是否包含不可逆副作用、是否使用长期会话或实时连接以及是否能从旧环境导出并验证状态。from datetime import date, timedelta import json announced date(2026, 10, 9) deploy_review announced timedelta(days180) runtime_review announced timedelta(days365) projects [ { name: agent-publisher, platform: deno-deploy, features: [cron, websocket, external-write], state_export_tested: False, owner: agent-team, }, { name: js-package-build, platform: jsr, features: [package-read], state_export_tested: True, owner: build-team, }, { name: api-runtime, platform: self-hosted-deno, features: [http], state_export_tested: True, owner: api-team, }, ] def score(project): risk 0 if project[platform] deno-deploy: risk 5 if external-write in project[features]: risk 4 if websocket in project[features]: risk 2 if cron in project[features]: risk 2 if not project[state_export_tested]: risk 3 return risk report [] for item in sorted(projects, keyscore, reverseTrue): report.append({ project: item[name], owner: item[owner], risk_score: score(item), requires_migration: item[platform] deno-deploy, }) print(json.dumps({ planning_review_deploy: deploy_review.isoformat(), planning_review_runtime: runtime_review.isoformat(), projects: report, }, ensure_asciiFalse, indent2))这段代码的日期只是用于内部排期的观察点并非厂商承诺的正式关停日。半年直接换算成固定天数可能与日历月份不同因此生产上应以官方最终通知为准。风险分值也不是行业统一标准五分、四分这样的权重仅用于帮助组织从高风险业务开始盘点。它输出的是清单优先级不是自动迁移指令任何系统都不应该据此直接删除、关闭或迁移线上服务。把代码输出交给负责的工程师复核通常能立刻发现遗漏。比如托管页面看似只有一个 HTTP 入口实则用外部自动化任务定时触发平台元数据没有显示 WebSocket实际业务又把会话状态放进消息层。清单里除了特性名称还应附上来源链接、配置截图或仓库路径证明判断来自真实运行证据。若风险排序有争议先补证据再讨论分数比在会上争论“哪个项目看着更危险”更加有效。如何迁移而不让两套系统同时写出副作用迁移通常从一段只读并行期开始。新环境部署同样的代码和配置但只接收镜像流量不调用外部写接口团队比较请求输出、关键延迟、错误类型、路由逻辑和资源消耗。对于 LLM 相关服务不能假定模型输出完全一致因此验收指标要聚焦结构、权限、工具调用次数、数据来源和终态状态机而不是要求两次自然语言结果逐字相同。镜像流量中的用户隐私应遵守原有数据处理约束不得为了测试而复制到未经授权的新位置。第二步是状态导出和可恢复性演练。逐项确认任务游标、幂等键、队列偏移、会话令牌、缓存规则以及事务性数据的保存方式。建立一次受控的恢复实验在隔离环境复制非敏感测试数据模拟原平台中断启动新环境并核对待处理队列的每个身份。如果业务允许回滚必须提前验证回滚后不会把新环境完成的动作当成旧环境的未完成任务。备份文件存在只是必要条件能够准确恢复并且不会重复发送外部写请求才是切换的必要证据。第三步只迁移一小部分真实流量并把写入权集中在单一环境。入口层根据稳定的业务标识选择旧平台或新平台而不是每次请求随机抽签。对需要长期会话的 Agent可以按会话分配执行归属直到当前工作结束对消息任务可以按队列分区或任务键进行独占领用。关键约束是同一个业务键在任意时刻只有一个环境拥有向外部系统提交新动作的权限。否则所谓双活发布会悄悄成为双倍扣费、双倍邮件或重复文章。最后一步才是扩大比例和退役旧服务。发布前要记录错误率、恢复耗时、内存与 CPU 尾部分位、未确认任务数量、重复提交计数、外部 API 限流以及回滚成功率。每次扩大流量都应保留可观察的稳定窗口。如果第三方出现发布超时唯一正确的下一动作是查询原业务键的真实状态绝不能因为页面没有显示成功就自动再次点击发布。将这类机制在迁移前做好也能防止未来新平台出现网络抖动时重复同样的事故。部署账单之外还要核算谁来运维过去由托管平台承担的补丁、故障检测、容量扩展、负载均衡、访问日志、密钥轮换、备份恢复和高可用设计到了自有基础设施可能变成内部成本。Cloudflare 与 Deno 共同强调简化基础依赖不代表组织可以忽略这些运行责任。比较成本时至少要分开计算计算资源、持久化存储、出口流量、值班时间和事故恢复不能只比较每百万请求的单价。对于 AI Agent 工作流还要单独列出模型调用费、外部工具费用、向量或对象存储、人工审核工时和重复任务造成的浪费。一条使用 Durable Objects 保存状态的路径可能减少协调复杂度却并不会自动降低模型推理账单。如果应用原本在 Deno Deploy 上几乎没有流量强行为它配置一套需要自行运维的高可用集群反而可能把成本与故障面一起放大。同样应当对照供应商承诺与当前实现的边界。十月九日的公告说明两支团队将合并 celld 与 workerd 的想法与代码但没有公布完整迁移工具、功能兼容矩阵、SLA 或准确的长期价格。工程团队可以先启动清点和隔离演练暂时不应把尚未发布的功能写进未来生产架构的关键路径。对现有生产环境有时最稳妥的短期动作只是保存全部配置、更新依赖并安排迁移试验保持在线业务不动。今天应该立刻做的四件事第一件事是识别自己的真实使用面。区分运行时、部署平台、包注册与嵌入式 V8 接口避免由于看到同一个 Deno 名称就开展无差别迁移。把每个项目的责任人和版本补齐确认是否直接使用 Deno Deploy 付费服务能否获得官方迁移协助。特别要找出定时任务、长连接和不可逆写入因为这些功能的恢复语义往往比代码移植困难。第二件事是建立可以核对的基线。对现行系统固定一组经过脱敏的请求样本与真实业务键记录正常情况下的响应、状态变化、数据库写入、外部调用次数和失败时的回执。不要只记请求成功率也要记任务是否完成一次且仅一次。把当前部署版本与样本证据绑在一起以后才能判断新环境是否破坏了重要不变量。第三件事是设计最小的迁移实验。先挑选没有用户写入副作用的服务使用独立测试数据部署再针对一项可恢复的长任务模拟中途断线。确认检查点、重试、幂等键以及公开或外部结果核对都工作正常才把同样机制应用到有真实用户数据的服务。实验失败时只记录证据并调整对应实现不要让一次失败自动触发整个平台的批量重建。第四件事是给团队一个明确的停止条件。只要出现无法确认的外部写结果、账号权限不明确、回滚路径缺失、状态导出不完整或新旧环境同时持有写入权就应停止扩大流量保留现场并优先核对真实结果。停下扩容不等于中断全部业务可以继续在旧环境运行已知稳定的流量同时把故障范围限制在新迁移试验。这样的做法能让研发与生产并行而不会为了赶期限牺牲用户数据安全。Deno 的消息真正值得关注的是一个长期追求更简单 JavaScript 运行体验的团队把工作重心移向可自托管的分布式执行与持久化状态。六个月和一年是应当纳入排期的事实celld 与 workerd 的整合方向是可以提前研究的工程机会至于具体功能何时达到可生产状态需要后续发布与真实测试给出答案。对正在运营 Agent 服务的团队今天最有价值的动作不是立刻迁走所有代码而是弄清哪些状态与副作用必须被可靠地带到下一套系统。事实来源Deno 官方公告Deno is joining Cloudflare2026年10月9日Cloudflare 官方联合公告Deno is joining Cloudflare2026年10月9日。日期与产品承诺以两方后续正式通知为准本文的清单、风险评分、迁移顺序和演练流程属于明确标注的工程建议。
阅读完成 · 觉得有帮助？
