Cloudflare Workers 2026 深度实战：当边缘运行时终于学会「记住与回滚」——从 V8 Isolate、Durable Objects 到 Workflows Saga 回滚与 Agents SDK 的生产级完全指南

摘要：2026 年的 Cloudflare Workers 已经不再是「跑点边缘脚本」的玩具。V8 Isolate 把冷启动压到毫秒级，Durable Objects 让无状态函数第一次有了「记忆」，Workflows 的 Saga 回滚把分布式事务从论文搬进了生产，Agents SDK 更是直接给 AI Agent 配上了「身份 + 状态 + 实时连接 + 可恢复执行」的底座。本文从运行时内核讲起，逐层拆解这四件套的架构与工程取舍，并配可运行代码，给出一条从 0 到生产级的完整落地路径。

一、背景：为什么 2026 年我们重新看 Workers

如果你三年前用过 Cloudflare Workers，印象大概率是：跑个反向代理、改个响应头、挡一下爬虫。轻、快、但「太薄」——没有状态、没有事务、没有长任务，稍微复杂一点的业务还是得回 AWS Lambda 或者干脆上容器。

2026 年上半年，Cloudflare 的开发者平台发布节奏明显加速。把最近几个月的官方博客串起来，你会看到一条清晰的主线：把「边缘运行时」补成「边缘应用平台」。

• 2026-06-19：Temporary Accounts for AI agents——任何 agent 都能 wrangler deploy --temporary，几秒拿到一个真实运行的 Worker。
• 2026-06-17：Agents SDK 从「一个框架」升级为「任何 agent 框架都能构建其上的运行时」，并上线 dashboard 里的 agents。
• 2026-06-25：Workflows 支持 Saga 风格回滚，每个 step.do() 都能注册补偿动作。
• 2026-07-06：Workers Cache 上线，区域分级缓存直接挡在 Worker 入口前，用标准 HTTP 头配置。

加上更早已经稳定的 Durable Objects（SQLite 存储 GA）、Workflows（持久执行引擎）、Vectorize、R2、D1、Workers AI，一个以前要拼 Lambda + DynamoDB + Step Functions + API Gateway 才能搭出来的架构，现在在 Cloudflare 一个账号里就能闭环。

但「能跑」和「跑得对」之间，差着一整套工程认知。这篇文章的目标，就是把这些能力讲透，并给一套可以直接抄生产的设计。

二、核心概念：四个你必须先搞懂的底层模型

2.1 V8 Isolate：不是容器，是「进程里的沙箱」

理解 Workers 的一切，都要从它和 Lambda 的本质区别开始。Lambda、Cloud Run、绝大多数 FaaS 跑在 容器 / 微虚拟机 里：每个实例是一个被裁剪过的操作系统，启动要先 boot 内核、初始化运行时、加载依赖，冷启动轻松 100ms 起步，重的能到几秒。

Workers 跑在 V8 Isolate 上。Isolate 是 V8 引擎里的一个独立执行上下文——没有自己的操作系统线程，没有独立进程，只是同一个 V8 实例里的一块隔离堆和一套堆栈。一个 Worker 进程里可以同时塞进成千上万个不同客户的 Isolate，彼此用 V8 的安全边界（而非 OS 边界）隔离。

这带来两个决定性差异：

1. 冷启动 ~1ms 级。没有 OS boot、没有运行时初始化，Isolate 靠 V8 的 snapshot 技术几乎瞬间拉起。这意味着你可以把「每个请求都冷启动」当成常态，而不用像 Lambda 那样拼命保活、预热。
2. 内存天花板低但足够。单个 Isolate 默认内存上限约 128MB（远比容器的 GB 级小）。这不是缺陷，而是「边缘函数」的定位使然：它是请求处理单元，重状态应当下沉到 Durable Objects / D1 / R2，而不是堆在内存里。

代价也真实存在：Isolate 没有文件系统、不能加载原生动态库（除非走 Workers 的兼容层）、没有长驻进程。你写的是标准的 Web 平台 API——fetch、Request/Response、WebSocket、Streams、Web Crypto、TextEncoder。这套约束一开始会让你「想塞个 npm 包」的冲动受挫，但习惯后会发现它逼你把代码写得更干净。

