Agent Runtime Architecture — סביבת ההרצה החדשה של סוכני AI

מאת צוות מדיה דיל · 12.08.2026 · Agent Infrastructure · 5 דק׳

למה מודל שפה לבדו הוא לא סוכן פועל, ואיך בונים את שכבת ה-Runtime שמריצה כלים, קוד ורשת בבטחה סביבו, עם בידוד, מכסות משאבים ו-Observability מלאה.

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

ההבדל בין מודל לסוכן פועל

מודל שפה, בפני עצמו, לא עושה שום דבר בעולם האמיתי. הוא מקבל טקסט ומחזיר טקסט. כשאומרים "הסוכן קרא קובץ" או "הסוכן שלח בקשת HTTP", בפועל יש שכבת קוד חיצונית שמפרשת את פלט המודל, מזהה קריאת כלי (tool call), ומבצעת אותה בסביבה אמיתית — עם דיסק, רשת ו-CPU. השכבה הזו היא ה-Runtime, וההחלטות שמתקבלות בה — לא במודל — הן שקובעות בפועל את רמת הסיכון של המערכת. סוכן "חכם" שרץ בתוך Runtime רשלני מסוכן בהרבה מסוכן "פשוט" שרץ בתוך Runtime מהודק, כי הנזק בפועל נקבע על ידי מה שהסוכן יכול לעשות, לא רק מה שהוא מתכנן לעשות.

ההבדל הזה חשוב במיוחד כשעוברים מ-Chatbot פשוט לסוכן דורבילי (Durable) שמבצע פעולות אמיתיות — עדכון רשומה בבסיס נתונים, שליחת תשלום, הרצת סקריפט על שרת פרודקשן. ברגע שיש לסוכן יכולת השפעה על העולם החיצוני, שאלת ה-Runtime הופכת לשאלה הכי חשובה בארכיטקטורה כולה, לפני שאלת בחירת המודל.

אנטומיה של Agent Runtime

Runtime רציני בנוי משכבות בידוד מרובות, ולא מסתמך על שכבה אחת. ברמה התחתונה יש בידוד תהליכים — Docker container בסיסי מספק בידוד filesystem וסביבת תלויות, אבל לא מספיק כשצריך להריץ קוד לא מהימן שהמודל עצמו יצר. לשם כך משתמשים ב-microVMs כמו Firecracker (המנוע שמאחורי AWS Lambda) או ב-gVisor, שמספקים kernel נפרד לכל הרצה ומצמצמים דרמטית את משטח התקיפה מול container רגיל שחולק kernel עם המארח.

מעל שכבת הבידוד יושבים מדיניות רשת ומדיניות משאבים: Egress Allowlist שמגדיר בדיוק לאילו דומיינים מותר לסוכן לפנות (ולא "כל האינטרנט"), הגבלת CPU וזיכרון לכל הרצה, ו-timeout קשיח שמונע מסוכן שנתקע בלולאה להמשיך לצרוך משאבים לנצח. חשוב גם timeout ברמת כלי בודד, לא רק ברמת המשימה כולה — קריאת API חיצונית שנתקעת לא צריכה לתקוע את כל ה-Session.

• בידוד תהליכים: microVM או gVisor לכל הרצת קוד לא מהימן
• Egress Allowlist ברמת דומיין, לא ברמת "פתוח/סגור"
• מכסות CPU/זיכרון/דיסק לכל הרצה בנפרד
• Timeout הן ברמת כלי בודד והן ברמת המשימה כולה
• Filesystem זמני שנמחק במלואו בסוף כל הרצה

Multi-Tenant Isolation וניהול Credentials

כשה-Runtime משרת כמה לקוחות או כמה סוכנים במקביל, בידוד בין Tenants הוא לא Nice-to-have — הוא תנאי סף. סוכן שמריץ קוד עבור לקוח A אסור לו לקבל גישה, ולו תיאורטית, לנתונים או לקרדנציאלס של לקוח B, גם אם שני ההרצות רצות על אותה מכונה פיזית. הפרקטיקה הנכונה היא Namespace נפרד לכל Tenant ברמת ה-Secrets Manager, והזרקת קרדנציאלס לתוך ה-Sandbox רק ברגע ההרצה ולא כחלק מה-image הבסיסי — כדי שאם ה-Sandbox נפרץ, מה שדולף הוא רק ה-Token של ה-Session הספציפי, לא מפתח-על שמשרת את כל המערכת.

