יצירת סוכן AI עם Code Interpreter: הרצת קוד ב-sandbox

סוכן AI עם code interpreter: היכן זה נשבר במשימות אמת

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

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

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

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

בהמשך נפרט איך זה נסגר.

מה נותן ביצוע קוד מנוהל בסוכן

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

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

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

• אותה בקשה ואותה סביבה נותנות אותו ארטיפקט — התוצאה ניתנת לבדיקה חוזרת לפני מסירה ללקוח.
• כשל בשלב אחד לא מפיל את השירות: הסביבה נבנית מחדש ממצב נקי, והשחזור אורך דקות.
• מגבלות זמן, זיכרון ודיסק חוסמות לולאה לפני שהיא תופסת את המתחם המשותף.
• גישה לרשת לפי רשימת כתובות סוגרת דליפת נתונים החוצה.

השורה התחתונה — צריכת משאבים צפויה וחזרתיות במקום תקווה להרצה מוצלחת: גבולות ההרצה, העקבות שלה והמגבלות מוגדרים מראש.

מצבי עבודה של code interpreter: השוואת גישות

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

הרצה מקומית: היכן היא מתאימה

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

sandbox בתשתית הלקוח

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

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

איך אנחנו מטמיעים את הסוכן: שלבי עבודת הנדסה

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

1. ביקורת תרחישי הסוכן — מפרקים אילו משימות הוא פותר, היכן הוא מבצע קוד, אילו נתונים קורא ולאן כותב. התוצאה — מפת תרחישים עם רשימת פעולות ונקודות שבהן נדרשת בדיקה אנושית.
2. תכנון סכימת הבידוד — קובעים באיזו סביבה מבוצע הקוד, באיזו תדירות היא נבנית מחדש ומה נשאר בין הרצות. את הסכימה בודקים משני צדדים: מה הסוכן יכול לשבור ומה יכול לדלוף.
3. הגדרת הרשאות ומגבלות — נותנים רק את הגישות הנדרשות: תיקיות מסוימות, רשימת כתובות מותרות, הגבלות על זמן ביצוע ונפח כתיבה. כל מה שחורג מהמסגרת פשוט לא מבוצע.
4. חיבור מקורות נתונים — הסוכן מקבל קבצים, מסד נתונים ושירותים חיצוניים שאיתם הוא עובד. כל חיבור עובר דרך אותה בקרת הרשאות.
5. הרצה על משימות אמת — בודקים תרחישים יחד עם כשלים צפויים: קלט שגוי, שירות לא זמין, חריגה ממגבלה. בודקים איך הסוכן מתאושש ומה נכנס ליומן.
6. קבלת הסוכן — אתם בודקים את התוצאה על המשימות שלכם לפי קריטריונים שסוכמו מראש. בנפרד מקבעים אילו כשלים נחשבים קבילים ואילו חוסמים את ההרצה.
7. מסירת הסכימה ונוהל הליווי — מוסרים תיאור ארכיטקטורה, כללי עדכון תרחישים וסדר פעולות בעת כשל.

מה מוסרים לידיים: קונפיגורציות, מדיניות ונהלים

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

• קונפיגורציית סביבת ההרצה: תיאור image בסיסי, רשימת ספריות מקובעת, כללי גישת רשת, נקודות mount של קבצי עבודה.
• מדיניות גישה: תפקידים והרשאות, תוחלת חיים של מפתחות, סדר רוטציה של סודות, הפרדה בין מתחם בדיקה למתחם עבודה.
• מגבלות משאבים: זמן מקסימלי להרצה אחת, נפח זיכרון ודיסק לסשן, מספר סשנים במקביל, התנהגות בעת מיצוי מכסה.
• מטריצת כלי הסוכן: אילו קריאות מותרות אוטומטית, אילו דורשות אישור מפעיל, ואילו סגורות לחלוטין.
• סכימת אחסון ארטיפקטים: היכן נמצאים קבצי ביניים, איך מוגדרת פקיעתם ואיך מוחקים נתונים לפי בקשה.
• תיעוד נמסר: הוראות פריסה, רשימת תלויות, תיאור משתני סביבה, נקודות חיבור ליומנים ולמדדים.
• מערך בדיקות: תרחישים לבקשות טיפוסיות, בדיקות למיצוי מגבלות, בקרת איכות של תשובות סופיות לפני העלאה.
• נוהל ליווי: רמות תגובה לכשלים, חלונות עדכון של imageים וספריות, סדר rollback לגרסה קודמת.

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

מקרה בוחן: יציבות הסוכן לפני ואחרי בידוד קוד

פלטפורמת אנליטיקה של הלקוח העבירה חישובים לסוכן AI: הוא כתב קוד לפי בקשת המשתמש והריץ אותו ישירות בתהליך ה-API.

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

שיעור המשימות שנכשלו עמד על 18%, וניתוח כל נפילה לקח למהנדס תורן שעות: לפי הלוגים אי אפשר היה להבחין בין שגיאת הסוכן לנפילת התהליך המשותף.

העברנו את הביצוע לסביבה מבודדת נפרדת מבוססת Docker: מערכת קבצים משל עצמה לקריאה בלבד, volume זמני לארטיפקטים, איסור על קריאות רשת ומגבלות קשיחות על מעבד וזיכרון לכל סשן. image עם סט ספריות מקובע נבנה מראש — קוד הסוכן לא מושך תלויות מהאינטרנט ולא שובר את הסביבה לשכנים.

מה השתנה בהתנהגות הסוכן

כשל של סשן הפסיק להיות כשל כללי: חישוב שנפל מסתיים לפי מגבלת זמן, והתור ממשיך לעבוד. שיעור המשימות שנכשלו ירד מ-18% ל-2%, וכשלים מסוג "הסוכן נתקע ולא מגיב" לא נותרו כלל ברבעון.

הרצות חוזרות של אותה בקשה נותנות תוצאה זהה ב-96% מהמקרים — קודם אי-התאמות נתפסו ידנית, כי הסביבה "צפה".

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

מה לעשות אם הסוכן כבר עובד בלי בידוד קוד?

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

מעבר של סוכן שכבר פרוס נראה כך: באשכול Kubernetes עולה לצדו סביבת ביצוע שנייה, הניתוב מוחלף לפי חלק מהתעבורה דרך flag, והתשובות מושוות לקודמות על אותה דגימת משימות. אי-התאמות מנותחות עד להחלפה מלאה, וה-rollback נעשה באותו flag.

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

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

ספקות טכניים נפוצים לגבי בידוד ביצוע

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

איך מנקים את הסביבה בין הרצות?

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

מה יקרה אם הקוד נפל או נכנס ללולאה?

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

נדון במשימה: נבנה סכימה לתרחיש שלכם

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

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

• סכימת הפתרון: מאין מגיעים הנתונים, באיזו סביבה מבודדת מבוצע הקוד, לאן מוחזרת התוצאה;
• גבולות הסביבה: ספריות זמינות, מגבלות רשת ומערכת קבצים, זמן חיים של התהליך;
• רשימת בדיקות ותרחישי בדיקה, כולל ענפי כשל והרצות חוזרות;
• הערכת היקף העבודה לפי שלבים עם סדר הרצה ונקודות בקרה;
• רשימת סיכונים ופתרונות שמסירים אותם לפני תחילת הפיתוח;
• נוהל תפעול: לוגים, מעקב שגיאות, סדר עדכון כללי הסוכן.

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