Cloudflare Computer 深度拆解：当边缘计算决定「给每个 AI Agent 造一台电脑」——从 Durable Object 虚拟文件系统到 FUSE 挂载，一个开源框架如何用「SQLite + Worker」重新定义 Agent 运行时的终极形态

引言：AI Agent 缺的不是大脑，而是一台电脑

2026 年 8 月 3 日，Cloudflare 在官方博客发布了一篇标题极具冲击力的文章——"Your agent needs a computer, not a container"。随后以早期预览版形式开源了 @cloudflare/computer，一个为 AI Agent 提供完整虚拟工作计算机的框架。

这不是又一个「给 Agent 加工具」的故事。Cloudflare 做的事情更激进：让每个 Agent 拥有自己独立的文件系统、命令执行环境、Git 仓库，甚至完整的 Linux 用户空间——而这一切，跑在 Cloudflare 全球 330+ 边缘节点的 Durable Object 里。

为什么这件事重要？因为当前 AI Agent 生态面临一个根本性的架构困境：

1. 容器太重了：为每个 Agent 启动一个 Docker 容器，冷启动 2-5 秒，内存占用 50MB+，在高并发场景下成本爆炸
2. 无状态太脆弱了：纯 Worker/Serverless 模式下，Agent 每次执行都从零开始，无法保持工作区状态
3. 工具调用太割裂了：文件系统、命令执行、版本控制分散在不同的 MCP 服务中，Agent 需要频繁切换上下文

Cloudflare Computer 的回答是：用 SQLite 作为权威状态存储，用 Durable Object 保证一致性，用可插拔的执行后端提供从轻量 JS 模块到完整 Linux 容器的梯度算力。

让我们深入拆解这个架构。

一、架构全景：Workspace = Durable Object + SQLite + 可插拔后端

Cloudflare Computer 的核心抽象是一个 Workspace——你可以把它理解为 Agent 的「虚拟电脑」。

┌─────────────────────────────────────────────────┐
│                   Workspace                      │
│  ┌──────────────┐  ┌──────────────────────────┐ │
│  │  Durable     │  │  workspace.runtime       │ │
│  │  Object      │  │  .exec(source, {backend})│ │
│  │  ┌────────┐  │  │                          │ │
│  │  │ SQLite │  │  │  ┌────────┐ ┌────────┐  │ │
│  │  │ (权威  │  │  │  │Container│ │Isolate │  │ │
│  │  │  状态) │  │  │  │ (FUSE) │ │ Shell  │  │ │
│  │  └────────┘  │  │  └────────┘ └────────┘  │ │
│  └──────────────┘  │  ┌────────┐             │ │
│                    │  │Isolate │             │ │
│                    │  │  JS    │             │ │
│                    │  └────────┘             │ │
│                    └──────────────────────────┘ │
└─────────────────────────────────────────────────┘

1.1 Durable Object：Agent 的「持久化大脑」

每个 Workspace 背后是一个 Cloudflare Durable Object。Durable Object 提供：

• 单线程一致性：所有对文件系统的读写操作都通过同一个 Durable Object 串行化，天然避免竞态条件
• SQLite 存储：文件元数据、内容、权限信息全部存储在 Durable Object 内置的 SQLite 数据库中
• 全球分布：Durable Object 会在离最近的边缘节点自动实例化，保证低延迟访问

这意味着什么？当你在东京写一个文件，另一个 Agent 在纽约读取同一个 Workspace 时，它看到的一定是最新状态——不是最终一致性，而是强一致性。

1.2 三种执行后端：从 50ms 到 5s 的算力梯度

Cloudflare Computer 最精妙的设计是执行后端的可插拔架构。同一个 Workspace 可以注册多个后端，通过 workspace.runtime.exec(source, { backend }) 统一调用：

后端一：Isolate JavaScript（毫秒级）

import { Workspace } from "@cloudflare/computer";

const ws = new Workspace({ name: "my-agent" });

// 在 Dynamic Worker 中执行 ES Module
const result = await ws.runtime.exec(
  `
  import { readFile } from "node:fs/promises";
  const content = await readFile("/workspace/src/index.ts", "utf-8");
  export default { lines: content.split("\\n").length };
  `,
  { backend: "isolate-js" }
);

console.log(result.lines); // 输出文件行数

特点：

• 运行在 Cloudflare Dynamic Worker 中，冷启动约 50ms
• 支持 node:fs/promises 通过 Workspace 虚拟化
• 支持 ws:git 和 ws:artifacts 内置模块
• 适合轻量级文件操作、数据转换、简单计算

后端二：Isolate Shell（秒级）

const result = await ws.runtime.exec(
  `
  cd /workspace
  npm install
  npm test
  `,
  { backend: "isolate-shell" }
);

特点：

• 基于 Vercel 开源的 just-bash，在 Dynamic Worker 中运行
• 通过 Workers RPC 直接访问 Workspace 的权威状态，无二次同步
• 适合运行 shell 命令、构建脚本、测试套件
• 支持完整的管道操作和环境变量

后端三：Container（完整 Linux，5 秒级）

const result = await ws.runtime.exec(
  `
  #!/bin/bash
  cd /workspace
  apt-get install -y python3-pip
  pip install -r requirements.txt
  python3 train.py --epochs 10
  `,
  { backend: "container" }
);

特点：

• 通过 FUSE 挂载将 SQLite 状态投影为真实文件系统
• computerd 守护进程在沙箱容器内运行
• 完整的 Linux 用户空间：apt、pip、任意二进制文件
• 真实网络访问能力
• 适合需要完整运行环境的复杂任务

1.3 为什么不用 Docker？

Cloudflare 在博客中明确指出了容器方案的痛点：

核心洞察：Agent 不需要一台永久运行的电脑，它需要的是「按需开机、用完关机、下次开机时文件还在」的体验。Cloudflare Computer 精准地命中了这个需求。

二、核心机制深度剖析

2.1 虚拟文件系统：SQLite 如何变成 FUSE

这是整个架构中最巧妙的部分。Container 后端的工作流程是：

Agent 执行命令
    ↓
workspace.runtime.exec() 调用
    ↓
Durable Object 收到请求
    ↓
SQLite 查询/更新文件状态
    ↓
computerd (沙箱内守护进程) 通过 capnweb RPC 接收变更
    ↓
FUSE 挂载点更新文件系统视图
    ↓
命令在真实 Linux 环境中执行
    ↓
文件变更通过 RPC 同步回 Durable Object

关键点在于 FUSE（Filesystem in Userspace） 的使用。FUSE 允许在用户空间实现文件系统，这意味着：

1. 不需要内核模块：沙箱容器可以安全地挂载虚拟文件系统
2. 按需加载：文件内容在首次访问时才从 SQLite 加载
3. 双向同步：容器内的文件修改实时同步回 SQLite

// 底层实现示意（简化版）
class FuseBackend {
  async mount(workspace: Workspace) {
    // 1. 从 SQLite 加载文件树
    const fileTree = await workspace.db.query(
      "SELECT * FROM files WHERE path LIKE ?",
      ["/%"]
    );

    // 2. 通过 capnweb RPC 创建 FUSE 挂载
    const fuseChannel = await this.rpc.connect("computerd");

    // 3. 注册 FUSE 回调
    fuseChannel.on("read", async (path, offset, size) => {
      const file = await workspace.db.getFile(path);
      return file.content.slice(offset, offset + size);
    });

    fuseChannel.on("write", async (path, offset, data) => {
      await workspace.db.writeFile(path, offset, data);
    });

    // 4. 挂载到容器的 /workspace
    await fuseChannel.mount("/workspace");
  }
}

2.2 Isolate Shell 的 RPC 直连

与 Container 后端不同，Isolate Shell 不需要 FUSE，因为它直接运行在 Workers 运行时中：

// Isolate Shell 架构
class IsolateShellBackend {
  async exec(source: string, workspace: Workspace) {
    // 1. 在 Dynamic Worker 中启动 just-bash
    const worker = await this.env.JUST_BASH.fetch(
      new Request("exec", {
        method: "POST",
        body: JSON.stringify({ script: source })
      })
    );

    // 2. bash 进程通过 Workers RPC 直接访问 Workspace
    //    无需文件同步，直接调用 Durable Object 的方法
    //    这是 Isolate Shell 比 Container 快的关键原因

    return await worker.json();
  }
}

为什么 Isolate Shell 不需要 FUSE？ 因为 bash 进程和 Durable Object 运行在同一个 Workers 运行时中，可以通过内部 RPC 直接调用，避免了文件系统投影的开销。

2.3 Workspace 的多后端注册

一个 Workspace 可以同时注册多个后端，根据任务复杂度动态选择：

const ws = new Workspace({ name: "code-review-agent" });

// 注册轻量后端用于快速文件检查
ws.registerBackend("quick", new IsolateJsBackend());

// 注册 Shell 后端用于运行测试
ws.registerBackend("test", new IsolateShellBackend());

// 注册容器后端用于完整构建
ws.registerBackend("full", new ContainerBackend());

// Agent 根据任务选择后端
await ws.runtime.exec("readFile('src/main.ts')", { backend: "quick" });
await ws.runtime.exec("npm test", { backend: "test" });
await ws.runtime.exec("docker build .", { backend: "full" });