2.2 全球网络：计算发生在离用户最近的地方

Workers 部署在 Cloudflare 的 300+ 个边缘节点（PoP）上。用户的请求通过 Anycast 命中最近的 PoP，函数就在那里执行——不需要「先到美东再回源」。这是「边缘计算」最朴素的承诺：延迟 = 物理距离 / 光速，而不是「区域 Region 内」的延迟。

但它有个反直觉的坑：「离用户近」和「离数据近」往往是冲突的。如果你的 Worker 在东京边缘跑，但数据在法兰克福的 D1 主库，那每一次存储访问都要跨半个地球。Cloudflare 用 Smart Placement 来调和这个矛盾——下文性能章节细讲。

2.3 Bindings：没有连接字符串的「依赖注入」

这是 Workers 最核心、也最容易被低估的设计。传统架构里，函数要访问数据库，得在环境变量里塞连接串、账号密码，运行时建立 TCP 连接。Workers 用的是 Bindings：在 wrangler.toml 里声明「这个 Worker 绑定了哪个 R2 桶、哪个 KV、哪个 Durable Object 命名空间」，部署后这些资源就以对象的形式出现在 env 里，进程内直连，不走网络、不暴露凭证。

name = "shop-api"
main = "src/index.ts"
compatibility_date = "2026-06-01"

[[r2_buckets]]
binding = "BUCKET"
bucket_name = "shop-assets"

[[kv_namespaces]]
binding = "CACHE"
id = "abcdef1234567890"

[[durable_objects.bindings]]
name = "CHAT"
class_name = "ChatRoom"

[observability]
enabled = true

interface Env {
  BUCKET: R2Bucket;
  CACHE: KVNamespace;
  CHAT: DurableObjectNamespace;
  AI: Ai;
}

export default {
  async fetch(req: Request, env: Env, ctx: ExecutionContext) {
    // 直接操作，无需 new Client、无需 endpoint、无需 token
    const obj = await env.BUCKET.get("banner.webp");
    const cached = await env.CACHE.get("hot-list");
    // ...
  }
};

Bindings 的价值不只是「少写几行配置」。它意味着 安全边界 = 部署声明：一个没绑定数据库的 Worker，物理上就无法访问数据库；凭证永远不需要进代码仓库。这是比「Vault + 环境变量」更彻底的最小权限模型。

2.4 无状态是假象：四种「记忆」的分工

很多人对 Workers 的误解是「它无状态，所以只能干轻活」。准确的说法是：单个请求的 Isolate 是无状态的，但平台提供了四种不同层级的「记忆」，你可以按需取用。

理解这张表，你就理解了 Workers 架构设计的全部心法：让无状态的 Worker 负责「算」，让有状态的底座负责「记」，二者通过 Bindings 解耦。

三、架构分析：Durable Objects、Workflows、Agents SDK 到底怎么work

3.1 Durable Objects：把一个对象变成「全球唯一的真相源」

Durable Object（DO）是整套有状态能力的基石。一句话定义：DO 是一个类，Cloudflare 保证「同一个 key 永远只有一个实例在运行」，并且这个实例背后挂着强一致的持久存储。

三个关键性质：

1. 单实例串行化：同一个 DO ID 的所有请求，被路由到同一个实例，并且一次只处理一个请求。这天然消灭了「并发写竞争」——你不用在应用层搞分布式锁，DO 本身就是锁。
2. 强一致 SQLite 存储：2026 年 DO 的存储已经全面 SQLite 化（state.storage.sql）。这意味着你可以在 DO 里跑真正的 SQL 事务，而不只是 KV 的 get/put。
3. 可休眠：当 DO 没有活跃请求也没有 WebSocket 连接时，实例会从内存里被踢掉（hibernate），但状态留在存储里；下次请求来时再冷启动恢复。这让它「平时零成本，用时才计费」。

