תפסיקו לשפר פרומפטים: הנדסת סוכני AI

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

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

בניתי לא מעט מערכות אוטומציה בשנים האחרונות. ראיתי צוותים שורפים שבועות על ניסוח מחדש של הנחיות ל-Claude או GPT, רק כדי לגלות שהסוכן עדיין קורס כשהוא פוגש API אמיתי או קובץ פגום. הבעיה היא לא ב"מוח" של ה-AI, אלא במערכת ההפעלה שנתתם לו.

כדי להגיע לביצועים ברמת ייצור (Production), אנחנו צריכים לעבור מ"שיחות עם מודלים" ⁨להנדסת מערכות סוכניות⁩ (Agentic Systems). זה אומר להפריד בין המודל לבין המעטפת, הלולאות והגרפים שמנהלים אותו.

נקודות מרכזיות

• תקרת הזכוכית של ה-12%: למה מודלים חזקים יותר לא יפתרו את בעיות האמינות של הסוכנים שלכם.
• הנדסת מעטפת (Harness): בניית סביבת עבודה בטוחה שבה המודל הוא רק רכיב אחד בתוך מערכת גדולה.
• הנדסת לולאות (Loops): המעבר מניסיונות חוזרים אינסופיים לבקרה מבוססת ראיות ומגבלות תקציב.
• ⁨הנדסת גרפים⁩ (Graphs): ניהול זרימת העבודה באמצעות מכונת מצבים שמונעת מהסוכן ללכת לאיבוד.

למה המודל שלכם לא מצליח לסיים את המשימה

רוב הפרויקטים של סוכני AI נתקעים ב⁨שלב ה-Demo⁩. המודל נראה חכם בשיחה, אבל כשהוא צריך לבצע רצף פעולות בעולם האמיתי, הוא מאבד ריכוז. מחקר של Sakhinana ו-Runkana ממרכז המחקר של Tata הראה ששימוש במודל חזק ללא מעטפת מתאימה מוביל לשיעורי הצלחה נמוכים להחריד.

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

הנדסת מעטפת: הבית שבו הסוכן חי

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

מעטפת טובה כוללת:

1. זהות מוגדרת: הסוכן פועל עם הרשאות ספציפיות (RBAC), בדיוק כמו עובד אנושי.
2. סביבה מבודדת (Sandbox): הרצת קוד בתוך סביבה סגורה כדי ⁨למנוע נזק לתשתית הארגונית⁩.
3. אימות חיצוני: שימוש בכלים דטרמיניסטיים (כמו בדיקות יחידה או Linter) כדי לאשר את פלט המודל.

לפי הדיווח ב-Codex Knowledge Base, שימוש במעטפת קשיחה מבטיח שגם אם המודל טועה, הטעות נשארת מוגדרת ובטוחה.

הנדסת לולאות: להפסיק לנחש ולהתחיל לבדוק

לולאה היא לא סתם "תנסה שוב". הנדסת לולאות (Loop Engineering) עוסקת בעיצוב מחזור המשוב. במקום לשלוח פרומפט שאומר "תתקן את זה", אנחנו בונים לולאה שבודקת קוד שגיאה (Exit Code) ומחזירה למודל רק את המידע הרלוונטי לתיקון.

הלולאה חייבת להיות מוגבלת (Bounded). אם לא נגדיר ⁨תקציב טוקנים או מספר ניסיונות⁩ מקסימלי, הסוכן עלול להיכנס ללולאה אינסופית שתשרוף לכם את כרטיס האשראי ב-OpenAI תוך לילה אחד. המטרה היא להפוך חיפוש אינסופי לחישוב מוגדר.

הנדסת גרפים: המפה של תהליך העבודה

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

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

מקורות

• Towards Agentic Cloud Engineering: Graph and Loop Engineering with a Zero-Trust Agent Harness (arXiv)
• Agentic Cloud Engineering: How Graph, Loop, and Zero-Trust Harness Abstractions Make Bounded Autonomous Work Provable (Codex Knowledge Base)
• Agent Harness Engineering vs. Loop Engineering vs. Graph Engineering (Towards AI)

שאלות נפוצות

מה ההבדל בין הנדסת פרומפטים להנדסת מעטפת?

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

למה צריך להגביל את הלולאות של הסוכן?

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

האם הנדסת גרפים מתאימה לכל פרויקט AI?

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

דברים שחשוב לזכור

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

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