Agent Name Service (ANS) چیست؟ نحوه عملکرد، کاربردها و تفاوت آن با DNS

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

Agent Name Service (ANS) تلاشی برای پاسخ به این نیاز است. این طرح با استفاده از زیرساخت نام‌گذاری اینترنت، به دنبال ایجاد روشی استاندارد برای شناسایی هویت ایجنت‌ها، بررسی اطلاعات ثبت‌شده درباره آن‌ها و تسهیل کشف ایجنت‌های قابل اعتماد است.

ANS در سال ۲۰۲۵ در قالب یک طرح پژوهشی برای ایجاد یک فهرست مشترک از ایجنت‌های هوش مصنوعی مطرح شد. در ژوئن ۲۰۲۶ نیز بنیاد لینوکس از برنامه خود برای توسعه یک استاندارد باز با همین نام خبر داد. نسخه مرتبط با این تلاش، با عنوان ANS v2، بر پیوند دادن هویت ایجنت به دامنه، گواهینامه‌های دیجیتال و سوابق رمزنگاری‌شده تغییرات تمرکز دارد. با این حال، این فناوری هنوز به یک استاندارد نهایی و فراگیر تبدیل نشده است.

برای درک درست ANS باید میان سه موضوع تفاوت قائل شد: پیدا کردن ایجنت، بررسی هویت آن و برقراری ارتباط با آن. این فناوری به‌ویژه در دو مورد نخست نقش دارد، اما به‌تنهایی جایگزین پروتکل‌های ارتباطی یا راهکارهای امنیتی دیگر نمی‌شود.

چرا به Agent Name Service نیاز داریم؟

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

برای مثال، یک سامانه خودکار مدیریت سفارش را در نظر بگیرید. این سامانه برای بررسی یک سفارش به ایجنتی نیاز دارد که اطلاعات تامین‌کننده را ارزیابی کند، از ایجنت دیگری برای تحلیل فاکتور کمک بگیرد و در نهایت نتیجه را به ایجنت مسئول ثبت اطلاعات مالی تحویل دهد.

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

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

ANS برای پاسخ به همین نیاز شکل گرفته است: ایجاد سازوکاری که نام ایجنت را به اطلاعات هویتی قابل بررسی پیوند دهد و امکان تشخیص تغییرات مهم را فراهم کند.

البته کشف ایجنت و اعتماد به آن دو مسئله جداگانه هستند. یک سرویس کشف می‌تواند ایجنت‌های مناسب برای یک وظیفه را پیدا کند؛ اما تایید هویت باید مشخص کند ایجنت پیدا‌شده واقعا با هویت ثبت‌شده خود مطابقت دارد یا خیر. در یک معماری امن، هر دو مرحله اهمیت دارند.

Agent Name Service چگونه کار می‌کند؟

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

این معماری از چند بخش تشکیل شده است: مرجع ثبت که فرایند معرفی و اعتبارسنجی ایجنت را مدیریت می‌کند، زیرساخت DNS که در انتشار برخی اطلاعات نقش دارد، گواهینامه‌هایی که برای بررسی هویت استفاده می‌شوند و گزارش تغییرناپذیر رویدادها که سابقه ثبت را نگهداری می‌کند.

ثبت ایجنت و ایجاد هویت قابل بررسی

فرایند با ثبت اطلاعات ایجنت توسط توسعه‌دهنده یا بهره‌بردار آن آغاز می‌شود. در معماری موردبحث، مرجع ثبت یا Registration Authority باید ابتدا کنترل دامنه مربوط را بررسی کند. یکی از سازوکارهای مورد استفاده برای این کار، ACME است که می‌تواند کنترل یک دامنه را از طریق چالش‌های اعتبارسنجی اثبات کند.

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

برای مثال، نامی مانند ans://v1.0.0.my-agent.example.com را در نظر بگیرید. این نام نشان می‌دهد که هویت موردنظر به نسخه مشخصی از ایجنتی با نام زیر دامنه مربوط است. بنابراین، نام ایجنت فقط یک برچسب برای یافتن سرویس نیست؛ نسخه نیز بخشی از هویت ثبت‌شده آن به شمار می‌رود.

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

پیدا کردن ایجنت و دریافت اطلاعات آن

پس از ثبت ایجنت، اطلاعات لازم برای شناسایی آن منتشر می‌شوند. DNS در این مرحله می‌تواند نام و اطلاعات مرتبط را در دسترس کلاینت قرار دهد تا مشخص شود برای بررسی هویت یا برقراری ارتباط باید از کجا شروع کند.

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

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

