האתגרים הגדולים בפיתוח סוכני AI
בפוסט שפרסם אנדרו גרין (Andrew Green) בבלוג של n8n בתאריך 10 ביולי 2026, הוא מפרט כי לאחר שבחן מאות מסמכים טכנולוגיים של n8n, גוגל (Google), Gumloop ופלטפורמות נוספות, הוא ספר 75 יכולות שניתן לצפות מכלי לפיתוח סוכני AI להציע. עם זאת, הוא מציין כי ישנם היבטים רבים נוספים שניתן, שצריך או שכדאי לבצע עם סוכנים שלא נכללו בדוח הטכני הרשמי, והוא משתף כמה מהם כאן. הנושאים המרכזיים שטרם נפתרו במלואם בתחום זה, לדבריו, הם זהות סוכנים (Agent Identity), הרצה אמינה של סוכנים (Reliable Execution) וניתוח כוונות (Intent Analysis).
זהות סוכנים (Agent Identity)
לפי המאמר, סוכני AI נפלו בין הכיסאות של זהויות אנושיות לבין זהויות שאינן אנושיות, דבר המעורר קשיים מכיוון שאין כיום דרך מובנית לעקוב אחר סוכנים, הפעולות שהם מבצעים והבעלים שלהם. אם סוכן מסוים מחליט לבצע מחיקה המונית של נתונים, זהות היא הדבר שיכול לסייע לגלות היכן הוא פועל ומי יצר אותו. אנדרו גרין מציין כי איש עדיין לא פתר את בעיית הזהות באופן מלא, ואם מישהו טוען שעשה זאת, הדבר נעשה לרוב על ידי התאמה בדיעבד של טכניקות קיימות לסוכנים, מה שלא באמת עובד. הוא מדגיש כי המושג Auth נמצא במצב טוב יותר מאשר זהות (Identity), אך Auth הוא רק תת-קבוצה של זהות.
כאשר מריצים סוכנים בתוך n8n, למשל, אין דרך להגדיר באופן פורמלי את הזהות של הסוכן כך שיוענק לו תג זיהוי, ייקבעו עבורו מדיניות (policies), וינוטרו פעולותיו בסביבה הרחבה שבה הוא פועל. אמנם ניתן לשלב אותו עם ספקי זהות (IdPs) התומכים בסוכנים, אך הדבר כרוך בעבודה הנדסית עצמאית מצד המשתמש.
המקור מתאר כיצד להגדיר סוכן n8n מול מערכת Entra Agent ID של מיקרוסופט (Microsoft Entra Agent ID). המקור מונה את הרכיבים הבאים:
- מופע פעיל של n8n המותקן על Azure Container Apps, מאחורי HTTPS ingress, הכולל אחסון מתמשך מסוג Postgres ואחסון קבצים.
- תוכנית מתאר של Microsoft Entra Agent Identity Blueprint, ישות שירות (service principal) מסוג Agent Identity, וחשבון משתמש סוכן (Agent User account).
- תהליכי עבודה (workflows) ב-n8n לביצוע קריאה ל-Microsoft Graph, מנהל Auth (מתווך אסימונים / Auth Manager), ורכיב webhook הפועל מטעם הסוכן (on-behalf-of webhook) ומתקשר עם שרת Microsoft Graph MCP Server for Enterprise.
- קריאה מואצלת פעילה מסוג MCP.User.Read.All מתוך הסוכן.
לדברי אנדרו גרין, האפשרות הטובה ביותר להרצה זו באופן טבעי (natively) נכון להיום היא פלטפורמת Google Gemini Enterprise Agent Platform, המהווה יתרון ברור של פורטפוליו ענני רחב. לפי דברי אנדרו גרין, פלטפורמה זו מספקת זהות חזקה ומאומתת מבחינה טכנית עבור כל סוכן. באמצעות זהות הסוכן (Agent Identity), סוכנים יכולים לבצע אימות מאובטח מול שרתי MCP, משאבי ענן, נקודות קצה וסוכנים אחרים, כשהם פועלים בשמם או בשם משתמש הקצה. זהות הסוכן משתמשת באישור (credential) של הסוכן עצמו ובמנהל Auth של זהות הסוכן. מנהל ה-Auth יכול ליצור ולנהל ספקי Auth, שהם ההגדרות הספציפיות המשמשות להשגה, ניהול ואבטחה של מפתחות API, מזהי לקוח של OAuth, סודות לקוח של OAuth ואסימוני OAuth מואצלים של משתמשי קצה.
הרצה אמינה של סוכנים (Reliable Execution)
בנוגע להרצה אמינה, אנדרו גרין מסביר כי מודלי שפה גדולים (LLMs) מייצרים את הקוד, והסוכנים מריצים אותו. בדיוק כפי ששרת עלול לחוות תקלה זמנית ויש צורך לכבות ולהדליק אותו מחדש, גם סוכנים יכולים לחוות תקלות דומות. ארגונים רבים חווים את הקושי הזה, אך גרין מציין כי הוא רואה מעט מאוד גישות שיטתיות או דטרמיניסטיות להבטחת הרצה אמינה של סוכנים. קיים מגוון של כלים המנסים לפתור את הבעיה הזו, אך האימוץ שלהם אינו מהיר.
הכלי הפשוט ביותר שיכול להריץ קוד של סוכן הוא מפרש פייתון (Python interpreter). עם זאת, מצופה מכלי פיתוח סוכנים לבצע יותר מאשר הרצת פייתון פשוטה. המקור מונה את הרכיבים הבאים:
- מניעת בעיית "הסגן המבולבל" (confused deputy): סביבות הרצה מבודדות (כמו MicroVMs או Wasm) יכולות להריץ קוד AI שאינו מהימן בצורה בטוחה, או לספק גישה מוגבלת לרשת.
- עמידות (Durability): זיהוי כשלים, ביצוע ניסיונות חוזרים של שלבים (retry), שמירה על מצב (state), קביעת נקודות בדיקה (check points) ותיקוף של תוצאות.
- מקביליות (Concurrency): הקצאת משאבים וטיפול במצבים של "שכנים רועשים" כאשר השירותים משתנים בקנה המידה שלהם.
עמידות ומקביליות בהרצה
המאמר מתמקד בפירוט בשני ההיבטים האחרונים:
ראשית, עמידות הרצת הסוכן (Agent execution durability) – סוכנים עלולים להיתקל במגבלות קצב (rate limits) מצד ספק ה-LLM, לחוות פקיעת זמן של בקשה (timeout), או שסוכן בהתקנה עצמית עלול להישאר ללא זיכרון זמין. עמידות בהרצה יכולה לסייע להתאושש מאירועים כאלה על ידי: בדיקה שמשימות הסוכן אכן מבוצעות ושמירת השלבים שהושלמו; אם פעולת הסוכנים מופרעת, הם מתחילים שוב מאותה נקודה בדיוק שבה נעצרו; הבטחה שהסוכנים מורצים פעם אחת בלבד, ולא אפס או מספר פעמים; פעולות הסוכן כוללות מודעות לזמן כך שהן ממתינות להשלמת משימות אחרות או לוחות זמנים; וקיימת אפשרות לחזור אחורה ולנסות שוב אם הפלט אינו מניב תוצאה מתוקפת.
שנית, ניהול מקביליות (Concurrency) – סוכנים וסביבת האירוח הבסיסית שלהם מתחרים על זיכרון, מעבד (CPU) וקריאות רשת. כאשר סוכנים חולקים את אותה תשתית (כלומר, ללא הפרדה ביניהם), הפעלה אחת הצורכת משאבים רבים פוגעת בביצועים של כל שאר ההפעלות. ניהול מקביליות יעיל דורש אכיפת מכסות ברמת הליבה (kernel-level quota enforcement), תזמון בזמן אמת על פני עומסי עבודה מגוונים, ומנגנוני ויסות לחץ (backpressure) המונעים מהתפרצויות של הפעלות סוכנים להוביל לכשלים במערכות המשך.
כדי לתמוך במקביליות בשכבת התשתית, ניתן לאכוף מגבלות משאבים לכל הפעלה ברמת הליבה באמצעות cgroups. כמו כן, ניתן לתחזק את מצב האשכול בזמן אמת לצורך קבלת החלטות תזמון. בידוד ההפעלות עצמו מבוצע באמצעות גבולות של microVM או gVisor המונעים זליגת משאבים של "שכנים רועשים" בין סוכנים.
בשכבת ההרצה, ניתן לאכוף מגבלות מקביליות על הרצת תהליכי עבודה ועל קיבולת העובדים (workers), ובכך למנוע הרצה של משימות סוכן רבות מדי במקביל מול ספק LLM המוגבל בקצב או מול API חיצוני. זהו מנגנון ויסות לחץ (backpressure) ברמת תהליך העבודה, ולא בידוד משאבים ברמת החישוב. בקרות מקביליות נוספות כוללות תורות משימות, כמו הגבלת מספר המופעים של שלב או פונקציה הרצים במקביל. כלי זה שימושי למניעת שחיקה של מגבלות קצב של ה-LLM, אך הוא אינו מטפל בתחרות על המשאבים הבסיסיים בין ההפעלות השונות.
ניתוח כוונות (Intent Analysis)
בנוגע לניתוח כוונות, אנדרו גרין מציין כי מודלי שפה גדולים נוטים לסטייה (drift) מעצם טבעם, ופניות פשוטות כמו "בבקשה אל תסטה מהנושא" או הפעלת סוכן מתזמר (orchestrator agent) שיבקש ממנו "בבקשה אל תסטה" לא יועילו. המשתמשים ימצאו את עצמם ללא ספק במצבים שבהם סוכנים אינם משלימים את המשימה שהוקצתה להם, מבצעים משהו אחר, מדווחים על השלמה של עבודה לא גמורה, או פשוט יוצרים הזיות של תוצאות. לכן, יש צורך לנטר סטיית התנהגות כדי לקבוע האם הלוגיקה של הסוכן נותרת הולמת את היקף העבודה והבקשה שלו. ניטור זה דורש סריקה מתמשכת של השיחות ושל הרצת הקוד כדי לבדוק אילו ספריות הסוכן מעוניין להפעיל, מה הפונקציות שנקראו ישיגו בפועל, ומה ה-LLM מבצע מול מערכת ההפעלה. המערכת עוקבת אחר שדה הנימוק (reasoning) בתגובה ואחר שדה קריאת הכלי (tool call) בתגובה כדי להבין כל האצלה של לוגיקה ואת הסיבות לה. גרין מציין כי בעוד שקיימת עבודה רבה בתחום האבטחה למניעת הזרקות הנחיות (prompt injections) ובעיות סגן מבולבל, נעשתה מעט מאוד עבודה למניעת סטייה שאינה זדונית.
ניתן לבחור בין ניתוח כוונות מבוסס LLM לבין ניתוח כוונות שאינו מבוסס LLM:
מערכות ניתוח מבוססות LLM הן קלות ליישום ומתאימות לכל מטרה. החיסרון הוא שהשופטים המבוססים על LLM סובלים מאותן בעיות שהם מנסים לפתור. למרות זאת, המקור מונה את הרכיבים הבאים כחלק מניתוח זה:
- מדד הערכה הבוחן את הנכונות והלכידות של מסלול הפעולה של הסוכן.
- הערכה למדידת תזוזה ביעד השיחה הראשי של המשתמש או בתהליך העבודה במהלך הפעלה, ביחס לכוונתו המקורית כפי שהוצהרה בתחילה.
- הערכת מידת היעילות שבה כל פעולה מקדמת את הסוכן לעבר היעד.
מערכות ניתוח כוונות שאינן מבוססות LLM הן קשות יותר ליישום ומאופיינות בצורך בחשיבה מוקדמת, משימה מאתגרת בחברה המאופיינת בתרבות כתיבת קוד המבוססת על תחושות (vibe-coding). המקור מונה את הרכיבים הבאים כחלק מניתוח זה:
- שימוש במודלים המבוססים על מקודד בלבד (encoder-only models), דוגמת BERT או ModernBERT, שמבינים טקסט אך אינם מייצרים אותו, ושימוש בהם כדי להפיק פלט בינארי של כן או לא.
- מעקב (כלומר, כתיבה לבסיס הנתונים) האם הסוכן ביצע בהצלחה את כל יעדי המשתמש.
- הגדרת טווחי פעולה בלתי ניתנים לשינוי (immutable scopes) המאלצים את הרצת הסוכן לעבור דרך סט קבוע של שלבים, הניתנים להגדרה במהלך תהליך הנימוק או על ידי סוכן מתזמר.
- הגדרת גבולות ספציפיים למשימה, סמכות לביצוע משימות, הכלים הזמינים, והאם הסוכן רשאי ליצור סוכני משנה.
סיכום ודברים נוספים מהדוח
לסיכום, אנדרו גרין מסביר כי באיטרציה השנייה של הדוח הטכני, הצוותים העריכו כלים שונים אל מול 75 יכולות, החל מהרצת קוד וסביבות הרצה מבודדות ועד לאימות (authentication) ומתגי השבתה (killswitches). חלק מהתכונות הללו הפכו למוצרים בסיסיים נפוצים, בעוד שאחרות מהוות גורמי בידול ברורים. כמו כן, מצוין במאמר כי משתמשי n8n מגיעים ממגוון רחב של רקעים, רמות ניסיון ותחומי עניין. צוות הבלוג מעוניין להציג משתמשים שונים והפרויקטים שלהם בבלוג כדי להעניק השראה לקהילה. במאמר המקור לא מופיע כל אזכור להקשר ישראלי מקומי.