MCP یک درمان جادویی نیست.

نویسنده (ها): Maithri VM

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

MCP یک درمان جادویی نیست.

حداقل نه هنوز!

اکنون که امواج MCP در حال حل و فصل هستند ، زمان آن رسیده است که از یادگیری من از ساخت نمونه های اولیه MCP برای یک بررسی واقعیت تأمل کنم.

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

MCP چیست؟

این یک پروتکل برای تنظیم استاندارد است مشخصات برای تعامل با LLM عوامل

اجزای اصلی MCP چیست؟

1. سرور MCP: مکانیسمی که برای سرورهای از راه دور برای انتشار منابع ، اعلان ها و ابزارهایی طراحی شده است LLM عامل
2. مشتری MCP: یک شیء است که به سرورهای MCP متصل می شود و برای دستیابی به نتایج مورد انتظار آنها را به رابط LLM متصل می کند.
3. میزبان MCP: یک برنامه نهایی (بومی / وب) که مشتری در آن ساکن است ، تا کاربران را قادر به تعامل با مشتری (های) MCP کند.
4. لایه حمل و نقل: برای برقراری ارتباط بین مشتری و سرورها ، MCP به ترتیب از پشتیبانی STDIO از فرآیندهای محلی و HTTP با SSE برای ارتباطات مشتری به سرور و سرور به مشتری پشتیبانی می کند.

بنابراین به طور خلاصه ، سرور MCP اساساً استانداردی برای برنامه های کاربردی هوش مصنوعی با استفاده از عوامل LLM است.

عامل LLM چیست؟

عامل LLM انتزاعی برای “مهندسی زمینه پیشرفته“😛 این سزاوار یک پست جداگانه به خودی خود است ، اما تعداد زیادی در این مورد نوشته شده و مورد بحث قرار گرفته است ، بنابراین بگذارید این مورد را منتقل کنم.

بنابراین ، MCP اساساً a است استاندارد برای ‘مهندسی متن!

چگونه MCP از برنامه های AI شرکت بهره مند می شود؟

یک برنامه شرکت معمولی شامل اتصال به چندین سرویس مختلف (داخلی و خارجی) برای ارائه راه حل های جامع (اغلب پیچیده) برای نتایج مختلف تجاری است.

1. MCP یکنواختی را در سراسر خدمات شرکت به کار می برد تا یکپارچه با برنامه های LLM (USB-C Anagogy) کار کند: به عنوان پروتکل استاندارد برای یک برنامه AI برای اتصال به این سرورهای مختلف عمل می کند-هم برای زمینه ورودی (منابع) و هم برای اقدامات خروجی (ابزارها) در کنار اعلان ها ، که می تواند راهنمایی خاصی به مشتری دعوت کننده در قالب قالب های سریع ارائه دهد.
2. MCP معماری جدا شده را تشکیل می دهد که مشتری (برنامه LLM) و سرورهای توزیع شده (خدمات از راه دور که منابع و ابزارهایی را ارائه می دهد) ارائه می دهد. این امر به ویژه مدولار بودن و مقیاس پذیری مورد نیاز را برای راه حل کلی با خدمات “plug-n-play” فراهم می کند ، که یک برنامه LLM می تواند به آن متصل شود. به عبارت دیگر ، این امکان را فراهم می کندکشف پویااز خدماتی که بدون داشتن پیامدهای زیادی در برنامه های نهایی مشتری به سرور اضافه می شوند/ حذف می شوند.
3. با تبدیل شدن به کالاهای یکپارچه برنامه های وب آینده ، تنظیم استاندارد مانند MCP برای عوامل LLM مطمئناً یک ضرورت برای عوامل قابل تعامل در سراسر سیستم ECO است.

آیا این بدان معنی است که MCP واقعاً یک پاناسه برای برنامه های هوش مصنوعی است؟

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

1. منبع / ابزار : چگونه به یک عامل LLM آموزش می دهید تا منابع / ابزارها را صحیح انتخاب کند / طرحی برای حل یک مشکل پیچیده ایجاد کند؟ این یک چالش اساسی برای هر برنامه هوش مصنوعی بوده است ، و بسیاری از راه حل ها مانند Rag ، Function ، تنظیم دقیق ، مقیاس زمان استنباط و غیره وجود دارد (و لیست در حال رشد است).

