استاندارد WebMCP وب‌سایت‌ها را به APIهای ساختاریافته برای عامل‌های هوش مصنوعی

تصور کنید یک برنامه‌نویس می‌خواهد ابزاری بسازد که رزرو پرواز را به‌طور خودکار انجام دهد، اما عامل هوش مصنوعی او مانند توریستی سردرگم است که به جای خواندن منو، سعی می‌کند با حدس زدن جای دکمه‌ها در عکس‌های صفحه، خرید کند. این فرآیند شکننده که «استفاده از مرورگر» (Browser Use) نام دارد، کند است، هزینه‌ی زیادی دارد و هر بار که چیدمان سایت حتی یک پیکسل تغییر می‌کند، با شکست مواجه می‌شود.

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

در ۲۷ سپتامبر ۲۰۲۶، جزئیات فنی یک راهکار جدید افشا شد: WebMCP قصد دارد عصر «تظاهر به انسان بودن» را به پایان برساند. طبق این مستندات، به‌جای اینکه عامل‌ها مجبور باشند کلیک‌ها و ضربات کیبورد را شبیه‌سازی کنند، WebMCP به وب‌سایت اجازه می‌دهد تا یک منوی تمیز و ترجمه‌شده از ابزارهای ساختاریافته را که عامل می‌تواند مستقیماً آن‌ها را فراخوانی کند، به او تحویل دهد.

چرا عامل‌های فعلی شکست می‌خورند؟

بیشتر عامل‌های فعلی در واقع استخراج‌کننده‌های وب (Web Scrapers) پیشرفته‌ای هستند. آن‌ها چشم یا دست ندارند، بنابراین سعی می‌کنند آن‌ها را جعل کنند. به گزارش تحلیلگران، این جعل در سه مورد خاص به کاربر ضربه می‌زند:

• کندی: هر کلیک ساده نیاز به یک رفت‌وبرگشت کامل از طریق یک مدل عظیم دارد.
• هزینه بالا: ارسال عکس‌های صفحه و کدهای HTML خام، هزاران توکن (Token) — مثل برش‌های کوچکی از متن که مدل تکه‌تکه می‌خورد — را فقط برای پیدا کردن یک کادر ورودی می‌سوزاند.
• شکنندگی: تغییر یک کلاس CSS، یک کلاس Utility تغییر یافته یا یک نام کلاس پویا (Dynamic) می‌تواند کل چرخه را بشکند. عاملی که ۹ بار درست کار می‌کند، ممکن است در بار دهم شکست بخورد.

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

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

محدودیت‌های MCP در سمت سرور

شاید اولین غریزه من به عنوان یک توسعه‌دهنده این باشد که یک سرور MCP در بک‌اِند را پیشنهاد دهم. در حالی که این سرورها برای پایگاه‌های داده و APIها عالی هستند، اما اصطکاک‌های قابل توجهی ایجاد می‌کنند:

• سربار زیرساختی: آن‌ها به کلیدهای API جداگانه، توکن‌های OAuth و پروکسی‌های پایگاه داده نیاز دارند.
• قطع ارتباط با نشست (Session): آن‌ها رابط کاربری را کاملاً نادیده می‌گیرند و نشست کاربر (که در حال حاضر لاگین کرده است) را دور می‌زنند. این موضوع می‌تواند منجر به چالش‌های امنیتی در دسترسی به داده‌های حساس شود که پیش‌تر به آن‌ها پرداخته‌ایم.
• عدم شفافیت: کاربری مانند پریانکا صفحه‌ای را می‌بیند که در آن هیچ اتفاقی نمی‌افتد و صرفاً باید «اعتماد» کند که پروازش رزرو شده است. این موضوع یک شکاف اعتماد و فقدان شفافیت ایجاد می‌کند.

سازوکار WebMCP

WebMCP یک فریم‌ورک استخراج داده، یک مدل بینایی هوشمندتر یا یک سرور بک‌اِند دیگر نیست که مجبور باشید آن را مستقر کنید و مراقبت کنید؛ بلکه یک استاندارد وب پیشنهادی است که در W3C در حال بررسی است و توسط تیم‌های Chrome و Edge توسعه می‌یابد. این استاندارد وب‌سایت را به یک API برای عامل تبدیل می‌کند، بدون اینکه رابط کاربری انسان را حذف کند.

