当前位置：首页 > news >正文

一天一个开源项目（第87篇）：Tank-OS —— Red Hat 工程师用一个周末，把 AI Agent 塞进了一个可启动的 Linux 镜像

news 2026/5/1 3:17:25

引言

“当 AI Agent 开始删除邮件、访问数据库、调用外部 API，你真的确定它不会越界吗？”

这是"一天一个开源项目"系列的第 87 篇文章。今天带你了解的项目是Tank-OS，一个将 OpenClaw AI Agent 直接烧进操作系统镜像的开源工具。

2026 年 4 月，TechCrunch 报道了这个项目——作者是 Red Hat 首席软件工程师 Sally O’Malley，她利用一个周末写出了 Tank-OS。这个项目回答了一个越来越紧迫的问题：当你需要在企业里部署一个 AI Agent 舰队时，怎样才能让每台机器上的 Agent 既隔离、又安全、还能统一更新？

Tank-OS 的答案是：把 Agent、运行时、OS、Systemd 单元和升级机制，全部打包进一个 OCI 容器镜像，然后直接从这个镜像启动整台机器。

这个思路在云原生世界并不陌生——bootc（Boot Container）技术本就是为此而生。但把它用来解决 AI Agent 的企业部署安全问题，Tank-OS 是目前最具体、最完整的开源参考实现。

你将学到什么

bootc 是什么：为什么说"OS 即容器"是下一代 Linux 部署的核心范式
rootless Podman Quadlet 原理：无 root 权限运行容器，比 Docker 更安全的理由
Tank-OS 的分层架构：不可变 OS 层与可变状态层如何分离
事务性系统更新：一条命令回滚整台机器的 OS 状态
与 NVIDIA NemoClaw 的对比：两种企业 AI Agent 安全方案的本质差异
实际部署流程：从构建镜像到 QCOW2 虚拟磁盘，再到 SSH 登录 Agent

前置知识

了解 Linux 容器基础概念（镜像、容器、OCI 规范）
熟悉 Podman 或 Docker 的基本操作
对 Systemd 服务管理有基本认知
了解 OpenClaw 是什么（AI Agent 框架，GitHub 40,000+ Stars）

项目背景

项目简介

Tank-OS 解决的核心问题可以用一句话概括：AI Agent 足够强大，强大到危险，而大多数部署方案没有认真对待这个危险。

Sally O’Malley 在项目文档中描述的真实场景：OpenClaw Agent 在生产环境中曾经删除过邮件、意外修改过用户数据。当一个企业需要部署数十台、数百台运行 Agent 的机器时，传统的"直接 apt install + 配置文件"方案存在几个根本性问题：

凭证安全：API Key 存在配置文件里，容易被其他进程读取或意外泄露
更新一致性：每台机器的 OS 版本、依赖库版本可能不同，导致 Agent 行为不一致
故障隔离：Agent 进程崩溃或被攻击时，可能影响宿主 OS
批量管理：没有统一的方式将更新推送到整个舰队

Tank-OS 用 bootc + rootless Podman Quadlet 技术栈，系统性地解决了这四个问题。

作者介绍

Sally Ann O’Malley（GitHub:sallyom，LobsterTrap 是她用于这个项目的账号）

职位：Red Hat 首席软件工程师（Principal Software Engineer），Emerging Technologies，Office of the CTO
角色：OpenClaw 核心维护者之一，与 OpenClaw 创始人 Peter Steinberger 合作，聚焦企业级用例和 Red Hat Linux 生态集成
背景：长期从事 Red Hat 容器技术和 Linux 基础设施工作，是 Podman、bootc 等 Red Hat 开源项目的深度用户和贡献者
项目来源：Tank-OS 诞生于一个周末，起因是 O’Malley 预判到 “OpenClaw 进入企业后会发生什么”，并希望提前准备好参考架构

Red Hat 官方博客也发表了配套文章《Building a hardened, image-based foundation for AI agents》，标志着这不只是个人项目，而是 Red Hat 在 AI Agent 基础设施方向的正式探索。

项目数据

⭐ GitHub Stars：104
🍴 Forks：11
🔤 语言：Shell（81.7%）、Dockerfile（18.3%）
📄 License：MIT
📦 预构建镜像：quay.io/sallyom/tank-os:latest（支持 amd64 / arm64）
📰 媒体报道：TechCrunch（2026-04-28）、Decrypt、Yahoo Tech
🗓️ 发布时间：2026 年 4 月

主要功能

核心作用

Tank-OS 做的事情，本质上是把"如何安全运行 AI Agent"这个问题，从软件配置层面提升到了操作系统架构层面。

