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

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

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

זה היה העידן בו כולם קידשו את היכולת לנסח הנחיה מדוייקת - Prompt Engineering.

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

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

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

כך נולד השלב הבא, Context Engineering.

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

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

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

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

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

מידע נוסף על הנדסת הקשר תוכלו ללמוד במאמר הבא:
הנדסת הקשר - מיומנות חדשה שמגדירה את האבולוציה של מערכות הצ'ט.

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

הבעיה השלישית היא סיכון תפעולי. סוכן שמחובר לכלים יכול לבצע פעולות לא רצויות אם אין גבולות והרשאות ברורים.

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

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

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

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

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

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

לסיכום להלן השוואה של שלושת שלבי ההנדסה בעולם ה AI

סעיף השוואה	Prompt Engineering	Context Engineering	Harness Engineering
מיקוד מרכזי	שיפור ניסוח ההוראה למודל	מתן ההקשר הנכון למודל	בנייה והרצה של מערכת AI אמינה מקצה לקצה
שאלת המפתח	מה כדאי לבקש מהמודל?	איזה מידע המודל צריך לקבל כדי לבצע את המשימה?	איך גורמים למערכת לעבוד בצורה אמינה, מבוקרת ומדרגית?
היקף הפעולה	אינטראקציה בודדת	שכבת מידע סביב המשימה	מערכת מלאה הכוללת מודל, כלים, הרשאות, בדיקות, תיעוד ואורקסטרציה
יעד האופטימיזציה	איכות התשובה הנקודתית	איכות ההקשר שמוביל לתשובה מדויקת יותר	איכות המערכת כולה לאורך זמן
תוצאה רצויה	תשובות טובות וברורות יותר	תשובות מדויקות, רלוונטיות ומותאמות יותר	תהליך עבודה אמין, ניתן למדידה ובעל השפעה עסקית
דפוס כשל נפוץ	ניסוח לא ברור שמוביל לתשובה חלשה	מידע חסר או לא רלוונטי שמוביל לתוצאה שגויה	ירידה באיכות לאורך זמן, טעויות חוזרות או פעולה לא מבוקרת של הסוכן
כלים נפוצים	ניסוח פרומפטים, הגדרת תפקיד, דוגמאות, פורמט תשובה	RAG, מסמכים, זיכרון, MCP, היסטוריית שיחה, מקורות ידע	בדיקות, Guardrails, CI/CD, לוגים, ניטור, הרשאות, תתי סוכנים, אורקסטרציה ולולאות שיפור
תדירות שינוי	משתנה בכל בקשה או משימה	דינמית לפי המשימה והמידע הדרוש	יציבה יותר, כחלק מתשתית מערכתית שמתעדכנת בעקבות כשלים ושיפורים
לולאת משוב	לרוב אין לולאת משוב מובנית	שיפור ההקשר לפי הצורך	לולאה מתמשכת של כשל, ניתוח, תיקון ומניעה עתידית