Agent Sandbox 不只是一个 exec：我为什么做了 Axern

如果把 Coding Agent 的执行环境压缩成一个接口，它看起来可能只有一行：

result = sandbox.exec(command)

Agent 生成命令，Sandbox 执行命令，再把 stdout、stderr 和退出码返回。对于 Demo，这个抽象简单而且有效。

但当任务从一次命令变成持续几十分钟甚至更久的软件工程过程，exec 很快就不再是问题的全部。Agent 需要反复修改文件、安装依赖、启动后台进程、暴露 HTTP 服务、保留工作区，并在客户端断开或节点异常后继续确定资源是否有效。任务结束后，系统还要知道哪些计算资源应该释放、哪些文件和执行证据需要保留。

这也是我过去几个月开发 Axern 开源 Sandbox 平台 时一直在处理的问题：Agent 写出的代码究竟应该在哪里运行，以及谁来管理这段执行过程的完整生命周期？

图 1：Axern 官网展示了项目定位、运行时选择和 SDK 入口。

官网地址：Axern 官网

Axern 不是一个新的 Agent 框架，而是一套用于运行 Agent 及其代码的开源基础设施。它也不是先有一个宏大的平台设想，再去寻找使用场景，而是在处理隔离、进程、文件、存储、网络和生命周期这些具体问题时逐渐长出来的。

1. 一个 exec 接口隐藏了哪些状态

最简单的代码执行服务通常可以抽象成：

输入代码 → 启动容器 → 获取输出 → 删除容器

真实的 Agent 工作负载更接近下面这条链路：

创建环境
  → 安装依赖
  → 写入和修改文件
  → 多次运行命令
  → 启动后台服务
  → 暴露 HTTP 或终端入口
  → 验证执行结果
  → 保存必要产物
  → 清理计算资源

图 2：一次 exec 结束，不代表任务生命周期结束。

这里至少存在几类不能只放在客户端内存中的状态：

• 身份与归属：这个环境属于哪个任务、用户或项目？
• 进程状态：前台命令结束后，后台服务是否仍然存活？
• 文件与存储：工作区是临时的，还是需要跨多次执行保留？
• 网络入口：Agent 启动的服务如何被调用方访问？
• 租约与清理：客户端退出后，资源应该继续存在多久？
• 执行证据：任务做过什么、验证过什么、产生了哪些结果？

如果这些状态全部由调用方临时拼接，一旦客户端断开、服务重启或节点失联，系统就很难判断哪些任务仍然有效、哪些资源应该回收，以及哪些文件和产物应该继续保留。

因此我逐渐形成了一个判断：

Sandbox 更接近一种具有身份、状态和生命周期的资源，而不是一次性的容器进程或一个 exec 函数。

2. Agent 框架、执行 Runtime 和 Sandbox 不是同一层

围绕 Agent 执行环境已经出现了多种技术路径，但它们处理的问题层次并不完全相同。

• E2B Sandbox 将快速启动的隔离 Linux VM 和 Sandbox Template 作为主要抽象。
• Modal Sandboxes 在 Modal 云计算平台中提供用于执行不受信任用户或 Agent 代码的安全容器，并复用其镜像、Volume 和网络能力。
• Google AX 分布式 Agent Runtime 将自己定位为分布式 Harness Runtime，更关注隔离执行、状态管理、故障恢复和执行续跑。

如果团队需要即开即用的托管沙箱，E2B 或 Modal 可能是更直接的路径；如果重点是 Agent Harness 的分布式执行和恢复，Google AX 更接近那个问题。

Axern 当前选择的是另一组取舍：构建一套可以自托管的开源执行底座，让隔离沙箱、可信常驻服务、存储、网络和生命周期共享同一套资源模型。

真正值得比较的不是一张功能清单，而是几个系统边界：谁负责部署和运维、隔离发生在哪一层、任务生命周期由谁持有、数据怎样进入和离开环境，以及状态与证据如何保留。

3. Axern 的运行模型

Axern 是一个面向 AI Agent 的开源 Sandbox 平台。它使用 runsc 隔离不受信任的 Agent 生成代码，也可以通过 runc 运行受信任、需要长期存活的服务，并让两类工作负载共享同一套资源与生命周期模型。

图 3：runsc Sandbox 与 runc Service 共享公开资源和生命周期模型。

这里的关键不是把 runc 和 runsc 包装成同一种实现，而是让运行时差异位于统一资源模型之后。调用方仍然围绕环境、执行、文件、服务、存储和生命周期工作，再根据负载的信任边界选择运行时。

Axern 当前主要支持三类场景：