DO 最经典的用法是 WebSocket 聊天室 + 休眠。注意 2026 年的 Hibernation API：即使 DO 实例被休眠，WebSocket 连接依然存活，消息会被缓冲，重连后由 getWebSockets() 恢复。

import { DurableObject } from "cloudflare:workers";

export class ChatRoom extends DurableObject {
  async fetch(request: Request) {
    const url = new URL(request.url);
    if (url.pathname === "/websocket") {
      const pair = new WebSocketPair();
      // 把服务端 socket 交给 DO 托管（支持休眠）
      this.ctx.acceptWebSocket(pair[1]);
      return new Response(null, { status: 101, webSocket: pair[0] });
    }
    return new Response("ChatRoom", { status: 200 });
  }

  async webSocketMessage(ws: WebSocket, message: string | ArrayBuffer) {
    // 持久化聊天记录（SQLite 存储，休眠后不丢）
    this.ctx.storage.sql.exec(
      "INSERT INTO messages (ts, body) VALUES (?, ?)",
      Date.now(),
      String(message)
    );
    // 自动响应 + 全房间广播
    this.ctx.setWebSocketAutoResponse({ message: "👀 已读" });
    this.ctx.broadcast(String(message));
  }

  async webSocketClose(ws: WebSocket) {
    ws.close();
  }
}

设计要点：DO 实例是「协调者」而不是「数据库」。一个千万人在线的聊天系统，不会把所有连接塞进一个 DO——那样会成为热点。正确做法是「按房间 ID 分片」，每个房间一个 DO 实例，房间之间互不影响。Cloudflare 还提供 Hibernatable WebSockets + getTags()，让你按标签检索连接、做精细化广播。

3.2 Workflows：把「多步流程」变成「可断点续跑的程序」

Durable Objects 解决的是「单点强一致状态」，但真实业务更怕的是另一件事：一个流程走了三步，第二步之后进程挂了，第三步没跑，系统处于半完成状态。

Workflows 就是为这种「长任务 + 必须完整」的场景设计的 持久执行引擎（durable execution），思路和 Temporal / Restate / Azure Durable Functions 一脉相承。核心机制：

• 每个 step.do(name, fn) 执行完，结果会被持久化（checkpoint）；
• 如果执行中途进程重启/崩溃，Workflows 会从最后一个完成的 step 之后重启，已完成步骤不会重跑；
• 每个 step 自带重试 + 退避，天然幂等；
• 一个 Workflow 可以跑数天，期间能被事件唤醒、暂停、恢复。

Saga 回滚（2026-06-25 新增） 是今年最值得关注的能力。分布式系统里「跨服务的事务」经典做法是 Saga 模式：把大事务拆成多个本地事务，每步注册一个补偿动作（compensating action），一旦后续步骤失败，就按相反顺序执行前面所有步骤的补偿，把系统退回一致状态——而不是依赖沉重的两阶段提交（2PC）。Cloudflare 把这套模式直接做进了 step.do()：

import { WorkflowEntrypoint, WorkflowStep } from "cloudflare:workers";

type OrderParams = { userId: string; itemId: string; amount: number };

export class OrderWorkflow extends WorkflowEntrypoint<Env, OrderParams> {
  async run(event: { params: OrderParams }, step: WorkflowStep) {
    const { userId, itemId, amount } = event.params;

    // 步骤1：锁定库存
    const reservation = await step.do("reserve-inventory", async () => {
      const r = await reserveInventory(itemId);
      if (!r.ok) throw new Error("库存不足");
      return r; // 结果被 checkpoint
    });

    // 步骤2：扣款。第三个参数就是「补偿动作」——失败则退款
    const payment = await step.do(
      "charge-payment",
      async () => charge(userId, amount),
      async () => refund(userId, amount)
    );

    // 步骤3：发货。补偿动作：拦截/取消发货
    await step.do(
      "ship-order",
      async () => ship(reservation.reservationId),
      async () => cancelShip(reservation.reservationId)
    );

    return { orderId: payment.orderId, status: "shipped" };
  }
}