در اصطلاحات انسانی، اگر عامل‌های امروز توریست‌هایی باشند که به منوی یک زبان خارجی اشاره می‌کنند، WebMCP به آن‌ها منویی ترجمه‌شده با قیمت‌های دقیق می‌دهد. در هسته خود، WebMCP از API navigator.modelContext برای ایجاد یک کانال ساختاریافته بین صفحه وب، محیط اجرای مرورگر (Browser Runtime) و عامل هوش مصنوعی استفاده می‌کند. این امر موارد زیر را ممکن می‌سازد:

• اجرای قطعی (Deterministic): عامل‌ها به‌جای شبیه‌سازی رویدادهای بصری، توابع جاوااسکریپت با تایپ (Type) مشخص را فراخوانی می‌کنند.
• بدون نیاز به زیرساخت: ابزارها در بستر سمت کلاینت (Client-side) در تب فعال اجرا می‌شوند و به‌طور خودکار کوکی‌های نشست لاگین شده کاربر را به ارث می‌برند. هیچ لایه احراز هویت جداگانه‌ای نیاز نیست.
• بهینگی توکن: عامل‌ها به‌جای چیدمان‌های حجیم HTML، طرح‌های JSON تمیز دریافت می‌کنند که هزینه‌ها را به‌شدت کاهش می‌دهد.

جزئیات پیاده‌سازی

توسعه‌دهندگان می‌توانند از دو مسیر اصلی برای ادغام WebMCP استفاده کنند:

۱. API توصیفی (Declarative): این روش به‌طور خودکار فرم‌های استاندارد HTML و عناصر ورودی موجود را بدون نیاز به منطق تجاری سفارشی، به بستر مدل مرورگر معرفی می‌کند. این رویکرد در واقع تکامل‌یافته‌ی روش‌های بهینه‌سازی محتوا برای شناسایی توسط عامل‌ها است که پیش از این در پلتفرم‌هایی مانند وردپرس بررسی شده بود.
۲. API امری (Imperative): این روش به توسعه‌دهندگان اجازه می‌دهد تا ابزارها را به‌طور صریح با استفاده از JSON Schemas و هندلرهای اجرای جاوااسکریپت تعریف کنند.

در محیط React، این کار شبیه ثبت یک ابزار در هوک useEffect است. توسعه‌دهنده نام ابزار، یک عنوان، توضیحات و یک inputSchema تعریف می‌کند که پارامترهای مورد نیاز را مشخص می‌کند (مثلاً itemName به عنوان رشته و quantity به عنوان عدد). سپس تابع execute همان منطقی را اجرا می‌کند که دکمه‌های واقعی وب‌سایت از قبل استفاده می‌کنند، مانند تابع addItemToState.

برای تضمین پایداری و امنیت، ثبت ابزار شامل یک پاک‌سازی چرخه عمر (Lifecycle Cleanup) با استفاده از سیگنال AbortController است تا ابزار هنگام خروج کامپوننت (Unmount) لغو ثبت شود. امنیت بیشتر از طریق یادداشت‌های (Annotations) خاص مدیریت می‌شود:

• readOnlyHint: به مدل می‌گوید که آیا یک اقدام باعث تغییر وضعیت (Mutate State) می‌شود یا خیر.
• untrustedContentHint: تضمین می‌کند داده‌های بازگشتی صرفاً به عنوان محتوا تلقی شوند و نه دستورات پرامپت، تا خطر تزریق پرامپت (Prompt Injection) از طریق خروجی ابزار کاهش یابد. این موضوع مستقیماً با چالش‌های امنیتی و مرزهای جدید پروتکل MCP در ارتباط است.

مقایسه معماری‌های عامل

وقتی WebMCP با روش‌های سنتی مقایسه می‌شود، شکاف بین عامل‌های بصری و سرورهای بدون رابط کاربری (Headless) را پر می‌کند.

