שלבי קוד (code_step)
חלק מהלוגיקות ייחודיות מדי עבור אופרטור compute, אך דטרמיניסטיות מדי כדי להצדיק agent LLM: הצלבות רב-מקורות, חישובים עסקיים מותאמים, נורמליזציות אקזוטיות. עבור מקרים אלה, הצומת code_step מבצע קוד ב-sandbox, ללא קריאת LLM, עם פלט צפוי.
הקוד נערך ישירות, כמו כל שדה תצורה אחר, ומתבצע ברגע שהוא נשמר.
מודל הביצוע
code_step מבצע Starlark — ניב של Python שתוכנן לבידוד: אין גישה למערכת הקבצים, אין רשת, אין import שרירותי, דטרמיניסטי, תחום בתקציב זמן. הקוד רואה רק:
- את הקלטים שמיפיתם לו במפורש (
input_paths). - את הtools שאתם מרשים לו לקרוא (
allowed_tools).
כל השאר מחוץ לטווח. שלב קוד אינו יכול להגיע למשאב שלא הגשתם לו.
תצורה
| שדה | תפקיד |
|---|---|
| קוד | קוד המקור Starlark שמבוצע, נערך ישירות. |
קלטים (input_paths) | מיפוי משתנה ← סלקטור. רק המפתחות הללו מהקונטקסט נחשפים לקוד. מפתחות פנימיים (_*) נדחים. |
| Allowlist tools | ה-tools הניתנים לקריאה דרך tool(שם, args). כל קריאה יורשת את מנגנוני ההגנה של ה-tool (SSRF, חיוב, audit, killswitch). |
| מפתח פלט | היכן להציב את התוצאה בקונטקסט. הצמתים שבזרם קוראים מפתח זה. |
| תקציב ביצוע | תקרת זמן (ms), מוגבלת בצד השרת. שלב שחורג נקטע. |
היכן גבול האבטחה
השפה אינה האיום: Starlark מבודד מעצם תכנונו — בכוחות עצמו הוא אינו יכול לקרוא קובץ, להגיע לרשת או ללולאה אינסופית. חישוב טהור אינו מסוכן.
היכולת היחידה הממשית היא גשר ה-tool(), והוא תחום על-ידי ה-allowlist הנאכף בזמן ריצה: הקוד יכול לקרוא רק ל-tools שרשמתם, וכל אחד נושא את מנגנוני ההגנה שלו (SSRF, חיוב, audit, killswitch). שם — בבחירת ה-tools — אתם תוחמים את מה ששלב יכול לעשות.
allowlist ריק = אין יכולת לתופעות לוואי: השלב רק מחשב על הקלטים שלו ומפיק פלט.
מתי להשתמש
- כן: לוגיקה דטרמיניסטית שאתם יודעים לתאר במדויק, אך חורגת מהפעולות המסופקות של
compute(פיוס כמה רשימות, כלל עסקי מורכב, פורמט קנייני). - לא: מסנן פשוט, אגרגציה, הקרנה — אופרטור
computeמספיק. - לא: משימה שדורשת שיפוט או כתיבה — זה agent, לא קוד.