cloudflare/computer：8.3k stars 的「给 agent 一台云端电脑」，把 Durable Object + FUSE 容器、Worker Shell、JS 三个 backend 串成一个 API

发表于 分类于
cloudflare/computer 是 GitHub 8.3k stars 的 Cloudflare 官方边缘沙箱项目，把 SQLite-backed 虚拟文件系统塞进 Durable Object，提供 Container / Worker Shell / Worker JavaScript 三个可插拔 backend，统一通过 workspace.runtime.exec 入口调用，让 AI Agent 可以直接在 Cloudflare 边缘上跑真 Linux、跑 bash、跑 JS，并把状态用 FUSE 挂载成真实文件系统。

凌晨两点，我让 Cursor 帮我写一段 MongoDB 聚合查询。它写得很漂亮，一键应用、改了 .env 又 npm test 跑过去 —— 就在我要存盘睡觉的时候，Cursor 突然弹出一句：” 需要我帮你 push 到 GitHub 吗？” 我心头一紧：它跑的是我笔记本里的 node，能 ssh 到我的服务器，能扫我 /Users/daishengli 整个目录。

这不是假设的恐惧。这是过去一年每一个重度 Claude Code / Codex / Cursor 用户的真实阴影。

我们想要 AI Agent 替我们写代码、跑命令、装包、起服务，但我们不希望这件事发生在我们上班用的那台 MacBook 上。于是过去两年里，”AI 沙箱” 这个赛道彻底炸开了：e2b、daytona、modal、codesandbox、gitpod、namedev/morphcloud、cloudflare/sandbox-sdk、阿里 pages-agent…… 全都想做同一件事 —— 给 agent 一台干净、隔离、按需启停、可以随时销毁的云端电脑。

今天 GitHub Trending 上冒出来的是 Cloudflare 官方自己下场做的版本：cloudflare/computer。8.3k stars、1.9k 本周新增，仓库的 README 第一句话就是 ——

“Give your agent a computer 👾”

这四个字，对一个长期关注 AI Agent 基础设施的人来说，几乎是直击命门。

我花了半个晚上读它的源码、AGENTS.md、设计文档、跟 sandbox-sdk 做对比，决定把它拆开讲讲：一个 Cloudflare 工程师为什么觉得” 把 computer 塞进 Durable Object” 是值得认真做的方向；它跟现有 sandbox 生态的差异在哪；以及，我们作为 agent 的开发者，到底为什么应该关心这个项目。

一、为什么 AI Agent 需要一台” 云端电脑”

把场景往前推一推。

你让 Claude Code 帮你做一个新功能，处理流程大概是这样：

  1. 它要 git status 看仓库状态；
  2. 它要 npm install 装新包；
  3. 它要写文件、跑测试、再 git commit；
  4. 有时候它要起一个 dev server 验一下页面跑得对不对；
  5. 万一你让它” 顺手把那个 issue 也修了”，它可能要去 clone 另一个仓库下来。

这些动作在 Claude Code 自己的环境里跑确实方便，但代价是 —— 它能干任何事。删文件、改 .env、rm -rf / 写过的惨案 Github 一搜一大把。所以从 2024 年开始，所有想做” 严肃 agent” 的厂商都在解决同一件事：怎么让 agent 跑在一个独立的、隔离的、按需启停的执行环境里，不直接碰用户的本机。

市面上已有的方案大致分三类：

第一类：传统 VM / 容器平台。Firecracker、Fly machines、AWS Lambda。优点是隔离性好、技术成熟；缺点是冷启动慢（几百毫秒到几秒）、部署流程复杂、面向开发者友好但面向 agent 不友好。

第二类：专门给 AI 的 sandbox SDK。e2b、daytona、Modal、morphcloud。一行 e2b.Sandbox.create() 拿到一个隔离的 Linux 容器，里面 Python/Node 装好、文件系统可挂载、命令可远程执行。冷启动已经做到 200ms~1s，是为 agent 量身定做的。

第三类：Cloudflare 自己的 sandbox-sdk。基于 Durable Object + Container，去年 Cloudflare 推 Workers Containers 时就内置了类似的 API。优点是全球化边缘 + 边缘低延迟 + Cloudflare 生态一行代码部署；缺点是 Container 冷启动相对更慢，而且早期 sandbox-sdk 暴露给开发者的接口比较” 裸”，要写不少胶水代码。

