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

Alexandra Klepper

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

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

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

لقد كتبنا بشكل منفصل عن إنشاء أدوات تراعي الأمان.

إنشاء استراتيجية أداة

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

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