בונה סוכני דפדפן שבאמת עובדים: CLI, CDP, ולולאת Sense-Act-Verify

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

CLI מנצח MCP למשימה הזו

האינסטינקט הראשוני שלי עם כל כלי סוכן היה לעטוף אותו כ-MCP server. לאוטומציית דפדפן ספציפית, זזתי מזה - והנתונים תומכים בכך. מחקר של Arize AI מצא שגישה מבוססת CLI וגישה מבוססת MCP מצליחות באותן המשימות בערך באותו שיעור - כ-83% מהזמן בשני המקרים. יכולת (capability) היא לא ההבדל.

שימוש חוזר, מהירות, ועלות - כן. כלי מבוסס CLI (קריאות shell) אפשר לתכנת פעם אחת ולהריץ אלף פעמים בלי מודל בלולאה. MCP server מכניס את המודל לכל תור בנפרד. באותו מחקר, גישת MCP לקחה 71 round trips וכ-8 דקות למשימה שגישת CLI סיימה ב-7 תורות, מתחת לדקה. Anthropic דיווחו בנפרד על שימוש בכלי מבוסס CLI שיצא זול פי 75 בעלות טוקנים לעבודה דומה. אם הסוכן שלכם עומד להריץ שגרה יותר מפעם אחת, ההבדל הזה מצטבר מהר.

מפעילים את הדפדפן דרך CDP, לא ספריית עטיפה

ה-Chrome DevTools Protocol הוא אותו פרוטוקול שמאחורי הפנל שנפתח כשלוחצים F12. הפעלת דפדפן ישירות דרך CDP, במקום ספריית אוטומציה ברמה גבוהה יותר, אומרת שהקליקים והקשות המקלדת של הסוכן עוברים את אותו נתיב בדפדפן שהיו עוברים אצלכם. זה פחות עניין של עקיפה ויותר עניין של אמינות: פחות שכבות הפשטה בין "הסוכן החליט ללחוץ" לבין "הקליק באמת קרה" - פחות מקומות שדברים יכולים להישבר בשקט.

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

• לראות את הדף: לקרוא את ה-DOM, לקרוא את עץ הנגישות, או לקחת screenshot כשצריך פיקסלים ממש.
• לשמוע את הדף: לעקוב אחרי תעבורת רשת, פלט console, ולוגים.
• לפעול על הדף: קליק, הקלדה, ניווט.

הלולאה שבאמת הופכת את זה לאמין

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

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

מקרה שימוש אמיתי: מיילים מותאמים אישית בקנה מידה

הנה איפה זה באמת השתלם לי. הייתי צריך לשלוח קבוצת מיילים מותאמים אישית דרך לקוח Outlook מבוסס-ווב. יש API אמיתי לזה, אבל בהרבה סביבות ארגוניות, ה-API של Office 365 דורש app registration ואישור אדמין שעובד רגיל לרוב לא יכול לקבל. ה-login לווב שכבר היה לי מספיק כדי לעשות בדיוק את מה שהייתי צריך, על ידי הפעלה ישירה של הממשק.

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

המסקנה האמיתי

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