הסוכן הראשון שלך — להריץ משימה אמיתית מקצה-לקצה, מפוקח

כש-Chrome מציג לכם את רשימת ההרשאות, אלה הקטגוריות המרכזיות שתראו:

• Read and change all your data on websites — זו ההרשאה שמאפשרת לסוכן לראות מה יש בכל אתר שאתם גולשים אליו, וגם לשנות טפסים, ללחוץ כפתורים, להזין טקסט. בלי זה, הוא לא יכול למלא שום טופס. הסיכון: אם מותקן בפרופיל הראשי, יש לו גישה לכל סשן מחובר.
• Read your browsing history — מאפשר לסוכן להבין איפה הייתם ולקבל הקשר. גם דרך זו הוא יכול לדעת שיש לכם סשן פתוח ב-Gmail, ב-Salesforce, ב-portal של ספק. הסיכון: דליפת היסטוריית גלישה למודל.
• Manage your downloads — מאפשר לסוכן להוריד קבצים: חשבוניות, דוחות, קבצי CSV. הסיכון: הוא יכול להוריד גם דברים שלא ביקשתם, אם הוא מפרש לא נכון.
• Debugger — גישה ל-Chrome DevTools. זה מה שמאפשר ל-Claude Code לקרוא console errors, לבדוק network requests, ולבצע build-test-verify. רוב המשתמשים לא צריכים את זה למשימות read-only, אבל ה-extension מבקש את זה מראש.
• Tab Groups — יכולת לקבץ טאבים. זה תמים לכאורה, אבל זה גם אומר שהסוכן יכול לפתוח טאבים חדשים בשמכם. הסיכון: אם הוא נתקע בלולאה, הוא עלול לפתוח עשרות טאבים ריקים.

למה כל ההרשאות האלה נדרשות? כי מודל ה-computer-use עובד כך: הוא מצלם את המסך, רואה אלמנטים על הדף, צריך גישה ללחוץ עליהם ולהקליד בהם. בלי גישה "read and change all data" — הוא יכול לראות את המסך, אבל לא לפעול. בלי "manage downloads" — הוא לא יכול לשמור קבצים. זה לא "הרשאות מפחידות" — זה המחיר של היכולת. ההחלטה אינה "להעניק או לא" אלא "באיזה פרופיל להעניק".

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

הטעות הקריטית של מתחילים היא להתקין את ה-extension בפרופיל הראשי של Chrome, שבו מחוברים Gmail, בנק, Salesforce, LinkedIn, ועוד עשרות חשבונות. ברגע שהסוכן רץ — גם אם רק read-only — הוא רואה הכל. הפתרון הוא פרופיל נפרד.

Chrome תומך בפרופילים מרובים (Settings → You and Google → Add person). צרו פרופיל חדש בשם "Agent" או "Sandbox", התקינו בו את ה-extension, והתחברו רק לחשבונות שאתם רוצים שהסוכן יראה. בפרק 6 נרחיב את ההיבט של הפרופיל הייעודי, הרשאות מינימליות, ו-memory isolation. לעת עתה, מספיק לזכור כלל אחד: אל תתקינו את ה-extension בפרופיל הראשי שלכם לפני שהבנתם איך הוא מתנהג.

תהליך ההתקנה עצמו קצר. ל-Claude in Chrome: פתחו Chrome Web Store, חפשו "Claude", לחצו "Add to Chrome", אשרו הרשאות, יופיע חלון קופץ שמבקש login ל-Anthropic. ל-Codex for Chrome: פתחו Codex (אפליקציה או web), לכו ל-Codex Plugins, חפשו "Chrome", לחצו Install, ה-extension מותקן ומופעל אוטומטית. בשני המקרים, אחרי ההתקנה תראו את האייקון של הסוכן ב-toolbar של Chrome.

חוק הזהב של ההרצה הראשונה — Read-Only First

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

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

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

מה נחשב "קריאה-בלבד"?

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

• כן, קריאה-בלבד: לסכם את כל המיילים מהיום האחרון ב-Gmail. לקרוא את המספרים מ-dashboard של אנליטיקס. להוציא רשימת הזמנות מפורטל ספק. לאסוף שמות וטלפונים מ-LinkedIn. להשוות מחירים משלוש אתרי סחר.
• לא, זה כתיבה: לשלוח מייל. לעדכן תאריך ב-Calendar. לסמן מייל כנקרא. להוריד חשבונית (כי זה יוצרת קובץ חדש במערכת). למלא טופס וללחוץ Submit.
• תלוי: להוריד דוח (קובץ עובר למחשב שלכם, זו לא כתיבה במערכת המקור — אבל זה כן side-effect במכונה שלכם).

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

משימת קריאה-בלבד לדוגמה — לסכם dashboard מחובר על-פני tabs

עכשיו אתם יודעים שההרצה הראשונה צריכה להיות read-only. השאלה הבאה היא: איזה משימה? הקריטריונים: (1) שימושית עבורכם בעולם האמיתי, (2) קצרה יחסית (עד 5 דקות לסוכן), (3) ללא צורך ב-2FA או CAPTCHA, (4) על ממשק שאתם כבר מכירים.

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

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

בחרו אחת מהדוגמאות האלה (או דומה להן), ובצעו את הצעדים הבאים. הצעדים מתוארים באופן כללי, ומתאימים גם ל-Claude in Chrome וגם ל-Codex for Chrome — שני ה-extension מציגים UI דומה בעקרונותיו.

הצעדים — הרצה ראשונה ב-Claude in Chrome

צעד 1 — פתחו את ה-Chrome profile הייעודי (זה שיצרתם עם ה-extension). ודאו שהוא נבדל מהפרופיל הראשי שלכם, ושאתם מחוברים רק לחשבונות שאתם רוצים שהסוכן יראה.

צעד 2 — פתחו את הטאב/ים הרלוונטיים. עבור דוגמת ה-Jira, פתחו טאב אחד עם רשימת הכרטיסים. עבור דוגמת ה-Gmail, פתחו את Gmail. אם יש לכם מספר tabs, פתחו את כולם.

צעד 3 — לחצו על אייקון ה-extension ב-toolbar. תיפתח תיבת chat (בצד הימני של ה-Chrome, במצב RTL). בתיבה, הקלידו את המשימה שלכם בשפה טבעית: "תסכם לי את הכרטיס הראשון ב-Jira — כותרת, סטטוס, assignee, ועדיפות". הימנעו מפקודות ארוכות עם הרבה תנאים; התחילו בפשוט.

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

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

ה-latency האמיתי — למה זה לוקח יותר זמן ממה שאתם חושבים

אחת ההפתעות הגדולות של מתחילים היא שמשימה שלוקחת לכם 30 שניות ידנית יכולה לקחת לסוכן 2-5 דקות. הסיבה: הלולאה screenshot→reason→act היא איטית מטבעה. הסוכן מצלם (300-800ms), שולח למודל (1-3 שניות), מקבל פעולה (עוד 500ms-2s), מבצע (1-2 שניות). על משימה של 8-15 פעולות, זה מצטבר.

בנוסף, המודל עצמו לא תמיד מצליח בניסיון הראשון. ייתכן שהוא ילחץ על כפתור לא נכון, יזהה אלמנט לא נכון, או יחזור על פעולה. Anthropic מדווחת ש-Claude in Chrome מצליח ב-workflows מורכבים ב-~60-80% מהפעמים, תלוי במורכבות. תכננו להמתין 3-7 דקות למשימה בינונית, ואל תבטלו את הריצה באמצע אלא אם כן הסוכן תקוע בלולאה ברורה.

Per-Site Confirmation — הגבול האבטחתי האמיתי בפעולה

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

ה-prompt מציג שלוש אופציות, והן בדיוק מה שהשם שלהן אומר:

• "Allow this chat" — אישור חד-פעמי. הסוכן רשאי לפעול באתר הזה, רק במהלך השיחה הנוכחית. ברגע שתסגרו את ה-tab או תתחילו שיחה חדשה, הוא יצטרך לבקש שוב. זו ברירת המחדל הבטוחה ביותר.
• "Always allow host" — אישור קבוע ל-host. הסוכן רשאי לפעול באתר הזה בכל שיחה עתידית, בלי לשאול שוב. זה נוח, אבל זה גם מסיר את ה-confirmation עבור אותו אתר. תחשבו פעמיים לפני שאתם לוחצים על זה.
• "Decline" — דחייה מוחלטת. הסוכן לא יפעל באתר הזה. הוא יציע לכם משימה חלופית או יעצור. זו האופציה הנכונה לכל אתר שאתם לא מכירים, לא סומכים עליו, או לא רוצים שהסוכן יגע בו.

בפועל, מה שקורה הוא זה: אתם פותחים את המשימה ("תסכם את ה-Jira שלי"), הסוכן רואה שצריך לפעול ב-app.atlassian.net, הוא מבקש אישור. אתם לוחצים "Allow this chat" (כי זו הרצה ראשונה), הסוכן מתחיל לעבוד. ברגע שהוא סיים את המשימה, אם תפתחו שיחה חדשה, הוא יצטרך לבקש שוב. זו ההתנהגות הרצויה.

