דלג לתוכן הראשי
מדריכים Computer-Use Agents
מעודכן ליולי 2026 14 דקות קריאה מתקדם

Computer-Use — סוכנים
שמפעילים את המחשב

עד עכשיו סוכני AI השתמשו ב-API. הדור הבא רואה מסך, מזיז עכבר ומקליד — בדיוק כמו אדם. סוכני Computer-Use מפעילים כל תוכנה בממשק הגרפי שלה, גם כזו בלי API. במדריך: איך זה עובד, הכלים (Claude Computer Use, Operator, Mariner), מקרי שימוש, והסיכונים שאסור להתעלם מהם.

Screenshot
רואה מסך
Click
מזיז עכבר
Type
מקליד
Loop
עד להשלמה

מה זה, ולמה זה מרגיש אחרת

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

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

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

ההבדל במשפט

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

אם יש API — השתמשו ב-API

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

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

לכן סדר הבדיקה, לפני שנוגעים בקטגוריה הזו:

  1. יש API רשמי? השתמשו בו. סוף הדיון.
  2. יש ייצוא לקובץ או ייבוא מקובץ? לרוב זה מספיק, וזה יציב לאין שיעור.
  3. יש גישה למסד הנתונים ישירות, בקריאה? לעתים קרובות קיימת ואיש לא חשב עליה.
  4. המערכת נגישה בדפדפן? אז אוטומציית דפדפן שמתבססת על מבנה הדף יציבה יותר מסוכן שמסתכל על פיקסלים.
  5. ורק אם כל אלה נשללו — Computer-Use מוצדק.

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

הלולאה, ומה בה נשבר

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

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

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

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

שבירות היא תכונה, לא באג

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

ארבעה דברים ששוברים זרימה שעבדה אתמול, וכולם מחוץ לשליטתכם:

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

איך זה נראה בקוד

הלולאה עצמה קצרה, וכל מה שהופך אותה לאמינה נמצא סביבה — לא בתוכה:

MAX_STEPS = 25
history = []

for step in range(MAX_STEPS):
    shot = screenshot()

    action = call_model(
        system=RULES,          # כולל: ממשק עברי, RTL
        goal=goal,
        screenshot=shot,
        history=history[-6:],  # לא הכול — רק מה שרלוונטי
    )

    if action.type == "done":
        break
    if action.type in NEEDS_APPROVAL:
        return ask_human(action, shot)    # מציג מה עומד לקרות

    perform(action)
    wait_for(action.expect)     # ממתין לאלמנט, לא לשניות

    # אימות: האם המסך אכן הגיע למצב הצפוי
    if not screen_matches(screenshot(), action.expect):
        return {"ok": False, "step": step,
                "reason": "המסך לא הגיע למצב הצפוי"}

    history.append((action, action.expect))
    save_shot(shot, step)       # לתיעוד, לא לתצוגה

else:
    return {"ok": False, "reason": "הגיע לתקרת הצעדים"}

return verify_at_source(goal)   # לא מול המסך — מול המקור

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

לוודא במקום להניח

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

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

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

הרשאות: מה הסוכן יכול לעשות ברגע שהוא בפנים

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

שלוש הגבלות שאינן המלצות:

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

ממשקים בעברית

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

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

מה לתת למודל חוץ מהתמונה

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

מה שכדאי שיהיה בה:

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

איפה זה כן משתלם

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

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

אוטומציית דפדפן היא לרוב התשובה הנכונה

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

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

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

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

עלות וזמן

שני מספרים שמפתיעים מי שמגיע מאוטומציה רגילה.

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

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

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

מי אחראי כשזה טועה

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

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

איך בודקים דבר כזה

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

מה שכדאי לצפות ממנו, ומה לא

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

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

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

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

מתי לא

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

טעויות שחוזרות