پروتکل‌های ایجنت؛ MCP و A2A چه مسئله‌ای را حل می‌کنند؟

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

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

چرا پروتکل‌های ایجنت لازم شدند؟

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

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

پروتکل MCP؛ اتصال ایجنت به ابزار

پروتکل زمینه‌ی مدل (Model Context Protocol) یک استاندارد باز است که روش ارائه‌ی زمینه و ابزار به مدل‌های زبانی را یکسان می‌کند. در قسمت‌های قبل با آن آشنا شدیم؛ حالا ساختارش را دقیق‌تر می‌بینیم.

معماری میزبان، کلاینت و سرور

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

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

مزایای MCP

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

مزیت سوم امنیت استاندارد است. MCP روشی استاندارد برای احراز هویت دارد که اضافه کردن سرورهای تازه را ساده‌تر می‌کند. به‌جای مدیریت کلیدهای مختلف برای هر API، یک الگوی یکسان دارید.

مثال؛ رزرو پرواز با MCP

دستیاری را در نظر بگیرید که به سرور MCP یک شرکت هواپیمایی وصل می‌شود. اول، دستیار که همان کلاینت است، به سرور متصل می‌شود. بعد می‌پرسد «چه ابزارهایی دارید؟» و سرور ابزارهای «جستجوی پرواز» و «رزرو پرواز» را معرفی می‌کند.

کاربر می‌گوید «پرواز تهران به مشهد را پیدا کن». دستیار ابزار جستجو را با پارامترهای مناسب صدا می‌زند. سرور MCP درخواست را به API داخلی شرکت می‌رساند و نتیجه را برمی‌گرداند. پس از انتخاب پرواز، دستیار می‌تواند ابزار رزرو را در همان سرور صدا بزند؛ البته با تأیید کاربر.

پروتکل A2A؛ همکاری ایجنت با ایجنت

MCP ایجنت را به ابزار وصل می‌کند. پروتکل ایجنت به ایجنت (Agent-to-Agent) یک قدم جلوتر می‌رود؛ ارتباط و همکاری میان خود ایجنت‌ها را استاندارد می‌کند. با A2A، ایجنتی از یک شرکت می‌تواند کاری را به ایجنت شرکت دیگری بسپارد.

چهار جزء اصلی A2A

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

جزء دوم اجراکننده‌ی ایجنت است که زمینه‌ی گفت‌وگوی کاربر را به ایجنت دوردست می‌رساند؛ ایجنت دوردست برای فهم کار به این زمینه نیاز دارد. جزء سوم محصول کار (Artifact) است؛ نتیجه‌ی کار ایجنت دوردست همراه توضیح و زمینه. جزء چهارم صف رویداد است که به‌روزرسانی‌ها و پیام‌ها را مدیریت می‌کند؛ به‌خصوص برای کارهای طولانی که نباید ارتباط وسط کار قطع شود.

مثال؛ برنامه‌ی کامل سفر

کاربری از «ایجنت سفر» می‌خواهد یک سفر کامل برنامه‌ریزی کند؛ پرواز، هتل و خودرو. ایجنت سفر درخواست را تحلیل می‌کند و تشخیص می‌دهد به سه ایجنت تخصصی نیاز دارد. بعد با A2A کار را به «ایجنت هواپیمایی»، «ایجنت هتل» و «ایجنت اجاره‌ی خودرو» می‌سپارد.

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

NLWeb؛ وب‌سایتی که به زبان طبیعی پاسخ می‌دهد

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

اجزای NLWeb

NLWeb از چند جزء تشکیل شده است. برنامه‌ی اصلی پرسش‌های زبان طبیعی را پردازش می‌کند. پروتکل NLWeb قواعد پایه‌ی تعامل زبان طبیعی با وب‌سایت را تعریف می‌کند و پاسخ‌ها را در قالب JSON، معمولاً با واژگان Schema.org، برمی‌گرداند. مدل‌های تعبیه محتوای سایت را به بردار تبدیل می‌کنند و پایگاه داده‌ی برداری آن‌ها را برای جستجوی معنایی نگه می‌دارد.

جزء مهم دیگر این است که هر نمونه‌ی NLWeb یک سرور MCP هم هست. یعنی ایجنت‌های بیرونی هم می‌توانند به‌صورت استاندارد از آن سؤال کنند. سایت یک مجموعه‌ی آموزشی با NLWeb، هم برای بازدیدکننده‌ی انسانی و هم برای ایجنت‌های دیگر قابل پرسش است.

مرز پروتکل و اختیار

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

استاندارد بودن یعنی مجاز بودن؟

فرض کنید دستیار به سرور MCP یک سامانه‌ی آموزشی وصل است که هم ابزار «خواندن نمرات» دارد و هم «تغییر نمره». پروتکل هر دو را یکسان معرفی می‌کند. اما تغییر نمره اقدامی حساس است که باید تأیید انسانی بخواهد و فقط برای نقش‌های مشخص مجاز باشد.

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

نمودار زیر نقش هر پروتکل و مرز اختیار را خلاصه می‌کند.

سناریوی عملی؛ دستیار با دو اتصال

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

اقدام و معیار پذیرش

اقدام مورد بررسی، تفکیک ابزار داده از سرویس تصمیم‌گیر و تعریف مسیر ارتباط هرکدام است. مخزن محتوا مناسب MCP است؛ ابزار و منبع ارائه می‌دهد. سرویس برنامه‌ریزی که خودش تصمیم می‌گیرد، به ایجنت شبیه‌تر است و A2A برایش طبیعی‌تر است.

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

نمونه‌ی شکست

شکستی که باید عمداً دنبالش باشید این است: فرض اینکه استاندارد بودن ارتباط به معنای مجاز بودن هر اقدام است. برای بازسازی، به سرور MCP آزمایشی یک ابزار حساس اضافه کنید و ببینید آیا دستیار بدون تأیید آن را اجرا می‌کند. اگر بله، فهرست ابزارهای مجاز یا لایه‌ی تأیید کم است.

تمرین عملی؛ نقشه‌ی اتصال‌ها

خروجی این تمرین نقشه‌ی اتصال ابزارها و ایجنت‌ها با مسئولیت مشخص است:

1. همه‌ی اتصال‌های دستیارتان را فهرست کنید و برای هر کدام تعیین کنید MCP مناسب است یا A2A.
2. برای هر ابزار MCP مشخص کنید فقط‌خواندنی است یا تغییردهنده و کدام نقش اجازه‌ی استفاده دارد.
3. برای هر اتصال A2A بنویسید نتیجه را چطور پیش از نمایش به کاربر بررسی می‌کنید.

مشخص کنید کدام بخش را واقعاً اجرا کرده‌اید و کدام هنوز فرض است.

سخن پایانی

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

در قسمت بعد اتصال عملی ابزارهای MCP به دستیار را پیاده می‌کنیم.

این آموزش بر پایه‌ی درس Using Agentic Protocols (MCP, A2A and NLWeb) از مجموعه‌ی آزاد AI Agents for Beginners مایکروسافت (مجوز MIT) به فارسی بازنویسی و تکمیل شده است.