Anthropic Computer Use: היכן נשברת האוטומציה של ממשקים
תרחיש על בסיס Anthropic Computer Use נראה אמין כל עוד הוא רץ באותו סטנד שבו נבנה. הכלי מקבל צילום מסך, מזהה אלמנטים ולוחץ עליהם — ולכן אוטומציה של ממשקים עובדת במקומות שבהם למערכת אין ממשק תוכנה פנימי. הבעיות מתחילות בתפעול אמיתי, שבו הפריסה מתעדכנת מדי שבוע והנתונים מגיעים בצורה חלקית.
שני סוגי תרחישים נשברים. הראשון כבול לקואורדינטות: לחיצה על מיקום מחושב מחמיצה כשמשתנים רזולוציה, קנה מידה או גופן. השני נשען על אלמנט שנמצא — עדכון בפריסה משנה את המבנה, והמודל לוחץ בביטחון על הבלוק הסמוך, והשגיאה צפה רק אחרי כמה צעדים. בנפרד — תרחישים שבירים עם מעברים מודאליים והשהיות קשיחות במקום בדיקת מצב המסך.
יקר הוא לא הכשל עצמו, אלא האופן שבו מגלים אותו. פעולות ידניות לא נעלמות לשום מקום: העובד משלים חריגים, מצליב תוצאות, מפרק הרצות שנתקעו. שיעור הריצות המוצלחות יורד בשקט, בלי שגיאה מפורשת — עד שמתברר שחלק מהנתונים נרשמו בשדה הלא נכון. כל עדכון פריסה הופך לדיבוג מחדש של כל השרשרת.
מפרקים איך סוגרים את זה: בדיקות מצב מסך במקום קואורדינטות והשהיות, בידוד נקודת הכשל, נראות של כל צעד.
מה משתנה אחרי ההטמעה: אפקטים מדידים
שיעור הפעולות הידניות שנגרעו מהעובדים
סוכן מבוסס Anthropic Computer Use עובד באותו ממשק שבו עובד האדם: מזהה את המסך, מוביל סמן, מקליד טקסט, בודק את התוצאה. בסט של פעולות טיפוסיות — הפקת דוח, הצלבת שתי מערכות, מילוי כרטיס — 70–80% מהצעדים יורדים מהאנשים. האדם נשאר לאישורים ולמקרים שנויים במחלוקת, שבהם צריך החלטה ולא חזרה על אותה פעולה שוב ושוב.
זמן מעבר התרחיש ושיעור הריצות המוצלחות
את המדד מחשבים על סט קבוע של תרחישים, אחרת ההשוואה אינה הוגנת: זמן מההתחלה ועד למסך האחרון שנבדק, ושיעור הריצות בלי התערבות של מפעיל. תרחיש שאדם עבר ב-12–15 דקות, אחרי כיוונון ציפיות וניסיונות חוזרים נסגר ב-2–3 דקות, ושיעור הריצות המוצלחות מגיע ל-9 מתוך 10. השאר — לא כשלים, אלא עצירות תקינות עם העברה לאדם.
מחלקות הכשל שהוסרו ועומס הצוות
המקור העיקרי לאובדן הוא שגיאה שקטה: הממשק השתנה, הצעד פורמלית עבד, הנתונים הלכו למקום הלא נכון. הסוכן מצליב את מצב המסך עם המצופה אחרי כל פעולה: במקרה של אי-התאמה הוא עוצר ושומר תיעוד של הצעדים.
מחלקת "שגיאה בלי אות" נעלמת, ועומס השיא של העובדים מוחלק — הזמן הולך לניתוח חריגים ולא לשגרה.
Anthropic Computer Use וחלופות: איזה מצב לבחור
בחירת המצב נקבעת לא כל כך ביכולות המודל, אלא ביציבות הממשק ובזמינות של גישה תוכנית. Anthropic Computer Use עובד במחזור צילום מסך: המודל רואה את המסך, מוצא אלמנטים ולוחץ לפי קואורדינטות. זה מסיר את התלות ב-API, אבל מוסיף השהיה בכל צעד ורגישות לרזולוציה, לערכת עיצוב ולחלונות קופצים.
גישה תוכנית דרך API נותנת תוצאה דטרמיניסטית: הקריאה מחזירה מבנה ולא פיקסלים, וחוזרת על עצמה בלי סטיות. המגבלה — כיסוי: לחלק מהמערכות אין ממשק ציבורי, ובלי שכבה חזותית אי אפשר לסגור את המשימה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| שליטה חזותית (Computer Use) | יש ממשק, אין גישה תוכנית: מערכות מיושנות, עמדות עם ממשק גרפי | השהיה בכל צעד, רגישות לפריסה ולרזולוציה, נדרש ניהול סשנים |
| גישה תוכנית (API, פרוטוקולים) | למערכת יש ממשק מתועד וחוזה יציב | לא מכסה מערכות סגורות, דורשת תחזוקה של גרסאות החוזה |
| קונקטורים מוכנים | מערכת טיפוסית עם תמיכה מהקופסה | מסגרת נוקשה של תרחישים, התאמה אישית מוגבלת |
| היברידי: מסלול תוכני ורזרבה חזותית | פעולות קריטיות עוברות דרך API, נדירות — דרך הממשק | נדרשת שכבה אחודה של לוגים וחזרה לאחור |
את המצב בוחרים לפי שני קריטריונים — יציבות הממשק ומחיר הטעות. במקום שבו כשל בפעולה יקר, הולכים במסלול תוכני, ואת השליטה החזותית משאירים כרזרבה למקרי חריגה.
איך אנחנו מטמיעים: שלבי העבודה ההנדסית
לפני שמוסרים לסוכן פעולות חיות, אנחנו מפרקים מה בדיוק הוא עושה במקום האדם ואיפה מחיר הטעות גבוה מהתועלת. העבודה מתנהלת באיטרציות: אבחון תהליכים, פיילוט על העתק של המערכת, ורק אחר כך הוצאה לקו העבודה. להלן המסלול שכל הטמעה של Anthropic Computer Use עוברת.
- אבחון תרחישים. עוברים על המשימות יחד עם המבצעים שלהן, בוחרים פעולות חוזרות עם צעדים שניתן לפרמל, ופוסלים את אלה שכמעט כל מקרה בהן אינו שגרתי.
- סכימת האינטראקציה. מקבעים את המסכים, הטפסים והמעברים שהסוכן רואה, מקורות הנתונים וההתנהגות בסטייה מהמצופה. מסמנים בנפרד נקודות שבהן האדם חייב לקבל את ההחלטה.
- הגדרת הסביבה. מרכיבים סטנד מופרד עם העתקה של הממשקים ואותן הרשאות גישה. הסוכן עובד בפרופיל נפרד, כל צעד נרשם ביומן עם צילום מסך.
- בדיקה על העתק המערכת. מריצים תרחישים בסדרות, כולל מקרי קצה: טעינה איטית, חלונות קופצים, שינויי פריסה. מסתכלים על שיעור יציב של ריצות מוצלחות, ולא על הרצה מוצלחת אחת.
- פיילוט על קו צר. מפעילים את הסוכן על חלק מהפעולות לצד מפעיל. מצליבים את התוצאה עם העבודה הידנית, מפרקים אי-התאמות ומתקנים את הלוגיקה עד שהן נעלמות.
- העברה לתחזוקה. מוסרים נהלים: איך קוראים יומנים, מה עושים במקרה של כשל, איך מעדכנים תרחישים אחרי שינויי ממשק. מגדירים התראות וסף שממנו הסוכן עוצר בעצמו.
מה נשאר אצלכם: ערכת תיעוד ותצורות
מעבירים את ההטמעה כך שהיא תמשיך לחיות בלעדינו: הצוות שלכם מקבל את אותה ערכה של תצורות, מדיניות ויומנים שלפיהם התרחישים עובדים אצלנו. בנפרד מקבעים מה הסוכן Anthropic Computer Use מבצע בעצמו, ומה דורש אישור של אדם.
- תצורות תרחישים — תיאורים צעד-אחר-צעד של המשימות: נקודות המתנה לממשק, תנאי מעבר, טיפול בחלונות קופצים ובפריסה שהשתנתה.
- מדיניות גישה — באילו חשבונות עובד הסוכן, אילו אזורים חסומים לו, ואיפה חובה בדיקה ידנית לפני שליחה.
- יומני ריצות — לכל הרצה: משך הצעדים, נקודת העצירה והסיבה לה, צילום מצב ברגע הכשל.
- מפת כשלים — מצבים טיפוסיים: הממשק השתנה, האלמנט לא נמצא, הסשן נפסק — ומה עושים בכל אחד מהם.
- נהלי תחזוקה — מי ואיך מעדכנים צעדים, איך עוברת קבלת תיקונים, באיזו תדירות נבחנת מחדש המדיניות.
- סט בדיקות — תרחישי בדיקה לאחר תיקון ממשק או עדכון מודל, כדי שהקבלה תתבצע בלי התמיכה שלנו.
ההעברה מתבצעת עם הסבר: עוברים על התצורות יחד עם המהנדסים שלכם ומריצים את התרחישים כבר בסביבה שלכם. הערכה עצמאית — תחזוקה בהמשך אפשרית, אך אינה הכרחית.
מקרה בוחן: איך צומצמו פעולות ידניות במערכת הנהלת חשבונות
מחלקת טיפול בפניות עבדה במערכת הנהלת חשבונות בלי ממשק תוכנה חיצוני: מיילים, טפסים מהאתר וסריקות חוזים הועברו על ידי המפעילים ידנית לכרטיסים. במשמרת היו כ-1 200 פעולות באורך 6–8 דקות כל אחת — למצוא את הצד שכנגד במרשם, להצליב פרטים, למלא כחמישה עשר שדות, לצרף קובץ.
מה היה לפני ההטמעה
מחיר ההקלדה הידנית אינו הזמן, אלא מחלקת שגיאות שאי אפשר לתפוס בכניסה. כ-4% מהכרטיסים יצאו לעבודה עם שגיאת הקלדה בפרטים או בסכום, וכל אחד מהם חזר לתיקון כבר אחרי האישור.
מקור כשלים נפרד — כפילויות: פנייה מהאתר ומייל של אותו לקוח נרשמו כשתי רשומות, כי המפעיל לא הספיק לבדוק היסטוריה.
מה שינו
סוכן מבוסס Anthropic Computer Use עובד באותו חלון של מערכת הנהלת החשבונות שבו עובד האדם: רואה את המסך, מזיז את הסמן, ממלא שדות, מצרף קבצים — לא היה צורך לכתוב מחדש את המערכת ולפתוח בה גישה תוכנית.
לפני שמירת הכרטיס עוברות הפעולות הצלבה עם מרשם הצדדים שכנגד, בדיקת שדות חובה וחיפוש כפילויות לפי סכום ותאריך. אם חסרים נתונים או שהערכים מתנגשים, הפנייה עוברת למפעיל עם תיאור אי-ההתאמה.
מה נהיה אחרי
| מדד | לפני | אחרי |
|---|---|---|
| פעולות ידניות במשמרת | ~1 200 | ~180 |
| שיעור שגיאות הקלדה | ~4% | 0.4% |
| זמן טיפול בפנייה | 6–8 דק' | 40–50 שנ' |
| פניות בלי מעורבות אדם | 0% | 78% |
המפעילים עברו לניתוח חריגים ולהצלבת כרטיסים שנויים במחלוקת — שיעור העברת הנתונים השגרתית במשמרת ירד בערך פי שישה. מהכשלים החוזרים נעלמו אי-התאמות המרשמים, כפילויות פניות ושדות חובה שהוחמצו: הבדיקות מתבצעות לפני הרישום, ולא אחריו.
מה ההבדל בין שליטה בדפדפן לשליטה בשולחן העבודה?
שליטה בדפדפן עובדת עם תוכן העמוד: הסוכן מוצא שדות, כפתורים וקישורים לפי התפקיד והתווית שלהם, ולא לפי קואורדינטות על המסך. התרחיש לא נשבר כשמשתנים רזולוציה וקנה מידה, וההרצה עולה פחות — אין צורך להעלות מעטפת גרפית, וכמה סשנים מתקיימים באותו מחשב. המגבלה אחת: הסוכן רואה בדיוק את מה שהעמוד מסר לתוך המבנה.
שולחן העבודה של האפליקציות — רמה אחרת. הסוכן מקבל תמונה של המסך ומפעיל סמן ומקלדת, ולכן זמינים לו חלונות ודיאלוגים שאין בדפדפן: בחירת קובץ מערכתית, אזהרות אבטחה, לקוחות נייטיביים של מערכות הנהלת חשבונות.
כך בנויה הגישה של Anthropic Computer Use — המודל מוביל את הסוכן לפי המסך, ולא לפי הממשקים הפנימיים של התוכנות. המחיר — רגישות למיקום האלמנטים: הזיזו פאנל או החליפו ערכת נושא, והקואורדינטות צריכות להיחשב מחדש.
בחירת תחום היישום מצטמצמת לשאלה אחת: האם המסלול נתקע בגבול העמוד. כל עוד כל המסלול נכנס בממשק הווב, שליטה בדפדפן זולה ואמינה יותר — ממנה מתחילים. ברגע שמופיעות פעולות קבצים עם תיקיות מקומיות, עבודה בלקוח נייטיבי או אישור בחלון מערכתי, בלי שולחן עבודה אי אפשר לסגור את התרחיש.
בפועל, לרוב נדרש היבריד: חלק מהצעדים עובר דרך העמוד, חלק דרך חלונות ודיאלוגים של המערכת. אנחנו מסמנים את המסלול, משאירים צעדי דפדפן לדפדפן, ופונים לשולחן העבודה רק במקום שאין בו ממשק ווב פיזית.
ספקות של מהנדס: התנגדויות נפוצות ותשובות
הספקות של מהנדסים בשלב ההערכה הם אותם ספקות: מה יקרה כשהממשק ישתנה, האם מותר להריץ בסביבה סגורה, מי ואיך מגביל את הגישה של הסוכן, ובמה מאשרים את התוצאה. להלן תשובות לגופן, בלי הבטחות שיווקיות.
הטמעת Anthropic Computer Use בנויה כך שהכשל ייראה לפני הפרודקשן, ולא אחריו. להלן ארבע שאלות טכניות שנשאלות לרוב בדיון על הארכיטקטורה.
מה יקרה כשהממשק ישתנה?
התרחיש נשען על עוגנים סמנטיים — תוויות, כותרות, מבנה הטופס, ולא על קואורדינטות וסדר האלמנטים. כפתור שעבר מקום או אזור ששינה שם שוברים את הריצה בבדיקה, ולא בתור העבודה.
צעדים קריטיים מוצלבים בנוסף עם מצב המערכת, ולכן השינוי נתפס בשלב הבדיקה, ושיעור התרחישים שמאותתים בעצמם על אי-התאמה עולה עם כל גרסה.
אפשר לפרוס בסביבה סגורה?
כן. הסביבה נבנית בתוך ההיקף של הלקוח: הסוכן עובד עם אותו מקטע רשת שמותר לו לשהות בו, והחוצה לא יוצא דבר מעבר למדיניות המוסכמת. בדרך כלל אין צורך בחליפין חיצוני כלל — יומן הריצות והצבת המשימות נשארים אצלכם.
איך מוגבלת הגישה של הסוכן?
הסוכן עובד בחשבון נפרד עם הרשאות מינימליות מספיקות: רק האזורים הנדרשים, רק הפעולות שהתרחיש מגדיר, וזמן חיים קצר לסשן. פעולות הרסניות מתבצעות באישור מפורש, וכל פנייה נרשמת ביומן עם שיוך לתרחיש ולאדם שהפעיל אותו.
במה מאשרים את התוצאה ומה קורה אחרי ההרצה?
ההצלחה נרשמת לא לפי עצם הלחיצה, אלא לפי המצב הסופי: הרשומה נוצרה, הסטטוס השתנה, המסמך תאם את המצופה. אי-התאמות עוברות לתור ניתוח ולא הולכות לאיבוד. אחרי העלייה לעבודה אנחנו מלווים את הסביבה: מפרקים כשלים, מעדכנים תרחישים לפי גרסאות הממשק ושומרים על כיסוי של המסלולים הקריטיים.
נדון במשימה: נחזור עם הערכה ותוכנית הטמעה
כדי לחזור עם הערכה ולא עם ניסוחים כלליים, אנחנו צריכים מכם מעט: תיאור התהליך שאתם רוצים לסגור באוטומציה, גישה לסביבת בדיקה ורשימת מגבלות — מה אסור לסוכן לעשות בממשק חי בשום תנאי.
זה מספיק כדי לפרק את הגדרת המשימה, להבין איפה Anthropic Computer Use באמת נותן יתרון ואיפה עדיף חילוף נתונים רגיל בין מערכות.
אחרי ניתוח המשימה נחזור עם ערכה קונקרטית של מסמכים:
- הערכת היקף העבודה: אילו תרחישים סוגרים בתור הראשון ובאיזה סדר, ומה מוציאים במודע מחוצה לו;
- תוכנית הטמעה עם שלבים, תפקידים, נקודות בקרה ותרחיש פיילוט על תהליך אחד;
- סכימת האינטראקציה של הסוכן עם הממשקים, כולל התנהגות במצבים לא שגרתיים וכללי חזרה לאחור;
- רשימת סיכונים: איפה הפריסה או הלוגיקה של המסך משתנה ושוברת את התרחיש, ואיך אנחנו עוקבים אחר זה;
- קריטריוני קבלה — לפי אילו מדדים רואים שהאוטומציה עובדת ולא מחקה עבודה;
- דרישות לגישות, לסטנדים ולנתונים שיש להכין מצדכם לקראת תחילת הפרויקט.
תארו את המשימה בצורה חופשית — נחזור עם הערכה ותוכנית. אם כבר יש סביבת בדיקה או עבודה קודמת, ננתח אותה ולא נמציא מחדש.







