Agentic Browser Architecture — תכנון Browser Agent לפרודקשן

מאת צוות מדיה דיל · 09.08.2026 · AI · 8 דק׳

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

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

שכבת ה-Browser Pool — ניהול מחזור חיים של דפדפנים

הרצת instance חדש של דפדפן לכל משימה יקרה ואיטית (שניות של זמן עלייה). הפתרון הסטנדרטי הוא Browser Pool: מספר קבוע של instances דפדפן שרצים כל הזמן, שמוקצים למשימות נכנסות ומוחזרים לפול כשהמשימה מסתיימת. זה דורש ניהול קפדני של מצב: כל instance חייב לחזור למצב "נקי" (context חדש, cookies ריקים) לפני שהוא משורת למשימה הבאה, אחרת מידע מ-session אחד יכול "לדלוף" לתוך המשימה הבאה — בעיה חמורה במיוחד כשמדובר בנתוני משתמשים שונים.

{
  "browser_pool": {
    "min_instances": 5,
    "max_instances": 40,
    "instance_ttl_hours": 2,
    "context_isolation": "per-task",
    "recycle_after_tasks": 50
  }
}
// כל instance מוחזר לפול עם context נקי לגמרי,
// ומוחלף לגמרי (לא רק מנוקה) אחרי מספר משימות או זמן קבוע

בידוד Session — לא רק ביצועים, גם אבטחה

מעבר ליעילות, בידוד session הוא דרישת אבטחה: אם שני משתמשים שונים מפעילים משימות Browser Agent על אותו יעד בו-זמנית, cookies או local storage שדלפו בין contexts יכולים לגרום לבלבול חמור — הרשאות של משתמש אחד "זולגות" למשימה של אחר. הפתרון המעשי הוא Browser Context נפרד (לא רק tab נפרד) לכל משימה, עם ניקוי מלא בסיום, בדומה לעקרונות בידוד שנדונים בSandboxing ל-AI באופן כללי.

טיפול בכשלים: Retry, Circuit Breakers ו-Graceful Degradation

ל-Browser Agent יש הרבה יותר נקודות כשל אפשריות ממערכת API רגילה: timeout ברשת, אלמנט לא נטען, שינוי בעיצוב האתר, חסימת בוט. ארכיטקטורה עמידה צריכה שכבות טיפול כשל נפרדות:

• Retry עם backoff — כשל חד-פעמי (timeout רגעי) מקבל ניסיון חוזר, לא כישלון מיידי.
• Circuit Breaker — אם אתר יעד מסוים נכשל שוב ושוב, המערכת מפסיקה לנסות זמנית ומתריעה, במקום להמשיך לשלוח בקשות למשהו שכבר לא עובד — עיקרון מוכר מארכיטקטורת Retry ל-Agents.
• Graceful degradation — כשמשימה נכשלת חלקית, המערכת מחזירה את מה שכן הצליחה לאסוף, עם דיווח ברור על מה נכשל, במקום להיכשל בכללי ולאבד גם את החלק שהצליח.

ניטור וצפייה — מה שקורה בתוך הדפדפן חייב להיות גלוי

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

• Screenshot בכל צעד קריטי — לא כל frame, אבל לפחות לפני ואחרי כל פעולה משנה-מצב.
• הקלטת session מלאה (video או trace) לתרחישים בסיכון גבוה, שאפשר לחזור אליהם בחקירת כשל.
• מדדי ביצועים לכל שלב — כמה זמן לקח כל צעד, כמה tokens נצרכו, שיעור הצלחה לפי סוג משימה — נושא שמתחבר לObservability ל-LLM הרחב יותר.

עלות בקנה מידה — מה שנראה זול בדמו לא נשאר זול

