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

Alexandra Klepper

تم النشر في: 18 مايو 2026

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

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

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

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

• يجب أن تتألف كل أداة من دالة واحدة. على سبيل المثال، يمكن أن تكون إحدى الأدوات هي توجيه المستخدم إلى نوع نموذج معيّن، بينما يجب أن تطابق أداة أخرى حقول الإدخال مع معلومات المستخدم. احرص على عدم إنشاء أدوات متداخلة، لأنّ الوكيل قد لا يعرف ما يجب استخدامه. اسأل نفسك: هل يمكنني تغطية مهام متعددة باستخدام الدالة نفسها؟
• إدارة تسجيل الأداة: سجِّل الأدوات عندما تكون مفيدة في حالة صفحة معيّنة، ثم ألغِ تسجيلها عندما تصبح غير قابلة للاستخدام.
  • واجهة برمجة التطبيقات الإلزامية: يمكنك إدارة التسجيل ديناميكيًا باستخدام 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.