فقط مهاجرت نماینده LLM به مشخصات MCP هیچ یک از این چالش های اساسی را حل نمی کند. خوب ، نکته ای که در اینجا مورد توجه قرار می گیرد این است که Sonnet 3.7 بر عملکردهای فراخوانی عملکرد تسلط دارد و ادعا می کند عملکرد مناسبی را با حداکثر 100 ابزار در یک زمینه معین به دست می آورد (Sic: Mahesh Murag’s کارگاه). امید به شرط بندی در مورد این مشاوره ها ، به نمایندگی از مونتاژ MCP Server / Tools ، وجود دارد ، زیرا مدل ها محدودیت های زمینه و قابلیت های فراخوانی عملکردی و سایر نوآوری ها را با سرعت سریع گسترش می دهند.

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

اگر این راه حل شامل مدل های تنظیم شده زیبا و مناسب برای تصمیم گیری مبتنی بر منابع یا فراخوانی عملکرد مبتنی بر ابزارها باشد ، معماری Dynamic Resource & Tool Binding MCP می تواند سربار اضافی را برای نگه داشتن چنین مدل های خاص در همگام سازی اضافه کند. به نوعی ، این یک نوع مزاحمت برای طراحی پلاگین و بازی پویا است که MCP برای حل آن انجام شده است.

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

الف ریختن همه ابزارها در سرورهای مختلف MCP در ثبت MCP سفارشی (Single DB) ، که کشف ابزار مبتنی بر RAG را با یک جستجو_ tool مانند API امکان پذیر می کند (این یکی از گزینه های توصیه شده در کارگاه است). خوب ، این یک ایده بد نیست ، اما ما می توانیم این مسئله را به عنوان مشکل فراوان رفتار کنیم ، همانطور که در نکته شماره 1 مورد بحث قرار گرفت.

ب. درمان هر سرور MCP به عنوان یک عامل مستقل ، در حالی که برنامه درخواست را برای هدف قرار دادن سرور MCP به روشی سلسله مراتبی هدایت می کند: این یک رویکرد مناسب برای ساخت عوامل ماژولار و ماژولار است که ابزارها و منابع خود را اداره می کنند. با این حال ، این در این لحظه چقدر می تواند پیش برود.

یک عامل واقعی همانطور که می دانیم باید پشتیبانی کند زبان طبیعی سریع با زمینه بدون ساختار به عنوان ورودی و با استفاده از ابزارها / منابع خاص خود در تعامل سبک مکالمه ای بهترین پاسخ را ارائه دهید. اما بسته بندی یک عامل به عنوان سرور MCP شامل چرخش “/تکمیل” به عنوان ابزاری با پارامترهای زوج است که به عنوان متن و پیکربندی عامل عمل می کنند. با تمام پیچیدگی هایی که این روزها فریم ورکهای عامل ارائه می دهند ، تصور زنده بودن همه آنچه که به عنوان ابزارهای MCP انجام می شود ، دشوار است.

3. اجرای سبک گردش کار در مقابل نمایندگی ساده : همانطور که برای اکثر سناریوهای سازمانی می دانیم ، گردش کار هوش مصنوعی باعث پذیرش صنعت بر روی عوامل کاملاً خودمختار می شود. برای دستیابی به چنین گردش کار ، همکاری عامل همچنین مستلزم مدیریت جریان پی در پی ، انسان در وقفه های حلقه و مصوبات و مدیریت دولت برای پشتیبانی از همه آنها است. ایجاد چنین گردش کار عامل که به جای عامل واقعی توسط سرورهای MCP پشتیبانی می شود ، چالش دیگری است که باید با راه حل ها / داربست ها برطرف شود ، همانطور که در نکته شماره 2 بحث شده است. با این حال ، این یکی دیگر از موارد نقشه راه برای MCP است – گردش کار تعاملی ، نمودارهای عامل و غیره.

