继两周前 v0.3.0 发布了快照、克隆、回滚“三件套”后，本周 v0.4.0 正式上线。这一版的更新清单看起来庞杂，但如果只用一句话概括，就是：

Cube 正在从一个"高性能隔离运行时"，长成一个"可治理的 Agent 基础设施"

隔离做到了极致之后，下一个问题不仅仅是"怎么把 Agent 关起来"，而是演变成：

本次 v0.4.0 核心解决的就是这三个问题。

Cube 的网络模型从第一个版本起即支持 AllowOut / DenyOut 的 IP/CIDR 过滤，可以按 IP粒度对沙箱出站流量做精细控制，但真实业务场景的出站访问往往以域名的方式，通过DNS解析获得IP地址，配置策略时还不确定域名对应的IP地址，并且域名对应的IP随时可能发生变化，这套模型在原型阶段够用，但在生产环境下就开始捉襟见肘。

基于域名的过滤增强了出站流量管控，更贴合了真实Agent使用沙箱的方式，在Allowout中配置1个或多个域名，意味着放通该域名对应IP的流量，在Allowout中可以同时配置域名和IP/CIDR，域名不仅支持精确匹配，还支持后缀通配符方式，如"*.qq.com"即放通任何以".qq.com"为后缀的子域名，Denyout不支持域名，当Allowout中有至少1个域名时，Denyout必须包含"0.0.0.0/0"，以拒绝任何未放通域名的流量。

◆CubeEgress：沙箱第一次有了"L7 出境管控"◆

不管是Cube第一个版本起即支持的 AllowOut / DenyOut 的 IP/CIDR 过滤，还是上一节讲的域名过滤，都是以IP地址粒度对沙箱出站做精细控制，类似业内常见的做法，用 NetworkPolicy 做 L3/L4 隔离，但 Agent 的世界已经不在 L3/L4 这个抽象层了，Agent 调用的是 https://api.openai.com/v1/chat/completions，是 host + path + method 的组合。NetworkPolicy 看不到这一层。

CubeEgress 是一个全新的基于 OpenResty 的出站网关，通过 TPROXY 截获沙箱出站流量，在请求离开集群之前执行 L7 策略。它由运行在 OpenResty/nginx 上的 9 个 Lua 模块（约 2200 行代码）以及 Go 端的集成组成——CubeAPI （提供API配置沙箱出站策略）、CubeMaster（生成并烘焙CA 证书到模版）、 NetworkAgent（策略下发）和 CubeEgress（策略执行），在rules策略中配置的SNI和host会自动在allowout中放通域名，且该域名对应80/443的http/https流量将从CubeVS重定向到CubeEgress处理，

因此，CubeEgress 的设计就是把管控点放在 L7。

它的工作方式，是通过 TPROXY 透明按需截获沙箱的出站流量——沙箱内的代码无需任何感知，请求像往常一样发出去，但在离开集群之前必须先过它这一关。

策略匹配维度是五个：SNI、host、method、path、scheme。动作是四个：allow、deny、audit、inject，

同时也支持写lua脚本轻松扩展任何需要的功能

IP/CIDR/域名的过滤，都是针对目的IP粒度的过滤，CubeEgress支持SNI、host、method、path、scheme五元组的过滤，SNI、host都支持后缀通配符，path支持前缀通配符，每个元素也可以不配置，但SNI/host至少配置其一，以将流量引流到CubeEgress。

每个沙箱可以配置若干rule，每个rule可以配置五元组过滤，顺序匹配，每个规则可以allow或deny以实现精细的过滤策略。

CubeEgress处理沙箱发出的https流量时需要对流量解密，即CubeEgress支持自分发证书服务，沙箱进行https访问时接收到CubeEgress分发的证书，并与CubeEgress完成加解密处理后，CubeEgress再与原目的服务进行Https交互。

制作模板时Cube自动将CubeEgress的根证书烘焙到沙箱镜像中，以使沙箱证书验证成功，这一切都在cube内部闭环完成。

2.3 关于凭据注入：Agent 代码再也不必接触你的 API Key

传统做法里，沙箱里的 Agent 要调 OpenAI，OPENAI_API_KEY 通常以环境变量的形式注入沙箱。这意味着：Agent 的 Python 代码读得到、它 import 的任何第三方库读得到、它跑的 LLM 上下文里可能出现、它打的日志里可能落盘。任何一环失守，Key 就出去了。

Key 只存在于代理层，永远不进沙箱

你在 EgressRule.inject 里配置好"凡是发往 api.openai.com 的请求，自动追加 Authorization: Bearer ${KEY}"，沙箱内的 Agent 代码只管发裸请求或携带任意KEY，真实Key 都由CubeEgress代理在转发时附加到 Header。从代码到日志，Agent 自始至终接触不到原始 Key。在 CubeEgress 自己的安全审计日志里，凭据字段也会被替换为 

，避免审计日志反过来成为泄密通道。

2.4 关于审计：每一次出站，都留下可追溯的结构化记录

每个经过 CubeEgress 的请求，都会生成一条结构化 JSON 日志——去了哪个域名、用了什么方法、Header 里有什么、Body 里有什么。配合 redactor Lua 模块做请求体脱敏，你既能事后追溯 Agent 访问了什么，又不会把用户隐私写进日志。

◆容器日志转发：沙箱内的输出，第一次能被宿主机"看见"◆

之前的沙箱存在一个问题：容器进程 stdout/stderr 的输出留在沙箱内部，宿主机上看不到。调试要 cubecli exec 进去翻，生产环境的日志聚合根本无从下手。