Browser Agent שמבצע 5-10 קריאות מודל למשימה בודדת, כשמריצים אותו אלפי פעמים ביום, הופך למרכיב עלות משמעותי. אופטימיזציות מעשיות כוללות: שימוש במודל קטן וזול יותר לצעדי ניווט פשוטים ומודל חזק רק לפעולות שדורשות שיקול דעת, caching של תיאורי דף חוזרים, וצמצום גודל הייצוג שנשלח למודל (רק אלמנטים רלוונטיים, לא כל ה-DOM). כל אלה נופלים תחת אותם עקרונות של הנדסת עלויות AI שרלוונטיים לכל מערכת LLM בקנה מידה.

Load Testing לפול הדפדפנים

לפני שסומכים על הפול בעומס פרודקשן אמיתי, שווה לבדוק אותו תחת עומס מבוקר: מה קורה כשכל ה-instances תפוסים ומגיעה בקשה נוספת — היא ממתינה בתור, או נדחית? מה קצב יצירת instance חדש כשצריך להרחיב את הפול באמצע עומס? האם יש נקודת כשל יחידה (למשל שירות ניהול הפול עצמו) שקורסת תחת עומס גם אם ה-instances עצמם תקינים? בדיקת עומס ייעודית ל-browser pool, לא רק לשכבת ה-API הרגילה, חושפת צווארי בקבוק שקל לפספס כי הם לא מופיעים בבדיקות עומס גנריות שלא מביאות בחשבון את העלות הגבוהה של הרצת דפדפן מלא.

Scheduling ותזמון — מתי משימות רצות

ברוב מקרי השימוש בפרודקשן, Browser Agent לא רץ בזמן אמת מול משתמש ממתין, אלא כמשימת רקע מתוזמנת או מונעת אירוע (webhook, תור הודעות) — דפוס שמתאים לארכיטקטורה מונעת אירועים. זה מאפשר לתזמן ריצות בשעות עומס נמוך, להריץ מספר משימות דומות כ-batch, ולהימנע מלחסום את חוויית המשתמש בזמן שהדפדפן "עובד" ברקע.

Health Checks לפול הדפדפנים

instance של דפדפן יכול "להיראות" תקין (התהליך רץ) אבל להיות בפועל תקוע במצב לא שמיש — זיכרון שדלף לאורך שעות ריצה, tab שנתקע ברינדור אינסופי. בדיקת בריאות (health check) פשוטה כמו "האם התהליך חי" לא מספיקה; נדרשת בדיקה פונקציונלית — למשל ניסיון ניווט לדף בדיקה פשוט ומדידת זמן התגובה — שרצה תקופתית על כל instance בפול ומוציאה אוטומטית מהמחזור כל instance שלא עומד בסף. בלי בדיקה כזו, הפול מתמלא בהדרגה ב"אזורים מתים" שממשיכים להיחשב זמינים אך בפועל מאטים או מכשילים כל משימה שמוקצית אליהם.

ניהול Secrets לפרטי התחברות של דפדפנים

Browser pool שמריץ משימות שדורשות התחברות למערכות שונות צריך גישה מבוקרת לאוסף אישורי כניסה, ולא credentials מוטמעים בקוד. הפתרון הנכון הוא ששכבת ה-orchestration שולפת credential רלוונטי ממנהל Secrets ייעודי בתחילת כל משימה, מזריקה אותו ל-context של אותו instance בלבד, ומוודאת שהוא לא נשמר בשום מקום אחרי סיום המשימה — לא בלוגים, לא ב-storage state ששרד להרצה הבאה. עיקרון זה זהה לחלוטין לניהול Secrets בכל מערכת production אחרת, כמתואר במדריך ניהול Secrets ל-AI, רק שכאן יש תשומת לב נוספת לכך שה-secret "עובר" דרך שכבה ויזואלית (הקלדה בפועל בשדה) ולא רק דרך קריאת API.

אבטחת רשת: Egress Filtering לדפדפנים

