Cloudflare Computer 深度拆解：当每个 AI Agent 拥有一台专属「虚拟机」—— SQLite 文件系统 × 智能执行后端 × Cloudflare OS 全栈解析

一、引言：当 Agent 还在「借宿」，Cloudflare 决定给它「买房」

在 AI Agent 的发展史上，有一个被长期忽视的底层问题：文件系统与执行环境的缺失。

传统的聊天 AI（如 ChatGPT、Claude）本质上是「对话机器」——你问一句，它答一句，中间没有任何持久状态。但当 AI Agent 开始处理复杂任务时，这个模式就不够用了。写代码需要保存工作区的文件，跑测试需要环境，执行失败了需要重试，Agent 之间还需要共享上下文。

当前行业的解决方案是容器（Container）。为每个用户的 AI Agent 分配一个独立的 Linux 容器，内含文件系统、网络、工具链，听起来很美好——但代价是什么？

Cloudflare 做过测算：持续为每个用户的 Agent 分配专属容器，会消耗大量 CPU 与内存资源。对于一个面向消费者的 Agent 平台而言，这种成本结构根本无法规模化。

2026 年 8 月 4 日，Cloudflare 在 Agents Week 2026 上开源了 @cloudflare/computer——一个 Agent 运行时项目，其核心思路简洁而颠覆：不是给 Agent 一个容器，而是给它一台电脑。

这台「电脑」的核心是一个 SQLite 虚拟文件系统，配合可插拔的执行后端，让系统在轻量隔离环境与完整 Linux 容器之间自动选择最优执行路径。配合同天发布的 Cloudflare OS，Cloudflare 正试图构建一套完整的 Agent 基础设施生态。

本文将从架构原理、代码实现、性能对比、生态全景四个维度，对这套系统进行深度拆解。

二、背景：为什么现有的 Agent 执行方案都「差点意思」

2.1 传统容器的成本困境

让我们先复盘一下行业现状。当你使用一个主流的 AI Agent 编程工具（如 Cursor、Cline、Devin）时，后端通常是这样的架构：

用户请求 → 调度层 → 为该用户分配一个容器
         ↓
    容器内：Linux 环境 + 文件系统 + 工具链
         ↓
    Agent 在容器内执行操作
         ↓
    返回结果，容器销毁或回收

问题在哪？

• 启动延迟：即便使用预热池，冷启动一个容器仍需要数秒到数十秒
• 资源成本：一个包含完整 Linux 环境的基础镜像，即使什么都不做，也占用内存
• 隔离粒度：容器的隔离是「全有或全无」——要么给一个完整容器，要么无法给

对于一个只需要写几个文件、执行几个命令的轻量级 Agent 任务来说，完整容器的资源消耗远远超出实际需求。但对于需要编译大型项目、运行 Docker 的复杂任务，轻量隔离又不够用。

2.2 文件系统：被忽视的那块拼图

在 Cloudflare 看来，现有 Agent 框架存在一个根本性的抽象错误：它们把文件操作当成了消息传递的一部分，而不是持久化状态的一部分。

当一个 Agent 执行 mkdir /workspace && echo "hello" > /workspace/test.txt 时，这个操作实际上依赖于：

1. 一个可写的文件系统（不是临时的，是持久的）
2. 一个执行环境来运行命令
3. 一个状态来追踪这个 Agent 关联的「工作区」

现有方案将这三个职责混在一起，导致了系统设计的拧巴——要么用复杂的虚拟文件系统（如 E2B），要么干脆不支持文件操作（纯对话式 Agent）。

Cloudflare Computer 的核心洞察是：把这三个职责解耦，用 SQLite 作为统一的虚拟文件系统抽象层，让上层的 Agent 逻辑完全不用关心文件实际存在哪里。

2.3 Cloudflare OS：更大的棋局

值得注意的是，@cloudflare/computer 并非孤立的工具项目，它是 Cloudflare OS 生态的一部分。

Cloudflare OS 是 Cloudflare 在 2026 年 8 月 4 日发布的面向 AI Agent 的开放平台，构建在三个核心支柱上：

@cloudflare/computer 对应的是第一个支柱中的「执行后端」层——它是 Agent 实际运行代码、处理文件的那一层基础设施。

三、架构解析：三层核心设计

3.1 整体架构图

Cloudflare Computer 的架构可以分为三层：

┌─────────────────────────────────────────┐
│         Agent Logic Layer               │
│    (你的 Agent prompt / tool calling)   │
├─────────────────────────────────────────┤
│      Virtual Filesystem Layer           │
│    (SQLite as virtual FS + FS API)     │
├─────────────────────────────────────────┤
│      Execution Backend Layer            │
│  ┌─────────────┐    ┌───────────────┐  │
│  │   Lightweight│    │  Full Container│  │
│  │   Isolation │    │  (Cloudflare  │  │
│  │  Environment │    │   Workers)    │  │
│  └─────────────┘    └───────────────┘  │
└─────────────────────────────────────────┘

关键设计原则：SQLite 层是「虚拟文件系统」的底层实现，它暴露标准的文件系统 API（如 read、write、mkdir、list），但实际的数据可以存储在任何后端。执行后端是「插拔式」的，系统根据任务需求自动选择轻量隔离或完整容器。

3.2 SQLite 虚拟文件系统：不是数据库，是「电脑里的硬盘」

这是 Cloudflare Computer 最有趣的设计决策——用 SQLite 充当虚拟文件系统的存储引擎。

为什么是 SQLite？SQLite 有几个天然适合这个场景的特性：

1. 单文件、事务性：SQLite 是一个完整的嵌入式数据库，支持 ACID 事务，这意味着文件系统操作是原子的——不会出现「写了一半」的文件
2. 高性能：SQLite 的读性能可达每秒 50 万次以上，对于 Agent 的文件操作绰绰有余
3. 跨平台：一个 .db 文件可以在任何环境打开，不需要额外的服务进程
4. 易于备份和迁移：把一个 Agent 的整个「工作区」导出成一个文件即可

在 Cloudflare Computer 的实现中，SQLite 数据库的 schema 大致如下（简化版）：

-- 文件系统元数据表
CREATE TABLE fs_metadata (
    path TEXT PRIMARY KEY,          -- 绝对路径
    type TEXT NOT NULL,             -- 'file' | 'directory'
    size INTEGER DEFAULT 0,         -- 文件大小（字节）
    mode INTEGER DEFAULT 0o644,     -- Unix 权限位
    created_at INTEGER,             -- Unix timestamp
    updated_at INTEGER,
    parent_path TEXT,               -- 父目录路径
    FOREIGN KEY (parent_path) REFERENCES fs_metadata(path)
);

-- 文件内容表（BLOB 存储）
CREATE TABLE fs_content (
    path TEXT PRIMARY KEY,
    content BLOB,                   -- 实际文件内容
    checksum TEXT,                  -- SHA-256 校验和
    FOREIGN KEY (path) REFERENCES fs_metadata(path)
);

-- 操作日志（用于增量同步和崩溃恢复）
CREATE TABLE fs_log (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    operation TEXT,                 -- 'write' | 'delete' | 'mkdir'
    path TEXT,
    timestamp INTEGER,
    tx_id INTEGER                  -- 事务 ID，用于批量回滚
);

核心文件系统 API（TypeScript 接口定义）：

// 定义标准文件系统接口
interface VirtualFS {
  // 文件操作
  read(path: string): Promise<Uint8Array>;
  write(path: string, data: Uint8Array): Promise<void>;
  mkdir(path: string): Promise<void>;
  rm(path: string): Promise<void>;
  stat(path: string): Promise<FileMetadata>;
  list(path: string): Promise<FileEntry[]>;
  
  // 路径操作
  resolve(...segments: string[]): string;
  join(...segments: string[]): string;
  dirname(path: string): string;
  basename(path: string): string;
  
  // 工作区快照
  snapshot(): Promise<WorkspaceSnapshot>;
  restore(snapshot: WorkspaceSnapshot): Promise<void>;
}

// SQLite 实现（简化）
class SQLiteVirtualFS implements VirtualFS {
  private db: Database;
  
  async read(path: string): Promise<Uint8Array> {
    const row = this.db.query(
      'SELECT content FROM fs_content WHERE path = ?',
      [path]
    ).first();
    
    if (!row) {
      throw new FileNotFoundError(path);
    }
    
    return new Uint8Array(row.content);
  }
  
