รันโค้ดที่ Agent เขียนขึ้นเองใน Sandbox แยกส่วน กับปล่อยรันตรงในโปรเซสหลัก ต่างกันตรงไหน

ทีมที่เริ่มสร้าง AI Agent ที่ทำได้มากกว่าตอบคำถาม เช่น Agent ที่เขียนสคริปต์วิเคราะห์ข้อมูลเองแล้วรันดูผลจริง มักเจอคำถามเดียวกันตอนออกแบบระบบ คือโค้ดที่ Agent เขียนขึ้นมาเองสด ๆ นั้นควรรันที่ไหน ถ้ารันในโปรเซสเดียวกับแอปหลักตรง ๆ แล้วโค้ดนั้นมีบั๊กหรือพยายามทำอะไรที่ไม่ควรทำ ความเสี่ยงจะกระทบทั้งระบบทันที

Vercel Sandbox ถูกออกแบบมาตอบคำถามนี้โดยตรง คือให้พื้นที่รันโค้ดแบบแยกส่วนที่สร้างขึ้นชั่วคราว รันโค้ดที่ต้องการ แล้วปิดตัวเองทิ้งไปเมื่อทำงานเสร็จ ต่างจาก Serverless Function ทั่วไปที่ออกแบบมาสำหรับรันโค้ดที่ทีมเขียนไว้ล่วงหน้าและ Deploy ผ่านกระบวนการ Build ตามปกติ

บทความนี้จะเทียบให้เห็นชัดว่ารันโค้ดใน Sandbox กับรันตรงในโปรเซสหลักต่างกันตรงไหนจริง ๆ ทั้งเรื่องความปลอดภัย โครงสร้างการทำงาน และจังหวะที่ควรเลือกใช้แบบไหน เพื่อให้ทีมตัดสินใจได้จากความเสี่ยงจริงของงาน ไม่ใช่จากความเคยชิน

Vercel Sandbox คืออะไรกันแน่

Vercel Sandbox คือ Compute Environment ชั่วคราวที่สร้างขึ้นแบบแยกส่วนโดยสมบูรณ์จากแอปหลัก มีระบบไฟล์ หน่วยความจำ และขอบเขตการเข้าถึงเครือข่ายเป็นของตัวเอง ทีมสั่งสร้าง Sandbox ขึ้นมาผ่านโค้ด รันคำสั่งหรือสคริปต์ที่ต้องการ อ่านผลลัพธ์กลับมา แล้ว Sandbox นั้นจะถูกทำลายทิ้งไปเมื่อทำงานเสร็จหรือหมดเวลาที่กำหนด

จุดที่ต่างจาก Serverless Function ของ Vercel เองคือ Function ถูกออกแบบมาให้รันโค้ดที่ทีมเขียนและ Deploy ไว้ล่วงหน้าแล้ว ส่วน Sandbox ถูกออกแบบมาสำหรับรันโค้ดที่ไม่รู้ล่วงหน้าว่าเนื้อหาจะเป็นอะไร เพราะถูกสร้างขึ้นระหว่างทำงานจริง เช่นโค้ดที่โมเดลภาษาสร้างขึ้นมาตอบสนองต่อคำสั่งของผู้ใช้ ณ ขณะนั้น

อีกจุดสำคัญคือ Sandbox แต่ละตัวไม่รู้จักกันและไม่แชร์สถานะกัน ต่อให้สร้าง Sandbox สองตัวพร้อมกันเพื่อรันงานคนละชิ้น ทั้งสองก็แยกขาดจากกันโดยสมบูรณ์ ทำให้ปลอดภัยกว่าการรันหลายงานปนกันในโปรเซสเดียวที่แชร์หน่วยความจำและตัวแปรร่วมกัน

ทำไม AI Agent ที่เขียนโค้ดเองถึงต้องการพื้นที่รันแยกส่วน

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

