به آزمایش اولیه WebMCP بپیوندید

پس از اینکه Chrome 149 شروع به ارائه آزمایشی اصلی WebMCP کرد، رابطه بین صفحه وب و پراکسی مستقیم‌تر می‌شود: صفحه دیگر فقط DOM و کپی قابل مشاهده را برای حدس زدن ماشین نشان نمی‌دهد، خود کنترل همچنین می‌تواند هدف، وضعیت و مرزهای اجرایی را اعلام کند. این تغییر شبیه یک آزمایش API به نظر می‌رسد، اما در واقع بیشتر شبیه ارتقای «نیت رابط» از اطلاعات ضمنی به پروتکل صریح است.

ارزش چیزی مانند WebMCP اضافه کردن یک لایه از اصطلاحات به صفحه وب نیست، بلکه برای تشدید عدم قطعیتی است که نمایندگان بیش از همه از آن می ترسند. آیا یک دکمه برای ارسال، تغییر، تأیید یا باز کردن یک لایه پاپ آپ است. آیا کادر ورودی تاریخ، عبارت جستجو یا زمان ملاقاتی است که به قالب خاصی نیاز دارد. در گذشته، این اطلاعات عمدتاً از متن، ساختار و زمینه استنباط می شد. استنتاج کار می کند، اما وقتی صفحه پیچیده می شود، عامل شروع به اشتباه “به نظر می رسد” با “است”.

برای انسان ها، این اشتباه خواندن معمولاً فقط یک اشتباه است. برای نمایندگان، خوانش نادرست به مسیر ثابتی از خطا تبدیل می شود. تا زمانی که با تأیید، بازگشت، یا عوارض جانبی مواجه شود که نشان می دهد مرحله قبلی به بیراهه رفته است، با درک اشتباه اجرا می شود. پس از اینکه WebMCP این لایه معناشناسی را واضح کرد، عامل مجبور نیست صفحه را به عنوان یک نقشه صرفاً بصری حدس بزند، و صفحه وب همچنین می تواند به وضوح مسئولیت سطوح تعامل کلیدی را توضیح دهد.

این موضوع برای آن دسته از اینترفیس‌هایی مناسب است که توضیح آن‌ها با کپی‌نویسی خالص HTML دشوار است، مانند تقویم‌ها، رزروها، برنامه‌های مجوز، پانل‌های تنظیمات، یا دسته‌ای از صفحات که شبیه جعبه‌های ورودی معمولی هستند اما در واقع معانی تجاری متفاوتی دارند. هنگامی که فقط به برچسب و مکان‌نما متکی است، عامل اغلب مجبور است صفحه را دور بزند و دوباره و دوباره امتحان کند. هنگامی که صفحه بتواند اعلام کند “اینجا انتخاب تاریخ است” “اینجا اقدام تایید است” و “وضعیت اینجا فقط می تواند در این جهت تغییر کند”، هزینه ادغام مستقیما کاهش می یابد.

اما آزمایش مبدأ موضوع دیگری را نیز مطرح می‌کند: این لایه معناشناسی باید حفظ شود. ساختار صفحه تغییر خواهد کرد، کپی دکمه تغییر خواهد کرد، و وضعیت کسب و کار تغییر خواهد کرد. اگر لایه قصدی که عامل واقعاً به آن متکی است همراه با مؤلفه ها به روز نشود، به زودی جابجا می شود. در آن زمان، خطرناک ترین حالت “کاملاً غیرقابل استفاده” نیست، اما “هنوز می تواند اجرا شود، اما گاهی اوقات اشتباه می کند، و اشتباهات طبیعی هستند.”

بنابراین، WebMCP بیشتر شبیه یک قرارداد با خود صفحه وب است، نه یک کارت یادآوری ارسال شده به نماینده. این نیاز به بخش جلویی دارد که مرزهای تعامل را در پیاده سازی، در تست ها و در بررسی های رگرسیون بنویسد. تا زمانی که این لایه قرارداد هنوز در مرحله نمایش است، تمام چیزی که نماینده می تواند بفهمد یک مورد موفقیت است. هنگامی که وارد صفحه واقعی می شود، چیزی که واقعاً باید با آن برخورد شود سازگاری نسخه، مسیر کاهش رتبه و راه حل پس از نامعتبر شدن اعلامیه است.

من ترجیح می دهم این آزمایش مبدأ را به عنوان یک سیگنال جهت دار در نظر بگیرم. مرورگرها شروع به بررسی جدی نحوه خواندن صفحات وب توسط نمایندگان کردند، به این معنی که قسمت جلویی نه تنها برای افراد قالب‌بندی می‌شود، بلکه اقداماتی را برای ماشین‌ها نیز تعریف می‌کند. هرچه صفحه پیچیده تر باشد، این لایه تعریف ارزشمندتر است. هرچه صفحه بیشتر تغییر کند، هزینه تعمیر و نگهداری این لایه تعریف بیشتر است. میراث نهایی قابلیت‌هایی مانند WebMCP یک اصطلاح جدید نیست، بلکه اصطلاحی برای همسویی مداوم بین قسمت جلو و عامل خواهد بود.