تصور کنید وبسایت شما دیگر فقط یک ویترین محتوا نیست، بلکه جعبهابزاری است که هر عامل هوش مصنوعی میتواند دقیقاً بفهمد چطور از آن استفاده کند. با انتشار نسخه ۶.۹ وردپرس (WordPress)، وبسایتها اکنون میتوانند به عنوان مجموعهای از ابزارهای ساختاریافته برای عاملها (Agents) عمل کنند.
به کمک Abilities API، توسعهدهندگان میتوانند قابلیتهای سایت — مثل ایجاد پیشنویس یا همگامسازی محصولات — را در قالبی تعریف کنند که ماشینهای خارجی بتوانند آن را درک و اجرا کنند. سالها بود که اتصال هوش مصنوعی به یک وبسایت نیازمند کدهای رابط شکننده یا دسترسیهای گسترده و خطرناک به API بود. این چارچوب جدید با ایجاد یک دفتر ثبت استاندارد، پارادایم را تغییر میدهد؛ حالا سایت بهجای اینکه اجازه دهد هوش مصنوعی حدس بزند چطور با آن تعامل کند، صراحتاً میگوید: «من این کارها را بلدم و برای انجام هر کدام، دقیقاً به این دادهها نیاز دارم».
زمینه و هدف
این API قابلیتهای سایت را هم ماشینخوان و هم قابلاجرا میکند. در واقع این سیستم شبیه به یک منوی رستوران است که هر غذا (تابع) و مواد لازم برای آن (پارامترها) را دقیقاً لیست کرده تا مشتری (هوش مصنوعی) بدون اشتباه سفارش دهد. همانطور که در تحلیلهای قبلی ما دربارهی اکوسیستم ابزارهای عاملمحور اشاره کردیم، استانداردسازی مسیر ارتباطی میان مدل و ابزار، کلید مقیاسپذیری است.
این سیستم برای اعمال طرحوارههای (Schemas) ثابت برای پارامترها و قابلکشف کردن قابلیتها برای ابزارهای اتوماسیون طراحی شده است. با استفاده از این رویکرد استاندارد، توسعهدهندگان میتوانند منطق سایت را از طریق REST در دسترس قرار دهند، بدون اینکه نیاز باشد برای هر ویژگی جدید، لایههای API کاملاً مجزا و جدیدی بسازند.
طبق مستندات developer.wordpress.org، هسته این سیستم تابع wp_register_ability() است. توسعهدهندگان با این تابع، نام، توضیحات و یک اسکیما (Schema) از نوع JSON برای پارامترها تعریف میکنند. برای مثال، قابلیت «ایجاد پیشنویس» مشخص میکند که پیش از اجرای تابع، حتماً باید «عنوان» و «محتوا» به صورت رشته متنی دریافت شوند.
جزئیات فنی
پیادهسازی فنی این قابلیت از یک گردشکار مشخص پیروی میکند:
- ثبت: قابلیتها به
wp_abilities_api_init(و هر قلاب ثبت دستهبندی دیگر) متصل میشوند تا برای آداپتورهایی که آنها را به عاملها معرفی میکنند، قابل کشف باشند. - نمایش: با فعال کردن
show_in_restبه مقدار true، نقاط انتهایی REST بهطور خودکار ایجاد شده و قابلیت از طریق مسیرهای REST مربوط به Abilities قابل شناسایی میشود. - اجرا: این API از مدل احراز هویت و مجوزهای موجود در وردپرس استفاده میکند تا دسترسیها را در محدودترین سطح ممکن (Least-privilege) اعمال کند.
برای پر کردن شکاف میان این قابلیتها و مدلهای زبانی بزرگ (LLM) — که مثل کتابخانهداری هستند که میلیاردها صفحه را خوانده و حالا با همان لحن جواب میدهد — از آداپتور MCP وردپرس استفاده میشود. این آداپتور، قابلیتهای ثبتشده را به ابزارهایی تبدیل میکند که چارچوبهای عاملمحور بتوانند مصرف کنند. در واقع، انتخاب میان این معماری و روشهای سنتی، مشابه مقایسهای است که پیشتر میان MCP و REST برای بهینهسازی عاملهای سئو داشتیم. به این ترتیب، یک عامل هوش مصنوعی لیست توابع موجود را میبیند و بدون دخالت انسان، آنها را با پارامترهای درست فراخوانی میکند.
این تغییر، نگاه ما به توسعه سیستمهای مدیریت محتوا را دگرگون میکند. ما از دنیای «اول رابط کاربری» (UI-first) که در آن انسان روی دکمهای کلیک میکند، به دنیای «اول API» (API-first) میرویم که در آن یک عامل، عملیاتی محدود و هدفمند را تحریک میکند. با تعریف قابلیتهای کوچک و تخصصی، توسعهدهندگان از ریسک امنیتی دادن دسترسی کامل مدیریت (Admin) به هوش مصنوعی میگریزند.
ارزش تجاری و امنیت
برای مالکان کسبوکار، این یعنی کاهش اصطکاک در ادغام با سرویسهای شخص ثالث. شرکای تجاری دیگر نیازی به مهندسی پیچیده برای خودکارسازی وظایف ندارند و فقط کافی است از Abilities API بپرسند چه کارهایی ممکن است. این اتفاق، وبسایت را از یک مخزن محتوای ایستا به یک ارائهدهنده خدمات فعال تبدیل میکند.
هنگام ترویج این ادغامها، مخاطبان مختلف به تمرکزهای متفاوتی نیاز دارند:
- مخاطبان فنی (GitHub/DEV.to): تمرکز باید روی نمونه کدهای واقعی، مخازن افزونههای مینیمال و فایلهای README باشد که نحوه ثبت، اعتبارسنجی پارامترها و پاسخهای JSON مورد انتظار را نمایش دهند.
- مخاطبان تجاری (LinkedIn): باید بر ارزش تجاری سایتهای قابل اتوماسیون، ادغامهای تفویضشدهی امن و کاهش اصطکاک برای شرکای تجاری تأکید شود.
تعاملات باید از طریق تحلیلهای گیتهاب، معیارهای DEV.to و برچسبگذاری CRM برای سرنخهایی (Leads) که از پیامهای لینکدین یا درخواستهای دمو میآیند، ردیابی شود.
با این حال، امنیت همچنان اولویت اول است. هر قابلیتی که عملیات «نوشتن» (Write) انجام میدهد — مثل حذف پست یا تغییر تنظیمات — باید حساس تلقی شود و نیاز به تایید صریح (Opt-in) داشته باشد. بر اساس توصیههای فنی، ثبت هر اجرا به همراه هویت اجراکننده، نام قابلیت و پارامترها برای ایجاد یک ردپای حسابرسی (Audit Trail) کامل از تغییرات ایجاد شده توسط هوش مصنوعی ضروری است.
گام بعدی شما
- توسعهدهندگان باید با ساخت یک افزونه ساده شامل یک قابلیت «خواندنی» و یک قابلیت «نوشتنی»، جریان کشف ابزارها را تست کنند.
- بررسی تستهای واحد (Unit Tests) و تستهای یکپارچگی (Integration Tests) برای توابع بازگشتی (Callbacks) پیش از باز کردن دسترسی برای عاملهای خارجی حیاتی است.
- رشد اکوسیستم آداپتورهای MCP را دنبال کنید، زیرا احتمالاً در سال ۲۰۲۶ به دروازه اصلی مدیریت محتوای وب توسط عاملهای خودمختار تبدیل خواهد شد.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو