מלחמת הטוקנים: למה Playwright CLI מנצח את MCP באוטומציית בדיקות מבוססת AI

המלחמה הבלתי נראית בארגון ההנדסי שלכם

בעשור האחרון פעלתי בנקודת החיבור בין מערכות מורכבות לאיכות תוכנה. ראיתי את הדעיכה האיטית של Selenium legacy ואת העלייה של pipelines מודרניים ודטרמיניסטיים סביב Playwright.

אבל היום הנוף משתנה מהר יותר.

השאלה כבר אינה האם AI יכתוב ויריץ אוטומציית בדיקות. השאלה היא איך הוא יעשה את זה בקנה מידה. כפי שכתבתי ב-קוד הוא זול, הקשר הוא המלך, תפקיד Test Architect עובר מכתיבת boilerplate לניהול agents בתוך Quality Gates קשיחים.

אבל כאשר צוותים ממהרים לחבר LLMs ל-pipeline שלהם, הם נתקלים במציאות מתמטית אכזרית: context window ו-token bloat.

ב-Playwright נוצרו שתי גישות מרכזיות:

1. Playwright MCP: שרת שמציג פעולות דפדפן ככלים ומחזיר למודל snapshots עשירים של accessibility tree.
2. Playwright CLI עם Skills: ממשק command-line שנבנה כדי להיות חסכוני בטוקנים.

זו לא העדפת כלי. זו החלטת ארכיטקטורה. בחירה שגויה תייצר latency, timeouts ועלויות API שלא מתאימות ל-CI/CD אמיתי.

ברוכים הבאים למלחמת הטוקנים.

מאיפה מגיע token bloat

כדי ש-agent יפעל בדפדפן, הוא צריך לראות את מצב העמוד. הוא פועל בלולאה:

Observe -> Reason -> Act

במקום עיניים אנושיות, המודל מקבל מידע מובנה: DOM, accessibility tree או snapshot. כאן מתחילה הבעיה.

Playwright MCP נשען על Accessibility Snapshots: ייצוג YAML של roles, שמות נגישים, states ויחסים היררכיים. זה מעולה ל-targeting סמנטי, אבל גם מאוד verbose.

סדרי גודל:

להכניס snapshot של 138K טוקנים בשביל ללחוץ על כפתור “Submit” זה כמו לבקש מהמודל לקרוא נובלה קצרה בכל צעד.

Playwright MCP: הבנה עשירה במחיר פרימיום

Playwright MCP הוא הנדסה מצוינת. הוא חושף primitives כמו browser_navigate, browser_click ו-browser_snapshot ככלים שכל client תומך MCP יכול לקרוא להם.

היתרון המרכזי שלו הוא Semantic Targeting. המודל מקבל accessibility tree ולכן נוטה לייצר locators טובים כמו getByRole במקום CSS שביר.

MCP מתאים במיוחד ל:

• חקירה של עמודים לא מוכרים.
• self-healing עמוק.
• אבחון כישלונות שבהם צריך להבין hierarchy.
• יצירת locators מאפס.

אבל אותה הבנה עשירה הופכת לחיסרון ב-pipeline עתיר ריצות.

אם כל snapshot נשמר בתוך transcript של השיחה, עלות הטוקנים גדלה בצורה ריבועית. בצעד 5 המודל קורא מחדש snapshots מצעדים 1 עד 4. בצעד 10 הוא כבר סוחב היסטוריה עצומה. התוצאה: latency, שכחת הוראות, hallucinations ועלויות ענן מיותרות.

Playwright CLI: צלף הטוקנים

ה-CLI הופך את המודל.

במקום להכניס את כל מצב העמוד לתוך context window, הוא שומר את ה-snapshot על הדיסק ומחזיר למודל פלט קצר: refs יציבים ו-summary.

לדוגמה:

playwright-cli snapshot
# e15: [Button] "Submit"
# e5:  [Textbox] "Email Address"

עכשיו ה-agent לא צריך לקרוא 200KB YAML. הוא צריך לדעת:

playwright-cli fill e5 "admin@testshift.com"
playwright-cli click e15

זהו שינוי גבול חשוב: ה-accessibility tree נשאר מחוץ לחלון ההקשר. המודל משתמש בטוקנים לחשיבה, לא לבליעת רעש.

הכלכלה האכזרית

ב-UI automation אג’נטי, Time-To-First-Token הוא קריטי. אורך הקלט משפיע ישירות על latency. אם agent קורא 150K טוקנים לפני כל click, בדיקת E2E של עשרה צעדים יכולה להפוך מדקות לשמונה או עשר דקות.

ב-CI/CD זה לא עובד.

השוואה ארכיטקטונית:

מתי להשתמש במה

זה לא מאבק של “טוב מול רע”. זו החלטת systems design.

MCP מייעל semantic fidelity. CLI מייעל context efficiency.

ה-blueprint שלי:

להשתמש ב-MCP עבור exploration ו-healing

כאשר צריך להבין עמוד שבור, ליצור locators, לחקור hierarchy, או לתת ל-agent תמונה עמוקה של UI לא מוכר, MCP מצדיק את המחיר.

להשתמש ב-CLI עבור execution ו-CI/CD

כאשר יש test plan ידוע, flow סטנדרטי, או pipeline שצריך להריץ הרבה פעמים, default ל-CLI או native tools. המודל צריך לחשוב על business logic, לא לקרוא שוב ושוב את אותו עץ נגישות.

סיכום: ארכיטקטורה לפני קסם

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

לא מנצחים את מלחמת הטוקנים עם מודל גדול יותר.

מנצחים אותה על ידי צמצום הבעיה.

Enterprise automation לא תיכשל בגלל locator שביר בלבד. היא תיכשל בגלל context לא מוגבל. לכן צריך להתייחס לטוקנים, state ו-reporting כתשתית קריטית.

קוד הוא זול. טוקנים יקרים. הקשר הוא המלך.