  async write(path: string, data: Uint8Array): Promise<void> {
    const tx = this.db.transaction(() => {
      // 确保父目录存在
      const dir = this.dirname(path);
      if (dir !== '/') {
        this.ensureDir(dir);
      }
      
      // 更新元数据
      this.db.run(`
        INSERT INTO fs_metadata (path, type, size, updated_at)
        VALUES (?, 'file', ?, ?)
        ON CONFLICT(path) DO UPDATE SET
          size = excluded.size, updated_at = excluded.updated_at
      `, [path, data.length, Date.now()]);
      
      // 更新内容
      this.db.run(`
        INSERT INTO fs_content (path, content, checksum)
        VALUES (?, ?, ?)
        ON CONFLICT(path) DO UPDATE SET
          content = excluded.content, checksum = excluded.checksum
      `, [path, Buffer.from(data), this.checksum(data)]);
    });
    
    tx.run();
  }
  
  async mkdir(path: string): Promise<void> {
    const tx = this.db.transaction(() => {
      const parent = this.dirname(path);
      
      if (parent !== '/' && !this.exists(parent)) {
        this.ensureDir(parent);
      }
      
      this.db.run(`
        INSERT OR IGNORE INTO fs_metadata 
        (path, type, created_at, updated_at)
        VALUES (?, 'directory', ?, ?)
      `, [path, Date.now(), Date.now()]);
    });
    
    tx.run();
  }
}

3.3 可插拔执行后端：智能调度策略

Cloudflare Computer 的第二个核心创新是执行后端的插拔式设计。系统不预设「必须用容器」或「必须用轻量隔离」，而是根据任务特征自动选择。

3.3.1 两种执行模式

模式 A：轻量隔离环境（Lightweight Isolation）

适用场景：单个脚本执行、文件操作、轻量级测试

实现原理：利用 Cloudflare Workers 的 V8 隔离（isolate）机制，每个 Agent 的任务在独立的 V8 上下文中执行。V8 isolate 的启动时间是微秒级（μs），远低于容器启动的秒级。

Agent 请求
    ↓
调度器判断：轻量任务
    ↓
V8 Isolate 1 ← SQLite FS（读取该 Agent 的 .db 文件）
    ↓
执行命令（如 `node script.js`）
    ↓
结果写入 SQLite FS
    ↓
响应

模式 B：完整容器（Full Container / Cloudflare Workers）

适用场景：需要系统级工具（Docker、编译工具链）、长时间运行、需要网络访问

实现原理：使用 Cloudflare Workers（完整的 V8 + WASI 环境），或 Cloudflare 的长时运行 Worker（最长 15 分钟超时）。

Agent 请求
    ↓
调度器判断：复杂任务
    ↓
Worker 容器启动（预热池）
    ↓
挂载 SQLite FS（通过网络或共享存储）
    ↓
执行命令（如 `cargo build --release`）
    ↓
结果写入 SQLite FS
    ↓
响应

3.3.2 调度器实现

调度器是整个系统的「大脑」，负责决定走哪条路径：

interface ExecutionTask {
  command: string;           // 要执行的命令
  timeout: number;           // 超时限制（毫秒）
  requiresNetwork: boolean;  // 是否需要网络访问
  requiresFilesystem: boolean; // 是否需要完整文件系统
  requiresSystemTools: string[]; // 需要的系统工具列表
  estimatedComplexity: 'low' | 'medium' | 'high';
}

class Scheduler {
  private lightweightBackend: LightweightBackend;
  private containerBackend: ContainerBackend;
  
  async schedule(task: ExecutionTask): Promise<ExecutionResult> {
    // 调度策略：保守优先
    // 只要有任何一项不满足轻量条件，就上容器
    
    if (this.shouldUseContainer(task)) {
      console.log(`[Scheduler] Task "${task.command}" → Container`);
      return this.containerBackend.execute(task);
    } else {
      console.log(`[Scheduler] Task "${task.command}" → Lightweight`);
      return this.lightweightBackend.execute(task);
    }
  }
  
