WebMCP: جایگزینی قراردادهای ساختاریافته با استخراج داده از DOM

تصور کنید جهانی را که در آن عامل‌های هوش مصنوعی دیگر برای پیدا کردن یک دکمه حدس نمی‌زنند، بلکه وب‌سایت‌ها را از طریق مجموعه‌ای از دستورالعمل‌های دقیق هدایت می‌کنند. این هدف اصلی WebMCP است؛ پیشنهادی در سطح مرورگر از سوی گروه کاری یادگیری ماشین وب در W3C که اجازه می‌دهد یک صفحه، ابزارهای ساختاریافته‌ای را برای فراخوانی مستقیم توسط عامل‌ها ثبت کند. این رویکرد نشان‌دهنده یک تغییر پارادایم است: وب‌سایت‌ها از حالتی که صرفاً توسط هوش مصنوعی «خوانده» می‌شدند، به حالتی تغییر می‌کنند که توسط هوش مصنوعی «هدایت و مدیریت» شوند.

سال‌هاست که عامل‌ها (Agents) — شبیه دستیارهای دیجیتالی که می‌توانند به‌جای شما کارهای پیچیده را در وب انجام دهند — برای تعامل با وب به استخراج داده از مدل شیء سند (DOM)، پیمایش درخت دسترسی (Accessibility Tree) یا خواندن اسکرین‌شات‌ها متکی بوده‌اند. طبق گزارش‌های فنی، این روش به‌شدت شکننده است؛ یک تغییر ساده در CSS یا ظاهر شدن یک بنر تبلیغاتی دیرهنگام می‌تواند کل گردش‌کار یک عامل را مختل کند. این حالت شکست باعث کندی عامل‌ها می‌شود و آن‌ها را در برابر تزریق پرامپت (Prompt Injection) آسیب‌پذیر می‌کند، زیرا وقتی متن‌های غیرقابل‌اعتماد یک صفحه به‌جای محتوا، به‌عنوان دستورالعمل شناسایی شوند، عامل ممکن است دچار خطا شود. در همین راستا، ابزارهایی مانند HatFetch تلاش می‌کنند با استراتژی‌های ارتقای تدریجی محدودیت‌های شناسایی ربات و پیچیدگی‌های استخراج داده را مدیریت کنند.

سارا دراسنر در دموی WebMCP صراحتاً جایگزین این وضعیت را بیان می‌کند: به عامل‌ها ابزار بدهید، نه یک DOM استخراج‌شده. تصور کنید در یک سایت رزرو، یک عامل باید ابتدا فیلد تاریخ را پیدا کند، سپس دکمه ارسال را بیابد و امیدوار باشد که چیدمان صفحه در این فاصله تغییر نکند. WebMCP این حدس‌زنی را با یک قرارداد رسمی جایگزین می‌کند. به‌جای مهندسی معکوس رابط کاربری (UI)، سایت دقیقاً اعلام می‌کند که چه کارهایی را از طریق یک رابط استاندارد می‌تواند انجام دهد.

همان‌طور که در تحلیل‌های قبلی ما درباره‌ی پروتکل‌های ارتباطی مدل‌ها اشاره کردیم، استانداردسازی لایه‌ی تعامل، کلید مقیاس‌پذیری است.

سازوکار WebMCP

WebMCP مشابه ابزارهای پروتکل زمینه مدل (MCP) در سمت سرور عمل می‌کند، اما تفاوت بنیادین در این است که کاملاً در محیط کاربر و نشست (Session) جاری اجرا می‌شود. در حالی که MCP سرور از طریق یک سرور راه دور به دستیارهایی مثل ChatGPT یا Claude متصل می‌شود، WebMCP روی خودِ صفحه مستقر است. این پروتکل از متد document.modelContext.registerTool برای تعریف قابلیت‌ها استفاده می‌کند. این رویکرد در واقع تکامل همان استاندارد MCP است که پیش‌تر باعث کاهش شدید مصرف توکن‌ها در فرآیندهای استخراج وب شده بود.

• تعاریف ساختاریافته: هر ابزار شامل یک نام، توضیحات و یک طرحواره JSON (JSON Schema) برای ورودی‌ها است تا مدل دقیقاً بداند چه داده‌ای ارسال کند.
• مسیرهای اجرا: هر ابزار مستقیماً به یک تابع اجرایی (Execute Function) در جاوااسکریپت صفحه متصل می‌شود.
• مسیر دستوری (Imperative): در این حالت، جاوااسکریپت ابزارهایی مانند getAvailability (بررسی موجودی) یا bookSlot (رزرو جایگاه) را همراه با یک طرحواره و تابع اجرا ثبت می‌کند.
• مسیر اخباری (Declarative): فرم‌ها می‌توانند قابلیت‌های خود را با استفاده از ویژگی‌های (Attributes) HTML مانند toolname و toolparamdescription نمایش دهند. این یعنی یک جریان رزرو می‌تواند بدون نیاز به نوشتن اسکریپت ثبت جداگانه، به یک ابزار تبدیل شود.

