KechuAI

Monty：Pydantic 用 Rust 写的、为跑 AI 生成代码而生的 Python 沙箱

Python
Rust
沙箱
AI Agent
安全
Pydantic
2026/9/29
·

阅读时间: 大约 8 分钟

Monty：Pydantic 用 Rust 写的、为跑 AI 生成代码而生的 Python 沙箱

Monty 官方文档：v1.0.0 已发布，定位为「用 Rust 写的、给 AI 代码用的最小安全 Python 沙箱」

让 LLM 生成 Python 代码并真实执行，是 Agent 工具调用里最强大也最危险的一环。传统做法是每个代码片段起一个 Docker 容器——隔离够了，但启动要几百到上千毫秒，Agent 一次任务串行调十几个工具就慢得不可用。Monty 是 Pydantic 团队（Samuel Colvin 等）用 Rust 写的 Python 沙箱，v1.0.0 于 2026-09-25 发布，目标就是「在微秒级延迟下安全执行 AI 生成的代码」。本文基于其官方文档做分析。

一、它要解决的矛盾

执行不可信代码，核心是安全与延迟的矛盾：

  • Docker/gVisor 容器：隔离强，但冷启动约 1500ms，Agent 工具链里不可接受；
  • 直接在主进程跑：快，但 LLM 生成的恶意/错误代码能读环境变量、访问网络、删文件；
  • Pyodide/WASI：浏览器向，但工程集成与系统能力有限。

Monty 的答案：用 Rust 实现一个受限的 Python 3.14 子集解释器，在进程内做内存级隔离，新沙箱从运行中的资源池取出不到 1ms（商业版 Full Monty 约 2ms），对比容器类沙箱服务约 1500ms。它已经用在 Pydantic AI 的 Code Mode 里。

二、安全模型：沙箱里「没有」文件系统、网络、环境变量

这是 Monty 最核心的设计选择，README 原话：

Filesystem, environment variables and network do not exist inside the sandbox: it reaches the host only through the functions and mounts you pass in.

也就是说，LLM 代码在沙箱里根本 import os 不到真实环境、发不出网络请求、读不到环境变量。它要访问外部世界，只能通过你显式注入的函数（external_lookup）。示例里：

session.feed_run(
    code,
    inputs={'bulb_watts': 10},
    external_lookup={'nutrition': lambda food: {'kcal': 230}},
)

nutrition 这个函数跑在宿主机上，沙箱只能看到它的返回值。这样 Agent 代码可以调用宿主能力，却碰不到宿主本身。

三、关键能力

Monty 的设计理由：从字节恢复执行状态、VM 内强制内存与时间资源限制、OSS 包与商业版并存

  • 快照与恢复：可把整个沙箱状态 dump 成字节，外部函数调用或 REPL 片段结束时落盘，下次从字节恢复——长外部调用与人在环（human-in-the-loop）因此变得廉价，长运行 REPL 会话也好实现；
  • 严格资源限制：最大内存与执行时间由 VM 自己强制——'x' * 10**12 在分配前就抛 MemoryError，而不是把机器 OOM；
  • 多语言绑定：Python（uv add pydantic-monty）、JS/TS（npm i @pydantic/monty）、Rust（cargo add monty），社区还有 Go、Dart 绑定；
  • 两种形态：OSS Monty（MIT，本地包）与 Full Monty（商业，同一沙箱 worker 打成容器镜像、经 WebSocket 作为服务提供，带 OS 级隔离与水平扩展）。

四、必须接受的代价（官方与 Koala 都点明）

  1. 受限的 Python 子集。Monty 不是完整 CPython——它是一个用 Rust 重写的解释器，只支持「Python 子集」。Koala 点评准确：复杂业务逻辑可能跑不通，因为缺失它没实现的标准库模块和语言边角。把它当「跑 LLM 生成的小脚本」的沙箱，而不是「跑任意生产 Python」的运行时。

  2. 安全边界是「子集 + 无外部世界」，不是 OS 隔离。进程内沙箱的安全性依赖解释器实现得正确；OSS 版给的是「快速、防呆」级隔离，真正需要 OS 级隔离与水平扩展的生产场景，官方推 Full Monty 容器版。这一点要按威胁模型选。

  3. v1.0.0 刚发布：33 个 release、63 位贡献者，生态年轻；文档自己也写「as is, no warranty」。

  4. 性能数字是「从池中取出」的延迟：<1ms 指 checkout 一个预热好的会话，不是冷启动、也不是执行任意代码的端到端延迟；真实吞吐取决于你跑的代码。

五、适用与不适用场景

适合： Agent 框架里需要安全、低延迟执行 LLM 生成代码的场景；需要把代码执行嵌进请求路径（工具调用）、等不起容器冷启动的应用；想要快照/恢复做长时 REPL 的人；已经在用 Pydantic AI 的团队。

不适合： 跑复杂生产 Python（缺标准库、语言子集受限）；需要 OS 级强隔离且不愿上商业版的高安全场景；要跑依赖原生 C 扩展（numpy 等）的数据科学代码的项目。

六、客观分析：优势与意义

优势： 把代码执行延迟从百毫秒级压到亚毫秒级，让 Agent 工具调用「边想边跑」成为可能；无文件系统/网络/环境变量的默认安全模型，配合显式注入函数，权限边界清晰；快照恢复与 VM 内资源限制是成熟的工程设计；Python/JS/Rust 三端绑定。

局限： Python 子集 + 标准库缺失，不能跑任意代码；OSS 是进程内沙箱，OS 级隔离要商业版；v1.0 刚发布；性能数字有口径前提。

Monty 指向的趋势是：AI Agent 的工具执行层正在从「每次起容器」走向「进程内热沙箱」。当 LLM 生成的代码越来越短、越偏脚本化，为每个片段付 1.5 秒容器启动费就成了纯粹浪费。Pydantic 用做类型校验起家的工程能力，去做一个受限 Python 沙箱，逻辑上是连贯的——他们最懂「怎么在沙箱里把数据结构约束好」。对构建 Agent 平台的团队，这是一个绕不开的参照系。

参考来源