מה זה בעצם 'סוכן שמפעיל את המחשב' (ומה זה לא)

סוכן שעונה מול סוכן שעושה — ההבדל שמשנה הכל

הצעד הראשון, לפני כל שם מוצר, הוא לעצור ולהבין שמה שאנחנו מדברים עליו בקורס הזה לא דומה למה שרובכם מכירים מצ'אטים של AI. הבלבול הזה הוא השורש של רוב הבעיות שאנשים נתקלים בהן — הם ניגשים לסוכן שמפעיל דפדפן עם אותה ציפייה שיש להם מ-Claude.ai או ChatGPT, ואז מתפלאים שהם שולחים הודעה ללקוח במקום אחד, או מוחקים רשומה במקום אחר. זה לא "AI חכם יותר". זה סוג אחר לגמרי של תוכנה.

מה זה chatbot (סוכן שעונה)

כשאתם פותחים ChatGPT או Claude.ai ושואלים "מה ההבדל בין תאגיד לעוסק מורשה", אתם מקבלים תשובה מילולית. המודל רואה prompt, מייצר טקסט, וזהו. הוא לא פתח שום חלון, לחץ על שום כפתור, מילא שום טופס. גם אם הוא מייצר קוד — הוא מייצר טקסט של קוד, לא קוד שרץ. זה העולם שרוב המשתמשים חיים בו, וזה העולם שבו הסיכון הוא מידע שגוי — לא פעולה שגויה.

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

מה זה acting agent (סוכן שעושה)

כשאתם נותנים לסוכן משימה כמו "תוריד את שלוש החשבוניות מ-portal הספק ותשמור אותן בתיקייה 'חשבוניות-יוני' ב-Google Drive שלי", הוא פותח את הדפדפן, מקליד את ה-credentials שלכם (לא — הוא פועל בתוך ה-session המחובר שלכם, נגיע לזה בסעיף 4), נכנס ל-portal, לוחץ על "הורדה", בוחר קובץ, עובר ל-Drive, יוצר תיקייה, מעלה. זו פעולה פיזית בתוך תוכנה אמיתית. הוא לא סיפר לכם איך עושים את זה — הוא עשה את זה.

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

למה ההבדל הזה קריטי לכם

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

בפרק 6 נעמיד במסגרת מסודרת איך מגינים על עצמכם (human-in-the-loop gates, audit log, allowlist, פרופיל סוכן ייעודי). בפרק 7 נבנה את ה-pipeline האמיתי. אבל בלי שתבינו את ההבחנה הזו עכשיו, שום פרק בהמשך לא יעבוד. זה ההבדל בין "להשתמש במכונית" לבין "להבין שמכונית יכולה לדרוס".

שלוש דרכים שבהן סוכן יכול לעבוד: computer-use, browser-use, API-first

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

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

1. computer-use — "הסוכן רואה את כל המסך"

computer-use agent הוא סוכן שמקבל צילום-מסך של כל שולחן העבודה (או חלון ספציפי), מחליט פעולה — קליק, הקלדה, גלילה, משיכה — ומבצע אותה דרך העכבר והמקלדת. הוא לא יודע מה זה Salesforce או Slack; הוא רק רואה פיקסלים, מזהה כפתור, לוחץ עליו. הדוגמה הקלאסית היא Operator של OpenAI (שגם קיבל את השם הטכני CUA — Computer-Using Agent) — הוא מקבל גישה למחשב וירטואלי, רואה אותו, מבצע בו פעולות. אותו מנגנון משמש גם את Antigravity 2.0 של גוגל במצב desktop.

היתרון: הסוכן יכול לעבוד עם כל תוכנה, כולל תוכנות שאין להן API, כולל תוכנות legacy (ישנות) שאיש לא טרח לבנות להן אינטגרציה. CRM פנימי בדפדפן IE? Photoshop? תוכנת הנהלת חשבונות ישראלית ישנה? אם זה רץ על מסך — computer-use יכול להפעיל אותו.

