عمليات التقييم لـ WebMCP

Kasper Kulikowski

Published: May 19, 2026, Last updated: May 28, 2026

Explainer	الويب	الإضافات	Chrome Status	النيّة بالشراء
GitHub	مرحلة التجربة والتقييم		العرض	النيّة في إجراء تجربة

تتوفّر في WebMCP إمكانية استخدام وكلاء يستخدِمون نماذج الذكاء الاصطناعي التوليدي. لاختبار أي نظام يستخدِم الذكاء الاصطناعي التوليدي، يجب أن تتيح اختباراتك نتائج احتمالية: يمكن أن يؤدي إدخال واحد إلى آلاف الإجابات بدرجات متفاوتة من الدقة. تُعرف تقنية الاختبار هذه باسم عمليات التقييم أو التقييمات.

قبل طرح الأدوات في مرحلة الإنتاج، عليك التأكّد من أنّ الوكلاء يفهمون متى يجب استدعاء الأداة وكيفية تنفيذها والإجابات المقبولة. عليك معالجة فرص حدوث الإخفاق قبل وقوعها.

اكتب عمليات تقييم لاختبار نقاط الاتصال في نظامك مع نموذج لغوي كبير (LLM):

• تأكَّد من أنّ النموذج يفهم الغرض من أداتك، استنادًا إلى وصفها ومخططها.
• تأكَّد من أنّ النموذج يختار الأداة المناسبة مع المَعلمات الصحيحة لدعم نيّة المستخدم.
• تأكَّد من أنّ النموذج يتخذ إجراءً استنادًا إلى المعلومات التي تلقّاها، مثلاً لاستخدام المعلومات لاستدعاء أداة أخرى.
• تأكَّد من نجاح رحلات المستخدم. بالنظر إلى نيّة المستخدم، هل يمكن للوكيل إكمال رحلة المستخدم بنجاح على موقعي الإلكتروني باستخدام الأدوات المتاحة؟

عليك مواصلة كتابة اختبارات حتمية كلاسيكية لأي تفاعل مع النظام لا يتواصل مع النموذج.

أوضاع الإخفاق

على المطوّرين اختبار أنظمتهم لمنع حدوث الإخفاقات قبل وقوعها. لإجراء ذلك، عليك فهم الحالات التي قد يفشل فيها النظام، سواء بمفرده أو عند التفاعل مع عوامل خارجية. بالنسبة إلى WebMCP، قد تفشل الأداة نفسها وقد يفشل الوكلاء في استخدام الأدوات على النحو المتوقّع.

قد تفشل أدوات WebMCP وقد يفشل الوكيل في استخدام أدوات WebMCP. على سبيل المثال، لنفترض أنّ المستخدم يريد إضافة قميص إلى سلّته.

تعذّر إتمام العملية	مثال	تحديد المشاكل وحلّها
يفشل الوكيل في اختيار الأداة الصحيحة أو يستدعي الأداة الخاطئة مباشرةً.	يتخطّى الوكيل addToCart وينتقل مباشرةً إلى checkout.	هل description الأداة واضح وكامل ويعكس بدقة ما تفعله الأداة؟ هل functionName بديهي ووصفي؟ هل يتم عرض الأداة بشكلٍ صحيح للنموذج اللغوي الكبير في الحالة/السياق الحاليَين؟ هل يمكن أن يكون مخطط هذه الأداة مشابهًا جدًا لأداة أخرى، ما يؤدي إلى غموض في الاستدعاء؟
يستدعي الوكيل الأدوات بترتيب خاطئ	يستدعي الوكيل checkout ثم addToCart.	هل تتداخل أوصاف الأدوات، ما يؤدي إلى إرباك النموذج اللغوي الكبير بشأن التسلسل المطلوب؟ هل يوفّر ناتج أداة سابقة السياق اللازم لاستدعاء الأداة التالية؟ هل يتم تعديل الحالة بشكلٍ صحيح وهل يتم عرض أي أدوات جديدة للنموذج اللغوي الكبير على النحو المتوقّع؟ هل لا تزال حالة الاستخدام الشاملة صحيحة إذا تم استدعاء أدوات معيّنة بترتيب مختلف؟ هل اختبرت سلسلة استدعاء الأداة المحدّدة بشكلٍ منفصل من خلال فرض الاستدعاءات السابقة للتأكّد من أنّ النموذج اللغوي الكبير يختار الخطوة التالية الصحيحة؟
يستدعي الوكيل الأداة باستخدام وسيطات غير صحيحة	يستدعي الوكيل addToCart، ولكنّه يضيف حذاء بدلاً من قميص.	هل تم تحديد inputSchema بوضوح، بما في ذلك قيم enum وdescription جيد لكل سمة؟ هل تم وضع علامة على جميع المَعلمات المطلوبة والتحقّق منها بشكلٍ صريح؟ هل يوجّه وصف الوسيطة النموذج اللغوي الكبير بشكلٍ صريح بشأن كيفية ربط بيانات أدخلها المستخدم بالبيانات المنظَّمة المتوقّعة (مثل معرّف أو تنسيق معيّن)؟