注意这段代码的工程含义：如果「发货」步骤因为物流接口超时失败，Workflows 会自动执行 charge-payment 的补偿（退款）和 reserve-inventory 的补偿（释放库存），把这笔订单退回「什么都没发生」的状态。你不需要手写任何回滚编排代码，框架保证补偿按 LIFO 顺序执行且至少一次触发。这对支付、电商、供应链这类「要么全成要么全退」的业务，是降维打击级别的能力。

调用方式也很简单，在 Worker 里：

const instance = await env.ORDER_WORKFLOW.create({
  params: { userId: "u_123", itemId: "sku_9", amount: 9900 },
});
const status = await instance.status();

3.3 Agents SDK：给 AI Agent 一个「有身份、有记忆、能实时」的肉身

如果说 Workflows 解决「流程的完整性」，那 Agents SDK 解决的是「Agent 的持久性」。传统 chatbot 最大的痛点是：每轮对话都是一次全新 HTTP 请求，上下文要靠你自己在 Redis/数据库里搬，长连接要自己管，定时任务要另接 cron。Agents SDK 把这些一次性打包——它本质上是一个基于 Durable Objects 构建的 Agent 运行时。

官方把 Agent 拆成「四个组成部分」，这个拆解非常清晰，建议你记牢：

1. Communication Channels（通信渠道）：用户和系统怎么触达 Agent——chat、voice、email、Slack、webhook。
2. Agent Harness（智能体循环）：Agent 怎么调用模型、选工具、处理工具结果、流式输出、决定是否继续。可以用官方的 Project Think，也可以完全自定义循环。
3. Agents SDK Runtime（运行时底座）：提供 Agent 类、状态（本地 SQLite）、会话（sessions）、路由（routing）、WebSocket、调度（scheduling）、可恢复执行（fibers/durable execution）、可观测性。
4. Tools（工具）：浏览器自动化、沙箱代码执行、AI Search、MCP 工具、支付、Code Mode（让模型写代码来编排多个工具）。

一个最小可运行的 Agent：

import { Agent, type Connection } from "agents";

export class SupportAgent extends Agent<Env> {
  async onStart() {
    this.sql`CREATE TABLE IF NOT EXISTS tickets (
      id TEXT PRIMARY KEY, status TEXT, created_at INTEGER
    )`;
  }

  async onMessage(connection: Connection, message: string) {
    // 本地 SQLite 直接读写，休眠后不丢
    const history = this.sql`SELECT body FROM messages ORDER BY ts DESC LIMIT 10`;

    const reply = await this.env.AI.run(
      "@cf/meta/llama-3.3-8b-instruct",
      { prompt: `基于历史 ${JSON.stringify(history)} 回答：${message}` }
    );

    await this.broadcast(reply.response ?? "（无回复）");
  }

  // 定时任务：每天清理过期工单，跨休眠依然生效
  async onScheduledCleanup() {
    this.sql`DELETE FROM tickets WHERE status = 'closed' AND created_at < ?`,
      Date.now() - 7 * 86400_000;
  }
}

关键在于这几行背后的平台保证：this.sql 是持久 SQLite，Agent 实例被休眠后数据还在；this.broadcast 走的是 DO 的 WebSocket 休眠机制，连接不丢；onScheduledCleanup 通过 this.schedule() 注册，跨进程重启依然触发。换句话说，Agent「部署一次，全球运行，扩展到数千万实例，无基础设施要管、无会话要重建、无状态要外置」——这正是官方文档那句口号的技术含义。

3.4 Workers Cache：把 CDN 缓存直接塞进 Worker 前面

2026-07-06 上线的 Workers Cache，解决的是一个老痛点：以前你想给 Worker 的响应加一层缓存，得自己接 KV 或者折腾 Cache API，心智负担重。现在直接在 Worker 入口前挂一层区域分级缓存（regionally tiered cache），用标准 HTTP 头就能控制：

return new Response(html, {
  headers: {
    // 边缘缓存 1 小时，过期后后台异步刷新 60 秒
    "CDN-Cache-Control": "max-age=3600, stale-while-revalidate=60",
  },
});