نکته مهم این است که نباید ANS را به‌طور خودکار یک موتور جست‌وجوی معنایی برای ایجنت‌ها در نظر گرفت. در معماری v2، سرویس کشف می‌تواند مولفه‌ای مستقل باشد که اطلاعات ایجنت‌های ثبت‌شده را نمایه‌سازی می‌کند. جست‌وجو بر اساس وظیفه، به ساختار فراداده‌ها و قابلیت‌های این سرویس نیز بستگی دارد.

بررسی هویت و ارتباط با مقصد

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

ANS v2 برای ثبت رویدادها از یک گزارش شفافیت یا Transparency Log استفاده می‌کند. این گزارش به‌صورت یک ساختار رمزنگاری‌شده و افزایشی طراحی شده است؛ یعنی رویدادهای ثبت‌شده باید به‌گونه‌ای نگهداری شوند که تغییر یا حذف پنهانی سوابق قبلی قابل تشخیص باشد. رسیدهای رمزنگاری‌شده نیز می‌توانند شواهدی برای بررسی وضعیت را در اختیار کلاینت قرار دهند.

پس از بررسی‌های لازم، کلاینت می‌تواند بر اساس سیاست امنیتی خود درباره برقراری ارتباط تصمیم بگیرد. برای انتقال پیام، فراخوانی ابزار یا تبادل اطلاعات، همچنان به یک پروتکل ارتباطی سازگار نیاز است. بنابراین، ANS به‌خودی‌خود وظیفه تمام پروتکل‌های ارتباط میان ایجنت‌ها را بر عهده نمی‌گیرد.

مدیریت نسخه‌ها و تغییرات

هویت یک ایجنت ممکن است در طول زمان تغییر کند. برای مثال، توسعه‌دهنده نسخه جدیدی منتشر کند، نشانی سرویس عوض شود یا ایجنت از دسترس خارج شود. اگر این تغییرات به‌درستی ثبت نشوند، سیستم‌های دیگر ممکن است به اطلاعات قدیمی متکی بمانند.

در ANS v2، ثبت رویدادهای چرخه عمر ایجنت برای قابل بررسی کردن این تغییرات در نظر گرفته شده است. ثبت نسخه جدید، تغییر وضعیت و لغو ثبت می‌توانند در سابقه ایجنت منعکس شوند. این سوابق به کلاینت کمک می‌کنند اطلاعات فعلی را با وضعیت ثبت‌شده قبلی مقایسه کند.

البته وجود سابقه رمزنگاری‌شده به معنی اطلاع‌رسانی فوری به همه کلاینت‌ها نیست. کش DNS، زمان اعتبار رکوردها، وضعیت دسترس‌پذیری زیرساخت و سیاست‌های به‌روزرسانی همچنان بر سرعت انتشار تغییرات تاثیر می‌گذارند.

چه اطلاعاتی در ANS نگهداری می‌شود؟

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

مهم‌ترین دسته‌های اطلاعاتی عبارت‌اند از:

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

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

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

تفاوت Agent Name Service و DNS چیست؟

DNS یا سامانه نام دامنه، زیرساختی است که امکان بازیابی اطلاعات مرتبط با نام‌های دامنه را فراهم می‌کند. این سامانه تنها برای تبدیل نام دامنه به نشانی IP به کار نمی‌رود؛ رکوردهای مختلف آن می‌توانند اطلاعات مربوط به سرور ایمیل، سرویس‌های شبکه و سایر داده‌های تعریف‌شده در استاندارد DNS را نیز منتشر کنند.

ANS از این زیرساخت استفاده می‌کند، اما هدف آن گسترده‌تر از بازیابی یک رکورد شبکه است.

تفاوت در هدف و نوع اطلاعات

DNS پاسخ می‌دهد که برای یک نام دامنه، چه رکوردهایی ثبت شده‌اند. برای مثال، رکورد A می‌تواند نشانی IPv4 یک میزبان را مشخص کند. با دریافت این رکورد، کلاینت می‌تواند مقصد شبکه را پیدا کند؛ اما این پاسخ به‌تنهایی اطلاعاتی درباره نسخه نرم‌افزار اجراشده روی سرور یا هویت یک ایجنت مشخص ارائه نمی‌دهد.

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