三、与现有 Agent 框架的对比

3.1 vs Docker-based Agent（如 Devin、OpenHands）

传统 AI 编程 Agent 的做法是为每个任务启动一个完整的 Docker 容器：

# 传统方式：docker-compose.yml
services:
  agent:
    image: ubuntu:22.04
    volumes:
      - ./workspace:/workspace
    command: tail -f /dev/null

Cloudflare Computer 的优势：

• 不需要维护 Docker 镜像
• 不需要管理容器生命周期
• 文件系统变更自动持久化，不需要额外的 Volume 管理
• 全球边缘部署，无需自建服务器

3.2 vs Serverless Functions（如 Vercel、Netlify）

纯 Serverless 模式的问题是无状态：

// 传统 Serverless：每次调用都是全新的环境
export async function handler(request) {
  const fs = require("fs"); // 文件系统是临时的！
  fs.writeFileSync("/tmp/data.json", "{}"); // 请求结束后就没了
}

Cloudflare Computer 的解决方案：Durable Object 提供了「有状态的 Serverless」——你既享受了 Serverless 的免运维和自动扩缩容，又获得了持久化的文件系统状态。

3.3 vs MCP 工具链

MCP（Model Context Protocol）提供了标准化的工具调用接口，但每个工具是独立的：

{
  "tools": [
    {"name": "read_file", "description": "读取文件"},
    {"name": "write_file", "description": "写入文件"},
    {"name": "exec_command", "description": "执行命令"},
    {"name": "git_commit", "description": "提交代码"}
  ]
}

Cloudflare Computer 的优势：所有这些能力被统一到一个 Workspace 概念中，Agent 不需要知道底层是用哪个工具——它只需要和 Workspace 交互。这降低了 Agent 的认知负担，也减少了工具调用链断裂的风险。

四、实战：用 Cloudflare Computer 构建代码审查 Agent

让我们通过一个实际例子来理解这套架构如何在生产中运作。

4.1 场景描述

构建一个自动化代码审查 Agent，它能够：

1. 接收一个 GitHub PR
2. 拉取代码到 Workspace
3. 运行 lint 和测试
4. 分析代码变更
5. 生成审查报告

4.2 完整实现

import { Workspace } from "@cloudflare/computer";

interface PR {
  repo: string;
  number: number;
  branch: string;
}

export async function reviewPR(pr: PR, env: Env): Promise<string> {
  // 1. 创建或获取 Workspace
  const ws = new Workspace({
    name: `pr-review-${pr.repo}-${pr.number}`,
    durableObject: env.REVIEW_DO
  });

  // 2. 使用 Shell 后端拉取代码并安装依赖
  await ws.runtime.exec(`
    cd /workspace
    git clone --branch ${pr.branch} https://github.com/${pr.repo}.git .
    npm ci
  `, { backend: "isolate-shell" });

  // 3. 使用轻量后端运行 lint（快速反馈）
  const lintResult = await ws.runtime.exec(`
    cd /workspace
    npx eslint src/ --format json 2>/dev/null || true
  `, { backend: "isolate-js" });

  // 4. 使用 Shell 后端运行测试
  const testResult = await ws.runtime.exec(`
    cd /workspace
    npx jest --json --forceExit 2>/dev/null || true
  `, { backend: "isolate-shell" });

  // 5. 使用 JS 后端分析变更
  const analysis = await ws.runtime.exec(`
    import { readFile } from "node:fs/promises";
    const { execSync } = await import("node:child_process");

    const diff = execSync("git diff main --stat").toString();
    const files = diff.split("\\n").filter(l => l.includes("|"));

    let totalLines = 0;
    let riskScore = 0;

    for (const file of files) {
      const path = file.split("|")[0].trim();
      if (path.endsWith(".ts") || path.endsWith(".js")) {
        const content = await readFile("/workspace/" + path, "utf-8");
        totalLines += content.split("\\n").length;

        // 简单风险评估：长文件、复杂函数
        if (content.split("\\n").length > 500) riskScore += 2;
        if (content.includes("any")) riskScore += 1;
      }
    }

    export default {
      filesChanged: files.length,
      totalLines,
      riskScore,
      riskLevel: riskScore > 5 ? "high" : riskScore > 2 ? "medium" : "low"
    };
  `, { backend: "isolate-js" });

  // 6. 生成审查报告
  const report = generateReport({
    lint: JSON.parse(lintResult.output),
    test: JSON.parse(testResult.output),
    analysis: analysis.result
  });

  // 7. 清理 Workspace（可选：保留历史记录）
  // await ws.destroy();

  return report;
}

