الاختبار الوكيل (Agentic Testing) في عام 2026: ماذا تظهر بيانات 200 تشغيل من Slack

في سطر واحد: الاختبارات الوكيلية (Agentic testing) توجه وكيل ذكاء اصطناعي نحو هدف معين — مثل "الرد في سلسلة رسائل والتحقق من ظهور الرد" — وتتركه يقود واجهة المستخدم للوصول إلى هناك، بدلاً من إعادة تشغيل سيناريو ثابت؛ قام الفريق الهندسي في Slack بتشغيل أكثر من 200 اختبار من هذا النوع ونشر التكلفة الفعلية ومعدلات الفشل.¹

ملخص: في تقرير هندسي بتاريخ 11 يونيو 2026، والذي حظي بتغطية واسعة من الصحافة التقنية للمطورين حتى يوليو، أفادت Slack بتشغيل أكثر من 200 سير عمل لاختبارات شاملة (E2E) مدفوعة بالوكلاء عبر ثلاثة نماذج تنفيذ ومسارين للمستخدمين.¹² العنوان الرئيسي هنا ليس "الوكلاء يحلون محل ضمان الجودة (QA)"، بل هو مجموعة من المقايضات الصعبة: تكلفة التشغيل المدفوع بالوكلاء تتراوح تقريباً بين 15-30 دولاراً لكل اختبار وتستغرق من 3-11 دقائق، وتتأرجح الموثوقية من شبه مثالية إلى معدل فشل يصل إلى ~48% اعتماداً على كيفية إعداد الوكيل، وأكبر محرك للتكلفة ليس تفكير النموذج بل سياق المحادثة الذي يتم إعادة إرساله في كل خطوة.¹ استنتاج Slack كان متزناً — الاختبارات الوكيلية تكتسب مكانة جديدة في قمة هرم الاختبارات للاستكشاف وتصحيح الأخطاء، وليست بديلاً عن الاختبارات الحتمية التي تحمي التكامل المستمر (CI).¹ ويشير مقياس منفصل من Stripe من شهر مارس إلى نفس العقبة من زاوية مختلفة: الوكلاء يقومون بالتوليد والتنفيذ بشكل جيد، ولكن التحقق من عملهم الخاص هو النقطة التي لا يزالون يخفقون فيها.³

ما ستتعلمه

• ما هي الاختبارات الوكيلية، وكيف يختلف "التحقق من الهدف" عن "إعادة تشغيل الرحلة"
• كيف قامت Slack بهيكلة تجربتها التي شملت أكثر من 200 تشغيل، وما هي النماذج والأدوات التي استخدمتها
• ماذا تظهر أرقام الموثوقية عبر Playwright MCP و Playwright CLI والاختبارات المولدة
• لماذا تكلف عملية تشغيل اختبار مدفوع بالوكيل من 15-30 دولاراً، وأين تذهب هذه الأموال فعلياً
• مقايضة القابلية للتكيف: تشغيل واحد فقط من بين كل خمسة تقريباً يسلك نفس المسار
• أين تقع الاختبارات الوكيلية في هرم الاختبارات — وأين لا تقع
• النمط الأكبر لعام 2026: وكلاء يبنون بشكل جيد ولكن يتحققون بشكل سيئ
• ماذا تفعل إذا كنت تضيف الوكلاء إلى مجموعة أدوات الاختبار الخاصة بك

ما هي الاختبارات الوكيلية في الواقع

يقوم الاختبار الشامل (end-to-end) التقليدي بتشفير رحلة: انقر هنا، اكتب ذلك، تأكد من النتيجة. إنه اختبار حتمي ورخيص، ولكنه ينهار في اللحظة التي تتغير فيها واجهة المستخدم — فتغيير اسم زر أو إعادة ترتيب قائمة يؤدي إلى فشل الاختبار حتى لو لم يحدث أي تراجع وظيفي. هذه الهشاشة هي "ضريبة الصيانة" التي تدفعها كل تطبيقات الويب الكبيرة.

تستبدل الاختبارات الوكيلية الرحلة بالهدف. أنت تصف النتيجة بلغة طبيعية — "أرسل رسالة في سلسلة"، "قم بإجراء بحث وتأكد من ظهور النتيجة في جميع السلاسل" — ويقوم وكيل ذكاء اصطناعي بمراقبة الواجهة، ويقرر ما الذي يجب النقر عليه، ويتحقق مما إذا كانت حالة الهدف قد تحققت. ملخص Slack المكون من سطر واحد هو أدق تعريف متاح: "الاختبارات تفرض الرحلات. الوكلاء يتحققون من الأهداف."¹ لقد قضى سوق مزودي خدمات ضمان الجودة (QA) عام 2026 في الترويج لهذه الفكرة بقوة — حيث تنشر BrowserStack و Mabl و UiPath وعشرات الشركات الأخرى عروضاً متطابقة تقريباً حول "الاختبارات الذاتية، ذاتية الإصلاح، والتي تحل محل ضمان الجودة اليدوي" — ولكن تقريباً لا أحد منهم يوضح التكلفة أو عدد مرات النجاح. مساهمة Slack تكمن في أنها أجرت التجربة ونشرت الأرقام.

داخل تجربة Slack

قام فريق DevXP في Slack بتشغيل أكثر من 200 سير عمل agentic E2E — بواقع 20 تشغيلًا لكل منها عبر خمس تكوينات ومسارين للمستخدم — في مساحات عمل تجريبية باستخدام بيانات غير إنتاجية.¹ وقد قارن الفريق بين ثلاثة نماذج تنفيذ:

• Agent + Playwright MCP. يقوم الـ agent بتشغيل المتصفح من خلال خادم Playwright MCP مفتوح المصدر من Microsoft، والذي يعرض إجراءات المتصفح كأدوات ويعيد لقطات من شجرة إمكانية الوصول (accessibility-tree) كحالة مهيكلة.¹⁴
• Agent + Playwright CLI. يقوم الـ agent بتنفيذ أوامر Playwright CLI خطوة بخطوة، ويحدد الإجراء التالي بناءً على واجهة المستخدم المحدثة.¹
• اختبارات Playwright المولدة. يقوم الـ agent بكتابة كود Playwright حتمي من وصف بلغة طبيعية، ثم يقوم بتشغيله وتحسينه حتى ينجح — وبعد ذلك يتم تنفيذه مثل أي اختبار برمجي عادي.¹

كانت نماذج الـ agent المستخدمة هي Claude Sonnet 4.5 لتشغيلات MCP و CLI، و Claude Opus 4.6 لتوليد الاختبارات الحتمية، وتم تنفيذ الجميع من خلال Claude Code غير التفاعلي (claude -p)، مع تجربة جانبية لاستهلاك الـ tokens شملت أيضًا Claude Haiku 4.5.¹ كان المساران عبارة عن "رد على سلسلة رسائل" (Thread Reply) بسيط (حوالي 15-20 خطوة) و "اكتشاف البحث" (Search Discovery) متوسط التعقيد (حوالي 25-30 خطوة)، وتم تزويد الـ agent بكل منهما في شكل لغة طبيعية حرة و YAML مهيكل.¹ هذه هي خيارات النماذج والأدوات الدقيقة التي استخدمتها Slack في منتصف عام 2026؛ والنقطة الجوهرية هي شكل النتائج، والتي من غير المرجح أن تتغير مع استخدام نموذج أحدث.

ما تظهره بيانات الموثوقية

قصة الموثوقية هي في الواقع قصة عن كيفية ربط الـ agent، وليس عن النموذج الذي يعمل خلفه. أرقام ملخص Slack:

هناك نمطان بارزان. أولاً، فجوة الموثوقية تتسع مع زيادة التعقيد، ويظل الـ agent المعتمد على MCP هو الأكثر استقرارًا معما تصبح المسارات أصعب — حيث كانت الإخفاقات تقترب من الصفر في المسار البسيط وضمن نطاق 0-12% في المسار المعقد.¹ تعزو Slack ذلك إلى معالجة الحالة: حيث يحافظ MCP على رؤية حية ومستقرة للتطبيق ويبدو أنه يعيد استخدام التفاعلات الناجحة من مراحل سابقة في نفس التشغيل، بينما يقوم CLI بإعادة بناء الحالة من اللقطات في كل خطوة، مما يسمح بتراكم أخطاء التوقيت والتفسير الصغيرة.¹ ومن الملاحظ أن معظم إخفاقات CLI جاءت من المصادقة، وتوقيت التنقل، وعدم استقرار الجلسة — أي طبقة التنفيذ — وليس بسبب خطأ في استنتاج النموذج.¹

ثانياً، الاختبارات التي يتم إنشاؤها تلقائياً هي فخ في التدفقات المعقدة. لقد بدت جيدة في التدفق البسيط (نسبة فشل ~8%) ولكنها فشلت بنسبة 48% تقريباً في التدفق المتوسط، وعادة ما يحدث ذلك بعد التقدم عبر 70-80% من التدفق قبل أن تتعطل عند التفاعل النهائي أو التأكيد.¹ وبما أنها أُنشئت من لغة طبيعية محددة بشكل فضفاض مع إعادة استخدام تجريدات page-object الموجودة، فقد تعثرت بالضبط في استهداف العناصر الدقيق الذي يتطلبه التدفق الأطول. الدرس هنا ليس أن الإنشاء التلقائي سيء — بل أن "جعل العميل البرمجي (agent) يكتب سكريبت لمرة واحدة" و"جعل العميل البرمجي يقود المتصفح مباشرة في كل مرة" هما أداتان مختلفتان بمساحات فشل مختلفة.

لماذا تكلف عملية التشغيل الموجهة بواسطة العميل البرمجي 15-30 دولاراً

الرقم الذي يجعل المهندسين يشعرون بالقلق هو التكلفة. تقدر Slack عمليات التشغيل الموجهة بواسطة العميل البرمجي بنحو 15-30 دولاراً لكل عملية تنفيذ، مقابل سنتات قليلة للاختبار التقليدي المعتمد على السكريبت.¹ التفسير الغريزي — "نموذج كبير، لذا فهو مكلف" — خاطئ، وتحليل Slack لمكان ذهاب الأموال هو الجزء الأكثر فائدة في التقرير.

عند قياس نفس تدفق Search Discovery، تراوح استخدام الـ tokens من حوالي 3.5 مليون token (باستخدام MCP مع Sonnet 4.5) إلى حوالي 7 ملايين (الاختبارات المنشأة تلقائياً مع Opus 4.6)، بينما كان نهج CLI حوالي 6 ملايين، ومن المثير للاهتمام أن Haiku استهلك مزيداً من الـ tokens (~5.7 مليون) مقارنة بالنماذج الأكبر على MCP.¹ طريقة تنفيذ العميل البرمجي كانت أهم من النموذج الذي يشغله. السبب هو عدد الأدوار (turn count): بلغ متوسط CLI حوالي 85 دوراً لإكمال التدفق، مقابل 40-60 دوراً تقريباً لـ MCP، لأن كل تفاعل مع المتصفح كان مقسماً عبر أوامر منفصلة للعمل (action)، والانتظار (wait)، وأخذ لقطة (snapshot)، والقراءة (read)، والبحث (lookup)، بينما دمج MCP التفاعل وإرجاع الحالة في رحلة ذهاب وإياب واحدة.¹

وكل دور مكلف لأن API الأساسي عديم الحالة (stateless). وكما توضح Slack، يقوم Claude Code بإعادة إرسال موجه النظام (system prompt) الكامل بالإضافة إلى تاريخ المحادثة بالكامل في كل دور، لذا فإن التكلفة تعتمد على سرعة تراكم السياق وعدد الأدوار التي تستغرقها العملية — وليس على مخرجات النموذج، والتي تعتبر ضئيلة.¹ الجزء الأكبر من الحمولة هو لقطات شجرة إمكانية الوصول للمتصفح (browser accessibility-tree snapshots) التي تتراكم في نافذة السياق دوراً بعد دور؛ ومعظم الإنفاق، حسب تحليل Slack، هو ببساطة إعادة إرسال محتوى رآه النموذج بالفعل. إذا كنت قد تابعت تكلفة الـ token لمهمة واحدة للعميل البرمجي، فهذا هو نفس الحساب، ولكن يتم قياسه مقابل متصفح بدلاً من chatbot: الأدوات التي ذكرتها Slack لخفض التكلفة — تخزين الموجهات مؤقتاً (prompt caching)، وضغط السياق (context compaction)، وتقليل تكرار اللقطات — كلها تتعلق بتقليص ما يتم إعادة إرساله، وليس باختيار نموذج أرخص. وهو أيضاً تذكير بأن نموذج الطلب عديم الحالة خلف بروتوكولات أدوات العميل البرمجي مثل MCP له تأثير مباشر على فاتورتك.

