microsoft/mxc

解决什么问题

应用一旦要执行自己没写的代码，宿主机就成了攻击面。模型生成的脚本、第三方插件、Agent 的工具调用都需要一个运行位置，而 Linux 上接 seccomp、macOS 上接 Seatbelt、Windows 上接作业对象或 Sandbox，等于维护三套安全模型、三种失败方式和三套排查方法。MXC 的做法是在这些平台原生隔离后端之前加一层统一的请求与策略模型：应用只声明容器类型、约束规则和要执行的命令，MXC 校验请求、选择后端并启动负载。

有什么不同

多数团队会直接用系统原语（Linux 上的 bubblewrap、nsjail，macOS 的 Seatbelt，Windows 的 Sandbox 或 AppContainer），再自己写各平台的胶水代码。MXC 的价值在于这层统一抽象：一份带版本号的 JSON 容器创建请求，包含文件系统、网络和 UI 策略，并支持持久容器的 provision、start、execute、stop、deprovision 生命周期。它在一个抽象下覆盖了从进程级容器到 MicroVM 的多种后端，并提供 Rust、.NET、Node 的类型化 SDK，而不是只有命令行接口。诊断也被当作一等能力：除 debug 输出外，还有记录被拒访问的 audit 模式，用来反推策略。

适合谁

适合要运行模型输出、插件或用户工具，并且跨多个操作系统发布、希望用一套策略 schema 代替各平台沙箱的应用工程师和平台工程师。只跑 Linux 容器的团队已经有 bubblewrap、nsjail 或 gVisor 类方案，未必需要这层抽象。想找 Docker 替代品或托管执行服务的人也不对口——MXC 是要嵌进应用里的库。

上手成本

它会把原生运行时编进你的应用，构建复杂度随之而来：Rust crate 会编译 SDK、引擎和所选后端，Node 与 .NET 包则自带原生资产。各后端的平台前置条件不同，README 中标注 Windows Sandbox、MicroVM、Hyperlight 为实验性。从源码构建要求 Rust 1.93 与 Node 24+。需要预留调策略的时间，README 明确提醒沙箱内的应用会先遇到访问被拒，直到规则调好为止；audit 模式会关闭全部安全防护，绝不能用来跑不可信代码。微软官方构建可发送可选遥测，默认关闭且需要多重同意，本地开源构建不会把遥测发往微软。许可证为 MIT。README 在使用方法和前置条件上写得比较完整，但没有性能数据、实验性后端的成熟度承诺，也没有与现有沙箱服务的横向对比。

点评

按 GitHub 年龄看 MXC 是全新项目，约 259 天；它的热度主要来自单次脉冲——2026 年 10 月的一篇 Hacker News 讨论，以及一个月内约 1,635 颗星、位列 Rust 月榜第九，而不是长期积累。接近 3,000 颗星和微软维护的多语言 SDK 是有分量的信号，但没有上过日榜意味着持续关注度尚未被验证。如果你的产品需要跨平台执行代码，这套统一策略模型确实省事，MIT 许可证也免去法务顾虑。但要有心理准备：你选择的是一个早期库，部分后端仍是实验性，真正集成需要实打实的工作量，不能视为已经定型的securi­ty边界。