بنابراین، تفاوت اصلی این دو در این نیست که DNS فقط نام را به IP تبدیل می‌کند و ANS همه اطلاعات ایجنت را می‌شناسد؛ تفاوت در هدف و لایه‌ای است که هر کدام پوشش می‌دهند.

آیا ANS می‌تواند جایگزین DNS شود؟

خیر. در طرح ANS v2، مفهوم DNS بخشی از زیرساخت مورد استفاده برای انتشار اطلاعات است. ANS به‌جای ایجاد یک سامانه نام‌گذاری کاملا مستقل، تلاش می‌کند هویت و سوابق ایجنت‌ها را با زیرساخت موجود مرتبط کند.

این دو نقش مکمل دارند: DNS اطلاعات نام‌گذاری را در دسترس قرار می‌دهد و ANS لایه‌ای برای شناسایی نسخه‌دار و بررسی هویت ایجنت فراهم می‌کند. البته DNS به‌تنهایی تضمین نمی‌کند که اطلاعات ثبت‌شده صحیح یا ایجنت قابل اعتماد باشد؛ همان‌طور که ANS نیز جایگزین بررسی امنیت سرویس و مجوزهای دسترسی نمی‌شود.

در کنار ANS، پروژه دیگری به نام DNS-AID نیز با هدف تسهیل کشف ایجنت‌ها از طریق DNS توسعه یافته است. تمرکز DNS-AID بر انتشار و یافتن نقطه دسترسی ایجنت‌ها و سرویس‌های MCP با استفاده از رکوردهای استاندارد DNS است. در مقابل، ANS v2 بیشتر بر هویت نسخه‌دار، گواهینامه‌ها و سابقه تغییرات قابل بررسی تمرکز می‌کند. این دو رویکرد می‌توانند در کنار یکدیگر به کار گرفته شوند، اما یک فناوری با دو نام متفاوت نیستند.

کاربردهای ANS در سیستم‌های هوش مصنوعی

ارزش ANS زمانی بیشتر نمایان می‌شود که شناسایی ایجنت‌ها از یک فهرست داخلی ساده فراتر برود و تعامل میان سامانه‌های مستقل اهمیت پیدا کند.

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

در محیط‌های توزیع‌شده نیز ANS می‌تواند مدیریت هویت ایجنت‌ها را با وجود تغییر نسخه‌ها و نقاط دسترسی ساده‌تر کند. وقتی یک سازمان چند ایجنت را روی زیرساخت‌های متفاوت اجرا می‌کند، پیوند دادن هویت به یک نام نسخه‌دار و ثبت تغییرات می‌تواند از اتکا به اطلاعات ثابت و دستی بکاهد.

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

نکته مهم این است که ANS کیفیت کار یک ایجنت را تضمین نمی‌کند. حتی اگر هویت یک ایجنت به‌درستی تایید شود، ممکن است پاسخ اشتباه بدهد، وظیفه موردنظر را به‌خوبی انجام ندهد یا رفتار ناخواسته‌ای از خود نشان دهد. برای ارزیابی کیفیت و رفتار ایجنت به سازوکارهای جداگانه نیاز است.

محدودیت‌ها و ملاحظات امنیتی ANS

یکی از مزایای ANS، فراهم کردن شواهدی برای بررسی هویت و تغییرات ایجنت است؛ اما این مزیت به معنای حذف ریسک‌های امنیتی نیست.

در درجه اول، اعتماد به مرجع ثبت اهمیت دارد. این مرجع باید بتواند کنترل دامنه را به‌درستی تایید کند، گواهینامه‌ها را طبق سیاست مشخص صادر کند و رویدادهای ثبت‌شده را به گزارش شفافیت تحویل دهد. اگر مرجع ثبت یا کلیدهای مورد استفاده برای امضای سوابق به خطر بیفتند، اعتبار بخش مهمی از اطلاعات زیر سوال می‌رود.

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

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

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

ارتباط ANS با A2A و MCP چیست؟

ANS جایگزین پروتکل‌های تعامل میان ایجنت‌ها نیست. برای درک جایگاه آن، باید تفاوت میان معرفی ایجنت، شناسایی هویت و ارتباط با سرویس را در نظر گرفت.