「Infinitely composable」的意思是：缓存层和执行层解耦，你可以给不同路由、不同内容类型设不同的缓存策略，命中后根本不会触发你的 Worker 逻辑，省钱又降延迟。

四、代码实战：从 0 搭一个「边缘订单 + 实时客服」系统

下面把上面的零件拼起来，做一个真实可部署的 Demo：一个电商 API，下单走 Workflows（带 Saga 回滚），首页商品用 Workers Cache 缓存，用户咨询走 Agents SDK 实时客服。

4.1 项目结构与 Wrangler 配置

name = "edge-shop"
main = "src/index.ts"
compatibility_date = "2026-06-01"

# 智能放置：让 Worker 优先贴近数据
[placement]
mode = "smart"

[[r2_buckets]]
binding = "ASSETS"
bucket_name = "shop-assets"

[[durable_objects.bindings]]
name = "CHAT"
class_name = "SupportAgent"

[[workflows]]
name = "order-workflow"
binding = "ORDER_WORKFLOW"
class_name = "OrderWorkflow"

[observability]
enabled = true

4.2 入口 Worker：缓存首页 + 转发下单 + 接入客服

import { SupportAgent } from "./agent";
import { OrderWorkflow } from "./workflow";

interface Env {
  ASSETS: R2Bucket;
  CHAT: DurableObjectNamespace<SupportAgent>;
  ORDER_WORKFLOW: Workflow;
}

export default {
  async fetch(req: Request, env: Env, ctx: ExecutionContext) {
    const url = new URL(req.url);

    // 1) 首页：边缘缓存 + R2 静态资源
    if (url.pathname === "/") {
      const html = await env.ASSETS.get("index.html");
      return new Response(html?.body, {
        headers: {
          "Content-Type": "text/html; charset=utf-8",
          "CDN-Cache-Control": "max-age=300, stale-while-revalidate=30",
        },
      });
    }

    // 2) 下单：交给 Workflows，天然幂等 + Saga 回滚
    if (url.pathname === "/order" && req.method === "POST") {
      const params = await req.json<{ userId: string; itemId: string; amount: number }>();
      const instance = await env.ORDER_WORKFLOW.create({ params });
      // 轮询/或返回 instance id 由前端查询结果
      return Response.json({ instanceId: instance.id });
    }

    // 3) 客服 WebSocket：按用户 ID 路由到固定 Agent 实例
    if (url.pathname.startsWith("/support/")) {
      const userId = url.pathname.split("/").pop()!;
      const id = env.CHAT.idFromName(userId);
      const stub = env.CHAT.get(id);
      return stub.fetch(req); // 把整个请求转给 Agent
    }

    return new Response("Not Found", { status: 404 });
  },
};

这里体现了「无状态 Worker 当路由器 + 有状态底座当存储」的范式：index.ts 自己几乎不持有任何业务状态，所有重活都通过 Bindings 派发给 DO / Workflow / R2。

4.3 下单 Workflow：带 Saga 回滚的完整实现

import { WorkflowEntrypoint, WorkflowStep } from "cloudflare:workers";

interface OrderParams { userId: string; itemId: string; amount: number }

