Docker Sandboxes: แซนด์บ็อกซ์แบบใช้แล้วทิ้งสำหรับ AI Agent น่าใช้แค่ไหน

Docker Sandboxes คือ environment แบบ disposable ที่รันอยู่ใน microVM แยกจากเครื่องหลัก ให้ AI coding agent เช่น Claude Code, Copilot CLI, Gemini CLI รันคำสั่งได้โดยไม่แตะไฟล์ระบบจริง จุดเด่นคือ agent สามารถทำงานแบบ “YOLO mode” ได้ (sbx run --dangerously-skip-permissions) เพราะ isolation แข็งระดับ microVM ไม่ใช่แค่ container namespace เหมาะกับทีมที่ต้องปล่อย coding agent รันงานยาวโดยไม่มีคนคอย approve ทุก step เช่น long-running task, autonomous PR, หรือ multi-agent workflow ที่ต้องแยก environment ให้เด็ดขาด

หน้าตาจริงของ Docker Sandboxes

ตัว CLI ชื่อ sbx — ติดตั้งบน macOS ผ่าน brew install docker/tap/sbx, Windows ใช้ winget install Docker.sbx, Linux ใช้ apt package docker-sbx และไม่ต้องมี Docker Desktop ด้วยซ้ำ

เวลาสั่งรัน agent ในกล่อง ทำแค่ sbx run <command> — sandbox จะสร้าง microVM ใหม่ mount แค่ project workspace ที่เลือก แล้ว agent ก็เริ่มทำงานได้เลย ไม่ต้อง config network/filesystem ไปทีละบรรทัด

โฟกัสของ tool คือ spin up-teardown เป็นรอบๆ ไม่ได้ออกแบบมาให้รันยาวแบบ production service เหมือน container orchestration ทั่วไป

คืนที่ปล่อยให้ AI agent รันโค้ดเองแล้วนอนไม่หลับ

จำได้แม่นเลยคืนที่ปล่อย coding agent รันคำสั่งแก้ bug บนเครื่อง dev ตัวเอง แล้วไปนอนรอผลตอนเช้า

ตื่นมาเจอ terminal ค้าง เครื่องร้อนจี๋ agent วน loop รันคำสั่งซ้ำจน CPU กิน resource จนแทบต้อง force restart

เช็คย้อนหลังพบว่ามันไปแก้ไฟล์ config ผิดตัว แล้วดันมี .env ที่มี API key อยู่ในโฟลเดอร์เดียวกันที่ agent เข้าถึงได้ตรงๆ

โชคดีที่ไม่มีอะไรหลุดออกไปจริง แต่นั่นแหละคือจุดเปลี่ยน — รู้เลยว่าปล่อย agent รันโค้ดบนเครื่องจริงแบบไม่มีกำแพงกั้นมันเสี่ยงเกินไป

ปัญหาคือ agent ทำงานเร็วและรันคำสั่งเองแบบไม่หยุดรอ human review ทุกจุด ถ้าไม่มี isolation ที่แยกขาดจากเครื่องจริง โอกาสพังมีสูง

นี่แหละที่ทำให้แนวคิด disposable sandbox อย่าง Docker Sandboxes น่าสนใจ — ให้ agent รันเต็มที่ในกล่องที่ตายแล้วทิ้งได้ ไม่ต้องมากังวลว่าจะลามมาเครื่องจริง

Docker Sandboxes ยืนอยู่ตรงไหนในจักรวาล Docker

ถ้านึกภาพ Docker ที่ผ่านมา จะเห็น Docker Desktop สำหรับ dev รัน container บนเครื่องตัวเอง, Docker Compose ไว้ผูกหลาย service เข้าด้วยกัน, Docker Build Cloud ไว้ build image เร็วขึ้นบน cloud, และ Docker Hub เป็นที่เก็บ image

ทั้งหมดนี้ออกแบบมาให้ “คนหรือ pipeline” เป็นคนสั่ง container แบบมี control ชัดเจน — รู้ว่าจะรันอะไร รันตอนไหน

แต่ AI agent ไม่ทำงานแบบนั้น มันตัดสินใจเองว่าจะรันคำสั่งอะไรต่อ ไม่รอ human approve ทุก step และอาจต้อง spin container ใหม่ถี่มากในเวลาสั้นๆ

Docker Sandboxes เลยไม่ใช่ container ปกติที่ใช้ยาว แต่รันในรูป microVM ที่แยกจากเครื่อง host จริงเป็นชั้นแข็งกว่า namespace ธรรมดา เพราะ “ผู้ใช้งาน” ตัวจริงคือ agent ที่ไม่มีใครคอยเบรกทันที

จากคอนเทนเนอร์ที่ต้องคุมเองสู่แซนด์บ็อกซ์พร้อมทิ้ง

วิธีเดิมคือ dev สั่ง docker run เอง ต้อง config network isolation, permission, แล้วก็ต้องจำ cleanup เองหลังใช้เสร็จ ถ้าลืมลบ container ค้างไว้เยอะๆ เครื่องก็รก

Docker Sandboxes เปลี่ยนงานพวกนี้ให้เป็นอัตโนมัติ ตั้งค่า isolation ให้ตั้งแต่สร้าง แล้วพอ agent ใช้งานเสร็จก็ทิ้งเองได้เลย ไม่ต้องมานั่งไล่ลบทีหลัง

