تاريخ النشر: 19 مايو 2026، تاريخ آخر تحديث: 28 مايو 2026
| فيديو توضيحي | الويب | الإضافات | حالة Chrome | النيّة بالشراء |
|---|---|---|---|---|
| Github |  مرحلة التجربة والتقييم |
العرض | النية في إجراء تجربة |
يدعم WebMCP الوكلاء الذين يستخدمون نماذج الذكاء الاصطناعي التوليدية. لاختبار أي نظام يستخدم الذكاء الاصطناعي التوليدي، يجب أن تدعم اختباراتك النتائج الاحتمالية: يمكن أن يؤدي إدخال واحد إلى آلاف الإجابات بدرجات متفاوتة من الدقة. تُسمى تقنية الاختبار هذه التقييمات أو التقييمات.
قبل إطلاق الأدوات في بيئة الإنتاج، يجب عليك التأكد من أن الوكلاء يفهمون متى يجب استدعاء الأداة، وكيفية تنفيذها، وما هي الإجابات المقبولة. عالج فرص الفشل قبل حدوثها.
اكتب تقييمات لاختبار نقاط اتصال نظامك باستخدام نموذج لغة كبير (LLM):
- تأكد من أن النموذج يفهم الغرض من أداتك، بناءً على وصفها ومخططها.
- تحقق من أن النموذج يختار الأداة المناسبة بالمعلمات الصحيحة لدعم نية المستخدم.
- تأكد من أن النموذج يتصرف بناءً على المعلومات التي تلقاها، على سبيل المثال لاستخدام المعلومات لاستدعاء أداة أخرى.
- تحقق من نجاح رحلات المستخدم. بالنظر إلى نية المستخدم، هل يستطيع الوكيل إتمام رحلة المستخدم بنجاح على موقعي الإلكتروني باستخدام الأدوات المتاحة؟
ينبغي عليك الاستمرار في كتابة الاختبارات الحتمية الكلاسيكية لأي تفاعل مع النظام لا يتواصل مع النموذج.
أنماط الفشل
ينبغي على المطورين اختبار أنظمتهم لمنع الأعطال قبل حدوثها. وللقيام بذلك، تحتاج إلى فهم متى قد يفشل النظام، سواء بمفرده أو عند تفاعله مع عوامل خارجية. بالنسبة لـ WebMCP، قد تفشل الأداة نفسها وقد يفشل العملاء في استخدام الأدوات كما هو متوقع.
قد تفشل أدوات WebMCP، وقد يفشل الوكيل مع أدوات WebMCP. على سبيل المثال، لنفترض أن المستخدم يريد إضافة قميص إلى سلة التسوق الخاصة به.
| تعذّر إتمام العملية | مثال | تحديد المشاكل وحلّها |
|---|---|---|
| يفشل الموظف في اختيار الأداة الصحيحة أو يستدعي الأداة الخاطئة مباشرةً. |
يتخطى العامل 
|
|
| يقوم الوكيل باستدعاء الأدوات بترتيب خاطئ |
يتصل الوكيل بـ 
|
|
| يقوم الوكيل باستدعاء الأداة باستخدام وسائط غير صحيحة |
يقوم الوكيل بالاتصال بـ 
|
|
ماذا لو أراد المستخدم التحقق مما هو موجود في سلة التسوق الخاصة به؟
| تعذّر إتمام العملية | مثال | تحديد المشاكل وحلّها |
|---|---|---|
| مخرجات الأداة غير صحيحة أو أن الأداة أغفلت شيئاً ما. | يطلب المستخدم 
|
|
وأخيرًا، يمكن للأداة أن تعمل بأي طريقة تفشل فيها جافا سكريبت. لحل المشكلة، تحقق مما يلي:
- هل يتعامل رمز الأداة بشكل صحيح مع جميع أخطاء وقت التشغيل والاستثناءات المحتملة؟
- هل يتم إبلاغ الوكيل والنموذج بالخطأ بشكل سليم؟
- هل واجهات برمجة التطبيقات أو الخدمات الخارجية التي تعتمد عليها الأداة سليمة؟
- هل بنية الخطأ واضحة بما يكفي بحيث يمكن للنموذج التمييز بين مشكلة مؤقتة (إعادة المحاولة) وفشل حرج؟
أدوات الاختبار بمعزل عن بعضها البعض
إذا لم يتمكن الموظف من معرفة الأداة التي يجب استخدامه لطلب مثل "أريد بيتزا صغيرة"، فلن يكون لديه فرصة في رحلة المستخدم المعقدة.
من خلال اختبار الأدوات بشكل منفصل، يمكنك تحسين المخططات والأوصاف الخاصة بك قبل تشغيل محاكاة المتصفح.
قياس دقة المكالمات
ألقِ نظرة على العرض التوضيحي الخاص بنا، 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. تذكر أن تحاكي البيئة التي تعمل فيها الأداة للحصول على أفضل النتائج الممكنة. وهذه هي الطريقة نفسها التي تستخدمها لكتابة اختبار تكامل تطبيق آخر.
إجراء اختبارات احتمالية
إذا كنت بحاجة إلى مخرجات نموذجية لاستدعاء الأدوات التالية بشكل صحيح، فأنت بحاجة إلى كتابة دوال التقييم (evals).
من الممكن للمستخدمين تقديم استعلامات مباشرة إلى النموذج تسأل تحديدًا عما تفعله الأداة، أو استعلام غامض يشير إلى أنه ينبغي استخدام أداة معينة. على سبيل المثال، "أضف بيبروني إلى البيتزا الخاصة بي" هو استعلام مباشر. "أريد كل اللحم على البيتزا الخاصة بي" أكثر غموضًا ويتطلب من النموذج أن يفهم أنه يحتاج إلى أداة add_topping وأي من الإضافات يمكن تعريفها على أنها لحم.
عند إنشاء مجموعات البيانات لتقييماتك، قم بتضمين كل من الاستعلامات المباشرة التي تختبر تنفيذ الأداة الأساسية والاستعلامات المفتوحة التي تختبر منطق النموذج ومنطق اختيار الأداة.
إذا كنت تدير مقهى، فيمكنك دعم المستخدمين الذين يطلبون من وكيلهم إعادة طلب نفس القهوة التي طلبوها الشهر الماضي. اكتب أداة للبحث عن الطلبات السابقة، OrderHistoryService، وأداة أخرى لطلب القهوة. لاختبار خدمة سجلّ الطلبات، يمكنك إرسال نموذج يعرض معرّف منتج قهوة.
في هذا المثال، تقوم بتقييم ما إذا كان النموذج يفهم نية الاستعلام، ويختار الأداة المناسبة، وما إذا كانت تلك الأداة توفر المعلومات الصحيحة لاتخاذ الإجراء.
إذا لم يستدعِ النموذج get_order_history، فلن يعرف ما هو item_id الذي يجب استخدامه لـ order_product.
اختبار شامل من البداية إلى النهاية
اكتب اختبارات شاملة لتتأكّد من أنّ المستخدمين وبرامجهم يمكنهم إكمال رحلاتهم بنجاح. بالإضافة إلى اختبار الأدوات الفردية، فإنك تختبر أيضًا أن الإجراءات متعددة الخطوات يتم تنفيذها بالترتيب الصحيح.
على سبيل المثال، أنت تدير متجرًا إلكترونيًا للملابس. يسأل أحد المستخدمين وكيله: "أرغب في شراء سترة سوداء وبنطال جينز". هل يمكنك تقديم تفاصيل حول المواد المستخدَمة؟"
قد تبدو رحلة الوكالة الناجحة على النحو التالي:
- انتقِل إلى فئة الملابس.
- ابحث عن أحد قطع الملابس المطلوبة (الترتيب غير مهم).
- ابحث عن عنصر معيّن (
search_clothes). - احصل على تفاصيل المنتج التي تحتوي على قائمة المواد (
get_product_details). - كرِّر الخطوات من 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" }
}
]
}
]
}
]
}
تقييم حالات الفشل في منتصف السلسلة
start_pizza_creator وset_pizza_style وset_pizza_size وstart_checkout وadd_discount_coupon وcomplete_checkout. تعذّر تنفيذ add_discount_coupon، ولكن كان من الممكن إكمال العملية، ما يعني أنّ المستخدم لم يحصل على خصم.قد يحتاج الوكيل في بعض الأحيان إلى استدعاء أدوات متعددة بالتسلسل. ماذا يحدث إذا تعذّر إكمال إحدى الأدوات في منتصف هذه العملية؟ على سبيل المثال، يريد المستخدم طلب بيتزا باستخدام رمز القسيمة:
"أريد بيتزا صغيرة بصلصة البيستو. استخدِم الرمز الترويجي FreePizza".
من المحتمل أن يتعذّر على الوكيل تنفيذ الطلب عند add_discount_coupon، وأن ينتقل إلى صفحة الدفع لشراء بيتزا بالسعر الكامل. لاختبار أداة add_discount_coupon، يمكنك تنفيذ تسلسل استدعاءات الأدوات هذا يدويًا بدون التفاعل مع نموذج لمحاكاة هذا السيناريو. اجعل تطبيقك في الحالة التي تتوقّع أن تفشل فيها الأداة. في هذه الحالة، يكون ذلك بعد الأداة start_checkout. بعد ذلك، يمكنك تقييم add_discount_coupon بشكل منفصل.
تجربة WebMCP
ابدأ تجربة عمليات التقييم للأدوات بشكل منفصل وتقييم مواقعك الإلكترونية المفعَّلة باستخدام WebMCP مع أي وكيل متوافق مع WebMCP:
- يمكنك تنزيل أدوات التقييم التجريبية على GitHub.
- راجِع الدورة التدريبية إنشاء تقييمات الذكاء الاصطناعي.