אינטגרציה של LangGraph עבור סוכני בינה מלאכותית מבוססי גרף

למה שרשראות קריאה לינאריות נשברות, ואילו LangGraph — לא

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

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

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

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

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

מה נותן LangGraph: אפקט מדיד של תזמור גרפי

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

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

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

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

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

מצבי הרצה של הגרף: השוואת גישות

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

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

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

שלבי הטמעת LangGraph בשירות פעיל

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

1. פירוק התרחישים הקיימים. מקבעים היכן השירות כבר מקבל החלטות: פיצולים, פניות למערכות חיצוניות, מקומות שבהם נדרש אדם. בפלט — מפת תהליכים עם כניסות, יציאות ונקודות כשל מפורשות.
2. סכמת הגרף. מגדירים צמתים, מעברים, תנאי עצירה והמצב שעובר בין הצעדים. את הסכמה מתאמים לפני הקוד — בה מיד רואים לולאות, מבויים ותרחישים שבהם הסוכן עלול להיתקע בלולאה.
3. העברת הלוגיקה. בדיקות קיימות, מגבלות וקריאות לשירותים הופכות לצמתים בגרף; כללי הוולידציה נשמרים. המסלול הישן נשאר פעיל, כדי שהמעבר יהיה הפיך.
4. בדיקת הסוכן על נתונים אמיתיים. מריצים פניות היסטוריות עם תוצאה ידועה וסופרים את שיעור ההחלטות הנכונות. פערים מנתחים לפי צעדים: רואים איזה צומת או מעבר בדיוק יצר את השגיאה.
5. הרצה תחת עומס. בודקים את ההתנהגות בזרם קרוב לזרם הייצור: זמן תשובה, חזרות, צריכה על קריאות יקרות. כאן גם מגדירים מגבילים וכללי חזרה ללוגיקה הקודמת.
6. מסירה לתפעול. מוסרים את סכמת הגרף, את התצורה, את יומני ההרצה והוראות לעריכת צמתים. בנפרד מתארים מה רואים בניטור ולפי אילו סימנים הצוות מבין שהסוכן סטה מההתנהגות הצפויה.

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

מה מוסרים לידיים: גרפים, מדיניות, תיעוד

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

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

מקרה בוחן: סוכן לעיבוד פניות הפסיק ליפול

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

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

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

מדדים לפני ואחרי

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

LangGraph או מתזמר עצמאי על פונקציות?

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

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

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

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

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

ספקות טכניים לפני תחילת האינטגרציה

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

מה קורה למצב במעבר בין צעדים?

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

אפשר להמשיך הרצה שנקטעה, ולא להתחיל מההתחלה?

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

איך מוסיפים ענף חדש בלי לשבור מערכת פעילה?

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

איך מנתחים למה הסוכן קיבל דווקא את ההחלטה הזאת?

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

נדון במשימה: איך מתחילים אינטגרציה של גרף

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

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

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

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