• Agent Sandbox：在 runsc 隔离边界内执行 Agent 生成的代码，同时保留进程、文件、终端和输出访问能力。
• 持久服务：用 runc 运行受信任、对性能更敏感的长期进程，由控制面负责副本、健康状态、存储和发布生命周期。
• 可复现的 Agent 执行：通过 Axrun 编排不可变任务、验证过程、轨迹、用量和类型化产物，为 Benchmark、评测与自动化任务保留证据。

开发者可以通过 CLI，或者使用 Go、Python、TypeScript SDK 管理这些资源。控制面、Gateway 和节点运行时共同处理身份、租约、清理与可观测性，上层 Agent Harness 不必重复实现这些职责。

4. 设计这套模型时的四个取舍

4.1 控制面持有持久意图

身份、放置、租约、重试、健康、清理和存储状态不会只存在于某个 CLI 进程的内存里。客户端可以退出，节点也可能重启，但平台仍然知道用户想要什么，以及当前执行到了哪里。

例如，用户声明某个服务应该存在两个副本时，"两个副本"是一种持久化意图，而不是某个客户端进程中的临时变量。节点异常、服务重启或网络短暂中断后，控制面仍然可以继续调和实际状态。

4.2 运行时选择位于公开模型之后

runc 和 runsc 具有不同的实现、隔离边界与性能特征，但它们不应该迫使开发者重新学习完全不同的资源 API。

在 Axern 中，runc 与 runsc 的选择位于统一资源模型之后。OCI 与 Nydus 属于镜像和文件系统路径，同样可以在节点运行时内部演进，而不改变公开资源的生命周期。

4.3 进程、文件和网络访问是一等能力

真正参与软件开发和运维工作的 Agent，不会只执行一条命令。

它通常还需要启动和终止多个进程，实时读取 stdout 与 stderr，上传、下载和修改文件，读取目录归档，建立交互式终端，启动 HTTP 服务，通过反向 TCP Tunnel 连接调用方本地服务，以及挂载临时或持久化存储。

Axern 将进程流、文件、归档、HTTP 服务、SSH 兼容终端和反向 TCP Tunnel 作为明确能力暴露，而不是让每个 Agent 产品在容器之外重新拼接访问路径。

4.4 本地与集群使用相同的服务边界

Agent 基础设施的一个常见问题是：本地测试运行一套简化逻辑，进入集群后却变成另一套系统。

Axern 尽量让本机 Docker Compose、kind 和云中立 Helm Chart 面向相同的公开合同。开发者可以先在自己的电脑上理解环境、运行、服务和访问模型，再决定是否进入 Kubernetes 场景。

5. 在本地运行第一个隔离任务

在 amd64 或 arm64 的 macOS/Linux 上准备 Docker Desktop，或者 Docker Engine 与 Compose v2，然后安装 Axern CLI：

brew install cofy-x/tap/axern

不使用 Homebrew 时，也可以使用带校验和的安装器：

curl -fsSL https://raw.githubusercontent.com/cofy-x/axern/main/install.sh | sh

启动本地 Axern，并运行第一个 Python 命令：

axern local up
axern run python:3.12-slim -- python -c 'print("hello from axern")'

图 4：Axern CLI 的命令入口与 Run 参数。

axern local up 会启动 PostgreSQL、MinIO、控制面和节点服务，等待它们就绪，并创建本地 CLI Context。第一次使用某个运行时或 Agent 镜像时，镜像会按需拉取。

运行记录可以继续查询：

axern context current
axern run list
axern local status

体验完成后可以关闭本地环境：

axern local down

更完整的系统要求和操作步骤见 Axern 中文快速开始。

6. 当前阶段与安全边界

Axern 目前由我独立开发和维护，采用 Apache License 2.0，仍处于 pre-1.0 和活跃开发阶段。它适合评估、实验和参与贡献，但默认本地环境不能直接作为承载不受信任多租户工作负载的生产部署。

本地栈只监听 loopback，并生成开发身份材料。真正的共享或生产部署还需要操作者逐项评审认证、TLS、网络策略、运行时隔离、镜像信任、Secret 存储、资源限制和持久化存储。

使用 runsc 并不会自动让整个系统变成安全的多租户平台；拥有持久控制面也不等于已经解决所有可靠性问题。这些边界不应该藏在宣传口号后面，也需要在真实使用中继续验证。

7. 写在最后

Axern 还处在很早期的阶段。我把它开源，并不是因为这些问题已经有了完整答案，而是希望隔离、状态、访问和清理这些设计取舍能够在真实任务中继续被检验。

如果你正在构建 Coding Agent、远程代码执行平台或自动化评测系统，可以尝试运行一个本地任务。无论是命令跑不起来、概念难以理解，还是资源模型不符合实际工作负载，都是值得继续解决的问题。

• 项目代码：Axern GitHub 仓库
• 项目官网：Axern 官网
• 使用文档：Axern 中文快速开始