پروتکل MCP: ۵ تغییر بزرگ در معماری هوش مصنوعی که باید بدانید

اگر بخشی از زمان خود را صرف ساخت ورک‌فلوهای مبتنی بر ایجنت (Agentic Workflows) کرده باشید، احتمالا با کابوس «مشکل ادغام $N \times M$» مواجه شده‌اید. این همان بن‌بست معماری است که در آن هر اپلیکیشن جدید هوش مصنوعی ($N$) برای اتصال به هر منبع داده یا ابزار ($M$)، به یک کانکتور اختصاصی و کدنویسی‌شده نیاز دارد؛ رویکردی شکننده و غیرقابل‌توسعه که توسعه‌دهندگان را مجبور می‌کند به‌جای تمرکز روی منطق استدلال مدل، زمان خود را تلف کنند.

پروتکل کانتکست مدل یا همان Model Context Protocol (MCP) مانند یک پورت USB-C برای عصر هوش مصنوعی است. این پروتکل یک زبان استاندارد جهانی ارائه می‌دهد تا مدل‌های هوش مصنوعی بتوانند بدون نیاز به پل‌های سفارشی، مستقیما به دیتابیس‌ها، فایل‌سیستم‌ها و APIها متصل شوند. با حرکت صنعت به سمت این معماری پلاگین‌محور، MCP همان کاری را برای هوش مصنوعی انجام می‌دهد که درایورهای استاندارد برای کامپیوترهای شخصی انجام دادند.

اما با بلوغ این پروتکل — به‌ویژه با معرفی قابلیت‌های جدید در SEP-2567 — نگاه ما به استیت (State) و اتصالات در هوش مصنوعی دستخوش تغییرات غافل‌گیرکننده‌ای شده است. در ادامه ۵ نکته کلیدی از اکوسیستم فعلی MCP را بررسی می‌کنیم.

۱. تغییر فرمول اتصال از ضرب به جمع (راهکار $N+M$)

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

این کار حجم تلاش برای اینتگریشن را از $N \times M$ به $N + M$ کاهش می‌دهد. این تغییر نه‌تنها سرعت توسعه را بالا می‌برد، بلکه زیرساخت اصلی برای هوش مصنوعی در مقیاس انترپرایز است.

«پروتکل MCP یک استاندارد متن‌باز است که زبانی یکپارچه برای اتصال مدل‌های هوش مصنوعی به منابع داده، ابزارها و اپلیکیشن‌های مختلف ایجاد می‌کند.» — Astrix Security

استانداردسازی همان حلقه مفقوده‌ای است که مشکل قفل شدن روی یک سرویس‌دهنده خاص (Vendor Lock-in) را حل می‌کند. سازمان‌ها حالا می‌توانند کتابخانه‌ای از ابزارهای داخلی بسازند که حتی در صورت مهاجرت از Claude به GPT-5 یا تغییر ارکستراتور، همچنان کارایی خود را حفظ کنند.

۲. مرگ سشن‌ها و حرکت به سمت MCP بدون استیت (Stateless)

یکی از عمیق‌ترین تغییرات فنی در آپدیت‌های اخیر این پروتکل، حذف سشن‌ها (Sessions) در سطح پروتکل است. در گذشته، سشن‌ها برای مدیریت کستومایز کردن دسترسی‌ها و استیت اپلیکیشن استفاده می‌شدند. اما به دلیل تعریف متفاوت کلاینت‌ها (مثل ChatGPT در مقابل Claude Desktop) از طول عمر سشن، این رویکرد بسیار شکننده بود.

با حرکت به سمت یک پروتکل بدون استیت (Stateless)، کارایی ارکستراتورهای ایجنتی به شدت افزایش می‌یابد. در مدل‌های مبتنی بر سشن، لیست ابزارها (مانند tools/list) به سشن وابسته بودند و باید برای هر ساب‌ایجنت موقت دوباره بررسی می‌شدند؛ مشکلی با پیچیدگی از مرتبه $O(\text{subagents} \times \text{servers})$.

در مدل Stateless، نتایج این اندپوینت‌ها مستقل از سشن هستند و در کل لایف‌سایکل ارکستراتور کش (Cache) می‌شوند. این یعنی کاهش پیچیدگی به $O(\text{servers})$ و افت چشمگیر لیتنسی در ورک‌فلوهای موازی و پیچیده.

۳. تله کثیف شدن استریم Stdout

برای توسعه‌دهندگانی که از ترانسپورت stdio (پیش‌فرض پروسس‌های لوکال) استفاده می‌کنند، یک نکته فنی خطرناک در استریم JSON-RPC وجود دارد. از آنجا که کلاینت، سرور را به عنوان یک Child Process اجرا کرده و از طریق stdin و stdout ارتباط برقرار می‌کند، این ترانسپورت به یک استریم کاملا تمیز از کدهای JSON نیاز دارد.