مقايضة القدرة على التكيف

إليك الخاصية التي تجعل الاختبارات الموجهة بالعملاء البرمجية مختلفة حقاً، ومربكة حقاً: إنها غير حتمية (non-deterministic) بحكم التصميم. عبر عمليات تشغيل Slack، اتبع حوالي 20% فقط نفس تسلسل الإجراءات بالضبط؛ وفي معظم العمليات وجد العميل البرمجي مساراً صالحاً مختلفاً للوصول إلى نفس الهدف — فتح القوائم بترتيب مختلف، اختيار عناصر مختلفة، أو استخدام تنقل بديل.¹ قامت Slack بقياس ذلك من خلال مقارنة "توقيعات الإجراءات" (action signatures) الموحدة، مع استبعاد فترات الانتظار وبدائل الأدوات المتكافئة بحيث يتم احتساب الاختلافات الجوهرية فقط.¹

هذه المرونة هي الهدف الأساسي — فهي السبب في أن العميل (agent) ينجو من تغيير في واجهة المستخدم (UI) قد يؤدي إلى تعطل اختبار برمجي (scripted test). ولكن هذا هو أيضاً السبب الذي يمنعك من وضع الاختبارات القائمة على العملاء في بوابة CI بنفس الطريقة التي تضع بها اختبار وحدة (unit test). إن الفحص الذي يتخذ مساراً مختلفاً في كل مرة، ويكلف ما بين 15 إلى 30 دولاراً، ويفشل بنسبة ~12% في تدفق متوسط، لا يمكن أن يكون بوابة لمنع التراجع (regression gate). إنه شيء آخر تماماً.

أين يقع الاختبار القائم على العملاء

إجابة Slack كانت واقعية وبعيدة عن المبالغات: الاختبار القائم على العملاء هو طبقة رابعة جديدة فوق هرم الاختبارات الكلاسيكي — الوحدة (unit)، التكامل (integration)، الطرفين (E2E)، والآن القائم على العملاء (agentic) — وليس بديلاً عن أي شيء تحته.¹ تظل الاختبارات الحتمية (Deterministic tests)، سواء كانت مكتوبة يدوياً أو تم إنشاؤها بواسطة عميل، هي الأساس السريع والرخيص والقابل للتكرار لـ CI. أما طبقة العملاء فهي المكان الذي ترسل إليه عميلاً للقيام بالأشياء التي تفشل فيها البرمجيات: استكشاف سلوك واجهة المستخدم المعقد أو غير المألوف، وتصحيح أخطاء سير العمل غير المستقرة (flaky workflows)، وإعادة إنتاج أخطاء البيئة الفعلية (production bugs) التي لا يمكنك تحديد خطوات إعادة إنتاجها بالكامل مسبقاً.¹ وتوضح Slack صراحةً أنه، بالأسعار الحالية، فإن الاختبارات التي يقودها العملاء تناسب "تصحيح الأخطاء المستهدف أو الاختبار الاستكشافي" بشكل أفضل بكثير من "تنفيذ CI عالي التردد".¹

هذا الإطار هو الرد المباشر على عروض الموردين. الاختبار القائم على العملاء في عام 2026 ليس ضمان جودة (QA) ذاتياً يتسبب في طرد مهندسي الاختبارات لديك؛ بل هو أداة قوية للحالات الغامضة، مسعرة وفقاً لذلك، وتكمل الاختبارات الحتمية التي تقوم بتشغيلها بالفعل.

النمط الأكبر لعام 2026