พูดง่ายๆ คือ concept เดิมของ container ยังอยู่ครบ แค่เปลี่ยน default ให้เหมาะกับโลกที่ agent เป็นคนสั่งงานแทนคน

ใช้งานจริงแล้วช่วยตรงไหนบ้าง

microVM spin-up เร็วกว่า VM เต็มรูป พอ agent ต้อง test โค้ดที่เพิ่ง generate สด ๆ ไม่ต้องรอ provision เครื่องใหม่ทั้งลูก

Isolation ก็สำคัญไม่แพ้กัน เวลา agent รันแบบ --dangerously-skip-permissions ไม่ต้องรอ approve ทีละคำสั่ง microVM boundary กันไม่ให้หลุดไปแตะไฟล์หรือ credential นอกกรอบที่ mount ไว้

อีกจุดที่สำคัญคือ credential isolation — agent เห็นเฉพาะที่ตั้งใจส่งเข้าไป ไม่ได้อ่านไฟล์ .env ที่หลบอยู่ในโฟลเดอร์อื่นของเครื่องหลัก

ที่เห็นชัดตอนงานเยอะคือรันหลาย sandbox พร้อมกัน สั่ง agent หลายตัว (Claude Code, Codex, Gemini CLI ฯลฯ) ทำงานคู่ขนานแยก microVM กันไปเลย ไม่ชนกันเอง

รวมแล้วสี่จุดนี้ตอบโจทย์ pattern การทำงานของ agent ที่รันสั้น ถี่ และไม่มีคนนั่งเฝ้าตลอดเวลาได้ตรงกว่า container แบบเดิมที่ออกแบบมาให้คนคุม

เทียบชั้นกับ E2B, Modal Sandboxes และ Daytona

จุดต่างที่ชัดสุดคือ Docker Sandboxes เป็น local-first — รัน microVM บนเครื่อง dev เอง ไม่ต้องส่ง workspace ขึ้น cloud ของใครก่อน กับที่รองรับ coding agent ตัวหลักๆ ให้ตั้งแต่ต้น ไม่ต้อง wrap SDK เพิ่ม ส่วน SaaS สาย E2B/Modal/Daytona เหมาะกับทีมที่อยากรัน sandbox แบบ multi-tenant ฝั่ง cloud อยู่แล้ว

สิ่งที่ได้มาคุ้มไหมกับสิ่งที่ต้องเผื่อไว้

ต้นทุนแฝงที่โผล่มาตอนใช้จริง

ตัว sbx โหลดฟรี ฟังดูไม่มีอะไรเสีย แต่พอเอาเข้าทีมจริงจะเจอต้นทุนที่ไม่ขึ้นบิล Docker ตรงๆ

อย่างแรกคือ RAM/CPU ของ microVM — รันหลาย sandbox พร้อมกันบนเครื่อง dev ตัวเดียวกินทรัพยากรเยอะกว่า container ธรรมดา ทีมที่ใช้ MacBook รุ่นเล็กหรือเครื่อง dev เก่าต้องเผื่อไว้

อย่างที่สองคือ storage ของ image และ workspace ที่ sandbox แต่ละตัวเก็บไว้ ถ้าไม่มีระบบ teardown จริงจัง disk จะเต็มไว

อย่างที่สามคือ Docker Business/Team tier ถ้าอยากใช้ AI Governance คุมทั้งองค์กร ($15–24 ต่อ user/เดือน ตาม tier) — ไม่ใช่ค่า sbx โดยตรง แต่ถ้าอยากบังคับ policy รวมศูนย์เลี่ยงไม่ได้

สุดท้ายคือเวลาแรงงานทีมที่ต้องปรับ workflow เดิมให้ agent เข้าไปทำงานในกล่องแทนเครื่อง host — ต้นทุนนี้ไม่ขึ้นบิล แต่กระทบ timeline จริง

สนามที่ใช่และสนามที่ยังไม่ต้องรีบเข้า

ทางเลือกของทีมที่กำลังจะปล่อย AI agent ให้ทำงานเอง

ก่อนจะทุ่มเวลาผูก infra ใหม่ ลองเริ่มจาก workflow ที่ agent ต้องรันโค้ด user-generated บ่อยที่สุดก่อน เช่น code review bot หรือ agent ที่แก้ PR อัตโนมัติ — เพราะนั่นคือจุดที่ isolation คุ้มค่าที่สุด ไม่ใช่ทุก pipeline ที่ต้องการ sandbox แยก

คำถามที่ทีมควรถามตัวเองก่อนตัดสินใจ: agent ของเรารันโค้ดที่มาจากไหน (internal เขียนเอง หรือ generate แบบ unpredictable), ถ้า agent หลุดออกจากกล่องมาได้ผลกระทบแค่ไหน, และเครื่อง dev ของทีมมี RAM/CPU เผื่อ microVM หลายตัวพร้อมกันหรือเปล่า

ถ้าคำตอบคือ “agent เขียนโค้ดเองแบบคาดเดาไม่ได้ และผลกระทบสูงถ้าพลาด” นั่นคือสัญญาณให้เริ่มทดลอง Docker Sandboxes จริงจัง ไม่ใช่แค่ทางเลือกเสริม