ความเสี่ยงหลักไม่ได้อยู่ที่ Agent ตั้งใจทำร้ายระบบ แต่อยู่ที่โมเดลภาษาอาจสร้างโค้ดที่มีบั๊กโดยไม่ตั้งใจ เช่นเขียนลูปที่ไม่มีวันจบ เปิดไฟล์ผิดตำแหน่งจนไปทับข้อมูลสำคัญ หรือพยายามเรียกใช้ทรัพยากรของระบบเกินความจำเป็น ถ้าโค้ดแบบนี้รันอยู่ในโปรเซสเดียวกับแอปหลักที่ผู้ใช้คนอื่นกำลังใช้งานอยู่ ผลกระทบจะลามไปถึงคนอื่นด้วย

การแยก Runtime ออกมาต่างหากทำให้ทีมกำหนดขอบเขตได้ชัดเจนล่วงหน้า เช่นจำกัดเวลารันสูงสุด จำกัดหน่วยความจำที่ใช้ได้ และปิดการเชื่อมต่อเครือข่ายที่ไม่จำเป็น เพื่อให้ต่อให้โค้ดที่ Agent สร้างขึ้นมามีปัญหาจริง ความเสียหายก็จำกัดอยู่แค่ใน Sandbox นั้นและไม่กระทบส่วนอื่นของระบบ

รันใน Sandbox กับรันตรงในโปรเซสหลักของแอป ต่างกันตรงไหน

หลายทีมที่เพิ่งเริ่มสร้าง Agent ที่รันโค้ดได้มักตั้งคำถามว่า ทำไมไม่รันโค้ดตรงในฟังก์ชันเดียวกับที่จัดการ Request อื่น ๆ ไปเลย ในเมื่อดูเหมือนง่ายกว่าและเร็วกว่า ตารางนี้เทียบให้เห็นความต่างที่ส่งผลจริงต่อความปลอดภัยและความเสถียรของระบบ:

วงจรการทำงานของ Sandbox หนึ่งรอบเป็นอย่างไร

การทำความเข้าใจวงจรชีวิตของ Sandbox ช่วยให้ออกแบบระบบรอบมันได้เหมาะสมกว่าการเดา เพราะแต่ละขั้นตอนมีผลต่อทั้งความหน่วงที่ผู้ใช้รู้สึกได้และต้นทุนที่เกิดขึ้นจริง

1. โค้ดฝั่ง Agent เรียกสร้าง Sandbox ใหม่ขึ้นมา พร้อมกำหนดค่าพื้นฐาน เช่น Runtime ที่ต้องการและเวลารันสูงสุดที่ยอมให้
2. Sandbox ถูกจัดสรรทรัพยากรแยกต่างหาก มีระบบไฟล์ของตัวเองที่ว่างเปล่าตั้งแต่ต้น ไม่มีข้อมูลเก่าจากการรันครั้งก่อนหลงเหลืออยู่
3. โค้ดหรือคำสั่งที่ต้องการรันถูกส่งเข้าไปทำงานภายใน Sandbox นั้น ระหว่างนี้ทีมสามารถอ่าน Output ที่พิมพ์ออกมาระหว่างทางได้แบบ Stream
4. เมื่อโค้ดทำงานเสร็จหรือครบเวลาที่กำหนดไว้ Sandbox จะหยุดทำงานและถูกทำลายทิ้ง ทรัพยากรทั้งหมดที่จัดสรรไว้ถูกคืนกลับ ไม่มีอะไรหลงเหลืออยู่ให้ Sandbox รอบถัดไปเห็น
5. ผลลัพธ์สุดท้าย เช่นค่าที่คำนวณได้หรือไฟล์ที่สร้างขึ้น จะถูกดึงกลับมาใช้ในแอปหลักก่อนที่ Sandbox จะหายไป ถ้าลืมดึงผลลัพธ์ก่อนปิด ข้อมูลนั้นจะสูญหายไปพร้อมกับ Sandbox

งานแบบไหนที่เหมาะกับ Sandbox จริง ๆ

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

