Cloudflare给每个Agent配电脑

Cloudflare 把 Agent 的“电脑”做成了一个开源库

Cloudflare 于当地时间 8 月 3 日发布早期预览版开源库 @cloudflare/computer，目标是为每个 AI Agent 分配一台拥有文件系统和命令执行能力的虚拟工作计算机。

@cloudflare/computer 是一个面向 AI Agent 的工作区与执行环境抽象层，它把文件读写、代码编辑、命令执行以及运行后端选择封装在同一套工具接口下。开发者不必默认给每个 Agent 常驻一套完整 Linux 容器，而是可以先在轻量级 V8 Isolate 中完成大部分操作，确实需要 Linux、npm、原生二进制文件或编译工具时，再切换到 Cloudflare Containers。

这项发布解决的不是模型“会不会写代码”，而是模型写完代码之后“在哪里安全地动手”。聊天机器人只要生成文本即可，编程 Agent 却必须读取仓库、修改文件、执行测试、观察报错，再根据结果继续迭代。没有持久文件系统和可控执行环境，Agent 就只有大脑，没有真正可用的双手。

独立计算机不等于独占一台虚拟机

Cloudflare 所说的“每个 Agent 一台计算机”主要指逻辑上独立的工作区与执行边界，而不是给每次会话永久占用一台传统虚拟机。每个 Agent 可以拥有自己的文件、Shell 操作范围和运行状态，但底层资源能够按任务类型动态调度，并在空闲时释放重型计算资源。

这是 @cloudflare/computer 最值得关注的设计判断。当前不少 Agent 平台直接以容器或 microVM 作为默认沙盒，这种方案兼容性高，也符合开发者对 Linux 环境的直觉，但每个实例都要承担操作系统、进程和内存开销。并发规模只有几百或几千时问题不大，一旦平台需要同时承载数百万个长时间等待模型响应、用户输入或外部任务的 Agent，常驻容器会把大量成本花在“什么也没做”的空闲时间上。

V8 Isolate 是一种共享宿主进程、但在内存和执行上下文上相互隔离的轻量运行环境。Cloudflare Workers 长期使用 Isolate 承载边缘 JavaScript 工作负载，其优势是创建和调度成本低，缺点是它并不是完整 Linux，不能直接假设所有系统调用、原生程序和软件包都能运行。

Cloudflare 的策略因此不是在 Isolate 与容器之间二选一，而是把两者分层使用。文件编辑、文本处理、数据转换和 Git 操作优先进入 Isolate；安装 npm 依赖、调用原生二进制文件、编译项目以及运行依赖完整 Linux 用户态的测试时，任务才会进入容器。

Workspace 是真正的核心

Workspace 是 @cloudflare/computer 中承载文件、状态和工具操作的统一工作区。它使用 SQLite 支撑虚拟文件系统，并能够从云存储、Git 仓库或开发者自定义的数据源导入内容。

SQLite 在这里并不是给 Agent 随手查询的一张业务数据库，而是文件系统抽象的一部分。传统 Agent 沙盒通常把状态绑定在某个容器磁盘上，容器销毁、迁移或休眠之后，还要额外处理数据持久化；Cloudflare 则试图把“文件属于工作区”与“命令在哪种计算环境执行”拆开，让执行后端可以变化，而文件视图保持一致。

统一工作区也降低了混合执行最容易出现的状态错乱问题。假设 Agent 先在 Isolate 中修改 package.json，随后发现必须运行 npm 和原生测试工具，系统可以启动容器，并让容器看到同一组工作区文件；测试产生的新日志和修改也会同步回工作区，Agent 不需要手工复制项目或重新构建上下文。

FUSE 是一种允许应用在用户态实现文件系统的机制。@cloudflare/computer 的容器后端通过 FUSE 挂载和同步工作区文件，使 Linux 工具看到的是熟悉的目录结构，同时让上层继续维持统一的文件状态。

这种设计可以类比为：Workspace 是 Agent 的办公桌和档案柜，Isolate 是随手可用的轻型工具台，Container 则是需要时才打开的完整实验室。Agent 换了工作地点，但桌上的文件仍然是同一份。

两种执行后端分别做什么

@cloudflare/computer 当前提供 Isolate 与 Container 两类执行后端，两者共享工作区，但在兼容性、资源成本和适用任务上存在明显差异。

