جیک منیکس (Jake Mannix)، عضو جامعه Fellows در والمارت، روزها را با عاملهای هوش مصنوعی سر میکند. او بههمراه آدیتا، روی میانافزار عاملی (Agentic Middleware) کار میکند که زیرساخت بیش از ۲۰ هزار توسعهدهنده نرمافزار و دانشمند داده در والمارت را تأمین میکند؛ افرادی که اکنون با سرعت بیسابقهای در حال ساخت عاملهای هوش مصنوعی هستند.
«سال عاملها» تقریباً به پایان رسیده و بیشتر ما در این جمع مهندس نرمافزار هستیم. پس بیایید درباره این صحبت کنیم که ساخت یک عامل مبتنی بر LLM در عمل چه معنایی دارد.» اینها جملههای آغازین منیکس در ارائهای است که به یکی از مهمترین چالشهای فعلی توسعه هوش مصنوعی پرداخت: چگونه میتوان عاملهای هوش مصنوعی را مانند نرمافزارهای واقعی ساخت و از کپیپیست بیهدف رها شد؟
برنامهنویسی به زبان انگلیسی؛ جدیدترین پارادایم توسعه
منیکس با اشاره به توییت معروف آندری کراپاتی (Andrej Karpathy) که کمتر از دو ماه پس از عرضه ChatGPT منتشر شد، میگوید: «زبانی که با آن برنامهنویسی میکنیم انگلیسی است. زبانی بسیار مشخص، منعطف و فازی. فکر کردن دربارهاش عجیب است، اما این دقیقاً همان کاری است که ما انجام میدهیم: برنامهنویسی به زبان انگلیسی.»
اما问题是 این که نحوه برنامهنویسی با این زبان جدید، شکلی بهشدت آشنا دارد؛ آشنایی که به پنجاه سال پیش برمیگردد. منیکس معتقد است ما در حال بازآموزی چیزهای گذشته هستیم، زیرا برنامههایی که با زبان انگلیسی مینویسیم، ساختاری شبیه به زبان BASIC در سال ۱۹۷۵ دارند.
بازگشت به سال ۱۹۷۵؛ ساختار شکننده عاملهای امروزی
در سال ۱۹۷۵، یک برنامه BASIC از یک فایل واحد تشکیل میشد. شماره خط داشت، دستور GOTO داشت و همه چیز در یک متد main قرار میگرفت. منیکس توضیح میدهد که وضعیت فعلی ساخت عاملهای هوش مصنوعی دقیقاً همین الگو را دنبال میکند:
- یک فایل بزرگ که تمام منطق اجرایی در آن قرار دارد
- پرشهای غیرقطعی (Non-deterministic) شبیه به دستور GOTO
- هیچ رابط (Interface) مشخصی وجود ندارد
- کپسولهسازی (Encapsulation) به معنای واقعی کلمه غایب است
«ما برنامهنویسی به انگلیسی میکنیم، بله، اما برنامهنویسی مثل سال ۱۹۷۵. چرا؟ رابط نداریم. کپسولهسازی نداریم. فقط به سبک ۱۹۷۵ جلو میرویم.» منیکس این وضعیت را فانتزی و در عین حال نگرانکننده توصیف میکند.
پنجاه سال پیشرفت مهندسی نرمافزار که نادیده گرفتهایم
مهندسی نرمافزار در پنجاه سال گذشته مسیر طولانیای را طی کرده است. ما امروز به مجموعهای از ابزارها و روشهای بالغ دسترسی داریم که پیش از این وجود نداشتند:
- رابطها (Interfaces): برای تعریف قراردادهای واضح بین اجزا
- کتابخانههای مشترک نسخهبندیشده: برای استفاده مجدد کد بدون تداخل
- مدیریت وابستگی: برای کنترل پیچیدگی ارتباط بین ماژولها
- تست واحد (Unit Testing): برای تضمین صحت عملکرد
- CI/CD: برای اتوماسیون فرآیند ساخت و استقرار
منیکس تأکید میکند که ما در دنیای خوبی زندگی میکنیم و همه این ابزارها را بدیهی میدانیم. اما وقتی شروع به ساخت عاملهایی کردیم که نیاز به فراخوانی ابزار داشتند، طبیعتاً چیزی شبیه کتابخانههای مشترک میخواستیم، نه اینکه همه چیز را در متد main پیست کنیم.
MCP؛ قدمی به جلو اما با چالشهای جدی
وقتی توسعهدهندگان شروع به ساخت عاملهای دارای ابزار کردند، نیاز به چیزی شبیه کتابخانههای مشترک احساس شد. نتیجه این نیاز، پروتکل Model Context Protocol یا MCP بود. منیکس با صراحت میگوید: «نمیخواستیم آن را از نو اختراع کنیم، اما کردیم. نامش را MCP گذاشتیم. من تا حد زیادی به MCP انتقاد میزنم، اما واقعاً ضروری بود.»
پیش از MCP، وضعیت بسیار بدتر بود. تمام کار این بود که یک متد main بزرگ داشتید و همه نفران همان ابزارها را دوباره و دوباره مینوشتند. MCP قطعاً یک قدم به جلو است. با حرکت به سمت این پروتکل، قابلیتهای تخصصی از عامل اصلی به سرورهای جداگانه منتقل میشوند:
- Slack درباره Slack میداند و ابزارهای مرتبط را ارائه میدهد
- Stripe درباره پرداخت میداند و سرویسهای مالی را در دسترس قرار میدهد
- صاحبان هر سرویس ابزارهای خود را میسازند و عاملها آنها را در زمان اجرا به هم وصل میکنند
چالش پنهان طراحی ابزار
اما منیکس هشدار میدهد که این کار بههیچوجه ساده نیست. طراحی ابزار برای عاملهای هوش مصنوعی یکی از سختترین بخشهای این فرآیند است:
«نمیتوانید سرورهای MCP را از یک مشخصه OpenAPI بهطور خودکار تولید کنید و امیدوار باشید که خوب باشد. در واقع، کاملاً آشغال خواهد بود. صدها نقطه پایانی (Endpoint) به شما میدهد بدون هیچ فکری درباره آنچه LLM واقعاً نیاز دارد.»
این مشکل ریشه در تفاوت بنیادین میان APIهای طراحیشده برای انسان و ابزارهای طراحیشده برای مدلهای زبانی دارد. یک مشخصه OpenAPI معمولاً صدها نقطه پایانی دارد که برای توسعهدهندگان انسانی طراحی شدهاند، نه برای مدلهایی که باید با زبان طبیعی تصمیم بگیرند کدام ابزار را فراخوانی کنند. تبدیل خودکار این مشخصهها به ابزارهای MCP بدون بازنگری در طراحی، نتیجهای غیرقابل استفاده تولید میکند.
آینده توسعه عاملهای هوش مصنوعی
منیکس در ارائه خود به نکتهای اشاره میکند که بسیاری از توسعهدهندگان عاملهای هوش مصنوعی با آن دستوپنجه نرم میکنند: ما از دستاوردهای پنجاه سال مهندسی نرمافزار برای ساخت سیستمهای جدید استفاده نمیکنیم. عاملهای هوش مصنوعی امروزه مانند برنامههای BASIC در دهه ۱۹۷۰ نوشته میشوند؛ یک فایل، بدون معماری، بدون کپسولهسازی، بدون تستپذیری واقعی.
مسیر پیش رو روشن است: ابزارهایی مانند MCP نقطه آغاز هستند، اما نه نقطه پایان. تا زمانی که طراحی ابزار با درک عمیق از نیازهای مدلهای زبانی انجام نشود و تا زمانی که اصول مهندسی نرمافزار مانند رابطگذاری، نسخهبندی و تستپذیری وارد دنیای عاملهای هوش مصنوعی نشود، این سیستمها در همان سال ۱۹۷۵ باقی خواهند ماند؛ هرچند که زبان برنامهنویسی از BASIC به انگلیسی تغییر کرده باشد.