החיסרון: הסוכן "רואה" רק מה שיש על המסך. הוא לא יכול לקרוא את ה-DOM (Document Object Model — המבנה הפנימי של הדף), לא יכול לראות תוכן שמוסתר מאחורי modal (חלון קופץ), לא יכול לגשת ל-API ישירות. זה גם הסיכון הגדול ביותר — הוא רואה הכל על המסך, כולל מידע רגיש שאולי לא רציתם שייחשף למודל.

2. browser-use — "רק בתוך הדפדפן, אבל יותר חכם"

browser-use agent הוא תת-קבוצה של computer-use, אבל עם שני הבדלים מעשיים ענק: (א) הוא פועל רק בתוך חלון הדפדפן, (ב) הוא רואה גם את מבנה הדף (DOM) ולא רק פיקסלים, מה שנותן לו יתרון בקריאת טבלאות מורכבות, טפסים עם הרבה שדות, וכו'. הדוגמאות המרכזיות: Codex for Chrome, Claude in Chrome, Atlas (כשהוא במצב agent), ו-Browser Use ה-OSS (קוד-פתוח) שרץ על המחשב שלכם.

היתרון: רוב עבודת-הידע החוזרת ב-2026 קורית בדפדפן — Salesforce, Gmail, LinkedIn, Notion, Airtable, כלי ניהול פרויקטים, רוב ה-CRMs. browser-use מספיק ב-90% מהמקרים, והוא זול יותר (פחות tokens על צילומי מסך מיותרים), מהיר יותר (ה-DOM מכוונן אותו), ובטוח יותר (פחות סיכון לפעולה שלא בדפדפן).

החיסרון: לא יכול לגעת באפליקציות native (מותקנות), לא יכול לפתוח קבצים ב-Excel, לא יכול להפעיל תוכנה ישנה. חייב שהמשימה תהיה נגישה דרך Chrome (או דפדפן תואם).

3. API-first — "בלי מסך, יש רק קריאות"

API-first agent לא רואה שום מסך. הוא מקבל רשימה של כלים (tools) — לדוגמה: search_customer(name), update_record(id, fields), send_email(to, subject, body) — והוא מחליט איזה כלי לקרוא ובאיזה סדר. הוא לא לוחץ על כפתורים; הוא קורא לפונקציות. הדוגמאות: Claude Code כשהוא עובד דרך SDK, רוב ה-agents המובנים ב-Copilot Studio, ו-agents של LangChain או Lindy שמחוברים ל-API ספציפי.

היתרון: מהיר, זול, מדויק. אין צילומי מסך, אין OCR (זיהוי תווים אופטי), אין ניווט בממשק. הסוכן מדבר ישירות למערכת דרך ה-API. ה-SDK מחזיר JSON מובנה, הסוכן מקבל החלטה, קורא לפונקציה הבאה. זה המצב היעיל ביותר — וגם הזול ביותר לרוץ ב-volume (נפח משימות גבוה).

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

איזה מהשלושה מתאים למשימה שלכם?

השאלה הראשונה שאתם צריכים לשאול היא לא "איזה מוצר הכי חדש" — אלא "איפה המשימה שלי גרה".

• המשימה בדפדפן ולמערכת יש API? → API-first. הכי זול, הכי מהיר, הכי אמין.
• המשימה בדפדפן אבל אין API (או שהוא חסום/לא-מתועד)? → browser-use. זה המקרה הנפוץ ביותר.
• המשימה באפליקציה native, קובץ מקומי, או תוכנה legacy? → computer-use. המקרה היקר והאיטי ביותר, אבל היחיד שעובד.

ברוב המקרים המעשיים, browser-use הוא התשובה. לכן רוב הקורס הזה מתמקד בו. אבל ההבחנה המלאה תעזור לכם לבחור נכון בפרק 4 (Picking the right tool), ולהבין למה לפעמים ה-API-first הוא הבחירה הנכונה גם כשהוא דורש הגדרה.

