تاريخ النشر: 22 يونيو 2026
تستخدم شركة P2ER، وهي وكالة متخصّصة في الحلول الرقمية، أدوات مطوّري البرامج في Chrome للوكلاء للتأكّد من أنّ البرامج التي تم التحقّق منها والتي تعمل بشكل صحيح فقط هي التي يتم إرسالها إلى المراجعين لإجراء المراجعة النهائية. ومن خلال تحويل سير العمل إلى بنية أساسية قائمة على الوكلاء، تمكّنوا من منح وكلاء الذكاء الاصطناعي القدرة على إجراء عمليات التحقّق التجريبية من واجهة المستخدم، ما أدّى إلى زيادة معدّل النشر من مرة واحدة في الأسبوع إلى عدة مرات في اليوم.
التحدي: تحسين الجودة في التطبيقات الحالية
تقدّم P2ER تجارب رقمية متطوّرة للعلامات التجارية العالمية، بما في ذلك شركات تصنيع السيارات والعلامات التجارية للساعات وشركات الضيافة. كان التحدي الأساسي الذي واجهته، كما هو الحال مع العديد من الشركات، هو العمل ضمن تطبيقات معقّدة حالية. واجه الفريق الذي اعتمد الترميز المستند إلى الوكلاء ثلاث عقبات رئيسية:
- اختبار واجهة المستخدم الهشّة: واجهت مجموعات الاختبار العادية صعوبة في التعامل مع البيانات الديناميكية، مثل الأسعار المتقلّبة للفنادق أو العروض الموسمية في بعض مشاريع P2ER. غالبًا ما كانت البيانات الوهمية تخفي عيوب الدمج التي كان بإمكان المختبِر البشري رصدها على الفور.
- مشاكل في موثوقية الوكيل: بدون تعليمات واضحة، ادّعت وكالات الذكاء الاصطناعي في بعض الأحيان أنّها أكملت مهمة بدون التحقّق منها فعليًا.
- فقدان السياق: تسبّبت المهام الواسعة النطاق ومهلات النماذج في فقدان البرامج الوكيلة لتتبُّع أهداف الجلسة، ما صعّب على المطوّرين تتبُّع العمل الذي بدأه البرنامج الوكيل ومواصلته.
الحل: إنشاء بنية تحتية للحرفية
أنشأت P2ER بنية تحتية تتعامل مع الذكاء الاصطناعي على أنّه "شريك تدريب" يمكنه أيضًا التعامل مع الجوانب المتكررة في عملية التطوير. يتيح هذا النهج للفريق توسيع نطاق الحرفية من خلال التركيز على التصميم المعماري وحلّ المشاكل بطرق إبداعية.
فرض التحقّق التجريبي باستخدام "أدوات مطوّري البرامج" لخادم 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. - عمليات التحقّق من سهولة الاستخدام: يرصد العملاء الترجمات غير المتوفّرة أو أخطاء سهولة الاستخدام التي غالبًا ما تتجاهلها النصوص البرمجية المبرمَجة. من خلال التفاعل مباشرةً مع شجرة تسهيل الاستخدام ومراجعة اللقطات المرئية التي يتم استردادها من خلال
take_snapshotوtake_screenshot، تبحث البرامج بشكل نشط عن أي مشاكل في واجهة المستخدم، مثل سلاسل MISSING_MESSAGE، وذلك وفقًا للتعليمات الصريحة الواردة في مهام سير عمل التحقّق الآلي.
تقسيم المهام الفرعية وحفظها
لمنع انتهاء مهلة الجلسة وفقدان السياق، تقسّم أداة 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 مرّات: يتم الآن إغلاق معظم المشاكل خلال يوم واحد، مقارنةً بالمتوسط السابق الذي كان يتراوح بين يوم واحد و3 أيام. ارتفعت وتيرة النشر من مرّة واحدة في الأسبوع إلى عدّة مرات في اليوم.
- التركيز الاستراتيجي لفِرق ضمان الجودة: بما أنّ البرامج الآلية ترصد الآن حالات التراجع الأساسية و "الفرص السهلة"، يمكن لفريق الاختبار البشري التركيز على سيناريوهات اختبار أكثر تعمّقًا وتعقيدًا.
- عمليات تنفيذ قوية لأصحاب المصلحة: أصبحت عمليات التنفيذ أكثر مرونة لأنّ الاختبار يتجاوز "المسار السعيد" المعتاد للمبرمج.
- تواصل وتتبُّع أوضح: من خلال فرض قاعدة "مشكلة من المستخدم إلى مشكلة فرعية متعلقة بالتنفيذ"، يتلقّى أصحاب المصلحة تعليمات واضحة بشأن التحسينات المنطقية التي تم إجراؤها بدلاً من قراءة التذاكر المليئة بتفاصيل التنفيذ الفني وكيفية اختبارها.
كمثال على كيفية تأثير ذلك في سرعة التطوير، أنشأت شركة P2ER منصة جديدة في ستة أشهر، وهو إنجاز كان سيستغرق سنوات عديدة باستخدام طرقها المعتادة. يبقى الإنسان هو المسؤول عن مراجعة الجودة النهائية، إذ يراجع طلبات الدمج التي سبق أن تحقّق منها الوكلاء.
إحصاءات فنية للفِرق
أثناء إنشاء سير العمل هذا، حدّدت P2ER العديد من الاستراتيجيات التي ساعدتها في الانتقال من مرحلة التجربة إلى نموذج تطوير ناضج بمساعدة وكيل.
يمكن أن تساعد هذه الاستراتيجيات الفِرق الأخرى في تحسين عمليات التنفيذ المستندة إلى الوكلاء:
تحسين استخدام الرموز المميزة من خلال إدخال النصوص البرمجية وتجميعها في دفعات باستخدام واجهة سطر الأوامر
يمكن أن تصبح خوادم MCP كثيفة الاستخدام للرموز المميزة خلال جلسات التطوير الطويلة إذا اعتمد العملاء بشكل كامل على التنقّل خطوة بخطوة (على سبيل المثال، التقاط لقطة شاشة، والعثور على معرّف، وملء حقل إدخال، والانتظار). لتقليل هذا الحمل الزائد، تستخدم P2ER أسلوبًا ذا شقّين:
- إدخال النصوص البرمجية المضمّنة: لإجراء تفاعلات مستهدَفة، مثل المصادقة من خلال نماذج React المعقّدة، يستخدم موظفو الدعم أداة
evaluate_scriptلإدخال JavaScript العادية مباشرةً في المتصفح. يؤدي ذلك إلى تجاوز عمليات إلغاء الإعدادات المضمّنة وتنفيذ عدة إجراءات في آنٍ واحد، ما يوفّر العديد من الأدوار الحوارية. - تجميع النصوص البرمجية في واجهة سطر الأوامر: عندما يواجه العملاء "مشكلة" أو يواجهون تسلسلاً طويلاً ومتكررًا في المتصفح، ينتقلون إلى خيار احتياطي لتجميع النصوص البرمجية في واجهة سطر الأوامر. بدلاً من إنفاق الرموز المميزة على أدوات MCP الفردية المتكررة أو كتابة نصوص برمجية مخصّصة للأتمتة من البداية، يطلب P2ER من واجهة سطر الأوامر في "أدوات مطوّري البرامج في Chrome" الاحتفاظ بإجراءات المتصفّح وتجميعها. يتيح ذلك للوكلاء تنفيذ مهام سير العمل المتعدّدة الخطوات بالكامل بشكل آلي دفعة واحدة، ما يقلّل بشكل كبير من الوقت المستغرق في التواصل المستمر بين النموذج والأداة.
أتمِتة عملية تتبُّع الأداء باستخدام "تحليل عمليات التتبُّع"
بدلاً من الاعتماد على الإدراك البشري فقط، أنشأ فريق P2ER
review-performance مهارة تستخدم "أدوات مطوّري البرامج" للسماح للوكلاء بإجراء عمليات تدقيق مبرمَجة في Lighthouse
وتتبُّع الأداء.
يستخدم العملاء الأداة performance_start_trace وperformance_analyze_insight
لتسجيل Core Web Vitals (سرعة عرض أكبر محتوى مرئي، ومدى استجابة الصفحة لتفاعلات المستخدم، ومتغيّرات التصميم التراكمية) والتحقيق فيها، وتحديد المشاكل التي تؤثر في أداء سلسلة التعليمات الرئيسية أو تغييرات التصميم. لإكمال بوابة الجودة، يمكن للموظفين إجراء lighthouse_audit كاملة للحماية تحديدًا من حالات التراجع في إمكانية الوصول (a11y) وتحسين محركات البحث وأفضل الممارسات العامة على الويب، ما يضمن إرسال رمز عالي الجودة فقط لطلب الدمج.
تحسين عملية التحقّق باستخدام "أدوات مطوّري البرامج في Chrome" للوكلاء
بالإضافة إلى المهارات المخصّصة، تستخدم أداة P2ER الإمكانات الأساسية لخادم MCP الخاص بـ "أدوات مطوّري البرامج في Chrome" للوكلاء من أجل إجراء عملية التحقّق الوظيفي. ويشمل ذلك استخدام الخادم لمحاكاة الأجهزة المختلفة واختبار مدى استجابتها، والتأكّد من أنّ واجهة المستخدم تعمل على أحجام الشاشات والأجهزة المختلفة.
باستخدام خادم MCP للتنقّل في التطبيق، يمكن للوكلاء تحديد التناقضات المرئية بين التصاميم والتنفيذ الفعلي، وتحديد الأخطاء التي غالبًا ما تتجاهلها الاختبارات الثابتة.
الموارد
لاستكشاف حالة استخدام P2ER بشكل أكبر، يمكنك الاطّلاع على جميع المهارات المذكورة في مستودع GitHub ذي الصلة.
للبدء بنفسك والتعرّف على المزيد حول تنفيذ سير عمل مشابه باستخدام "أدوات مطوري البرامج للوكلاء"، يمكنك استكشاف المراجع التالية: