引言“当 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 容器镜像然后直接从这个镜像启动整台机器。这个思路在云原生世界并不陌生——bootcBoot 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’MalleyGitHub:sallyomLobsterTrap 是她用于这个项目的账号职位Red Hat 首席软件工程师Principal Software EngineerEmerging TechnologiesOffice 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 Stars104 Forks11 语言Shell81.7%、Dockerfile18.3% LicenseMIT 预构建镜像quay.io/sallyom/tank-os:latest支持 amd64 / arm64 媒体报道TechCrunch2026-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 KeysPodman 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 公钥注入配置catconfig.jsonEOF { blueprint: { customizations: { user: [ { name: openclaw, groups: [wheel], key: ssh-ed25519 AAAA...你的公钥... } ] } } } EOF# 构建 QCOW2 磁盘镜像需要 rootful Podmansudopodmanrun\--rm\--privileged\--pullnewer\-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.qcow2SSH 登录并操作 OpenClaw# 以 openclaw 用户登录非 rootsshopenclawvm-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 OSOS 根文件系统以只读方式挂载Agent 进程或任何用户空间程序无法修改系统文件彻底消除配置漂移rootless Podman QuadletOpenClaw 运行在无 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裸机直接安装 OpenClawDocker docker-composeNVIDIA NemoClawOS 不可变性完整bootc 只读根文件系统无无宿主 OS 可变无容器权限rootless无守护进程无容器化需要 Docker daemonrootK3s Docker daemon事务性更新支持可原子回滚不支持不支持不支持凭证存储Podman secret store明文文件Docker secrets 或明文L7 代理注入企业舰队管理适合镜像统一分发困难一般适合更复杂部署复杂度低单镜像启动低中高K3s 集群安全策略精细度中OS 级隔离低低高多层策略引擎为什么选择 Tank-OS最简单的企业级 AI Agent 安全部署方案无需运维 K8s 或复杂策略引擎与 Red Hat/Fedora 生态无缝集成适合已有 RHEL/Fedora 基础设施的企业完全开源 MIT可作为定制化企业镜像的起点项目详细剖析核心技术一bootcBoot Containerbootc 是 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 而不是 DockerPodman 是 Red Hat 开发的无守护进程容器工具其核心安全优势在于无中央守护进程Docker 需要 root 权限运行的dockerd这是一个持续运行的特权进程Podman 直接 fork 容器进程无需守护进程rootless 模式普通用户可以运行完整的容器容器内 root 实际上是宿主上的普通用户用户命名空间隔离通过 subuid/subgid 实现容器内 UID 1000 映射为宿主上的 UID 101000Tank-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] DescriptionOpenClaw AI Agent Service Afternetwork-online.target [Container] Imageghcr.io/openclaw/openclaw:latest ContainerNameopenclaw UserNSkeep-id:uid1000,gid1000 Volume%h/.openclaw:/home/openclaw/.openclaw:z Secretopenclaw-api-key,typeenv,targetOPENCLAW_API_KEY [Service] Restartalways [Install] WantedBydefault.targetSystemd 读取这个文件后自动生成对应的.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_CONTAINERopenclaw-research openclaw doctor底层实现上每个额外实例有独立的容器名称openclaw-researchSystemd user service 单元数据目录~/.openclaw-research/端口映射Podman secret 命名空间与 NVIDIA NemoClaw 的技术对比发布 Tank-OS 后技术社区最常见的问题是“这和 NVIDIA 的 NemoClaw 参考架构有什么不同”技术维度Tank-OSNVIDIA NemoClaw核心技术Fedora bootc rootless PodmanDocker 嵌入式 K3s 集群OS 不可变性完整bootc 分区级无凭证隔离Podman secret storeL7 代理层注入key 不触碰 Agent 文件系统安全策略OS 级隔离seccomp Landlock 网络命名空间多层策略更新机制原子镜像替换可回滚标准容器更新适用场景企业舰队标准 IT 运维工具链研究环境、需要细粒度策略控制的场景部署复杂度低单镜像、标准 VM 工具高K3s 集群运维结论Tank-OS 更适合把 AI Agent 作为标准 IT 基础设施来管理的企业场景NemoClaw 更适合需要多层精细安全策略的专业研究或高安全要求环境。项目地址与资源官方资源GitHubhttps://github.com/LobsterTrap/tank-os预构建镜像quay.io/sallyom/tank-osamd64 / arm64构建文档docs/build.mdCLI 文档docs/cli.md模型提供商配置docs/model-providers.mdIssue TrackerGitHub Issues相关资源TechCrunch 报道Red Hat’s OpenClaw maintainer just made enterprise Claw deployments a lot saferJulie Bort2026-04-28Decrypt 报道OpenClaw Insider Builds the Enterprise Safety Layer No One Asked ForRed Hat 官方博客Building a hardened, image-based foundation for AI agentsSally O’Malley技术演示Simplifying Linux Appliance Deployment with bootc and OpenClawRed Hat 开发者文章Deploying agents with Red Hat AI: The curious case of OpenClawOpenClaw 主项目github.com/openclaw/openclawFedora bootc 文档docs.fedoraproject.org/en-US/bootc总结与展望核心要点回顾问题定义清晰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解决了一个真实的企业痛点。它提醒我们很多看似复杂的基础设施问题其实只需要把现有成熟工具正确组合起来。适用人群企业 IT 管理员需要在公司内部署 OpenClaw Agent 舰队有统一管理和安全合规要求DevOps/SRE 工程师对 bootc、不可变基础设施感兴趣寻找 AI Agent 部署的参考架构Red Hat/Fedora 用户希望将 AI Agent 无缝集成进现有 RHEL 基础设施AI 安全研究者研究 AI Agent 隔离、凭证管理和企业级安全加固方案开源贡献者希望在 AI Linux 基础设施交叉领域做出贡献学习建议建议先了解 bootc 的基本概念Fedora bootc 官方文档再阅读 Tank-OS 的bootc/Containerfile和docs/build.md跟着文档在本地 VM 中运行一个实例。整个过程不超过 2 小时但你会对OS 即容器这个范式有非常直观的感受。如果你已经在企业中使用 OpenClawTank-OS 几乎可以直接作为生产参考架构使用——Sally O’Malley 本人就是 OpenClaw 的企业场景维护者项目中的每个设计决策都来自真实的企业需求。访问我的个人网站探索更多实用知识和有趣产品