Monty - Trình thông dịch Python nhẹ để thực thi mã do AI tạo ra một cách an toàn

 (github.com/pydantic)
8 điểm bởi GN⁺ 2026-02-08 | 1 bình luận | Chia sẻ qua WhatsApp
  • Trình thông dịch Python nhẹ viết bằng Rust được thiết kế để thực thi an toàn mã do AI tạo ra, loại bỏ độ phức tạp và độ trễ của sandbox dựa trên container
  • Chặn hoàn toàn quyền truy cập vào hệ thống tệp, biến môi trường và mạng, chỉ cho phép gọi các hàm bên ngoài do nhà phát triển chỉ định
  • Cung cấp thời gian khởi động dưới 1 micro giây và hiệu năng thực thi tương tự CPython, đồng thời có thể được gọi từ Rust, Python và JavaScript
  • Có thể lưu và khôi phục snapshot trạng thái thực thi ở mức byte, cho phép tạm dừng và tiếp tục giữa các tiến trình
  • Dự kiến sẽ vận hành tính năng Code Mode của Pydantic AI, đóng vai trò là thành phần cốt lõi để thực thi an toàn mã Python do LLM viết

Tổng quan về Monty

  • Monty là một trình thông dịch Python thử nghiệm được viết bằng Rust, là công cụ để thực thi an toàn mã do AI tạo ra
    • Tránh được chi phí, độ trễ và độ phức tạp của sandbox dựa trên container, đồng thời có thể thực thi trực tiếp mã Python do LLM viết
    • Thời gian khởi động ở mức vài micro giây, nhanh hơn rất nhiều so với hàng trăm mili giây của container thông thường
  • Các khả năng hiện có
    • Hỗ trợ thực thi một phần cú pháp của Python, bao gồm kiểm tra kiểu tĩnh dựa trên type hint
    • Chặn hoàn toàn truy cập vào host, việc gọi hàm bên ngoài chỉ khả dụng với những hàm được nhà phát triển cho phép rõ ràng
    • Có thể được gọi từ Rust, Python và JavaScript, đồng thời tích hợp sẵn tính năng theo dõi và giới hạn mức sử dụng tài nguyên
    • Hỗ trợ thu thập stdout/stderr, thực thi mã bất đồng bộ, lưu và khôi phục snapshot
  • Hạn chế
    • Thư viện chuẩn hiện chỉ dùng được sys, typing, asyncio, dataclasses(sắp hỗ trợ), json(sắp hỗ trợ)
    • Định nghĩa class và câu lệnh match hiện vẫn chưa được hỗ trợ
    • Thư viện bên thứ ba không nằm trong phạm vi hỗ trợ
  • Mục tiêu thiết kế chỉ có một: thực thi an toàn mã do agent viết

Tích hợp với Pydantic AI

  • Monty vận hành Code Mode của Pydantic AI
    • Thay vì gọi tool, LLM sẽ viết mã Python và Monty sẽ thực thi mã đó một cách an toàn
    • Trong ví dụ, các công cụ dạng hàm như get_weather, get_population được định nghĩa và LLM sẽ viết mã để gọi chúng

So sánh với các công nghệ thay thế

  • Monty có mức độ hoàn chỉnh về ngôn ngữ còn hạn chế, nhưng vượt trội về bảo mật, tốc độ và tính đơn giản
    • Độ trễ khởi động 0.06ms, miễn phí, cài đặt đơn giản, hỗ trợ tính năng snapshot
  • Tóm tắt so sánh với các công nghệ khác:
    • Docker: môi trường CPython đầy đủ, bảo mật tốt nhưng độ trễ khởi động 195ms
    • Pyodide: dựa trên WASM, bảo mật yếu và độ trễ khởi động 2800ms
    • starlark-rust: ngôn ngữ rất hạn chế, nhanh nhưng khác Python
    • dịch vụ sandboxing: bảo mật mạnh nhưng tốn chi phí, có độ trễ và cấu hình phức tạp
    • YOLO Python(exec/subprocess): nhanh nhưng không có bảo mật
  • Monty cung cấp môi trường Python an toàn cho việc thực thi mã AI thông qua các tính năng kiểm soát truy cập tệp, giới hạn tài nguyên, tạm dừng/tiếp tục dựa trên snapshot

Bài viết liên quan