传统部署：

宿主 OS（可变） └── 用户空间（可变） └── OpenClaw 进程（可访问宿主文件系统） └── API Keys（明文配置文件）

Tank-OS 部署：

bootc 镜像（不可变 OS 层，只读） └── openclaw 用户（无 root 权限） └── rootless Podman Quadlet（容器，无守护进程） └── OpenClaw 进程（隔离于宿主） └── API Keys（Podman secret store，加密存储） └── ~/.openclaw/（可变状态层，持久化但与 OS 隔离）

使用场景

企业 AI Agent 舰队管理
- 数十台、数百台机器运行相同版本的 OpenClaw，通过统一的镜像更新机制保持一致性，避免"配置漂移"导致的行为差异
本地开发与生产环境对齐
- 开发者在本地 VM 中运行与生产完全相同的 Tank-OS 镜像，消除"在我机器上好好的"问题
只读 OS 安全加固
- Agent 进程即使被攻击或出现 bug，也无法修改宿主 OS 文件，因为 OS 层是不可变的
云实例和边缘设备部署
- 通过 cloud-init 注入 SSH 密钥，快速在 AWS EC2、GCP VM 或 Raspberry Pi 等设备上启动 Agent 实例
快速版本回滚
- 执行一条命令即可回滚到上一个 OS + Agent 版本，无需手动卸载和重装依赖

快速开始

方法一：直接使用预构建镜像（推荐）

无需本地编译，直接用 Podman Desktop 的 BootC 扩展或bootc-image-builder生成虚拟磁盘：

# 创建输出目录mkdir-pout-tank-os# （可选）准备 SSH 公钥注入配置cat>config.json<<'EOF' { "blueprint": { "customizations": { "user": [ { "name": "openclaw", "groups": ["wheel"], "key": "ssh-ed25519 AAAA...你的公钥..." } ] } } } EOF# 构建 QCOW2 磁盘镜像（需要 rootful Podman）sudopodmanrun\--rm\--privileged\--pull=newer\-v./config.json:/config.json\-v./out-tank-os:/output\-v/var/lib/containers/storage:/var/lib/containers/storage\quay.io/centos-bootc/bootc-image-builder:latest\--typeqcow2\--config/config.json\quay.io/sallyom/tank-os:latest# 结果：out-tank-os/qcow2/disk.qcow2

SSH 登录并操作 OpenClaw：

# 以 openclaw 用户登录（非 root）sshopenclaw@<vm-ip># 检查 Agent 状态openclaw gateway status--deep# 运行健康检查openclaw doctor# 获取 Dashboard 访问地址openclaw dashboard --no-open# 查看已连接设备openclaw devices list

更新 OS + Agent（事务性更新）：

# 首次更新：切换到最新镜像sudobootc switch--applyquay.io/sallyom/tank-os:latest# 后续更新：拉取新版本并重启应用sudobootc upgrade--apply

核心特性

不可变操作系统（Immutable OS）
- OS 根文件系统以只读方式挂载，Agent 进程或任何用户空间程序无法修改系统文件，彻底消除"配置漂移"
rootless Podman Quadlet
- OpenClaw 运行在无 root 权限的 Podman 容器中，由 Systemd Quadlet 单元管理生命周期；即使容器内进程被攻击，也无法提权到宿主 OS
事务性系统更新（Transactional Updates）
- 基于 bootc 的原子更新机制：更新要么完整成功，要么完整回滚，不存在"更新到一半机器坏了"的状态
安全的凭证管理
- API Keys 存储于 rootless Podman 的 secret store（加密），不以明文出现在配置文件或环境变量中；SSH 密钥通过 cloud-init 在首次启动时注入，不烘焙进镜像
多实例支持
- 单台机器可运行多个 OpenClaw 实例，每个实例使用独立的容器名、端口、数据目录和配置，互相隔离
多架构支持
- 预构建镜像同时支持linux/amd64和linux/arm64，覆盖 x86 服务器和 Apple Silicon/ARM 设备
Agent 友好的提示词嵌入
- 仓库中内置了一段面向 AI 编程助手的 prompt，帮助 AI 了解 tank-os 的安全约束，引导用户正确完成本地测试流程
cloud-init 原生集成
- 支持标准 cloud-init 配置，可直接用于 AWS、GCP、Azure 等云平台的实例初始化

项目优势

