当每个客户都想跑自己的代码，云厂商怎么接招

Cloudflare 的开发者平台正在经历一场静默的架构革命。八年前，Workers 是个直接面向开发者的工具；今天，它要解决的问题变成：如何让成千上万个互不相识的租户，在同一台机器上安全地运行彼此从未见过的代码。

上个月 Dynamic Workers 开放测试，让平台方能在毫秒级启动隔离的代码沙箱。Durable Object Facets 把同样的思路搬到存储——每个动态加载的应用都能按需获得独立的 SQLite 数据库。Artifacts 则搞定了版本控制。现在，最后一个拼图来了：Dynamic Workflows。

从"绑定一个类"到"每个租户一个工作流"

Workflows 是 Cloudflare 的持久化执行引擎。它把 run(event, step) 函数变成能扛住故障、能睡上几天、能等外部事件、能在隔离环境回收后精确恢复的程序。V2 版本已经能支撑单账户 5 万个并发实例、每秒 300 个新实例——明显是为 agent 时代设计的。

但有个前提一直没变：工作流代码得是你部署的一部分。

wrangler.jsonc 里写死一个类名，一次部署对应一个绑定。你自己写代码，这没问题。可一旦想让客户提交自己的工作流逻辑，这套模型就卡住了。

想象这些场景：AI 应用平台为每个租户生成 TypeScript；CI/CD 产品里每个仓库定义独立流水线；agent SDK 让每个 agent 自己写持久化执行计划。每个租户、每个请求的工作流都不一样，没有"一个类"可以绑定。

这正是 Dynamic Workers 解决过的计算层问题，也是 Durable Object Facets 解决过的存储层问题。Workflows 成了最后一块没松动的铁板。

Dynamic Workflows 的解法：把执行引擎和代码解耦

新方案的核心改动是：Workflows 不再要求代码预先部署。平台可以在运行时传入任意代码，引擎照样保证持久化语义——失败重试、休眠唤醒、事件等待、精确恢复，一个不少。

技术实现上，这依赖 Workers 平台已有的隔离能力。Dynamic Workers 证明了毫秒级冷启动沙箱的可行性；Durable Object Facets 证明了动态存储分片的可行性。Workflows 现在把持久化状态机和动态代码加载拼在一起，让"每个租户一个工作流"从架构负担变成常规操作。

对平台方来说，这意味着可以暴露更原生的编程接口。不用再让客户把逻辑拆成"配置"塞进你的 DSL，直接给 TypeScript 就行。AI 生成的代码、用户手写的代码、agent 自举的代码，一视同仁。

为什么这指向了 multi-tenant 架构的终局形态

Cloudflare 这三步棋——Dynamic Workers、Durable Object Facets、Dynamic Workflows——拼出的是一个完整图景：计算、存储、执行流，全部变成可按租户动态实例化的资源。

这不是简单的功能叠加。传统 multi-tenant 架构要么共享代码（限制客户自由度），要么完全隔离（成本爆炸）。新模型走的是第三条路：共享物理机，但每个租户获得逻辑上独立的运行时、数据库、工作流状态机。隔离性由底层平台保证，客户感知不到彼此存在。

Artifacts 的版本控制系统让这套模型更完整。现在一个租户的工作流可以有完整的生命周期：代码版本化、状态持久化、执行可观测——而平台方只扮演监督者角色。

对 25-40 岁的技术从业者来说，这个信号很清晰：下一代应用平台的竞争焦点，正在从"功能丰富度"转向"架构自由度"。谁能让客户以最自然的编程方式表达业务逻辑，同时不牺牲隔离性和可靠性，谁就能吃掉 SaaS 的下一波红利。

如果你正在设计需要支持客户自定义逻辑的平台——无论是 AI 应用构建器、自动化工作流工具，还是垂直领域的 CI/CD 产品——现在需要重新评估技术选型了。托管 Kubernetes 或传统 FaaS 可能还在你的候选清单上，但 Cloudflare 这套动态原语组合已经定义了新的基准线：毫秒级启动、租户级隔离、持久化语义内建。这不是"可能更好"的选项，而是"客户会期待"的默认配置。