cloudflare/computer 想要做的，是第三类的” 上半身”—— 建筑在 sandbox-sdk 之上，提供一个更高层的抽象：把” 一台 computer” 这个概念本身，做成一类 first-class 对象，让 agent 开发者用同一个 API 同时调度 Container、Worker Shell、Worker JavaScript 三种不同的执行后端。

这件事听起来小，但意义大。

二、cloudflare/computer 到底是什么

直接说结论：cloudflare/computer 是 Cloudflare 官方开源的一个” 虚拟电脑” 抽象层，它把一个 SQLite-backed 的虚拟文件系统塞进 Durable Object，向上提供三套可插拔的执行 backend：

  1. Container backend—— 真 Linux 容器、FUSE 挂载、原生二进制、原生网络。
  2. Isolate Shell backend—— 在 Dynamic Worker 里跑 Vercel 的 just-bash，无容器、毫秒级冷启动。
  3. Isolate JavaScript backend—— 在 Dynamic Worker 里跑原生 ECMAScript module，结构化输入 / 输出、可访问 workspace 文件系统、可挂 ws:git / ws:artifacts 等受信任模块。

三种 backend 共享同一个 API：workspace.runtime.exec(source, { backend })。source 在 container 里是 shell 命令，在 Isolate backend 里是 ECMAScript module 或 bash 脚本 ——backend 决定了 source 该怎么解释，调用方完全不用 care。

这是我读完 README 之后最震动的一点：它不是一个 sandbox 选项，而是把” 沙箱” 这件事本身做成了一个模式。

让我再拆细一点。

1. 权威状态：Durable Object + SQLite

cloudflare/computer 的整个故事，建立在一个看似平淡但其实非常聪明的设计选择上：把” 这台电脑的硬盘” 做成一个 Durable Object 里的 SQLite 表。

为什么是 SQLite？因为：

  • Durable Object 本身就是 Cloudflare 边缘计算里少数几个能持有” 长生命周期单实例状态” 的对象；
  • SQLite 在 Cloudflare 内部已经作为 DO 的存储后端，访问延迟极低；
  • SQLite 天然支持事务、文件粒度锁、二进制大对象 —— 刚好对应一个虚拟文件系统的需要。

这意味着这台 computer 的文件系统不是某个易失的容器磁盘，而是 Cloudflare 边缘上一个强一致、能跨请求保留、可以随时 persist 的数据库。container 死了，文件还在；shell session 退了，文件还在；agent 第二天回来，文件还在。

packages/dofs（@cloudflare/dofs）就是这套东西的实现 ——Durable Object SQLite-backed 虚拟文件系统，外加同步协议的构建块，以及一个给 Node.js 用的 @platformatic/vfs provider。

2. FUSE 挂载：让容器” 真看见” 数据库

光把文件存进 SQLite 不够。Container backend 真正的杀手锏，是把 SQLite 状态通过 FUSE 挂载为容器内的真实文件系统。

具体怎么做的：

  • 容器里跑一个叫 computerd 的 daemon（packages/computerd）；
  • 这个 daemon 用 libfuse 把 DO 里的 SQLite 表挂载成一个 FUSE 目录；
  • 容器内的所有命令（ls、cat、npm install、git clone）看到的都是一个带真实 inode、真实文件层级、真实权限的 POSIX 文件系统；
  • 任何文件写入会通过 capnweb RPC 通道同步回 DO 的 SQLite；任何文件读取反过来从 DO 拉。

这条路径的效果是 —— 容器内不需要任何 SDK、不需要任何 wrapper，bash /git/npm /node 这些原生二进制可以直接运行，根本” 不知道” 自己其实在操作一个挂在 SQLite 表上的虚拟磁盘。

性能上，README 自己提到：FUSE 挂在元数据密集的工作上比真实磁盘快，在大块顺序 I/O 上比真实磁盘慢。具体数据在他们 docs/19_performance.md 里有 fs-bench 完整数字，包括和 cloudflare/sandbox-sdk 的 npm install 对比。

3. capnweb RPC：DO 与 computerd 的” 神经系统”

FUSE 解决了” 容器内文件系统感知” 的问题，但还有另一个问题：容器进程和控制平面（DO）之间怎么通信？

cloudflare/computer 用的是 Cloudflare 自家的 capnweb：

  • 一个面向 capability 的 RPC 系统；
  • 双向、对象能力（object-capability）的 stub；
  • Durable Object 是 server，computerd 是 client；
  • 同步、文件操作、git 操作、artifacts 操作，都通过 capnweb 走。