WebMCP پایداری JSON ساختاریافته را با قابلیت مشاهده تب فعال مرورگر ترکیب می‌کند. این تغییر در رابط‌های پیچیده که در آن‌ها پیمایش (Navigation) یک مانع است، بیشترین قدرت را دارد.

کاربردهای واقعی

پیچیده‌ترین رابط‌های کاربری را در نظر بگیرید، مانند یک ابزار مدل‌سازی سه‌بعدی، یک ویرایشگر عکس با ۲۸ اسلایدر، یا یک داشبورد SaaS با فیلترهایی که در عمق پنج منو دفن شده‌اند. WebMCP این تجربه‌ها را متحول می‌کند:

• کانبان و مدیریت تسک: به‌جای باز کردن کارت‌ها و انتخاب از منوهای کشویی، یک عامل توابع moveCard ،setPriority و createTask را فراخوانی می‌کند. درخواستی مانند «این کارت را به بخش ساخت‌وساز منتقل کن و اولویت آن را بالا بگذار» در یک مرحله انجام می‌شود.
• داشبوردهای داده: کاربر می‌تواند بخواهد «درآمد فصلی را بر اساس کانال مقایسه کن» و عامل مستقیماً توابع رندر نمودار را بدون هیچ کلیک دستی فراخوانی می‌کند.
• مجموعه‌های خلاقانه: در یک ویرایشگر عکس، گفتن «این عکس را روشن‌تر کن» فراخوانی setExposure(+0.8) را فعال می‌کند. در یک ابزار سه‌بعدی وب، تابع add3DBlock را صدا می‌زند.

این امر منحنی یادگیری را برای افراد غیرمتخصص کاهش می‌دهد. رزرو پرواز پریانکا تبدیل به یک فراخوانی ساده book_flight می‌شد و او حتی پیش از تمام شدن چای‌اش، تاییدیه را دریافت می‌کرد.

شروع کار و تست

برای کسانی که می‌خواهند این فناوری را تست کنند، در حال حاضر از طریق فلگ chrome://flags/#enable-webmcp-testing در Chrome در دسترس است. تست‌های عملیاتی از طریق Origin Trial برای Chrome ۱۴۹+ و با پشتیبانی کتابخانه‌های آزمایشی مانند usewebmcp برای React و Angular امکان‌پذیر است.

برای عیب‌یابی (Debug)، توسعه‌دهندگان می‌توانند افزونه Model Context Tool Inspector را نصب کنند تا ابزارهای ثبت‌شده را ببینند، آن‌ها را به‌صورت دستی فراخوانی کنند و طرح‌های (Schemas) آن‌ها را اعتبارسنجی کنند. یک ابزار پایه را می‌توان در کمتر از ۱۵ خط کد با استفاده از document.modelContext.registerTool پیاده‌سازی کرد، در حالی که از همان منطقی استفاده می‌کند که دکمه «افزودن» در حال حاضر به کار می‌برد.

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

توسعه‌دهندگان باید با شناسایی ۵ تا ۱۰ اقدام تکراری که کاربران در سایت‌هایشان انجام می‌دهند و تبدیل آن‌ها به ابزارهای WebMCP شروع کنند. این رویکرد تدریجی اجازه می‌دهد تا پایداری سیستم پیش از خودکارسازی کامل جریان‌های کاری پیچیده، تست شود. منتظر نهایی شدن مشخصات navigator.modelContext توسط W3C باشید، زیرا این موضوع تعیین می‌کند که عامل‌های هوش مصنوعی تا چه حد می‌توانند بدون تکیه بر پلاگین‌های اختصاصی با وب باز تعامل داشته باشند.

گام بعدی شما

• اگر توسعه‌دهنده فرانت‌اِند هستید، ۵ تا ۱۰ اقدام تکراری کاربران در سایتتان را شناسایی و آن‌ها را به ابزارهای WebMCP تبدیل کنید.
• فلگ تست WebMCP را در کروم فعال کنید تا با نحوه تعامل مدل‌ها با DOM آشنا شوید.
• مستندات نهایی navigator.modelContext در W3C را دنبال کنید تا از استانداردهای نهایی مطلع شوید.

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