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

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

รูปแบบที่ 1: เอเจนต์ทำงานภายในแซนด์บ็อกซ์

ในรูปแบบนี้ เอเจนต์ทำงานโดยสมบูรณ์ภายในสภาพแวดล้อมแซนด์บ็อกซ์ โดยภายนอกสื่อสารกับมันผ่านเครือข่าย

วิธีการดำเนินการ: สร้างอิมเมจ Docker หรือเครื่องเสมือนที่ติดตั้งเฟรมเวิร์กเอเจนต์ไว้ล่วงหน้า รันภายในแซนด์บ็อกซ์ และเชื่อมต่อส่งข้อความจากภายนอก เอเจนต์เปิดเผยจุดปลายทาง API (โดยทั่วไปคือ HTTP หรือ WebSocket) แอปพลิเคชันสื่อสารข้ามขอบเขตแซนด์บ็อกซ์กับมัน

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

ความท้าทาย:
* โครงสร้างพื้นฐานการสื่อสาร: การสื่อสารข้ามขอบเขตแซนด์บ็อกซ์ต้องการการสนับสนุนเพิ่มเติม ผู้ให้บริการบางราย (เช่น E2B) จัดการปัญหานี้ใน SDK มิฉะนั้นจำเป็นต้องสร้างเลเยอร์ WebSocket หรือ HTTP ด้วยตัวเอง รวมถึงการจัดการเซสชันและการจัดการข้อผิดพลาด
* ความปลอดภัยของคีย์ API: คีย์ API ต้องถูกเก็บไว้ภายในแซนด์บ็อกซ์เพื่ออนุญาตให้เอเจนต์ทำการเรียกอนุมาน ซึ่งสร้างความเสี่ยงด้านความปลอดภัยหากแซนด์บ็อกซ์ถูกบุกรุก ผู้ให้บริการเช่น E2B และ Runloop กำลังพัฒนาฟีเจอร์ตู้นิรภัยคีย์เพื่อแก้ไขปัญหานี้
* การอัปเดตและการวนซ้ำช้า: การอัปเดตต้องสร้างอิมเมจคอนเทนเนอร์ใหม่และปรับใช้ใหม่ ซึ่งทำให้วงจรการวนซ้ำการพัฒนาช้าลง
* การกู้คืนสถานะ: แซนด์บ็อกซ์ต้องถูกกู้คืนก่อนที่เอเจนต์จะทำงาน ซึ่งมักต้องการตรรกะเพิ่มเติม
* ความเสี่ยงด้านทรัพย์สินทางปัญญา: สำหรับทีมที่กังวลเกี่ยวกับการปกป้องทรัพย์สินทางปัญญาของเอเจนต์ โค้ดและพรอมต์ของเอเจนต์มีแนวโน้มที่จะรั่วไหลมากขึ้นเมื่อทำงานภายในแซนด์บ็อกซ์

Nuno Campos จาก Witan Labs ชี้ให้เห็นปัญหาด้านความปลอดภัยอีกประการหนึ่ง: “ส่วนใดๆ ของเอเจนต์ไม่ควรมีสิทธิ์มากกว่าเครื่องมือ bash ตัวอย่างเช่น หากคุณต้องการเอเจนต์ที่มีทั้งเครื่องมือ bash และเครื่องมือค้นหาเว็บ โค้ดที่สร้างโดย LLM ทั้งหมดสามารถเข้าถึงอินเทอร์เน็ตได้โดยไม่มีข้อจำกัด ซึ่งเป็นความเสี่ยงด้านความปลอดภัยที่ใหญ่ หากเป็นรูปแบบที่สอง คุณสามารถให้เครื่องมือมีสิทธิ์มากกว่าโค้ดที่สร้างโดย LLM ได้ เนื่องจากขอบเขตความปลอดภัยล้อมรอบเครื่องมือ bash ไม่ใช่ทั้งเอเจนต์”

รูปแบบที่ 2: แซนด์บ็อกซ์เป็นเครื่องมือ

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

วิธีการดำเนินการ: เอเจนต์ทำงานในเครื่องท้องถิ่นหรือบนเซิร์ฟเวอร์ เมื่อสร้างโค้ดที่ต้องการรัน จะเรียกใช้ API ของผู้ให้บริการแซนด์บ็อกซ์ (เช่น E2B, Modal, Daytona หรือ Runloop) SDK ของผู้ให้บริการจัดการรายละเอียดการสื่อสารทั้งหมด จากมุมมองของเอเจนต์ แซนด์บ็อกซ์เป็นเพียงเครื่องมืออีกชิ้นหนึ่ง

ข้อดี:
* วนซ้ำอย่างรวดเร็ว: สามารถอัปเดตโค้ดเอเจนต์ได้ทันทีโดยไม่ต้องสร้างอิมเมจคอนเทนเนอร์ใหม่ ซึ่งเร่งความเร็วการวนซ้ำระหว่างการพัฒนา
* คีย์อยู่ภายนอก: คีย์ API ยังคงอยู่ภายนอกแซนด์บ็อกซ์ มีเพียงการดำเนินการโค้ดที่เกิดขึ้นในสภาพแวดล้อมที่แยกออก
* การแยกความสนใจ: สถานะของเอเจนต์ (ประวัติการสนทนา, ห่วงโซ่การให้เหตุผล, ความจำ) อยู่ในที่ที่เอเจนต์ทำงาน แยกจากแซนด์บ็อกซ์ ซึ่งหมายความว่าความล้มเหลวของแซนด์บ็อกซ์จะไม่สูญเสียสถานะเอเจนต์ และสามารถเปลี่ยนแบ็กเอนด์แซนด์บ็อกซ์ได้โดยไม่กระทบต่อตรรกะหลักของเอเจนต์

ข้อดีอื่นๆ ที่ Tomas Beran จาก E2B ชี้ให้เห็น:
1. สามารถรันงานแบบขนานในแซนด์บ็อกซ์ระยะไกลหลายตัวได้
2. จ่ายเงินสำหรับแซนด์บ็อกซ์เฉพาะเมื่อรันโค้ดเท่านั้น ไม่ใช่สำหรับเวลารันของกระบวนการทั้งหมด

Ben Guo จาก Zo Computer เสริมว่า: “เราเลือกรูปแบบที่สองโดยคำนึงถึงความเป็นไปได้ที่ในอนาคตอาจจำเป็นต้องรันเครื่องมือเอเจนต์บนเครื่อง GPU โดยทั่วไป ความต้องการสภาพแวดล้อมของแซนด์บ็อกซ์ถาวรและเครื่องมืออนุมานจะแยกจากกัน”

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

คำแนะนำในการเลือก

สถานการณ์ที่เลือกรูปแบบที่หนึ่ง:
* เอเจนต์เชื่อมโยงอย่างแน่นหนากับสภาพแวดล้อมการดำเนินการ (เช่น ต้องการการเข้าถึงอย่างต่อเนื่องไปยังไลบรารีเฉพาะหรือสถานะสภาพแวดล้อมที่ซับซ้อน)
* ต้องการให้สภาพแวดล้อมการผลิตสะท้อนสภาพแวดล้อมการพัฒนาท้องถิ่นอย่างใกล้ชิด
* SDK ของผู้ให้บริการจัดการเลเยอร์การสื่อสารให้คุณ

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

ตัวอย่างการดำเนินการ

ตัวอย่างเฉพาะโดยใช้เฟรมเวิร์ก deepagents:

รูปแบบที่ 1: เอเจนต์ภายในแซนด์บ็อกซ์
ขั้นแรกสร้างอิมเมจที่ติดตั้งเอเจนต์ไว้ล่วงหน้า:
dockerfile
FROM python:3.11
RUN pip install deepagents-cli
จากนั้นรันภายในแซนด์บ็อกซ์ การดำเนินการที่สมบูรณ์ต้องการโครงสร้างพื้นฐานเพิ่มเติมเพื่อจัดการการสื่อสารระหว่างแอปพลิเคชันและเอเจนต์ภายในแซนด์บ็อกซ์ (เซิร์ฟเวอร์ WebSocket หรือ HTTP, การจัดการเซสชัน, การจัดการข้อผิดพลาด)

รูปแบบที่ 2: แซนด์บ็อกซ์เป็นเครื่องมือ
python
from daytona import Daytona
from langchain_anthropic import ChatAnthropic
from deepagents import create_deep_agent
from langchain_daytona import DaytonaSandbox

สามารถใช้ E2B, Runloop, Modal ก็ได้

sandbox = Daytona().create()
backend = DaytonaSandbox(sandbox=sandbox)

agent = create_deep_agent(
model=ChatAnthropic(model=”claude-sonnet-4-20250514″),
system_prompt=”You are a Python coding assistant with sandbox access.”,
backend=backend,
)