  private shouldUseContainer(task: ExecutionTask): boolean {
    // 需要网络访问 → 容器
    if (task.requiresNetwork) return true;
    
    // 需要系统级工具（如 gcc, cargo, docker）→ 容器
    const systemTools = ['gcc', 'g++', 'cargo', 'docker', 'kubectl', 'make'];
    if (task.requiresSystemTools.some(t => systemTools.includes(t))) {
      return true;
    }
    
    // 复杂度高或超时较长 → 容器
    if (task.estimatedComplexity === 'high' || task.timeout > 60000) {
      return true;
    }
    
    // 其他情况走轻量
    return false;
  }
}

3.4 与 Cloudflare OS 的集成

@cloudflare/computer 在 Cloudflare OS 生态中的位置：

Cloudflare OS
├── Workers for Agents (Agent 运行时)
│   ├── @cloudflare/computer (执行后端 + SQLite FS)
│   │   ├── Virtual Filesystem (SQLite)
│   │   ├── Lightweight Backend (V8 Isolate)
│   │   └── Container Backend (Workers)
│   ├── WebSocket Manager (长连接状态)
│   └── Tool Registry (工具注册表)
│
├── Durable Objects 2.0 (持久化存储)
│   ├── Key-Value Storage
│   ├── Vector Store (向量存储)
│   └── Agent Memory (Agent 记忆)
│
└── Workflows (工作流编排)
    ├── Step Orchestrator
    ├── Retry Policy
    └── Parallel Branch

一个典型的 Agent 请求处理流程：

1. 用户发送请求到 Workers for Agents
2. Durable Objects 查找/创建该 Agent 的状态
3. @cloudflare/computer 挂载 Agent 的 SQLite FS
4. Scheduler 决定执行路径
5. 执行命令，读写 SQLite FS
6. 结果返回，状态持久化到 Durable Objects

四、代码实战：构建一个基于 Cloudflare Computer 的 Agent

4.1 环境准备

# 安装依赖
npm install @cloudflare/computer

# 初始化 Cloudflare Workers 项目
npx wrangler init my-agent --type typescript
cd my-agent

# 安装 computer 包
npm install @cloudflare/computer

4.2 基本使用：创建 Agent + 执行文件操作

// src/index.ts
import { Computer, Agent } from '@cloudflare/computer';

// 初始化虚拟文件系统
const computer = new Computer({
  storage: ' DurableObjects', // 或 'memory' | 'local'
});

// 创建 Agent 实例
const agent = new Agent({
  computer,
  model: 'gpt-4o',
  system: `你是一个全栈开发助手。你在一个虚拟文件系统中工作。
          可以使用 computer.read / computer.write / computer.run 执行操作。
          工作目录默认在 /workspace 下。`
});

// 处理用户请求
export default {
  async fetch(request: Request): Promise<Response> {
    const { message, agentId } = await request.json();
    
    const result = await agent.run(message, {
      agentId,
      timeout: 120_000, // 2分钟超时
    });
    
    return Response.json(result);
  }
};

4.3 执行文件操作

// 在 Agent 的 tool calling 中注册文件系统工具
agent.registerTools([
  {
    name: 'read_file',
    description: '读取文件内容',
    parameters: {
      type: 'object',
      properties: {
        path: { type: 'string', description: '文件路径（绝对路径或相对 /workspace）' }
      },
      required: ['path']
    },
    async execute({ path }: { path: string }) {
      // 路径标准化
      const absPath = path.startsWith('/') ? path : `/workspace/${path}`;
      
      try {
        const content = await computer.read(absPath);
        const text = new TextDecoder().decode(content);
        return { success: true, content: text, path: absPath };
      } catch (err) {
        return { success: false, error: String(err) };
      }
    }
  },
  
  {
    name: 'write_file',
    description: '写入文件内容',
    parameters: {
      type: 'object',
      properties: {
        path: { type: 'string', description: '文件路径' },
        content: { type: 'string', description: '文件内容' },
        append: { type: 'boolean', description: '是否追加模式（默认覆盖）' }
      },
      required: ['path', 'content']
    },
    async execute({ path, content, append }: { path: string; content: string; append?: boolean }) {
      const absPath = path.startsWith('/') ? path : `/workspace/${path}`;
      
      try {
        if (append) {
          const existing = await computer.read(absPath).catch(() => new Uint8Array());
          const merged = new TextEncoder().encode(
            new TextDecoder().decode(existing) + content
          );
          await computer.write(absPath, merged);
        } else {
          await computer.write(absPath, new TextEncoder().encode(content));
        }
        return { success: true, path: absPath };
      } catch (err) {
        return { success: false, error: String(err) };
      }
    }
  },
  
  {
    name: 'run_command',
    description: '在虚拟环境中执行命令',
    parameters: {
      type: 'object',
      properties: {
        command: { type: 'string', description: '要执行的命令' },
        cwd: { type: 'string', description: '工作目录' },
        timeout: { type: 'number', description: '超时（毫秒）' }
      },
      required: ['command']
    },
    async execute({ command, cwd, timeout }: { command: string; cwd?: string; timeout?: number }) {
      const result = await computer.run(command, {
        cwd: cwd || '/workspace',
        timeout: timeout || 30_000,
        // 系统会自动判断走轻量还是容器
      });
      
      return {
        stdout: result.stdout,
        stderr: result.stderr,
        exitCode: result.exitCode,
        executionMode: result.backend, // 'lightweight' | 'container'
      };
    }
  }
]);

