تصور کنید مدیر فنی شرکتی هستید که ابزارهای هوش مصنوعیاش بین گوگل، مایکروسافت و آمازون پخش شدهاند و حالا برای پیدا کردن یک ابزار ساده، باید سه فهرست مختلف را چک کنید. آمازون وب سرویسز (AWS) قصد دارد با یک تغییر ساختاری، این دیوارهای نامرئی را فرو بریزد.
طبق اعلام این شرکت در ۲۴ اوت ۲۰۲۶، AWS مشخصات استاندارد کشف منابع عاملمحور (Agentic Resource Discovery یا ARD) را در اکوسیستم مدیریت عاملهای خود ادغام میکند. در حال حاضر، اکثر سازمانهای بزرگ از استراتژی چندابری استفاده میکنند؛ یعنی عاملها، ابزارها و مهارتهای آنها روی سرورهای مختلف، محیطهای On-premises و پلتفرمهای مختلف SaaS پراکنده است. هر یک از این محیطها معمولاً رجیستری و فرمت متادیتای خاص خود را دارند و تا پیش از این، متصل کردن این محیطها به یکدیگر نیازمند ساخت رابطهای سفارشی، گرانقیمت و اختصاصی برای هر جفت از رجیستریها بود.
این استاندارد جدید شبیه به سیستم DNS در اینترنت عمل میکند — یعنی به جای داشتن یک لیست بسته و محرمانه، اجازه میدهد کاتالوگهای مختلف با یک زبان مشترک با هم حرف بزنند. به این ترتیب، یک توسعهدهنده میتواند یک عامل (Agent) — شبیه به کارمندی دیجیتال که میتواند کارهای خاصی را به طور مستقل انجام دهد — را یکبار توصیف کند و آن عامل در هر محیطی، فارغ از محل میزبانی، قابل شناسایی باشد.
همانطور که در تحلیلهای قبلی ما دربارهی پروتکلهای ارتباطی مدلها اشاره کردیم، هدف نهایی رسیدن به یک لایه ارتباطی واحد است. این رویکرد در واقع تکامل همان جایگزینی پرامپتهای ساده با جریانهای کاری عاملمحور است که برای حل پیچیدگیهای عملیاتی در مقیاس سازمانی طراحی شده است. AWS این قابلیت را از طریق Amazon Bedrock AgentCore پیادهسازی میکند که کاتالوگی از عاملها، سرورهای MCP و منابع سفارشی را مدیریت میکند. این سامانه بر دو رکن اصلی استوار است:
- رجیستریها (Registries): کاتالوگهایی که توسط مدیران با تنظیمات دسترسی و تأیید خاص ایجاد میشوند.
- رکوردها (Records): ورودیهای متادیتایی که هر منبع را به صورت مجزا توصیف میکنند.
بر اساس مستندات AWS، جریان انتشار این منابع به صورت یک خط لوله (Pipeline) ساختاریافته است که از مدیر (Administrator) به ناشر (Publisher)، سپس به کیوریتور (Curator) و در نهایت به مصرفکننده (Consumer) میرسد. پیش از آنکه هر رکورد برای دیگران قابل کشف شود، یک دروازه تأیید (Approval Gate) وجود دارد تا حاکمیت و نظارت بر منابع تضمین شود.
دسترسی به این منابع به شدت توسط مدیریت هویت و دسترسی (IAM) یا توکنهای JSON Web Tokens (JWT) از طریق یک ارائهدهنده هویت سازمانی کنترل میشود. این رجیستری به عنوان یک نقطه اتصال از راه دور پروتکل زمینهٔ مدل (MCP) — شبیه به یک مترجم جهانی که اجازه میدهد مدلهای مختلف با ابزارهای مختلف صحبت کنند — در دسترس است و به هر کلاینت سازگار با MCP اجازه میدهد مستقیماً در آن جستوجو کند. این قابلیتها در کنار امکانات جدید جستوجوی وب در سرویس بدراک قرار میگیرند تا عاملها بتوانند هم از منابع داخلی سازمان و هم از دادههای زنده وب برای تصمیمگیری استفاده کنند.
نکته کلیدی این است که AWS لایه حاکمیتی خود را با دقت حفظ کرده است. ARD به عنوان یک لایه interoperability (تبادلپذیری) عمل میکند که خارج از نقطه اجرای دسترسیها قرار دارد. سازمان ناشر کاتالوگ همچنان کنترل میکند که چه چیزی در داخل باشد، چه کسی بتواند آن را ببیند و چه زمانی دسترسی لغو شود. در واقع ARD مسئول یافتن منابع است، نه اعطای اعتماد برای ورود آنها به محیط عملیاتی (Production).
به گزارش منابع صنعتی، ARD پروژه اختصاصی آمازون نیست. این استاندارد در ۱۷ ژوئن ۲۰۲۶ توسط گروه کاری متشکل از گوگل، مایکروسافت، Hugging Face و GoDaddy معرفی شد. شرکتهای بزرگی دیگر مانند سیسکو، دیتابریکس، گیتهاب، انویدیا، سِیلزفورس، سرویسنو و اسنوفلیک نیز در زمان عرضه با این پروژه همکاری کردند. این مشخصات تحت لایسنس Apache 2.0 منتشر شده و در وبسایت agenticresourcediscovery.org در دسترس است و پیادهسازیهای مرجع آن در گیتهاب موجود است.
معماری ARD از دو ابزار اصلی برای تضمین اعتماد و کشف استفاده میکند:
- کاتالوگها: فایلی به نام
ai-catalog.jsonکه در یک مسیر شناختهشده روی دامنه سازمان منتشر میشود. این فایل عاملهای موجود، سرورهای MCP، عاملهای A2A، ابزارهای OpenAPI یا کاتالوگهای تودرتو را توصیف میکند. مالکیت دامنه در اینجا به عنوان مدرک رمزنگاریشده برای تأیید هویت ناشر عمل میکند. - رجیستریها: موتورهای جستوجویی که این کاتالوگها را میخزند و به درخواستهای زبان طبیعی پاسخ میدهند و نتایج را به همراه متادیتای اعتماد قابل تأیید برمیگردانند تا کلاینت پیش از اتصال، هویت ناشر را تأیید کند.
بسیار مهم است که بدانیم ARD مدیریت «کشف» را بر عهده دارد، نه «اجرا». این استاندارد یک runtime یا کاتالوگ مرکزی نیست و جایگزینی برای پروتکل A2A یا MCP محسوب نمیشود. هنگامی که یک کلاینت منبعی را از طریق ARD پیدا میکند، آن منبع را با استفاده از مکانیسم بومی خودش (مانند API، فریمورک عامل یا MCP) فراخوانی میکند. این ساختار اجازه میدهد تا ابزارهای تخصصی، مانند عاملهای DevOps آمازون در تحلیل RCA، به راحتی در یک محیط فدراسیون شناسایی و فراخوانی شوند.
این همسویی نشاندهنده لحظه نادری از توافق بین سه غول ابری است. گوگل نیز در حال حاضر برنامهریزی کرده است تا در ماههای آینده پشتیبانی بومی از ARD را به پلتفرم Gemini Enterprise Agent اضافه کند.
برای کاربر تجاری، این یعنی «اتحاد بدون مهاجرت» (Federation without migration). سازمانی که زیرساختهای عاملمحور آن بین ابرهای مختلف، سیستمهای داخلی و ابزارهای SaaS پخش شده است، میتواند همه آنها را در فرمت ARD نمایش دهد. این کار باعث میشود ابزارها در محیطهای مختلف قابل شناسایی شوند در حالی که کنترل آنها محلی باقی میماند. همچنین مسیرهایی برای همکاریهای بینسازمانی باز میکند که یک رجیستری تکفروش (Single-vendor) هرگز نمیتوانست به آنها دست یابد.
با این حال، باید توجه داشت که این ادغام فعلاً در جهتگیریهای اولیه است. AWS تاریخ دقیقی برای عرضه نهایی اعلام نکرده و Agent Registry همچنان در مرحله پیشنمایش (Preview) است. اما آنچه تثبیت شده، یک نقشه راه مشترک است: بزرگترین ارائهدهندگان ابری اکنون در حال ساخت یک پروتکل فدراسیون باز هستند.
منتظر انتشار کلاینتهای سازگار با ARD از سوی GitHub و Hugging Face باشید؛ زیرا اینها احتمالاً اولین ابزارهایی خواهند بود که شناسایی متقاطع عاملها در سطح سازمانهای مختلف را ممکن میکنند.
گام بعدی شما
- اگر از زیرساختهای چندابری استفاده میکنید، مستندات
agenticresourcediscovery.orgرا بررسی کنید تا با ساختار فایل JSON کاتالوگها آشنا شوید. - منتظر انتشار کلاینتهای سازگار با ARD از سوی GitHub و Hugging Face باشید؛ اینها اولین ابزارهایی خواهند بود که شناسایی متقاطع عاملها را ممکن میکنند.
- استراتژی مدیریت دسترسی (IAM) خود را برای پذیرش توکنهای JWT در سطح فدراسیون بازبینی کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو