אוטומציית GUI עם סוכן AI על בסיס Computer Use

Computer Use AI: היכן נשברת האוטומציה של הממשק

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

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

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

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

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

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

האפקט מהטמעת הסוכן: מהירות, כיסוי, פחות שגרה

הסוכן מבוסס Computer Use עובד דרך אותו ממשק שבו עובד האדם: רואה את המסך, מזיז את הסמן, ממלא שדות, קורא את תגובת המערכת.

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

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

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

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

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

מצבי הפעולה של הסוכן: דפדפן, שולחן עבודה, היברידי

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

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

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

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

איך אנחנו מטמיעים את הסוכן: מניתוח התהליכים ועד למסירה

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

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

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

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

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

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

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

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

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

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

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

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

מדדים לפני ואחרי הפרויקט:

• שיעור הפניות שטופלו בלי מפעיל — מ-0 ל-82%;
• הזמן מהופעת הפנייה ועד להעברה לטיפול — מ-6 שעות ל-4 דקות;
• שגיאות בהזנת נתונים — מ-4% ל-0.6%;
• פניות ליליות ופניות בסופי שבוע הפסיקו לחכות לתחילת המשמרת;
• התפוקה בשעות השיא עלתה בערך פי שלושה בלי להרחיב את המצבת.

מה זה אומר למשימות דומות

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

במה Computer Use שונה מתרחישים קלאסיים?

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

Computer Use כגישה באוטומציית AI יוצאת מהיעד: הסוכן רואה את המסך ומחליט בעצמו היכן ללחוץ ומה להזין, ומוודא את התוצאה מול המשימה.

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

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

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

ספקות טכניים לפני ההתחלה: מפרקים סעיף-סעיף

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

לאן מגיעים פרטי הגישה ואילו הרשאות מקבל הסוכן?

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

מה קורה כשיש שגיאה באמצע התהליך?

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

אפשר לפרוס את זה בקונטור סגור?

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

נדבר על המשימה: מה לשלוח ואיך אנחנו מגיבים

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

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

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