使用 MicroPython 和 WASM 在沙箱中运行 Python 代码

一句话看懂：开发者 Simon Willison 发布了一个实验性包 micropython-wasm，它通过将 MicroPython 编译为 WebAssembly 并在 wasmtime 引擎中执行，实现了在宿主 Python 应用内安全运行用户提交的 Python 代码。这一方案直接针对插件安全和任意代码执行场景，有望改变 Python 生态中“插件即全权限”的设计困境。

事件核心：发生了什么

Simon Willison（Datasette、LLM 等项目作者）正在推进一个代号为 micropython-wasm 的 alpha 包。其核心思路是：将精简版 Python 解释器 MicroPython（已通过最新 PR 获得 WASI 支持）编译成 WebAssembly 二进制，再借助 Python 库 wasmtime 来加载和运行这个 WASM 模块。宿主进程将待执行的 Python 代码字符串传入沙箱，沙箱内的 MicroPython 负责解释执行，返回结果，整个过程完全隔离于宿主文件系统和网络。目前该方案已封装为 datasette-agent-micropython 插件，供 Datasette Agent 使用。Willison 还通过 GPT-5.5 Pro 辅助研究，并用 Codex Desktop 和 GPT-5.5 high 编写了编译脚本，完整走通从“研究文档”到“可运行原型”的流程。当前最难的部分——保持解释器状态以支持变量跨调用驻留——仍处于探索阶段。

为什么重要

Python 生态中，插件系统（如 Pluggy）几乎都依赖宿主的 Python 解释器运行扩展代码，这意味着任何有 bug 或恶意的插件都能读取私有文件、连接网络甚至破坏核心应用。此前，Web 浏览器是唯一强制隔离动态代码的环境，但将 V8 等 JavaScript 引擎嵌入 Python 库困难重重且长期缺少维护。WebAssembly 作为为安全隔离而生的二进制格式，在 wasmtime 等运行时加持下，正在成为一种可行的“服务端沙箱”方案。如果 micropython-wasm 成熟，它将为 Datasette、LLM 等开源项目提供一套可无缝嵌入的、类似浏览器安全级别的代码执行环境。更重要的是，这套方案可能在更广的领域（如低代码平台、数据管道定时任务、用户自定义函数）替代当前依赖子进程或容器隔离的做法，显著提升开发效率和安全性。

对用户/开发者/创作者的影响

插件作者：过去写一个 Datasette 或 LLM 插件等同于获得宿主应用的完全权限，一旦代码质量不高可能导致应用崩溃或数据泄露。未来可以作为“受限插件”发布，仅获得沙箱内的运算能力，无法触及文件系统和网络，极大降低风险。
应用开发者：如果采用 micropython-wasm，可以安全地开放“数据变换”“定时脚本”“自定义逻辑注入”等场景，而不必担心用户提交的代码破坏系统。例如让用户写 Python 代码从预授权 URL 抓取 JSON 并转换后写入 SQLite 数据库。
AI/LLM 应用构建者：LLM Agent 经常需要生成并执行临时代码来完成任务（如数据清洗、API 调用后处理）。利用 WASM 沙箱执行这些代码，可以防止 prompt 注入导致 Agent 做出危险操作，这是 AI Agent 工程化落地中的关键安全基础设施。

值得关注的后续

1）持久化状态方案的进展。目前的 WASM 二进制入口是一次性执行模式：启动-运行-退出。Willison 明确表示要支持多轮调用中保持变量和函数驻留，这需要设计持续运行的 WASM 实例和宿主之间的通信机制。如果该问题解决，沙箱的实用性将大幅提升。
2）MicroPython 标准库的覆盖度。MicroPython 仅包含 Python 标准库的裁剪子集，对于许多依赖 datetime、json、re 等模块的脚本可能不够用。社区是否会扩充兼容库列表将决定方案能覆盖多少真实用例。
3）竞争对手与生态整合。Pyodide 目前不适用于服务端 Python，而 CPython 编译 WASM 的方案（如 python-wasi）尚在早期。 micropython-wasm 能否成为 Datasette/LLM 之外的通用 Python 沙箱层，取决于其性能是否足够支撑高频调用以及是否会孵化出独立的开源维护团队。