agentOS：92倍冷启动的开源 Agent 运行时

“把操作系统作为一个库交给 Agent。冷启动快 92 倍，内存占用少 47 倍，成本比沙箱低 254 倍。”

这是「每天一个开源项目」系列的第 137 篇文章。今天介绍的项目是 agentOS——一个以 npm package 形式分发的 AI Agent runtime。它允许你直接在自己的 Node.js 后端中运行 AI 编程 Agent，无须启动任何外部 sandbox、microVM 或 container。

为 AI Agent 提供执行环境，正在逐渐演变成一个基础设施问题：E2B、Daytona、Modal 等 sandbox 服务的冷启动时间通常在数百毫秒到数秒之间，每个实例至少需要 1 GB 内存，并按分钟计费。

agentOS 的切入点是：如果 Agent 的 VM 基于 V8 isolates + WebAssembly 构建，而不是使用完整的 Linux 环境，那么这个 VM 就可以直接嵌入你的进程中——冷启动只需几毫秒，内存占用只有几十 MB，成本还能降低两个数量级。

4,265 个 Stars。采用 Apache 2.0 许可证。由 Rivet Dev 维护。

• agentOS 的 VM 隔离模型：V8 isolates + WebAssembly，以及它与完整 sandbox 的核心区别
• 性能基准测试：与 E2B 和 Daytona 对比冷启动、内存及成本
• 核心功能：bindings、文件系统挂载、权限控制、通过 ACP 管理 session
• 内置 Agent 支持：Pi、Claude Code、Codex、OpenCode
• 哪些场景适合 agentOS，以及什么时候确实需要完整 sandbox

你需要具备：

• 基础的 Node.js/TypeScript 知识
• 对 AI Agent 的 tool-calling 有基本了解
• 如果知道 V8 或 WebAssembly 是什么会更有帮助，但不是必需条件

agentOS 是一个 npm package（@rivet-dev/agentos）。安装之后，你可以直接在 TypeScript/Node.js 代码中创建 VM 实例，在这些 VM 内运行 AI Agent，并让 Agent 通过 bindings 调用你的 JavaScript 函数——整个过程不需要经过网络跳转。

架构方面：每个 VM 都由一个可信的 sidecar 进程管理。该进程负责维护一个虚拟 kernel，包括虚拟文件系统、进程表、pipes、PTY 以及虚拟网络栈。Guest 发起的每一个 syscall 都会经由这个 sidecar 代理；Guest 的任何操作都不会触及真实 host。

Guest JavaScript 运行在原生 V8 上，支持完整 JIT；编译后的工具则以 WebAssembly 形式运行。多个 VM 共享同一个 sidecar 进程，因此每增加一个 VM，只需增加一个 V8 isolate 和相应的 kernel state，而不需要创建新的 OS process。

• 主要语言：Rust（核心 runtime）+ TypeScript（SDK）
• 网站：agentos-sdk.dev
• ⭐ GitHub Stars：4,265+
• 📄 许可证：Apache-2.0
• 📅 创建时间：2024-02-07

npm install @rivet-dev/agentos @agentos-software/pi

创建服务端（server.ts）：

import { agentOS, setup } from "@rivet-dev/agentos";
import pi from "@agentos-software/pi";

const vm = agentOS({
  software: [pi],
});

export const registry = setup({ use: { vm } });
registry.start();

创建客户端（client.ts）：

import { createClient } from "@rivet-dev/agentos/client";
import type { registry } from "./server";

const client = createClient<typeof registry>({
  endpoint: "http://localhost:6420",
});
const handle = client.vm.getOrCreate("my-agent");

// Subscribe to streaming events
const conn = handle.connect();
conn.on("sessionEvent", (event) => console.log(event));

// Open a session and send a prompt
await handle.openSession({
  agent: "pi",
  env: { ANTHROPIC_API_KEY: process.env.ANTHROPIC_API_KEY! },
});
await handle.prompt({
  content: [{ type: "text", text: "Write a hello world script to /workspace/hello.js" }],
});

// Read the file the agent created
const content = await handle.readFile("/workspace/hello.js");
console.log(new TextDecoder().decode(content));