4. کشف سرور: خواه یک قطب و مدل صحبت یا مش عامل ، با تعداد فزاینده ای از عوامل در اکوسیستم ، محتاطانه است که یک راه حل هوش مصنوعی شامل تعامل با عوامل مختلف برای رسیدن به هدف نهایی است. از آنجا که تعداد نمایندگان در حال تکامل هستند (دقیقاً مانند وب سایت های موجود در اینترنت) ، و Agent Market در افق قرار می گیرد ، کشف نمایندگان چیز بزرگ بعدی خواهد بود که شایسته است Google Like Solutionبشر خوب ، MCP Architecture با ایجاد پایه و اساس استانداردها پیشرو است ، همچنین به روزرسانی Dynamic Tool & Resource یک سرور MCP در پرواز را فعال کرده است.

با این حال ، راه حل های قوی برای کشف پویا از مأمورین خود یک مورد نقشه راه (رجیستری MCP) است. در حالی که چنین رجیستری مرکزی به مدل توپی و گفتاری می پردازد ، استانداردهای دیگری نیز در این صنعت وجود دارد که Discovery عامل همکار را نیز قادر می سازد تا مش را فعال کند.

5. سرانجام ، فیل در اتاق: امنیت ، ایمنی و حاکمیت سرور MCP: ادغام تمام این نگرانی های مهندسی سیستم در یک گلوله واحد ، زیرا در حال حاضر به اندازه کافی گفته شده است و در مورد حفره های امنیتی با MCP و همچنین برنامه های کاهش ریسک لازم که توسعه دهنده راه حل باید در نظر بگیرد ، بحث شده است. (به پیوست مراجعه کنید.)

به طور خلاصه ، MCP تا آنجا که به امنیت مربوط می شود ، مسیری طولانی برای رفتن به جبهه های مختلف دارد ، اما اگر کسی در حال حاضر در نظر دارد تحویل های درجه تولید را با استفاده از MCP در نظر بگیرد ، توصیه می شود با احتیاط عمل کنید. امنیت خود را داشته باشید!

حتی حکم MCP امنیت سرور خود با ساختن لایه AUTH خود ، مدیریت اعتماد (هم بین کاربر و هم نماینده و هم عامل به عامل) ، مدیریت جلسه و اقدامات در برابر زندان های مدل هوش مصنوعی و غیره برای کاهش خطرات شناخته شده. مهندسی این جنبه ها در اطراف مشتری ، میزبان و سرور MCP قابل مذاکره نیست. اگرچه برخی از این نکات قطعاً بخشی از نقشه راه MCP هستند ، اما Onus تا آن زمان در تیم Dev قرار دارد.

بنابراین ، توصیه در اینجا چیست؟

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

به نظر من هر استاندارد / مشخصات فقط با پذیرش گسترده تر توسط جامعه توسعه دهنده موفق می شود ، که به نوبه خود آن را بالغ می کند و به سمت برنده شدن استاندارد (های) همگرا می شود. با استفاده از مزایای شناخته شده و تجارت (هرچند که در موقت) ، تمام آنچه که من می توانم به توسعه دهندگان پیشنهاد کنم ارزیابی گزینه ها و انتخاب بر اساس ملاحظات دقیق است. عضویت در آن بر اساس تصمیمات آگاهانه در مورد اقدامات اضافی در محل ، توصیه می شود.

استانداردهای بیشتری وجود دارد که پس از MCP دنبال شده است ، و همچنین عادلانه است که انتظار داشته باشیم در آینده نزدیک چنین باشد. در حالی که MCP با تعریف استاندارد برای سیم کشی داخلی عامل شروع خوبی دارد ، افزایش چنین استانداردهایی به تعامل واقعی عامل به عامل نیاز ساعت است!

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

پیوست:

https://www.latent.space/p/why-mcp-won

https://techcommunity.microsoft.com/blog/microsoft-security-blog/understanding-mitigating-securance-risks-in-mcp-implementations/4404667

همه چیز با MCP اشتباه است

توضیح پروتکل زمینه مدل و هر آنچه ممکن است اشتباه پیش برود.

blog.sshh.io

https://equixly.com/blog/2025/03/29/mcp-server-new-securance-nightmare/

منتشر شده از طریق به سمت هوش مصنوعی