หาก AI agent ของคุณสามารถเขียนโค้ดได้ มันก็สามารถเขียนโค้ดที่ไม่ดีได้ หากมันสามารถเรียกใช้เครื่องมือได้ มันก็สามารถเรียกใช้เครื่องมือผิดตัวด้วยอาร์กิวเมนต์ที่ผิดพลาดได้ วิธีแก้ไขไม่ใช่การใช้ prompt ที่ฉลาดขึ้น แต่เป็นการสร้างขอบเขตการแยก (isolation boundary) ระหว่างผลลัพธ์ของโมเดลกับเครื่องจักรที่รันมัน CubeSandbox เป็นหนึ่งในระบบที่สร้างขึ้นมาเพื่อขอบเขตนั้นโดยเฉพาะ และคุ้มค่าที่จะทำความเข้าใจว่ามันทำอะไร แตกต่างจากแนวทางอื่นอย่างไร และจะเข้าไปอยู่ตรงไหนเมื่อ agent ของคุณเริ่มเข้าถึง API และข้อมูลจริง
สรุปสั้นๆ (TL;DR)
CubeSandbox คือบริการ sandbox แบบโอเพนซอร์สที่แยกด้วยฮาร์ดแวร์จาก Tencent Cloud สำหรับรันโค้ด AI agent แต่ละ sandbox จะได้รับ guest OS kernel ของตัวเองผ่าน KVM, เริ่มทำงานได้ในเวลาประมาณ 60 มิลลิวินาที และใช้หน่วยความจำโอเวอร์เฮดน้อยกว่า 5MB มันได้รับอนุญาตภายใต้ Apache 2.0 และสามารถใช้งานร่วมกับ E2B SDK ได้โดยตรง
บทนำ
ระบบ Agentic กำลังเขียนและรันโค้ดในการทำงานจริง Coding agent สร้างสคริปต์ Python แล้วรันมัน Research agent ดึงข้อมูลจากหน้าเว็บ, แยกวิเคราะห์ และส่งผลลัพธ์ไปยังขั้นตอนถัดไป Data agent โหลดไฟล์ CSV และรันการแปลงข้อมูลที่โมเดลตัดสินใจในขณะรันไทม์ ไม่มีโค้ดใดได้รับการตรวจสอบโดยมนุษย์ก่อนที่จะรัน นั่นคือปัญหาหลักที่ agent sandboxing เข้ามาแก้ไข: คุณต้องรันคำสั่งที่ไม่น่าเชื่อถือที่สร้างโดยโมเดล โดยไม่ให้มันเข้าถึงโฮสต์ ไฟล์ระบบ ข้อมูลประจำตัว หรือเครือข่ายของคุณ
เรื่องนี้สำคัญยิ่งขึ้นเมื่อ agent มีความเป็นอิสระมากขึ้น โมเดลที่ผิดพลาดเกี่ยวกับ SQL query อาจน่ารำคาญ โมเดลที่ผิดพลาดเกี่ยวกับ rm -rf หรือทำตามคำสั่งที่ถูกแทรกเข้ามาในหน้าเว็บที่ถูก scraping คือเหตุการณ์ด้านความปลอดภัย Sandboxing ขีดเส้นแบ่งที่ชัดเจน: agent สามารถทำอะไรก็ได้ในสภาพแวดล้อมที่แยกออกและใช้แล้วทิ้ง และไม่มีสิ่งใดที่มันทำจะรั่วไหลออกไป
มีปัญหาที่สองที่เงียบกว่า Agent ไม่ได้แค่รันโค้ด แต่ยังเรียกใช้ API และเครื่องมือต่างๆ ด้วย ก่อนที่คุณจะเชื่อถือ agent ให้เข้าถึง Payment API หรือบริการภายในของคุณจากภายใน sandbox คุณต้องแน่ใจว่า API เหล่านั้นทำงานได้อย่างถูกต้อง และ agent เรียกใช้มันในแบบที่คุณคาดหวัง นั่นคือจุดที่เครื่องมือ API มีความสำคัญควบคู่ไปกับการแยกสภาพแวดล้อมขณะรันไทม์ (runtime isolation) แพลตฟอร์มอย่าง Apidog ช่วยให้คุณสามารถ mock และทดสอบ endpoint ที่ agent จะเรียกใช้ได้ เพื่อให้คุณตรวจสอบความถูกต้องของสัญญา (contract) ก่อนที่ระบบอัตโนมัติจะเริ่มใช้งานมันในการรันแบบ sandboxed หากคุณกำลังพิจารณาสถาปัตยกรรม agent คู่มือของเราเกี่ยวกับ สถาปัตยกรรม AI แบบ Agentic จะครอบคลุมถึงวิธีที่ชั้นการทำงานและการใช้เครื่องมือเหล่านี้ทำงานร่วมกัน
ส่วนที่เหลือของบทความนี้จะอธิบายว่า CubeSandbox คืออะไร ทำไม agent ถึงต้องมี sandbox, รูปแบบการแยก (isolation models) แตกต่างกันอย่างไร และสิ่งนี้เชื่อมโยงกับการทดสอบ API ที่ agent ของคุณต้องพึ่งพาอย่างไร
CubeSandbox คืออะไร?
CubeSandbox เป็นระบบ security sandbox สำหรับรันโค้ด AI agent ซึ่ง Tencent Cloud ได้เปิดเป็นโอเพนซอร์สภายใต้สัญญาอนุญาต Apache 2.0 ในเดือนเมษายน 2026 สโลแกนบน GitHub ของมันอธิบายไว้อย่างชัดเจนว่า: “Instant, Concurrent, Secure & Lightweight Sandbox for AI Agents.” (Sandbox ที่รวดเร็ว พร้อมกัน ปลอดภัย และมีน้ำหนักเบาสำหรับ AI Agent) มันไม่ใช่แค่ SDK แต่เป็น stack ของ sandbox-as-a-service เต็มรูปแบบ ซึ่งเขียนด้วย Rust เป็นส่วนใหญ่ และคุณสามารถติดตั้งใช้งานเองได้
สถาปัตยกรรมนี้สร้างขึ้นบน RustVMM และ KVM ซึ่งเป็นชั้นการจำลองเสมือนของ Linux kernel เดียวกันกับที่ cloud hypervisor จำนวนมากใช้ ตามเอกสารของโปรเจกต์และประกาศอย่างเป็นทางการ ระบบแบ่งออกเป็นหลายองค์ประกอบดังนี้:
- CubeAPI: เกตเวย์ REST ที่จำลองอินเทอร์เฟซ sandbox ของ E2B
- CubeMaster: ตัวจัดระเบียบคลัสเตอร์ที่จัดกำหนดการ sandboxes ทั่วทั้งโหนด
- CubeHypervisor และ CubeShim: ชั้นการจำลองเสมือน KVM ที่บูตและจัดการ microVM แต่ละตัว
- Cubelet และ CubeProxy: agent ระดับโหนดที่รันและกำหนดเส้นทางไปยัง sandboxes
- CubeVS: ชั้นเครือข่ายที่ขับเคลื่อนด้วย eBPF ซึ่งบังคับใช้การแยกเครือข่ายระหว่าง sandbox ในระดับเคอร์เนล
คุณสมบัติเด่นคือแต่ละ sandbox จะได้รับ guest OS kernel เฉพาะของตัวเอง นั่นเป็นรูปแบบการแยก (isolation model) ที่แตกต่างและแข็งแกร่งกว่าคอนเทนเนอร์ ซึ่งแชร์โฮสต์เคอร์เนล ตัวเลขที่ Tencent เผยแพร่ระบุว่าการ cold start อยู่ที่ประมาณ 60 มิลลิวินาทีเมื่อมีการทำงานพร้อมกันครั้งเดียว (เฉลี่ย 67 มิลลิวินาที โดย P95 อยู่ที่ประมาณ 90 มิลลิวินาทีภายใต้การสร้างพร้อมกัน 50 ครั้ง), ใช้หน่วยความจำโอเวอร์เฮดน้อยกว่า 5MB ต่ออินสแตนซ์ และสามารถรัน sandboxes ได้หลายพันตัวบนโฮสต์ขนาดใหญ่เพียงเครื่องเดียว เอกสารแถลงข่าวอ้างว่าเซิร์ฟเวอร์ 96-vCPU รองรับ sandboxes ที่ทำงานพร้อมกันได้มากกว่า 2,000 ตัว Tencent ระบุว่า CubeSandbox ได้ถูกใช้งานในขนาดใหญ่ภายในโครงสร้างพื้นฐานของตนเอง และ MiniMax ได้ใช้มันสำหรับการฝึกอบรมการเรียนรู้แบบเสริมแรง (reinforcement-learning training) แบบ agentic ขนาดใหญ่ในสภาพแวดล้อมที่หลากหลาย
คุณสมบัติขั้นสูงบางอย่าง เช่น การย้อนกลับ snapshot ระดับเหตุการณ์สำหรับการทำ checkpoint และการคืนค่าสถานะ sandbox ยังอยู่ในระหว่างการพัฒนา พิจารณาสิ่งที่คาดการณ์ไว้ในอนาคตเป็นแผนงาน ไม่ใช่การรับประกันที่จัดส่งแล้ว และตรวจสอบที่เก็บข้อมูลสำหรับสถานะปัจจุบัน ระเบียบวิธีมาตรฐานสาธารณะนอกเหนือจากตัวเลขของผู้จำหน่ายนั้นมีจำกัด ดังนั้นควรตรวจสอบข้อเรียกร้องด้านประสิทธิภาพกับปริมาณงานของคุณเอง
สำหรับรายละเอียดที่ถูกต้อง แหล่งข้อมูลที่เป็นทางการคือ ที่เก็บ GitHub ของ CubeSandbox และ เว็บไซต์เอกสารอย่างเป็นทางการ
ทำไม AI agent ถึงต้องมี sandbox
มันช่วยให้เข้าใจภัยคุกคามได้อย่างเป็นรูปธรรม เพราะคำว่า "ความปลอดภัย" กว้างเกินไปที่จะใช้เป็นแนวทางในการออกแบบ มีสามโหมดความล้มเหลวที่ผลักดันให้ทีมงานต้องใช้ sandboxing
โค้ดที่สร้างขึ้นซึ่งมีความเสี่ยง โมเดลสร้างโค้ดที่เชื่อว่าถูกต้อง บางครั้งมันก็ไม่ใช่ มันอาจลบไดเรกทอรีผิดพลาด, ใช้หน่วยความจำจนหมดในการวนซ้ำไม่รู้จบ หรือเขียนไฟล์ในตำแหน่งที่ไม่ควร ไม่มีสิ่งใดที่ประสงค์ร้าย; มันแค่ผิดพลาด และโค้ดที่ผิดพลาดพร้อมการเข้าถึงโฮสต์นั้นอันตราย Agent ไม่มีแนวคิดเรื่องขอบเขตความเสียหาย (blast radius) เว้นแต่คุณจะกำหนดให้
การเรียกใช้เครื่องมือที่ไม่น่าเชื่อถือ Agent เรียกใช้เครื่องมือและ API ตามที่โมเดลตัดสินใจในขณะรันไทม์ หากโมเดลถูกชี้นำโดย prompt injection ที่ซ่อนอยู่ในเอกสาร หน้าเว็บ หรือการตอบสนองของเครื่องมือ มันอาจเรียกใช้เครื่องมือที่ก่อให้เกิดความเสียหาย, ส่งอาร์กิวเมนต์ที่ผู้โจมตีควบคุม หรือเชื่อมโยงการเรียกใช้ในแบบที่คุณไม่เคยตั้งใจไว้ โมเดลไม่ใช่ผู้กระทำการที่น่าเชื่อถือในที่นี้; มันเป็นเพียงตัวแปลข้อความใดๆ ที่เข้าถึงหน้าต่างบริบทของมัน เราเจาะลึกเรื่องนี้ในบทความของเราเกี่ยวกับ AI agent ในฐานะผู้บริโภค API รายใหม่ ซึ่งครอบคลุมถึงเหตุผลที่สมมติฐานความเชื่อถือ API แบบดั้งเดิมใช้ไม่ได้กับผู้เรียกใช้แบบอัตโนมัติ
การนำข้อมูลออก นี่คือสิ่งที่คนมักประมาท Agent ที่มีสิทธิ์เข้าถึงเครือข่ายและข้อมูลลับสามารถถูกเปลี่ยนเป็นช่องทางในการนำข้อมูลออกได้ คำสั่งที่ถูกวางยาบอกให้ agent อ่านตัวแปรสภาพแวดล้อมที่เก็บ API key และ POST ไปยัง endpoint ภายนอก หากไม่มีการกรองขาออก (egress filtering) และการแยกข้อมูลประจำตัว (credential isolation) ขอบเขต sandbox จะไม่มีความหมายเพราะข้อมูลจะหลุดออกไปทางประตูหน้า นี่คือเหตุผลที่ CubeSandbox จับคู่การแยกในระดับเคอร์เนลเข้ากับการกรองขาออกที่ใช้ eBPF ผ่าน CubeVS; การแยกกระบวนการไม่เพียงพอหากเครือข่ายเปิดกว้าง
จุดร่วมคือ: คุณไม่สามารถสันนิษฐานได้ว่า agent จะประพฤติตัวดี เพราะพฤติกรรมของ agent ถูกควบคุมบางส่วนโดยข้อมูลที่ไม่น่าเชื่อถือที่มันได้รับเข้ามา Sandbox ช่วยให้คุณหยุดคิดว่าโมเดลน่าเชื่อถือหรือไม่ และเริ่มคิดเกี่ยวกับขอบเขตที่คงอยู่ไม่ว่าจะเกิดอะไรขึ้น สำหรับมุมมองเชิงปฏิบัติในการตรวจสอบพฤติกรรมเหล่านี้ก่อนที่จะนำไปใช้งานจริง โปรดดู วิธีการทดสอบ AI agent ที่เรียกใช้ API
Sandboxes ของ agent ทำงานอย่างไร: รูปแบบการแยก
ไม่ใช่ทุก sandbox ที่แยกในลักษณะเดียวกัน และความแตกต่างนั้นสำคัญทั้งต่อความปลอดภัยและประสิทธิภาพ มีสี่แนวทางหลักที่คุณจะเห็นในระบบนิเวศของ agent
การแยกในระดับกระบวนการ (Process-level isolation) รันโค้ดเป็นกระบวนการ OS ที่ถูกจำกัดสิทธิ์ด้วย seccomp filters, ความสามารถที่ถูกลดลง, namespaces และ cgroups นี่คือตัวเลือกที่เบาที่สุดและอ่อนแอที่สุด มันแชร์โฮสต์เคอร์เนล ดังนั้นการโจมตีเคอร์เนลจึงหมายถึงการถูกโจมตีโฮสต์ ใช้ได้ดีสำหรับโค้ดที่คุณเชื่อถือเป็นส่วนใหญ่; อ่อนแอสำหรับผลลัพธ์ของโมเดลที่ไม่จำเพาะเจาะจง
คอนเทนเนอร์ คอนเทนเนอร์สไตล์ Docker เพิ่ม namespacing และการจำกัดทรัพยากร และเป็นที่คุ้นเคยในการปฏิบัติงาน แต่คอนเทนเนอร์แชร์โฮสต์เคอร์เนลโดยการออกแบบ ช่องโหว่ Container escape เป็นประเภทของบั๊กที่เกิดขึ้นจริงและซ้ำซาก และ "โค้ดที่ไม่น่าเชื่อถือในคอนเทนเนอร์ที่แชร์เคอร์เนล" เป็นจุดอ่อนที่รู้จักกันดี หลายทีมเริ่มต้นที่นี่เพราะมันง่าย จากนั้นก็ชนกับขีดจำกัดของการแยก
MicroVMs microVM จะบูต guest kernel ที่มีขนาดเล็กที่สุดภายใน virtualization ฮาร์ดแวร์ (KVM) โค้ดของ agent จะรันกับเคอร์เนลของตัวเอง ดังนั้นการโจมตีในระดับเคอร์เนลจะถูกจำกัดอยู่ใน VM ที่ใช้แล้วทิ้ง ไม่ใช่โฮสต์ Firecracker ทำให้โมเดลนี้เป็นที่นิยมสำหรับเวิร์คโหลดแบบ serverless และ CubeSandbox ก็อยู่ในหมวดหมู่นี้ โดยใช้ RustVMM และ KVM พร้อม guest kernel สำหรับแต่ละ sandbox ข้อแลกเปลี่ยนในอดีตคือเวลาเริ่มต้น; microVMs ใช้เวลาบูตช้ากว่าคอนเทนเนอร์ การใช้งานสมัยใหม่แก้ปัญหานั้นด้วยการทำ snapshotting และการจัดสรรทรัพยากรล่วงหน้า ซึ่งเป็นวิธีที่ CubeSandbox รายงานเวลาเริ่มต้นที่ต่ำกว่า 100 มิลลิวินาที
Application kernels gVisor ใช้เส้นทางที่แตกต่างออกไป: มันดักจับการเรียกใช้ระบบ (system calls) ใน userspace และนำอินเทอร์เฟซที่เหมือน Linux มาใช้เอง ดังนั้นเวิร์คโหลดจึงไม่เคยสื่อสารโดยตรงกับโฮสต์เคอร์เนล มันเป็นชั้นการแยกที่แข็งแกร่งโดยไม่ต้องใช้ VM เต็มรูปแบบ ซึ่งมีข้อแลกเปลี่ยนบางอย่างเกี่ยวกับการเข้ากันได้ของ syscall และประสิทธิภาพ
นี่คือวิธีที่แนวทางต่างๆ เปรียบเทียบกันในมิติที่สำคัญสำหรับ agent:
| แนวทาง | ความแข็งแกร่งของการแยก | Cold start | โอเวอร์เฮด | การแชร์เคอร์เนล | ตัวอย่าง |
|---|---|---|---|---|---|
| กระบวนการ + seccomp | ต่ำ | ทันที | น้อยที่สุด | แชร์โฮสต์เคอร์เนล | กระบวนการย่อยที่ถูกจำกัดสิทธิ์, nsjail |
| คอนเทนเนอร์ | ปานกลาง | ~10 มิลลิวินาที | ต่ำ | แชร์โฮสต์เคอร์เนล | Docker, containerd |
| MicroVM | สูง | ~50–150 มิลลิวินาที | ต่ำ–ปานกลาง | เคอร์เนลแขกโดยเฉพาะ | CubeSandbox, Firecracker |
| Application kernel | สูง | ~10 มิลลิวินาที | ต่ำ–ปานกลาง | ถูกดักจับใน userspace | gVisor |
| Hosted sandbox API | สูง (มีการจัดการ) | แตกต่างกันไป | จัดการให้คุณ | จัดการให้คุณ | E2B, บริการแบบโฮสต์ |
ไม่มีผู้ชนะเพียงหนึ่งเดียว การตัดสินใจที่ถูกต้องขึ้นอยู่กับว่าคุณเชื่อถือโค้ดมากแค่ไหน, คุณต้องการ cold start ที่รวดเร็วแค่ไหน, คุณสามารถรัน KVM ได้หรือไม่ และคุณต้องการดำเนินการโครงสร้างพื้นฐานด้วยตัวเองหรือใช้งานเป็นบริการ
CubeSandbox ในภาพรวม
การวางตำแหน่งของ CubeSandbox มีความเฉพาะเจาะจง: การแยกในระดับฮาร์ดแวร์ (hardware-level isolation) พร้อมการ cold start ที่เร็วพอจนรู้สึกเหมือนคอนเทนเนอร์ ซึ่งถูกใช้งานในลักษณะที่คุณรันเองมากกว่าเป็นบริการที่คุณเช่า นั่นทำให้มันถูกเปรียบเทียบในเชิงแนวคิดโดยตรงกับสามจุดอ้างอิง
เทียบกับคอนเทนเนอร์ คอนเทนเนอร์แชร์โฮสต์เคอร์เนล; CubeSandbox ให้เคอร์เนลของตัวเองแก่แต่ละ sandbox สำหรับโค้ดที่สร้างโดย agent แบบไม่จำเพาะเจาะจง นั่นคือข้อโต้แย้งด้านความปลอดภัย ค่าใช้จ่ายคือคุณต้องมีโฮสต์ Linux x86_64 ที่เปิดใช้งาน KVM (เซิร์ฟเวอร์ bare-metal, Cloud VM ที่รองรับ nested virtualization หรือ WSL 2 สำหรับงานในเครื่อง) หากแพลตฟอร์มของคุณไม่สามารถเปิดเผย KVM ได้ การแยกแบบ microVM จะไม่สามารถใช้งานได้ และแนวทาง userspace เช่น gVisor หรือ hosted API อาจเหมาะสมกว่า
เทียบกับ Firecracker Firecracker เป็น microVM ที่รู้จักกันดีสำหรับ serverless และเป็น building block ในตัวเอง ไม่ใช่ผลิตภัณฑ์ agent-sandbox CubeSandbox ก็ใช้ KVM/RustVMM เป็นพื้นฐาน แต่มาพร้อมกับองค์ประกอบที่สูงขึ้นใน stack: ตัวจัดระเบียบ (orchestrator), เกตเวย์ API ที่เข้ากันได้กับ E2B, และการแยกเครือข่าย eBPF ดังนั้นคุณกำลังใช้งานบริการ agent sandbox แทนที่จะต้องประกอบมันขึ้นมาเอง หากคุณต้องการพื้นฐาน, Firecracker หากคุณต้องการบริการ sandbox ที่มี API ที่เหมาะสมกับ agent, CubeSandbox ก็มุ่งเป้าไปที่สิ่งนั้น
เทียบกับ E2B และ hosted sandboxes E2B ให้บริการ sandbox ที่แยกออกจากกันเป็นบริการที่มีการจัดการ; คุณเรียกใช้ API และโครงสร้างพื้นฐานเป็นปัญหาของคนอื่น การเลือกออกแบบที่โดดเด่นของ CubeSandbox คือความเข้ากันได้กับ E2B SDK เอกสารอธิบายว่ามันเป็นการแทนที่แบบ drop-in: ชี้ E2B_API_URL ไปยังอินสแตนซ์ Cube ที่คุณโฮสต์เอง และโค้ดที่มีอยู่ก็ยังคงทำงานได้ นั่นทำให้การตัดสินใจที่แท้จริงไม่ใช่เรื่อง "sandbox ตัวไหน" แต่เป็น "บริการที่มีการจัดการเทียบกับโครงสร้างพื้นฐานที่โฮสต์เอง" โดยมีเรื่อง data residency, ต้นทุนเมื่อขยายขนาด และความเป็นเจ้าของในการดำเนินงานเป็นปัจจัยในการตัดสินใจ นอกจากนี้ยังรองรับ OpenAI Python SDK โดยกำเนิดตามประกาศของ Tencent
สรุปอย่างตรงไปตรงมา: CubeSandbox เป็นผู้เล่นที่น่าเชื่อถือในพื้นที่ agent-sandbox ด้วยแนวคิดที่ชัดเจน (การแยกที่แข็งแกร่ง, การเริ่มต้นที่รวดเร็ว, โฮสต์เอง, เข้ากันได้กับ E2B) อย่างไรก็ตาม มันยังใหม่และส่วนใหญ่ได้รับการบันทึกโดยผู้จำหน่าย ดังนั้นข้อมูลมาตรฐานอิสระจึงมีจำกัด ควรทดลองใช้กับปริมาณงานของคุณเอง และวัด cold start, ความหนาแน่น และพฤติกรรมการแยก ก่อนที่จะตัดสินใจใช้งานจริง
สิ่งนี้เชื่อมโยงกับการทดสอบ API และเครื่องมือที่ agent ของคุณเรียกใช้อย่างไร
Runtime isolation ตอบคำถามว่า "จะเกิดอะไรขึ้นถ้าโค้ดไม่ดี" มันไม่ได้ตอบคำถามว่า "จะเกิดอะไรขึ้นถ้า API ที่ agent เรียกใช้นั้นไม่ดี หรือ agent เรียกใช้ผิดพลาด" นั่นเป็นปัญหาที่แตกต่างกัน และคุณจำเป็นต้องครอบคลุมทั้งสองอย่าง
ลองนึกภาพ agent ที่อยู่ใน sandbox ซึ่งจองการเดินทาง โค้ดทำงานได้อย่างปลอดภัยภายใน CubeSandbox แต่ agent ยังคงเรียกใช้ Flight API, Payment API และบริการตารางการเดินทางภายใน หาก API เหล่านั้นคืนค่าการตอบสนองที่ผิดรูปแบบ agent อาจวนซ้ำ, สร้างการกู้คืนที่ผิดพลาด หรือส่งข้อมูลที่ไม่ดีไปยังปลายทาง หากมันเรียก Payment API ด้วย idempotency key ที่ผิด การแยก (isolation) ก็ช่วยอะไรไม่ได้; เงินก็ยังคงถูกโอนไป Sandbox ป้องกันโฮสต์ของคุณจาก agent แต่มันไม่ได้ป้องกันระบบของคุณจาก agent ที่สับสนซึ่งทำการเรียกใช้จริงไปยังบริการจริง
ดังนั้นขั้นตอนการทำงานที่แท้จริงจึงมีสองชั้นที่ทำงานร่วมกัน:
- แยกการทำงาน เพื่อให้โค้ดที่สร้างโดยโมเดลและการเรียกใช้เครื่องมือไม่สามารถทำอันตรายต่อโฮสต์หรือนำข้อมูลออกไปได้ นั่นคือชั้นของ CubeSandbox
- ตรวจสอบความถูกต้องของสัญญา ของทุก API และเครื่องมือที่ agent สามารถเข้าถึงได้ ทั้งก่อนและระหว่างการรันแบบ sandboxed นั่นคือชั้นของเครื่องมือ API
สำหรับชั้นที่สอง ให้ mock dependencies เพื่อให้ agent สื่อสารกับตัวแทนที่ควบคุมได้ในขณะที่คุณกำลังทดสอบพฤติกรรม จากนั้นจึงทดสอบ endpoint จริงสำหรับการปฏิบัติตาม schema, การจัดการข้อผิดพลาด, การตรวจสอบสิทธิ์ และกรณีขอบ ด้วย Apidog คุณสามารถสร้าง mock server ที่คืนค่าการตอบสนองที่กำหนดได้และถูกต้องตาม schema ชี้ agent ที่อยู่ใน sandbox ไปที่มัน และดูว่า agent ตอบสนองต่อทั้งเส้นทางที่สำเร็จและล้มเหลวอย่างไรโดยไม่ต้องแตะต้องระบบ production เมื่อคุณพร้อม ให้รันสถานการณ์เดียวกันกับ Live API เพื่อยืนยันว่าสัญญายังคงถูกต้อง บทความของเราเกี่ยวกับการ ทดสอบ sandbox ครอบคลุมการปฏิบัติทั่วไปในการทดสอบกับสภาพแวดล้อมที่แยกและควบคุม ซึ่งสามารถนำมาใช้ได้โดยตรงในที่นี้
การจับคู่นี้มีความสำคัญเพราะ agent ขยายความเบี่ยงเบนของสัญญา (contract drift) มนุษย์จะสังเกตเห็นเมื่อการตอบสนองของ API ดูผิดปกติ Agent มักจะไม่สังเกต; มันจะรับการตอบสนองและดำเนินการตามนั้น สัญญา API ที่เข้มงวด ซึ่งมีการฝึกฝนด้วย mocks และการทดสอบ จะช่วยป้องกันไม่ให้ผู้เรียกใช้แบบอัตโนมัติรวมการตอบสนองที่ไม่ดีเพียงครั้งเดียวให้กลายเป็นผลกระทบต่อเนื่อง หาก agent ของคุณพูด Model Context Protocol, การ ทดสอบ MCP servers ด้วย Apidog จะขยายระเบียบวินัยเดียวกันไปยังชั้นเครื่องมือ และหากคุณกำลังออกแบบ API สำหรับผู้บริโภค agent, การ ออกแบบ API สำหรับ AI agent จะครอบคลุมรูปแบบสัญญาที่ทำให้การเรียกใช้แบบอัตโนมัติสามารถคาดเดาได้
กรณีการใช้งานจริง
รูปแบบบางอย่างที่แนวทางแบบ isolation-plus-contract แสดงให้เห็นถึงคุณค่าของมัน:
Coding agent และ Code interpreter โมเดลเขียนและรันโค้ดเพื่อตอบคำถาม, แปลงข้อมูล หรือสร้างกราฟ นี่คือกรณีการใช้งาน sandbox แบบมาตรฐานและเป็นเป้าหมายโดยตรงของ API ที่เข้ากันได้กับ E2B เคอร์เนลสำหรับแต่ละ sandbox ของ CubeSandbox มีความสำคัญในที่นี้ เนื่องจากโค้ดเป็นแบบ arbitrary และเปลี่ยนแปลงทุกครั้งที่รัน
แพลตฟอร์ม agent แบบ Multi-tenant หาก agent ของลูกค้าหลายรายรันโค้ดบนโครงสร้างพื้นฐานที่ใช้ร่วมกัน การแยกในระดับคอนเทนเนอร์ระหว่าง tenant มีความเสี่ยง การแยกด้วยฮาร์ดแวร์สำหรับแต่ละ sandbox ให้ขอบเขตการเช่าที่คงอยู่ได้แม้ว่า agent ของ tenant หนึ่งจะเป็นภัยคุกคาม ความหนาแน่นที่รายงาน (sandboxes นับพันต่อโฮสต์) คือสิ่งที่ทำให้สิ่งนี้เป็นไปได้ แทนที่จะเป็นหนึ่ง VM ต่อหนึ่ง tenant
Agentic RL และ Training loop การฝึก agent ด้วย reinforcement learning หมายถึงการรัน rollouts ที่มีอายุสั้นและไม่น่าเชื่อถือนับไม่ถ้วน Tencent อ้างถึง MiniMax ที่ใช้ CubeSandbox สำหรับสิ่งนี้โดยเฉพาะในสภาพแวดล้อมที่หลากหลาย การ cold start ที่รวดเร็วและโอเวอร์เฮดต่ออินสแตนซ์ที่ต่ำคือความแตกต่างระหว่างการฝึกอบรมที่สามารถทำได้กับที่ทำไม่ได้
Research agent และ Data agent ที่ใช้เครื่องมือ Agent ดึงเนื้อหาภายนอก, แยกวิเคราะห์ และเรียกใช้ API ปลายทาง เนื้อหาที่ดึงมาไม่น่าเชื่อถือ (ความเสี่ยงในการทำ prompt-injection) ดังนั้นการแยกวิเคราะห์และโค้ดที่สร้างขึ้นควรอยู่ใน sandbox ในขณะที่ API ปลายทางควรได้รับการทดสอบกับ mocks ก่อน นี่คือจุดที่การจับคู่การแยกเข้ากับการ ทดสอบสัญญา API ให้ผลตอบแทนสูงสุด
การรันปลั๊กอินหรือส่วนขยายที่ไม่น่าเชื่อถือ หากผู้ใช้สามารถจัดหาเครื่องมือหรือโค้ดที่ agent ของคุณรันได้ คุณกำลังรันโค้ดที่ไม่น่าเชื่อถือจากบุคคลที่สามโดยนิยาม ขอบเขต microVM ต่อการรันแต่ละครั้งเป็นท่าทีที่เหมาะสม ซึ่งเป็นเหตุผลเดียวกับที่แพลตฟอร์ม serverless ใช้เมื่อนำ Firecracker มาใช้
บทสรุป
การทำ Agent sandboxing ไม่ใช่ทางเลือกอีกต่อไปเมื่อ agent เริ่มรันโค้ดและเรียกใช้เครื่องมือโดยไม่มีการตรวจสอบจากมนุษย์ CubeSandbox เป็นคำตอบที่เป็นรูปธรรมและเปิดเผยสำหรับครึ่งหนึ่งของปัญหาในด้านการแยก (isolation)
ประเด็นสำคัญ:
- CubeSandbox มีอยู่จริงและเฉพาะเจาะจง: เป็น sandbox แบบโอเพนซอร์สของ Tencent Cloud ภายใต้สัญญาอนุญาต Apache 2.0 สำหรับ AI agent ซึ่งสร้างขึ้นบน RustVMM และ KVM พร้อม guest kernel สำหรับแต่ละ sandbox
- รูปแบบการแยกคือหัวใจสำคัญ: เคอร์เนลเฉพาะสำหรับแต่ละ sandbox นั้นแข็งแกร่งกว่าการแยกแบบคอนเทนเนอร์สำหรับโค้ดที่สร้างโดยโมเดลแบบ arbitrary โดยมีรายงานการ cold start ที่ต่ำกว่า 100 มิลลิวินาที และโอเวอร์เฮดน้อยกว่า 5MB
- ความเข้ากันได้กับ E2B ช่วยลดต้นทุนการเปลี่ยนผ่าน: หากคุณใช้ E2B เส้นทางแบบ drop-in ที่ระบุในเอกสารจะเปลี่ยนการตัดสินใจเป็นการเลือกระหว่างบริการที่มีการจัดการกับโครงสร้างพื้นฐานที่โฮสต์เอง ไม่ใช่การเขียนโค้ดใหม่ทั้งหมด
- พิจารณาตัวเลขจากผู้จำหน่ายเป็นจุดเริ่มต้น: การอ้างสิทธิ์ด้านประสิทธิภาพและความหนาแน่นส่วนใหญ่มาจาก Tencent; ควรเปรียบเทียบกับปริมาณงานของคุณเอง และตรวจสอบที่เก็บข้อมูลสำหรับฟีเจอร์ที่จัดส่งแล้วเทียบกับที่กำลังพัฒนา
- การแยกเป็นสิ่งจำเป็นแต่ไม่เพียงพอ: sandbox ปกป้องโฮสต์ของคุณจาก agent; แต่มันไม่ได้ปกป้อง API ของคุณจาก agent ที่สับสนซึ่งเรียกใช้พวกมัน
- จับคู่ runtime isolation กับการทดสอบสัญญา API: mock และทดสอบทุก endpoint ที่ agent สามารถเข้าถึงได้ เพื่อให้การตอบสนองที่ไม่ดีเพียงครั้งเดียวไม่ส่งผลกระทบต่อเนื่อง
หาก agent ของคุณเรียกใช้ API ที่คุณเป็นเจ้าของหรือต้องพึ่งพา ให้ตั้งค่าชั้นสัญญาควบคู่ไปกับชั้นการแยก ดาวน์โหลด Apidog เพื่อ mock บริการที่ agent ใน sandbox ของคุณเข้าถึง และทดสอบ schema, การตรวจสอบสิทธิ์ และพฤติกรรมการเกิดข้อผิดพลาด ก่อนที่ระบบอัตโนมัติจะนำไปใช้งานจริง