Cloudflare 用自建容器重写 Browser Run，拼完六层 Agent 基础设施

预计阅读时间：9 分钟

Cloudflare 刚把 Browser Run 从第三方托管迁移到自家 Containers 平台上跑，并发能力翻了 4 倍、响应时间砍掉一半。这件事本身是个性能升级，但更值得注意的是——它把 Cloudflare 的 Agent 基础设施拼到了第六层，从计算到交易，一条链路全部收在边缘网络里。

为什么 Browser Run 要重写

Browser Run 是 Cloudflare 给 Agent 提供的"眼睛"——让 AI 代理能打开真实浏览器、渲染页面、提取内容、执行交互。之前的实现跑在外部托管容器上，每次调用都要跨网络调度，冷启动慢、并发上限卡在别人的资源池里。

迁移到自建 Containers 之后，Browser Run 的浏览器实例直接在 Cloudflare 边缘节点上拉起，调度路径短了、资源池大了。实测数据：并发从原来的瓶颈水平拉到 4 倍，响应时间压缩 50%。对 Agent 场景来说，这意味着同一个任务可以并行开更多浏览器标签页，抓取和交互的等待时间大幅缩短。

六层 Agent 基础设施全貌

Browser Run 补上之后，Cloudflare 的 Agent栈完整了六层：

层级	组件	职责
计算	Dynamic Workers + Sandboxes	执行逻辑、隔离运行
编排	Dynamic Workflows	多步骤任务串联与状态管理
记忆	Agent Memory	跨会话持久化上下文
浏览	Browser Run	真实浏览器渲染与交互
交易	Stripe Projects	支付与商业闭环

每一层都在边缘节点上运行，不需要回源到某个中心机房。Agent 从"思考"到"动手"到"收钱"，整条链路不离开 Cloudflare 网络。

用 Workers + Browser Rendering 写一个网页摘要 Agent

下面是一个可以直接部署到 Cloudflare Workers 的最小 Agent 示例——它接收一个 URL，用 Browser Rendering 打开页面、提取正文，再返回摘要。这个例子把计算层和浏览层串起来，是六层栈中最核心的两层协作。

// worker.js — 部署到 Cloudflare Workers
export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    const targetUrl = url.searchParams.get("url");
    if (!targetUrl) {
      return new Response("Usage: ?url=https://example.com", { status: 400 });
    }

    // 1. 通过 Browser Rendering API 启动浏览器会话
    const browser = await env.BROWSER.launch();
    const page = await browser.newPage();

    // 2. 导航到目标页面
    await page.goto(targetUrl, { waitUntil: "networkidle" });

    // 3. 提取页面正文内容
    const content = await page.evaluate(() => {
      // 粗略提取：取所有 <p> 标签文本
      const paragraphs = document.querySelectorAll("p");
      return Array.from(paragraphs)
        .map(p => p.innerText.trim())
        .filter(t => t.length > 20)
        .join("\n");
    });

    // 4. 关闭浏览器释放资源
    await browser.close();

    // 5. 返回提取结果（可在此接入 LLM 做摘要）
    return new Response(JSON.stringify({
      url: targetUrl,
      content: content.slice(0, 2000), // 截断防止过大
      length: content.length
    }), {
      headers: { "Content-Type": "application/json" }
    });
  }
};

对应的 wrangler.toml 配置：

name = "web-summary-agent"
main = "worker.js"
compatibility_date = "2024-09-23"

# 绑定 Browser Rendering 服务
[browser]
binding = "BROWSER"

部署命令：

npx wrangler deploy

调用示例：

curl "https://web-summary-agent.your-subdomain.workers.dev/?url=https://blog.cloudflare.com/browser-rendering-api/"

注意事项： Browser Rendering API 目前有并发限制和单次会话时长上限（约 60 秒），生产环境需要做好超时兜底和错误重试。上面的例子省略了这些处理，实际部署时建议加上 try/catch 和 setTimeout 保护。

把编排层和记忆层串进来

单步提取只是起点。真实 Agent 通常需要多轮操作——先搜索、再筛选、再提取、再总结。Cloudflare 的 Dynamic Workflows 就是干这个的。

一个典型的多步 Workflow 大致结构如下：

// workflow.ts — Cloudflare Dynamic Workflows 示意
import { Workflow } from "cloudflare:workflows";

export class ResearchAgent extends Workflow {
  async run(event: WorkflowEvent, step: WorkflowStep) {
    // 步骤 1：搜索相关页面
    const searchResults = await step.do("search", {
      retries: { max: 3 },
    }, async () => {
      // 调用搜索 API 或 Browser 搜索
      return [{ url: "https://..." }, { url: "https://..." }];
    });

    // 步骤 2：逐个提取页面内容
    const contents = await step.do("extract", async () => {
      const results = [];
      for (const item of searchResults) {
        // 每个页面用 Browser Run 提取
        results.push(await extractWithBrowser(item.url));
      }
      return results;
    });

    // 步骤 3：用 LLM 生成摘要，写入 Agent Memory
    const summary = await step.do("summarize", async () => {
      // 调用 Workers AI 或外部 LLM
      return await summarizeText(contents.join("\n"));
    });

    // 步骤 4：持久化到 Agent Memory
    await step.do("remember", async () => {
      await env.AGENT_MEMORY.put(event.sessionId, summary);
    });

    return summary;
  }
}

Workflow 的关键优势是步骤级重试——某一步失败只重试那一步，不用从头跑。这对浏览器操作尤其重要，因为网页加载失败是常态。

交易层：Stripe Projects 收尾

第六层 Stripe Projects 让 Agent 能在任务末端触发支付——比如 Agent 替用户完成数据采集后自动扣费。这一层目前集成度还在早期，但架构位置已经明确：Agent 不只是"干活"，还要能"收钱"，形成商业闭环。

采用建议与风险边界

适合上 Cloudflare Agent栈的场景：

网页数据采集与监控——Browser Run 的并发提升直接利好批量抓取
多步骤自动化流程——Workflow 的步骤级重试比自建重试逻辑可靠
需要跨会话记忆的对话型 Agent——Agent Memory 解决了 KV 存储的上下文问题

需要谨慎的地方：

Browser Rendering 单次会话时长有限，长时间交互（比如填多步表单）可能需要拆成多次会话
Containers 平台刚承接 Browser Run，资源调度策略还在迭代，大规模生产部署建议先做压测
六层栈每层都有独立定价模型，组合使用时成本核算要提前做——并发翻 4 倍意味着浏览器实例费用也可能翻 4 倍
Agent Memory 目前是 KV 存储，不适合需要复杂查询的场景，重关系型数据还是要外接数据库

快速验证清单：

先用单层（Workers + Browser Rendering）跑通一个最小 Agent
确认目标页面的加载时间在 Browser Run 会话时限内
加 Workflow 做多步编排，验证步骤级重试是否符合预期
上 Agent Memory 前评估数据结构——KV 适合扁平键值，不适合嵌套查询
生产上线前做并发压测，观察 Containers 资源分配是否稳定

Cloudflare 这六层栈的完整度已经够搭一个端到端 Agent 了，但每一层的成熟度不同。Browser Run 的性能跃升是实打实的，编排和记忆层还在快速迭代，交易层刚起步。现在入场，建议从浏览+计算两层切入，逐步叠加其他层——而不是一上来就六层全用。