Microsandbox 本地微 VM 沙箱

要解决的问题

当 AI 代理开始替你写脚本、跑命令、调工具时，一个现实问题很快浮现：这些代码你无法预先审查。代理可能在调试中生成任意 shell 脚本，也可能调用外部工具产出临时文件，而默认执行环境就是你的本机。一旦代理被恶意提示词诱导，或它自己生成的代码带有副作用，损失就直接落在你的文件系统、凭据和网络上。

传统的容器隔离能挡住一部分风险，但启动开销大、镜像构建链路长，不适合高频、短生命周期的代理执行场景。这个技能给出的方案是把执行环境下沉到本地微虚拟机（microVM）：每个任务跑在一个轻量 VM 里，资源隔离更硬，生命周期跟着任务走，用完即弃。

技能如何工作

技能的核心是围绕 Microsandbox 封装出一套隔离执行工作流，关键能力包括：

• 微虚拟机沙箱：以 microVM 作为执行边界，把不可信代码和宿主机的文件系统、进程空间隔开。
• OCI 镜像兼容：可直接加载 Docker Hub、GHCR 或任意 OCI registry 上的标准镜像，例如通过 .image("python") 拉起一个 Python 运行环境，无需额外转换格式。
• 长驻会话支持：沙箱支持 detached 模式运行，适合需要持续在线的代理会话，不会因单次命令结束就销毁环境。
• 本地化执行：整个流程在你的机器上完成，不依赖远程托管沙箱服务，数据不出本机网络。

典型用法是把代理生成的代码交给沙箱解释执行，例如 msb run debian 起一个 Debian 环境后再进入交互，代理的读写都被限制在这个 VM 内部。

适用边界与注意点

• 不是免死金牌：microVM 隔离的是资源和文件系统，不代表代理生成的代码本身安全。业务逻辑层面的漏洞、对合法 API 的滥用仍需单独审查。
• 依赖本地 microVM 支持：宿主机需具备 microVM 运行能力，嵌套虚拟化受限的云主机等环境下可能无法工作。
• 镜像来源仍需自查：兼容任意 OCI registry 本身是供应链风险，建议锁定可信源和 digest。
• 技能是编排入口：真正的隔离能力来自 Microsandbox 上游项目，技能负责把这套能力接进代理代码执行流程。