Cloudflare Agent 电脑方案调研：远程桌面、Browser Run 与 Computer 工作区

Cloudflare Computer

AI 参与说明（Agent：Codex）：本文依据 Cloudflare 官方文档、Cloudflare Computer 公开仓库与 noVNC 项目资料辅助整理，资料日期为 2026-10-20。产品能力与费用以对应官方来源为准；文中的桌面组合是待实现的架构方案，成本算例采用明确假设，不代表运行基准。

Cloudflare 可以承载一套让 Agent 使用云端环境、让用户观看并接管的产品。选择取决于任务需要什么：操作网页可以直接使用 Browser Run；编辑文件和运行工具可以使用 Computer 或 Sandboxes；需要完整 Linux 桌面时，则使用 Containers，再加入桌面环境、VNC 和 Agent 控制接口。

决定架构之前，先把四种能力拆开：任务与权限由应用管理，程序由执行环境运行，画面由远程浏览器或 VNC 传输，文件与任务结果由持久化存储保留。这些能力可以组合，但其中一项的存在不会自动带来其余几项。

先按产品体验选择路线

Browser Run 的 Live View、Human in the Loop、Session Recording 当前仍标为 Beta。Computer 则应按组件判断成熟度：Workspace 与 JavaScript 后端为 stable，ContainerBackend 与 WorkerShellBackend 为 experimental。选择托管服务可以减少需要维护的组件，但仍要检查所依赖的具体功能状态。Browser Run、Computer 状态表

Workers 能连接 VNC 但不能运行 Linux 桌面

Workers 支持 WebSocket，也支持通过 cloudflare:sockets 发起出站 TCP。因此可以在 Worker 中实现 WebSocket 与 TCP 的桥接，将 noVNC 接到可达的 VNC Server。这个判断来自两种传输能力的组合；VNC Server 和桌面仍需运行在支持原生进程的环境中。WebSockets、TCP sockets

Workers do not accept raw TCP connections directly from the public Internet.

2026 年 10 月新增的 connect() handler 可以接收另一个 Worker 通过 Service Binding 转来的 TCP 连接，仍不代表传统 VNC 客户端能直接访问 Worker 域名的 5900 端口。普通出站 connect() 对私有 IP、localhost 和 Cloudflare IP 也有限制，不能将局域网 VNC 地址直接填进去。Connect Handler、TCP 限制

Workers for Platforms 适合让客户部署自己的 Worker，并由平台管理调度、隔离和资源限制。平台只提供统一 Agent 服务时，普通 Worker 加每任务 Durable Object 已经可以管理多个租户，无须仅因用户数量增加就引入 Workers for Platforms。用户要上传和持续运行自己的 Worker 代码时，后者才更有价值。Workers for Platforms

Dynamic Workers 在运行时加载代码，适合 Code Mode、生成脚本和受控工具调用。它不能启动原生子进程，因此不能运行 Xvfb、桌面环境或 VNC Server。动态代码可以通过宿主能力与 Durable Object Facets 使用持久存储，不能简单归为完全无状态；但持久存储不会把它变成 Linux。环境选择、Durable Object Facets

另一个组合限制是：Workers for Platforms 的 user Worker 配置 Outbound Worker 后，不能再直接使用 TCP connect()。需要出站治理时，应将桌面转发放在平台控制的服务中，或采用允许的 HTTP/WebSocket 路径。Outbound Workers

Browser Run 适合只需要网页的 Agent

Browser Run 提供托管的 headless Chrome。Quick Actions 完成截图、PDF、网页提取等常见任务；Browser Sessions 则允许应用通过 CDP、Playwright 或 Puppeteer 控制多步骤交互。Live View 让用户观看和操作同一个浏览器，Human in the Loop 提供结构化的人工交接。Browser Run 总览

flowchart TD
    UI["用户网页"] --> APP["Worker 与任务服务"]
    APP --> AGENT["Agent 决策与会话状态"]
    AGENT -->|"CDP 或 Workers Binding"| BROWSER["Browser Run Session"]
    BROWSER --> SITE["目标网站"]
    UI -->|"Live View"| BROWSER

这种架构适合网页表单、后台操作、网页测试和基于网页的研究。用户看到的可以是单个 tab，也可以是包含多个 tabs 的浏览器界面。无需为这些任务再维护完整桌面。Live View

Browser Run 流量有明确的自动化来源标识，不提供绕过目标网站机器人保护的能力。选型时应先验证目标网站与登录流程能否正常使用。FAQ

它也有明确边界：不能在 Browser Run 中任意安装 Linux 软件，不能把它当作 Windows 或 macOS 桌面，也不提供通用 VNC Server。需要将本地程序、终端和浏览器放在同一桌面里时，应选择 Container 路线。Browser Run 的接口与示例见 Browser Run 能力原理与使用指南。

Computer 适合持久工作区与混合执行

@cloudflare/computer 的核心是 Durable Object SQLite 中的文件系统，以及统一的 workspace.runtime.exec()。同一 Workspace 可以搭配 JavaScript、Worker shell 和 Container 后端。它解决的是 Agent 的文件放在哪里、工具如何操作文件、不同运行时如何使用这些文件。包说明