إذا نظرنا للصورة الأشمل، سنجد أن تجربة Slack تتشابه مع القطعة الجادة الأخرى من بيانات الهندسة القائمة على العملاء هذا العام. في معيار قياسي بتاريخ 2 مارس 2026 تم فتحه لاحقاً كمصدر مفتوح، قامت Stripe ببناء 11 بيئة واقعية للإنتاج وجعلت العملاء يحاولون إجراء عمليات تكامل كاملة مع Stripe من خلال نظام يعتمد على goose وخادم MCP.³⁵ كانت النماذج قوية: حقق Claude Opus 4.5 متوسط 92% في مهام تكامل API كاملة المكدس (full-stack)، وحقق GPT-5.2 من OpenAI متوسط 73% في مجموعات مشكلات "النادي الرياضي" (gym) الأكثر صعوبة في Stripe، مع استمرار أفضل التشغيلات في تحقيق متوسط 63 دورة من العمل المنتج.³ رفضت Stripe نشر درجة إجمالية واحدة، ولسبب كاشف — وهو أن الإخفاقات لم تتركز في كتابة الكود بل في التحقق من صحته.³

أكثر أنماط الفشل تعليمية في Stripe: في مهام تحديث SDK، قامت بعض العملاء بتغذية نقطة نهاية (endpoint) ببيانات غير موجودة، ورأت خطأ HTTP 400 المتوقع، واستنتجت أن التكامل يعمل — "نقطة النهاية تعمل، إنها تعيد خطأ Stripe صحيحاً" — بينما في الواقع لم يتحققوا من أي شيء.³ وآخرون تسببوا في وصول صفحة الدفع في المتصفح إلى حالة تركيز خاطئة واستسلموا في مهمة كان من الممكن استعادتها بمجرد تحديث الصفحة.³ رأت Slack الصورة المعاكسة: عملاء لم يتمكنوا دائماً من التعافي من خلل في المتصفح، وملف تعريف للموثوقية/التكلفة يضع قيوداً على الاستخدام في بيئة الإنتاج.

اقرأ هذه النقاط معاً — وهذا هو تحليل الكاتب بناءً على دراستين مستقلتين، وليس ادعاءً مشتركاً من كلا الشركتين — ستجد أن صورة عام 2026 متسقة: العملاء الذكيون (agents) يقومون بالتوليد والتنفيذ بثقة، لكن التحقق الذاتي وفق معيار دقة حقيقي هو العقبة. هذه هي نفس الفجوة التي تظهر في أماكن أخرى حيث يقوم العملاء بشحن الكود بشكل أسرع مما تستطيع الفرق إدارته، وهو توتر غطيناه في فجوة حوكمة برمجة الذكاء الاصطناعي، وهذا هو السبب في أن تتبع وتقييم عمليات تشغيل العملاء أصبح بنفس أهمية العميل نفسه.

ماذا يعني هذا إذا كنت تضيف العملاء إلى حزمة الاختبارات الخاصة بك

هناك بعض الاستنتاجات العملية التي تظهر من البيانات. فضل استخدام أداة متصفح مهيكلة (خادم بنمط MCP) على استخدام CLI إذا كانت الموثوقية تهمك — فأفضل نتائج Slack جاءت من التكامل الأكثر إحكاماً، وأسوأ حالات عدم الاستقرار جاءت من طبقة التنفيذ، وليس من النموذج.¹ كن واقعياً في الميزانية: بتكلفة تتراوح بين 15-30 دولاراً وعدة دقائق لكل عملية تشغيل، يجب أن تخصص الاختبارات القائمة على العملاء للسيناريوهات عالية القيمة والصعبة في كتابة السكربتات، وليس لكل طلب سحب (pull request). راقب عدد الأدوار (turn count) ونمو السياق، وليس اختيار النموذج، كأداة أساسية للتحكم في التكلفة، والجا إلى تخزين المطالبات مؤقتاً (prompt caching) وضغط السياق قبل أن تلجأ إلى نموذج أصغر. وحافظ على مجموعة الاختبارات الحتمية (deterministic suite) الخاصة بك — فالهدف من طبقة العملاء هو الوصول إلى الحالات التي لا تستطيع تلك المجموعة الوصول إليها، بما في ذلك توليد اختبارات مسكربتة جديدة يمكنك تشغيلها لاحقاً بتكلفة زهيدة للأبد. وكما هو الحال عند تحديد عدد الأدوات التي يمكن للعميل التعامل معها واقعياً، فإن الفوز في عام 2026 يأتي من ربط العميل بشكل جيد، وليس من انتظار نموذج أفضل.