به گزارش از وبسایت cncf

چندی پیش با پروژه‌ای جالب به نام agent-sandbox آشنا شدم که با تکیه بر بلوک‌های زیرساختی‌ای که برای پادهای Kubernetes ساخته شده‌اند — مانند هویت، ذخیره‌سازی و شبکه — یک محیط امن و ایزوله یا sandbox برای اجرا کردن عوامل هوش مصنوعی فراهم می‌کند. اگر داستان‌های ترسناک درباره عوامل کدنویس AI را خوانده‌اید یا پروژه‌هایی مثل OpenClaw و NemoClaw را دنبال کرده‌اید، احتمالاً با اهمیت داشتن یک محیط ایمن آشنا هستید؛ بدون جداسازی مناسب، عوامل ممکن است کارهایی را انجام دهند که هرگز قصدش را نداشته‌اید، مثل حذف عکس‌های خانوادگی یا تغییر فایل‌های حساس 😬.

در اجلاس Open Source Summit در آمریکای شمالی در مینیاپولیس، در پی گفتگو با Bob Kline، با پروژه جدیدی به نام agent-substrate آشنا شدم. نکته‌ای که بلافاصله توجه‌ام را جلب کرد این بود که agent-substrate می‌تواند عوامل را به‌صورت پویا بر اساس فراخوانی بیدار کند، به این معنی که تعداد بیشتری عامل می‌توانند روی همان زیرساخت مشترک اجرا شوند و در عین حال از مزایای ایزوله‌سازی sandbox بهره‌مند شوند 🤝. بلافاصله در تیم‌مان بررسی کردیم چگونه می‌توان این پروژه را با kagent و agentgateway یکپارچه کرد.

تفاوت بین این دو پروژه چیست؟

Agent-sandbox یک Custom Resource Definition (CRD) و کنترل‌کننده برای Kubernetes است که تحت چتر Kubernetes SIG Apps قرار می‌گیرد. تمرکز اصلی آن بر موارد زیر است: ارائه هویت‌های قوی برای عوامل، فراهم کردن ذخیره‌سازی پایدار که پس از راه‌اندازی مجدد باقی بماند، مدیریت چرخه حیات غلاف‌های sandboxed و تضمین امنیت و ایزوله‌سازی از طریق کنترلر Sandbox. به‌طور خلاصه، agent-sandbox روی اجرای امن، قابل مدیریت و بومی Kubernetes متمرکز است.

Agent-substrate اما پروژه‌ای مستقل است که هنوز جزئی از SIG یا دیگر پروژه‌های بنیادی بومی ابری نیست. این پروژه که بر بستر Kubernetes ساخته شده، فراتر از موضوع sandboxing حرکت می‌کند و روی مقیاس بالاتر، بهره‌وری بهتر منابع، اجرای با تأخیر کمتر و مدیریت چرخه حیات پویا برای عوامل تمرکز دارد.

درک من این است که agent-substrate بلوک‌های زمان اجرا را فراهم می‌کند تا بتوان عوامل هوش مصنوعی را با مقیاس بسیار بالا و به‌صورت امن اجرا کرد. به‌جای این‌که عامل‌ها همیشه به‌عنوان غلاف‌های در حال اجرا باقی بمانند، آن‌ها در غلاف‌های کارگر امن برای دوره‌های کوتاه اجرا می‌شوند، در زمان بی‌کاری معلق می‌گردند و بعداً می‌توانند روی هر کارگر موجود از سر گرفته شوند. چرخه حیات غلاف کارگر از عامل «بازیگر» که توسط صفحه کنترل agent-substrate مدیریت می‌شود جدا شده است؛ در این مدل عامل‌ها شبیه بارهای کاری serverless درخواستی عمل می‌کنند و از زمان‌های اجرا سبک مثل gVisor یا kata containers بهره می‌برند.