ماذا لو أراد المستخدم الاطّلاع على محتويات سلّته؟

تعذّر إتمام العملية	مثال	تحديد المشاكل وحلّها
ناتج الأداة غير صحيح أو أنّ الأداة لا تتضمّن شيئًا.	يطلب المستخدم viewCart، ولكن يعرض الوكيل التكلفة الإجمالية للسلّة بدلاً من أسماء المنتجات وأسعارها الفردية.	هل تتضمّن منطق الأداة الأساسي أخطاء (تحقَّق من خلال الاختبارات الحتمية)؟ هل تم تعديل حالة واجهة المستخدم بشكلٍ صحيح وهل تلقّى الوكيل المعلومات الصحيحة عن التأثير الجانبي؟ إذا كان النموذج اللغوي الكبير يستخدم الناتج في عمليات الاستدعاء اللاحقة، هل تم تنسيق الناتج بوضوح لكي يتمكّن النموذج اللغوي الكبير من استيعابه؟ هل الناتج مطوّل جدًا؟ هل يحتوي فقط على الحد الأدنى من المعلومات الأساسية التي يحتاجها النموذج اللغوي الكبير للإجراء التالي؟

أخيرًا، يمكن أن تفشل الأداة بأي طريقة تفشل بها JavaScript. لتحديد المشاكل وحلّها، تحقَّق مما يلي:

• هل يعالج رمز الأداة بشكلٍ صحيح جميع أخطاء وقت التشغيل والاستثناءات المحتملة؟
• هل يتم الإبلاغ عن الخطأ للوكيل والنموذج بشكلٍ سليم؟
• هل واجهات برمجة التطبيقات أو الخدمات الخارجية التي تعتمد عليها الأداة سليمة؟
• هل بنية الخطأ واضحة بما يكفي ليتمكّن النموذج من التمييز بين مشكلة مؤقتة (إعادة المحاولة) وفشل خطير؟

اختبار الأدوات بشكلٍ منفصل

إذا لم يتمكّن الوكيل من تحديد الأداة التي يجب استدعاؤها لطلب مثل "أريد بيتزا صغيرة"، فلن يتمكّن من إكمال رحلة مستخدم معقّدة.

من خلال اختبار الأدوات بشكلٍ منفصل، يمكنك تحسين المخططات والأوصاف قبل إجراء أي محاكاة للمتصفّح.

قياس دقة الاستدعاء

يمكنك الاطّلاع على العرض التوضيحي، الـ WebMCP zaMaker. عندما يطلب المستخدم "أريد بيتزا صغيرة"، يمكنك توقّع ردّ من النموذج يشير إلى نيّة إجراء استدعاء set_pizza_size باستخدام الوسيطة "size":"Small".

تحدّد الدالة expectedCall الدالة والوسيطة المتوقّعتَين. يؤكّد هذا النهج أنّ الوكيل سيختار الأداة الصحيحة لدعم نيّة المستخدم، استنادًا إلى المخطط المقدَّم.

{
  "messages": [
    {
      "role": "user",
      "content": "I'd like a small pizza."
    }
  ],
  "expectedCall": [
    {
      "functionName": "set_pizza_size",
      "arguments": { "size": "Small" }
    }
  ]
}

تُستخدم expectedCall لإجراء اختبار حتمي يستند إلى القواعد:

يمكن ربط أدوات WebMCP بدورة حياة أحد المكوّنات، ما يعني أنّه عليك اختبار ما إذا كانت حالة تطبيقك تتطابق مع ما تتوقّعه WebMCP. لإدارة ذلك، قدِّم قائمة كاملة بالأدوات ذات الصلة بالحالة التي تريد تقييمها. على سبيل المثال، يتصفّح مستخدم مع وكيله ويفتح WebMCP zaMaker.

[
...
  {
    "name": "add_topping",
    "description": "Add one or more toppings to the pizza",
    ...
  },
  {
    "name": "set_pizza_size",
    "description": "Set the pizza size directly.",
    "inputSchema": {
      "type": "object",
      "properties": {
        "size": {
          "type": "string",
          "enum": [
            "Small",
            "Medium",
            "Large",
            "Extra Large"
          ],
          "description": "The specific size name."
        },
      }
    }
  },
  {
    "name": "set_pizza_style",
    "description": "Set the style of the pizza (colors/theme)",
  ...
  },
...
]

...
 "expectedCall": [
   {
     "functionName": "set_pizza_size",
     "arguments": { "size": "Small" }
   }
 ]
...

عند الفتح، يعرض WebMCP أدوات add_topping وset_pizza_size وset_pizza_style. لاختبار أي من هذه الأدوات الفردية بدقة، عليك تضمين جميع الأدوات لإنشاء حالة محاكاة كاملة.

ملاحظة: قد يتمكّن الوكيل من الوصول إلى أدوات إضافية، ولكن أفضل ما يمكنك فعله هو تقييم الأدوات التي تقدّمها.

بعد أن تتأكّد من أنّ الوكيل يستدعي الأداة المناسبة حسب الحاجة، يمكنك اختبار ما إذا كان استدعاء الأداة يتضمّن المَعلمات الصحيحة وأنّ النتيجة هي المتوقّعة. هناك خطوتان: الاختبارات الحتمية والاختبارات الاحتمالية.

إجراء الاختبارات الحتمية

بما أنّ أدوات WebMCP يتم إنشاؤها باستخدام JavaScript أو كتعليقات توضيحية بتنسيق HTML، يمكنك كتابة اختبارات حتمية لإجراء المهام التالية:

• التحقّق من منطق الأداة
• التأكّد من استدعاء التبعيات بشكلٍ صحيح
• التأكّد من تعديل واجهة المستخدم على النحو المتوقّع، بالإضافة إلى أي آثار جانبية مقصودة أخرى
• التأكّد من أنّ المعلومات المعروضة تتطابق مع القيمة المتوقّعة
• التحقّق من صحة مَعلمات الاختبار

على سبيل المثال، إذا كانت أداتك تستخدِم دالة SearchComponent، يمكنك إجراء الاختبار من خلال تمرير نموذج أولي لـ SearchComponent. تذكَّر محاكاة البيئة التي تعمل فيها الأداة للحصول على أفضل النتائج الممكنة. هذه هي التقنية نفسها التي ستستخدمها لكتابة اختبار آخر لدمج التطبيقات.

إجراء الاختبارات الاحتمالية

إذا كنت بحاجة إلى مخرجات النموذج لاستدعاء الأدوات التالية بشكلٍ صحيح، عليك كتابة عمليات تقييم.

من الممكن أن يقدّم المستخدمون طلبات بحث مباشرةً إلى النموذج تطلب تحديدًا ما تفعله الأداة، أو طلب بحث غامضًا يشير إلى ضرورة استخدام أداة. على سبيل المثال، "أضِف البيبروني إلى البيتزا" هو طلب بحث مباشر. "أريد كل اللحوم على البيتزا" هو طلب بحث أكثر غموضًا ويتطلّب من النموذج فهم أنّه يحتاج إلى أداة `add_topping` وتحديد الإضافات التي يمكن تعريفها على أنّها لحوم.

عند إنشاء مجموعات بيانات لعمليات التقييم، عليك تضمين طلبات بحث مباشرةً تختبر تنفيذ الأداة الأساسي وطلبات بحث مفتوحة تختبر منطق النموذج في الاستنتاج واختيار الأداة.

إذا كنت تدير مقهى، يمكنك مساعدة المستخدمين الذين يطلبون من وكيلهم إعادة طلب القهوة نفسها التي طلبوها في الشهر الماضي. اكتب أداة للبحث عن الطلبات السابقة، وهي OrderHistoryService، وأخرى لطلب القهوة. لاختبار خدمة سجلّ الطلبات، يمكنك إرسال نموذج أولي يعرض معرّف منتج قهوة.