پروتکل A2A برای تعامل میان ایجنت‌ها طراحی شده است. این پروتکل از سندی به نام Agent Card استفاده می‌کند که اطلاعاتی مانند نام، توضیحات، قابلیت‌ها، مهارت‌ها و نشانی سرویس را در اختیار کلاینت قرار می‌دهد. چنین سندی به کلاینت کمک می‌کند بفهمد ایجنت چه کاری انجام می‌دهد و چگونه باید با آن تعامل کند. اما وجود Agent Card به‌تنهایی به معنی تایید رمزنگاری‌شده هویت آن ایجنت نیست.

در مقابل، MCP بر ارتباط برنامه‌های میزبان مدل‌های هوش مصنوعی با ابزارها و منابع داده تمرکز دارد. این پروتکل مشخص می‌کند ابزارها چگونه معرفی شوند و درخواست‌ها و پاسخ‌ها به چه شکل مبادله شوند.

ANS می‌تواند در کنار این فناوری‌ها برای شناسایی هویت و بررسی سوابق ثبت ایجنت استفاده شود. برای مثال، یک سامانه می‌تواند اطلاعات لازم برای تعامل را از Agent Card دریافت کند و پیش از برقراری ارتباط، هویت مقصد را از طریق سازوکارهای ANS بررسی کند. با این حال، اینکه چنین ترکیبی دقیقا چگونه پیاده‌سازی شود، به نسخه پروتکل‌ها و طراحی سیستم بستگی دارد.

آیا استفاده از Agent Name Service ضروری است؟

برای همه پروژه‌های هوش مصنوعی، خیر. اگر یک برنامه تنها با یک ایجنت داخلی کار می‌کند و نشانی و هویت آن از قبل مشخص است، تنظیم مستقیم مقصد ممکن است کافی باشد. اضافه کردن زیرساخت ثبت هویت و گزارش شفافیت در چنین محیطی می‌تواند پیچیدگی بیشتری از نیاز واقعی پروژه ایجاد کند.

اما در سامانه‌هایی که تعداد زیادی ایجنت پویا دارند، بین سازمان‌ها ارتباط برقرار می‌کنند یا به داده‌ها و عملیات حساس دسترسی دارند، بررسی هویت و مدیریت نسخه‌ها اهمیت بیشتری پیدا می‌کند. در این شرایط، استفاده از سازوکاری مانند ANS می‌تواند وابستگی به فهرست‌های دستی و اطلاعات ثابت را کاهش دهد و بررسی وضعیت ثبت ایجنت‌ها را منظم‌تر کند.

پیش از انتخاب ANS باید وضعیت توسعه آن، سازگاری با پروتکل‌های موجود، هزینه نگهداری زیرساخت و کیفیت سازوکارهای اعتبارسنجی بررسی شود. وجود یک پیاده‌سازی متن‌باز و پیش‌نویس فنی، به‌تنهایی به معنای آماده بودن فناوری برای تمام محیط‌های عملیاتی نیست.

ANS چه جایگاهی در آینده سیستم‌های چندایجنتی دارد؟

با گسترش ایجنت‌های هوش مصنوعی، نیاز به شناسایی مقصد، بررسی هویت و مدیریت تغییرات آن‌ها جدی‌تر می‌شود. Agent Name Service تلاشی برای پاسخ به این نیاز است؛ تلاشی که با تکیه بر DNS، گواهینامه‌های دیجیتال و گزارش‌های رمزنگاری‌شده می‌خواهد زیرساخت مشترکی برای هویت قابل بررسی ایجنت‌ها ایجاد کند.

با این حال، ANS را نباید با یک استاندارد نهایی و فراگیر اشتباه گرفت. بنیاد لینوکس در ژوئن ۲۰۲۶ برنامه خود را برای توسعه این استاندارد اعلام کرد و پیاده‌سازی متن‌بازی نیز برای آن وجود دارد. در عین حال، پیش‌نویس ANS v2 در IETF یک سند کاری است، نه استاندارد نهایی این سازمان؛ نسخه منتشرشده آن در ۱۵ اکتبر ۲۰۲۶ به تاریخ انقضای خود رسید و وضعیت آن باید در ادامه روند توسعه بررسی شود.

در نتیجه، اهمیت ANS بیش از آنکه به جایگزینی DNS یا پروتکل‌های ارتباطی مربوط باشد، به ایجاد لایه‌ای مشترک برای شناسایی و بررسی هویت ایجنت‌ها وابسته است. اینکه این رویکرد تا چه اندازه فراگیر شود، به تکامل مشخصات فنی، پذیرش آن توسط توسعه‌دهندگان و هماهنگی با سایر زیرساخت‌های ایجنت‌های هوش مصنوعی بستگی دارد.