این تغییر به این معناست که یک عامل دیگر نیازی ندارد «فیلد تاریخ را پیدا کند». مرورگر (یا یک افزونه مجهز به WebMCP) این ابزارها را جمع‌آوری کرده و با رعایت محدوده دسترسی (Origin Scope) و در حالی که مجوزها همچنان در چرخه تایید هستند، آن‌ها را به عامل ارائه می‌دهد. عامل صرفاً تاریخ، زمان و ایمیل مورد نیاز را طبق قرارداد ارسال می‌کند و کد داخلی سایت عملیات رزرو را مدیریت می‌کند. این فرآیند توکن (Token) — تکه‌های کوچکی از متن که مدل تکه‌تکه می‌خورد — کمتری مصرف می‌کند، کلیک‌های اشتباه را کاهش می‌دهد و مرزهای امنیتی سخت‌گیرانه‌تری ایجاد می‌کند.

زمینه پیاده‌سازی

بر اساس مستندات، این پیشنهاد هنوز در مراحل اولیه است. گوگل کروم پشتیبانی آزمایشی در قالب Origin-trial را اجرا کرده است. حتی نام APIها در این مدت تغییر کرده و از navigator.modelContext به سمت document.modelContext حرکت کرده است. به‌دلیل این نوسانات و تغییرات سریع، پذیرش این فناوری در محیط‌های عملیاتی باید به‌عنوان یک پژوهش آگاهانه دیده شود، نه الزامی برای بازنویسی تمام فرم‌ها در این فصل.

تداوم جابه‌جایی چیدمان

با وجود این ابزارها، پایداری بصری همچنان حیاتی است. ممیزی‌های آزمایشی Lighthouse Agentic Browsing در کروم نشان می‌دهند که جابه‌جایی تجمعی چیدمان (CLS) همچنان یک ریسک جدی است. اگر یک ابزار موجود نباشد یا ناقص باشد و عامل مجبور شود به روش قدیمی هدف‌گیری رابط کاربری (UI Targeting) بازگردد، جابه‌جایی چیدمان باعث شکست عملیات می‌شود.

لایت‌هاوس به‌طور خاص اشاره می‌کند که اگر تبلیغات، تصاویر دیرهنگام یا بنرهای تزریق‌شده، چیدمان را بین لحظه‌ی «شناسایی کنترل» توسط عامل و لحظه‌ی «فعال‌سازی آن» تغییر دهند، اقدام عامل با خطا مواجه می‌شود. تیم‌های محصول نمی‌توانند معیارهای حیاتی وب (Core Web Vitals) را صرفاً به‌دلیل پیاده‌سازی WebMCP نادیده بگیرند.

در عمل، یک لیست ثبت‌شده‌ی «سبز» از ابزارها، لزوماً از URL تبدیل (Conversion) محافظت نمی‌کند اگر یک بنر دیرهنگام، عناصری را که عامل در هنگام استخراج داده‌ی جایگزین (Fallback Scrape) سعی در هدف‌گیری آن‌ها دارد، جابه‌جا کند. تیم‌هایی که ثبت ابزار را در دموها نمایش می‌دهند اما پایداری چیدمان را نادیده می‌گیرند، با اولین بنر تبلیغاتی که دیرهنگام بارگذاری شود، دوباره با شکست‌های مسیر استخراج داده مواجه می‌شوند.

WebMCP صفحه در برابر MCP سرور

برای جلوگیری از خطاهای راهبردی در نقشه راه (Roadmap)، تفکیک این دو الگوی پیاده‌سازی ضروری است:

۱. MCP سرور: این یک الگوی ادغام دستیار است. این پروتکل به دستیارهایی مثل Claude یا ChatGPT دسترسی امن و محدود به داده‌ها و اقدامات بک‌اند محصول را از طریق پروتکلی می‌دهد که بک‌اند شرکت مالک آن است. برای درک بهتر مقیاس این رویکرد، می‌توان به پروژه‌ی Mu اشاره کرد که دسترسی به ۶۷ ابزار عملیاتی را از طریق یک نقطه اتصال MCP یکپارچه کرده است.
۲. WebMCP صفحه: این مورد درباره اعلام قابلیت‌های یک سند (Document) خاص در لحظه‌ای است که کاربر فعالاً در آن صفحه حضور دارد.

اشتباه در این تفکیک منجر به اتلاف منابع در اسپرینت‌های توسعه می‌شود؛ یا ابزارهای صفحه را در جایی می‌سازند که یک API احراز هویت‌شده لازم بود، یا عامل‌ها را به استخراج داده از ویجت‌ها واگذار می‌کنند چون قراردادهای صفحه را نادیده گرفته‌اند.

ممیزی‌های آزمایشگاهی و نظارت

بخش Agentic Browsing در لایت‌هاوس کروم می‌تواند ثبت WebMCP و بررسی‌های آمادگی را رصد کند. برخلاف امتیازات آشنای ۰ تا ۱۰۰ در بخش Performance، این ممیزی‌ها از نسبت‌های عبور کسری (Fractional Pass Ratios) استفاده می‌کنند. اگرچه این ابزار برای بهداشت کد مفید است، اما جایگزین نظارت مستمر بر PageSpeed برای رگرسیون‌هایی که کاربر نهایی حس می‌کند، نیست.

اجرای‌های پراکنده لایت‌هاوس با همان مشکل زمان‌بندی چک‌های دستی PageSpeed روبروست. یک تایید سبز در روز سه‌شنبه ثابت نمی‌کند که زمان‌بندی ثبت، روندهای CLS یا طرحواره‌های ابزار پس از انتشار یک تگ تبلیغاتی جدید در روز پنج‌شنبه همچنان درست کار می‌کنند. به همین دلیل، نظارت زمان‌بندی‌شده بر اسکرین‌شات‌های آزمایشگاهی برتری دارد.

آماده‌سازی برای پذیرش

آژانس‌ها و توسعه‌دهندگان می‌توانند از همین امروز با ممیزی جریان‌های پرخطا مانند رزرو، جست‌وجوی حساب، اقدامات تجاری ساده و تریاژ پشتیبانی، برای WebMCP آماده شوند. اولین گام، نوشتن قرارداد ابزار روی کاغذ است: تعریف نام، توضیحات، فیلدهای مورد نیاز و مشخص کردن اینکه اقدام مورد نظر «فقط خواندنی» (Read-only) است یا «تغییر وضعیت» (State-changing) ایجاد می‌کند. این تمرین اغلب فرم‌هایی را آشکار می‌کند که فقط برای انسانی که متن‌های اطراف را می‌بیند معنا دارند و برای هوش مصنوعی مبهم هستند.

برای کسانی که در نسخه Canary یا از طریق افزونه‌ها با document.modelContext آزمایش می‌کنند، دستورالعمل‌های زیر کاربردی است:

• استفاده از تشخیص قابلیت (Feature Detection): مطمئن شوید مرورگرهای پشتیبانی‌نشده واکنشی نشان نمی‌دهند و کدها باعث خطا نمی‌شوند.
• شروع کوچک: ابتدا یک ابزار اکتشافی فقط-خواندنی و سپس یک ابزار نوشتنی را پشت یک تاییدیه صریح ثبت کنید.
• حفظ طرحواره‌های سخت‌گیرانه: استفاده از فیلدهای متنی مبهم و آزاد، همان ابهامات استخراج داده را درون یک شیء JSON بازتولید می‌کند.
• یکپارچگی با کارهای موجود: آزمایش‌ها را با بهبودهای CLS و دسترسی‌پذیری (Accessibility) که در حال حاضر برای آن‌ها هزینه می‌شود، ترکیب کنید. برچسب‌های معنایی و چیدمان پایدار به انسان‌ها، فناوری‌های کمکی و عامل‌هایی که در نبود ابزار از درخت DOM پیمایش می‌کنند، کمک می‌کند.

تست و نگهداری

برای تست WebMCP در یک URL واحد بدون توقف نظارت بر CLS، دموی WebMCP را با یک بازرس (Inspector) مجهز به این پروتکل باز کنید. تعداد ابزارها را بشمارید، یکی را فراخوانی کنید، عمداً یک طرحواره را بشکنید و این مسیر را با کلیک دستی در رابط کاربری رزرو مقایسه کنید.

در گزارش به مشتریان، چک‌های Agentic Browsing را تا زمان تثبیت استانداردها «آزمایشی» برچسب بزنید. اولویت را بر نظارت مستمر روی Core Web Vitals (شامل LCP، INP و CLS) بگذارید که پیش‌بینی‌کننده واقعی رنج کاربر هستند. این دو را لایه‌بندی کنید: از ابزارهایی مثل Apogee Watcher برای تاریخچه مستمر PageSpeed استفاده کنید و ممیزی‌های WebMCP را به‌عنوان بهداشت آزمایشگاهی اختیاری در نظر بگیرید تا زمانی که پشتیبانی مرورگرها عادی شود.

گام بعدی شما

• جریان‌های حساس وب‌سایت خود (مانند فرم‌های رزرو یا خرید) را شناسایی کرده و قراردادهای ابزاری آن‌ها را روی کاغذ طراحی کنید.
• پایداری چیدمان (CLS) را در صفحات کلیدی بهبود ببخشید تا در صورت شکست ابزارها، مسیر بازگشت (Fallback) عامل‌ها با خطا مواجه نشود.
• در نسخه Canary کروم، قابلیت document.modelContext را برای ثبت اولین ابزار ساده‌ی «فقط-خواندنی» تست کنید.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.