result = agent.invoke({
“messages”: [{
“role”: “user”,
“content”: “Run a small python script”,
}]
})

sandbox.stop()

ขั้นตอนการไหลของโค้ดนี้เมื่อรัน:
1. เอเจนต์วางแผนในเครื่องของคุณในท้องถิ่น
2. สร้างโค้ด Python เพื่อแก้ปัญหา
3. เรียกใช้ API ของ Daytona เพื่อดำเนินการโค้ดในแซนด์บ็อกซ์ระยะไกล
4. แซนด์บ็อกซ์ส่งกลับผลลัพธ์
5. เอเจนต์เห็นผลลัพธ์และดำเนินการให้เหตุผลต่อไปในท้องถิ่น

การอภิปรายในชุมชน

หัวข้อนี้จุดประกายการอภิปรายในชุมชน

มีนักพัฒนาที่ตั้งคำถามถึงความได้เปรียบของรูปแบบที่หนึ่งในสภาพแวดล้อมการผลิต โดยเห็นว่ามี “ช่องโหว่ความปลอดภัยที่ใหญ่และข้อจำกัดโครงสร้างพื้นฐานที่ท้าทายอย่างยิ่ง (การสังเกตการณ์แซนด์บ็อกซ์, เวลาทำงานปกติ, การขยายขนาด ฯลฯ)”

Nico Ritschel แสดงมุมมองที่แตกต่างเกี่ยวกับข้อเสียบางประการ โดยเชื่อว่ามีวิธีแก้ปัญหาง่ายๆ และปฏิบัติได้จริง:
* ปัญหาคีย์ API สามารถแก้ไขได้โดยใช้พร็อกซี่สำหรับการเรียกอนุมานและฉีดคีย์จากภายนอกแซนด์บ็อกซ์
* สำหรับการปกป้องทรัพย์สินทางปัญญา สามารถเก็บ IP ไว้ในเครื่องมือที่เอเจนต์เข้าถึงได้

Harrison Chase ตอบว่าการพร็อกซี่คีย์ยังไม่ใช่แนวทางปฏิบัติมาตรฐาน แม้ว่าผู้ให้บริการบางรายกำลังเพิ่มฟีเจอร์เหล่านี้

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

นักพัฒนา Ale Alonso กล่าวว่าการแซนด์บ็อกซ์เป็นหนึ่งในความยากลำบากที่ใหญ่ที่สุดที่พบเมื่อใช้ deepagents

Nathan Flurry แนะนำ Sandbox Agent SDK ที่พวกเขาพัฒนาขึ้น ซึ่งเป็นเครื่องมือที่ออกแบบมาเพื่อแก้ไขความซับซ้อนของรูปแบบ “เอเจนต์ภายในแซนด์บ็อกซ์” โดยเฉพาะ SDK นี้รองรับเอเจนต์หลากหลายประเภท เช่น Claude Code, Codex, OpenCode, Cursor, Amp และ Pi และให้ API HTTP แบบรวมศูนย์เพื่อควบคุมเอเจนต์ภายในแซนด์บ็อกซ์จากระยะไกล

สรุป

เอเจนต์จำเป็นต้องรันโค้ดในสภาพแวดล้อมที่แยกออกเพื่อความปลอดภัย รูปแบบสถาปัตยกรรมทั้งสองแบบมีข้อดีต่างกัน: รันเอเจนต์ภายในแซนด์บ็อกซ์ (สะท้อนการพัฒนาท้องถิ่น, เชื่อมโยงอย่างแน่นหนา) หรือรันภายนอกและใช้แซนด์บ็อกซ์เป็นเครื่องมือ (อัปเดตง่าย, คีย์ API ยังคงปลอดภัย) แต่ละรูปแบบมีประโยชน์และการแลกเปลี่ยนที่แตกต่างกันตามความต้องการเฉพาะ

https://x.com/hwchase17/status/2021261552222158955?s=46

http://github.com/rivet-dev/sandbox-agent

ติดตาม “Whale Habitat” Mini Program เพื่อรับข่าวสาร AI ล่าสุด

⚠️ หมายเหตุ: เนื้อหาได้รับการแปลโดย AI และตรวจสอบโดยมนุษย์ หากมีข้อผิดพลาดโปรดแจ้ง

☕ สนับสนุนค่ากาแฟทีมงาน

หากคุณชอบบทความนี้ สามารถสนับสนุนเราได้ผ่าน PromptPay

SCAN TO PAY WITH ANY BANK