对比维度	Tank-OS	裸机直接安装 OpenClaw	Docker + docker-compose	NVIDIA NemoClaw
OS 不可变性	完整（bootc 只读根文件系统）	无	无（宿主 OS 可变）	无
容器权限	rootless（无守护进程）	无容器化	需要 Docker daemon（root）	K3s + Docker daemon
事务性更新	支持（可原子回滚）	不支持	不支持	不支持
凭证存储	Podman secret store	明文文件	Docker secrets 或明文	L7 代理注入
企业舰队管理	适合（镜像统一分发）	困难	一般	适合（更复杂）
部署复杂度	低（单镜像启动）	低	中	高（K3s 集群）
安全策略精细度	中（OS 级隔离）	低	低	高（多层策略引擎）

为什么选择 Tank-OS？

最简单的企业级 AI Agent 安全部署方案，无需运维 K8s 或复杂策略引擎
与 Red Hat/Fedora 生态无缝集成，适合已有 RHEL/Fedora 基础设施的企业
完全开源 MIT，可作为定制化企业镜像的起点

项目详细剖析

核心技术一：bootc（Boot Container）

bootc 是 Red Hat 主导的开源项目，它实现了一个听起来反直觉的想法：把整个操作系统当作一个 OCI 容器镜像来管理。

传统 Linux 系统的更新模型：

系统运行中 → apt upgrade / dnf update（逐个替换文件） → 部分成功 → 系统处于中间状态 → 回滚困难

bootc 的更新模型：

当前运行：镜像 v1.0（只读挂载） → bootc switch quay.io/sallyom/tank-os:v1.1 → 下载新镜像层，写入独立分区 → 重启 → 原子切换到 v1.1 → 出错 → bootc rollback → 回到 v1.0

这与手机 OTA 更新的 A/B 分区机制类似：更新写入备用分区，重启后切换，失败则自动保留原分区。

Tank-OS 的bootc/Containerfile基于quay.io/fedora/fedora-bootc:latest，这是 Fedora 官方维护的 bootc 基础镜像：

FROM quay.io/fedora/fedora-bootc:latest # 安装必要软件包 RUN dnf install -y \ podman \ openssh-server \ cloud-init \ python3 \ shadow-utils \ sudo \ vim # 创建 openclaw 用户（UID/GID 1000） # 配置 subuid/subgid 范围（100000-165535）用于 rootless Podman RUN useradd -m -u 1000 -g 1000 openclaw && \ usermod -aG wheel openclaw && \ echo "100000:65536" > /etc/subuid && \ echo "100000:65536" > /etc/subgid # 启用 cloud-init 服务族 RUN systemctl enable \ cloud-init-local.service \ cloud-init-network.service \ cloud-init.service \ cloud-config.service \ cloud-final.service \ sshd.service # 注入 tank-os 自定义脚本和 Quadlet 单元 COPY bootc/ /

核心技术二：rootless Podman Quadlet

为什么用 Podman 而不是 Docker？

Podman 是 Red Hat 开发的无守护进程容器工具，其核心安全优势在于：

无中央守护进程：Docker 需要 root 权限运行的dockerd，这是一个持续运行的特权进程；Podman 直接 fork 容器进程，无需守护进程
rootless 模式：普通用户可以运行完整的容器，容器内 root 实际上是宿主上的普通用户
用户命名空间隔离：通过 subuid/subgid 实现，容器内 UID 1000 映射为宿主上的 UID 101000

Tank-OS 中的 OpenClaw 容器以openclaw用户（UID 1000）运行，这意味着即使 OpenClaw 进程被恶意利用：

它无法访问宿主 OS 的系统文件（因为 OS 层是只读的）
它无法提权到 root（因为 rootless Podman 的命名空间隔离）
它无法影响其他用户的数据

Quadlet 是什么？

Quadlet 是 Podman 4.4+ 引入的特性，允许用 Systemd unit 文件的语法来声明容器的运行方式，由 Systemd 直接管理容器生命周期（启动、停止、重启、依赖关系）：

# /etc/containers/systemd/users/1000/openclaw.container [Unit] Description=OpenClaw AI Agent Service After=network-online.target [Container] Image=ghcr.io/openclaw/openclaw:latest ContainerName=openclaw UserNS=keep-id:uid=1000,gid=1000 Volume=%h/.openclaw:/home/openclaw/.openclaw:z Secret=openclaw-api-key,type=env,target=OPENCLAW_API_KEY [Service] Restart=always [Install] WantedBy=default.target

Systemd 读取这个文件后，自动生成对应的.service单元，负责拉取镜像、创建容器、管理重启策略。这使得 OpenClaw 成为了一个标准的 Systemd 服务，可以用systemctl --user status openclaw查看状态，用journalctl --user -u openclaw查看日志。

状态分层架构