הלולאה שמחזיקה את כל הקסם: screenshot → reason → act

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

האנימציה הבאה ממחישה את הלולאה. הסוכן לא "מתכנן הכל מראש" — הוא רואה, מגיב, רואה שוב.

שלב 1 — Screenshot (צילום-מסך)

הסוכן מקבל תמונה של מה שיש עכשיו על המסך. לא קוד HTML, לא רשימת אלמנטים — תמונה, בדיוק כמו שאתם רואים. זה הקלט העיקרי שלו. בכל מוצר הצילום נראה קצת אחרת: ב-Operator הוא צילום של מחשב וירטואלי שלם, ב-Claude in Chrome זה צילום של ה-tab הפעיל, ב-Atlas זה צילום של הדף הנוכחי. אבל הרעיון זהה — תמונה היא הקלט.

למה זה חשוב לכם? כי זה אומר שהסוכן "רואה" בדיוק מה שאתם רואים. אם יש modal חסום, הוא לא יודע מה מאחוריו. אם יש טקסט קטן במיוחד, הוא עלול לפספס. אם צבעים מסוימים משמעותיים למשתמש אנושי (אדום = שגיאה), הוא לא תמיד יודע. זה ה-baseline של הביצועים שלו.

שלב 2 — Reason (חשיבה / החלטה)

המודל מקבל את הצילום יחד עם: (א) המשימה המקורית ("תוריד את החשבונית"), (ב) היסטוריית הפעולות שכבר ביצע, (ג) במקרים מסוימים גם ה-DOM של הדף (ב-browser-use agents). הוא מייצר פעולה — לרוב בפורמט מובנה כמו JSON: {"action": "click", "target": "כפתור 'הורד'", "coordinates": [450, 320]} או {"action": "type", "text": "חשבוניות-יוני"}.

זה המקום שבו המודל "מחליט" — וזה גם המקום שבו הוא יכול לטעות. הוא לא תמיד מזהה נכון את הכפתור הנכון, לא תמיד מבין שה-dropdown שנפתח דורש בחירה לפני שהוא ממשיך, לא תמיד מבחין בין "כפתור 'שמור'" ל"כפתור 'שמור כטיוטה'". זה ה-skill של המודל — וזו הסיבה שמודלים שונים (Claude Opus 4.8, GPT-5.4, Gemini 2.5) נותנים תוצאות שונות.

שלב 3 — Act (פעולה)

הפעולה מבוצעת פיזית בממשק. ב-Chrome extension זה קליק של ממש, ב-Operator זה פעולה ב-VM (מכונה וירטואלית), ב-API-first זה קריאה לפונקציה. הסוכן לא יודע אם הפעולה הצליחה עד שהוא רואה צילום-מסך חדש. הוא פועל "בעיוורון" עד הצילום הבא.

הנקודה הזו קריטית: הסוכן לא "מתכנן הכל" ואז פועל. הוא רואה → פועל → רואה תוצאה → מתאים. זה הופך אותו לאיטי (כל פעולה דורשת round trip עם המודל), ליקר (כל צילום = אלפי tokens של vision input), וגם לפגיע לשינויים לא-צפויים — הוא לא יכול להגיב למה שהוא לא רואה.

חזרה — וזה ה-loop

אחרי הפעולה, צילום-מסך חדש נשלח למודל, הוא רואה את המצב החדש, מחליט פעולה הבאה, מבצע. במשימה ממוצעת של "הורד חשבונית" יש 8-15 סיבובים כאלה. במשימה מורכבת של "בדוק 50 רשומות ב-CRM ועדכן סטטוס" יש 100-300 סיבובים. כל סיבוב = צילום + reasoning + פעולה. זה המקום שבו מתמטיקת העלות והאמינות מתחילה להיות מהותית (פרק 5), והמקום שבו כל vendor שונה — חלק יעילים יותר, חלק זולים יותר, חלק נשברים בצילומים עמומים.