דפדפן שרץ בתוך תשתית הארגון ומבצע ניווט לפי הוראות מודל שפה הוא בעצם ערוץ יציאה (egress) פוטנציאלי מהרשת הפנימית. בלי בקרה, Agent שהוטעה (למשל דרך Prompt Injection עקיף) יכול לנווט לדומיין לא מורשה ולדלוף מידע. הפתרון הארכיטקטוני הוא allowlist דומיינים ברמת הרשת עצמה (לא רק ברמת קונפיגורציית ה-Agent) — proxy שמאפשר רק תעבורה ליעדים מאושרים מראש, כך שגם אם ה-Agent "מנסה" לנווט לאנשהו אחר, החיבור נחסם ברמת התשתית. זה מתקשר ישירות לעקרונות Zero Trust שרלוונטיים לכל Agent עם גישה לרשת.

איפה הפול רץ בפועל: מיקום התשתית

החלטת deployment משפיעה ישירות על latency ואמינות: הרצת browser pool קרוב פיזית (מבחינת רשת) לשירותים שה-Agent צריך לתקשר איתם מקצרת את זמן הביצוע לכל צעד. עבור ארגונים עם תשתית פרודקשן קיימת, הפול הרבה פעמים רץ כחלק מאותה תשתית container orchestration שמריצה שירותים אחרים — עם quota משאבים נפרד, כי דפדפנים צורכים זיכרון ו-CPU בצורה שונה מאוד משירותי backend רגילים, ודורשים תכנון capacity ייעודי במסגרת תשתית הפרודקשן הכוללת.

טעויות נפוצות

• הפעלת instance דפדפן חדש לכל משימה בלי pool — עלות ביצועים מיותרת שמצטברת מהר.
• שיתוף context בין משימות — בעיית בידוד שיכולה לגרום לדליפת מידע בין משתמשים.
• אין circuit breaker לאתרי יעד בעייתיים — המערכת ממשיכה "לדפוק על דלת סגורה" ומבזבזת משאבים.
• ניטור מבוסס לוג טקסט בלבד — בלי screenshots או trace, כמעט בלתי אפשרי לחקור כשל ויזואלי בדיעבד.

Snapshot Testing לזיהוי שינויים באתר היעד

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

שאלות נפוצות

כמה instances של דפדפן צריך בפול לתחילת דרך?

תלוי בנפח המשימות בו-זמנית, אבל עקרון טוב להתחלה הוא להתחיל קטן (3-5 instances), למדוד תפוסה בפועל, ולהרחיב בהדרגה — לא לתכנן קיבולת מראש על סמך הערכה בלבד שעלולה להתברר כשגויה בכיוון זה או אחר.

איך מונעים מ-Browser Agent "לתקוע" את כל הפול כשהוא נתקע בלולאה?

timeout קשיח לכל משימה ברמת ה-orchestration, לא רק ברמת הפעולה הבודדת, כך שגם אם ה-Agent "לא מבין" שהוא תקוע, המערכת מוציאה אותו החוצה ומשחררת את ה-instance.

האם צריך תשתית ייעודית, או שאפשר להשתמש בשירותי ענן קיימים?

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

איך זה משתלב עם Approval Gates לפעולות רגישות?

בדיוק כמו כל Agent אחר — כל פעולה משנה-מצב (שליחת טופס, אישור עסקה) יכולה לעבור דרך Approval Gate לפני ביצוע בפועל בדפדפן, עם ה-screenshot של המצב המוצע כחלק מבקשת האישור.

מה ההבדל בין Browser Pool לבין הרצת Browser Agent בודד לצורך פיתוח?

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

איך מתכננים capacity ל-browser pool כשהעומס לא ידוע מראש?

מתחילים עם pool קטן ומדדי ניטור מלאים על תפוסה וזמני המתנה, ומרחיבים בהדרגה על סמך נתונים אמיתיים במקום הערכה תיאורטית מראש. autoscaling מבוסס תפוסה בפועל, עם min/max ברור, עדיף על ניחוש קיבולת קבועה מראש.

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

תגיות: Agentic Browser Architecture · Browser Agent Production · Session Isolation · AI Agent Reliability · Circuit Breaker AI · Browser Pool

← חזרה לבלוג · צור קשר