נקודה שקל לפספס: גם Rate Limiting חייב להיות פר-Tenant ולא גלובלי. אחרת, סוכן אחד שנכנס ללולאת קריאות אינטנסיבית — למשל בגלל תקלה ב-Registry שגרמה לו לנסות לגלות את אותו כלי שוב ושוב — יכול לצרוך את כל מכסת ה-API החיצוני ולהשאיר את שאר הלקוחות בלי שירות.

Observability ברמת ה-Runtime

בניגוד לשרת אפליקציה רגיל, שבו כל בקשה קצרה ודומה לקודמתה, הרצת סוכן יכולה להימשך דקות עד שעות ולכלול עשרות קריאות כלי, קריאות API ופעולות דיסק. בלי Trace מפורט לכל הרצה — מי קרא לאיזה כלי, מתי, עם אילו פרמטרים, ובאיזו עלות טוקנים — אין שום דרך לדבג כשל, ואין שום דרך לדעת כמה עולה כל משימה בפועל. הפרקטיקה הנכונה היא Structured Logging שמקשר כל אירוע ל-session_id יחיד, כך שאפשר לשחזר את כל שרשרת הפעולות של הרצה בודדת מקצה לקצה, כולל צריכת טוקנים מצטברת שמאפשרת חיוב מדויק ובקרת עלויות.

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

Build vs Buy: מתי כדאי לבנות Runtime משלכם

בניית Agent Runtime מאפס היא השקעה משמעותית — microVM orchestration, ניהול Secrets, ו-Observability מפורט הם לא פרויקט של שבוע. עבור רוב הצוותים, נכון להתחיל עם פלטפורמה מנוהלת שכבר פותרת את שכבת הבידוד (למשל E2B, Modal, או Sandboxes מובנים בענן), ולהשקיע את הזמן שלכם בלוגיקה העסקית של הסוכן עצמו. הסף שבו כדאי לבנות Runtime מותאם הוא בדרך כלל כשיש דרישות רגולטוריות ספציפיות (נתונים שאסור שיצאו מאזור מסוים), כשעלות הפלטפורמה המנוהלת הופכת משמעותית בסקייל, או כשצריך אינטגרציה הדוקה מאוד עם תשתית קיימת שפלטפורמה כללית לא תומכת בה. בכל מקרה, ההחלטה הזו צריכה להתקבל מודעת לעלות התחזוקה השוטפת — Runtime הוא רכיב שדורש עדכוני אבטחה קבועים, בדיוק כמו כל שכבת בידוד אחרת בתשתית.

שיקול נוסף שלרוב נשכח בשלב התכנון הוא זמן ה-Cold Start. אם כל הרצת סוכן דורשת הקמת microVM חדש מאפס, הסוכן עלול להמתין שניות ארוכות לפני שהוא בכלל מתחיל לעבוד — פער שמורגש מאוד במשימות אינטראקטיביות שבהן משתמש ממתין לתשובה בזמן אמת. פלטפורמות מנוהלות בשלות פותרות את זה עם Pool של סביבות "חמות" שמוכנות מראש ומוקצות לפי דרישה, אבל אם בונים Runtime עצמאי, ניהול Pool כזה — כולל מדיניות מחזור חיים (מתי לסגור סביבה לא בשימוש, איך מוודאים שהיא נוקתה לגמרי לפני שהיא חוזרת ל-Pool כדי שלא ידלפו נתונים בין הרצות) — הופך לפרויקט הנדסי בפני עצמו, ולא פחות מורכב מבניית שכבת הבידוד המקורית.

תגיות: Agent Runtime · Sandboxing · Firecracker · gVisor · Multi-Tenant Isolation · Observability

← חזרה לבלוג · צור קשר