Computer 本身没有提供桌面与 VNC。当前官方 Container 示例运行 computerd、FUSE 和命令服务；需要图形桌面时，还要增加显示服务、窗口管理器、应用、VNC 与控制接口。

有一条持久化语义直接影响桌面方案：Container 后端不是每次文件读写都穿透到 DO 的共享磁盘。它在容器侧维护独立文件状态，默认命令执行的同步边界是 push → spawn → 消费事件或结果 → pull。computerd 不自行运行持续的后台同步循环。命令同步、computerd

因此，浏览器在后台持续写入 profile，并不意味着这些变化已自动保存在 DO。采用 Computer 承载这类文件时，需要明确同步时机，并检查执行结果里的同步状态；命令成功与文件耐久提交是两个条件。大型缓存、依赖和高频写入目录也要评估 FUSE、内存与同步成本。

Computer 的 stable 核心不应和 experimental Container 路线一起概括为“整套都已适合生产”。先验证持久 Workspace 的价值，再决定是否接受该后端的变动成本。更完整的机制与 API 见 Computer 技术解析。

完整桌面采用 Containers 加 VNC

Containers 运行自定义 Linux 镜像；Sandboxes 提供面向隔离执行的命令、文件和运行管理接口。需要完整桌面时，以下是一套可实现的组合，图中桌面组件与控制接口需要自行开发和维护。Sandboxes

flowchart TD
    USER["用户网页中的 noVNC"] <-->|"WSS"| WORKER["Worker 鉴权与会话路由"]
    WORKER <-->|"会话定位"| DO["每任务 Durable Object"]
    DO <-->|"HTTP 与 WebSocket"| PROXY["Container 中的 websockify"]
    PROXY <-->|"RFB TCP"| VNC["VNC Server"]
    VNC <--> DISPLAY["X Server 与窗口管理器"]
    DISPLAY <--> APPS["浏览器 终端 原生应用"]
    DO --> CONTROL["截图与输入控制服务"]
    CONTROL <--> DISPLAY
    DO --> STATE["任务状态与持久文件"]

Xvfb 等 X Server 提供虚拟显示，窗口管理器管理应用窗口，VNC Server 输出桌面并接收输入。noVNC 是网页客户端；VNC Server 未直接支持 WebSocket 时，websockify 在 WebSocket 与 TCP 之间转发。Cloudflare 已提供 Worker 经 Durable Object 向容器转发 WebSocket upgrade 的官方示例，所以浏览器观看通路有现成的平台基础。noVNC、websockify

Agent 控制是另一条通路：获取截图，交给模型判断，再执行点击、按键或输入，等待界面变化后获取下一张截图。模型不必消费 VNC 的每一帧。人类通过 noVNC 观看，Agent 通过截图和输入 API 工作，两者必须指向同一个显示会话。

除了镜像，还需要完成这些具体工作：

1. 定义显示分辨率、桌面组件、字体、输入法和目标软件，固定镜像与依赖版本。
2. 设置启动顺序与健康检查；VNC 端口可达不等于浏览器和桌面已经可用。
3. 对外只开放经过 Worker 授权的 HTTP/WebSocket 路径，按登录身份校验 session 所有权。
4. 为截图与键鼠工具设置执行边界，并让人工接管暂停 Agent 输入，释放控制权后再继续。
5. 设置空闲回收、任务超时和断线重连；独立保存文件、任务结果和必要的应用状态。

这条 Container 路线运行 Linux，Windows 与 macOS 应用需要另行选择匹配的主机。Computer 当前 ContainerBackend 使用的 durable_object scheduling policy 仍为 public beta，其平台状态与包内 experimental 状态应分别评估。Scheduling policies

旧教程中的 sandbox.desktop 不能作为当前开箱即用方案。Cloudflare 在 2026-06-09 的变更说明中确认，内置完整桌面及 VNC/noVNC 已在 SDK 0.10.2 移除；需要此能力时，应自行扩展。官方变更

已有电脑通过 Tunnel 与 Access 接入

如果桌面已经运行在自己的电脑或服务器上，可以用 Cloudflare Tunnel 接入 VNC Server，再用 Access 验证用户。官方支持用户打开 hostname、登录 Access、输入 VNC 密码后直接在网页中操作。浏览器 VNC 指南

这条路线节省了重建桌面环境的工作，适合管理已有机器。计算、软件安装、用户数据与机器可用性仍由原主机承担。将它用作 Agent 环境时，Agent 权限和输入控制也需要另外设计，Tunnel 本身不执行任务。

持久化需要按状态分别设计

Durable files do not imply durable processes.

Containers 默认磁盘是临时的。当前 Snapshots 已可用，但只保存文件系统，不保存内存和进程；仅支持 durable_object scheduling policy，并绑定创建时的镜像版本。快照不可变，后续文件变化需要新快照。默认保留 30 天，每次恢复会刷新保留期，最大 20 GB，不能把一次快照当作持续备份或永久归档。Snapshots