דוגמה קונקרטית: הלולאה במשימה אמיתית — "הורד את חשבונית יוני"

במקום הפשטה, בואו נראה את הלולאה רצה באמת על משימה שכל בעל-עסק מכיר: הורדת החשבונית של חודש יוני מ-dashboard של ספק SaaS (נניח, Vercel). שימו לב איך כל סיבוב הוא screenshot → reason → act, ואיך הסוכן "מגלה" את הדרך תוך כדי תנועה:

שימו לב לשלושה דברים: (1) הסוכן לא ידע מראש ש-Billing נמצא ב-Settings — הוא גילה את זה בסיבוב 1 מהצילום. (2) אם בסיבוב 2 ה-sidebar היה נראה אחרת (Vercel שינו UI), הוא היה צריך להתאים — זו השבירות שנדבר עליה בפרק 5. (3) ארבעה סיבובים פשוטים = ~4 צילומים = אלפי tokens. תכפילו ב-50 חשבוניות וקיבלתם את מתמטיקת העלות של פרק 5.

למה ה-loop הזה הוא ה-frame הנכון

יש עשרות רעיונות מבלבלים בשוק — "ReAct loop", "chain-of-thought", "function calling", "tool use". רובם רק ניסוחים שונים לאותו רעיון: רואים, חושבים, פועלים. אם תזכרו רק את הלולאה הזו, תוכלו להבין כל מוצר חדש תוך 10 דקות — פשוט תשאלו: "איזה צילום הוא רואה, איזה פעולות הוא יכול לבצע, ואיך הוא מקבל feedback?". שלוש שאלות, ואתם בפנים.

ה-shift של 2026: signed-in session access

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

מה זה signed-in session access

בעבר, אם רצית לתת לסוכן גישה ל-Salesforce, היו לך שתי אפשרויות: (א) לתת לו את הסיסמה שלך (מסוכן, וגם Salesforce חוסם את זה), (ב) לבנות אינטגרציה דרך API (יקר, דורש פיתוח, ולפעמים בלתי-אפשרי כי אין API). ב-2026 יש אפשרות שלישית: הסוכן פשוט משתמש בדפדפן שבו אתם כבר מחוברים. הוא לא צריך סיסמה, הוא לא צריך API — הוא פשוט "יושב" ב-Chrome שלכם, רואה את ה-cookies (קבצי זיהוי שמאשרים שאתם מחוברים), ופועל כאילו אתם.

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

למה זה כוח-על

תחשבו על זה: יש המון מערכות שאין להן API ציבורי. פורטל הבנק, פורטל הביטוח הלאומי, ה-CRM הפנימי של החברה שמבוסס על template של 2014, כלי ניהול של ספק ספציפי, מערכות legacy שאף אחד לא מתחזק. לכל המערכות האלה, הדרך היחידה לגעת בהן אוטומטית היא דרך ה-UI. והדרך היחידה לגעת ב-UI של מערכת מאומתת — היא session access.

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

למה אותו דבר מסוכן

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

