当 AI 代理需要执行由大语言模型生成的 Python 代码时，安全性始终是首要考量。传统的沙箱方案如 Docker 容器虽然隔离彻底，但启动延迟高达数百毫秒，且设置复杂。Pyodide 等 WebAssembly 方案则面临内存限制和隔离不足的问题。在这种情况下，Pydantic 开发的 Monty 项目提供了一种全新的思路：用一个用 Rust 从头编写的极简 Python 解释器，直接在进程级别实现安全隔离，同时保持微秒级的启动速度和接近 CPython 的运行时性能。
内存安全：Rust 所有权模型的内生保障
Monty 的核心安全优势源于其底层实现语言 Rust 的设计哲学。传统的 CPython 解释器使用 C 语言编写，这意味着开发者在处理内存管理时必须手动管理堆栈分配，稍有不慎便会引入 use-after-free、double-free 或迭代器失效等经典内存安全问题。这些漏洞在安全审计中屡见不鲜，且往往难以在测试阶段发现，却在运行时可能被恶意利用来获取系统权限或泄露敏感数据。
Rust 的所有权系统（Ownership）和借用检查器（Borrow Checker）在编译阶段就消除了这类风险。在 Monty 的实现中，所有内存分配都受到 Rust 类型系统的严格约束，任何试图绕过生命周期规则的代码都无法通过编译。这意味着即使运行的是完全不受信任的、由 LLM 生成的代码，解释器本身也不可能出现内存损坏问题。这种安全保障不需要额外的垃圾回收器或运行时检查，因此 Monty 能够在保持语言简洁性的同时实现与企业级安全要求相符的内存保护。
沙箱机制：从语言层面重构安全边界
与传统的 Python 沙箱方案不同，Monty 并非试图在 CPython 之上通过禁用内置函数或修补运行时来限制代码行为。实践已经反复证明，这种「应用层沙箱」的方法注定失败。正如安全研究者所指出的，Python 的动态特性允许代码通过 __builtins__ 恢复、__class__ 基类遍历以及帧栈检查等多种手段突破限制。PySandbox 等项目的失败案例清晰地说明了这一点：在一个拥有超过 12 万行 C 代码的 Python 核心上进行安全审计几乎是不可能完成的任务。
Monty 采取了一种根本不同的策略：它从一开始就将自身定位为一个完全隔离的执行环境。在 Monty 的运行时中，文件系统访问、网络调用和环境变量读取等操作全部通过外部函数调用（External Function Calls）实现，开发者可以完全控制哪些函数可以被调用、哪些资源可以被访问。这种设计将安全策略从「尝试堵住所有漏洞」转变为「仅开放必要的最小权限」，从架构层面大幅降低了攻击面。
资源限制：可量化、可预测的执行边界
除了访问控制，Monty 还内置了对资源使用的精确限制能力。在高并发场景下运行的 AI 代理可能同时执行数百个代码片段，任何一个失控的代码都可能迅速耗尽系统资源导致服务中断。Monty 允许开发者预设内存使用上限、分配次数上限、栈深度限制以及执行时间限制。当代码尝试超出这些限制时，解释器会立即中断执行并返回明确的错误信息，而非让整个进程陷入无响应状态。
这些限制机制对于构建可靠的 AI 代理系统至关重要。例如，在代码生成场景中，AI 可能会写出存在无限循环倾向的代码，或者在不了解数据大小的情况下尝试一次性加载整个文件。Monty 的资源限制确保了这些错误只会影响单个执行单元，而不会波及其他并发请求或底层基础设施。
性能对比：替代容器化方案的技术基础
在传统的代码执行架构中，为了确保安全性，通常需要为每个请求启动一个独立的容器。这种方法虽然隔离彻底，但启动延迟通常在 100 到 200 毫秒的量级，对于需要实时响应的 AI 代理系统来说开销过大。Pyodide 等 WebAssembly 方案虽然启动更快，但其冷启动时间仍在数秒级别，且在服务器端运行时缺乏可靠的内存隔离机制。
Monty 的性能数据则展现出显著的优势：启动延迟低于 1 微秒，比 Docker 容器快约 20 万倍；运行时性能与 CPython 相近，通常在 5 倍快到 5 倍慢的范围内。这一性能特性使得 Monty 特别适合以下场景：高频次代码执行的 AI 代理、需要低延迟响应的交互式应用、对资源成本敏感的部署环境，以及需要快照和恢复执行状态的复杂工作流。
部署参数与集成实践
在实际部署中，Monty 提供了灵活的 API 来满足不同的安全需求。从 Python 端，可以创建 pydantic_monty.Monty 实例并传入待执行的代码、输入变量定义、外部函数白名单以及类型检查配置。代码执行可以是同步的也可以是异步的，后者特别适合需要与外部 API 交互的代理工作流。
外部函数机制是 Monty 安全模型的核心组成部分。开发者需要显式声明代码可以调用的函数列表，并在运行时将这些函数的实际实现注入。当代码执行遇到外部函数调用时，Monty 会暂停执行并将控制权交还给宿主程序，宿主程序可以执行真实的函数逻辑、检查参数有效性、记录调用日志，然后恢复代码执行。这种设计不仅增强了安全性，还使得复杂的代理行为编排成为可能。
序列化功能是另一个值得关注的特性。Monty 支持将解释器状态快照序列化为字节串并保存到文件或数据库中。这意味着一个执行到一半的代码可以在进程边界之间迁移，甚至可以暂停后稍后恢复执行。这种能力对于实现可靠的执行工作流、调试复杂的代理行为以及构建可恢复的任务系统都具有重要价值。
技术定位与适用边界
理解 Monty 的设计定位对于正确使用它至关重要。Monty 明确声明自己是一个极度受限的解释器，设计目标是运行 AI 代理生成的代码，而非替代完整的 Python 开发环境。它不支持标准库的大部分模块（仅开放了 sys、typing、asyncio 等少数模块），不支持第三方库，也不支持类定义和 match 语句。这种极简主义的设计选择正是其安全性和性能的来源：每增加一个语言特性，就意味着更多的潜在攻击面和实现复杂性。
对于需要完整 Python 环境的场景，Docker 容器或专业的沙箱服务仍然是更合适的选择。但对于那些只需要让 AI 代码执行特定计算任务、调用预定义工具、访问受控数据的场景，Monty 提供了一种在安全性、性能和复杂度之间取得极佳平衡的解决方案。Pydantic 计划将其用于 Pydantic AI 的 Code Mode 功能中，这一选择本身就说明了业界对其技术方向的认可。
未来演进与生态定位
作为一个新兴项目，Monty 仍在积极开发中。其路线图中提到了对类定义、match 语句以及更多标准库模块的支持，这些改进将使 Monty 能够覆盖更广泛的用例。然而，项目的核心原则应当保持不变：始终将安全性和简洁性置于功能完备性之上。对于关注 AI 系统安全的开发者而言，持续关注 Monty 的发展并在合适的场景中采用它，将是构建可靠代理基础设施的重要技术选型之一。
资料来源：GitHub Pydantic Monty 项目（https://github.com/pydantic/monty）