המלכודת היא הציפייה. אחרי 3-4 הרצות שבהן לחצתם "Allow this chat" על אותו אתר, אתם מתחילים לחשוב "למה לא פשוט Always?". התשובה: כי ברגע שתלחצו "Always allow host", אתם מסירים שכבת הגנה. אם הסוכן יחטוף prompt injection (קוד זדוני בתוך תוכן האתר שמשפיע על ההתנהגות שלו), הוא יוכל לפעול בלי שתדעו. Anthropic מדדה את זה: גם אחרי מיטיגציות, attack-success-rate של prompt injection ב-Claude in Chrome הוא 11.2% — 1 מכל 9 התקפות מצליח. "Always allow host" לא גורם לזה, אבל הוא מסיר את האזעקה שתופסת חלק מהמקרים.

בפרק 6 נרחיב את המודל הזה לעומק — כולל allowlist/blocklist גלובליים, פרופילים ייעודיים, ו-memory isolation. לעת עתה, הכלל הפשוט: "Allow this chat" כברירת מחדל, "Decline" לכל דבר לא-מוכר, "Always allow host" רק אחרי שאתם באמת מבינים מה הסיכון.

טבלת ההחלטה — מתי Allow, מתי Always, מתי Decline

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

העיקרון המנחה פשוט: החלטה דיפולטיבית היא "Allow this chat", וכל חריגה דורשת נימוק. כשאתם מתלבטים, "Allow this chat" כמעט תמיד נכון. "Always allow host" כמעט אף פעם לא נכון בהרצה הראשונה. "Decline" כמעט תמיד נכון לכל מה שלא-מוכר.

Allowlist ו-Blocklist גלובליים — הרובד השני

בנוסף ל-confirmation prompt, בהגדרות של ה-extension (Codex for Chrome: Computer Use settings; Claude in Chrome: Settings → Computer use) יש שני מסננים גלובליים: Allowlist (אתרים שתמיד מותר לסוכן לפעול בהם בלי prompt) ו-Blocklist (אתרים שאף פעם לא מותר). זה הרובד השני של ההגנה, והוא רץ לפני ה-confirmation prompt.

ההגדרה מומלצת להתחלה: השאירו את ה-allowlist ריקה (כלומר, אין אתר שמותר בלי prompt), והוסיפו ל-blocklist את כל הדברים הרגישים — בנקים, מס, ביטוח לאומי, מערכות פנימיות של חברה, אפליקציות SaaS שמחזיקות נתוני לקוחות. ככל שתצברו ניסיון, תוכלו להעביר אתרים מ-allowlist אל "Allow this chat" רגיל.

פיקוח חי — Live View, pause, interrupt, take-over

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

Live View / Streaming — אתם רואים את המסך של הסוכן בזמן אמת. כל צילום-מסך שהוא לוקח, אתם רואים. כל פעולה שהוא מתכנן, אתם רואים (בדרך כלל כ-text overlay על המסך). Claude in Chrome מציג גם את "מחשבות" הסוכן: "אני רואה שיש כפתור 'עדכן' בפינה הימנית-תחתונה, אני לוחץ עליו". Codex for Chrome מציג פחות טקסט, אבל מציג חיווי ויזואלי על כל פעולה. תנאי חובה: אל תסגרו את ה-tab של ה-Live View. זה הcontrol plane שלכם.

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

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

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

מתי להשתמש בכל יכולת

הזהב בהרצה הראשונה: השתמשו ב-pause ברגע שאתם לא בטוחים. אל תחכו שהסוכן יעשה טעות — תעצרו אותו לפני. הtake-over הוא למצבי חירום: הסוכן תקוע, אתם צריכים לעשות פעולה ידנית (למשל, לאשר 2FA), ואז להחזיר לו. interrupt הוא כשאתם רואים שהוא עומד לעשות פעולה בלתי-הפיכה בלי שאישרתם.

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

הנתיב החינמי במקביל — Browser Use OSS מקומי

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

Browser Use הוא framework open source שמאפשר לכם להריץ agent שמפעיל דפדפן, ב-Python, עם vision LLM שאתם מביאים. הוא רץ על המכונה שלכם (או בכל מקום שתריצו Python), משתמש ב-Playwright (או ב-Chromium ישירות), ומחזיר לכם control מלא על מה שקורה. הוא לא extension — הוא סוכן עצמאי שמפעיל דפדפן דרך קוד.

הרכיבים הנדרשים: Python 3.13 (או 3.11+), Playwright להפעלת Chromium, vision LLM לקבלת פעולות. ה-LLM יכול להיות Claude (API), GPT (API), Gemini (API), או GLM-5.1 דרך Z.AI — האופציה הזולה ביותר עם תמיכה מצוינת ב-vision. העלות לכל הרצה: כמה סנטים ב-tokens, תלוי במורכבות.

התקנה — 5 שורות

ההתקנה עצמה קצרה. אחרי שיש לכם Python 3.13, אתם צריכים את המודולים האלה:

pip install browser-use playwright
playwright install chromium
export ZAI_API_KEY="..."   # API key שלכם מ-Z.AI

את המודול browser-use אפשר להחליף בגרסה קודמת (היא רצה ב-2026) או במודולים מקבילים כמו langgraph עם browser tools, או crewai עם custom actions. העיקרון זהה: agent loop → screenshot → LLM → action.

למה להריץ במקביל ל-extension?

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

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

הסיבה השלישית היא עלות. עבור משימות חוזרות ב-volume, ה-DIY זול משמעותית. תשלום רק על tokens של vision LLM, בלי מנוי חודשי לספק.

איך נראית משימה ב-Browser Use — אנטומיה של ריצה

בואו נראה קוד אמיתי. הדוגמה הבאה מריצה את אותה משימה שהרצנו ב-extension — סיכום 3 כרטיסי Jira — אבל ב-Browser Use. הקוד פשוט, והמטרה היא שתראו איך הלולאה נראית מבפנים.

from browser_use import Agent
from langchain_openai import ChatOpenAI
import asyncio
import os

async def main():
    llm = ChatOpenAI(
        base_url="https://api.z.ai/api/paas/v4/",
        model="glm-4.5v",
        api_key=os.environ["ZAI_API_KEY"],
    )
    agent = Agent(
        task=(
            "היכנס ל-Jira, סכם 3 הכרטיסים הפתוחים הראשונים שלי. "
            "לכל כרטיס תן: כותרת, סטטוס, assignee, עדיפות. "
            "אל תשנה דבר. אל תלחץ submit על שום טופס."
        ),
        llm=llm,
    )
    result = await agent.run()
    print(result)

asyncio.run(main())

מה קורה כאן? הtask הוא ה-prompt — בשפה טבעית, בעברית. ה-LLM הוא GLM-4.5V (vision LLM של Z.AI) — זול, מהיר, תומך vision. ה-agent מקבל את ה-task, פותח דפדפן, מצלם, שולח ל-LLM, מקבל פעולה, מבצע. בלולאה.

ההבדל המהותי מה-extension: אתם רואים את כל הצעדים בטרמינל. זה שקוף. אתם יכולים לעצור באמצע (Ctrl+C), לבדוק את הקובץ screenshots ש-browser-use שומר אוטומטית, ולהבין בדיוק איפה הסוכן טעה אם טעה.

השוואה קצרה: extension מול DIY

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

הקח מההשוואה: אין "מנצח". יש כלי שמתאים למשימה. למשימה מהירה על סשן קיים — extension. למשימה חוזרת בלי סשן — DIY. בפרק 4 נרחיב את ההחלטה לקטגוריה שלישית (deterministic).

עברית ו-RTL — האתגר שלא תראו בסרטוני-הדמו

אם אתם עובדים בישראל, חלק משמעותי מהמשימות שלכם ייגעו בממשקים בעברית: פורטל ממשלתי, בנק ישראלי, Priority/חשבשבת, מערכת HR פנימית, חנות מקוונת בעברית. הסוכנים של 2026 לא אומנו בעיקר על ממשקים בעברית. ה-training data שלהם מוטה לכיוון LTR (אנגלית, סינית, יפנית), וה-RTL — Right-to-Left, כיוון הכתיבה מימין לשמאל — הוא edge case.

המשמעות המעשית: צפו לאמינות נמוכה יותר על ממשקים בעברית. מה שעובד ב-90% על Salesforce לא יעבוד ב-90% על מערכת פנימית ישראלית. ייתכן שהסוכן יתבלבל בין "הבא" ל"הקודם" כי החצים הפוכים, ייתכן שהוא לא יזהה נכון תווים עבריים במקום צפוף, ייתכן שהוא ילחץ על הכפתור הלא-נכון כי ה-layout שונה ממה שהוא מכיר.