| 对比项 | Isolate 后端 | Container 后端 | |---|---|---| | 底层环境 | Cloudflare V8 Isolate / Dynamic Worker | Cloudflare Containers 提供的 Linux 环境 | | Shell 实现 | 通过 just-bash 将 Shell 行为转换到 JavaScript 环境执行 | 在完整 Linux 用户态中执行命令 | | 适合任务 | 文件读写、文本与数据处理、Git 管理、轻量脚本 | npm、原生二进制文件、编译、完整测试工具链 | | 启动与资源特征 | 更轻，适合高并发和短任务 | 更重，但系统兼容性更完整 | | 文件访问 | 直接操作统一 Workspace | 通过 FUSE 挂载并同步 Workspace | | 主要限制 | 不等同于完整 Linux，系统能力有限 | CPU、内存和启动成本高于 Isolate | | 公开价格 | 本次预览公告未单独披露 | 本次预览公告未单独披露 |

just-bash 是一个在 JavaScript 环境中实现 Bash 风格命令与文件操作的工具。它让 Agent 可以使用接近 Shell 的交互方式完成 ls、文件处理和部分 Git 工作，而不必为了每条简单命令都拉起一套 Linux 容器。

这种转换层并不能神奇地把 V8 变成 Linux。涉及系统级依赖、平台专用二进制文件、复杂构建链或内核能力的任务仍然需要容器，因此开发者不应把 Isolate 后端理解为“更便宜的完整服务器”。它更像覆盖 Agent 高频轻操作的一条快速路径。

Agent 可以自己选择，但平台必须保留否决权

@cloudflare/computer 会把 read、write、edit、ls 和 exec 等能力作为兼容 AI SDK 的工具提供给模型。模型能够根据工具描述和任务要求选择执行方式，例如普通文件编辑走 Isolate，而依赖 Linux 或 npm 的命令进入容器。

模型参与路由可以减少开发者手写规则的工作量，但不应成为安全决策的最后一层。大模型可能误判任务，也可能在提示注入影响下尝试执行超出预期的命令，因此真正的生产系统仍需要权限门槛、命令范围限制、审计记录和可观测性，而不是相信模型“会自觉”。

Cloudflare 在这一层给出的方向是正确的：工作区内的操作可以设置权限条件，并接受审计与观测。对于企业 Agent，能够回答“哪个会话在什么时间读取了哪个文件、执行了什么命令、产生了哪些修改”，通常比单纯把代码关进容器更重要。

隔离环境也不能自动解决所有安全问题。一个 Agent 即使无法访问其他租户的文件，仍可能通过网络泄露当前工作区中的敏感数据，或者运行消耗大量 CPU、内存和存储的命令。实际部署仍要补齐出站访问控制、凭据按需注入、资源配额、执行超时和人工审批等机制。

它与 Cloudflare Sandboxes 有什么区别

Cloudflare Sandboxes 是由 Cloudflare Containers 驱动的持久化隔离环境，能够提供 Shell、文件系统、后台进程、代码上下文、休眠唤醒与快照恢复。它强调的是一台可持续使用的完整沙盒计算机。

@cloudflare/computer 更像位于 Agent 和底层算力之间的调度与工作区层。它并不是简单替代 Sandboxes，而是让开发者不必把每一个文件操作都交给完整沙盒：轻任务先进入 Isolate，只有必须使用 Linux 能力时才调用容器体系。

| 产品或方案 | 核心定位 | 状态持久化 | 完整 Linux | 后端选择 | 更适合的场景 | |---|---|---:|---:|---:|---| | @cloudflare/computer | Agent 工作区与混合执行抽象 | 支持统一工作区 | 按需提供 | Isolate 与 Container | 大规模、多租户 Agent 工具执行 | | Cloudflare Sandboxes | 持久化隔离计算机 | 支持磁盘、上下文与快照 | 支持 | 以容器环境为核心 | 代码解释器、开发环境、长任务 | | 常驻独立容器 | 传统单会话沙盒 | 取决于挂载方案 | 支持 | 通常固定为容器 | 规模有限、兼容性优先的任务 | | 纯函数执行 | 无状态短任务运行器 | 通常较弱 | 通常不支持 | 通常固定 | 单次转换、轻量计算和简单工具调用 |

