当智能体不再编写 Shell：语言即沙箱

前言

2026 年 7 月 10 日，OthersideAI/HyperWrite 创始人 Matt Shumer 在 X 上称，他受邀测试 Codex 的 GPT‑5.6 Sol Ultra 模式时，系统意外删除了大量文件。

根据 OpenAI 后来的调查说明：

1. 智能体在任务中创建并清理临时工作目录。

2. 它错误地把 $HOME 这样的系统环境变量当成临时目录变量使用。

3. 清理命令路径因此指向真实用户目录，并执行了如下Shell脚本：

rm -rf /Users/mattsdevbox

这条路径实际是 Matt 的 Mac 用户主目录，里面可能包含项目、配置、文档等大量文件，Codex 随后承认自己造成了“严重的本地数据丢失事故”。这条帖子后来获得约 560 万浏览，引发大量讨论。

这个事件最重要的教训是：如果智能体处于 「完整访问权限」，提示词中的“不要误删”并不是可靠的安全边界。真正的保护应该是沙箱、审批、备份和最小权限。

智能体的问题，不只在模型

Matt Shumer 的遭遇并非个例，值得广泛关注，不夸张的说智能体在执行过程中面临「两宗罪」。

1、智能体普遍依赖 Shell 和临时 Python，权限边界粗、环境依赖多。

智能体会因为执行环境的问题反复向用户索取权限，导致用户为了能够让智能体正常运行，被迫要给予智能体过高的权限。

2、大量工具默认类 Unix 环境，Windows 体验容易失真或失败。

在 Windows 环境下，Codex 在执行 powershell 的过程中经常写出错误 quoting 导致命令执行失败的情况。

语言即沙箱

1、SeekMoon 介绍

SeekMoon 是一个值得期待的选择，它是一个智能体编程环境，包含智能体 CLI、图形化界面和 ADE（Agent Development Environment）。它最大的特色是整套技术栈建立在一个为智能体设计的语言 MoonBit 之上：「语言即沙箱」，MoonBit 构建的所有软件都运行在自己单独的沙箱之中，可以和宿主环境无缝交互，在保障安全隔离的同时不影响用户体验。

SeekMoon 用户界面

我们现在来看一下 SeekMoon 是如何解决上文提到的两大问题。

2、细粒度的沙箱

对于智能体，安全与易用性似乎天然存在冲突。主流智能体使用的 Shell + 系统级沙箱通常只能进行「粗粒度的沙箱审批」，也就是说，当一条任意 Shell 命令越过既有边界后，系统经常只能对整条命令或整棵进程树作出完全通过/完全拒绝的两种判断。

当大量正常操作反复触发整条命令的审批时，用户面对的选择会逐渐变成：不断确认类似的请求，或者扩大权限边界（例如启用 「完整访问权限」）以恢复流畅体验。从上文提到的 Codex 的案例中，我们也可以看到，很多开发者会选择开放 「完整访问权限」 ，绕过权限审批步骤，最终结果导致数据的意外丢失。

为了解决权限管理的问题，SeekMoon 提供了另一种思路：让智能体生成 MoonBit 程序，并将程序及其依赖编译成一个 WebAssembly（WASM） 模块，再通过受细粒度的 policy 约束的运行时中执行。文件访问、网络连接、环境变量读取都通过 API 的方式提供给 MoonBit 程序。对于经由这些 API 发起的外部操作，运行时识别具体的能力（capability) 请求，并在调用边界应用 policy，而不是把一整组权限授予整个 shell 进程。

也就是说，SeekMoon 能够显式指定智能体「能干什么」，而不是禁止「不能干什么」。这种构建沙箱的方式天然地更加安全，也能够让 SeekMoon 直接控制智能体的行为。在 SeekMoon 中，智能体只能通过调用 edit / multi_edit 工具落盘 MoonBit 代码。这两个工具会对模型生成的代码进行检查并将语法错误回报给模型，模型修正以后，才会将语法正确的代码写回到磁盘上。细粒度的沙箱避免了其他Shell工具非法篡改MoonBit代码。

值得一提的是，在MoonBit代码中直接调用所有 MoonBit生态的二进制可执行程序，也会进入同一条执行链路。通过这种方式启动的工具会直接运行在沙箱里面，并自动继承当前程序的 policy 约束。这样，Mooncakes.io 上面的生态工具可以直接作为沙箱工具运行，而且在结构上就被 capability 约束，不需要再进行逐个审批，这极大地提升了用户体验。

例如，mooncakes.io 上面的 bobzhang/office 是一个用来读取/操作 office 文档的 CLI 工具，这个工具在被智能体调用的时候会继承智能体的 policy。只要这个 CLI 没有访问 policy 以外的资源，就不会触发审批。