המלצה קונקרטית: אם המשימה שלכם נוגעת בעברית, אל תסמכו על הרצה אחת מוצלחת. תריצו 3-5 פעמים, תראו אם ההצלחה יציבה. ובמהלך ההרצות, תכננו pause: ייתכן שתצטרכו לתקן את הסוכן באמצע בגלל RTL confusion.

ההיבט השני הוא אזור גיאוגרפי. Codex for Chrome לא זמין ב-EU/UK בהשקה. ישראל מבחינה גיאוגרפית מחוץ ל-EU, אבל ההרצה לרוב מתחילה ב-US-then-rollout. אם אתם רואים הודעת "not available in your region" — זו לא בעיה בחיבור שלכם, זו בעיה בזמינות. תאמתו לפני שאתם מתחילים, במיוחד אם אתם בונים workflow ללקוח באירופה.

ההיבט השלישי הוא רגולציה. אם אתם עובדים עם לקוחות באירופה, GDPR וה-EU AI Act מחמירים את הדרישות סביב logging, consent, ושקיפות. המסמך הזה רלוונטי ישירות לפרק 6, ובפרק 7 (capstone) תצטרכו לעמוד בו אם ה-workflow שלכם נוגע במידע של אזרחי EU.

מה לא לעשות בהרצה הראשונה — 3 קווים אדומים

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

קו אדום 1: אל תתנו לסוכן לבצע פעולה כותבת בהרצה הראשונה. זה אומר: לא לשלוח מייל, לא לעדכן רשומה ב-CRM, לא למלא טופס וללחוץ Submit, לא למחוק כלום. רק קריאה, רק סיכום, רק חיפוש. אם הסוכן מציע "לעזור לכם לעדכן", תאמרו "לא הפעם". הסיבה: בהרצה הראשונה אתם לא מכירים את ההתנהגות שלו. גם אם הוא נראה חכם, הוא עלול לפרש לא נכון. הסיכון לכתיבה לא נכונה = 100% בלתי-הפיכה.

קו אדום 2: אל תתקינו את ה-extension בפרופיל הראשי שלכם. גם אם זה מרגיש "יותר נוח", גם אם "אני רק אריץ את זה פעם אחת". הסיכון: ברגע שהסוכן פעיל, הוא רואה כל טאב פתוח, כל סשן מחובר, כל היסטוריית גלישה. אם משהו ישתבש — ויש סיכוי — ה-blast radius הוא כל החיים הדיגיטליים שלכם. פרופיל נפרד = גבול ברור. זה עולה לכם 2 דקות של יצירת פרופיל, וחוסך לכם שבועות של debug.

קו אדום 3: אל תלחצו "Always allow host" על אתרים לא-מוכרים. גם אם "נמאס לי ללחוץ Allow כל פעם", גם אם "זה רק אתר שאני משתמש בו כל יום". "Always allow host" מסיר שכבת הגנה. אם תלחצו, אתם מבטלים את האזעקה הראשונה שמתריעה כשמשהו לא בסדר. בפרק 6 נרחיב את ההיבט הזה, אבל הכלל פשוט: Always allow host רק אחרי 20-50 הרצות מוצלחות, רק על אתרים שאתם מכירים לעומק, ורק אם אתם מבינים את המשמעות.

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

תיעוד ההרצה — המסמך שיחזיק אתכם עד פרק 7

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

הfirst-run-log הוא הקובץ שילווה אתכם עד הקפסטון בפרק 7. הוא לא צריך להיות ארוך — 15 שורות זה מספיק. הנה התבנית:

## First Run Log — [תאריך]

**כלי:** Claude in Chrome / Codex for Chrome / Browser Use
**גרסה:** [plan וגרסה]
**פרופיל Chrome:** [שם הפרופיל הייעודי]
**משימה:** [טקסט ה-prompt המלא]
**הרשאות שנדרשו:** [רשימת hosts שאושרו]
**זמן הרצה:** [דקות]
**תוצאה:** [מה הסוכן החזיר]
**אימות ידני:** [האם התוצאה תואמת למציאות]
**הערות:** [איפה הסס, איפה טעה, מה לשפר]
**Screenshots:** [קישורים]

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

בפרק 7 (הקפסטון) תריצו את המשימה 10 פעם, ותיצרו טבלה של success rate. ה-first-run-log שלכם הוא הבסיס לאותה טבלה. אם אתם לא מתעדים עכשיו, תצטרכו לשחזר מהזיכרון בפרק 7 — וזה כמעט בלתי-אפשרי.