两者组合后的产品逻辑更加清晰：Sandboxes 负责“真的给 Agent 一台 Linux 计算机”，@cloudflare/computer 负责判断 Agent 是否每一步都需要动用这台计算机。对于高并发平台，后者直接决定基础设施成本能否随 Agent 数量线性失控之前得到控制。

Cloudflare 想争的是 Agent 的运行时入口

Cloudflare 此次发布并非孤立的开源项目，而是其 Agent Cloud 基础设施布局的一部分。此前 Cloudflare 已经围绕 Workers AI、Agents SDK、Durable Objects、Workflows、Artifacts、Dynamic Workers、Containers 和 Sandboxes 补齐模型推理、状态、流程、存储与代码执行能力。

Agent 基础设施正在从“调用一个模型”变成“运营一批数字员工”。模型负责理解和规划，运行时负责文件、进程、网络、凭据、队列、状态恢复以及审计；后半部分越复杂，开发者就越难只靠几个工具函数搭出可靠系统。

Cloudflare 的优势是把这套运行时放到既有全球边缘网络和 Workers 生态中。对于需要靠近终端用户执行、同时存在大量短会话和突发并发的 Agent，Isolate 的资源模型确实比默认启动完整虚拟机更有吸引力；对于依赖复杂 Linux 工具链的编码 Agent，容器后端又保留了必要的兼容性。

Cloudflare 的短板则是抽象层正在快速增多。Workers、Durable Objects、Workflows、Agents SDK、Sandboxes、Containers、Artifacts 与现在的 @cloudflare/computer 各自解决一部分问题，但它们之间的职责边界需要开发者重新学习。如果诊断工具、成本归因和故障追踪跟不上，所谓统一平台也可能变成一组耦合较深的专有组件。

现在还不能只看“更快、更便宜”

本次公告没有公布 @cloudflare/computer 的统一价格、Isolate 与容器切换延迟、单位工作区存储成本，也没有给出与纯容器方案对比的标准化基准测试。Cloudflare 强调 Isolate 更轻、更适合扩展，在架构上成立，但开发者暂时还无法根据公开数字计算一万个并发 Agent 的真实账单。

早期预览版也意味着接口和执行语义可能继续变化。尤其是 Shell 兼容范围、文件同步冲突、容器唤醒时间、长任务中断恢复、Workspace 容量上限以及多 Agent 并行修改同一仓库时的锁策略，都会决定它能否从演示环境进入生产系统。

真正值得测试的并不是一次 ls 能快多少，而是完整 Agent 任务的成功率和总成本。一个轻量后端如果因为兼容性不足导致模型多轮试错，节省下来的容器时间可能又被额外模型推理消耗掉；反过来，如果绝大多数操作确实只是读取、编辑和检索文件，那么每一步都启动 Linux 环境显然过于浪费。

判断：方向对了，胜负取决于执行细节

@cloudflare/computer 最有价值的地方，是把 Agent 的“计算机”从固定机器改造成可拆分、可调度的能力集合。文件系统可以持久存在，轻量命令可以在 Isolate 中快速执行，完整 Linux 则成为按需调用的重型工具，这比“每个 Agent 永久绑定一个容器”的方案更符合大规模智能体的负载特征。

这套架构尤其适合代码审查、仓库维护、数据整理、报表生成和多租户 SaaS Agent。此类任务包含大量等待和轻文件操作，真正需要编译或运行复杂工具的时间只占一部分，混合执行有机会明显降低空闲资源消耗。

这套架构暂时还不适合被视为完整开发机的无差别替代品。需要 Docker-in-Docker、特定内核模块、GPU、复杂桌面程序或高度定制系统环境的 Agent，仍然要依赖更传统的虚拟机、microVM 或容器基础设施。

Cloudflare 押注的是一个正在形成的行业共识：下一代 Agent 平台的竞争，不只看谁接入的模型更强，也看谁能以更低成本、安全地给数百万个 Agent 提供文件、进程和网络。@cloudflare/computer 还只是早期预览，但它已经把问题定义得足够准确——Agent 不只是需要一个沙盒，而是需要一台能在轻量工具台与完整 Linux 之间自动切换的计算机。

参考来源

• IT之家：Cloudflare 推出新开源库，为每个 AI 智能体配备独立工作计算机——整理了 2026 年 8 月 3 日官方公告中的 Workspace、SQLite 虚拟文件系统、Isolate、just-bash、FUSE 与容器后端等关键信息。