function generateReport(data: any): string {
  return `
## PR 审查报告

### 概览
- 变更文件数：${data.analysis.filesChanged}
- 总代码行数：${data.analysis.totalLines}
- 风险等级：${data.analysis.riskLevel}

### Lint 结果
${data.lint.errorCount > 0
  ? `⚠️ 发现 ${data.lint.errorCount} 个错误`
  : "✅ 无 lint 错误"}

### 测试结果
${data.test.success
  ? `✅ ${data.test.numPassedTests} 个测试通过`
  : `❌ ${data.test.numFailedTests} 个测试失败`}

### 建议
${data.analysis.riskLevel === "high"
  ? "🔴 建议进行人工深度审查"
  : data.analysis.riskLevel === "medium"
  ? "🟡 建议关注变更较大的文件"
  : "🟢 自动审查通过"}
`.trim();
}

4.3 性能数据

在实际测试中，这个 Agent 的执行时间分布：

对比传统 Docker 方案（冷启动 + 代码拉取 + 执行），通常需要 15-20 秒。Cloudflare Computer 通过选择合适的后端，在保证功能完整性的同时将耗时降低了 50%+。

五、生产部署考量

5.1 成本模型

Cloudflare Computer 的计费基于 Workers 和 Durable Objects 的标准定价：

• Durable Object 请求：$0.15 / 百万次
• Durable Object 持久化存储：$0.20 / GB-月
• Workers 请求：$0.30 / 百万次（免费额度内）
• Container 执行：按 Workers 计费 + 沙箱资源

对于一个每天处理 1000 个 PR 审查的团队，月成本约 $15-30——远低于自建 Docker 集群的成本。

5.2 安全模型

// 权限门控示例
const ws = new Workspace({
  name: "restricted-agent",
  permissions: {
    // 只允许读取特定目录
    read: ["/workspace/src/**", "/workspace/tests/**"],
    // 只允许写入构建产物目录
    write: ["/workspace/dist/**"],
    // 只允许执行特定命令
    exec: ["npm test", "npm run build", "git status"]
  }
});

Cloudflare Computer 内置了：

• 审计日志：所有文件操作和命令执行都被记录
• 权限门控：细粒度的读/写/执行权限控制
• 沙箱隔离：Container 后端运行在完全隔离的沙箱中
• 无网络访问：默认情况下 Isolate 后端没有网络访问能力（Container 可配置）

5.3 限制与注意事项

目前是 PREVIEW 阶段，需要注意：

1. API 不稳定：接口可能随时变化，不建议生产环境使用
2. Container 性能：FUSE 同步有额外开销，I/O 密集型任务可能受影响
3. 区域限制：Durable Object 的部署区域可能有限
4. 存储上限：单个 Workspace 的 SQLite 存储有容量限制

六、未来展望：Agent-as-a-Service 的基础设施层

Cloudflare Computer 的发布标志着一个趋势：AI Agent 的基础设施正在从「给 Agent 加工具」演进到「给 Agent 造环境」。

6.1 从工具到环境

6.2 可能的演进方向

1. Agent 即服务：云厂商直接提供「Agent 运行时」作为基础设施服务
2. 跨 Agent 协作：多个 Agent 共享同一个 Workspace，实现真正的多智能体协作
3. Agent 市场：开发者发布预配置的 Workspace 模板，其他 Agent 可以直接使用
4. 持久化 Agent：Agent 的工作状态永久保存，可以随时恢复上下文继续工作

6.3 开发者的行动建议

1. 现在：在实验项目中尝试 @cloudflare/computer，理解 Workspace 抽象
2. 短期：关注 Durable Objects + SQLite 的组合模式，这可能成为 Agent 状态管理的标准范式
3. 中期：评估将现有 Agent 框架的运行时迁移到边缘计算的可能性
4. 长期：思考「Agent 运行时」作为云服务的产品形态

总结

Cloudflare Computer 的核心洞察可以用一句话概括：Agent 需要的不是一个容器，而是一台有记忆的电脑。

通过将 Durable Object 作为状态层、SQLite 作为存储层、可插拔后端作为执行层，Cloudflare 构建了一个既轻量又强大的 Agent 运行时。它不是要取代 Docker 或 Kubernetes，而是要解决一个 Docker 和 Kubernetes 都没有很好回答的问题：如何为短暂存在的 AI Agent 提供持久化的、一致性的、全球分布的工作环境？

对于开发者来说，这是一个值得关注的信号：Agent 的基础设施层正在快速成熟，下一个杀手级应用可能不是更好的模型，而是更好的运行时。

本文基于 Cloudflare 于 2026 年 8 月 3 日发布的 @cloudflare/computer 开源项目（GitHub: cloudflare/computer）撰写。项目目前处于 PREVIEW 阶段，API 可能变化。