Harness Engineering: השלב הבא אחרי Prompt ו-Context Engineering

עוד באזז AI נחת אצלי בפיד לאחרונה: harness engineering. אני מודה שהתגובה הראשונית שלי למונח חדש כזה היא בדרך כלל ספקנות - עולם ה-AI טובע מונח חדש כל כמה חודשים. אבל הפעם זה באמת מתאר משהו אמיתי, ולדעתי שווה לעקוב איך הגענו לפה.

שלב ראשון: Prompt Engineering

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

שלב שני: Context Engineering

השינוי הבא היה סביב מה שנותנים למודל מעבר לפרומפט עצמו. במקום להסתמך רק על מה שהמודל למד באימון, אפשר למסור לו את הנתונים הפרטיים שלכם ברגע ששואלים אותו, וזה הפחית משמעותית הזיות. מכאן בא retrieval-augmented generation, RAG: שליפת רשומות פרטיות, מדיניות, או חומר ייחוס - כדי שהמודל יענה עם העובדות שבאמת מולו במקום מה שהוא חצי-זוכר מהאימון.

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

שלב שלישי: Harness Engineering

מה שמביא אותנו להיום. Harness engineering זה על הסביבה שבונים סביב המודל כדי שהוא יוכל באמת לפעול כסוכן, לא רק לענות על שאלה בודדת.

Harness טיפוסי כולל לולאת כלים (tool loop), כך שהמערכת יכולה להמשיך לחזור על עצמה, לקרוא לכלים ולבדוק תוצאות, עד שהמשימה באמת הושלמה - לא רק אחרי תשובה אחת. הוא כולל גם כלים ו-MCP servers, ה-APIs והמשאבים שהמודל יכול לקרוא אליהם במקום רק לחשוב בבידוד, וגם skills: במקום לנסות להסביר כל תרחיש אפשרי בפרומפט אחד, מנהלים תיקייה של קבצי skill, וכשמצב רלוונטי עולה הסוכן קורא את ה-skill המתאים ופועל לפיו. ברוב ה-harnesses יש גם מערכת זיכרון, כך ששיחה או משימה ארוכה לא מאבדת מעקב אחרי מה שקרה קודם, לפעמים אפילו זוכרת דברים מהרבה לפני הסשן הנוכחי, ובנוסף hooks: קטעי קוד קטנים שרצים לפני או אחרי קריאה לכלי, למשל כדי לוודא שפעולה אמורה באמת לקרות לפני שהיא נורית.

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

איך זה נראה בפועל

סוכני קידוד כמו Claude Code ו-Codex הם דוגמה נקייה: תסירו את הלולאה, את הגישה לכלים, את קבצי ה-skill, ואת הזיכרון, ומה שנשאר מתחת זה מודל רגיל. ה-harness סביבו הוא מה שהופך "לענות על שאלה" ל"באמת לסיים את משימת הקידוד".

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

איפה זה משאיר אותנו

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

להמשך העבודה

לחיבור בין הכלים לשגרת העבודה, קראו את מדריך מחסנית Agentic Engineering: ממשקים, מנויים ו־Skills ובחנו את הבחירות מול המשימות והמגבלות שלכם.