pydantic/monty

解决什么问题

现在越来越多的 Agent 框架不再让模型输出 JSON 工具调用，而是让它直接写代码。代码一旦由模型生成，就是不可信的，必须找地方执行。常规做法是每次执行起一个容器，隔离性尚可，但冷启动动辄几百毫秒，还得维护编排层，调用越频繁账单越贵。Monty 同时解决延迟和运维这两件事：它用 Rust 写了一个 Python 解释器，在内部执行一个 Python 子集，沙箱里没有文件系统、没有环境变量、也没有网络，从预热池取用时不到 1ms 就能开始跑。

有什么不同

多数沙箱方案隔离的是进程或虚拟机，隔离性来自操作系统，代价是启动时间和内存。Monty 把隔离边界放进了解释器内部，没有进程要拉起，也没有内核要调度。宿主能力是显式授予的：函数和挂载由调用方传入，沙箱只能看到返回值——README 里的 external_lookup 例子就是这个意思。由此有两个直接后果。第一，它不是完整的 Python 运行时，README 指向专门的限制文档，标准库的大部分和 C 扩展都用不了。第二，官方给出的启动延迟是预热池内不到 1ms，而项目自己引用的沙箱服务约 1500ms，差了一到两个数量级；这意味着 Agent 每一轮能负担得起的代码执行次数完全不同。和 Pyodide、WASI 这类方案比，Monty 用 Python 完整性换更薄的边界和更小的部署体积。快照和资源限制补上了控制面。

适合谁

适合把"执行模型写的 Python"当作 Agent 循环一部分的团队：Pydantic AI 用户最直接，Monty 就是其 Code Mode 的引擎；也适合任何想要亚毫秒执行、又不想维护容器服务的人，典型场景是数据分析 Agent、计算与数据转换步骤，以及只需要几个宿主函数、不需要整个生态的代码。如果你的生成代码依赖 numpy、pandas、requests 或任何编译型依赖，或者需要完整 CPython 语义，又或者你的威胁模型要求操作系统级隔离而不是解释器级隔离，那就不合适。已经习惯容器方案、能接受单次执行延迟的团队也不值得换。

上手成本

MIT 协议，提供 Python、JavaScript/TypeScript、Rust 三种包，语言接入不是问题。真正的成本在 Python 子集：动手前得先读限制文档，通常还需要调整提示词或生成代码，让模型只写受支持的语法。商业版 Full Monty server 是单独收费的产品；OSS 包能独立使用，但多租户服务能力属于商业范畴。项目创建于 2023 年，但面向公众的沙箱功能较新，API 可能还会变。

点评

这不是一个蹭热点的新项目：它 2023 年就存在，并且是 Pydantic AI 的底层依赖，这是有分量的生产信号；那篇 323 分的 Hacker News 讨论也说明真实用户关注。本月在 Rust 榜单涨了 533 星，总量约 8.8k，更像是稳步增长而不是一夜爆红。取舍很清楚也很坦诚：放弃 Python 完整性，换来比容器更便宜、快得多的隔离。如果你的 Agent 只写小而精、靠宿主提供能力的 Python，这是这个方向上最值得看的方案；如果它需要真实生态，那暂时还是继续用容器。