انضم إلى تجربة WebMCP الأصلية

بعد أن يبدأ Chrome 149 في تقديم تجربة أصل WebMCP، ستصبح العلاقة بين صفحة الويب والوكيل أكثر مباشرة: لم تعد الصفحة تعرض فقط DOM والنسخة المرئية ليخمنها الجهاز، ويمكن لعنصر التحكم نفسه أيضًا أن يعلن الغرض والحالة والحدود القابلة للتنفيذ. يبدو هذا التغيير بمثابة تجربة لواجهة برمجة التطبيقات (API)، ولكنه في الواقع يشبه إلى حد كبير رفع “هدف الواجهة” من المعلومات الضمنية إلى البروتوكول الصريح.

إن قيمة شيء مثل WebMCP لا تتمثل في إضافة طبقة من المصطلحات إلى صفحة الويب، بل في تشديد حالة عدم اليقين التي يخشاها الوكلاء أكثر من غيرها. ما إذا كان الزر سيتم إرساله أو تبديله أو تأكيده أو مجرد فتح طبقة منبثقة؛ ما إذا كان مربع الإدخال عبارة عن تاريخ أو مصطلح بحث أو وقت موعد يتطلب تنسيقًا خاصًا. في الماضي، كان يتم استنتاج هذه المعلومات بشكل أساسي من النص والبنية والسياق. يعمل الاستدلال، ولكن بمجرد أن تصبح الصفحة معقدة، يبدأ الوكيل في الخلط بين “يبدو” و"هو".

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

هذا الأمر مناسب أكثر لتلك الواجهات التي يصعب تفسيرها باستخدام كتابة نص HTML خالصة، مثل التقويمات أو الحجوزات أو تطبيقات الأذونات أو لوحات الإعدادات أو مجموعة من الصفحات التي تبدو وكأنها مربعات إدخال عادية ولكنها في الواقع تحمل معاني تجارية مختلفة. عند الاعتماد فقط على التسمية والعنصر النائب، غالبًا ما يتعين على الوكيل التجول في الصفحة والمحاولة مرارًا وتكرارًا؛ بمجرد أن تعلن الصفحة “هذا هو تحديد التاريخ” و"هذا هو إجراء التأكيد" و"لا يمكن أن تتغير الحالة هنا إلا في هذا الاتجاه"، سيتم تخفيض تكلفة التكامل مباشرة.

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

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

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