4.4 完整示例：让 Agent 写一个 Todo CLI

// 用户请求：帮我写一个命令行 Todo 应用，支持添加、列表、完成功能
const userRequest = `
帮我用 Node.js 写一个命令行 Todo 应用。
要求：
1. 使用 SQLite 存储数据
2. 命令行参数解析（使用 commander 或 yargs）
3. 支持 add/list/complete 三种命令
4. 数据存储在 ~/.todo/todos.db
5. 完成后运行测试验证功能正常
`;

const result = await agent.run(userRequest);

// Agent 的执行过程（模拟）：
// 1. computer.mkdir('/workspace/todo-app')
// 2. computer.write('/workspace/todo-app/package.json', '{"name":"todo-cli","dependencies":{...}}')
// 3. computer.write('/workspace/todo-app/src/index.js', '...')  
// 4. computer.run('npm install', { cwd: '/workspace/todo-app' })
//    → 系统判断：npm install 需要网络 → 走容器后端
// 5. computer.run('node src/index.js add "买牛奶"', { cwd: '/workspace/todo-app' })
//    → 系统判断：单个 node 命令 → 走轻量后端
// 6. computer.run('node src/index.js list', { cwd: '/workspace/todo-app' })
//    → 同上，轻量后端

console.log(result.output);
// 最终 Agent 会把完整项目代码和执行结果返回给你

4.5 与 Durable Objects 集成：实现 Agent 记忆

// 使用 Durable Objects 存储 Agent 的状态和记忆
export class AgentState implements DurableObject {
  private state: DurableObjectState;
  private computer: Computer;
  private memory: AgentMemory;
  
  constructor(state: DurableObjectState, env: Env) {
    this.state = state;
    
    // 初始化 Agent 的虚拟文件系统
    this.computer = new Computer({
      storage: this.state.storage, // 直接用 Durable Objects 的 KV 存储
    });
    
    // 初始化 Agent 记忆系统
    this.memory = new AgentMemory({
      vectorStore: env.VECTOR_STORE, // Durable Objects 2.0 的向量存储
    });
  }
  
  async fetch(request: Request): Promise<Response> {
    const { action, payload } = await request.json();
    
    switch (action) {
      case 'execute':
        return this.handleExecute(payload);
      case 'remember':
        return this.handleRemember(payload);
      case 'snapshot':
        return this.handleSnapshot();
      default:
        return new Response('Unknown action', { status: 400 });
    }
  }
  
  private async handleRemember(payload: { event: string; metadata?: any }) {
    // 将重要事件存入向量存储，用于后续 RAG
    const embedding = await this.memory.embed(payload.event);
    await this.state.storage.put(`memory:${Date.now()}`, {
      content: payload.event,
      embedding,
      metadata: payload.metadata,
    });
    
    return Response.json({ success: true });
  }
  
  private async handleSnapshot(): Promise<Response> {
    // 快照整个工作区状态
    const snapshot = await this.computer.snapshot();
    
    // 存储快照到 Durable Objects
    await this.state.storage.put('workspace_snapshot', snapshot);
    
    return Response.json({
      snapshotId: snapshot.id,
      size: snapshot.size,
      createdAt: snapshot.createdAt,
    });
  }
}

五、性能对比：SQLite FS + 智能调度的实际表现

5.1 冷启动延迟对比

这是 Agent 执行场景中最关键的性能指标：

实测场景：一个 Agent 执行 ls -la /workspace 命令。

传统容器方案：
  - 创建容器：~2s
  - 执行命令：~50ms
  - 总计：~2050ms

Cloudflare Computer（轻量）：
  - 调度判断：~1ms
  - SQLite 读取：~2ms
  - 总计：<5ms（快了 400 倍）

5.2 资源消耗对比

5.3 调度准确率

Cloudflare 内部测试数据（2026年8月发布版）：

• 轻量化误判率：约 8%

  • 误判为轻量但实际需要容器的场景，主要是：pip install / npm install（需要网络）但被错误识别为本地命令
  • 解决方式：显式声明 requiresNetwork: true

• 容器误判率：< 2%

  • 主要发生在非常短的命令上走了容器后端（预热开销大于执行时间）

六、生态对比：Cloudflare Computer vs 竞品方案

6.1 竞品概览

6.2 核心差异分析

Cloudflare Computer vs E2B

E2B 是目前最成熟的 AI Agent 执行平台之一，特点是有成熟的沙箱安全机制和丰富的预置工具链。但 E2B 的执行后端是固定的全容器方案，没有轻量化路径。

Cloudflare Computer 的优势在于：

• SQLite 虚拟文件系统的设计更「数据库化」，便于增量快照和版本管理
• 智能调度可以根据任务自动选择轻量/容器，节省成本
• 与 Cloudflare OS 的 Durable Objects、Workflows 天然集成

但 Cloudflare Computer 的劣势：

• 刚开源（2026年8月），生态尚不成熟
• 缺少 E2B 那样的预置工具链（Python、Node、浏览器等镜像）
• TypeScript 优先，Python 开发者需要额外适配

Cloudflare Computer vs Modal

Modal 是一个通用计算平台，不专门面向 AI Agent，但其 Volums 功能（云端持久化文件系统挂载）解决了类似的问题。

Modal 的优势在于成熟的 SDK 和丰富的运行时选择（Python、Node、任何 Docker 镜像）。但 Modal 不是为 AI Agent 设计的——它的抽象层（App、Function、Image）更偏向传统后端开发。

Cloudflare Computer 的 AI Agent 原生设计（工具注册、状态记忆、调度器）是 Modal 所不具备的。

七、争议与挑战：Cloudflare OS 的「糖衣炮弹」

7.1 定价策略：免费额度背后的锁定逻辑

Cloudflare OS 的免费额度相当慷慨：

• 每天 10 万次 Agent 调用
• 1GB 向量存储
• 100 万次工作流步骤执行

对于独立开发者来说，这个免费额度足以支撑一个 MVP 运行一整年。

但批评者指出了「API 锁定」的风险：一旦 Agent 应用深度集成了 Durable Objects 的向量存储和 Workflows 的事件编排，迁移到 AWS/GCP/Azure 的成本将非常高。这不是「数据锁定」——你的数据可以导出——而是「架构锁定」——你的应用逻辑已经和 Cloudflare 的 API 深度耦合。

正如 HN 上的高赞评论所说：「Cloudflare 在 CDN 时代用'永远免费'吸引了数百万网站，在 AI 时代他们想用同样的策略复制这个剧本。区别在于，CDN 可以一夜之间换掉，嵌入向量数据库的 Agent 不行。」

7.2 SQLite 作为生产文件系统的局限性

SQLite 虚拟文件系统在轻量场景下表现出色，但在生产环境中面临几个现实问题：

1. 写入吞吐量：SQLite 的写锁机制在高并发写入时是瓶颈。如果多个 Agent 并发操作同一个工作区，写性能会显著下降
2. 大文件处理：虽然 SQLite 支持 BLOB，但超过 100MB 的文件存放在 SQLite 中效率不高
3. 并发连接数：SQLite 默认只支持单写，需要启用 WAL 模式才能支持有限的多写

Cloudflare 的解决方案是：将 SQLite 用于「元数据和命令记录」，而将大文件内容通过 Cloudflare R2（DDoS 防护的对象存储）分发。但这种混合架构增加了系统复杂度。

7.3 安全边界：V8 Isolate 隔离的信任模型

轻量后端使用 V8 Isolate 隔离而非容器，这意味着安全边界不如容器严格。V8 Isolate 可以防止 JavaScript 代码逃逸，但无法提供容器的完整系统级隔离。

对于需要处理用户代码的 Agent（如 Code Interpreter 场景），这是一个必须认真对待的风险。Cloudflare 的文档建议：对于不受信任的代码，始终使用容器后端。

八、未来展望：Agent 执行基础设施的演进方向

8.1 从「一台电脑」到「一个团队」

当前 @cloudflare/computer 的抽象是每个 Agent 拥有一台「专属电脑」。未来的演进方向是让多个 Agent 共享工作区——一个 Agent 写代码，另一个 Agent 做测试，第三个 Agent 部署上线，三者在同一个文件系统视图中协作。

这需要解决的核心问题：

• 跨 Agent 的并发控制（谁在写文件时其他人等待）
• 权限模型（不同 Agent 可以访问不同的目录）
• 审计追踪（每个操作是谁执行的）

8.2 边缘智能 + 端侧推理

Cloudflare 的网络优势（330+ 个城市数据中心，<50ms 延迟）为「边缘 Agent」提供了基础设施支撑。未来可能出现这样的场景：

用户手机上的 Agent（端侧推理，小模型）
    ↓ 发现需要复杂处理
    → 调度到最近的 Cloudflare 边缘节点（Cloudflare Computer）
    ↓ 边缘节点运行大模型 Agent
    ↓ 结果推回端侧

8.3 与 MCP 的协同

值得注意的是，Cloudflare 同时维护了 Firecrawl MCP Server——一个用于网页抓取和文档转换的 MCP 工具。结合 @cloudflare/computer，可以构建这样的工作流：

Agent 需要分析一个网站的技术栈
    ↓
调用 Firecrawl MCP 抓取页面
    ↓
@cloudflare/computer 虚拟文件系统保存抓取结果
    ↓
Agent 分析 HTML 内容，执行命令验证
    ↓
结果写入工作区，生成报告

九、总结：Cloudflare Computer 的意义与局限

9.1 它解决了什么问题

Cloudflare Computer 解决的核心问题是 AI Agent 执行环境的成本与灵活性矛盾。通过 SQLite 虚拟文件系统和智能调度，它让 Agent 的文件操作和命令执行可以在「零开销的轻量隔离」和「功能完整的容器」之间自动切换，大幅降低了 Agent 的执行成本。

9.2 它的局限性

这是一项发布不到一周的开源项目（截至 2026 年 8 月），它的局限性是客观存在的：

• 生态不成熟：缺少预置工具链、调试工具不完善
• 生产验证不足：没有大规模生产环境的案例
• 部分功能尚未公开：如完整的 Python SDK、企业级 SSO 等

9.3 适合的使用场景

推荐使用：

• 需要在边缘运行的轻量 Agent
• 成本敏感的 Agent 平台（初创公司、独立开发者）
• 与 Cloudflare Workers/Durable Objects 已有集成的项目

不推荐使用：

• 需要处理不受信任的第三方代码（安全边界不足）
• 需要 GPU 加速的场景（不支持）
• 需要复杂工具链（Docker-in-Docker、完整的 Linux 环境）

参考资料

1. GitHub: @cloudflare/computer - https://github.com/cloudflare/computer
2. Cloudflare Blog: "Unveiling good and bad behaviors on the Agentic Internet" - https://blog.cloudflare.com
3. Cloudflare OS 发布公告（企鹅号，2026-08-06）
4. GitHub Daily Rank - https://github.com/OpenGithubs/github-daily-rank（2026-08-06 数据）
5. Cloudflare Computer CSDN 解读 - https://blog.csdn.net/weixin_46946948/article/details/163533253
6. Firecrawl 官方文档 - https://www.firecrawl.link
7. SQLite 官方文档 - https://www.sqlite.org/docs.html

本文首发于程序员茄子（chenxutan.com），欢迎技术交流与讨论。