Cloudflare Computer 开源：Agent 真正需要的是一台可操作的电脑

预计阅读时间：9 分钟

Cloudflare 开源了 @cloudflare/computer 这个 npm 包，并提出了一个值得工程团队重新审视的判断：给 AI Agent 准备执行环境时，容器未必是默认答案。很多 Agent 需要的不是一台只会启动进程的服务器，而是一台能够打开网页、运行程序、保存状态并持续交互的电脑。

Cloudflare 的方案把重点放在 Isolate 上。Cloudflare 工程师过去十年一直使用 Isolate 运行代码，因此他们更倾向于把 Agent 放进轻量、快速启动、资源边界清晰的隔离运行时，而不是为每个任务启动一套完整容器环境。

容器解决了什么，Agent 还缺什么

容器擅长打包应用及其依赖，提供进程级隔离，并让后端团队用熟悉的方式部署服务。但 Agent 的工作形态通常更像一个持续操作系统：

它需要访问浏览器或图形化应用；
它可能需要在多轮任务之间保留文件、Cookie 和登录状态；
它会反复执行命令、读取结果，再决定下一步动作；
它的任务持续时间和资源消耗往往不可预测；
大量短任务需要快速启动，不能把启动一个完整容器的开销叠加到每次调用中。

容器并非不能完成这些事情。通过浏览器容器、远程桌面、虚拟显示器和持久化卷，团队可以拼出一台“云电脑”。问题在于，系统复杂度、冷启动时间、资源调度和生命周期管理都会迅速上升。

Isolate 的思路是把执行单元做得更轻：每个 Agent 获得一个隔离的运行上下文，代码在其中执行，资源使用受到限制，任务结束后可以销毁。对于大量并发、短生命周期的 Agent 任务，这种模型更接近实际负载。

“一台电脑”意味着什么

这里的“电脑”不一定指一台传统虚拟机，也不只是给模型暴露几个 HTTP API。它更接近一个可被 Agent 使用的计算工作区，至少应当明确以下能力：

执行：能运行脚本、命令或工具调用。
观察：能读取命令输出、页面内容、文件变化或应用状态。
操作：能根据观察结果继续点击、输入、调用接口或修改文件。
记忆：能选择性保留文件、认证信息和任务上下文。
收敛：能设置 CPU、内存、执行时间、网络和文件系统边界。

这也改变了 Agent 基础设施的抽象。过去我们常说“给模型一个工具列表”，现在更应该问：“给模型准备的工作区是什么？工作区如何被创建、观察、恢复和销毁？”

可以这样搭一个最小工作流

下面的命令可以直接创建一个 Node.js 试验项目并安装 Cloudflare 的包。具体的导出函数和运行时 API 应以当前项目文档为准，因此示例中的 createComputer 部分明确标为适配层伪代码；它展示的是集成边界，而不是对包 API 的硬编码承诺。

mkdir agent-computer-demo
cd agent-computer-demo
npm init -y
npm install @cloudflare/computer

可以把 Agent 调度逻辑分成四个阶段：创建隔离工作区、执行动作、采集观察结果、销毁或保存状态。

// index.mjs
// 假设：当前版本提供一个可创建隔离工作区的适配 API。
// 请按实际版本文档替换 createComputer、run 和 destroy 的调用方式。
import { createComputer } from "@cloudflare/computer";

const computer = await createComputer({
  timeoutMs: 60_000,
  memoryMb: 512,
  network: "restricted",
  persistent: false
});

try {
  const result = await computer.run("node -e \\"console.log('agent workspace ready')\\"");

  const observation = {
    exitCode: result.exitCode,
    stdout: result.stdout,
    stderr: result.stderr
  };

  console.log(JSON.stringify(observation, null, 2));
} finally {
  await computer.destroy();
}

实际接入时，建议把模型和执行环境隔开。模型只负责提出下一步动作，执行器负责校验动作、应用权限和返回结构化结果：

const allowedActions = new Set(["read_file", "run_test", "open_url"]);

function validateAction(action) {
  if (!allowedActions.has(action.type)) {
    throw new Error(`Unsupported action: ${action.type}`);
  }

  if (action.type === "open_url" && !action.url.startsWith("https://example.com/")) {
    throw new Error("URL is outside the allowed domain");
  }
}

async function executeAgentStep(computer, action) {
  validateAction(action);
  return computer.execute(action);
}

这层校验很重要。Isolate 解决的是执行环境隔离，不会自动替你解决 Agent 越权、提示注入、敏感数据泄露或网络访问失控等问题。

迁移时要做的工程取舍

采用 Isolate 风格的 Agent 运行时，收益主要来自启动速度、并发密度和生命周期控制，但它也有边界。

适合优先尝试的场景：

大量短任务，例如网页信息提取、代码检查和一次性数据转换；
需要让不同用户或任务之间保持强隔离的执行环境；
任务状态可以显式保存，而不依赖一台长期运行的机器；
团队希望按任务粒度控制网络、文件和资源权限。

仍然可能需要容器或虚拟机的场景：

必须运行复杂的系统服务或长期后台进程；
依赖特定内核能力、设备访问或完整操作系统环境；
需要安装大量原生依赖，且启动环境必须高度可控；
任务本身是长时间运行的工作负载，而不是短暂的 Agent 回合。

一个稳妥的架构通常不是二选一：用 Isolate 承载轻量 Agent 回合，把重型构建、浏览器集群或特殊系统依赖转发给受控容器或虚拟机。关键是让 Agent 的默认工作区足够轻，并把升级到更重运行时变成显式决策。

上线前检查清单

为每个工作区设置最大执行时间和内存上限。
默认关闭不必要的网络访问，只开放目标域名或服务。
将文件系统分为临时区和明确持久化区。
不把主机密钥、生产凭据和完整环境变量直接注入 Agent。
对每个动作记录调用者、参数、结果和耗时。
对浏览器或外部页面输入进行提示注入防护和权限隔离。
让工作区销毁成为默认路径，恢复状态必须显式开启。
用真实任务测量冷启动、并发密度、失败恢复和单任务成本。

Cloudflare Computer 的核心启发，不是把所有容器都替换掉，而是提醒我们重新选择 Agent 的计算抽象：当任务需要持续观察和操作一台电脑时，运行时就应该围绕“隔离工作区”设计，而不是简单地把模型塞进一个容器里。