packages/rpc（@cloudflare/computer-rpc）就是这套 RPC 的 wire types 和服务端 / 客户端 helpers。任何” 跨 DO ↔ computerd 边界” 的修改，都必须先读 docs/08_capnweb_interface.md 和 capnweb skill—— 这是 README 自己强调的”hard rule”。

4. 三个 backend，三种成本

Backend 真实 Linux 冷启动 网络 适合场景
Container ✅ 数百 ms~ 秒级 真实网络 装包、跑 binary、clone 仓库、安装系统工具
Isolate Shell ❌（just-bash） 毫秒级 受限 跑纯 bash 脚本、文件操作、轻量命令
Isolate JavaScript ❌（Workers V8） 毫秒级 受限 跑 ECMAScript module、调用受信任模块

关键 trick：开发者不用提前选 backend。workspace.runtime.exec(source, { backend }) 里那个 backend 参数是运行时的，你可以根据任务复杂度动态切换：

  • 让 agent 跑 ls -la？走 Isolate Shell，毫秒级回。
  • 让 agent 跑 npm install？切到 Container，真实 npm 真的装。
  • 让 agent 跑一段数据处理 JS？走 Isolate JavaScript，毫秒级回。

这种” 同一个 workspace 跨 backend 共享状态” 是 cloudflare/computer 区别于一般 sandbox SDK 的核心差异。

三、仓库结构：5 个 npm 包 + 9 个 example

clouflare/computer 是个典型的小 monorepo，每个 package 各自有自己的 README。

包结构

包 作用
@cloudflare/dofs Durable Object SQLite-backed 虚拟文件系统、同步协议构建块、Node 侧 @platformatic/vfs provider
@cloudflare/computer-rpc capnweb wire types + server/client helpers
@cloudflare/computerd computerd daemon：FUSE 挂载 + HTTP/WebSocket RPC server，跑在容器里
@cloudflare/computer 顶层 Computer 包，DO 侧消费
@cloudflare/computer-computerd-linux-x64 私有 Docker image context，预编译的 computerd linux-x64 二进制；真正交付的是 Docker image，不是 npm 包

stack 看起来有点反直觉 —— 为什么 computerd 是 Docker image 而不是 npm 包？因为它的本体是运行在容器里的 FUSE daemon，需要 libfuse2、native binary、容器能力，这些都不适合作为 npm 包分发。所以要做的事情是：build → publish Docker image → computer 启动时拉 image → 跑 computerd。

9 个 example，覆盖 90% 用法

这是我觉得这个项目最值得抄作业的地方。examples/ 下面 9 个跑得动的 example，每个单独一个 Worker + 独立 README，相当于 Cloudflare 官方给你写了 9 篇应用教程：

Example 作用
examples/container 在容器里跑 computerd、挂载 workspace、透过 capnweb 跟 DO 通信，暴露 write /read/exec HTTP 接口
examples/worker-shell 同样的 HTTP 接口，但 shell 跑在 Dynamic Worker 里的 just-bash，无容器
examples/worker-javascript 跟 worker-shell 类似，但 exec 跑的是 ECMAScript module
examples/egress 同一个 URL 走三种 backend，配置 none /all/ 自定义 egress 策略
examples/mcp 一个 Computer MCP 例子：同一个 Code Mode code tool，背后挂着 durable workspace + Worker shell + 完整 Linux 容器
examples/think 一个 @cloudflare/think chat agent，把 workspace 当工作目录，CLI 终端可达
examples/think-compare-runtimes 一个 web UI，同一个 agent 任务同时跑在 container 和 worker runtime 上做对比
examples/tutorial 端到端教程：一个 endpoint，一个 agent 在 host 上写 markdown recipe，跑到容器里用 pandoc 转 PDF
examples/artifacts 在 workspace 里生成一个 Worker 项目，发布到 Cloudflare Artifacts 作为可 clone 的 repo
examples/assets 提示词生成图（Workers AI），写入 workspace，通过 @cloudflare/computer/assets 返回可分享链接

每一个 example 单独都是一个能跑的小产品。挑你需要的 example 抄一份，10 分钟就能搭起一个能调 Claude Code 的沙箱。

.agents/skills/：给 agent 写的” 对内文档”