في هذا المثال، يمكنك تقييم ما إذا كان النموذج يفهم نيّة طلب البحث ويختار الأداة المناسبة وما إذا كانت هذه الأداة تقدّم المعلومات الصحيحة لاتخاذ إجراء. إذا لم يستدعِ النموذج get_order_history، فلن يعرف item_id الذي يجب استخدامه لـ order_product.

الاختبار الشامل

اكتب اختبارات شاملة لتتأكّد من أنّ المستخدمين والوكلاء يمكنهم إكمال رحلاتهم بنجاح. بالإضافة إلى اختبار الأدوات الفردية، يمكنك أيضًا اختبار تنفيذ الإجراءات المتعدّدة الخطوات بالترتيب الصحيح.

على سبيل المثال، أنت تدير متجرًا للملابس على الإنترنت. يطلب مستخدم من وكيله: "أبحث عن شراء سترة سوداء وبنطلون جينز. هل يمكنك تقديم تفاصيل عن المواد المستخدَمة؟"

قد تبدو رحلة الوكيل الناجحة على النحو التالي:

1. الانتقال إلى فئة الملابس
2. العثور على أحد الملابس المطلوبة (الترتيب غير مهم)
3. العثور على عنصر محدّد (search_clothes)
4. الحصول على تفاصيل المنتج التي تحتوي على قائمة المواد (get_product_details)
5. تكرار الخطوات من 2 إلى 4 لكل عنصر مطلوب

عندما يصل الوكيل إلى الخطوة 2، يمكنه البحث عن السترة السوداء أولاً أو بنطلون الجينز، والترتيب غير مهم. ومع ذلك، يجب اتّباع الخطوات المتبقية بالتسلسل.

اكتب عملية تقييم شاملة للتحقّق من أنّ الوكيل يستدعي الأدوات بالترتيب المتوقّع:

{
  "messages": [
    {
      "role": "user",
      "content": "I am looking to buy a black jacket and a pair of jeans.
        Could you provide a breakdown of the materials used ?"
    }
  ],
  "expectedCall": [
    {
      "functionName": "navigate_to_category",
      "arguments": { "category": "clothes" }
    },
    {
      "unordered": [
        {
          "ordered": [
            {
              "functionName": "search_clothes",
              "arguments": { "query": "black jacket" }
            },
            {
              "functionName": "get_product_details",
              "arguments": { "productId": "JACKET002" }
            }
          ]
        },
        {
          "ordered": [
            {
              "functionName": "search_clothes",
              "arguments": { "query": "jeans" }
            },
            {
              "functionName": "get_product_details",
              "arguments": { "productId": "JEANS001" }
            }
          ]
        }
      ]
    }
  ]
}

تقييم حالات الإخفاق في منتصف السلسلة

قد يحتاج الوكيل في بعض الأحيان إلى استدعاء أدوات متعددة بالتسلسل. ماذا يحدث إذا تعذّر تنفيذ أداة في منتصف هذه العملية؟ على سبيل المثال، يريد المستخدم طلب بيتزا باستخدام رمز القسيمة:

"أريد بيتزا صغيرة بالبيستو. استخدِم الرمز الترويجي FreePizza."

من المحتمل أن يتعذّر تنفيذ الوكيل في add_discount_coupon وأن ينتقل إلى صفحة الدفع لطلب بيتزا بسعرها الكامل. لاختبار أداة add_discount_coupon، يمكنك تنفيذ تسلسل استدعاءات الأدوات هذا يدويًا، بدون التفاعل مع نموذج، لمحاكاة هذا السيناريو. انقل تطبيقك إلى الحالة التي تتوقّع أن تفشل فيها الأداة. في هذه الحالة، يكون ذلك بعد أداة start_checkout. بعد ذلك، يمكنك تقييم add_discount_coupon بشكلٍ منفصل.

تجربة WebMCP

ابدأ تجربة عمليات التقييم للأدوات بشكلٍ منفصل وتقييم المواقع الإلكترونية المفعَّلة باستخدام WebMCP مع أي وكيل متوافق مع WebMCP:

• نزِّل أدوات التقييم التجريبية على GitHub.
• راجِع الدورة التدريبية إنشاء عمليات تقييم للذكاء الاصطناعي.