הפתרון להרס שסוכני AI עושים בטרמינל נמצא בפקודה הבודדת

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

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

מחקר חדש שהתפרסם ב־30 בספטמבר 2026 מציג גישה שונה לחלוטין. המאמר ב־arXiv, בהובלת החוקרים Minki Kang ו־Byung-Kwan Lee, מציע לא לבזבז זמן על הרצת משימות שלמות מההתחלה בכל פעם שהסוכן נתקע. במקום להריץ מסלולים מלאים שוב ושוב, מקצים את משאבי החישוב בבדיקה ישירות בין המודל למעטפת הטרמינל.

פקודה אחת לא נכונה

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

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

לבדוק לפני שהטרמינל מבצע

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

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

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

מספרים שמצדיקים את הסיבוך

המספרים במבחן TerminalBench-Lite מראים שהרעיון עובד בשטח. לפי נתוני המסמך המלא ב-HTML, כאשר השתמשו במודל הבסיסי TMAX-9B לבדו, הוא השיג שיעור הצלחה של 50.00% במדד Pass@1. ברגע שהוסיפו את Mid-Harness עם דגימה של 8 פעולות ומאמת מסוג GPT-5.6 Sol, שיעור ההצלחה זינק ל-68.03%. לפי החוקרים, השיטה שיפרה את התוצאות גם על פני מודלים, מבחנים ומעטפות הרצה נוספות.

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

בלי שופט אין תועלת

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

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

החוקרים בדקו גם מה קורה כשמשתמשים באותו מודל TMAX-9B כיוצר וגם כמאמת, ומצאו כי אימות בזוגות (pairwise verification) השיג את התוצאות הטובות ביותר מבין מנגנוני האימות שנבדקו. בנוסף, זיכוך (distillation) של תגובות ממאמת חזק לתוך TMAX-9B שיפר את מדד Pass@1 בלי לשנות את מודל יצירת הפעולות.

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

ההחלטה שלכם לשרת

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

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

אז לא, אל תתנו לו הרשאות root עדיין.

שאלות ותשובות

מה שואלים על זה

האם צריך לאמן מחדש את המודל שיוצר את הפקודות?

לא. המנגנון פועל לחלוטין בזמן בדיקה וריצה (test-time compute) ומותיר את המודל היוצר ואת סביבת ההרצה ללא שום שינוי או אימון מחדש.

האם השיטה מבטיחה אפס טעויות הרסניות בסביבת ייצור?

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

האם אפשר להשתמש באותו מודל גם ליצירה וגם לבדיקה?

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

מקורות

1. Mid-Harness: Scaling Actions Between Model and Harness for Terminal Agentsarxiv.org · המקור
2. What is MathJax? - arXiv infoinfo.arxiv.org · דוקומנטציה
3. גרסת ה-HTML המלאה והנספחים של מאמר Mid-Harness ב-arXivarxiv.org · קריאה נוספת
4. Minki Kangarxiv.org · מקושר מההודעה
5. Byung-Kwan Leearxiv.org · מקושר מההודעה

איך בדקנו

20 עובדות בכתבה נבדקו אחת־אחת מול המקורות המקושרים ומול חיפוש ברשת ב־1 באוקטובר 2026. מה שלא אומת הוסר או מסומן כטענה של החברה. הכתיבה נעשתה בעזרת AI מהמקורות האלה בלבד, בעריכה ובאחריות של סלבה מלנדוביץ׳. טעות? כתבו לנו.