Tank-OS 的设计原则之一是严格区分不可变层和可变层：

不可变层（OS 镜像，只读） ├── /usr/ ← 系统软件 ├── /etc/ ← 系统配置（镜像内烘焙） ├── /opt/tank-os/ ← tank-os 脚本和工具 └── Quadlet 单元 ← 容器声明文件 可变层（运行时状态，持久化） ├── ~/.openclaw/ ← OpenClaw 会话状态、插件、历史 ├── ~/.config/containers/ ← Podman 用户配置 └── Podman secret store ← 加密存储的 API Keys

当执行bootc upgrade时，只有不可变层被替换；可变层的 OpenClaw 状态和 API Keys 完整保留。这实现了"升级 Agent 版本但保留所有会话历史和配置"的效果。

凭证管理流程

API Keys 的注入流程是 Tank-OS 安全设计的另一个亮点：

1. 首次启动：cloud-init 执行 ↓ 2. 读取 user-data（来自 cloud provider metadata 或本地配置） ↓ 3. 执行 tank-os bootstrap 脚本 ↓ 4. 将 API Key 写入 rootless Podman secret store（加密） ↓ 5. Quadlet 单元启动 OpenClaw 容器 ↓ 6. 通过 Secret= 指令，将 secret 作为环境变量注入容器 ↓ 7. API Key 从未以明文出现在文件系统或进程环境中

与传统的.env文件方案相比，Podman secret store 使用系统密钥链加密存储，普通文件读取无法获取其内容。

多实例架构

Tank-OS 支持在单台机器上运行多个 OpenClaw 实例（例如，一个用于工作、一个用于研究），每个实例完全隔离：

# 默认实例：操作 openclaw 容器openclaw doctor# 指定实例：操作 openclaw-research 容器openclaw--containeropenclaw-research doctor# 通过环境变量切换默认实例exportOPENCLAW_CONTAINER=openclaw-research openclaw doctor

底层实现上，每个额外实例有独立的：

容器名称（openclaw-research）
Systemd user service 单元
数据目录（~/.openclaw-research/）
端口映射
Podman secret 命名空间

与 NVIDIA NemoClaw 的技术对比

发布 Tank-OS 后，技术社区最常见的问题是：“这和 NVIDIA 的 NemoClaw 参考架构有什么不同？”

技术维度	Tank-OS	NVIDIA NemoClaw
核心技术	Fedora bootc + rootless Podman	Docker + 嵌入式 K3s 集群
OS 不可变性	完整（bootc 分区级）	无
凭证隔离	Podman secret store	L7 代理层注入（key 不触碰 Agent 文件系统）
安全策略	OS 级隔离	seccomp + Landlock + 网络命名空间多层策略
更新机制	原子镜像替换（可回滚）	标准容器更新
适用场景	企业舰队（标准 IT 运维工具链）	研究环境、需要细粒度策略控制的场景
部署复杂度	低（单镜像、标准 VM 工具）	高（K3s 集群运维）

结论：Tank-OS 更适合"把 AI Agent 作为标准 IT 基础设施来管理"的企业场景，NemoClaw 更适合"需要多层精细安全策略"的专业研究或高安全要求环境。

项目地址与资源

官方资源

🌟GitHub：https://github.com/LobsterTrap/tank-os
📦预构建镜像：quay.io/sallyom/tank-os（amd64 / arm64）
📚构建文档：docs/build.md
📚CLI 文档：docs/cli.md
📚模型提供商配置：docs/model-providers.md
🐛Issue Tracker：GitHub Issues

总结与展望

核心要点回顾

问题定义清晰：Tank-OS 针对的是企业 AI Agent 部署中真实存在的安全问题——凭证泄露、配置漂移、更新一致性、故障隔离——而不是为了炫技而堆叠技术。
技术选型成熟：bootc + rootless Podman + Systemd Quadlet 全部是 Red Hat 生产级工具，有完整的企业支持和文档体系，不是实验性技术。
分层设计是精髓：不可变 OS 层与可变状态层的严格分离，是 Tank-OS 能够同时实现"安全隔离"和"状态持久化"的关键；这个设计原则值得在任何需要运行有状态 AI Agent 的场景中借鉴。
事务性更新改变运维范式：一条bootc upgrade命令更新整台机器的 OS + Agent，失败可原子回滚——这对于管理 AI Agent 舰队的 IT 团队来说，是质的飞跃。
周末项目的启示：Tank-OS 用约 500 行 Shell 脚本和 Dockerfile，解决了一个真实的企业痛点。它提醒我们：很多看似复杂的基础设施问题，其实只需要把现有成熟工具正确组合起来。