Agent Harness — השכבה החשובה שמודלים לבדם אינם מספקים

מאת צוות מדיה דיל · 12.08.2026 · Agent Infrastructure · 5 דק׳

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

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

מה בדיוק ה-Harness אחראי עליו

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

מעבר לביצוע הבסיסי, Harness טוב אוכף גם גבולות: מספר מקסימלי של סבבים (iterations) לפני עצירה כפויה, רשימת כלים מותרת שמונעת מהמודל "להמציא" קריאה לכלי שלא קיים, ואימות סכימה (schema validation) על כל קריאת כלי לפני שהיא בכלל מגיעה למערכת החיצונית. בלי האימות הזה, מודל שמחזיר JSON פגום — וזה קורה, גם במודלים חזקים — עלול לגרום לקריאת API עם פרמטרים שגויים, ולפעמים אף להשמיט פרמטר חובה שגורם לפעולה בלתי צפויה בצד השני.

טיפול בכשלים באמצע השרשרת

ההבדל בין Harness נאיבי ל-Harness פרודקשני נמדד בעיקר במה שקורה כשמשהו נכשל. קריאת כלי יכולה להיכשל מסיבות רבות: timeout ברשת, שגיאת הרשאות, נתונים לא תקינים, או שירות חיצוני שפשוט לא זמין כרגע. Harness נאיבי מעביר את השגיאה כאילו היא תוצאה רגילה, ולפעמים המודל פשוט "ממשיך הלאה" בלי להבין שמשהו נכשל. Harness טוב מבחין בין סוגי כשל: כשל זמני (timeout, rate limit) מטופל בretry עם backoff אוטומטי בשכבת התשתית, בלי לערב את המודל בכלל; כשל קבוע (הרשאה חסרה, נתון לא קיים) מדווח למודל במפורש כדי שיוכל להתאים את התוכנית שלו; וכשל חמור (חריגה מתקציב, ניסיון פעולה אסורה) עוצר את הריצה כולה ומעביר אותה לבדיקה אנושית.

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

Harness כנקודת האכיפה של מדיניות בטיחות

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

• Allowlist מפורש של כלים וסכימות פרמטרים מותרות
• סף לפעולות שדורשות אישור אנושי (human-in-the-loop) לפני ביצוע
• הגבלת מספר סבבים ותקציב טוקנים מקסימלי לכל ריצה
• לוג מלא של כל קריאה, כולל אלה שנחסמו על ידי המדיניות

Harness ומחזור החיים הארוך של המשימה

במשימות שנמשכות זמן רב — לא סבב אחד קצר אלא תהליך שעשוי להימשך שעות — ה-Harness הוא גם מי שאחראי לשמור checkpoint לאורך הדרך, כדי שאם התהליך נקטע (crash, restart, ניתוק) אפשר להמשיך מהנקודה האחרונה ולא מההתחלה. הנושא הזה מספיק עמוק בפני עצמו ומצריך דיון נפרד, המפורט במדריך Harness למשימות ארוכות טווח. חשוב להבין שה-Harness ושכבת ה-Checkpoints קשורים הדוקות: אין טעם לשמור checkpoint אם ה-Harness לא יודע לטעון אותו מחדש ולשחזר בדיוק את המצב שממנו הלולאה נעצרה, כולל ה-context שנצבר עד כה.

בונים Harness משלכם או משתמשים במסגרת קיימת

מסגרות סוכנים פופולריות (LangGraph, Agent SDKs שונים) מספקות Harness בסיסי מוכן, שמטפל בלולאת קריאה-ביצוע-תשובה, retry בסיסי, ולעיתים גם checkpointing. עבור רוב הצוותים זו נקודת התחלה טובה בהרבה מכתיבת לולאה מאפס. עם זאת, מדיניות הבטיחות הספציפית לעסק — אילו פעולות דורשות אישור אנושי, מה קורה כשחורגים מתקציב, איך בדיוק ממופים סוגי כשל שונים — כמעט תמיד דורשת התאמה מעל המסגרת הבסיסית. הטעות הנפוצה היא לסמוך על שה-Harness המוכן "כבר מטפל בזה", בלי לבדוק בפועל מה קורה כשקריאת כלי נכשלת שלוש פעמים ברציפות, או כשהמודל מבקש לבצע פעולה שלא הייתה בתוכנית המקורית. בדיקת התרחישים האלה מראש, לפני שהם קורים בפרודקשן על משתמש אמיתי, היא ההבדל בין Harness שנותן שקט נפשי לבין Harness שרק נראה כאילו הוא עושה את זה.

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

תגיות: Agent Harness · Tool Calling · Error Handling · Human-in-the-loop · Schema Validation

← חזרה לבלוג · צור קשר