تله اصلی اینجاست: لاگ‌های ناخواسته (Rogue Logs). یک دستور console.log ساده یا پیامی مثل "Connection successful" از یک کتابخانه شخص ثالث، نویز غیر-JSON وارد استریم می‌کند و باعث کرش کردن کلاینت با خطای "Unexpected token" می‌شود.

نکته: رفع مشکل لاگین

• هرگز از stdout برای لاگ استفاده نکنید: برای دیباگ کردن فقط از console.error() استفاده کنید؛ زیرا stderr توسط لایه ترانسپورت MCP نادیده گرفته می‌شود.
• ردایرکت کردن stdout در استارتاپ: تمام خروجی‌های استاندارد را به یک فایل یا به stderr منتقل کنید تا پکیج‌های دیگر استریم JSON-RPC را خراب نکنند.

معماران سیستم باید استریم stdout را به عنوان یک دیتابوس با یکپارچگی بالا در نظر بگیرند؛ زیرا حتی یک بایت متن ناخواسته می‌تواند کل لوپ استدلال ایجنت را مختل کند.

۴. پترن Explicit State Handles؛ سبد خریدهای جدید ابزارهای هوش مصنوعی

با حذف سشن‌ها، یک دیزاین پترن جدید برای ورک‌فلوهای استیت‌فول متولد شده است: Explicit State Handles. توجه داشته باشید که این هندل‌ها جزو ساختارهای خود پروتکل نیستند، بلکه یک پترن طراحی ابزار (Tool-Design Pattern) به شمار می‌روند.

به‌جای اینکه سرور سبد خرید یا ترنزکشن دیتابیس کاربر را از طریق یک سشن ضمنی به خاطر بسپارد، سرورها حالا از الگوی «ساخت و پاس دادن» (Create-and-Thread) استفاده می‌کنند. برای مثال، سرور ابزاری مثل create_browser() را ارائه می‌دهد که یک browser_id برمی‌گرداند. سپس ایجنت موظف است این هندل را به عنوان آرگومان در تمام فراخوانی‌های بعدی (مثل navigate(browser_id, url)) ارسال کند.

این پترن به دو دلیل برای ایجنت‌های هوش مصنوعی فوق‌العاده است:

• دقت (Precision): یک ساب‌ایجنت می‌تواند از basket_id اصلی برای یک سفارش مشترک استفاده کند، اما برای یک تسک جستجوی موازی و ایزوله، browser_id اختصاصی خودش را بسازد.
• قابلیت بازگشت (Resumption): از آنجا که هندل‌ها در نتایج ابزار ظاهر می‌شوند، در تاریخچه چت ذخیره شده و ایجنت می‌تواند هفته‌ها بعد با خواندن تاریخچه خود، تراکنش را از همان‌جا ادامه دهد.

۵. ترانسپورت‌های سفارشی؛ برگ برنده سازمان‌های بزرگ

اگرچه MCP ترانسپورت‌های داخلی مثل stdio و SSE را ارائه می‌دهد، اما معماران سازمانی اغلب به گزینه‌های بیشتری نیاز دارند. بر اساس راهنمای ترانسپورت‌های وب‌سایت Stainless، چهار محرک اصلی برای ساخت یک ترانسپورت سفارشی وجود دارد: پرفورمنس، ادغام با فریم‌ورک‌ها، امنیت و پروتکل‌های خاص (مثل WebSockets یا ZeroMQ).

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

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

جمع‌بندی و نتیجه‌گیری

ما در حال عبور از عصر «RAG استاتیک» — جایی که هوش مصنوعی صرفا تکه‌هایی از دیتاهای ایندکس‌شده قدیمی را بازیابی می‌کرد — و حرکت به سمت ارتباطات زنده مبتنی بر MCP هستیم. در این دنیای جدید، ایجنت‌ها فقط داده‌ها را نمی‌خوانند، بلکه از طریق ابزارهای تحت کنترل مدل (Model-Controlled Tools) با APIهای ریل‌تایم تعامل دارند.

با مستقل‌تر شدن ایجنت‌ها، تمرکز به سمت مدیریت هویت‌های غیرانسانی (Non-Human Identities) تغییر می‌کند. پروتکل MCP پایه و اساس یک Agent Control Plane (ACP) را فراهم می‌کند تا سازمان‌ها بتوانند چرخه حیات ایجنت‌های موقت هوش مصنوعی را مدیریت کنند.

تیم شما چطور معماری APIهای فعلی خود را برای دنیایی آماده می‌کند که مصرف‌کننده اصلی داده‌های آن، ابزارهای تحت کنترل هوش مصنوعی هستند؟ نظرات و تجربه‌های خود را در بخش کامنت‌ها با ما به اشتراک بگذارید!