הארנס
מה זה AI Harness Engineer, ולמה סוכנים נשברים בפרודקשן
אורן עובד · 2 בנובמבר 2026 · כ-7 דקות קריאה
הדמו תמיד עובד. הסוכן עונה יפה, כותב קוד, מתקן את עצמו. ואז מחברים אותו לעסק אמיתי, עם לקוחות שמחכים לתשובה ועם כסף שיוצא מהחשבון, ובתוך שבועיים משהו נשלח בלי שאדם קרא אותו, או שסקריפט דיווח הצלחה בזמן שלא עשה דבר. את הפער הזה אני סוגר במקצוע.
כשאני אומר שאני AI Harness Engineer, אנשים שומעים "בונה סוכנים". זה לא מדויק. את הסוכן עצמו היום כל מפתח מקים בכמה שעות. אני בונה את מה שמסביב לו: המעטפת שקובעת מה מותר לו, מה הוא זוכר, איך בודקים את מה שהוא מוציא, ומתי אדם חייב לאשר. במילה אחת, הארנס. בלי הארנס, סוכן הוא הדגמה. עם הארנס, הוא עובד שאפשר לתת לו מפתחות.
המעבדה שלי היא המערכת שמריצה את העסקים שלי, כולל חנות אונליין שאני מפעיל מאפריל 2023. כל מה שכתוב כאן נבדק קודם על הכסף שלי.
ממה הארנס בנוי
אין פה קסם, ורוב הרכיבים נראים משעממים על הנייר. זה בדיוק מה שהופך אותם לעמידים.
- שערים אכופים בקוד. כל פעולה שנוגעת בכסף, בפרסום או בהודעה ללקוח עוברת שער שכתוב בקוד ולא בהנחיה למודל. סקריפט השליחה של המיילים אצלי מקבל אך ורק רשומות שסומנו
APPROVED. אם הסוכן "החליט" לשלוח, אין לו דרך טכנית לעשות את זה. ההבדל בין הנחיה בפרומפט לשער בקוד הוא ההבדל בין בקשה לחוק. - אישור אנושי ברזולוציה של פעולה אחת. "אשר הכל לסשן" הוא לא ברירת מחדל אצלי. אישור ניתן לפעולה מדויקת, עם תוקף קצוב, ואם הוא פג זה כשל ניטור שנרשם. למדתי את זה בדרך הקשה: בקשת אישור שממתינה נראית בדיוק כמו סוכן שעובד, ואם אין ווטשר שמסתכל עליה, היא פגה בשקט ושעה של עבודה הולכת לאיבוד.
- פנקסים. כל פנייה יוצאת, בכל ערוץ, נרשמת בפנקס אחד. שאלה כמו "הלקוח ענה?" נענית מהפנקס ומהערוץ, אף פעם לא מהזיכרון של הסוכן. טענה שלילית ("לא ענו", "לא קיים") פסולה אצלי בלי ציטוט של הפקודה שהריצו ושל הפלט שחזר.
- dry-run כברירת מחדל. סקריפט שמפרסם, מוחק או כותב למערכת חיצונית רץ כברירת מחדל בלי לכתוב, ומדפיס מה היה עושה. כתיבה אמיתית דורשת דגל מפורש. ההיפך, כתיבה כברירת מחדל ודגל ל"רק להציג", הוא תאונה שמחכה.
- ווטשרים שבודקים דאטה. בדיקה מתוזמנת שמסתכלת על התוצאה עצמה: האם נוצר קובץ, האם הפיד מלא, האם ההודעה קיבלה מזהה. קוד יציאה אפס מודד שהסקריפט לא קרס. הוא לא מודד שהסקריפט היה שימושי.
- הוכחת מסירה. "נשלח" נאמר רק כשיש מזהה מהערוץ עצמו. שורה שנכתבה לתור היא לא שליחה. קובץ שמחכה בתיקייה זמנית הוא לא מסירה.
- לקחים כתובים. כל כשל שעלה בכסף או באמינות הופך לקובץ קצר: מה קרה, מה ציפיתי, מה השתנה. הקבצים האלה נטענים לכל סשן של כל סוכן, כדי שטעות שכבר שולמה לא תחזור.
איך זה נשבר בפועל
הדוגמאות הבאות קרו אצלי. השמתי את הפרטים המזהים, אבל המנגנון זהה בכל מערכת שראיתי.
הכלי קטם בשקט. סוכן קרא שרשור מייל חי דרך כלי שמחזיר רק את חמש ההודעות הישנות, בלי לסמן שיש עוד. השרשור היה באורך שתים-עשרה הודעות. הסוכן דיווח שהלקוח לא ענה. הלקוח ענה שלוש פעמים. הכלי הנכון היה קיים כל הזמן; הכשל היה בחירת כלי. התיקון היה מרשם כתוב: לכל שאלת מצב יש כלי מוסמך אחד, והכלים האחרים פסולים לשאלה הזאת.
קוד יציאה אפס במשך חודשים. מנגנון מעקב אחרי התחייבויות ללקוחות רץ כל עשר דקות והחזיר הצלחה בכל ריצה. הפיד שלו היה ריק, וההתראות שלו הפכו לרעש שכולם למדו להתעלם ממנו. כשהתגלו החמצות, האבחנה הראשונה הייתה "אין מעקב, צריך לבנות". זו אבחנה נכונה עם מרשם שגוי: המנגנון היה שם, רק שבור. היום החוק הוא לבדוק מה קיים ולשאול מה בו שבור, לפני שבונים מקביל.
dry-run שלא היה dry. קריאה ל-API חיצוני עם פרמטר שנראה כמו מצב בדיקה יצרה ישות אמיתית במערכת של צד שלישי. הלקח נכנס לחוקה: אימות עושים רק בקריאות קריאה, וכתיבה בפועל דורשת דגל מפורש שלנו, לא פרמטר של מישהו אחר.
"בוצע" לפני שבוצע. תשובה אנושית ללקוח הבטיחה זיכוי. איש לא ביצע אותו בפועל במערכת. השיחה נסגרה כ"טופל". היום "טופל" נאמר רק אחרי שבודקים את הרשומה החיה, לא את ההודעה.
המשותף לכולם: בכל המקרים המודל פעל נכון על מידע שגוי, או על מנגנון שהציג הצלחה ריקה. ככה סוכנים נשברים בפרודקשן, ובגלל זה מודל טוב יותר לא היה מונע אף אחד מהם.
המערכת במספרים
כדי שזה לא יישמע תיאורטי, הנה מה שרץ אצלי. המספרים נמדדו ישירות מהריפו ב-31/10/2026, קוד במעקב git בלבד.
שני המספרים שמעניינים אותי יותר מכולם הם דווקא הקטנים. 72 משימות מושבתות בכוונה: ווטשר שהציף פעם אחת מושתק, כי ערוץ רועש שווה פחות מערוץ שלא קיים. ו-821 לקחים: כל אחד מהם הוא מנגנון בקרה שנולד מכשל אמיתי, ולא רשימת תכונות שתוכננה מראש.
הסתייגות שאני אומר בעצמי: רוב הקוד הזה נכתב על ידי מודלים, בהכוונה שלי, ושלושה ספקי מודלים שונים עובדים בו יחד תחת חוקה כתובה אחת. המיומנות היא הארכיטקטורה, פירוק המשימות וניסוח מפרט שמודל מסוגל לבצע. מי שמציג את זה כקוד שנכתב ביד מפספס את הטענה החזקה יותר.
מה הארנס לא פותר
אני לא רוצה למכור שקט נפשי שאין לי. הארנס מצמצם את טווח הנזק, הוא לא מאפס אותו. סוכן עדיין יכול להבין בקשה הפוך. ווטשר יכול להיות מכוון על המדד הלא נכון. ושער שמוגדר רחב מדי חוסם עבודה לגיטימית עד שמישהו מרפה אותו יותר מדי. בשנה האחרונה אני עדיין מאשר בעצמי כל הוצאה, כל שינוי בפרסום וכל הודעה ללקוח שאינה תבנית מאומתת. זה הגבול שהגדרתי לאוטומציה, והוא זז רק אחרי שמנגנון ספציפי מוכיח את עצמו בתקופה מוגדרת.
אם יש שאלה אחת שאני ממליץ לשאול לפני שמשחררים סוכן על מערכת אמיתית, היא פשוטה: מה חסמת אותו מלעשות, ואיך תדע כשהוא ניסה בכל זאת.
מייסד OpticoAI ו-Gevurah, AI Harness Engineer עם 15+ שנה באיקומרס. בונה מערכות סוכני AI שרצות בפרודקשן על עסקים אמיתיים, כולל חנות אונליין משלו.