最有意思的一个细节 —— 这个仓库的 .agents/skills/ 下面已经放好了给 agent 写的” 操作手册”：

Skill 触发场景
prose 写代码注释、commit message、README、文档
pull-requests 写或编辑 PR 描述
test-driven-development 实现逻辑、修 bug、改行为
capnweb 任何跨 RPC 边界的修改（packages/rpc、computer、computerd 客户端、DO 服务端）
cloudflare Workers、Durable Objects、wrangler、sandbox SDK、agents SDK 的 host-side skill 索引
debugging-computerd-fuse 在特权 Docker 里 debug FUSE mount

这基本上是 Cloudflare 工程师在示范一件事：当你的项目复杂到一定程度，怎么把”agent 怎么参与贡献” 这件事本身做成结构化资产。我估计这个项目本身的开发流程里，agent 已经是常规 contributor。

四、实战：10 分钟搭一个能调 Claude 的 computer

既然仓库已经给了 9 个 example，最快的上手路径其实就是挑一个 example 抄。

下面我把 examples/think + examples/mcp 这两个拼起来，演示一个最小可用的”agent 沙箱”：

1. 克隆 & 装依赖

1
2
3
git clone https://github.com/cloudflare/computer.git
cd computer
npm install

⚠️ 这里有个新手坑 ——packages/computerd 依赖 fuse-native，一个 native addon，需要 C toolchain 和 libfuse2 头文件。在 Debian/Ubuntu 上：

1
apt-get install build-essential libfuse-dev

如果只想看代码不想跑 FUSE，可以用 npm install --ignore-scripts 跳过 native build。

⚠️ arm64 主机还有第二个坑 ——fuse-native 预编译的 libfuse 只有 x64 版本，跑在 Linux arm64 容器（含 Apple Silicon 上的 Linux 容器）会链接失败，得手动替换成本地 libfuse 再 rebuild。AGENTS.md 里给了完整 workaround。

2. 跑 worker-shell example

1
2
cd examples/worker-shell
npm run dev

worker-shell 这个 example 直接在你的 machine 上跑一个 Worker SDK dev 环境，背后挂的 shell executor 是 Isolate Shell（just-bash）。

往 localhost:8787/exec POST 一个命令：

1
2
3
curl -X POST http://localhost:8787/exec \
  -H "Content-Type: application/json" \
  -d '{"source": "ls -la /workspace && echo hello"}'

你会看到返回的是 JSON 化的 stdout / stderr / exit code。整个 backend 已经在跑 just-bash，没起任何容器。

3. 切到 container backend

把 examples/worker-shell 的 payload 改成 { "source": "npm install -g pnpm", "backend": "container" }：

1
2
3
curl -X POST http://localhost:8787/exec \
  -H "Content-Type: application/json" \
  -d '{"source": "npm install -g pnpm && pnpm --version", "backend": "container"}'

Cold start 会慢几百毫秒到几秒（要拉 computerd 的 Docker image 起 container），之后 pnpm --version 返回正版版本号。

关键点：两次 exec 之间，workspace 状态是连续的 —— 第一次你在 container 里写下的文件，第二次在 worker-shell 里能看到。这是为什么”DOFs + capnweb” 这个底座值钱。

4. 把它做成 MCP server

把 examples/mcp 拷过去当模板。这个 example 已经替你写好了一个”Code Mode code tool”—— 一个 tool，背后同时挂三种 backend，agent 拿到这个 tool 之后能通过在 source string 里指定 backend 自由切换。

跟 Claude Code 集成：

1
2
3
claude mcp add --transport http \
  --name "computer" \
  http://localhost:8787/mcp

接下来你在 Claude Code 里直接说：

“在 /workspace 下面建一个 vite 项目，然后用 pnpm 装依赖，最后跑 pnpm build 看有没有错。”

Claude 会主动用 computer 这个 MCP tool。它的所有写文件、装包、跑命令，全部跑在 Cloudflare 边缘容器里 —— 你 MacBook 上的 ~/ 保持干净。

5. 配 egress

examples/egress 给了一份” 网络出口白名单” 的范例：

1
2
3
4
// worker-shell 的 wrangler.toml 里
[vars]
EGRESS_POLICY = "allowlist"
EGRESS_ALLOWLIST = ["github.com", "registry.npmjs.org", "api.anthropic.com"]

默认情况下 Isolate backend 走 Cloudflare 的 egress 出口，container backend 走自己配置的 egress。生产部署时强烈建议配 allowlist，否则 agent 能访问整个公网。

