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

מדוע סוכן AI בדפדפן נשבר בממשקים אמיתיים

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

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

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

השהיה קבועה לא עוזרת כאן: בתגובה מהירה הרובוט מכה במקום ריק, בתגובה איטית הוא ממשיך הלאה בלי להמתין לנתונים.

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

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

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

מה נותן ניהול ממשק אדפטיבי במקום סקריפטים

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

עמידות לשינויים בממשק

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

קיצור זמן העיבוד

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

מחלקת כשלים שנעלמה

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

שחזור לאחר כשל בשלב

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

מצבי עבודה: תסריט, מעבר אוטונומי והיברידי

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

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

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

שלבי הטמעה: מניתוח תהליכים ועד מסירה

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

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

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

ערכת מסירה: תרשימים, תפקידי גישה, נהלים

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

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

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

מקרה בוחן: בקשות באזור האישי ללא פעולות ידניות

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

מה נשבר בגישה הראשונה

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

כיצד עשו זאת מחדש ומה השתנה

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

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

במה סוכן AI בדפדפן שונה מ-RPA קלאסי

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

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

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

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

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

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

האם הסוכן יכול לעבוד בלי יציאה החוצה?

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

מה קורה אם שלב בתסריט נפל?

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

מי אחראי לנכונות הפעולות?

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

מה נדרש להתחלה וכיצד אנו מעריכים את היקף העבודה

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

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

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