תאריך פרסום: 22 ביוני 2026
P2ER, סוכנות לפתרונות דיגיטליים, משתמשת בכלי הפיתוח ל-Chrome לסוכנים כדי לוודא שרק תוכנות מאומתות ותקינות מועברות לבדיקה סופית על ידי בני אדם. הם שינו את תהליך העבודה שלהם לתשתית אקטיבית, וכך אפשרו לסוכני AI לבצע אימות אמפירי של ממשק המשתמש. כתוצאה מכך, הם הגדילו את תדירות הפריסה מפעם בשבוע לכמה פעמים ביום.
האתגר: שיפור האיכות באפליקציות קיימות
חברת P2ER מספקת חוויות דיגיטליות מתקדמות למותגים גלובליים, כולל יצרני רכב, מותגי שעונים וחברות אירוח. האתגר העיקרי שלהם, כמו של חברות רבות, היה לעבוד עם אפליקציות מורכבות קיימות. הצוות שאימץ את השימוש בסוכני קוד נתקל בשלושה אתגרים עיקריים:
- בדיקות ממשק משתמש שבירות. חבילות בדיקה רגילות לא הצליחו להתמודד עם נתונים דינמיים, כמו תנודות במחירי מלונות או מבצעים עונתיים בחלק מהפרויקטים של P2ER. נתוני דמה הסתירו לעיתים קרובות פגמים בשילוב, שבודק אנושי היה מוצא מיד.
- בעיות מהימנות של הסוכן. ללא הוראות מפורשות, סוכני AI טענו לפעמים שמשימה הושלמה בלי לבדוק את זה בפועל.
- איבוד ההקשר. משימות רחבות ופסק זמן של המודל גרמו לסוכנים לאבד את המעקב אחרי יעדי הסשן. כך היה קשה למפתחים לעקוב אחרי עבודה שהסוכן התחיל ולחדש אותה.
הפתרון: בניית תשתית לשיפור המיומנויות
חברת P2ER בנתה תשתית שמתייחסת ל-AI כאל "שותף לאימון" שיכול גם לטפל בהיבטים החוזרים של הפיתוח. הגישה הזו מאפשרת לצוות להרחיב את היכולות המקצועיות שלו על ידי התמקדות בארכיטקטורה ובפתרון בעיות יצירתיות.
אכיפת אימות אמפירי באמצעות כלי הפיתוח ל-Chrome עבור שרת ה-MCP של סוכנים
כדי להבטיח מהימנות, ב-P2ER נקבע כלל אימות אמפירי חובה.
ההנחיה ההנדסית הזו, שמופיעה בקובץ AGENTS.md של הפרויקט, קובעת:
All claims regarding service availability and component rendering
MUST be empirically verified (log output, dev compiler, browser/devtools inspection)
before asserting to the user.
במקום להסתמך על דברי הנציג, הצוות משתמש בכלי הפיתוח ל-Chrome עבור נציגים כדי לספק לנציגים סביבה בטוחה לניווט באפליקציה באופן חזותי ואינטראקטיבי.
הסוכנים האלה מבצעים כמה משימות חשובות שלא מתבצעות בבדיקות סטטיות רגילות:
- בדיקה של נתונים דינמיים: גם בסביבת פיתוח, סוכנים בודקים נתונים אמיתיים שמשתנים (למשל, מחירי מלונות שמשתנים בהתאם לעונה) כדי לחוות את האפליקציה בדיוק כמו משתמש. ההגדרה הזו מופעלת על ידי DevTools עבור כלי אינטראקציה של סוכנים כמו
new_page,navigate_page,fill,clickו-hover, שמופיעים בכישורים שלgithub-issue-test, ומאפשרת לסוכן לבצע אימות באופן דינמי ולדמות נתיב קליקים ריאליסטי של משתמש. - ביקורות חזותיות: סוכנים מזהים אי-התאמות חזותיות בין פריסות Figma לבין ההטמעה בפועל. באמצעות הכלי
take_screenshotמ-DevTools לסוכנים, מיומנותfigma-validateשלהם מצלמת צילומי מסך ברזולוציה גבוהה של רינדורים חיים של Storybook כדי לבצע השוואה זה לצד זה עם ייצואים של Figma. - בדיקות שימושיות: נציגים מאתרים תרגומים חסרים או שגיאות שימושיות שסקריפטים אוטומטיים לרוב מפספסים. הסוכנים מבצעים סריקה פעילה של אנומליות בממשק המשתמש, כמו מחרוזות של MISSING_MESSAGE, על ידי אינטראקציה ישירה עם עץ הנגישות ובדיקה של תמונות מצב חזותיות שאוחזרו באמצעות
take_snapshotו-take_screenshot, כפי שמצוין במפורש בתהליכי העבודה האוטומטיים שלהם לאימות.
פירוק של משימות לתתי-משימות ושמירתן
כדי למנוע מצבים של פסק זמן בסשן ואובדן הקשר, P2ER מחלק את העבודה לקטעים קטנים באמצעות סוכני משנה. לאחר מכן הם מנחים את הסוכנים שלהם לפעול כמתזמנים באופן הבא:
Rather than executing everything in the main thread, you must decompose large
or complex objectives into modular subtasks that can be delegated
to specialized subagents.
כדי לעדכן את בעלי המוצרים האנושיים בתהליך הזה, הצוות שילב מיומנות מותאמת אישית לסוכנים כדי לעקוב אחרי העבודה שלהם בבעיות ב-GitHub. כך כל משימה של סוכן משנה והתוצאות שלה נשמרות ומתועדות כבעיה משנית באמצעות GitHub API, ונוצר שביל ביקורת ברור והקשר מתמשך שמפתחים אחרים יכולים להשתמש בו.
בידוד סביבות לביצוע מקביל
כדי להרחיב את תהליך הפיתוח כך שמספר סוכנים יריצו קוד במקביל, ב-P2ER נדרשות סביבות מבודדות לכל משימה של הסוכנים. כך נמנעים קונפליקטים במצב ובעיות ברשת במהלך אימות ממשק המשתמש.
ההגדרה הטכנית של הבידוד הזה כוללת:
- עצי עבודה מבודדים של Git: כדי למנוע התנגשויות בין קבצים וזיהום של סביבת העבודה כשכמה סוכנים פועלים במקביל, המשימות מבוצעות בעצי עבודה מבודדים של Git. כל סוכן מקבל מקום ייעודי במערכת הקבצים שבו משתני הסביבה מועתקים והתלויות מקושרות באמצעות קישור סמלי, כדי להבטיח ששינויים בקבצים לא יחליפו אחד את השני.
- סביבות ייחודיות: כל סוכן ומשימה מפעילים את שרת הפיתוח של Next.js ביציאה מבודדת ייחודית. לפי כללי הפרויקט שלהם, השרתים מופעלים באופן דינמי באמצעות
npx next dev -p <custom_port> --turbopackכדי להבטיח ביצוע מקביל ללא התנגשויות ברשת. - שיבוטים של מסדי נתונים: כדי למנוע התנגשויות של נתונים במהלך בדיקות מקבילות, התוכנה P2ER משכפלת באופן פרוגרמטי את מסד הנתונים הראשי לסכימה ספציפית למשימה בהפעלת הסוכן. אחרי שהסוכן מסיים את תהליך האימות והמשימה מאושרת, תהליך ניקוי אוטומטי משחרר את מסד הנתונים המבודד. מחזור החיים הזה מבטיח שכל סוכן יפעל בסביבת עבודה נקייה ולא ישאיר אחריו נתונים לא מאורגנים.
- בדיקות ממוקדות: כל הבדיקות בדפדפן באמצעות כלי הפיתוח ל-Chrome עבור סוכנים צריכות להיות ממוקדות ביציאה המותאמת אישית המדויקת שהוקצתה למופע הסוכן הספציפי הזה.
ההנחיה שלהם לבדיקות אוסרת על קידוד קשיח של יציאות ברירת מחדל, ולכן נדרשות כתובות URL של יעדי בדיקה כמו
http://localhost:<custom_port>.
ההשפעה: קצב התקדמות הפיתוח גדל פי 10, תוך שמירה על האיכות
המעבר לקידוד מבוסס-סוכן עם אמצעי בקרה מהימנים שינה את הפלט של P2ER. השינויים האלה היו נחוצים במקור כדי להבטיח שהסוכן יפעל בצורה מהימנה, אבל הם גם הועילו לכל מחזור החיים של הפיתוח:
- מחזורי עבודה מהירים פי 10: רוב הבעיות נסגרות עכשיו ביום אחד, לעומת ממוצע של יום עד שלושה ימים בעבר. תדירות הפריסה עלתה מפריסה אחת בשבוע לכמה פעמים ביום.
- התמקדות אסטרטגית לצוותי QA: עכשיו שהנציגים יכולים לזהות רגרסיות בסיסיות ובעיות פשוטות, צוות הבדיקות האנושי יכול להתמקד בתרחישי בדיקה מורכבים ומעמיקים יותר.
- יישומים חזקים יותר לבעלי עניין: היישומים עמידים יותר כי הבדיקות לא מוגבלות לתרחיש הרגיל של המתכנת.
- תקשורת ברורה יותר ומעקב: על ידי אכיפת הכלל 'בעיה אנושית לבעיית משנה של הטמעה', בעלי העניין מקבלים הוראות ברורות לגבי השיפורים הלוגיים שבוצעו במקום לקרוא כרטיסים שמלאים בפרטים טכניים על ההטמעה ואיך לבדוק אותם.
כדוגמה להשפעה על מהירות הפיתוח, חברת P2ER בנתה פלטפורמה חדשה בשישה חודשים, כשבשיטות המקובלות שלה היה לוקח לה שנים רבות. הגורם האנושי הוא עדיין השלב האחרון בבקרת האיכות, והוא בודק בקשות למשיכת שינויים שכבר אומתו על ידי סוכנים.
תובנות טכניות לצוותים
במהלך בניית תהליך העבודה הזה, חברת P2ER זיהתה כמה אסטרטגיות שעזרו לה לעבור משלב הניסויים למודל פיתוח בוגר שמתבסס על סיוע של סוכנים.
האסטרטגיות האלה יכולות לעזור לצוותים אחרים לשפר את ההטמעות שלהם של סוכנים דיגיטליים:
אופטימיזציה של השימוש באסימונים באמצעות הזרקת סקריפטים ועיבוד אצווה ב-CLI
שרתי MCP יכולים להפוך לשרתים עתירי טוקנים במהלך הפעלות פיתוח ארוכות אם הסוכנים מסתמכים רק על ניווט שלב אחר שלב (לדוגמה, צילום תמונה, חיפוש מזהה, מילוי קלט והמתנה). כדי לצמצם את התקורה הזו, P2ER משתמש בגישה דו-כיוונית:
- החדרת סקריפט מוטבע: כדי לבצע אינטראקציות ממוקדות, כמו אימות באמצעות טפסים מורכבים של React, הסוכנים משתמשים בכלי
evaluate_scriptכדי להחדיר JavaScript רגיל ישירות לדפדפן. כך אפשר לעקוף את ההגדרות המובנות של שינוי ערכים ולהריץ כמה פעולות בו-זמנית, ולחסוך הרבה תפניות בשיחה. - הוספת סקריפטים ל-CLI: אם סוכנים נתקלים בבעיה או בתהליך ארוך במיוחד בדפדפן שחוזר על עצמו, הם עוברים לגיבוי של הוספת סקריפטים ל-CLI. במקום לבזבז טוקנים על כלים חוזרים ונפרדים של MCP או לכתוב סקריפטים מותאמים אישית לאוטומציה מאפס, P2ER מנחה את ה-CLI של כלי הפיתוח ל-Chrome לשמור ולאגד פעולות בדפדפן. כך הסוכנים יכולים להריץ באופן אוטומטי תהליכי עבודה שלמים ומרובי-שלבים בפעם אחת, ולצמצם באופן משמעותי את התקורה של תקשורת קבועה בין המודל לכלי.
אוטומציה של מעקב אחרי ביצועים באמצעות ניתוח מעקב
במקום להסתמך רק על תפיסה אנושית, P2ER יצר review-performanceמיומנות שמשתמשת בכלי הפיתוח לסוכנים כדי להריץ ביקורות אוטומטיות של Lighthouse ומעקב אחר ביצועים.
הסוכנים משתמשים בכלי performance_start_trace ו-performance_analyze_insight כדי לתעד ולחקור את מדדי ה-Core Web Vitals (LCP, INP ו-CLS) ולזהות צווארי בקבוק בשרשור הראשי או שינויים בפריסה. כדי להשלים את תהליך בקרת האיכות, סוכנים יכולים להריץ lighthouse_audit מלא כדי להגן באופן ספציפי מפני רגרסיות בנגישות (a11y), ב-SEO ובשיטות מומלצות כלליות באינטרנט, וכך לוודא שרק קוד באיכות גבוהה נשלח לבקשת משיכה.
שיפור האימות באמצעות כלי הפיתוח ל-Chrome לסוכנים
בנוסף ליכולות המותאמות אישית שלהם, P2ER משתמש ביכולות הליבה של שרת ה-MCP של כלי הפיתוח ל-Chrome כדי לבצע אימות פונקציונלי. הבדיקה כוללת שימוש בשרת כדי לדמות מכשירים שונים ולבדוק את ההיענות, כדי לוודא שממשק המשתמש פועל בגדלים שונים של מסכים ובמכשירים שונים.
באמצעות שרת ה-MCP כדי לנווט באפליקציה, נציגים יכולים לזהות אי-התאמות חזותיות בין פריסות לבין ההטמעה בפועל, ולזהות שגיאות שבדיקות סטטיות לרוב לא מזהות.
משאבים
כדי להכיר עוד תרחישי שימוש ב-P2ER, אפשר לעיין בכל הכישורים שמוזכרים במאגר GitHub שקשור ל-P2ER.
כדי להתחיל בעצמכם ולקבל מידע נוסף על הטמעה של תהליכי עבודה דומים באמצעות כלי הפיתוח לסוכנים, אפשר לעיין במקורות המידע הבאים: