Perplexity משחררת בקוד פתוח את SPACE: מערכת להרצת קוד של סוכני AI בסביבות מבודדות

חברת Perplexity פרסמה ב-GitHub את SPACE כפרויקט קוד פתוח. השם הוא ראשי תיבות של Sandboxed Platform for Agentic Code Execution, כלומר פלטפורמה להרצת קוד של סוכנים בתוך ארגז חול. המערכת מריצה קוד בתוך microVMs, מכונות וירטואליות זעירות מבוססות Firecracker. אפליקציות פונות אליה דרך HTTP API כדי ליצור סביבות Linux, להריץ בהן פקודות, לאסוף את הפלט ולנהל את מחזור החיים של כל סביבה.

הבעיה: איפה מריצים קוד שסוכן כתב

סוכני AI כותבים קוד ומריצים אותו, והרצה כזו דורשת סביבה מבודדת. אם הסוכן טועה, או מקבל הוראה זדונית, הנזק צריך להישאר בתוך הסביבה ולא להגיע למערכות של החברה. לפי התיעוד של הפרויקט, SPACE מיועדת למקרים שבהם אפליקציה צריכה סביבת הרצה נפרדת "עבור סוכן, סביבת עבודה של משתמש או משימה שמריצה קוד". חלוקת העבודה מוגדרת בבירור: האפליקציה מחליטה מה להריץ ואילו תוצאות לשמור, ו-SPACE מנהלת את ארגז החול, את התהליכים שרצים בו ואת החיבור שמעביר את הפלט.

Firecracker היא טכנולוגיית וירטואליזציה בקוד פתוח שפיתחה אמזון. היא מספקת בידוד ברמת מכונה וירטואלית, ובכל זאת עולה מהר וצורכת מעט משאבים. בגלל השילוב הזה היא נחשבת לבחירה מקובלת לבידוד קוד שלא סומכים עליו.

איך זה עובד

המערכת בנויה משני מושגים מרכזיים. Template (תבנית) מגדירה את סביבת הפתיחה. Sandbox הוא מופע של התבנית, עם מכונה וירטואלית ומערכת קבצים משלו שניתנת לכתיבה, ואפשר להריץ בו כמה פקודות ברצף. מחזור החיים כולל יצירה, המתנה עד שהסביבה מוכנה, הרצת פקודות וקריאת הפלט. בסוף אפשר להשאיר את הסביבה פעילה, להשהות אותה (pause) או להקפיא אותה (suspend) ולהעיר אותה כשצריך, או למחוק אותה.

כמה פרטים טכניים מהתיעוד:

• פעולות אסינכרוניות: שינויים במחזור החיים של sandbox מחזירים מזהה פעולה, והאפליקציה בודקת שוב ושוב אם הפעולה הסתיימה.
• הפרדה בין ניהול לנתונים: הפלט של הפקודות עובר בחיבור נפרד (data plane), עם אסימון גישה שתקף לסשן אחד בלבד.
• Warm pools: ב-Kubernetes אפשר להחזיק מראש sandboxes שכבר עלו, כך שיצירה של סביבה חדשה לא מחכה לאתחול מלא.
• Base snapshots: שחזור sandboxes מתמונת מצב (snapshot) על צומת יחיד.
• פרופילי egress: מדיניות שמגדירה לאן מותר לסביבות לפנות ברשת.

SPACE כתובה ב-Rust, אבל אין צורך בספריית Rust כדי לעבוד איתה. התקשורת מתבצעת ב-HTTP וב-server-sent events, והמדריך הראשון מדגים את כל התהליך בסקריפט Python שמשתמש רק בספרייה הסטנדרטית. ההתקנה המתועדת מבוססת על Kubernetes, עם פריסה מקומית ב-Kind (כלי להרצת Kubernetes על מחשב מקומי). לפי התיעוד, מדריך הארכיטקטורה מסביר גם איך להריץ את המערכת בלי Kubernetes. שדות שמסומנים בסכמה כ-incubating אינם חלק מהממשק הנתמך ועשויים להשתנות.

תאימות ל-E2B

אחד הרכיבים הבולטים הוא ECW (E2B Compatibility Wrapper), שכבת תאימות שמאפשרת לעבוד מול SPACE עם ה-SDK של E2B ל-Python. E2B היא חברה שמציעה סביבות ארגז חול לסוכני AI כשירות. התיעוד מציין שה-SDK נבדק מול השכבה הזו, ומפרט אילו התנהגויות נתמכות ומה המגבלות. בפועל, צוותים שכבר כתבו קוד מול E2B יכולים ככל הנראה לבחון אירוח עצמי של SPACE בלי לשכתב את האינטגרציה מאפס.

המשמעות

ככל שסוכני AI מקבלים יותר עצמאות להריץ קוד, הבידוד שלהם הופך לחלק בסיסי בתשתית. כאן חברה שמפעילה מוצר AI בהיקף גדול פותחת לציבור כלי בתחום הזה. עבור מפתחים, המשמעות היא אפשרות נוספת לארח את ארגז החול בעצמם, על התשתית שלהם, במקום להסתמך על שירות חיצוני. זה עשוי להיות רלוונטי במיוחד לארגונים עם דרישות פרטיות או רגולציה. מצד שני, הפעלה של המערכת בייצור דורשת היכרות עם Kubernetes ועם ניהול מכונות וירטואליות. ההערכה היא שבשלב זה הכלי מתאים בעיקר לצוותי תשתית, ופחות למפתח יחיד שמחפש פתרון מוכן.