Simon Willison 这次发布的东西不大，但卡在一个很要命的位置：Python 插件怎么安全运行。

他做了一个 alpha 包 micropython-wasm，把 MicroPython 编译成 WebAssembly，再通过 wasmtime 嵌进 Python 应用里跑。这个包已经用在 Datasette Agent 的插件 datasette-agent-micropython 里。

反常点在这里：Python 很适合做插件，也很不适合做沙箱。插件一旦在宿主应用里跑起来，通常就有完整权限。能读文件，能连网络，也可能泄露数据、拖垮进程。

这不是理论洁癖。对插件系统和 AI Agent 来说，代码执行能力越强，安全边界越不能靠“相信作者”和“相信模型”。

它解决的是插件权限，不是完整 Python 运行时

micropython-wasm 的目标很清楚：在 Python 应用里跑一小段受控代码。

它不是把 CPython 原样塞进沙箱。MicroPython 是 Python 3 的轻量实现，标准库和运行能力是子集。适合小脚本、数据转换、受限逻辑，不适合拿来跑完整 Python 生态。

核心取舍可以压成一张表：

问题普通 Python 插件的风险micropython-wasm 的处理
安装依赖复杂会劝退用户依赖 wasmtime，PyPI 有 binary wheels
执行权限插件常拿宿主完整权限代码跑在 WASM 里的 MicroPython
内存恶意或错误代码可能拖垮进程wasmtime 支持内存限制
CPU死循环不好收wasmtime 用 fuel 限制执行量
文件/网络默认能力太危险通过宿主控制，没开放就不能用
宿主交互沙箱太封闭就没产品价值用 host functions 精准开口

这里最重要的不是“WASM 天然安全”。这句话太粗。

WASM 的好处是边界清楚。内存怎么限，能力怎么暴露，宿主函数给不给，至少能被设计、配置和测试。过去很多 Python 插件系统的问题，是边界根本没摆上桌。

Pyodide 没被选中，也不奇怪。它很强，但主要面向浏览器和 Node.js。原文提到，作者能找到的最新建议仍是：Pyodide 由 Emscripten 工具链构建，只能跑在浏览器或 Node.js。服务器端 Python 嵌入场景，不是它的主场。

MicroPython 反而合适。它本来就为受限环境设计。WebAssembly 在这里也像一个受限环境。

对 Python 插件开发者来说，这意味着一个现实动作：如果你只是想让用户写小段转换逻辑、调度脚本、Agent 工具函数，可以开始观察这条路线。别急着迁移生产系统，但可以把“WASM + 轻量解释器”列进技术预研。

真正的工程亮点，是把沙箱做成可用的笼子

把解释器编进 WASM，只是第一步。

Willison 碰到的难点是会话状态。普通 WASM 入口跑完就停。但 Agent 场景需要变量和函数留在内存里。上一段代码定义的东西，下一段还得能用。

他的做法有点土，也有效：宿主侧开线程和队列；MicroPython 里通过 host function 等下一段代码；拿到后 eval 执行；执行完再把结果传回宿主。

这让代码可以像会话一样运行：先设 x = 10，下一次还能 x += 5。

另一个关键点是 host functions。项目里用了 78 行 C，把宿主函数能力编进一个 362KB 的 WebAssembly blob。

这个细节决定了它不是玩具。

完全隔绝的沙箱很安全，也很没用。产品里真正需要的是“能开洞，但每个洞都要可控”。比如只允许读取某个文件，只允许请求某个批准过的 JSON 地址，只允许调用某个数据库写入函数。

问题也在这里回来。

“利之所在，弊亦随之。”host function 暴露什么、参数怎么校验、异常怎么处理，都会变成攻击面。WASM 负责把笼子搭出来，但钥匙怎么发，还是宿主应用自己的责任。

这也是它和一些替代路线的差别：

路线优点现实约束
直接跑 Python 插件生态完整，开发快权限边界弱，风险大
浏览器/Node.js 里的 PyodidePython 能力强，生态成熟不适配服务器端 Python 嵌入场景
系统级容器/进程隔离隔离强，工程经验多部署重，插件体验不轻
MicroPython + WASM轻、可嵌入、边界清楚不是完整 CPython，安全仍需审计

所以它最适合的不是“跑任何 Python 代码”。

更适合这些场景：小段数据处理、受控插件逻辑、Agent 调用的工具函数、定时抓取批准来源后做格式转换。原文里提到的例子，就是从批准位置抓 JSON，跑一点代码整理成字典列表，再插入 SQLite 表。

不适合的场景也要说清：复杂依赖、完整 Python 标准库、需要大量第三方包、强安全承诺的多租户生产环境。至少现在不适合。

方向对，但安全账还没结

我更愿意把 micropython-wasm 看成行业信号，而不是现成答案。

它说明 Python 插件生态终于摸到一条相对干净的沙箱路径：用 WASM 做执行边界，用 MicroPython 承担轻量代码，用 wasmtime 管资源，再通过 host functions 开受控能力。

这条路比“插件作者不会乱来”靠谱。

但它离“可托付生产”还差几笔硬账。

作者自己也说得很清楚：这是 alpha。他不建议风险偏好低的人使用。这个项目还带着明显的个人原型色彩，甚至有大量 AI coding agent 参与构建。

这不丢人。真正重要的是别把原型当证明。

CPU 限制就是一个例子。wasmtime 的 fuel 概念适合限制执行量，但单位不直观。作者现在实验的默认值是 2000 万 fuel，他自己也不确定是不是合适。

GPT-5.5 没能越狱，也只能说明这轮攻击没打穿。它不是安全审计。不是形式化证明。更不是生产背书。

如果一个团队真要评估这条路线，我会看四件事：

  • 默认权限是不是足够保守，文件和网络是否默认关闭；
  • host functions 是否少到不能再少，参数校验是否清楚；
  • CPU、内存、输出大小、执行时间是否都有上限；
  • 是否有人做过独立安全审计，维护节奏是否稳定。

对 Agent 工具开发团队来说，下一步不是立刻把生产插件迁进去。更现实的做法是拿低风险任务试水：数据清洗、格式转换、内部 demo、无敏感数据的插件实验。

对安全要求高的团队，结论更简单：观望，等审计，或者自己投入安全团队做验证。

这件事的历史感很强。早期浏览器也不是因为“脚本方便”才真正长大，而是因为它们学会了在敌意代码里建立边界。插件和 Agent 现在走到类似位置，但不完全一样：浏览器沙箱经过了多年攻击和修补，micropython-wasm 还只是一个聪明原型。

主线还是那句：代码执行能力会变得越来越便宜，安全边界会变得越来越贵。

模型越会写代码，平台越想让代码自动跑。沙箱就不是高级功能，而是地基。地基靠运气，楼越高，越心虚。