对于像 Git、npm 等外部程序（MoonBit生态暂未覆盖的工具），目前 MoonBit 仍以原生操作系统进程运行。对于这样的外部工具调用，SeekMoon 提供结构化的 Cmd API。Shell 中的 git status 对应到 MoonBit 里面可以写为 Cmd("git", ["status"])。当 MoonBit 程序通过 Cmd API 调用外部工具时，运行时能够在运行时边界上截获调用。Policy 中的 spawn 部分可以直接匹配 git status ... 等命令前缀，并限制传入的环境变量。进程启动后，Git 按照操作系统的原生进程模型执行，该进程和其内部启动的 SSH、hook 或 credential helper 可以最终跑在系统级的沙箱里。

或许有人会问，为什么不直接用传统的 OS 级别沙箱，如 Linux 上面的 bubblewrap 或者 macOS 上面的 Seatbelt 技术，而要专门打造一个 编程语言级别的沙箱呢？下面的对比可以清晰给出答案：SeekMoon 是所有沙箱方案中最轻量的，也是最贴近用户意图的；也规避了一些传统OS级别沙箱的劣势，例如使用起来配置复杂，启动速度慢，消耗资源多。

对于原生工具，MoonBit 可以在截获的 spawn 边界启动独立的 exec-sandbox，由宿主沙箱约束文件访问、网络连接和后代进程。长期目标是让更多工具由 MoonBit 实现并以 WASM 形式分发：每个工具成为统一运行时中的虚拟进程，拥有独立状态与 capability；多个虚拟进程在同一个宿主进程中运行，权限沿虚拟进程树继承。原生工具由宿主沙箱承接，WASM 工具逐步进入一体化的执行与权限模型。

总的来说 SeekMoon 通过一个合适的预设的 policy 和丰富的 MoonBit 生态，实现了在不牺牲智能体易用性的基础上保证安全。

3、副产品：跨平台，更好的 Windows 体验，更小的分发体积

当下，很多智能体「天然」忽视的了Windows 端的用户体验，工具分发体积异常大，而 MoonBit 通过 为WASM后端的特殊优化，实现了 office 工具大小仅 3.4 M ，而且支持跨平台。

而且 MoonBit 运行时在 MacOS、Linux 和 Windows 分别实现了同一组 capability，这意味着同一份 MoonBit 工具源码无需针对平台改写，就能够在三个平台上运行。这样一来，MoonBit 程序就可以覆盖大量原本需要使用 shell 来完成的工作。像是 grep / sed / jq / curl / zip 这些开发过程中常用的工具，可以使用 MoonBit 语言内置的文本搜索、JSON 处理、网络访问来替代；对于压缩、解压等需求，也可以使用的 MoonBit 库来处理。mooncakes.io 上也已经出现 MoonBit 实现的 coreutils 来为智能体提供一个统一的执行环境。而且，因为这组 coreutils 都运行在 MoonBit 运行时上，有相当一部分调用底层系统接口的代码可以共享。因此，coreutils 中单个 WASM 程序优化后体积通常约为 115–225 KiB，其中 xxd 为 176 KiB、printf 为 143 KiB。虽然 Rust uutils 提供了更加丰富的功能，但是单独的 Rust 工具编译以后约为 0.8–2.7 MiB，体积更大。

语言级沙箱这条链路对语言的要求极苛刻——编译要快、沙箱要原生、跨平台要在语言层收敛、还得适合写胶水脚本。为什么 MoonBit 是合适的选择？

为什么是 MoonBit

相信上文中有人会有困惑，为什么 MoonBit 与 SeekMoon 会紧密绑定，又为什么 MoonBit 拥有独特的语言级沙箱优势，接下来逐一解答这些疑惑。

重要的是想实现“语言即沙箱”有四个硬性要求：

• 编译必须足够快：沙箱的执行单元是现场编译的完整程序，编译处在智能体任务的关键路径上，只有百毫秒量级才能进入实时循环；也只有足够快，上文中的"最小动作也走编译"的统一模型才成立。Rust 的编译速度无法满足。

• 工具必须直接进入执行链路：WASM 已经可以承载 CPython、QuickJS 等语言运行时以及大量现有软件。但实际表现不尽如人意，性能很慢，这是因为 Python 和 QuickJs 使用了两层抽象。

  对于智能体现场生成的工具，MoonBit 把链路进一步缩短：源码本身经过静态检查并直接编译成 WASM，无需再交给另一层语言解释器执行。一次编译同时给出结构化诊断和可执行产物，最小动作也能够沿用同一套生成、修正与复用流程。可以看出只有语言沙箱原生才能带来更好的用户体验。

• 跨平台在语言运行时层收敛：同步与异步 IO 的语义在语言层统一定义，平台差异下沉到虚拟机的 capability 实现，同一份源码无需条件编译。

• 必须是高层“胶水”语言，同时有很好的可靠性保证：MoonBit 支持脚本模式（mbtx）和项目模式。智能体日常生成的是工具型脚本——解析 JSON、扫描处理文本、调用外部工具。MoonBit 原生支持 JSON，并把类 awk 的文本扫描与处理能力集成进语言本身（lexscan），表达密度接近 Python，而非 Rust 式的系统编程负担；Go 面向服务端工程，缺少模式匹配等结构化表达、错误处理冗长，同样不适合脚本密度。

  这里是一个 MoonBit 如何对 JSON 进行方便处理的例子。大模型会返回像下面这样的工具调用：

{  "id": "call_123",  "function": {    "name": "get_weather",    "arguments": "{\"location\":\"Hangzhou\"}"  }}

MoonBit 可以很方便地进行 JSON 的数据处理，使用强大的模式匹配从 JSON 里面提取数据：

match json {  {    "id": String(id),    "function": {      "name": String(name),      "arguments": String(arguments),      ..    },    ..  } => ToolCall(id~, name~, arguments~)  _ => raise InvalidToolCall(json)}

• 生态已经完成冷启动：MoonBit 既没有旧语言的包袱，又因为是 AI 原生快速抹平了与其他语言的差距。 目前已超过 20000 个包，智能体工具脚本所需的文件、文本、网络、编解码等能力已有覆盖。特别值得一提的是新语言的语料劣势，被"强类型 + 百毫秒编译反馈"的纠错循环抵消——错误以结构化编译信息在百毫秒内返回，模型自我修复成本极低；实测 deepseek-v4-flash 已能正确生成并使用 MoonBit。随着大模型语料学习滞后性问题逐渐的改善，未来将会有更好的表现。

这四项共同把问题收窄到智能体现场生成工具这一具体场景。MoonBit 同时提供快速编译、直接的 WASM 产物、跨平台 API 和高层表达能力，使生成、检查、分发与运行落在同一条工具链上。

一个端到端的例子

下面是一个端到端的真实例子：让智能体现场用 SeekMoon 写两个示例软件：用于处理 docx 和 xlsx 格式文件的小工具，即 Word 和 Excel 最简化版本。

下达任务的文本大致是：「用 proton（一个 MoonBit 的桌面端应用框架）、docx2html 库、mbtexcel 库构建两个应用：Office Word 和 Offcie Excel。需要支持常见的快捷键。」

通常，智能体面对这种类型的任务，只能现场安装 python-docx, openpyxl 或者调用本机的 Office 组件：依赖链长、跨平台通常不可用，在 Windows 上还要面对最脆弱的组件环境。

SeekMoon 使用 proton 这个桌面端应用框架的方式，和使用其它 MoonBit 软件一样：通过 moonx moonbit-community/proton_cli，这个 CLI 工具是通过 WASM 分发的，不必担心应用的开发和构建过程总会意外修改机器上的其它文件或做其他危险的事情。

任务的实际节拍是这样：SeekMoon 收到任务后，新建一个前后端一体化的 MoonBit 桌面端应用，应用中直接引入社区可用的 docx2html、mbtexcel 等基本库。不需要 Python 环境、不需要安装 Office，所有的依赖都是 MoonBit 生态的库。整个开发过程——代码生成、编译、修正、运行、打包——全都发生在 SeekMoon 所使用的 MoonBit 工具链内部。

在这个完整的应用示例中，SeekMoon 最终交付了两个可以在 MacOS 系统上正常运行应用。在 Office Word 应用中，用户可以编辑文稿，使用常用的快捷键，支持粗体、斜体；在 Office Excel 应用中，用户可以正常使用 Excel 的公式，公式单元格会根据依赖的单元格内容实时更新。

案例代码仓库链接：https://github.com/Milky2018/proton-gallery

不止于桌面端，与云端 Agent 融为一体

智能体的下一步，不只是写出更多代码，而是让生成代码的执行边界更清楚，让人理解代码的成本更低。为了更接近这一目标，在 SeekMoon 的官网上展示了未来发展的路线：

云端智能体：是当下智能体框架的一个重要组成部分，也是业界对于「如何让生成代码的执行边界更清楚」做的一些尝试。虽然相当多的开发者使用桌面应用程序或者 CLI 来运行智能体，但是这种运行方式有着许多限制，例如系统休眠会导致智能体中断，智能体运行导致别的开发任务受影响。

云端智能体不仅能够做到独立运行、不受别的任务的工况影响，也允许开发者可以在多种设备上异步地查看任务进度，通过 prompt 调整智能体行为等。E2B，Firecrack VM 等系统级沙箱经常被用来实现像这样的云端智能体。在 MoonBit 语言级沙箱的加持下，SeekMoon 可以把云端智能体的启动成本降到非常低。

在提升人如何低成本地理解代码上面，市面上现有的 AI 工具例如 Devin 也尝试如何提供一个更好的代码审查的工作流程。SeekMoon 在探索如何进一步将大模型的智能，静态代码分析和 diff 算法结合起来，改进代码架构的可视化，帮助人来更好地理解代码。

• SeekMoon 试用安装方式：https://openseek-api.moonbitlang.cn

• SeekMoon GItHub开源地址：https://github.com/moonbitlang/openseek

• Matt Shumer 在 X指责 codex ：https://x.com/mattshumer_/status/2075657271401390161

• CodeAct：ICML 2024 论文页面（PMLR）：https://proceedings.mlr.press/v235/wang24h.html

• Hugging Face smolagents 官方文档：https://huggingface.co/docs/smolagents/en/index

• 案例代码仓库链接：https://github.com/Milky2018/proton-gallery