اگر امروز در حال ساخت عامل‌های هوش مصنوعی هستید، احتمالاً آدرس ابزارها را به‌صورت دستی در فایل‌های تنظیمات می‌نویسید یا تمام توضیحات ابزارها را در پنجره متنی مدل می‌ریزید. این مدل «اول نصب، بعد استفاده» در مقیاس واقعی شکست می‌خورد و باعث کندی یا خطای مدل می‌شود.
در ۱۷ ژوئن ۲۰۲۶، شرکت Hugging Face برای رفع این گلوگاه، پیاده‌سازی مرجع خود از مشخصات Agentic Resource Discovery (ARD) را منتشر کرد. طبق اعلام این شرکت، هدف ARD حذف نیاز به پیکربندی دستی ابزارها پیش از اجراست.
بسیاری از چارچوب‌های فعلی بر سه پروتکل اصلی تکیه دارند: MCP برای فراخوانی ابزار، Skills برای دستورالعمل‌ها و A2A برای ارتباط بین عامل‌ها. اما همه‌ی این‌ها فرض می‌کنند کاربر دقیقاً می‌داند به چه قابلیتی نیاز دارد. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی اکوسیستم ابزارهای هوش مصنوعی اشاره کردیم، بار اکتشاف و نگهداری ابزارها هنوز بر دوش برنامه‌نویس است، نه خودِ هوش مصنوعی.
ARD یک لایه‌ی اکتشافی ایجاد می‌کند که پیش از این پروتکل‌ها قرار می‌گیرد. این استاندارد توسط ائتلافی شامل Microsoft، Google، GoDaddy و Hugging Face توسعه یافته است و مشارکت گسترده‌ای در سطح صنعت دارد. حالا عامل‌ها می‌توانند در لحظه‌ی اجرا (Runtime) — یعنی همان لحظه‌ای که مدل واقعاً جواب تولید می‌کند و شبیه به خودِ آشپزی است، نه دوره‌ی آموزش آشپز — با استفاده از زبان طبیعی در دفاتر ثبت فدرال جستجو کنند تا دقیق‌ترین ابزار را برای یک تکلیف خاص بیابند.
مشکل اکتشاف ابزارها
یکپارچه‌سازی سنتی عامل‌ها ایستا است. توسعه‌دهندگان معمولاً یک سرویس را از طریق پلاگین متصل می‌کنند و دوباره از آن استفاده می‌کنند؛ این روش برای چند ابزار روزمره جواب می‌دهد اما وقتی با هزاران سطح دسترسی مختلف و موردی (Ad-hoc) روبرو می‌شویم، ناکارآمد است. وقتی توسعه‌دهندگان سعی می‌کنند با ریختن تمام توضیحات ابزارها در پنجره متنی (Context Window) — که مثل میز کاری است و فقط جای چند ورق دارد، نه کل کتابخانه — این مشکل را دور بزنند، با محدودیت بودجه‌ی توکن‌ها مواجه می‌شوند. حتی استراتژی‌های مبتنی بر جستجو نیز اغلب شکست می‌خورند، زیرا توضیحات ابزارها برای تشخیص دقیق و رفع ابهام بیش از حد کوتاه هستند.
ARD فرآیند انتخاب را به بیرون از مدل زبانی بزرگ (LLM) — مثل کتابخانه‌داری که میلیاردها صفحه را خوانده و حالا با همان لحن جواب می‌دهد — منتقل می‌کند. یک دفتر ثبت (Registry)، قابلیت‌ها را با سیگنال‌های غنی فهرست‌بندی می‌کند؛ این سیگنال‌ها مواردی چون هویت ناشر، پرس‌وجوهای نمونه، گواهی‌های انطباق (Compliance Attestations) و تگ‌ها را شامل می‌شوند. این تغییر باعث می‌شود گردش کار از کاتالوگ‌های ایستای دستی به جستجوی مبتنی بر قصد (Intent-based) تغییر کند. این سازوکار به عامل‌ها اجازه می‌دهد به‌طور پویا به اکوسیستم رو به رشدی از ابزارهای MCP، عامل‌های A2A و سایر سرویس‌ها دسترسی پیدا کنند، بدون اینکه نیاز باشد هر یک را پیش از اجرا پیکربندی کنند.
بر اساس مستندات فنی Hugging Face، استاندارد ARD دو مکانیزم اصلی دارد:
- ai-catalog.json: یک فرمت مانیفست ایستا که به ناشران اجازه می‌دهد قابلیت‌های خود را در یک URL شناخته‌شده (Well-known) میزبانی کنند.
- POST /search: یک API پویا برای دفتر ثبت که اکتشاف رتبه‌بندی‌شده و زنده را فراهم می‌کند.
ابزار Hugging Face Discover به عنوان پیاده‌سازی مرجع عمل می‌کند. این ابزار از جستجوی معنایی موجود در Hub برای Spaces استفاده کرده و نتایج را به ورودی‌های کاتالوگ ARD تبدیل می‌کند. این سازوکار اجازه می‌دهد هزاران مهارت، اپلیکیشن ML و سرورهای MCP در کل اکوسیستم شناسایی شوند.
جزئیات پیاده‌سازی
سرویس Discover با ترکیب جستجوی معنایی روی Spaces و مهارت‌های عامل عمل می‌کند. جستجوی Hub از پرچم agents=true پشتیبانی می‌کند که Spaces را بر اساس متادیتای عامل-محور رتبه‌بندی می‌کند. سپس تبدیل‌گر Discover نتایج را با دو فیلتر اصلی به استاندارد ARD می‌برد:
- وضعیت اجرا (Runtime Status): پاسخ‌ها فقط شامل Spacesی هستند که وضعیت اجرای آن‌ها در حال حاضر "RUNNING" است.
- نوع رسانه (Media Type): پاسخ‌ها بر اساس درخواست در سه نوع ارائه می‌شوند:
application/ai-skill: نوع پیش‌فرض است. این مورد یک فایلSKILL.mdتولید می‌کند که فایلagents.mdمربوط به آن Space را در بر می‌گیرد.application/mcp-server+json: یک ورودی کاتالوگ مخصوص سرورهای MCP برای Spacesی است که تگmcp-serverدارند.application/vnd.huggingface.space+json: متادیتای خام Space برای کلاینت‌هایی که ترجیح می‌دهند خودشان آن را مدیریت کنند.
برای مهارت‌ها، سیستم فایل agents.md را از یک Space می‌خواند و آن را با اطلاعات لازم (Frontmatter) می‌پوشاند. این اطلاعات شامل نام، توضیحات و متادیتای منبع است که ID فضای کار، URL هاب، URL اپلیکیشن و URL اصلی فایل agents.md را پوشش می‌دهد. این کار تضمین می‌کند هر کلاینتِ مهارت-آگاه بتواند آن را از طریق یک جریان عادی بارگذاری کند.
در مورد سرورهای MCP، تبدیل‌گر یک ورودی کاتالوگ ایجاد می‌کند که به نقطه انتهایی (Endpoint) Gradio MCP روی پروتکل انتقال HTTP اشاره دارد. این URL از دامنه‌ی اجرای Space استفاده می‌کند (اگر توسط Hub ارائه شده باشد)؛ در غیر این صورت، از قرارداد استاندارد slug با پسوند .hf.space پیروی می‌کند.
توسعه‌دهندگان می‌توانند از طریق Hugging Face CLI (hf) به این قابلیت‌ها دسترسی داشته باشند. برای شروع، کاربران می‌توانند ابزار را با دستور uv tool install huggingface_hub نصب کنند. نمونه‌های استفاده عبارتند از:
- جستجوی منابع آموزش:
hf discover search "Fine tune a language model" - یافتن سرورهای تولید تصویر:
hf discover search "Generate an image" --json --kind mcp - پرس‌وجو از دفاتر ثبت خارجی:
hf discover search "Purchase aeroplane tickets" --registry-url <catalog-url>
کاتالوگ به‌صورت عمومی در آدرس https://huggingface.co/.well-known/ai-catalog.json در دسترس است.
API و یکپارچگی با MCP
کاربران می‌توانند مستقیماً از طریق درخواست‌های POST به آدرس https://huggingface-hf-discover.hf.space/search با API جستجو ارتباط برقرار کنند. برای مثال، یک درخواست curl می‌تواند برای یافتن ابزار تنظیم دقیق (Fine-tuning) مدل‌های Sentence Transformer، فیلتر application/ai-skill را اعمال کند، یا برای یافتن سرورهای تبدیل صوت به متن، فیلتر application/mcp-server-card+json را به کار بببرد.
از سوی دیگر، هر کلاینت MCP می‌تواند برای جستجو در کاتالوگ به نقطه انتهایی https://huggingface-hf-discover.hf.space/mcp متصل شود. این کار فرآیند اکتشاف را کاملاً در چرخه حیات فراخوانی ابزار ادغام می‌کند.
این تغییر بنیادین، گردش کار عامل‌ها را با جداسازی «اکتشاف» از «اجرا» متحول می‌کند. با انتقال انتخاب ابزار به بیرون از پنجره متنی LLM و سپردن آن به یک دفتر ثبت مبتنی بر REST، عامل‌ها بدون حجیم کردن پرامپت، به اکوسیستم رو به رشدی از ابزارها دسترسی دارند. استفاده از استاندارد HTTP REST به این معناست که هر کلاینتی می‌تواند بین دفاتر ثبت مختلف ارتباط برقرار کند (Federation). به دلیل اینکه فدراسیون در خودِ پروتکل تعبیه شده است، جستجو در یک سرویس می‌تواند قابلیت‌هایی را که در سرویس دیگری میزبانی شده‌اند، شناسایی کند.
برای توسعه‌دهنده، این یعنی پایان نگهداری از لیست‌های عظیم و ایستای تعاریف ابزار. دیگر نیازی نیست پیش‌بینی کنید عامل به چه ابزاری نیاز دارد؛ فقط کافی است راه جستجو در دفتر ثبت ARD را به او نشان دهید. این مدل، اکتساب قابلیت‌ها را به صورت «به‌موقع» (Just-in-time) و سیال می‌کند.
در ادامه، منتظر یکپارچگی عمیق‌تر با حالت‌های فدراسیون مشخصات (auto, referrals, none) و عرضه پشتیبانی از ai-catalog.json ایستا در پروفایل‌های شخصی کاربران و سازمان‌ها باشید. این امر به هر ناشر Space اجازه می‌دهد تا ابزارهای خود را از طریق مکانیسم استاندارد URI تبلیغ کند و اکوسیستم عامل‌ها را بیش از پیش غیرمتمرکز نماید.
گام بعدی شما
- اگر از Hugging Face Hub استفاده می‌کنید، ابزار
hf discoverرا نصب کنید تا سرعت یافتن مهارت‌های آماده را افزایش دهید. - در پروژه‌های خود، به جای Hardcode کردن ابزارها، از API جستجوی ARD برای ایجاد عامل‌های منعطف‌تر استفاده کنید.
- منتظر به‌روزرسانی‌های مربوط به حالت‌های فدرال (auto, referrals) و پشتیبانی از
ai-catalog.jsonدر پروفایل‌های شخصی باشید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو