在大语言模型驱动的 AI 代理系统中，让模型直接生成并执行代码正在成为一种主流范式。然而，传统的代码执行方案面临一个核心矛盾：要么选择安全性但付出高昂的延迟成本（如 Docker 容器），要么追求低延迟但暴露巨大的攻击面（如直接使用 exec()）。由 Pydantic 团队开发的 Monty 项目试图从根本上解决这一困境 —— 它用 Rust 实现了一个最小化的安全 Python 解释器，专门为运行 AI 生成的代码而设计。本文将深入剖析 Monty 的沙箱机制、内存安全保证以及在 AI 工具链中的工程实践。
传统代码执行方案的安全困境
在探讨 Monty 的设计之前，有必要理解当前 AI 代码执行领域面临的安全范式挑战。主流方案大致可分为三类，各有其不可忽视的局限性。
第一类是完整的容器隔离方案，以 Docker 为代表。这种方案提供了操作系统级别的隔离，能够限制文件系统访问、网络通信和进程权限，安全性相对可靠。然而，其启动延迟高达数百毫秒（实测约 195ms），且需要维护完整的容器镜像（最小的 python:3.14-alpine 镜像也有 50MB 左右），部署和编排的复杂度较高。对于需要频繁启动独立执行环境的 AI 代理场景，这种开销往往难以接受。
第二类是 WebAssembly 运行时方案，以 Pyodide 为代表。它将 CPython 编译为 WASM，在浏览器或 Deno 等运行时中执行。虽然提供了一定程度的沙箱能力，但其冷启动时间长达约 2800ms，且 WASM 沙箱并非为服务器端安全隔离设计 ——Python 代码理论上可以突破 WASM 边界访问宿主 JS 运行时。更关键的是，WASM 环境下的内存和执行时间限制难以精确强制执行。
第三类是最简化的直接执行方案，使用 Python 的 exec() 或子进程。这种方式延迟最低（exec() 约 0.1ms，子进程约 30ms），但安全性完全不存在 —— 代码可以任意访问文件系统、修改环境变量、发起网络请求甚至执行系统命令。在多租户或面对不可信代码的场景中，这种方案无异于敞开大门。
Monty 的出现正是为了填补这一空白：提供接近直接执行的低延迟，同时实现足以应对生产环境的隔离强度。
Monty 的架构设计与安全模型
Monty 的核心设计理念可以概括为「最小化攻击面 + 内存安全 + 明确的边界控制」。它并非要实现一个完整的 Python 解释器，而是有意识地限制语言特性，仅保留 AI 代理表达意图所需的功能子集。
在语言层面，Monty 支持合理的 Python 代码子集，包括函数定义、异步函数、基本类型和控制流，但刻意排除了若干高风险特性。当前版本不支持类定义（classes）、模式匹配（match statements），也不支持完整的标准库 —— 目前仅允许使用 sys、typing、asyncio 等少量模块，三方库更是完全不被支持。这种限制并非技术上的做不到，而是有意为之：每减少一个语言特性，就减少了一类可能的攻击向量。
在运行时隔离层面，Monty 采用了严格的零信任模型。文件系统访问、环境变量读取、网络请求 —— 所有这些在传统 Python 环境中理所当然的能力，在 Monty 中都被完全阻断。任何与外界的交互都必须通过外部函数调用（External Function Calls）机制，且这些调用需要开发者在初始化解释器时明确授权。当 Monty 代码需要访问网络或读取文件时，执行会暂停，状态被序列化为快照，交给宿主程序处理，宿主返回结果后执行恢复。这种设计从根本上消除了代码直接接触敏感资源的能力。
Rust 的使用为 Monty 带来了关键的内存安全保证。传统 CPython 实现使用 C 语言编写，虽然性能优异，但存在空指针解引用、缓冲区溢出、使用 - after-free 等内存安全问题的可能性。Rust 的所有权系统和借用检查器在编译期就消除了这些隐患。更重要的是，Rust 的内存模型使得 Monty 可以在没有垃圾回收器的情况下运行，这对于需要精确控制执行停顿和快照的场景至关重要 —— 没有 GC 暂停意味着执行时间可以被精确计量和限制。
资源限制与可观测性设计
除了访问控制，Monty 还提供了精细的资源使用限制机制，这对于防止恶意代码消耗系统资源至关重要。解释器内置了内存使用追踪、分配计数限制、栈深度限制和执行时间超时机制。当任何一项指标超出预设阈值时，执行会立即终止，防止代码陷入无限循环或试图耗尽系统资源。
Monty 的资源限制实现充分利用了 Rust 的控制流能力。由于整个解释器运行在 Rust 的上下文中，可以利用 Rust 的非侵入式性能监控，在不显著增加开销的情况下追踪资源使用情况。与基于信号或定时器的传统超时方案不同，Monty 的超时是协作式的 —— 解释器在执行的关键检查点主动判断是否超时，这避免了竞争条件，也使得超时行为更加可预测。
在可观测性方面，Monty 捕获并返回代码执行过程中的标准输出和标准错误。这意味着即使代码被沙箱隔离，开发者仍然可以查看日志、调试信息，这对于诊断 AI 代理的行为逻辑至关重要。同时，解释器的执行结果、暂停状态和错误信息都可以被序列化和反序列化，支持跨进程甚至跨机器的执行恢复，为分布式执行和状态持久化提供了基础。
快照机制与状态持久化
Monty 的快照功能是其区别于其他沙箱方案的一个重要特性。当代码执行遇到外部函数调用时，解释器的整个状态 —— 包括执行栈、变量环境和暂停位置 —— 可以被序列化为字节串。这个字节串可以存储到文件或数据库中，稍后甚至在另一个进程或另一台机器上恢复执行。
这种设计为 AI 代理架构带来了极大的灵活性。在传统方案中，如果外部函数调用需要较长时间（如调用远程 API），你必须维护一个长期运行的执行上下文，或者将状态序列化后自行管理。Monty 将这个过程内置为一流特性：快照 / 恢复的 API 简单直观（dump() 和 load() 方法），序列化格式紧凑且版本稳定。
快照机制还支持一个有趣的用例：执行分叉（forking）。由于状态可以序列化后恢复多次，你可以从同一个暂停点分支出多个执行路径，尝试不同的外部函数返回值，然后比较不同路径的结果。这对于需要回溯和探索的 AI 推理场景非常有价值。
与 AI 代理系统的集成实践
Monty 正在被用于实现 Pydantic AI 中的「代码模式」（Code Mode）。在这个模式下，大语言模型不再通过传统的工具调用接口与外部函数交互，而是直接编写 Python 代码来调用工具。这种方式的优势在于：模型可以更自然地表达复杂的控制流（循环、条件分支、重试逻辑），一次调用中可以组合多个工具，且代码比一系列独立的工具调用更容易理解和调试。
在典型的集成模式中，开发者将一组函数注册为「外部函数」，授予 Monty 代码调用它们的权限。这些函数在宿主环境中实现，可以执行任意操作 —— 访问数据库、调用 REST API、操作文件系统等 —— 因为它们运行在受信任的宿主代码中，不受 Monty 沙箱限制。Monty 代码所能做的，只是以类型安全的方式调用这些已授权的函数。
类型检查是 Monty 的另一个亮点。解释器支持完整的现代 Python 类型提示，并内置了 ty 类型检查器。这意味着在代码执行之前，Monty 可以验证外部函数调用的参数类型是否正确，捕获明显的类型错误。这不仅提高了安全性，也提升了 AI 生成代码的可靠性 —— 模型更容易生成符合预期的代码，因为类型错误会在执行前被检测出来。
性能基准与工程权衡
在性能方面，Monty 交出了一份令人印象深刻的答卷。其启动延迟仅为微秒级别（实测约 0.06ms），这意味着从代码提交到开始执行之间几乎没有可感知的延迟。相比之下，即使是优化良好的 Docker 容器也需要约 195ms，Pyodide 的 WASM 冷启动更是需要约 2800ms。这种差距在需要频繁启动独立执行环境的 AI 代理场景中是决定性的。
运行时性能方面，Monty 大致与 CPython 在同一数量级，通常在 5 倍更快到 5 倍更慢之间波动。这个范围看似很大，但对于 AI 代理生成的代码（通常是非性能关键的胶水代码）来说，完全可以接受。毕竟，AI 代理的主要瓶颈通常在模型推理时间，而非代码执行时间。
在工程复杂度方面，Monty 也具有显著优势。部署一个 Monty 沙箱只需要安装一个 Python 包（约 4.5MB），或者一个 npm 包，无需运行 Docker 守护进程，无需管理容器镜像，无需配置网络策略。对于已经使用 Python 的 AI 系统来说，集成 Monty 的学习曲线几乎为零。
安全边界与威胁模型
理解 Monty 的安全边界对于正确使用它至关重要。Monty 旨在隔离「AI 生成的不可信代码」，其威胁模型假设代码可能是恶意的或存在漏洞的，需要防止它访问或破坏宿主系统的资源。
在这个威胁模型下，Monty 能够有效防御的攻击包括：文件系统读写（完全阻断）、网络访问（完全阻断）、环境变量读取（完全阻断）、系统命令执行（完全阻断）、资源耗尽攻击（通过限制机制防御）。Monty 无法防御的，或者说不在其设计目标内的攻击包括：对 Monty 解释器本身（Rust 代码）的漏洞利用、侧信道攻击（如时序分析）、以及通过已授权外部函数发起的攻击（这是宿主安全的责任）。
特别值得注意的是，Monty 的安全性建立在「最小权限原则」之上。即使开发者错误地授予了过多的外部函数权限，导致代码能够执行删除文件的操作，责任也在开发者 ——Monty 只是忠实地执行了被授权的函数调用。这与 Docker 等容器方案形成对比：容器的安全模型依赖于内核隔离，即使配置错误，某些操作仍会被内核阻止。Monty 则相反，它假设所有外部函数调用都是可信的，将信任决策完全交给开发者。
技术局限与演进方向
作为一个实验性项目，Monty 当前存在若干技术限制。它不支持类定义，这意味着面向对象风格的代码无法运行；它不支持完整的标准库，许多常见的 Python 惯用法（如 json 模块）尚不可用；它不支持三方库，任何需要外部依赖的功能都无法实现。
Pydantic 团队正在积极推进这些功能的实现。类定义支持已在开发中，这将进一步扩展 Monty 可运行的代码范围。json 和 dataclasses 模块也在路线图上。长远来看，Monty 可能会增加对更多标准库模块的支持，但会继续保持「按需添加」的原则 —— 只添加那些对 AI 代理确实有用的模块，而非追求完整的 CPython 兼容性。
另一个值得关注的演进方向是与其他编程语言的互操作。虽然 Monty 主要面向 Python 生态系统，但它的 Rust 核心使得它可以被编译为 WebAssembly 并在 JavaScript 环境中运行。官方已经提供了 npm 包 @pydantic/monty，可以在浏览器或 Node.js 中使用。这为全栈 AI 应用提供了一个统一的代码执行层。
工程实践建议
对于考虑在生产环境中使用 Monty 的团队，以下是一些实践建议。首先，明确你的威胁模型 ——Monty 适合隔离 AI 生成的代码，但不适合隔离可能包含恶意依赖或利用解释器漏洞的完整 Python 程序。其次，设计外部函数时要格外谨慎 —— 它们是沙箱的唯一出口，一旦授权，就完全信任它们不会执行危险操作。再次，利用好快照机制 —— 它不仅支持异步交互，也是实现超时重试和故障恢复的有力工具。最后，关注类型检查 —— 启用类型检查可以捕获大量常见错误，提高 AI 生成代码的可靠性。
Monty 代表了一种新的代码执行范式：用一门现代语言（Rust）从零实现一门老语言（Python）的最小子集，以满足特定的安全和性能需求。这种方法看似折中 —— 既不如容器安全，也不如 CPython 功能完整 —— 但在 AI 代理代码执行这一特定场景下，它找到了一个极具吸引力的最优平衡点。随着 AI 代理系统越来越普遍，对安全、快速、可控的代码执行环境的需求只会增加。Monty 的设计理念和工程实践，为这个领域提供了一个值得深入研究和借鉴的解决方案。
参考资料：Monty 官方 GitHub 仓库（https://github.com/pydantic/monty）