五、和 sandbox-sdk /e2b /daytona 的对比

这一节是我自己写之前最想搞清楚的 —— 到底有了 cloudflare/sandbox-sdk 还要 cloudflare/computer 干嘛？

维度 sandbox-sdk cloudflare/computer e2b / daytona
部署位置 Cloudflare 边缘 Cloudflare 边缘 第三方云
Cold start 容器拉起 容器拉起（容 backend）
毫秒级（Isolate）		 200ms~1s
执行后端 单一 Container Container + Isolate Shell + Isolate JS 单一 Firecracker/Container
持久化 Container 卷 SQLite-backed DO，强一致 临时 sandbox，重启丢
跨 backend 共享 ❌ ✅ 同一 workspace 共享 ❌
MCP 原生 ❌ ✅ examples/mcp 各自提供
自建 Computer-Use Agent 较裸 抽象更完整 较裸
主语言 TS TS 多语言
协议 Cloudflare Services Cloudflare Services REST / gRPC

几个关键观察：

  1. cloudflare/computer 和 sandbox-sdk 不冲突。官方文档里有一段对比 docs/19_performance.md 里的 fs-bench，结论是 FUSE 挂在元数据密集场景反而比真实磁盘快 —— 这个结论我看完有点意外，但也合理：access pattern 变了，瓶颈从 IO 变成了 SQLite 索引查询。

  2. 持久化是核心差异。e2b /daytona 的 sandbox 大多按” 会话” 算，agent 退出会话状态就丢了。cloudflare/computer 把 workspace 直接做成 DO 的 SQLite，这是”agent 的工作目录” 应该有的样子 ——agent 第二天回来，文件还在，session-resume 是免费的。

  3. 跨 backend 共享是 second-order 的杀手锏。想象一个场景：agent 跑了一晚上 npm install 装好依赖，sleep 醒来要跑测试。如果中间某个 backend 升级、或者用户切到另一个 backend，状态不能丢。cloudflare/computer 用 SQLite + FUSE 把这件事做成了基础设施级别。

  4. MCP example 体现 Cloudflare 的判断。他们认为 2026 年 agent 互操作的事实标准是 MCP，所以 examples/mcp 不是后补的 demo，而是仓库的第一公民 —— 一个 Code Mode 工具，背后挂三种 backend。

六、关键设计选择：capnweb + FUSE + SQLite

我觉得值得单独开一节讲 cloudflare/computer 的架构选择，因为这些选择直接决定它能不能 work。

为什么是 SQLite 而不是 KV / R2 / S3

Cloudflare 自己的存储选项有 KV、R2、D1、DO 内置 SQLite。这里用 DO 内置 SQLite 而不是 KV / R2 / D1，原因有三：

  1. 延迟：DO 内部 SQLite 是 in-process，访问延迟在微秒级；KV/D1 都要走 RPC。FUSE 这种” 每读一个文件就要查询一次” 的工作模式，延迟会被放大成倍。
  2. 事务粒度：SQLite 提供自然的文件级别事务，KV 没事务，D1 事务延迟太高。
  3. 可控性：FUSE 路径上需要锁定、写前镜像、增量同步 —— 这些都需要” 够底层” 的数据库。

为什么是 FUSE 而不是 mount-bind /overlayfs

FUSE 不是 Linux 标准容器里挂文件系统的唯一方式。FUSE vs mount-bind vs overlayfs：

  • mount-bind：直接挂目录进去，简单但状态不可控。
  • overlayfs：经典的容器文件系统分层，但需要特权和协调 mount 命名空间。
  • FUSE：用户态文件系统，完全受控的” 虚拟磁盘” 语义 —— 这是 cloudflare/computer 想要的，因为 DO 侧的 SQLite 是唯一权威。

所以 FUSE 不是” 凑合用”，而是 ** 为了” 把数据库当成磁盘来用”** 这个语义表达。

为什么是 capnweb 而不是 WebSocket /fetch

capnweb 是 Cloudflare 自家的 RPC 协议，关键特性是 object-capability，每个 stub 都是一次性的、可被远端 dispose 的。这意味着 leak 会被 record 和 report——AGENTS.md 里专门提到：”Stubs are object-capabilities; dispose them. Leaks are tracked by the harness in packages/rpc.”