1 bình luận

 
GN⁺ 2026-02-08
Ý kiến trên Hacker News

  • Tôi đã thử chạy bản build bằng WebAssembly. Tôi đã tạo một web playground để có thể tự thử trực tiếp
    Hiện vẫn chưa hỗ trợ class, nhưng khi LLM cố dùng class thì nó thấy lỗi và tự viết lại thành mã không dùng class
    Bài viết tổng hợp quá trình build ở đây

    • Điều đó đúng, nhưng nếu những bất tiện nhỏ ở mức trừu tượng thấp này tích tụ lại thì hiệu năng ở tầng cao hơn sẽ giảm. LLM sẽ phải dùng tài nguyên để lách các hạn chế của trình thông dịch Python thay vì tập trung giải quyết bài toán gốc
    • Dự án rất hay, nhưng tôi chưa nghĩ ra được trường hợp sử dụng nào thật rõ ràng. Đây là cho code mode để thay lời gọi MCP bằng hàm Monty, hay là để tiền/xử lý hậu truy vấn hoặc triển khai CaMeL?
      Điểm mạnh của terminal agent là quyền truy cập mạng và hệ thống tệp, nên nếu vậy thì container sandbox có vẻ là phần mở rộng tự nhiên hơn
    • Thành thật mà nói tôi không hiểu vì sao cần nó. Các model của tôi đã viết code tốt bằng nhiều ngôn ngữ, vậy tại sao lại phải dùng mỗi Python bị giới hạn?
      Tôi dùng Typescript, C# và Python đều không vấn đề gì
    • Câu “viết lại thành code không dùng class” rốt cuộc chỉ khả thi khi trong dữ liệu huấn luyện có đủ kiểu mã như vậy. May là có rất nhiều code trên Stack Overflow nên có lẽ vẫn ổn

  • Nó làm tôi nhớ lại thời còn dùng Mercurial trước khi chuyển sang Git. Khi đó Git đang là xu hướng nên ai cũng dùng, nhưng tôi luôn thấy UX của Mercurial tốt hơn nhiều
    Bây giờ mọi người đều viết agent exec bằng Python, còn tôi lại thấy TypeScript/JS phù hợp hơn. Nó nhanh, an toàn, và nhờ có type nên mật độ thông tin cũng cao hơn. Nhưng có lẽ lần này tôi vẫn sẽ thua

    • Có ba lý do khiến tôi nghĩ Python tốt hơn JS
      1. Thư viện chuẩn phong phú (CSV, sqlite3, json, v.v.)
      2. Code do LLM viết ra phần lớn chạy được ngay. JS thì có đủ yếu tố thiếu ổn định như tách biệt Node/Deno, rối rắm cú pháp import, top-level await
      3. Hệ sinh thái xử lý dữ liệu mạnh hơn hẳn (csv/pandas, v.v.)
    • Tôi đã dùng Python và JS hơn 10 năm, và lần nào cũng khổ sở vì xử lý ngoại lệ kỳ quặc hoặc các vấn đề kiểm tra null/undefined. Vì thế ngày nào tôi cũng sẽ chọn Python
    • Về mặt lịch sử, Python mạnh ở hệ sinh thái khoa học và AI. Đó là nhờ các thư viện như numpy, scipy, PyTorch
      Cá nhân tôi thích hệ thống kiểu tĩnh của TypeScript hơn, nhưng về tốc độ hay bảo mật thì hai ngôn ngữ này đều ở mức tương tự
    • Nếu agent có thể thực thi code thì nó có thể xử lý dữ liệu trực tiếp, giúp giảm lượng context cần dùng.
      Python có hệ sinh thái xử lý dữ liệu rất tốt, và các công cụ như Pyodide hay ty cũng có thể giúp giảm bớt vấn đề bảo mật
    • Nhờ AI mà CPython cuối cùng cũng đang chịu áp lực phải tích hợp JIT. Phía GPU cũng có nhiều JIT dựa trên Python DSL nên chênh lệch hiệu năng thực tế không lớn.
      Giờ đây NVIDIA cũng chính thức hỗ trợ viết kernel bằng Python

  • Dự án này là một hướng tiếp cận thú vị cho bài toán sandboxing. Trước đây tôi từng làm thử nghiệm jsrun, nhúng V8 vào Python để chạy JS an toàn
    Có vẻ Monty cũng nhắm đến mục tiêu tương tự. Bắt đầu bằng một trình thông dịch tối giản rất hợp với workload AI, nhưng xử lý đuôi dài cú pháp của Python thì không dễ
    Điều quan trọng là tìm ra điểm cân bằng giữa việc giảm bề mặt tính năng để tăng bảo mật và tính dự đoán, trong khi vẫn cung cấp đủ khả năng để xử lý cả những đoạn code phức tạp do LLM tạo ra

    • Mục tiêu là đơn giản hóa code mode hoặc gọi hàm bên ngoài. Trong ngắn hạn, có lẽ chỉ cần hỗ trợ class, dataclass, datetime và json là đủ
    • Nhưng trong môi trường coi trọng bảo mật thì cuối cùng tôi vẫn nghĩ cách ly dựa trên VM là bắt buộc. Cách tiếp cận như Monty có khá nhiều ràng buộc thực tế (ý kiến từ nhân viên E2B)

  • Hơi lạc đề một chút, nhưng nó làm tôi nhớ đến cuốn Monty Roberts The Man Who Listens to Horses.
    Nội dung là về việc học ngôn ngữ của động vật; có link sách và video

  • Mô tả “thực thi code Python do LLM viết ra một cách an toàn với tốc độ siêu cao” nghe rất thú vị.
    Tuy vậy, ngay cả runtime viết bằng Rust như uv cũng mất ít nhất khoảng 10ms, nên mức micro giây có vẻ khó đạt được
    Dù sao thì ý tưởng về một mini interpreter không có thư viện chuẩn vẫn rất hay. Từ góc nhìn sandboxing cho AI cũng khá mới mẻ, và tôi không ngờ Pydantic lại làm ra thứ như vậy

    • Pydantic và FastAPI là hai đội Python thú vị nhất hiện nay. Họ luôn tung ra dự án mới
    • Nhân tiện, uv là một runtime được viết bằng Rust

  • Tôi nghĩ tốt hơn là tạo ra một ngôn ngữ nghiêm ngặt dành riêng cho AI thay vì tái sử dụng các ngôn ngữ hiện có
    AI hiểu đặc tả rất tốt, nên không cần cú pháp lỏng lẻo như con người.
    Ngược lại, một ngôn ngữ ép buộc cấu trúc chính xác và định dạng nhất quán sẽ phù hợp hơn.
    Tôi cũng đang thử nghiệm một ngôn ngữ như thế, và cho rằng với sinh mã cho AI, ta có thể đòi hỏi mức kỷ luật còn cao hơn con người

    • Nhưng vấn đề là lượng học liệu. Để model học một ngôn ngữ mới thì cần dữ liệu khổng lồ.
      Thực tế hơn nhiều là giới hạn một model vốn đã giỏi Python theo kiểu “chỉ dùng những hàm này” mà thôi

  • Luận điểm về “những bất tiện nhỏ (papercut)” mà jstanley nói là đúng, nhưng ngược lại, khi chạy code do AI tạo ở quy mô lớn thì rủi ro bảo mật mới là thứ đáng lo hơn
    Việc mở file I/O, mạng, subprocess cho một CPython đầy đủ là rất nguy hiểm
    Tuy vậy, hạn chế class thì hơi kỳ. Nó không liên quan đến bảo mật, chỉ làm code trở nên lộn xộn hơn thôi.
    Có lẽ đây là cách tiếp cận “bắt đầu với tính năng tối thiểu rồi mở rộng dần”

    • Đúng vậy, giới hạn class không nhằm mục đích bảo mật mà đơn giản là chưa được triển khai

  • Thay vì bắt chước toàn bộ tính năng của CPython, cách làm một trình thông dịch tối thiểu chỉ phục vụ cho code AI là rất thú vị
    Một runtime đầy đủ có bề mặt tấn công quá rộng, còn tập con bị giới hạn thì an toàn hơn
    Chiến lược dùng phản hồi lỗi để khiến LLM tự thích nghi với cú pháp bị giới hạn cũng khá thực tế.
    Trong phần lớn kịch bản dùng công cụ, không cần đến metaclass hay import động

  • Đây là câu hỏi đơn giản, nhưng liệu không thể dùng seccomp để hạn chế system call sao?
    Nếu muốn chặn truy cập tệp thì chỉ cần chặn các syscall liên quan, vậy tại sao lại cần hẳn một trình thông dịch riêng?

    • Các dự án như bvisor đang đi theo hướng đó
    • Đó là hướng đi đúng, nhưng nếu runtime nền tảng quá mạnh thì vẫn có nhiều khả năng bị vượt qua.
      Nếu ngay từ đầu khởi động bằng một runtime cực kỳ đơn giản thì bề mặt tấn công sẽ nhỏ hơn nhiều và an toàn hơn hẳn

  • Bản thân dự án thì hợp lý, nhưng cụm từ “công cụ siêu nhanh cho AI” vẫn khiến tôi bật cười
    Tốc độ suy nghĩ của AI vốn đã quá chậm, nên dù thực thi code nhanh đến đâu thì khác biệt về tốc độ tổng thể mà người dùng cảm nhận được cũng không lớn
    Nó giống như đi giao hàng cùng một đồng nghiệp làm việc với tốc độ băng hà đang di chuyển vậy