اگر سیستم کانتینر جدید اپل را با Docker بسنجید، خراب به نظر میرسد. هر نمونه قبل از انجام هر کار مفیدی، ۲۷۰ تا ۴۰۰ مگابایت رم مصرف میکند. سرعت راهاندازی چهار تا ده برابر کندتر از یک کانتینر لینوکس است. سعی کنید یک Volume را بین چندین کانتینر به اشتراک بگذارید و با یک دیوار سخت برخورد خواهید کرد: یک اتصال، یک جعبه. برای هر کسی که به دنبال راهی سبکتر برای اجرای میکروسرویسهاست، این اعداد عوامل بازدارنده محسوب میشوند.
اما اپل در حال ساخت جایگزینی برای استک توسعه شما نیست؛ بلکه در حال ساخت زندانی برای کدهایی است که نمیتوانید به آنها اعتماد کنید.
همین تغییر در دیدگاه، هر شکایت را به یک انتخاب آگاهانه تبدیل میکند.
معیار سنجش اشتباه
صنعت ما ده سال گذشته را صرف فشردهسازی کانتینرها برای افزایش تراکم کرده است. ما میخواستیم دهها اپلیکیشن روی یک کرنل واحد زندگی کنند، صفحات حافظه را به اشتراک بگذارند، Volumeهای یکسان را سوار کنند و در عرض چند میلیثانیه بالا بیایند. Docker این مشکل را به شکلی درخشان حل کرد. هدف اصلی این بود که انتزاع بین نرمافزار و سختافزار تا حد ممکن نازک شود.
طراحی اپل در مسیر دیگری حرکت میکند. اپل تراکم را فدای جداسازی میکند. اپل منابع مشترک را با دیوارهای سخت معاوضه میکند. اگر این سیستم را به عنوان زیرساختی برای یک کلاستر Kubernetes در نظر بگیرید، محاسبات آن مضحک است. شما هرگز مجموعهای از نودها را بهگونهای بستهبندی نمیکنید که هر کانتینر با یکچهارم گیگابایت سربار و کرنل مخصوص به خود همراه باشد. اقتصاد این کار اصلاً جور در نمیآید.
مگر اینکه بار کاری (workload)، یک عامل هوش مصنوعی باشد که تازه به لپتاپ خود دعوت کردهاید.
تغییر ماهیت تهدید
در سال ۲۰۲۶، خطرناکترین کدی که روی ماشین شما اجرا میشود، یک پکیج مسموم npm یا یک افزونه مشکوک مرورگر نیست؛ بلکه یک عامل کدنویسی خودگردان (autonomous coding agent) است. این ابزارها کدبیس شما را میخوانند، توابع را بازنویسی میکنند، دستورات شل را اجرا میکنند و APIهای خارجی را فراخوانی میکنند. آنها در هر دقیقه هزاران تصمیم را در همان درخت دایرکتوریای میگیرند که کلیدهای SSH، فایلهای محیطی (environment files) و کوکیهای مرورگر شما در آن قرار دارند.
مدلهای سنتی مجوزدهی در برابر این سرعت فرو میپاشند. شما نمیتوانید از یک انسان بخواهید هر خواندن فایل، هر اجرای زیرفرآیند (subprocess) و هر درخواست شبکه را تأیید کند. آن زنجیره تأیید، یک کار بازنویسی (refactoring) پنج دقیقهای را به یک ساعت نظارت لحظهبهلحظه تبدیل میکند. با این حال، دادن دسترسی کامل به یک عامل به دایرکتوری Home، تفاوت چندانی با سپردن لپتاپ خود به یک غریبه ندارد.
تنها نقطه شروع منطقی این است که با عامل هوش مصنوعی بهصورت پیشفرض به عنوان یک موجود متخاصم برخورد کنید و سپس امنیت را به جای امید داشتن، از طریق ساختار اثبات کنید.
سیستم کانتینر اپل دقیقاً برای همین طرز فکر مهندسی شده است.
وقتی هدف، جداسازی است
هر کانتینر اپل درون یک VM سبکوزن با کرنل مخصوص به خود اجرا میشود. در دنیای Docker، این یک بدعت است. شما قابلیت حذف دادههای تکراری در حافظه (memory deduplication) را از دست میدهید. سرعت یک کرنل مشترک را از دست میدهید. و توانایی بستهبندی صدها بار کاری روی یک میزبان واحد را از دست میدهید.
اما برای یک عامل غیرقابل اعتماد، یک کرنل خصوصی مانند یک دژ است. اگر عامل از فضای کاربری خود فرار کند، باز هم با مرزی برخورد میکند که کرنل میزبان شما نیست. این اتلاف منابع نیست؛ این همان ویژگیای است که شما با آن مگابایتهای اضافی برایش هزینه پرداخت میکنید.
اپل این مرز را از طریق mcpbridge گسترش میدهد. بسیاری از عوامل کدنویسی با استفاده از پروتکل بافت مدل یا MCP با ابزارها صحبت میکنند. اپل آن دستورات را رهگیری کرده و آنها را به XPC ترجمه میکند؛ همان فریمورک میان-فرآیندی که مجوزهای دقیق را در macOS و iOS اعمال میکند. عامل نمیتواند به سادگی به سیستم فایل یا شبکه شما دسترسی پیدا کند. هر فراخوانی ابزار ابتدا باید از مدل مجوزدهی سختگیرانه اپل عبور کند.
سپس بحث تقسیم محاسبات مطرح میشود. خود مدلهای سنگین هوش مصنوعی روی مک میزبان و بر روی Neural Engine اجرا میشوند. کانتینر رم خود را صرف وزنهای مدل یا موتورهای استنتاج (inference engines) نمیکند. کانتینر فقط ابزارهای عامل و فضای کار موقت را در خود جای میدهد. کار سنگین در جایی انجام میشود که سختافزار در قویترین حالت خود است؛ و کار پرخطر درون قفس انجام میشود.
این معماری بازتابدهنده فلسفه پشت ابتکار Private Cloud Compute اپل است. از کاربر نخواهید که کورکورانه به شما اعتماد کند؛ بلکه مرزها را با ساختار خودِ سیستم اثبات کنید.