对 FUSE 同步这种” 双向、长期、断线重连敏感” 的场景，capnweb 比裸 WebSocket 友好得多。

为什么 backend 是 runtime-level 而不是 compile-time

workspace.runtime.exec(source, { backend: "container" | "shell" | "javascript" }) 这种 runtime 切换，而不是在 wrangler.toml 里 [[unsafe.bindings]] 静态绑定，本质上是为了让”agent 选择 backend” 成为可能。

agent 看到命令的复杂度，自己决定哪个 backend。这是把” 调度决策” 留给上层 agent，而不是让 sandbox SDK 替你做。

七、适用人群 & 局限性

cloudflare/computer 适合哪些人？

  • 想给自己的 Claude Code / Cursor / Codex 配一个云端沙箱 ——examples/think + examples/mcp 改一改就能用。
  • 在做 Computer-Use Agent（类似 Claude Computer Use 或 OpenAI Operator）的开发者 ——FUSE + 三个 backend 给了你” 远程 Linux 的所有可能性”。
  • 在做 AI Agent 平台（内部 AI 工具、企业 agent 平台）——MCP 原生支持 + 边缘部署 + 跨 backend 共享状态，是过去一直被各种 hack 解决的核心痛点。
  • 在做 AI 编程工具 ——examples/artifacts 直接演示了”agent 在 workspace 里写一个 Worker 项目，发布到 Cloudflare Artifacts”，这是 AI 写代码 + 部署的最小闭环。

不适用：

  • 生产环境。README 第一页就写了 “PREVIEW ONLY – This package is provided as a preview for feedback only. APIs are unstable and the design is subject to change”。要看清楚再上生产。
  • 需要 GPU 跑大模型推理。Container backend 是普通 Linux 容器，没有 GPU 绑定；要跑本地 LLM 依然得用别的方式（modal、runpod、或者云上 GPU VM）。
  • 需要 Windows 兼容性。FUSE 是 Linux 特性，container 跑在 Linux 镜像里；要 Windows agent 体验得绕。
  • 需要强一致的多 agent 协作。DO 本身是单实例 SQLite，多 agent 共享同一个 workspace 需要在应用层加锁。

八、它对我意味着什么

最后讲一讲我自己看完这个仓库的两个感受。

第一，“computer” 这个词在 AI Agent 时代被重新定义了。三年的 ChatGPT 时代我们说”AI 是 copilot”；这两年我们说”AI 是 agent”；接下来这个项目让我看到的下一阶段是 ——“AI 是一台 computer”。CPU、内存、文件系统、进程、网络出口、生命周期 —— 这些本来就是一台 computer 的全部属性。Cloudflare 这次不只是做 sandbox，它是在 sandbox 之上定义一个 first-class 的”AI computer” 类型。

第二，它把” 沙箱” 这件事的门槛打成地板了。过去的 sandbox SDK 至少要你懂 Firecracker、懂容器编排、懂 VPC 配 egress。cloudflare/computer 用 9 个 example + 一份清晰的设计文档，把” 做一个能调 Claude 的 computer” 这件事做到了 10 分钟级别。这是我过去一年看到的最” 准备好被大规模复制” 的基础设施项目之一。

写在最后

如果说 OpenAI Operator / Anthropic Computer Use 还在演示”agent 在你屏幕上点按钮”，cloudflare/computer 在讲的是 **”agent 应该跑在你看不到的电脑里”**。

把 SQLite 塞进 Durable Object，把 FUSE 变成” 数据库挂载器”，把 capnweb 变成”computer 和 DO 之间的神经”，把 Container / Shell / JS 三个 runtime 串成同一个 API——Cloudflare 工程师用他们过去几年积累的边缘基础设施，做了一个让 AI Agent 真正落地时最缺的那一块拼图。

8.3k stars 还在涨，仓库目前还算早期，API 还会变，但方向我觉得是确定的。

如果你是 agent 开发者、如果你在挑 sandbox、如果你关心 MCP 未来的生态位 ——cloudflare/computer 这个仓库值得花一个周末跑一遍 9 个 example。

GitHub 仓库：https://github.com/cloudflare/computer
MIT 协议，Cloudflare 官方开源。
重要提示：当前是 Preview 状态，API 不稳定，不建议直接用于生产。

作者：小戴 | 数字游民、Java 全栈 / 大模型 / AI Agent 长期关注者。如果你也在做 agent 基础设施，欢迎在博客评论区或 X 上找我聊。