Cloudflare 发布了 Dynamic Workflows，这是一个基于 MIT 协议开源的库，用于扩展其持久化执行引擎，使工作流代码能够在运行时针对不同租户、Agent 或请求动态变化。
此前，Cloudflare Workflows 要求工作流代码必须作为部署的一部分存在，即每次部署对应一个 binding 和一个类。Dynamic Workflows 则移除了这一限制，使平台能够将每一次 create() 调用路由到不同租户的代码，并在工作流于数秒、数小时甚至数天后真正执行时，再将 run(event, step) 调度回对应租户的代码。
Cloudflare 工程团队的 Dan Lapid 与 Luís Duarte 写道：
假设你正在构建一个应用平台，其中 AI 会为每个租户生成 TypeScript 代码；或者你正在开发一个 CI/CD 产品，每个代码仓库都有自己的流水线；再或者你正在使用某种 Agent SDK，而每个 Agent 都会生成自己的持久化执行计划。在这些场景中，工作流对于每个租户、每个 Agent、每次请求来说都是不同的，因此根本不存在一个统一可绑定的类。
该库本身大约只有 300 行 TypeScript 代码。其核心机制是在 Workflows 引擎与租户代码（Dynamic Worker）之间加入一个 Worker Loader，用于在工作流恢复执行时，将请求重新路由到正确租户。
当租户调用 env.WORKFLOWS.create(...) 时，表面上看仍然像普通的 Workflow binding；但在底层，Worker Loader 会为调用附加租户元数据，由 Workflows 引擎持久化这些信息。当后续某个步骤被唤醒执行时，系统便能依据这些元数据重新定位到对应租户的代码。
与此同时，Workflow ID、暂停/恢复、重试、休眠、step.sleep('24 hours') 以及 step.waitForEvent() 等能力都无需修改即可继续使用。
import { createDynamicWorkflowEntrypoint, DynamicWorkflowBinding, wrapWorkflowBinding } from '@cloudflare/dynamic-workflows';export { DynamicWorkflowBinding };function loadTenant(env, tenantId) { return env.LOADER.get(tenantId, async () => ({ compatibilityDate: '2026-01-01', mainModule: 'index.js', modules: { 'index.js': await fetchTenantCode(tenantId) }, env: { WORKFLOWS: wrapWorkflowBinding({ tenantId }) }, }));}export const DynamicWorkflow = createDynamicWorkflowEntrypoint( async ({ env, metadata }) => { const stub = loadTenant(env, metadata.tenantId); return stub.getEntrypoint('TenantWorkflow'); });在 CI/CD 场景中，这一架构带来的影响尤为明显。Cloudflare 在博客中展示了一个完整流水线示例：流水线代码直接存放在客户仓库中，并以 TypeScript WorkflowEntrypoint 的形式存在；平台按需动态加载这些代码，而流水线中的每一步都具备完整的持久化执行能力。
Cloudflare 在这里将四项基础设施能力组合在一起：
Artifacts：提供基于 Git 的版本化存储，支持懒加载树结构（lazy tree hydration）以及针对每次 CI 运行的即时
fork()Dynamic Workers：运行轻量级步骤，例如 lint、类型检查和打包，这些隔离环境能够在毫秒级启动
Dynamic Workflows：负责维持整个执行流程，支持持久化、可重试步骤，并能在等待审批期间免费休眠
Sandboxes：负责需要完整操作系统环境的重型任务，并通过基于快照的预热启动机制，将启动时间缩短至数秒
If realized, this collapses the infrastructure cost of running a multi-tenant platform dramatically: idle tenants cost approximately nothing, active tenants share hardware through isolate-level multi-tenancy. In Cloudflare's framing, a platform that used to cap at thousands of paying customers can now reasonably serve tens of millions.
Cloudflare 将这一方案与传统 CI 流程进行了对比。传统 CI 往往需要先分配虚拟机、拉取基础镜像、克隆仓库并安装依赖，仅准备阶段就可能耗费一分钟以上，真正执行任务之前已经产生大量额外开销。而 Dynamic Workflows 的架构则省去了这些“仪式性步骤”：代码仓库无需移动，而计算能力会直接靠近代码。
Cloudflare 对这一平台战略的描述也非常明确。Dynamic Workers 解决了多租户动态代码的计算层问题；Durable Object Facets 则通过为每个动态加载的应用提供独立 SQLite 数据库，解决了存储层问题；而现在，Dynamic Workflows 则补齐了持久化执行层。
Cloudflare 表示，目前 Workers 提供的所有 binding，未来都将拥有对应的动态版本，包括队列、缓存、数据库、AI binding 以及 MCP Server 等。这些能力最终都能够按租户、按 Agent、按请求进行动态分发，并且在空闲状态下几乎没有成本。
如果这一愿景最终实现，多租户平台的基础设施成本将被大幅压缩：空闲租户几乎不会产生额外成本，而活跃租户则通过 isolate 级多租户机制共享硬件资源。按照 Cloudflare 的说法，一个过去只能支撑数千付费客户的平台，未来有可能扩展到服务数千万用户。
对于 Agent 平台而言，Dynamic Workflows 的意义尤其明显。Agent 现在可以直接编写自己的 run(event, step) 函数作为持久化执行计划，其中每一步都可以独立重试，每次 sleep 都能免费休眠，而每个 waitForEvent() 都能无限期暂停，等待人工审批。换句话说：Agent 负责编写执行计划，平台负责运行它，而双方都不需要提前知道这个计划最终会是什么样子。
在按租户动态持久化执行这一方向上，目前市场竞争仍相对有限。Temporal 与 Inngest 都提供持久化执行引擎，但都无法像 Dynamic Workflows 一样，在隔离级别上实现按租户动态加载代码。AWS Step Functions 虽然支持动态状态机，但仍要求预先定义任务结构。Cloudflare 当前这种“运行时代码加载 + V8 isolate 级隔离 + 边缘分布式执行”的组合，在业内仍具有明显独特性。
目前，@cloudflare/dynamic-workflows 已在 npm 上发布，并构建于 Dynamic Workers（目前为 Workers 付费计划中的公开 Beta 功能）之上。官方仓库还提供了可运行示例以及交互式浏览器 Playground。