อีกกรณีคือ Agent ที่ช่วยตรวจสอบหรือทดสอบโค้ดที่ผู้ใช้ส่งเข้ามา เช่นแพลตฟอร์มสอนเขียนโปรแกรมที่ให้ผู้เรียนส่งโค้ดมาให้ระบบรันดูผล การรันโค้ดของผู้เรียนแต่ละคนใน Sandbox แยกกันช่วยป้องกันไม่ให้โค้ดของคนหนึ่งไปกระทบการรันของอีกคน หรือกระทบตัวแพลตฟอร์มเอง

กรณีที่สามซึ่งเริ่มพบมากขึ้นคือการใช้ Sandbox เป็นส่วนหนึ่งของ Tool ที่ Agent เรียกใช้ระหว่างทำงาน โดยผูกเข้ากับ Vercel AI SDK Agent ให้ Agent ตัดสินใจเองว่าจะเขียนโค้ดขึ้นมารันเมื่อไร เช่นเมื่อคำถามซับซ้อนเกินกว่าที่จะตอบจากความรู้เดิมของโมเดลได้ตรง ๆ

ขอบเขตความปลอดภัยที่ Sandbox ให้จริง และสิ่งที่ยังต้องระวังเอง

Sandbox ช่วยตัดความเสี่ยงระดับโครงสร้าง เช่นโค้ดที่รันข้างในไม่สามารถเข้าถึงหน่วยความจำหรือระบบไฟล์ของแอปหลักได้โดยตรง และเมื่อ Sandbox ถูกทำลายทิ้ง ข้อมูลที่เคยอยู่ในนั้นก็หายไปด้วย ทำให้ไม่ต้องกังวลว่าโค้ดที่รันไปแล้วจะทิ้งร่องรอยอันตรายไว้ในระบบถาวร

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

อีกจุดที่ทีมต้องออกแบบเองคือการควบคุมว่า Agent จะสั่งรันโค้ดผ่าน Sandbox ได้เมื่อไร โดยเฉพาะงานที่มีผลกระทบสูง ควรผูกเข้ากับกลไกอย่าง Tool Approval เพื่อให้มีจุดตรวจก่อนโค้ดที่ Agent เขียนขึ้นเองถูกรันจริง ไม่ใช่ปล่อยให้ Agent ตัดสินใจรันได้เองทุกกรณีโดยไม่มีการตรวจสอบเลย

ผูก Sandbox เข้ากับ Vercel AI SDK เป็น Tool ให้ Agent เรียกใช้อย่างไร

รูปแบบที่ใช้กันบ่อยที่สุดคือกำหนด Sandbox เป็นหนึ่งใน Tool ที่ Agent เรียกใช้ได้ผ่าน Vercel AI SDK โดยอธิบายให้โมเดลรู้ว่า Tool นี้ใช้สำหรับรันโค้ดเพื่อคำนวณหรือทดสอบสิ่งที่ต้องการคำตอบที่แม่นยำ ไม่ใช่แค่คาดเดาจากความรู้ทั่วไป

เมื่อ Agent ตัดสินใจเรียก Tool นี้ ระบบจะสร้าง Sandbox ขึ้นมา ส่งโค้ดที่โมเดลสร้างเข้าไปรัน แล้วดึงผลลัพธ์กลับมาให้โมเดลใช้เรียบเรียงคำตอบสุดท้าย ขั้นตอนทั้งหมดนี้เกิดขึ้นภายในลูปการทำงานเดียวกับที่ Agent ตัดสินใจเรียก Tool อื่น ๆ ทำให้จัดการผ่านโครงสร้างเดียวกันได้โดยไม่ต้องแยกระบบ