对 Agent 而言，还要区分“准备执行”“已执行”“已保存结果”。浏览器或容器中断后，重新点击一次支付、发送或提交按钮可能产生重复副作用。恢复流程应检查外部结果，并在应用层采用幂等标识、结果查询或人工处理，而不是只重放上一条输入。

Workflows 可以保存编排步骤和等待状态，适合跨人工等待的长任务；它不能让外部浏览器或桌面进程获得持久性。任务恢复、文件恢复和浏览器重建应分别实现。

成本由运行时间和等待策略决定

下面的单价按 2026-10-20 官方价格页整理，单位为美元。模型推理、Worker 执行、DO、存储、网络与日志需另行计入。

Containers 的资源费用

Containers 按 10ms 粒度计量。CPU 按实际活跃用量计费，内存和磁盘按实例预配容量计费；桌面在等待用户操作时，即使 CPU 很空闲，内存和磁盘仍在产生费用。Containers 价格

假设每月 1,000 次会话，每次容器从启动到停止共 10 分钟，选择 standard-2，配置为 1 vCPU、6 GiB 内存和 12 GB 磁盘；平均实际活跃 CPU 假设为 0.25 vCPU。规格来源见实例类型。

若账户的这些包含量均未被其他业务消耗，抵扣后约 $11.78；加 Workers Paid 的$5 基础费用约 $16.78，仍不是全部账单。这里的 0.25 vCPU 是估算输入，实际桌面必须测量。用户操作结束后额外等待 10 分钟才停止，内存与磁盘费用就会接近翻倍。

以下算例可保存为 estimate.mjs，用 node estimate.mjs 复算资源费，不调用云服务：

const sessions = 1000;
const secondsPerSession = 10 * 60;
const seconds = sessions * secondsPerSession;
const memoryGiBSeconds = seconds * 6;
const activeCPUSeconds = seconds * 0.25;
const diskGBSeconds = seconds * 12;

const gross = memoryGiBSeconds * 0.0000025
  + activeCPUSeconds * 0.000020
  + diskGBSeconds * 0.00000007;
const afterIncluded = Math.max(0, memoryGiBSeconds - 25 * 3600) * 0.0000025
  + Math.max(0, activeCPUSeconds - 375 * 60) * 0.000020
  + Math.max(0, diskGBSeconds - 200 * 3600) * 0.00000007;

console.log({
  resourceCostBeforeIncluded: gross.toFixed(3),
  resourceCostAfterIncluded: afterIncluded.toFixed(3),
  withPaidBase: (afterIncluded + 5).toFixed(3),
});

预期三项输出依次为 12.504、11.779、16.779。

Browser Run 的时长与并发费用

Workers Paid 包含每月 10 browser-hours，超出部分为 $0.09/browser-hour。Browser Sessions 还按每日峰值并发的月平均值计费：包含 10 个，超出部分每个$2/月；Quick Actions 不收这项并发费。Browser Run 价格

同样以 1,000 次、每次 10 分钟估算，总计 166.67 browser-hours，按官方整小时规则计为 167 小时；扣除 10 小时后，时长费为 $14.13。如果每日峰值并发的月平均值不超过 10，就没有额外并发费。这个例子比较的是账单结构，不代表远程浏览器与完整 Linux 桌面具有相同能力或性能。

Paid 默认 200 个并发是技术限额，不能理解为包含 200 个免费计费并发。默认无活动超时为 60 秒，keep_alive 最多设为 20 分钟；持续活跃时没有固定最长时长，但服务发布仍可能关闭会话。人工等待也会占用浏览器时长，应为任务设置预算、主动关闭或有预算地复用会话，并准备重建与状态恢复。Browser Run 限额

还要计入哪些费用

完整预算至少包括 Workers、DO 请求与活跃时长、Linux 容器或 Browser Run、持久存储、出站网络、日志以及模型推理。普通 WebSocket 转发不能直接套用聊天消息的 Hibernation 成本假设，应核对所用连接路径的 DO 活跃情况。DO 价格

VNC 带宽随分辨率、画面变化、编码和帧率变化，需用目标任务测量。Containers 的网络出站另有区域价格与包含量，快照也不能因价格页未单列费用就宣称永久免费。Containers 价格

推荐的落地顺序与通过标准

先拿真实任务验证最少的组件，结果足以说明问题后再增加运行时与持久化抽象。

如果任务主体是网页，优先采用 Browser Run，将 DO 用于任务状态与控制协调。如果主体是 Coding Agent，先使用 Sandboxes 或 Containers，再按持久工作目录与多后端执行的需求引入 Computer。如果必须看到完整桌面，则把 Containers 与 noVNC 作为第一条验证链路，之后补齐截图、输入、同步和恢复。

Workers for Platforms 和 Dynamic Workers 放在客户代码与生成代码的执行边界上。它们可以参与这套产品，但桌面、持久文件与 Agent 决策仍各有自己的承载位置。

关联阅读与官方入口

• Browser Run 能力原理与使用指南
• Computer 技术解析
• Dynamic Workers 与 Containers 及 Sandbox
• Cloudflare Computer 仓库
• Sandboxes 官方文档
• Containers API
• Browser Run 官方文档