أفضل الممارسات المتعلّقة بـ WebMCP

Alexandra Klepper

Published: May 18, 2026

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

• قبل إنشاء الأداة، ضَع استراتيجية لها.
• استخدِم لغة واضحة وHTML دلاليًا.
• صمِّم المخططات وتعامل مع الإدخالات.
• أنشِئ أدوات موثوقة.
• اختبِر الأداة وصحِّح أخطاءها.

ضَع استراتيجية للأداة

تمامًا كما تفعل مع أي تطبيق برمجي، يجب أن تكون خطوتك الأولى هي التخطيط لاستراتيجية الأداة:

• يجب أن تتألف كل أداة من دالة واحدة. على سبيل المثال، يمكن أن تكون إحدى الأدوات هي توجيه المستخدم إلى نوع نموذج معيّن، بينما يجب أن تطابق أداة أخرى حقول الإدخال مع معلومات المستخدم. احرص على عدم إنشاء أدوات متداخلة، لأنّ الوكيل قد لا يعرف ما يجب استخدامه. اسأل نفسك: هل يمكنني تغطية مهام متعددة باستخدام الدالة نفسها؟
• إدارة تسجيل الأداة: سجِّل الأدوات عندما تكون مفيدة في حالة صفحة معيّنة، ثم ألغِ تسجيلها عندما تصبح غير قابلة للاستخدام.
  • واجهة برمجة التطبيقات الإلزامية: يمكنك إدارة التسجيل بشكل ديناميكي باستخدام unregisterTool و.registerTool
  • واجهة برمجة التطبيقات التصريحية: يمكنك إدارة التسجيل بشكل ديناميكي عن طريق إضافة سمات الأداة أو إزالتها من نموذج باستخدام toolName وtoolDescription.
• تقليل التعقيد: بالنسبة إلى معظم التطبيقات، يجب أن يكون التسجيل الثابت هو النهج التلقائي.
• اعتمد على الوكيل لإكمال المهمة*. بدلاً من كتابة تعليمات صارمة أو سلبية، افترِض أنّ الوكيل قادر على فهم ما هو مطلوب لإكمال المهمة، بدلاً من توقُّع أن يدير الوكيل تسلسلاً دقيقًا للخطوات.

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

يساعدك ذلك في إنشاء أدوات فردية، بدون تداخل في الغرض، وإدارة وقت توفّر هذه الأدوات.

استخدِم لغة واضحة ورمزًا دلاليًا

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

عند كتابة أسماء الأدوات، ميِّز التنفيذ عن البدء، واستخدِم الأفعال التي تصف ما يحدث بالضبط. على سبيل المثال، create-event هي أداة لإنشاء حدث فوري، ولكن start-event-creation-process هي أداة تُعيد توجيه المستخدم إلى نموذج لإنشاء الحدث.

يجب أن يصف الوصف الواضح ما تفعله الأداة ومتى يجب استخدامها. اعتمد على اللغة والتفضيلات الإيجابية بدلاً من اللغة السلبية، مثل القيود.

تقليل الحوسبة الإدراكية

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

• قبول بيانات أدخلها المستخدم الأولية. تجنَّب أن تطلب من الوكيل إجراء عمليات حسابية أو تحويل السلاسل المُدخَلة. على سبيل المثال، إذا قال أحد المستخدمين "من الساعة 11:00 إلى الساعة 15:00"، يجب أن تقبل الأداة ذلك كسلسلة. تجنَّب أن تطلب من النموذج حساب الدقائق بين هذين الوقتَين.
• الإعلان عن أنواع محدّدة للمعلمات، مثل السلسلة أو الرقم أو التعداد.
• توضيح سبب اتّخاذ خيارات معيّنة. يجب أن يكون الخيار الذي اتّخذته واضحًا بذاته. يساعد السبب الوكلاء في اتّخاذ خيارات أفضل. على سبيل المثال، إذا كنت تدير متجرًا للتجارة الإلكترونية، أعلِن عن نوع الشحن بلغة طبيعية بدلاً من استخدام رقم تعريف غامض: shipping="Express" بدلاً من shipping_id=1.

إعطاء الأولوية للموثوقية

يستفيد الوكلاء والمستخدمون من الأدوات التي تعمل على النحو المتوقّع:

• اضبط آلية للتعامل مع حالات الفشل بشكل سلس في ما يتعلّق بالحدود القصوى للطلبات : يجب أن تسمح الأدوات بالتكرار المعقول، مثل مقارنة الأسعار. إذا تم فرض حد أقصى لعدد الطلبات على أداة، فعليك عرض خطأ مفيد أو ننصح المستخدم بتنفيذ المهمة يدويًا.
• عدِّل حالة الواجهة بعد اكتمال الدوال : قد يعتمد الوكلاء على الواجهة للتخطيط للخطوات التالية، بينما قد يستغرق إكمال الدوال وقتًا أطول من تحميل الواجهة. يجب أن يؤكّد الوكيل اكتمال الدالة بعد تعديل الواجهة، أو يطلب تعديلها مرة أخرى.
• التحقّق بدقة في الرمز، وبشكل غير دقيق في المخطط : يجب استخدام القيود والاختبارات للدوال والرمز اللذين يتضمّنان منطقًا ثنائيًا. على الرغم من أنّ قيود المخطط يمكن أن تكون مفيدة، إلا أنّها ليست مضمونة. أضِف أخطاء وصفية إلى رمز الدالة للسماح للنموذج بتصحيح نفسه وإعادة المحاولة باستخدام معلّمات جديدة وصالحة.

اختبار التقييم وتصحيح الأخطاء

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

• حدِّد المشكلة : يمكنك صياغة مشكلتك كعقد واجهة برمجة تطبيقات، بما في ذلك نوع الإدخال وتنسيق الإخراج وأي قيود إضافية.
• حدِّد خطًا أساسيًا ونتيجة مثالية : خاصةً مع إدخال النص، من المهم فهم أنواع النتائج التي يمكن أن تحصل عليها للحصول على الناتج الذي تتوقّعه.
• حدِّد كيفية تقييم الناتج : من المحتمل أنّك تحدّد وتقيس نتائج ذاتية ونوعية استنادًا إلى جودة الإدخال وفائدته وقدرته على إنجاز المهمة التالية. هناك عدد من الأساليب التي يمكنك استخدامها لتقييم الناتج، بما في ذلك عمليات التحقّق المستندة إلى الرمز للنتائج المستندة إلى القواعد (الحدود القصوى للأحرف) وLLM-as-a-judge.

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

تفاعل وشارِك ملاحظاتك

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

• اقرأ شرح WebMCP، واطرح الأسئلة وشارِك في المناقشة.
• راجِع عملية التنفيذ في Chrome على صفحة حالة Chrome.
• انضم إلى برنامج المعاينة المبكرة للاطّلاع على واجهات برمجة التطبيقات الجديدة قبل إطلاقها والوصول إلى قائمتنا البريدية.
• إذا كانت لديك ملاحظات على عملية التنفيذ في Chrome، يُرجى إرسال تقرير عن خلل Chromium.