ถ้า Agent ต้องเรียกโค้ดหลายรอบต่อเนื่องกัน เช่นรันครั้งแรกแล้วพบว่าต้องปรับโค้ดแล้วรันใหม่อีกครั้งตามผลลัพธ์ที่ได้ ควรพิจารณาผูกเข้ากับ WorkflowAgent เพื่อให้จัดการลำดับขั้นตอนที่ซับซ้อนกว่าการเรียก Tool ครั้งเดียวจบได้อย่างมีโครงสร้าง แทนที่จะเขียน Logic ควบคุมลำดับเองทั้งหมด

ข้อจำกัดเรื่องเวลาเริ่มทำงานและต้นทุนที่ต้องวางแผนล่วงหน้า

การสร้าง Sandbox ใหม่ทุกครั้งมีเวลาเริ่มทำงานที่มากกว่าการรันตรงในโปรเซสที่มีอยู่แล้วเสมอ เพราะต้องจัดสรรทรัพยากรแยกใหม่ทั้งหมดตั้งแต่ต้น ทีมที่ต้องการคำตอบเร็วมาก ๆ อย่างแชทที่ผู้ใช้รอคำตอบแบบสด ควรคำนึงถึงเวลาส่วนนี้เมื่อออกแบบว่าจะให้ Agent เรียกใช้ Sandbox บ่อยแค่ไหน

ตัวอย่างสมมติเพื่อให้เห็นภาพ: ทีมหนึ่งออกแบบ Agent ให้เรียกรันโค้ดใน Sandbox ทุกครั้งที่ผู้ใช้ถามคำถามเกี่ยวกับตัวเลข แม้บางคำถามจะง่ายมากจนไม่จำเป็นต้องรันโค้ดเลยก็ตาม ผลคือผู้ใช้รู้สึกว่า Agent ตอบช้ากว่าที่ควรในคำถามง่าย ๆ ทั้งที่ Sandbox ทำงานถูกต้องทุกครั้ง ปัญหาจึงไม่ได้อยู่ที่ตัว Sandbox แต่อยู่ที่การออกแบบว่าเมื่อไรควรเรียกใช้

เรื่องต้นทุนก็ต้องวางแผนคล้ายกัน เพราะแต่ละครั้งที่สร้าง Sandbox ขึ้นมามีค่าใช้จ่ายแยกจากค่า Hosting ปกติ ทีมที่ปล่อยให้ Agent เรียกใช้ Sandbox โดยไม่มีการจำกัดความถี่อาจเจอค่าใช้จ่ายที่สูงกว่าที่ประเมินไว้ตอนแรก โดยเฉพาะถ้ามีผู้ใช้จำนวนมากถามคำถามที่ Trigger การรันโค้ดพร้อมกัน

ทำแบบนี้แล้วพัง เพราะทีมมักพลาดจุดเหล่านี้

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

สรุป

Vercel Sandbox คือพื้นที่รันโค้ดแบบแยกส่วนชั่วคราวที่สร้างขึ้นเฉพาะกิจ ใช้สำหรับรันโค้ดที่ไม่รู้ล่วงหน้าว่าจะเป็นอย่างไร เช่นโค้ดที่ AI Agent เขียนขึ้นมาเองระหว่างทำงานจริง ต่างจากการรันตรงในโปรเซสหลักของแอปตรงที่จำกัดขอบเขตความเสียหายไว้ใน Sandbox นั้นเท่านั้น ไม่ลามเข้าระบบหลักหรือกระทบผู้ใช้คนอื่น

การเลือกใช้ Sandbox ควรมาจากลักษณะงานจริง คืองานที่ Agent ต้องคำนวณหรือทดสอบสิ่งที่ไม่มี Tool สำเร็จรูปรองรับไว้ล่วงหน้า ส่วนงานที่รู้ขอบเขตชัดเจนอยู่แล้วมักเหมาะกับการเชื่อม Tool ผ่าน MCP มากกว่า ทีมที่เข้าใจความต่างนี้จะออกแบบ Agent ได้ทั้งปลอดภัยและไม่เสียเวลาผู้ใช้โดยไม่จำเป็น

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

คำถามที่พบบ่อย