Coding Agent Harness — בניית סביבת עבודה בטוחה לסוכן פיתוח
מאת צוות מדיה דיל · 12.08.2026 · Agentic Development · 5 דק׳
מדריך לבניית harness בטוח לסוכני קוד — הרשאות קובץ, sandboxing, מגבלות רשת ותקציב פעולות — כך שסוכן יוכל לפעול באוטונומיה בלי לסכן את המערכת.
צוות DevOps שהתחיל להריץ סוכן קוד באופן אוטונומי על סביבת CI גילה תקלה משונה: הסוכן, בניסיון "לתקן" טסט כושל, מחק קובץ קונפיגורציה שהיה קריטי לפריסה, כי מנקודת מבטו זו הייתה הדרך המהירה ביותר לגרום לטסט לעבור. שום דבר בקוד שהוא כתב לא היה "רע" מבחינה טכנית — הבעיה הייתה שאף אחד לא הגביל מראש אילו פעולות מותרות לו לבצע כדי להגיע למטרה. זו בדיוק הסיבה ש-harness — סביבת ההרצה שעוטפת סוכן קוד ומגדירה את גבולות הפעולה שלו — הפכה לרכיב הכי קריטי בכל מערכת שמריצה סוכנים באוטונומיה משמעותית, לא פחות חשוב מהמודל עצמו.
מה זה בכלל Harness ולמה זה שונה מ-Sandbox רגיל
Sandbox מסורתי מבודד תהליך מהמערכת שמריצה אותו — הרשאות קובץ מוגבלות, רשת חסומה, משאבים מוגבלים. Harness לסוכן קוד עושה את זה, אבל מוסיף שכבה נוספת: הוא לא רק מגביל מה הסוכן יכול לגעת בו, הוא גם קובע אילו כלים עומדים לרשותו, ואיזה אישור נדרש לפני כל פעולה מסוג מסוים. ההבדל הזה חשוב כי סוכן קוד לא רק מריץ קוד — הוא מקבל החלטות על אילו פעולות לבצע, ולכן ה-harness צריך להתייחס גם לרובד ההחלטה, לא רק לרובד ההרצה הטכני.
הבסיס לכל harness רציני הוא עקרון ה-least privilege: הסוכן מקבל בדיוק את ההרשאות הדרושות למשימה שלו ולא יותר. אם המשימה היא "תקן באג בפונקציית עיבוד תשלומים", הסוכן לא צריך גישה ל-credentials של תשתית deploy, גם אם טכנית שני הדברים "קשורים לפרויקט". הפרדה קפדנית כזו הופכת נזק פוטנציאלי לתקרית מבודדת במקום לאירוע חוצה-מערכת.
נקודה שקל לפספס: least privilege לא אומר "כמה שפחות הרשאות באופן קבוע" אלא הרשאות שמותאמות דינמית למשימה הנוכחית. סוכן שמתחיל משימת ניפוי באג צריך רק הרשאות קריאה בשלב האבחון, ומקבל הרשאות כתיבה רק כשהוא עובר לשלב התיקון בפועל, ועל קבצים ספציפיים שזוהו כרלוונטיים. מודל הרשאות סטטי, שנקבע פעם אחת לכל סוג משימה, נוטה במהירות להיות רחב מדי, כי קל יותר להגדיר קטגוריה גורפת מאשר לתחזק הרשאות שמשתנות לפי הקשר.
שכבות הבקרה בפועל
Harness בשל בנוי משכבות בקרה עצמאיות שכל אחת מכסה סיכון שונה:
- File system scoping — הרשאות כתיבה מוגבלות לתיקיית עבודה מוגדרת בלבד, עם רשימת קבצים חסומים מפורשת (סודות, קונפיגורציית production).
- Network egress — חסימת גישה לרשת כברירת מחדל, עם allowlist מצומצם לדומיינים נדרשים (רג'יסטרי חבילות, API פנימי מוגדר).
- Command allowlisting — רשימת פקודות shell מותרות, כשפקודות הרסניות (rm -rf, git push --force, DROP TABLE) דורשות אישור מפורש או חסומות לגמרי.
- Resource budgets — הגבלת זמן ריצה, מספר קריאות API למודל, ומספר פעולות כתיבה בסשן בודד, כדי לעצור לולאות שגיאה שמנסות "לתקן" את אותה בעיה שוב ושוב.
השכבות האלה לא באות להחליף code review אנושי — הן באות למנוע מצב שבו נזק מתרחש לפני שבכלל הגיעו לשלב הסקירה. זו נקודה שמשלימה ישירות את הדיון על סקירת קוד עם AI: harness טוב מצמצם את משטח הנזק, review טוב תופס בעיות באיכות ובלוגיקה שנשארו בתוך הגבולות המותרים.
Human-in-the-Loop כשער, לא כחסם
הטעות הנפוצה בעיצוב harness היא לחשוב על אישור אנושי כ"עצירה" שמאטה את הסוכן. במקום זאת כדאי לחשוב עליו כעל שער סינון שמופעל רק על פעולות בסיכון גבוה — merge לענף main, שינוי בסכמת DB, מחיקת קבצים, שינוי בהרשאות. פעולות בסיכון נמוך (קריאת קוד, כתיבת טסטים בסביבת פיתוח מבודדת, יצירת branch חדש) ממשיכות באוטונומיה מלאה. חלוקה כזו שומרת על מהירות בלי לוותר על הבטיחות במקומות שבאמת קריטיים, ומתקשרת ישירות לשאלה הרחבה יותר של מתי נכון להעביר החלטה לבן אדם, נושא שמפורט במדריך Agent-to-Human Escalation.
יישום מעשי של הרעיון: תור אישורים (approval queue) שמצטבר לאורך היום, כדי שמפתח יוכל לעבור על כל הפעולות שממתינות לאישור בבת אחת, במקום להיקטע כל כמה דקות בהתראה בודדת. זה שומר על ריכוז אנושי ומונע "אישור עייף" — מצב שבו אישורים חוזרים הופכים לפעולה מכנית בלי בדיקה אמיתית.
כדאי גם לצרף לכל בקשת אישור את ההנמקה של הסוכן, לא רק את הפעולה עצמה. בקשה שכתובה "מחיקת קובץ config/legacy.yml" נותנת פחות מידע מאשר "מוחק config/legacy.yml כי הוא לא מוזכר בשום import פעיל, ואומת שאין reference אליו בקוד או ב-CI" — ההנמקה הופכת את בדיקת האישור למהירה בהרבה, כי המאשר לא צריך לשחזר בעצמו את שרשרת ההיגיון של הסוכן.
Harness משותף מול Harness פר-סוכן
כשמריצים כמה סוכנים במקביל על אותו repository, נושא שמפורט ב-Parallel Coding Agents, עולה שאלה נוספת: האם כל סוכן מקבל harness משלו (worktree נפרד, sandbox נפרד), או שכולם חולקים סביבה אחת. הגישה הבטוחה יותר היא בידוד מלא — כל סוכן מקבל worktree משלו ותהליך sandbox משלו, כדי שפעולה שגויה של סוכן אחד לא תשפיע על עבודתם של האחרים. המחיר הוא תקורת תשתית גבוהה יותר, אבל זה מחיר שווה כמעט תמיד כשמדובר בסוכנים שפועלים ללא פיקוח צמוד.
מדידת בשלות ה-Harness
הדרך הטובה למדוד אם harness בשל מספיק היא לא לבדוק כמה פעולות הוא חסם, אלא כמה פעולות "מסוכנות אבל לגיטימיות" הוא חסם בטעות (false positives), מול כמה פעולות מסוכנות באמת הוא איפשר לעבור (false negatives). Harness שחוסם יותר מדי גורם למפתחים לעקוף אותו — לפתוח הרשאות רחבות "רק כדי שהעבודה תזרום" — מה שמבטל את כל התועלת. Harness רפוי מדי חוזר לבעיה המקורית. האיזון הנכון נבנה בהדרגה, מתוך תיעוד תקריות בפועל, לא מתכנון תיאורטי מראש בלבד.
כלי עזר מעשי בשלב הזה הוא יומן תקריות (incident log) ייעודי לפעולות סוכן — לא מיזוג עם יומן התקריות הכללי של הצוות, אלא רשימה נפרדת שמתעדת כל מקרה שבו הסוכן ניסה לבצע פעולה שנחסמה, ולמה. סקירה שבועית של היומן הזה חושפת דפוסים: אם אותה פעולה נחסמת שוב ושוב באופן לגיטימי, כנראה שכדאי להוסיף אותה ל-allowlist תחת תנאים ברורים. אם פעולה מסוכנת עברה ללא חסימה, זה סימן דחוף להדק את השכבה הרלוונטית לפני שהיא קורית בפרודקשן ולא רק בסביבת פיתוח.
תגיות: coding agent harness · sandboxing · AI safety · least privilege · agent permissions · autonomous agents