Monty - อินเทอร์พรีเตอร์ Python แบบเบาที่รันโค้ดที่ AI สร้างขึ้นได้อย่างปลอดภัย

 (github.com/pydantic)
8 คะแนน โดย GN⁺ 2026-02-08 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • อินเทอร์พรีเตอร์ Python แบบเบาที่พัฒนาด้วย Rust ซึ่งออกแบบมาเพื่อรันโค้ดที่ AI สร้างขึ้นได้อย่างปลอดภัย โดยตัดความซับซ้อนและความหน่วงของคอนเทนเนอร์แซนด์บ็อกซ์ออกไป
  • บล็อกการเข้าถึงไฟล์ซิสเต็ม ตัวแปรสภาพแวดล้อม และเครือข่ายโดยสมบูรณ์ และอนุญาตให้เรียกได้เฉพาะฟังก์ชันภายนอกที่นักพัฒนากำหนดไว้เท่านั้น
  • ให้ เวลาเริ่มต้นต่ำกว่า 1 ไมโครวินาที และประสิทธิภาพการรันใกล้เคียงกับ CPython พร้อมรองรับการเรียกใช้งานจาก Rust·Python·JavaScript
  • สามารถ บันทึกและกู้คืนสแนปช็อตสถานะการทำงานในระดับไบต์ จึงหยุดและทำงานต่อข้ามโปรเซสได้
  • มีแผนจะใช้ขับเคลื่อนฟีเจอร์ Code Mode ของ Pydantic AI และเป็นองค์ประกอบหลักสำหรับ การรันโค้ด Python ที่ LLM เขียนขึ้นอย่างปลอดภัย

ภาพรวมของ Monty

  • Monty คือ อินเทอร์พรีเตอร์ Python เชิงทดลอง ที่เขียนด้วย Rust สำหรับรันโค้ดที่ AI สร้างขึ้นได้อย่างปลอดภัย
    • หลีกเลี่ยง ต้นทุน ความหน่วง และความซับซ้อน ของแซนด์บ็อกซ์แบบคอนเทนเนอร์ และสามารถรัน โค้ด Python ที่ LLM เขียนขึ้น ได้โดยตรง
    • เวลาเริ่มต้นอยู่ในระดับ ไม่กี่ไมโครวินาที ซึ่งเร็วกว่าคอนเทนเนอร์ทั่วไปที่ใช้เวลาหลายร้อยมิลลิวินาทีมาก
  • ความสามารถที่รองรับ
    • รองรับการรัน ไวยากรณ์บางส่วน ของ Python รวมถึง static type checking จาก type hint
    • ปิดกั้นการเข้าถึงโฮสต์อย่างสมบูรณ์ และการเรียกฟังก์ชันภายนอกทำได้เฉพาะฟังก์ชันที่นักพัฒนาอนุญาตไว้อย่างชัดเจนเท่านั้น
    • เรียกใช้งานได้จาก Rust·Python·JavaScript และมีฟีเจอร์ ติดตามและจำกัดการใช้ทรัพยากร ในตัว
    • รองรับ การเก็บ stdout/stderr, การรันโค้ดแบบอะซิงโครนัส, และ การบันทึก/กู้คืนสแนปช็อต
  • ข้อจำกัด
    • ไลบรารีมาตรฐานที่ใช้ได้มีเพียง sys, typing, asyncio, dataclasses(กำลังจะรองรับ), json(กำลังจะรองรับ)
    • ยัง ไม่รองรับการประกาศคลาสและคำสั่ง match
    • ไลบรารีจากภายนอก ยังไม่อยู่ในขอบเขตที่รองรับ
  • เป้าหมายในการออกแบบมีเพียงข้อเดียว คือ รันโค้ดที่เอเจนต์เขียนขึ้นอย่างปลอดภัย

การผสานรวมกับ Pydantic AI

  • Monty ใช้สำหรับขับเคลื่อน Code Mode ของ Pydantic AI
    • LLM จะ เขียนโค้ด Python แทนการเรียกใช้เครื่องมือโดยตรง และ Monty จะรันโค้ดนั้นอย่างปลอดภัย
    • ในตัวอย่างมีการนิยามเครื่องมือในรูปฟังก์ชัน เช่น get_weather, get_population และให้ LLM เขียนโค้ดเพื่อเรียกใช้ฟังก์ชันเหล่านี้

เปรียบเทียบกับเทคโนโลยีทางเลือก

  • แม้ Monty จะมี ความสมบูรณ์ของภาษาอย่างจำกัด แต่โดดเด่นด้าน ความปลอดภัย ความเร็ว และความเรียบง่าย
    • ความหน่วงในการเริ่มต้น 0.06ms, ไม่มีค่าใช้จ่าย, ติดตั้งง่าย, และ รองรับฟีเจอร์สแนปช็อต
  • สรุปการเปรียบเทียบกับเทคโนโลยีอื่น:
    • Docker: สภาพแวดล้อม CPython แบบสมบูรณ์ ปลอดภัยใช้ได้ แต่เริ่มต้นช้า 195ms
    • Pyodide: ทำงานบน WASM ความปลอดภัยอ่อน และเริ่มต้นช้า 2800ms
    • starlark-rust: ภาษาจำกัดมาก เร็วแต่ไม่ใช่ Python
    • บริการ sandboxing: ปลอดภัยสูง แต่มีต้นทุน ความหน่วง และการตั้งค่าที่ซับซ้อน
    • YOLO Python(exec/subprocess) : เร็วแต่ ไม่มีความปลอดภัยเลย
  • Monty มอบ สภาพแวดล้อม Python ที่ปลอดภัยสำหรับการรันโค้ด AI ผ่านฟีเจอร์ ควบคุมการเข้าถึงไฟล์, จำกัดทรัพยากร, และ หยุด/ทำงานต่อด้วยสแนปช็อต

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2026-02-08
ความคิดเห็นจาก Hacker News

  • ลองรันเวอร์ชันที่บิลด์ด้วย WebAssembly แล้ว ทำ เว็บเพลย์กราวด์ ไว้ให้ลองทดสอบได้โดยตรง
    ตอนนี้ยัง รองรับคลาสไม่ได้นะ แต่ถ้า LLM พยายามใช้คลาส มันจะเห็น error แล้วเขียนใหม่เองเป็นโค้ดที่ไม่ใช้คลาส
    มีบทความสรุปขั้นตอนการบิลด์อยู่ที่นี่

    • พูดก็ถูก แต่ ความไม่สะดวกเล็กๆ ในระดับ abstraction ต่ำ แบบนี้ ถ้าสะสมไปเรื่อยๆ จะทำให้ประสิทธิภาพในระดับสูงลดลง LLM จะเอาทรัพยากรไปใช้กับการเลี่ยงข้อจำกัดของ Python interpreter แทนที่จะโฟกัสกับการแก้ปัญหาหลัก
    • โปรเจ็กต์เจ๋งดี แต่ยังนึก กรณีการใช้งาน แบบชัดๆ ไม่ออก ว่านี่ตั้งใจไว้สำหรับโหมดเขียนโค้ดที่แทนการเรียก MCP ด้วยฟังก์ชันของ Monty หรือสำหรับ pre/post-processing ของคำถามกับการทำ CaMeL กันแน่
      จุดแข็งของ terminal agent คือการเข้าถึงเครือข่ายและไฟล์ซิสเต็ม ดังนั้นถ้าเป็นแบบนั้น sandbox container ก็ดูเป็นส่วนขยายที่เป็นธรรมชาติมากกว่า
    • พูดตรงๆ คือไม่เข้าใจว่าทำไมต้องมี โมเดลของผมเขียนโค้ดได้ดีอยู่แล้วหลายภาษา แล้วทำไมต้องจำกัดให้ใช้แค่ Python แบบจำกัดความสามารถ ด้วย?
      ทั้ง Typescript, C#, Python ก็ใช้งานได้ไม่มีปัญหา
    • คำว่า “เขียนใหม่เป็นโค้ดที่ไม่ใช้คลาส” หมายความว่า สุดท้ายแล้วมันทำได้ก็ต่อเมื่อใน ข้อมูลฝึก มีโค้ดแบบนั้นมากพอเท่านั้น โชคดีที่มีโค้ดจาก Stack Overflow เยอะ เลยอาจจะโอเค

  • ทำให้นึกถึงตอนก่อนจะย้ายไป Git ที่เคยใช้ Mercurial สมัยนั้น Git กำลังดังจนเหมือนทุกคนใช้กันหมด แต่ผมคิดว่า UX ของ Mercurial ดีกว่าเยอะ
    ตอนนี้ทุกคนเขียน exec ของ agent ด้วย Python กัน แต่ผมรู้สึกว่า TypeScript/JS เหมาะกว่า เร็วกว่า ปลอดภัยกว่า และเพราะมี type เลยมีความหนาแน่นของข้อมูลสูงกว่า แต่รอบนี้ก็คงแพ้อีกเหมือนเดิม

    • มีอยู่สามเหตุผลที่คิดว่า Python ดีกว่า JS
      1. มี standard library ที่ครบมาก (CSV, sqlite3, json ฯลฯ)
      2. โค้ดที่ LLM เขียนส่วนใหญ่รันได้ทันที ขณะที่ JS มีความไม่นิ่งหลายอย่าง เช่น การแยก Node/Deno, ความสับสนของ syntax import, และ top-level await
      3. ecosystem ด้าน data processing แข็งแรงกว่ามาก (csv/pandas ฯลฯ)
    • ผมใช้ทั้ง Python และ JS มานานเกิน 10 ปี แล้วก็ต้องปวดหัวกับ การจัดการ exception แปลกๆ หรือปัญหาเช็ก null/undefined อยู่เรื่อยๆ เพราะงั้นผมน่าจะเลือก Python ทุกวัน
    • ในเชิงประวัติศาสตร์ Python แข็งแรงมากใน ecosystem ด้านวิทยาศาสตร์และ AI เพราะมีไลบรารีอย่าง numpy, scipy, PyTorch
      ส่วนตัวผมชอบ ระบบ static type ของ TypeScript มากกว่า แต่เรื่องความเร็วหรือความปลอดภัย สองภาษานี้ก็ใกล้เคียงกัน
    • ถ้า agent รันโค้ดได้ มันก็สามารถ ประมวลผลข้อมูลเองโดยตรง ได้ ทำให้ลด context ลงได้
      Python มี ecosystem ด้านนี้ดีมาก และก็มีเครื่องมืออย่าง Pyodide หรือ ty ที่ช่วยบรรเทาปัญหาด้านความปลอดภัยได้
    • เพราะ AI นี่แหละ CPython ถึงเริ่มโดนกดดันให้มี JIT ในตัว เสียที ฝั่ง GPU ก็มี JIT ที่อิง Python DSL เยอะอยู่แล้ว ดังนั้นความต่างด้านประสิทธิภาพจริงๆ ไม่ได้มากนัก
      ตอนนี้แม้แต่ NVIDIA ก็รองรับการเขียน kernel ด้วย Python อย่างเป็นทางการแล้ว

  • โปรเจ็กต์นี้เป็นแนวทางที่น่าสนใจสำหรับ ปัญหาการ sandbox ก่อนหน้านี้เคยมีการทดลองชื่อ jsrun ที่เอา V8 มาใส่ไว้ใน Python เพื่อรัน JS อย่างปลอดภัย
    Monty เองก็น่าจะมีเป้าหมายคล้ายกัน การเริ่มจาก interpreter ที่เล็กที่สุดเหมาะกับ workload ของ AI ดี แต่การจัดการกับ ไวยากรณ์ส่วนปลายที่ยาวมากของ Python ไม่ใช่เรื่องง่าย
    จุดสำคัญคือการหา สมดุล ระหว่างการลดพื้นผิวของระบบเพื่อความปลอดภัยและความคาดเดาได้ กับการมีฟีเจอร์มากพอให้รองรับโค้ดซับซ้อนที่ LLM สร้างขึ้น

    • เป้าหมายคือทำให้ code mode หรือ การเรียกฟังก์ชันภายนอก ง่ายขึ้น ในระยะสั้น แค่รองรับ class, dataclass, datetime, json ก็น่าจะพอแล้ว
    • แต่ในสภาพแวดล้อมที่ความปลอดภัยสำคัญ ผมยังคิดว่า การแยกด้วย VM เป็นสิ่งจำเป็นอยู่ดี แนวทางแบบ Monty มีข้อจำกัดในโลกจริงเยอะพอสมควร (ความเห็นจากคนทำงานที่ E2B)

  • เป็นเรื่องคนละทางนิดหน่อย แต่ทำให้นึกถึงหนังสือของ Monty Roberts ชื่อ 『The Man Who Listens to Horses』
    เป็นเรื่องเกี่ยวกับการเรียนรู้ภาษาของสัตว์ มีลิงก์หนังสือกับวิดีโอ

  • คำอธิบายที่ว่า “รัน Python code ที่ LLM เขียนได้อย่างปลอดภัยและเร็วระดับสุดๆ” ฟังดูน่าสนใจ
    แต่ runtime ที่อิง Rust อย่าง uv ก็ยังใช้เวลาอย่างต่ำราว 10ms ดังนั้นระดับ ไมโครวินาที ดูยากอยู่
    ถึงอย่างนั้นไอเดียเรื่อง มินิอินเทอร์พรีเตอร์ที่ไม่มี standard library ก็ยังดีมาก ในมุม AI sandboxing ก็ดูสดใหม่ และไม่คิดว่าจะเห็นอะไรแบบนี้จาก Pydantic

    • Pydantic กับ FastAPI เป็นทีม Python ที่น่าสนใจที่สุดในช่วงนี้ พวกเขาออกโปรเจ็กต์ใหม่ตลอด
    • เพิ่มเติมคือ uv เป็น runtime ที่เขียนด้วย Rust

  • ผมคิดว่าการสร้าง ภาษาแบบเข้มงวดสำหรับ AI โดยเฉพาะ น่าจะดีกว่าการเอาภาษาเดิมมาใช้ต่อ
    AI เข้าใจสเปกได้ดีอยู่แล้ว จึงไม่จำเป็นต้องมีไวยากรณ์หลวมๆ แบบที่มนุษย์ใช้
    ตรงกันข้าม ภาษาที่บังคับ โครงสร้างที่แม่นยำและฟอร์แมตที่สม่ำเสมอ น่าจะเหมาะกว่า
    ผมเองก็กำลังทดลองภาษาลักษณะนี้อยู่ และมองว่าสำหรับการสร้างโค้ดโดย AI เราสามารถเรียกร้องวินัยที่สูงกว่ามนุษย์ได้

    • แต่ปัญหาคือเรื่องการเรียนรู้ของโมเดล ถ้าจะให้มันเรียนภาษาใหม่ก็ต้องใช้ ข้อมูลจำนวนมหาศาล
      การจำกัดโมเดลที่รู้ Python ดีอยู่แล้วในลักษณะ “ให้ใช้แค่ฟังก์ชันนี้” น่าจะเป็นทางเลือกที่สมจริงกว่ามาก

  • ประเด็นเรื่อง “ความไม่สะดวกเล็กๆ (papercut)” ที่ jstanley พูดถึงนั้นถูกต้อง แต่ในอีกด้านหนึ่ง ถ้าจะรันโค้ดที่ AI สร้างในสเกลใหญ่ ความเสี่ยงด้านความปลอดภัย ก็ใหญ่กว่ามาก
    การเปิดให้ CPython เต็มรูปแบบเข้าถึงฟีเจอร์อย่าง file I/O, network, subprocess เป็นเรื่องอันตราย
    แต่ข้อจำกัดเรื่องคลาสก็ดูแปลก เพราะไม่ได้เกี่ยวกับความปลอดภัย แค่ทำให้โค้ดดูเลอะเทอะขึ้นเท่านั้น
    น่าจะเป็นแนวทางแบบ “เริ่มจากฟีเจอร์ขั้นต่ำก่อนแล้วค่อยขยายทีละน้อย” มากกว่า

    • ใช่ ข้อจำกัดเรื่องคลาส ไม่ได้มีไว้เพื่อความปลอดภัย แต่แค่ยังไม่ได้ implement เท่านั้น

  • แทนที่จะ พยายามเลียนแบบความสามารถทั้งหมดของ CPython การสร้าง interpreter ขั้นต่ำที่มีเฉพาะสิ่งจำเป็นสำหรับโค้ดของ AI เป็นแนวทางที่น่าสนใจ
    runtime แบบเต็มมีพื้นผิวการโจมตีกว้างเกินไป แต่ subset ที่จำกัด ปลอดภัยกว่า
    กลยุทธ์ที่ใช้ feedback จาก error เพื่อให้ LLM ปรับตัวกับไวยากรณ์ที่จำกัดได้เองก็ดูสมจริง
    ในกรณีใช้งานเครื่องมือส่วนใหญ่ เราไม่ได้ต้องการ metaclass หรือ dynamic import อยู่แล้ว

  • เป็นคำถามง่ายๆ แต่ใช้ seccomp จำกัด system call ไม่ได้หรือ?
    ถ้าอยากบล็อกการเข้าถึงไฟล์ ก็แค่บล็อก syscall ที่เกี่ยวข้อง แบบนั้นแล้วทำไมยังต้องมี interpreter แยกอีก?

    • โปรเจ็กต์อย่าง bvisor ก็กำลังไปในทิศทางนั้น
    • เป็นแนวทางที่ถูกต้อง แต่ถ้า runtime พื้นฐานทรงพลังเกินไป ก็จะมีช่องทางหลบเลี่ยงได้เยอะ
      ถ้าเริ่มจาก runtime ที่เรียบง่ายอย่างยิ่ง ตั้งแต่ต้น พื้นผิวการโจมตีก็จะเล็กลงและปลอดภัยกว่ามาก

  • ตัวโปรเจ็กต์เองก็ดูสมเหตุสมผล แต่พอพูดว่าเป็น “เครื่องมือความเร็วสูงพิเศษสำหรับ AI” ก็อดขำไม่ได้
    เพราะ ความเร็วในการคิดของ AI ช้ามากอยู่แล้ว ต่อให้รันโค้ดเร็วขึ้นแค่ไหน ความเร็วโดยรวมที่รู้สึกได้ก็แทบไม่ต่าง
    เหมือนออกไปส่งของกับเพื่อนร่วมงานที่ทำงานด้วยความเร็วระดับ ธารน้ำแข็งเคลื่อนตัว อยู่ข้างๆ