# Terminal 1: start the server
npx tsx server.ts

# Terminal 2: run the client
npx tsx client.ts

直接在 VM 内执行 Node.js 和 shell：

await handle.writeFile("/hello.mjs", 'import fs from "fs"; fs.writeFileSync("/out.txt", "hi")');
await handle.exec("node /hello.mjs");

const result = await handle.exec("cat /out.txt");
console.log(result.stdout); // "hi"

性能基准测试

以下 benchmark 数据测量于 2026 年 3 月 30 日。

agentOS 的数据在 Intel i7-12700KF 上测得。截至 2026 年 3 月 30 日，E2B 是主流 sandbox 中速度最快的方案。

每执行一秒的成本（自托管、完整编程 Agent）

Daytona 基准价格：$0.0504/vCPU-h + $0.0162/GiB-h，最低配置为 1 vCPU + 1 GiB。

为什么差距会这么大：Sandbox 服务的最低实例配置是 1 vCPU + 1 GiB——即便只运行一条 ls 命令，也必须为整个实例付费。agentOS VM 的最低开销只是一个 V8 isolate 加上 kernel state。一条简单的 shell 命令只占用 22 MB。

这种差距来自隔离层选择上的结构性差异，而不是某种性能优化。

Bindings：让 Agent 直接调用你的函数

这是 agentOS 与传统 sandbox 之间最根本的架构差异。

在传统 sandbox 中，Agent 若要访问你的数据或调用你的业务逻辑，必须经过网络 API：sandbox → HTTP → 你的后端。凭证需要被传入 sandbox，不仅增加延迟，还会扩大攻击面。

const vm = agentOS({
  software: [pi],
  bindings: {
    // This function is exposed to agents inside the VM as a CLI command
    get_user_data: async (userId: string) => {
      return await db.users.findById(userId); // Direct database access on the host
    },
  },
});

当 VM 内的 Agent 执行 get_user_data 123 时，它看起来就像在执行一条普通的 shell 命令，但实际上调用的是你在 host 上定义的 TypeScript 函数。凭证和数据库连接始终不会进入 VM。

可以在启动时挂载，也可以在 runtime 中动态挂载：

const vm = agentOS({
  software: [pi],
  mounts: [
    { type: "s3", bucket: "my-bucket", mountpoint: "/data" },
    { type: "host", path: "./local-dir", mountpoint: "/workspace" },
    { type: "memory", mountpoint: "/tmp" },
    { type: "gdrive", mountpoint: "/drive" },  // Google Drive (after OAuth)
  ],
});

默认禁止网络出站访问，可根据需要开放：

const vm = agentOS({
  software: [pi],
  permissions: {
    network: {
      outbound: [
        { host: "api.github.com", allow: true },
        { host: "*", allow: false }, // deny everything else
      ],
    },
    filesystem: {
      read: ["/workspace", "/data"],
      write: ["/workspace"],
    },
  },
});

agentOS 通过 ACP（Agent Client Protocol）管理 Agent session：

• Session 自动持久化，不需要编写额外代码
• 被中断的 session 可以恢复
• 所有 Agent 使用统一的 transcript 格式，方便调试和比较

// Schedule agent tasks
registry.cron("0 9 * * *", async () => {
  const handle = client.vm.getOrCreate("daily-report");
  await handle.openSession({ agent: "pi" });
  await handle.prompt({ content: [{ type: "text", text: "Generate today's report" }] });
});

// External webhook triggers
registry.webhook("/github-events", async (req) => {
  // handle GitHub webhook, delegate to agent
});

多个客户端可以实时观察同一个 Agent，并与它协作：

const conn1 = handleA.connect(); // read-only observer
const conn2 = handleB.connect(); // can also send prompts

Agent-to-Agent 委派

const vm = agentOS({
  software: [pi, claudeCode],
  bindings: {
    // Pi can call this binding to spin up a Claude Code agent for a subtask
    run_code_review: async (prUrl: string) => {
      const reviewHandle = client.vm.getOrCreate(`review-${prUrl}`);
      await reviewHandle.openSession({ agent: "claude-code" });
      await reviewHandle.prompt({
        content: [{ type: "text", text: `Review PR: ${prUrl}` }],
      });
      return await reviewHandle.getResult();
    },
  },
});

内置 Agent Registry

Agent 和工具均以 npm package 的形式分发。

CLI 工具同样以 npm package 形式提供，包括：git、ripgrep、jq、sqlite3、duckdb、curl、vim，以及 common、build-essential、everything 等 meta-package。

常见的 POSIX 工具，包括 coreutils、sed、grep、gawk、findutils、diffutils、tar、gzip，均默认内置。

agentOS 与完整 Sandbox：应该如何选择

agentOS 自己的文档明确指出：二者是互补关系，而不是竞争关系。

以下场景适合选择 agentOS：

• Agent 需要调用后端的数据库或函数，可以使用直接 bindings，无须经过网络跳转
• Agent 任务并发量高或执行频率高，较低的内存占用意味着每台 host 可以运行更多实例
• 冷启动延迟非常重要，例如面向用户的实时工作流
• 需要自托管，不想承担 sandbox 厂商的计费

以下场景应选择完整 sandbox：

• 需要执行原生编译，例如使用 C/C++/Rust toolchain
• 需要启动完整的开发服务器，例如在内部运行 Node/Python HTTP server
• 需要真实浏览器，而不只是 headless API
• 工作负载本身已经很重，并且可以接受 sandbox 成本

也可以把二者结合使用，通过 sandbox mounting 实现：

const vm = agentOS({
  software: [pi],
  // Spin up a full sandbox on demand, mount its filesystem
  sandbox: { provider: "e2b", mountpoint: "/sandbox" },
});

默认使用轻量级的 agentOS VM；只有当工作负载确实需要真正的 Linux 时，再挂载完整 sandbox。

• 🌟 GitHub：rivet-dev/agentos
• 🌐 网站：agentos-sdk.dev
• 📖 Quickstart：agentos-sdk.dev/docs/quickstart
• 📦 Registry：agentos-sdk.dev/registry
• 📊 Benchmarks：agentos-sdk.dev/docs/benchmarks
• 🏗️ Architecture：agentos-sdk.dev/docs/architecture
• 💬 Discord：rivet.dev/discord

agentOS 回答了一个非常具体的工程问题：“我想在自己的产品中运行 AI Agent，但不想接受 sandbox 的冷启动延迟、高昂的内存开销和按分钟计费模式。”

它给出的答案是：使用 V8 isolates + WebAssembly 实现一个够用的 VM，将其封装成 npm library，让开发者直接通过 npm install 把它安装到自己的后端中。

有三个设计决策值得记住：

Bindings 是最核心的洞见：不是“让 Agent 调用你的 HTTP API”，而是“让 Agent 调用你定义的 TypeScript 函数，并将这些函数作为 VM 内的 CLI 命令暴露出来”。凭证永远不会进入 VM，延迟接近于零，而 Agent 的能力边界完全由你掌控。

性能差距是结构性的，而不是优化出来的：完整 sandbox 的最低实例配置是 1 vCPU + 1 GiB——无论实际运行什么任务，你都要为这个最低配置付费。而 V8 isolate 的最低开销只有几十 MB。这种差距并非源自某种聪明的优化，而是选择不同隔离层之后的必然结果。

它是完整 sandbox 的补充，而不是替代品：sandbox mounting 功能表明，团队非常清楚 agentOS 的能力边界。当工作负载确实需要真正的 Linux 环境时，应将 sandbox 的文件系统挂载进 VM，而不是试图在 WebAssembly 中模拟一套完整 OS。

如果你正在构建一款需要 AI Agent 能力的产品，却又对 sandbox 服务的成本和延迟不满意，那么 npm install @rivet-dev/agentos 非常值得认真评估。

探索 PrimeSkills——一个精选的 AI Agent 与 skills 市场，其中每个 Agent 和 skill 都经过真实企业工作流验证。没有炒作，只提供真正有效的东西。

访问我的个人网站，获取更多洞见和有趣的产品。

如需采取进一步措施，你可以考虑屏蔽此人和/或举报滥用行为。