آیا وقتی agent-sandbox را داریم به agent-substrate نیاز هست؟ پاسخ من مثبت است. سندباکس کردن عوامل لازم اما کافی نیست. در خوشه‌های Kubernetes که منابع محدودند، نمی‌توان همه عوامل را دائماً روشن نگه داشت؛ بسیاری از عوامل فقط در مواقعی خاص مفید هستند و نگه داشتن همیشگی آن‌ها هدررفت منابع را به دنبال دارد. این دوگانگی بین هدر دادن منابع یا چرخش مداوم غلاف‌ها مقیاس‌پذیری را محدود می‌کند.

اینجاست که agent-substrate اهمیت پیدا می‌کند: در حالی که agent-sandbox امنیت، ایزوله و مدیریت چرخه حیات را فراهم می‌کند، agent-substrate روی تراکم، کارایی و مقیاس‌پذیری عملیاتی تمرکز می‌کند، در حالی که مدل اجرای امن را حفظ می‌کند. می‌توان آن را به‌عنوان عملیاتی‌سازی ناوگان عوامل در مقیاس بزرگ در نظر گرفت — نه تنها امن، بلکه از نظر اقتصادی به‌صرفه.

ادغام agent-substrate با kagent ساده و مطلوب است، چون kagent گردش‌کار مبتنی بر YAML و شفافیتی را ارائه می‌دهد که می‌توان با آن وضعیت خوشه را دقیقاً بازتولید کرد. با بهره‌ای که agent-substrate در کارایی می‌آورد، می‌توانیم تعداد زیادی نماینده را با استفاده از یک مجموعه مشترک از منابع کارگر پشتیبانی کنیم. به‌جای تخصیص یک پاد اختصاصی برای هر عامل، از استخرها و قالب‌های کارگر مشترک استفاده می‌کنیم تا عوامل در صورت تقاضا به‌صورت پویا اجرا شوند ⚙️.

من خودم AIRE agent را به‌روزرسانی کردم تا از agent-substrate به‌عنوان runtime استفاده کند؛ این امکان را داد که عوامل تنها در زمان نیاز فراخوانی شوند، بدون این‌که همیشه روشن باقی بمانند. به‌علاوه، چندین عامل AIRE با مهارت‌های متفاوت می‌توانند یک گروه کارگری یا حتی یک پاد را به اشتراک بگذارند، که نتیجه‌اش سیستمی کارآمدتر است: عوامل بر حسب تقاضا در دسترس‌اند، مصرف منابع بیکار به‌طور قابل‌توجهی کاهش می‌یابد و نیاز به افزایش و کاهش دائمی پادها کمتر می‌شود.

برای مثال، شش عامل AIRE من به شش الگوی actor نگاشت می‌شوند اما تنها به یک Worker pod نیاز دارند تا زمانی که همزمان اجرا نشوند. اگر همزمانی افزایش یابد، کافی است استخر کارگر (مثل kagent-default) را به‌صورت افقی اسکیل کنم تا کپی‌های بیشتری از کارگرها اضافه شود.

جمع‌بندی نهایی: agent-sandbox و agent-substrate به مسائل مرتبط اما متفاوت پاسخ می‌دهند. Agent-sandbox می‌پرسد: چگونه عامل‌ها را به‌طور ایمن اجرا کنیم؟ Agent-substrate می‌پرسد: چگونه عامل‌ها را نه فقط ایمن، بلکه کارآمد و در مقیاس اجرا کنیم؟ با گسترش استفاده از عوامل هوش مصنوعی در محیط‌های Kubernetes و توجه ویژه به هزینه‌های AI، باید از اتصال بیش از حد چرخه حیات عامل به پادها اجتناب کنیم. امنیت، هویت، ایزوله و کنترل‌های خط‌مشی ضروری‌اند، اما در کنار آن به یک مدل runtime نیاز داریم که اجازه دهد صدها یا هزاران عامل در حالت غیرفعال منتظر فراخوانی بمانند بدون این‌که صدها یا هزارها پاد بی‌حرکت مصرف منابع کنند. آینده متعلق به عامل‌هایی است که نه تنها امن، بلکه قابل‌توسعه، کارآمد و زودگذر هستند 🔮.

منابع اضافی: شروع به کار با kagent و agent-substrate؛ شیرجه عمیق در agent-substrate از Christian Posta؛ بررسی نقشه‌راه پروژه agent-substrate.