סוכנים בפרודקשן
למה סוכן AI שעובד בדמו נשבר בפרודקשן
אורן עובד · 4 בנובמבר 2026 · כ-9 דקות קריאה
כל סוכן AI עובד בדמו. הדמו נבנה על נתונים נקיים, בשעה נוחה, עם משתמש אחד שיודע מה לבקש. פרודקשן הוא כל השאר. אחרי תקופה ארוכה של הפעלת סוכנים על עסקים אמיתיים, כולל החנות שלי, למדתי שהפער בין השניים כמעט אף פעם לא נמצא במודל. הוא נמצא בעולם שמסביב.
במאמר על AI harness תיארתי את המעטפת שאני בונה סביב סוכנים. כאן אני רוצה להסתכל מהצד השני: מה בדיוק משתנה כשסוכן יוצא מהדמו, ואיפה זה שובר אותו. חמשת הדברים הבאים חסרים כמעט בכל דמו שראיתי, והם אחראים לרוב הכשלים שלי.
1. נתונים אמיתיים מלוכלכים
בדמו כל כתובת מלאה, כל מוצר עם מחיר, כל הודעה בעברית תקינה. בעולם האמיתי לקוח כותב את שם העיר באנגלית, שוכח מיקוד, או מדביק בצ'אט את כל ההודעה הקודמת שלו. הסוכן מבין את הבקשה מצוין. המערכת שהוא מעביר אליה את הנתונים לא.
דוגמה מלפני כמה ימים: הזמנה עם שם עיר באנגלית נכשלה ביצירת תווית משלוח. השירות של חברת השילוח החזיר שגיאת שרת כללית, בלי לומר מה לא בסדר. הסוכן ניסה שוב, קיבל אותה שגיאה, ודיווח שהשירות למטה. השירות לא היה למטה. הוא פשוט דורש שם עיר בעברית ומיקוד, ולא אומר את זה.
מה עוזר: לבדוק את הקלט לפני שהוא יוצא למערכת חיצונית, ולתרגם שגיאות כלליות לסיבות ידועות. כל פעם שאני מגלה סיבה כזו, היא נכתבת כלקח, והבדיקה נכנסת לכלי.
2. זמן
דמו רץ עכשיו. פרודקשן רץ גם מחר, בשבת, בחג ובסוף החודש. הרבה באגים שלי היו באגים של זמן, והם הכי קשים לזיהוי כי ביום שבו כתבתי את הקוד הכל עבד.
- טסטים עם תאריך אמיתי. טסט שנבנה על נתונים מתאריך מסוים עובר היום ונכשל בעוד חודש, כשהתאריך כבר "בעבר". הפתרון הוא לנעוץ את השעון בתוך הטסט.
- חג של שלושה ימים. המערכת שלי נועלת תקשורת יוצאת בשבת וחג. כשחג נצמד לשבת ויוצר רצף של שלושה ימים, לוח הזמנים נראה בדיוק כמו לוח שבור. ווטשר שלא מכיר את המקרה הזה יתריע על תקלה שאינה קיימת, או גרוע מזה, "יתקן" אותה.
- חלונות זמן של ערוצים. בוואטסאפ עסקי אפשר לשלוח הודעה חופשית רק בתוך 24 שעות מההודעה האחרונה של הלקוח. הודעה שתוזמנה ליום אחרי כבר לא תצא, והמערכת תדווח אפס שגיאות.
3. מגבלות וקצב
בדמו שולחים עשר בקשות. בפרודקשן שולחים אלף, ואז כל שירות חיצוני מתחיל לסרב. ממשק של חנות מחזיר "יותר מדי בקשות" אחרי כמה עשרות קריאות רצופות. תיבת מייל מפסיקה לשלוח לשעות. מסנן אבטחה באתר מזהה את הסוכן כבוט וחוסם את כתובת ה-IP.
הטעות המסוכנת כאן היא לפרש סירוב כזה כתוצאה. אם בדיקה של אתר חי מקבלת "יותר מדי בקשות", היא לא בדקה כלום. זה לא כשל של האתר וזו לא סיבה לבטל שינוי. זו מדידה שלא התקיימה, וצריך לומר את זה במילים האלה. אצלי שגיאת קצב בבדיקה מסומנת "לא נבדק", ולא "נכשל".
ומסנן אבטחה לא עוקפים. מאטים, עוצרים, וממשיכים מאוחר יותר. סוכן שמחפש דרך מסביב לחסימה הוא סוכן שיחסום לך את האתר.
4. דברים שקורים במקביל
בדמו יש סוכן אחד ומשתמש אחד. בפרודקשן יש כמה סוכנים, כמה תהליכים מתוזמנים, ואדם אחד שעובד באותו זמן באדמין. כל אחד מהם יכול לשנות את מה שהשני קורא.
שלושה דברים כאלה קרו אצלי:
- שכבת הבקרה הייתה איטית לענות, ולכן כל בדיקה "האם היא חיה?" הפעילה עותק נוסף. בבוקר אחד רצו שבעה עותקים במקביל, והסוכן שעבד דרכם נתקע. הבעיה לא הייתה בסוכן. היא הייתה בבדיקה שהניחה שאיטי פירושו מת.
- סדר ידני שקבעתי בקולקציה בחנות נדרס למחרת בבוקר על ידי מנוע סידור אוטומטי שרץ כל יום. שני המנגנונים עשו בדיוק את מה שתוכננו לעשות.
- סוכן לקח לידיו שלב שהועבר קודם לסוכן אחר, ולא עדכן אותו. שניהם עבדו על אותו דבר.
הכלל שיצא מזה: לפני שמאבחנים "הסוכן נתקע", סופרים כמה תהליכים באמת רצים. ולפני ששינוי ידני נחשב גמור, בודקים אם יש מנגנון שרץ מחר ומשנה את אותו דבר.
5. מערכות של אחרים
הסוכן מדבר עם ממשקים שלא אני כתבתי, והם מתנהגים בדרכים שהתיעוד לא מספר. שתי דוגמאות שעלו לי זמן:
- קריאה חוזרת שמחזירה גרסה ישנה. אחרי כתיבה לחנות, קריאה מיידית החזירה לפעמים את הגרסה הקודמת, ובפורמט מעט שונה. השוואה בייט-לבייט בין מה שכתבתי למה שקראתי הכריזה על כשל, כשהכתיבה הצליחה. היום משווים אחרי נרמול, וקוראים שוב אחרי המתנה קצרה.
- Mock שמסתיר באג. קוד שרץ בענן עבר את כל הטסטים כי בטסטים פונקציית הרשת הייתה מדומה. בסביבה האמיתית אותה שורה נכשלה, בגלל פרט טכני באופן שבו הפונקציה נשמרה. הטסטים היו ירוקים והשירות לא עבד. מאז, אחרי כל פריסה יש הרצת ניסיון אחת בסביבה האמיתית, לפני שמדליקים.
מה זה אומר לעסק שלך: כשבודקים ספק של סוכן AI, הדמו לא אומר הרבה. השאלות ששוות משהו הן אחרות: מה קורה כשהקלט חסר, מה קורה בשבת, מה קורה כשהשירות החיצוני מסרב, ואיך יודעים שמשהו באמת יצא.
איך מזהים מוקדם שזה קורה
הסימן הכי עקבי שראיתי הוא שקט. מערכת בפרודקשן שלא מדווחת על שום בעיה במשך שבוע היא כמעט תמיד מערכת שמשהו בה לא מסתכל. אצלי ווטשר אחד שלח במשך חודשים התראה אדומה על קמפיין שבכלל היה מושהה, וכולם למדו להתעלם ממנו. כשהגיעה התראה אמיתית, היא נבלעה ברעש.
לכן אני מחפש שלושה דברים. הראשון, מספרים שלא זזים: מונה שעומד על אותו ערך כמה ימים ברצף. השני, הצלחות בלי תוצר: ריצות שמסתיימות תקין אבל לא משאירות קובץ, רשומה או מזהה. השלישי, התראות שחוזרות על עצמן בלי שמישהו מגיב. כל אחד מהם אומר שהמערכת והעולם התחילו להתרחק, עוד לפני שלקוח שם לב.
למה זה כמעט אף פעם לא המודל
בכל חמשת הסוגים המודל הבין נכון. הוא קרא את הבקשה, בחר פעולה סבירה וניסח יפה. הכשל היה במידע שהוא קיבל, במגבלה שלא ידע עליה, או בבדיקה שאמרה לו "הצלחת" כשלא הצליח. החלפה למודל חזק יותר לא הייתה מתקנת אף אחד מהם, ולכן אני משקיע מעט מאוד זמן בבחירת מודל ביחס לזמן שאני משקיע בסביבה שלו.
יש גם פיתוי הפוך: כשמשהו נשבר, לבנות מנגנון חדש שיתפוס אותו. ברוב המקרים אצלי המנגנון כבר היה קיים, זיהה את הבעיה, וכתב אותה לקובץ שאף אחד לא קרא. החצי שחסר היה המסירה, ולא הזיהוי.
איך אני בודק לפני פרודקשן
- הרצת ניסיון כברירת מחדל. כל כלי שכותב לעולם מדפיס קודם מה היה עושה. כתיבה אמיתית רק עם דגל מפורש.
- קנרי קטן. שינוי שנוגע בהרבה רשומות רץ קודם על קבוצה קטנה, ונבדק, לפני שהוא רץ על הכל.
- בדיקה על המקרה שחשף את הבאג. תיקון נחשב גמור רק אחרי שהוא עובד על הרשומה האמיתית שנכשלה, ולא על דוגמה שבניתי.
- ראיה מהערוץ. "נשלח" נאמר כשיש מזהה מהערוץ עצמו. קוד יציאה אפס הוא לא ראיה.
- אדם רואה שינוי ויזואלי. שינוי בעיצוב של אתר חי לא נחשב גמור עד שמישהו הסתכל עליו בעיניים. קריאה חוזרת של הקובץ לא מספיקה.
אף אחד מאלה לא דורש טכנולוגיה מיוחדת. כולם דורשים להניח מראש שהעולם יתנהג אחרת מהדמו. את הצד הזה, הכנת סוכנים לעבודה אמיתית בעסק, אני עושה ללקוחות דרך OpticoAI. ואיך כל זה נראה ביום רגיל אצלי, כתבתי במאמר על עסק של אדם אחד עם צוות סוכנים.
שאלות נפוצות
למה סוכן AI שעבד בדמו מפסיק לעבוד אחרי ההשקה?
כי הדמו לא כולל נתונים מלוכלכים, זמן, מגבלות קצב, תהליכים מקבילים ומערכות חיצוניות שמתנהגות אחרת מהתיעוד. ברוב המקרים המודל עצמו ממשיך להבין נכון, והכשל נמצא בסביבה שלו.
האם מודל חזק יותר יפתור את הבעיה?
לרוב לא. מודל חזק יותר יקבל את אותו מידע חסר ואת אותה תשובת "הצלחה" מבדיקה שבורה. השקעה בבדיקות, בשערים ובהוכחת מסירה מחזירה יותר.
איך בודקים סוכן לפני שמחברים אותו לעסק?
מריצים אותו בהרצת ניסיון שלא כותבת כלום, מעבירים קבוצה קטנה של מקרים אמיתיים, ובודקים בכל פעולה שיש ראיה מהמערכת עצמה שהיא קרתה. רק אחרי תקופה שקטה מרחיבים.
מה השאלה הראשונה לשאול ספק של סוכן AI?
מה קורה כשמשהו נכשל באמצע: איך המערכת יודעת, מי מקבל התראה, ומה מונע ממנה לדווח הצלחה כשלא הייתה.
מייסד OpticoAI ו-Gevurah, AI Harness Engineer עם 15+ שנה באיקומרס ובשיווק דיגיטלי. בונה מערכות סוכני AI שרצות בפרודקשן על עסקים אמיתיים, כולל חנות אונליין משלו.