这件事的难点在于：沙箱是硬件隔离的 MicroVM，不是普通容器，stdout/stderr 不能像 docker logs 那样直接读宿主机进程的 fd。你必须在沙箱内部捕获、跨虚拟机边界传输、宿主机侧落盘——而且不能借用业务网络，否则日志和应用流量混在一起，又快又乱。

◆节点组件版本矩阵：让"版本漂移"无处藏身◆

你升级了 CubeMaster，忘了某台节点的 Cubelet；你刷新了 guest-image，有两个节点 kernel 没跟上。这种不一致不会立刻爆炸，但会在某一天以一种你完全意想不到的方式出问题——某个沙箱在 A 节点能跑、在 B 节点起不来，排查到最后才发现是某个组件版本差了两个小版本。

Kubernetes 用了多年才在这件事上形成共识：

版本可见性是集群运维的零号问题

。v0.4.0 把这一层基础设施搭起来了，分为了三步：

4.1 第一步：编译期统一注入版本元数据

所有 Go 二进制通过 ldflags、所有 Rust 二进制通过 build.rs，在编译期注入 version / commit / build-time 三元组。一键部署脚本生成 release-manifest.json。cubecli version 和 cubemastercli version 的输出格式完全一致。

听起来简单，但做过多语言异构项目的人都知道——

让 Go/Rust 两套构建链产生格式一致、来源一致的版本信息，是一件需要刻意约束才能做到的事

。在此之前，"同一个组件，不同工具查出来版本不一样"是 Cube 也存在过的现实。

4.2 第二步：节点自动上报、CubeMaster 维护矩阵

Cubelet 在节点侧自动采集 guest-image、cube-agent、kernel 及控制面组件的版本，上报 CubeMaster。CubeMaster 在 node_component_version 表（迁移 0004）维护全集群版本矩阵，按组件分组报告同版本节点，

——哪台节点和大部队不一样，一眼就能看到。

CubeAPI 同时提供了汇总和详情接口，Web UI 新增 Versions.tsx 页面做可视化呈现。

4.3 第三步：模板和组件版本"对账"

这一步比前两步更进一步。Cube 引入了 template_versions 表（迁移 0006）来记录每个模板副本依赖的组件版本，并提供两个端点：

Web UI 配套引入了CompatBadge/CompatSection/CompatWarning/ CompatNodeCard/ VersionDeltaList 五个组件——过时的副本、版本差异、需要重建的横幅，全部可视化。还支持"版本绑定"，把模板

，避免节点升级后模板悄无声息地坏掉。

◆那些不在 Highlight 里、但同样重要的事◆

GetTapFile 这条沙箱启动关键路径被重写成三层策略：缓存命中走快速路径（0 系统调用）、池化 fd 已关闭走热路径（2 系统调用，跳过昂贵的 restoreTap）、无状态走完整恢复路径。fdserver 的 JSON 响应携带 ifindex，让 cubelet 直接跳过 netlink.LinkByName——

这是个常被忽略但成本极高的并发序列化点

。同时把 EnsureNetwork/ReleaseNetwork 之间的 TOCTOU 竞态，用 per-sandbox creating 守护通道替代了 singleflight。

5.2 模板构建：峰值磁盘从 4.2 倍降到 1.2 倍

模板镜像构建管线做了一次彻底重构——引入 skopeo + umoci 走

其中，Cube 在 5 个细节上做了磁盘优化：包括Docker export stdout 

，消除中间 rootfs.tar；ext4 空间估算用

（256 MiB 固定 + 数据 10% + 每文件 1 KiB），按 256 MiB 边界对齐等。

峰值磁盘使用从约 4.2 倍镜像大小降到约 1.2 倍

。文件级 SHA256 指纹还实现了跨构建去重。SDK 侧的 POST /templates 同步支持了 DNS、出口 CIDR、镜像仓库认证、command/args、网络类型和节点范围等更完整的选项。

在调度层面，实现了可配置超卖、自定义节点亲和性。同时，也修复了一系列核心 Bug

，例如：禁用互联网时不再自动放行 DNS（之前是 deny-all 策略下的隐蔽漏洞，影响安全语义一致性）、DNS 服务器 IP 自动加入 AllowOut（之前需要用户手动配置，新手必踩）等。

v0.4.0 把"出站治理"和"可观测性"两块拼图补上了，但我们还会继续在下一个版本里将这些功能推送给大家：

当前，Cube 已经走过了"造出一个高性能 MicroVM 沙箱"的阶段。从 v0.4.0 开始，它要回答的问题是：

当 AI Agent 真的大规模跑在生产环境里，沙箱该提供什么样的治理能力？

如果你正在构建 Agent 工作流、Agentic RL 训练平台或者面向开发者的代码执行服务，欢迎来 GitHub 拍砖、提 issue、发 PR。

 https://github.com/TencentCloud/CubeSandbox

https://github.com/TencentCloud/CubeSandbox/blob/master/docs/zh/changelog/v0.4.0.md

继两周前 v0.3.0 发布了快照、克隆、回滚“三件套”后，本周 v0.4.0 正式上线。这一版的更新清单看起来庞杂，但如果只用一句话概括，就是：Cube 正在从一个"高性能隔离运行时"，长成一个"可治理的 Agent 基础设施"。

Cube Sandbox v0.4.0 发布：从"隔离 Agent"到"治理 Agent"

AI Infra 开源项目

开发工具

云计算

架构设计

安全审计

Kubernetes

虚拟机

服务器

Python

容器

GitHub

Agent

CIDR

JSON

热销域名限时优惠，新客首年免费！


domain

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

Cube Sandbox v0.4.0 发布：从"隔离 Agent"到"治理 Agent"

Cube Sandbox v0.4.0 发布：从"隔离 Agent"到"治理 Agent"

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