پروتکل محتوای مدل (MCP) سر و صدای زیادی در توییتر به پا کرده است – اما آیا واقعاً مفید است یا فقط هیاهو است؟ در این بحث و گفتگو، هریسون چیس (مدیرعامل لنگچین) و نونو کامپوس (رهبر لنگگراف) درباره اینکه آیا MCP به اندازه هیاهویی که به راه انداخته، ارزشمند است یا خیر، بحث میکنند.
هریسون: من موضعی را اتخاذ میکنم که MCP واقعاً مفید است. در ابتدا به آن شک داشتم، اما کمکم به ارزش آن پی بردم. اساساً: MCP زمانی مفید است که بخواهید ابزارهایی را به عاملی بیاورید که کنترلی روی آن ندارید.
بگذارید مثالی بزنم. به عنوان یک کاربر، در Claude Desktop، Cursor، Windsurf، من عامل زیربنایی را کنترل نمیکنم. آن عامل به چند ابزار داخلی دسترسی دارد.
اما اگر بخواهم به آن ابزاری بدهم که به طور پیشفرض ندارد، چه؟ برای انجام این کار، باید پروتکلی وجود داشته باشد – در غیر این صورت چگونه میداند که چگونه ابزار را فراخوانی کند؟
من معتقدم این برای غیر توسعهدهندگان نیز برای ایجاد عاملها مفید خواهد بود. یکی از روندهایی که مشاهده میکنیم این است که مردم میخواهند ساخت عامل را برای متخصصان موضوع، صرف نظر از تخصص فنی آنها، در دسترس قرار دهند. من فکر میکنم این سازندگان به ندرت میخواهند (یا میتوانند) منطق خود عامل را ویرایش کنند - اما میخواهند به آن دسترسی به ابزارهای خاصی بدهند. MCP در اینجا مفید خواهد بود.
نونو: من فکر میکنم شما میزان نیازمندی بقیه قسمتهای عامل به ابزارهایی که به آن دسترسی میدهید را دست کم میگیرید. مطمئناً، اگر Windsurf (خدای ناکرده) با یک ابزار جستجوی وب ضعیف ارائه شود و شما بخواهید آن را با یک ابزار خوب جایگزین کنید، این کار جواب میدهد. اما این یک مورد استفاده واقعی نیست.
مورد استفاده قانعکننده – موردی که در آن به Cursor قابلیتهای جدیدی میدهید که حتی سازندگانش هم خوابش را نمیدیدند، فقط با تزریق یک ابزار جادویی شما – در واقع در اکثر مواقع عملی نخواهد بود. تقریباً در تمام عاملهای تولیدی که دیدهام، شما باید پیام سیستم و حتی سایر بخشهای معماری را با ابزارهایی که در دسترس قرار میدهید، تنظیم کنید.
هریسون: خب، این عاملها ممکن است 99% قابل اعتماد نباشند... اما احتمالاً هنوز هم میتوانند به اندازه کافی خوب باشند که مفید باشند؟ توضیحات ابزار و دستورالعملها قطعاً مهم هستند! اما ما همچنین میدانیم:
- MCP دارای تعاریف ابزار است - و سرورهای خوب MCP احتمالاً توضیحات ابزار بهتری نسبت به آنچه شما به سرعت مینویسید، خواهند داشت.
- MCP امکان استفاده از پرامپتها را فراهم میکند - بنابراین میتوانید دستورالعملها را نیز بگنجانید.
- عامل فراخوانی ابزار خارج از قفسه با بهتر شدن مدلهای زیربنایی، بسیار بهتر خواهد شد.
من فکر نمیکنم کسی بخواهد Cursor بعدی را صرفاً بر اساس ادغامهای MCP و یک عامل فراخوانی ابزار بسازد، اما مطمئناً ارزشی در آن وجود دارد؟ به عنوان مثال، عاملهای داخلی یا شخصی.
نونو: خب، معیارهای فراخوانی ابزار خودمان نشان میدهد که مدلهای فعلی تقریباً نیمی از مواقع نمیتوانند ابزار مناسب را فراخوانی کنند – و این در عاملهایی با معماری و پرامپتهایی است که دقیقاً برای آن مجموعه ابزارها طراحی شدهاند. حتی یک عامل شخصی که نیمی از مواقع شکست میخورد، خیلی مفید نیست…
و بله، مدلها بهتر خواهند شد – اما انتظارات کاربر نیز افزایش مییابد. حرف من را قبول نکنید، از بزوس نقل قول میکنم: «چیزی که من در مورد مشتریان دوست دارم این است که آنها به طور الهی ناراضی هستند. انتظارات آنها هرگز ثابت نیست – بلکه بالا میرود. این طبیعت انسان است.»
اگر کل پشته – رابط کاربری، پرامپتها، معماری، ابزارها – را در اختیار داشته باشید، میتوانید به آن انتظارات عمل کنید. در غیر این صورت، موفق باشید.
هریسون: مدلها همچنان بهتر خواهند شد – من با اطمینان روی آن شرط میبندم. بنابراین نرخ موفقیت عاملها در حال حاضر هر چه باشد، فقط افزایش خواهد یافت.
من فکر نمیکنم مقایسه صحیح، مقایسه عاملی باشد که میتوانم با MCP بسازم با یک عامل صیقلخورده با آن ابزارها. من فکر میکنم ارزش واقعی در دنباله طولانی اتصالات و ادغامهایی که میخواهم ایجاد کنم، نهفته است.
مانند Zapier، این در مورد اتصال ایمیل به Google Sheets، Slack و غیره است. تعداد بینهایتی از گردشهای کاری وجود دارد که میتوانم ایجاد کنم، و احتمالاً یک عامل صیقلخورده برای هر یک از آنها وجود نخواهد داشت. با MCP، میتوانم نسخههای خودم را از آنها ایجاد کنم.
نظر شما در مورد قیاس Zapier چیست؟
نونو: در LangChain، ما به مدت دو سال کتابخانهای از 500 ابزار داشتهایم، و من ندیدهام که از آنها اغلب در محیطهای پروداکشن استفاده شود. همه آنها با یک "پروتکل" یکسان پیادهسازی شده بودند، با هر مدلی سازگار بودند و قابلیت تعویض داشتند. پس تفاوت در اینجا چیست – آیا این فرم فاکتور شگفتانگیز MCP است که مجبورید میلیونها سرور را در ترمینال خود به صورت محلی اجرا کنید و فقط با برنامههای دسکتاپ سازگار باشد؟ این به نظر من یک مزیت نیست. راستش را بخواهید، من فکر میکنم Zapier حد بالای پتانسیل MCP است.
هریسون: من فکر میکنم تفاوت بین ابزارهای LangChain و ابزارهای MCP این است که MCP برای توسعهدهندگان عامل نیست. آنها زمانی بیشترین کاربرد را دارند که ابزارها را به عاملی بیاورید که نمیتوانید آن را توسعه دهید.
برای روشن شدن – اگر من در حال نوشتن عاملی برای انجام XYZ بودم – به هیچ وجه از MCP استفاده نمیکردم. اما من فکر نمیکنم که این مورد استفاده هدف برای MCP باشد. MCP ابزارها را به عاملی میآورد که شما آن را کنترل نمیکنید. همچنین به غیر توسعهدهندگان این امکان را میدهد که ابزارها را به عاملها بیاورند (در حالی که ابزارهای LangChain متمرکز بر توسعهدهندگان هستند). تعداد غیر توسعهدهندگان بسیار بیشتر از توسعهدهندگان است.
در مورد فرم فاکتور فعلی MCP؟ بله، افتضاح است. اما قرار است بهتر شود، درست است؟ من وضعیت آیندهای از MCP را تصور میکنم، جایی که با یک کلیک برنامههای MCP را نصب میکنید (دیگر نیازی به اجرای سرورها در ترمینال به صورت محلی نیست) و آنها در برنامههای وب قابل دسترسی هستند. شرط میبندم که MCP به آن سمت میرود.
به نظر شما MCP چه چیزی را باید تغییر دهد و آیا این برای متقاعد کردن شما به مفید بودن آنها کافی است؟
نونو: خوب، بنابراین MCP باید بیشتر شبیه GPTهای سفارشی OpenAI شود، و آن زمان است که هیاهوی فعلی توجیه خواهد شد. اما GPTهای سفارشی هم آنقدرها محبوب نیستند. پس چه چیزی – چه چیزی در GPTها وجود نداشت که MCP دارد؟
هریسون: منظورم این است که MCP بیشتر شبیه پلاگینها است، که آنها هم موفق نشدند؟؟ من تجربه پلاگین را تا حدودی فراموش کردهام (مطمئن نیستم که تا به حال از آن استفاده کرده باشم) بنابراین هر مقایسهای که انجام دهم ممکن است اشتباه باشد. اما من استدلال میکنم:
- اکوسیستم MCP در حال حاضر بسیار بزرگتر از اکوسیستم پلاگینها است.
- مدلها بهتر شدهاند و توانایی بیشتری برای استفاده از این ابزارها دارند.
نونو: خب، من نمیدانم که آیا اکوسیستم بزرگتر است یا خیر. یک دایرکتوری تصادفی که در 5 ثانیه پیدا کردم، 893 سرور را در زمان نگارش این مطلب فهرست میکند. من فکر میکنم شما ممکن است تعداد توییتهایی را که در تایملاین شما به MCP اشاره میکنند، به جای چیزهای واقعی ساخته شده با آن، بشمارید؟؟ اما با بازگشت به سوال بیپاسخ شما، به نظر من، اگر قرار باشد MCP چیزی بیش از یک پاورقی در تاریخ هوش مصنوعی باشد، باید:
- کمتر پیچیده شود. چرا یک پروتکل ابزار باید پرامپتها و تکمیلهای LLM را نیز ارائه دهد؟
- پیادهسازی آسانتری داشته باشد. چرا یک پروتکل برای ارائه ابزارها باید ارتباط دو طرفه داشته باشد؟ بله، من تمام دلایلی را که آنها فهرست میکنند خواندهام، و نه، متاسفم، دریافت لاگها از سرور دلیل کافی خوبی نیست.
- قابل استفاده در سرور باشد. یک پروتکل بدون حالت برای این کار کلیدی است – فقط به این دلیل که ما با LLMها میسازیم، به این معنی نیست که باید تمام درسهای سخت آموخته شده در مورد مقیاسبندی چیزها را به صورت آنلاین فراموش کنیم. و هنگامی که در سرور قابل استفاده باشد، تعدادی از مسائل دیگر مانند احراز هویت (که حل آن به صورت توزیع شده آسان نیست) ظاهر میشود.
- کاهش کیفیتی را که ناشی از اتصال ابزارهای تصادفی به عاملی است که چیزی در مورد آنها نمیداند، جبران کند.
هریسون: احتمالاً حق با شماست که من مقداری سوگیری اخیر از تایملاین توییتر دارم. اما شک و تردید زیادی هم در آنجا وجود دارد!
بنابراین، بیایید آن را به آنها برگردانیم. رای خود را در نظرسنجی توییتر زیر ثبت کنید – آیا MCP یک جرقه زودگذر است یا یک استاندارد آینده؟