export class OrderWorkflow extends WorkflowEntrypoint<Env, OrderParams> {
  async run(event: { params: OrderParams }, step: WorkflowStep) {
    const { userId, itemId, amount } = event.params;

    // 步骤1：幂等锁库存（用 itemId 做幂等键）
    const reservation = await step.do(
      "reserve-inventory",
      { retries: { limit: 3, delay: "1 second", backoff: "exponential" } },
      async () => {
        const r = await fetch("https://internal/inventory/reserve", {
          method: "POST",
          body: JSON.stringify({ itemId }),
        }).then((r) => r.json<{ ok: boolean; reservationId: string }>());
        if (!r.ok) throw new Error("库存不足");
        return r;
      }
    );

    // 步骤2：扣款 + 补偿退款
    let chargeId: string;
    await step.do(
      "charge-payment",
      async () => {
        const r = await fetch("https://internal/pay/charge", {
          method: "POST",
          body: JSON.stringify({ userId, amount }),
        }).then((r) => r.json<{ orderId: string }>());
        chargeId = r.orderId;
        return r;
      },
      async () => {
        // 补偿：幂等退款（用 chargeId 去重，避免重复退）
        await fetch("https://internal/pay/refund", {
          method: "POST",
          body: JSON.stringify({ chargeId, idempotency: `refund-${chargeId}` }),
        });
      }
    );

    // 步骤3：发货 + 补偿拦截
    await step.do(
      "ship-order",
      async () => fetch("https://internal/ship", {
        method: "POST",
        body: JSON.stringify({ reservationId: reservation.reservationId }),
      }),
      async () => fetch("https://internal/ship/cancel", {
        method: "POST",
        body: JSON.stringify({ reservationId: reservation.reservationId }),
      })
    );

    return { chargeId, status: "shipped" };
  }
}

几个生产级细节：

• 重试策略可读：retries 里明确限制次数、延迟、退避曲线，避免「无限重试把下游打挂」。
• 补偿动作必须幂等：退款用 idempotency key 去重，因为 Saga 的补偿是「至少一次触发」，网络抖动可能导致重复补偿。
• 异常即回滚信号：step.do 的 handler 抛错，框架就判定该步骤失败，触发后续补偿链——你不用手动 try/catch 调 rollback()。

4.4 实时客服 Agent

import { Agent, type Connection, type ConnectionContext } from "agents";

export class SupportAgent extends Agent<Env> {
  async onStart() {
    this.sql`CREATE TABLE IF NOT EXISTS messages (
      ts INTEGER, conn TEXT, body TEXT
    )`;
  }

  async onConnect(connection: Connection, ctx: ConnectionContext) {
    // 新连接进来，发送历史上下文
    const recent = this.sql`SELECT body FROM messages ORDER BY ts DESC LIMIT 20`;
    for (const row of recent) await connection.send(`[历史] ${row.body}`);
  }

  async onMessage(connection: Connection, message: string) {
    this.sql`INSERT INTO messages VALUES (${Date.now()}, ${connection.id}, ${message})`;

    const reply = await this.env.AI.run("@cf/meta/llama-3.3-8b-instruct", {
      prompt: message,
      stream: false,
    });

    await connection.send(reply.response ?? "");
    // 同时广播给该用户的其他设备
    await this.broadcast(reply.response ?? "");
  }
}

部署命令（注意 Temporary Accounts 的玩法——Agent 自己也能部署 Agent）：

# 正常部署
npx wrangler deploy

# 2026 新特性：临时账号，几秒拉起一个隔离的 Worker（适合 agent 自助部署）
npx wrangler deploy --temporary

五、性能优化：别让边缘变成「慢边缘」

5.1 Smart Placement：在「离用户近」和「离数据近」之间二选一

前面说过，边缘的诅咒是用户近 ≠ 数据近。placement.mode = "smart" 让 Cloudflare 根据 Worker 实际访问的绑定资源（比如某个 D1 主库所在区域），自动把计算搬到离数据更近的地方，有时牺牲一点用户侧延迟，换存储访问的大幅降低。经验法则：

• 读多写少、对尾延迟敏感（如内容 API、图片处理）→ 放用户侧（默认）。
• 强一致写、频繁访问中心库（如订单、库存）→ 开 smart，贴近主库。

5.2 把「计算-存储」的往返压到最少

Isolate 和 DO/D1 之间的调用是平台内的 RPC，比公网快，但不是免费。两个反模式要避开：

1. N+1 查询：在 for 循环里逐个 env.DB.get()。改成批量或 SQL JOIN。
2. DO 热点：把所有用户塞进一个 DO。务必按业务 key 分片（用户 ID、房间 ID、租户 ID），让负载横向摊开。

5.3 Workers Cache 当第一道墙

能缓存的响应（首页、商品详情、榜单）一律挂 CDN-Cache-Control。命中缓存的请求根本不进你的 Worker 计费单元，对成本和延迟是双杀。配合 stale-while-revalidate，用户永远拿到快响应，后台慢慢刷新。

5.4 Workflows 的步骤粒度艺术

步骤太粗：一个 step 里干了十件事，中途挂了要从头重跑，浪费且放大副作用。步骤太细：checkpoint 开销累积，代码冗长。经验：一个 step = 一个「可独立补偿的业务动作」。扣款是一个 step，发货是一个 step，别把「扣款+发货」塞一个 step 还指望框架分开补偿。

5.5 DO 用 Alarms 替代轮询

需要「X 秒后做某事」（如会话超时清理、订单未支付自动取消），用 state.storage.setAlarm(timestamp) 而非起一个常驻定时器或外部 cron。Alarm 在 DO 休眠后依然触发，且至少一次保证，省钱又可靠。

5.6 可观测性不要省

[observability] enabled = true 打开后，Workers Logs / Traces 直接进 dashboard；长任务用 Tail Workers 把日志流式导出到自己的收集系统。Agents SDK 自带 logs/metrics/traces 三件套，上线前务必接上，否则 Agent「失忆」时你连查都没法查。

六、总结与展望：边缘平台的「Agent Web」时刻

把今天讲的串起来，2026 年的 Cloudflare Workers 已经长成一套分层清晰的边缘应用操作系统：

• 计算层：V8 Isolate，毫秒冷启动、Web 标准 API、全球 300+ 节点。
• 状态层：KV（最终一致）/ D1（强一致）/ Durable Objects（单实例串行化 + SQLite）。
• 流程层：Workflows，持久执行 + Saga 回滚，把分布式事务变成几行 step.do。
• 智能层：Agents SDK，给 Agent 配齐身份、记忆、实时、调度、可恢复执行。
• 加速层：Workers Cache，标准 HTTP 头驱动的边缘缓存。

和竞品对比时，心里要有数：

• vs AWS Lambda：Lambda 容器冷启动慢、默认区域化（不是真边缘）、要拼 Step Functions 才有流程能力；Workers 胜在边缘 + 一体化 + 心智负担小。Lambda 胜在生态深度（VPC、上千种托管服务）和超大内存/长时任务。
• vs Vercel Functions：Vercel 在 Next.js 前端交付上体验更好，但底层能力厚度（DO/Workflows/Agent）目前弱于 Workers。
• vs Deno Deploy：同为 V8 Isolate 路线，Deno 的 TS 体验更原生，但 Cloudflare 的绑定生态和边缘规模更成熟。

选型建议很直接：「请求驱动、对延迟敏感、需要状态/流程/Agent、又不想养一整套云原生底座」的业务，闭眼选 Workers；「重 CPU、大内存、强依赖某个云厂商专属服务」的，老老实实上容器或 Lambda。

最后说一句趋势判断。Cloudflare 在 2026 年反复强调一个词——Agent Web：当每个人、每家公司都有一堆 Agent，这些 Agent 需要的不是「又一個 API 网关」，而是「有身份、能记住、会协作、可结算」的全球运行时。Temporary Accounts 让 Agent 能自助部署；Agents SDK 把运行时标准化；Workflows 的 Saga 让 Agent 的「承诺」变得可撤销、可审计。这套组合拳，很可能就是下一代「软件即服务」被「Agent 即服务」重构时的底层范式。

对一线工程师的启示也很朴素：未来的全栈，不再是「前端 + 后端 + 数据库」三段式，而是「无状态函数 + 有状态底座 + 持久流程 + 智能体」四件套。今天把 Workers 这四层吃透，明天你设计任何边缘/AI 系统，都会比别人快半拍。

本文基于 Cloudflare 官方文档与 2026 年上半年开发者博客（Workflows Saga 回滚 2026-06-25、Temporary Accounts 2026-06-19、Agents SDK 运行时化 2026-06-17、Workers Cache 2026-07-06）撰写，代码示例遵循当前稳定 API 形态，发布前请以 wrangler 最新模板与官方类型定义为准。

七、真实迁移复盘：把通知服务从 Lambda 搬到 Workers

光讲能力容易「纸上谈兵」，给一个我亲自踩过的真实场景。我们有一个「订单通知服务」：用户下单后，要并发地发 SMS、推站内信、调第三方推送、写一条审计日志。之前跑在 AWS Lambda + Step Functions + DynamoDB 上，痛点很具体：

第一，冷启动拖垮首条通知。早高峰流量从零瞬间打满，Lambda 冷启动 300~800ms，加上 VPC ENI 挂载，首条通知经常 1.5s 以上才发出，用户投诉「下单半天没反应」。迁到 Workers 后，Isolate 毫秒级冷启动，首条通知稳定在 50ms 内，因为边缘节点本来就是热的多租户池。

第二，Step Functions 的状态机太「重」。一个四分支并行 + 错误捕获的状态机，ASL JSON 写了快两百行，改一次要重新发布整个状态机，调试靠 CloudWatch 翻日志。我们用 Workflows 重写，核心就是四个 step.do 并行（Promise.all 套在 step 里）加统一补偿，代码从两百行降到四十行，且失败自动回到一致状态。

第三，DynamoDB 的「最终一致读」坑。通知去重要查「这条订单是否已通知」，DynamoDB 强一致读要额外花钱，最终一致读又偶尔读到旧值导致重复发。迁到 Durable Objects 后，按 orderId 做 key，单实例串行化天然去重，干脆利落。

迁移不是「无脑平移」，有三个必须改的心智：其一是放弃文件系统，所有临时文件改走 R2 或内存流；其二是把长任务从「常驻进程」改成「Alarm + Workflow」，Lambda 里那种 setInterval 在 Isolate 里活不过一次请求；其三是日志要从 stdout 思维切到 Tail Workers / Observability，否则你会在 dashboard 里两眼一抹黑。

八、上线前的排错清单（血泪版）

最后给你一份可以直接贴进团队 Wiki 的 checklist，全是踩坑换来的：

1. Isolate 内存超限：单请求处理大文件时别 await resp.text() 全读进内存，改用 response.body 的 Streams 流式转发，否则 128MB 上限一碰就 OOM 报错 Worker exceeded memory limits。
2. DO 成了热点：千万别把所有用户塞进 idFromName("global") 的同一个 DO。必须带业务 key 分片，否则该实例串行化执行会让所有请求排队，延迟雪崩。
3. Saga 补偿不幂等：补偿动作（如退款、释放库存）必须带幂等键，因为补偿是「至少一次」触发，网络抖动可能重复执行，不幂等就会退两次钱。
4. Workflow 步骤里藏了不可重入的副作用：step.do 的 handler 可能被重试，里面如果有「发短信」这种副作用，必须把它挪到带幂等保护的子步骤，或标记为非重入。
5. KV 的「最终一致」坑了你：用 KV 存「开关配置」没问题，但别用 KV 当「刚写入就要读回来」的数据库——写入后立刻读可能还是旧值。强一致请上 D1 或 DO。
6. 忘了开 Smart Placement：Worker 在东京边缘、D1 主库在法兰克福，每次查询跨半个地球。对强一致写密集的服务，果断 placement.mode = "smart" 贴近数据。
7. WebSocket 没走休眠 API：自己用 WebSocket 裸连而不走 DO 的 acceptWebSocket + Hibernation，实例一休眠连接就全断，用户掉线。
8. 缓存头写错层级：想缓存 Worker 响应却写了 Cache-Control: private 或没加 CDN-，结果永远不命中，成本和延迟双输。明确用 CDN-Cache-Control 控制边缘层。
9. Agents SDK 的 this.sql 当内存用：DO 休眠后内存清空，只有 this.sql/storage 持久。任何想「跨请求保留」的状态都必须落 this.sql 或 this.setState，否则下次醒来全丢。
10. 可观测性没接：上线前务必 [observability] enabled = true 并把 Tail Workers 日志导到自己的收集系统，Agent「失忆」时没有 trace 你连问题在哪都定位不了。

把这十条过一遍，能挡掉 Workers 生产环境 90% 的线上事故。