והסיכון הזה אינו תיאורטי. באוגוסט 2025 פרסמה Anthropic ממצאי בטיחות על Claude in Chrome: גם אחרי שהוסיפו את כל ההגנות (אישור per-site, חסימת פעולות רגישות, וכו'), שיעור הצלחת התקיפות של prompt injection (הזרקת פקודות זדוניות) במצב אוטונומי עמד על 11.2%. כלומר, אחת מתוך תשע הרצות במצב אוטונומי הסתיימה בכך שהסוכן ביצע פעולה שתוקף ביקש ממנו לבצע, ולא מה שהמשתמש ביקש. וזה אחרי mitigations. בלי mitigations, המספר היה 23.6%.

זה לא אומר "אל תשתמשו". זה אומר: אל תשתמשו בלי פיקוח. בלי allowlist (רשימת אתרים מאושרים). בלי human-in-the-loop gates (אישור אנושי לפני כל פעולה רגישה). בלי audit log. בלי פרופיל סוכן ייעודי. ואת כל המנגנונים האלה נבנה יחד בפרקים 6 ו-7. בלעדיהם, signed-in session access הוא לא כלי עבודה — זה רובה טעון שמכוון לראש שלכם.

כוח-על וסיכון באותו מוצר — ה-blast radius

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

ההגדרה הפשוטה

ה-blast radius של סוכן הוא כמות הנזק המקסימלית שהסוכן יכול לעשות אם הוא נשבר או מותקף. זה תלוי בשני משתנים בלבד:

• אילו מערכות הסוכן נוגע בהן? סוכן שרץ רק על אתר חדשות ציבורי = blast radius קטן. סוכן שרץ ב-Gmail + Salesforce + הבנק = blast radius עצום.
• אילו הרשאות יש לו באותן מערכות? סוכן עם גישת read-only (קריאה בלבד) = blast radius קטן. סוכן עם גישת admin = blast radius עצום.

הנוסחה הפשוטה: blast radius = systems × permissions. זה לא מדע מדויק, אבל זה מספיק טוב כדי לדרג סיכונים בלי להיכנס לתיאוריה.

איך זה נראה בעולם האמיתי

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

• קריאת סיכום של דף אינטרנט ציבורי. מערכת אחת, גישת read-only. Blast radius = אפס. גם אם הסוכן נשבר, הוא לא יכול לעשות שום נזק אמיתי.
• מילוי טופס ליד ב-CRM. מערכת אחת, גישת write (כתיבה). אם הסוכן נשבר, הוא יכול ליצור לידים מזויפים או לדרוס לידים קיימים. Blast radius = בינוני.
• שליחת מיילים בשמכם. מערכת אחת (Gmail), גישת send. אם הסוכן נשבר, הוא יכול לשלוח מיילים בשמכם לכל כתובת. Blast radius = גבוה מאוד (פוטנציאל לפגיעה במוניטין, דליפת מידע, אפילו הונאה).
• העברת כספים דרך portal בנקאי. מערכת אחת, גישת transaction. אם הסוכן נשבר, הוא יכול להעביר כסף. Blast radius = קריטי. אל תעשו את זה.

למה המושג הזה משנה את כל החלטה

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

ולכן השאלה הראשונה שאתם צריכים לשאול לפני כל הרצה של סוכן היא לא "מה הוא יכול לעשות?" אלא "מה הוא יכול לעשות אם משהו ישתבש?". אם התשובה היא "הרבה" — אתם צריכים פיקוח רציני לפני שאתם לוחצים Run. אם התשובה היא "כלום" — אתם יכולים להריץ במצב אוטונומי בלי לחשוש.

agentic browser מול דפדפן רגיל + chatbot — מה ההבדל המעשי

הרבה אנשים שואלים "אם יש לי ChatGPT ב-tab צדדי, למה אני צריך agentic browser?". התשובה טמונה בההבדל בין סוכן שעונה לסוכן שעושה שדיברנו עליו קודם. אבל יש הבדל מעשי נוסף, וכדאי להבין אותו לפני שאתם בוחרים מוצר.

דפדפן רגיל + chatbot בtab צדדי

המודל הזה עובד ככה: אתם גולשים ב-Chrome כרגיל, פותחים chat.openai.com או claude.ai בטאב נפרד, מדביקים תוכן מדף אחר, שואלים שאלה, מקבלים תשובה. אתם מעתיקים טקסט, אתם לוחצים "העתק תשובה", אתם מדביקים ב-form. הצ'אטבוט לא נוגע ב-Chrome, לא רואה את ה-DOM, לא לוחץ על כלום. זה כלי שיחה שעובד עם תוכן שאתם מספקים לו.

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

agentic browser — הסוכן גר בתוך הדפדפן

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

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

מה זה "agent mode" בתוך מוצר

הרבה מוצרים מציגים היום שני מצבים באותו UI: "chat" ו"agent". ב-ChatGPT Atlas למשל, ברירת המחדל היא chat — אתם מדברים, הוא עונה. אם תפעילו "agent mode", הוא עובר למצב פעולה. אל תתבלבלו בין השניים. גם אם המוצר זהה, גם אם הממשק דומה, ההתנהגות והסיכון שונים לחלוטין.

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

זה לא סוכן-קוד — ההבחנה מ-Claude Code ו-Cursor

עוד בלבול נפוץ: אנשים שמכירים Claude Code, Cursor, או GitHub Copilot (ה-coding agent) רואים את המוצרים החדשים וחושבים שמדובר באותו דבר. זה לא נכון. ההבחנה היא מהותית, ואם לא תבינו אותה, אתם תצפו מהמוצר הלא נכון.

מה זה סוכן-קוד

Claude Code, Cursor, GitHub Copilot Coding Agent, ו-Codex (המוצר המקורי של OpenAI) הם כלי שעוזרים לכם לכתוב קוד. אתם מתארים מה אתם רוצים, הם מייצרים קוד, מציעים patches, מריצים בדיקות, פותרים bugs. הפלט שלהם הוא קוד שאתם תשלבו ב-repo שלכם, תריצו, תבדקו, תשחררו. הם עוזרי-פיתוח שמבינים TypeScript, Python, Rust, ו-stack טכני.

הקהל שלהם: מתכנתים, מהנדסי תוכנה, founders טכניים. המשימה שלהם: לכתוב קוד טוב יותר, מהר יותר. הסיכון: קוד עם bug שעולה לפרודקשן. הפתרון: code review, tests, CI/CD.

מה זה סוכן שמפעיל תוכנה (זה הקורס שלנו)

Codex for Chrome, Claude in Chrome, Atlas, Operator, Gemini Computer Use — אלה כלים שעוזרים לכם להפעיל תוכנה קיימת. אתם לא כותבים קוד. אתם משתמשים ב-Salesforce, ב-Gmail, ב-Canva, ב-Airtable, ב-figma, ב-stripe, ב-notion, ב-asana — והסוכן מבצע את הפעולות במקומכם. הפלט שלו הוא פעולה שבוצעה: חשבונית הורדה, מייל נשלח, רשומה עודכנה, טופס מולא.

הקהל: אנשי ידע, אנשי תפעול, אנשי מכירות, מנהלי מוצר, אנליסטים. אנשים שעובדים בתוך תוכנות SaaS יומיומיות ורוצים לאטמט משימות חוזרות. הסיכון: פעולה אמיתית בעולם האמיתי (מייל, רשומה, תשלום). הפתרון: human-in-the-loop, audit, allowlist.

איפה הקו מטשטש

יש אזורים אפורים, וחשוב להכיר אותם:

• Codex ה-CLI של OpenAI הוא סוכן-קוד. Codex for Chrome הוא סוכן שמפעיל דפדפן. אותו שם, שתי קטגוריות שונות לחלוטין. זה מבלבל בכוונה, וזה בדיוק הסיבה שאתם צריכים את ההבחנה הזו.
• Claude Code יכול להפעיל כלי CLI (command-line) ולקרוא ל-APIs. Claude in Chrome פועל בתוך הדפדפן. שניהם קוראים ל-Claude, שניהם סוכנים — אבל הם לא אותו מוצר.
• Cursor הוא IDE (סביבת פיתוח) עם AI מובנה. זה סוכן-קוד. אין לו computer use.

למה ההבחנה משנה לכם

אם אתם לא מתכנתים — ורוב קהל היעד של הקורס הזה לא — אתם לא צריכים Claude Code. אתם צריכים כלי שמפעיל את ה-Salesforce, את ה-Gmail, את ה-figma. אם תנסו להשתמש ב-Claude Code לזה, תתעצבנו מהר — הוא לא רואה דפדפן, הוא לא יודע ללחוץ על כפתורים ב-UI, הוא לא מבין workflows ויזואליים. זה כמו לנסות להכין סלט עם פטיש — הפטיש מצוין למסמרים, אבל לא לעגבניות.

הקורס הזה מלמד רק את הסוג השני. אם אתם רוצים גם סוכני-קוד, יש קטגוריה אחרת בקטלוג (ai-coding).

המנגנון מאחורי הקלעים — computer use tool vendor-agnostic

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

"computer use tool" — השם הרשמי

המנגנון נקרא computer use tool (או בשם הקצר "CUT"). זה tool (כלי) שמודל AI יכול לקרוא — בדיוק כמו שמודל קורא ל-search, או ל-calculator, או ל-database query. ההבדל: ה-tool הזה מקבל צילום מסך כקלט, ומחזיר פעולה כפלט. ב-OpenAI זה נקרא computer_use_preview, ב-Anthropic זה ה-"computer use" beta, ב-Google זה חלק מ-Gemini 2.5 Computer Use API.

ברמת הקריאה למודל, זה נראה ככה בערך (פסאודו-קוד):

// המודל רואה:
{
  "screenshot": "<binary>", // תמונה של המסך
  "task": "תוריד את החשבונית", // המשימה
  "history": [...], // מה הסוכן עשה עד עכשיו
  "tools": ["computer_use"] // שמות הכלים הזמינים
}

// המודל מחזיר:
{
  "action": "click",
  "coordinate": [450, 320],
  "reasoning": "זה המיקום של כפתור 'הורד' בעמוד החשבונית"
}

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

מה זה לא אומר

חשוב להבין מה המנגנון הזה לא עושה:

• הוא לא נותן למודל גישה למערכת ההפעלה. המודל רואה צילום-מסך, לא רואה קבצים, תהליכים, או רשת.
• הוא לא נותן למודל גישה ל-DOM. במצב basic, רק צילום. רק browser-use agents שמשלבים גם DOM יכולים לראות את מבנה הדף.
• הוא לא קורא ל-API. זה כלי ויזואלי, לא API. אם אתם רוצים API, אתם צריכים API-first agent, לא computer use.

למה זה משנה לכם

ההבנה שהמנגנון הוא vendor-agnostic נותנת לכם שלוש יתרונות מעשיים:

1. אתם יכולים לעבור בין מוצרים בלי ללמוד מנגנון חדש. Codex, Claude, Atlas — כולם אותו רעיון, רק implementations שונים.
2. אתם יכולים להשוות מוצרים על אותו ציר: מי נותן את הצילום האיכותי ביותר, מי מהיר יותר, מי זול יותר. ה-framework זהה, הערכים שונים.
3. אתם יכולים להבין באגים. כשמוצר נשבר, זה כמעט תמיד באחד משלושת השלבים: צילום לא-ברור, החלטה שגויה, או פעולה שלא-התבצעה. לדעת איפה הבעיה עוזר לתקן.

מיקום בקטלוג: קורס זה מול ai-agents-guide ו-agent-harness

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

שלושה קורסים, שלוש זוויות

ai-agents-guide — "מה זה סוכן". קורס זה מסביר את הרעיון המופשט: מה הופך תוכנה לסוכן, מה זה reasoning loop, מה זה memory, מה זה planning, מה ההבדל בין agent לבין workflow. אם אתם לא יודעים מה זה agent, ולא יודעים איך הם עובדים ברמה הקונספטואלית — התחילו שם. קורס זה מניח שאתם יודעים את זה.

agent-harness — "איך בונים סוכן". קורס זה מסביר איך לבנות סוכן: כותבים code, מגדירים tools, מחברים APIs, בונים state machine, מטפלים בשגיאות, מפעילים בפרודקשן. אם אתם רוצה לפתח סוכן משלכם (developer), התחילו שם. קורס זה לא מלמד את זה.

computer-use-agents (הקורס הזה) — "איך מפעילים סוכן שמפעיל תוכנה". קורס זה מלמד אתכם להשתמש בסוכנים קיימים (Codex, Claude, Atlas, Operator וכו') לעבודת-ידע אמיתית. אתם לא בונים סוכן. אתם לא מגדירים reasoning loop. אתם בוחרים כלי, מגדירים משימה, מפעילים, מפקחים, מודדים. זה המקום בקטלוג לאנשי-ידע, לא למפתחים.

איזה קורס מתאים לכם

תלוי איפה אתם נמצאים:

• "אני לא יודע מה זה agent בכלל." → התחילו ב-ai-agents-guide.
• "אני רוצה לבנות agent משלי." → לכו ל-agent-harness.
• "אני רוצה להשתמש ב-ChatGPT/Claude כדי שיעשו לי עבודה ב-Salesforce/Gmail/portal." → אתם במקום הנכון.

הצלבות בקטלוג

כשתתקלו במושגים מ-agent-harness (כמו "tool calling", "function calling", "memory", "vector store") — אלה רלוונטיים גם כאן, אבל אנחנו לא נעמיק בהם. הם רקע, לא ה-core. בקורס הזה, אנחנו מתמקדים במה שקורה בתוך הדפדפן, לא במה שקורה מאחורי הקלעים של הקוד.

באופן דומה, המושגים מ-ai-agents-guide (כמו "ReAct", "chain-of-thought", "agent loops") — הם רקע תיאורטי. אנחנו נשתמש בהם ברמה המעשית (הלולאה שראינו), לא ברמה האקדמית. אם תרצו להעמיק, יש cross-links בסוף כל פרק.

למה המנגנון הזה ages well — גם כשהמוצרים מתחלפים

לפני שאתם סוגרים את הפרק הזה, עצרו רגע וחשבו על משהו חשוב: ב-2025 Project Mariner של גוגל נסגר, ובמרץ 2026 OpenAI הודיעה על מיזוג Atlas + ChatGPT desktop + Codex לאפליקציה אחת. Codex for Chrome עצמו הושק רק ב-7 במאי 2026, והוא לא זמין באירופה. זה אומר שכל מוצר ספציפי שנקרא לו בשם היום עלול להיעלם או להשתנות תוך 6-12 חודשים.

ה-frame היציב

ה-frame שלמדנו בפרק הזה לא תלוי במוצר:

• computer-use / browser-use / API-first — זה חלוקה קטגורית שתישאר רלוונטית גם אם כל המוצרים ישתנו.
• screenshot → reason → act — זה המנגנון הבסיסי של כל computer use. גם אם המודל ישתנה, הרעיון יישאר.
• signed-in session access — זה הדרך שבה כל ההרשאות עוברות. גם אם הממשק ישתנה, המודל הזה נשאר.
• blast radius — זה המדד לסיכון. גם אם הכלי ישתנה, המדד יישאר.

זה מה שהופך את הקורס הזה לעמיד בפני זמן. אתם לא לומדים Codex. אתם לומדים לחשוב על computer-use agents בצורה שמתאימה גם לדור הבא של המוצרים.

מה הקורס ייתן לכם עד הסוף

תכננו את הקורס הזה כך שתצאו ממנו עם workflow עבודת-ידע אחד, אמיתי, מפוקח ומדוד. לא תצפו בדמו. לא תקראו case study של מישהו אחר. אתם תבחרו משימה אמיתית בעולם שלכם, אתם תבחרו את הכלי, אתם תריצו, אתם תמדדו, אתם תחליטו אם זה ready-לפרודקשן או נשאר תחת פיקוח. זה הקפיץ מ"הבנה" ל"יישום".

הדרך לשם עוברת דרך 7 פרקים. פרק 1 (הפרק הזה) נתן לכם את המפה. פרק 2 ייתן לכם את המוצרים. פרקים 3-6 ייתנו לכם את הכלים, הסיכונים, הבחירה, וההגנות. פרק 7 ישלב את הכל ל-capstone. בואו נתחיל.