طی نه ماه گذشته، سه غول فناوری جهان - آمازون، مایکروسافت و گوگل - هر کدام یک پلتفرم عامل (Agent) سازمانی را معرفی یا تغییر نام داده‌اند. نکته جالب اینجاست که هر سه شرکت به یک معماری اصلی مشترک رسیده‌اند. مؤلفه‌هایی مانند زمان اجرا (Runtime)، حافظه (Memory)، دروازه ابزار (Tool Gateway)، هویت (Identity)، مشاهده‌پذیری (Observability) و حکمرانی (Governance) اکنون در Amazon Bedrock AgentCore، Microsoft Foundry و Gemini Enterprise Agent Platform گوگل دیده می‌شوند؛ هرچند با نام‌هایی کمی متفاوت.

هر فروشنده این مؤلفه‌ها را به‌عنوان پایه و اساس عامل‌های تولیدی (Production Agents) معرفی می‌کند. آنچه که فقط ۱۸ ماه پیش مجموعه‌ای پراکنده از کتابخانه‌ها بود، اکنون به یک لایه پلتفرم مجزا و یکپارچه تبدیل شده است. این همگرایی نشان‌دهنده بلوغ سریع اکوسیستم عامل‌های هوش مصنوعی است.

درس‌هایی از گذشته: سفر PaaS

برای درک بهتر این تحول، نگاهی به تاریخچه پلتفرم به‌عنوان سرویس (PaaS) خالی از لطف نیست. بین سال‌های ۲۰۱۱ و ۲۰۱۶، توسعه‌دهندگان مجبور بودند برنامه‌های خود را از ترکیب ماشین‌های مجازی، متعادل‌کننده‌های بار، صف‌های پیام، فروشگاه‌های رمز و عامل‌های نظارت بسازند. هر کدام از این مؤلفه‌ها API و مدل عملیاتی خاص خود را داشتند و مدیریت آن‌ها به یک کابوس تبدیل شده بود.

اما ظهور پلتفرم‌هایی مثل Cloud Foundry و Heroku همه چیز را تغییر داد. این پلتفرم‌ها یک «قرارداد برنامه» (Application Contract) واحد ایجاد کردند که تمام این قطعات را یکپارچه می‌کرد. ناگهان، توسعه‌دهندگان به جای فکر کردن به ماشین‌ها و زیرساخت، می‌توانستند روی خود برنامه تمرکز کنند.

اکوسیستم عامل‌ها در آستانه یک نقطه عطف

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

لوله‌کشی‌های زیرساختی یک عامل تولیدی

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

هر یک از این انتخاب‌ها به تنهایی کوچک به نظر می‌رسند، اما در کنار هم تعیین می‌کنند که بار کاری نهایی در کدام ابر مستقر شود. وضعیت جلسه در فروشگاه مدیریت‌شده یک ارائه‌دهنده خاص ذخیره می‌شود، ردیابی‌ها در سرویس تله‌متری همان ارائه‌دهنده ثبت می‌شوند و هویت عامل از دایرکتوری آن استخراج می‌شود. جابجایی این عامل یک سال بعد به معنای بازسازی کل مجموعه است؛ درست همان جایی که شرکت‌ها قبل از ظهور PaaS در آن گیر افتاده بودند.

آموزه‌های Cloud Foundry: قرارداد، نه پیاده‌سازی

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

آنچه اهمیت داشت «قرارداد» بود، نه نحوه پیاده‌سازی. یک برنامه فقط اعلام می کرد به چه چیزی نیاز دارد و نسبت به جایی که اجرا می‌شد، بی‌تفاوت بود. این ایده PaaS در نهایت از خود پلتفرمی که آن را تولید کرد بیشتر عمر کرد. اگرچه Kubernetes به پلتفرم غالب تبدیل شد، اما جامعه کلود فاندری انتزاع خود را از طریق پروژه Korifi روی کوبرنیتیز بازسازی کرد.

اصول یکسان در سه ابر مختلف

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

  • زمان اجرا (Runtime): موتور اصلی اجرای عامل.
  • حافظه (Memory): برای ذخیره‌سازی وضعیت جلسه و حافظه بلندمدت.
  • دروازه ابزار (Tool Gateway): برای اتصال عامل به سیستم‌های خارجی و APIها.
  • هویت و دسترسی (Identity & Access): برای تعیین هویت عامل و مجوزهای آن.
  • مشاهده‌پذیری (Observability): شامل ردیابی، لاگ و مانیتورینگ.
  • حکمرانی (Governance): برای مدیریت خط‌مشی‌ها و امنیت.

این همگرایی، نویدبخش آینده‌ای است که در آن توسعه‌دهندگان می‌توانند عامل‌های هوش مصنوعی را به صورت قابل حمل و مستقل از ابر خاصی بسازند. سوال اساسی این است که آیا یک استاندارد باز مانند PaaS ظهور خواهد کرد تا این اکوسیستم را یکپارچه کند، یا هر ابر به باغ دیواری خود تبدیل خواهد شد؟ با نگاهی به تاریخ، به نظر می‌رسد که بازنده نهایی این بازی، انحصارطلبی خواهد بود.