Jeśli zestawisz nowy system kontenerów Apple z Dockerem, będzie on wyglądał na wadliwy. Każda instancja zużywa od 270 do 400 MB pamięci RAM, zanim zrobi cokolwiek pożytecznego. Start jest od czterech do dziesięciu razy wolniejszy niż w przypadku kontenera Linux. Spróbuj udostępnić wolumen między wieloma kontenerami, a natrafisz na ścianę: jedno podpięcie, jedno pudełko. Dla każdego, kto szuka lżejszego sposobu na uruchamianie mikroserwisów, te liczby wydają się dyskwalifikujące.
Ale Apple nie buduje zamiennika dla Twojego stosu deweloperskiego. Buduje klatkę dla kodu, któremu nie możesz ufać.
Ta jedna zmiana perspektywy zmienia każdą skargę w celowy kompromis.
Błędny punkt odniesienia
Nasza branża spędziła ostatnią dekadę na wyciskaniu z kontenerów maksymalnej gęstości. Chcieliśmy, aby dziesiątki aplikacji żyły na jednym jądrze, współdzieliły strony pamięci, montowały te same wolumeny i uruchamiały się w milisekundach. Docker rozwiązał ten problem genialnie. Cały cel polegał na tym, aby abstrakcja między oprogramowaniem a sprzętem była jak najcieńsza.
Projekt Apple działa odwrotnie. Poświęca gęstość na rzecz separacji. Zamienia współdzielone zasoby na sztywne ściany. Patrząc na to jak na infrastrukturę dla klastra Kubernetes, matematyka jest absurdalna. Nigdy nie upakowałbyś floty węzłów, w której każdy kontener niesie ze sobą ćwierć gigabajta narzutu i własne jądro. Ekonomia po prostu się tu nie spina.
Chyba że obciążeniem jest agent AI, którego właśnie zaprosiłeś na swój laptop.
Zmienił się lokator
W 2026 roku najbardziej niebezpiecznym kodem uruchamianym na Twojej maszynie nie jest zatruty pakiet npm czy podejrzane rozszerzenie przeglądarki. To autonomiczny agent programistyczny. Te narzędzia czytają Twój kod, przepisują funkcje, wykonują polecenia powłoki i wywołują zewnętrzne API. Podejmują tysiące decyzji na minutę w tym samym drzewie katalogów, w którym znajdują się Twoje klucze SSH, pliki środowiskowe i pliki cookie przeglądarki.
Tradycyjne modele uprawnień załamują się przy takiej prędkości. Nie możesz wymagać od człowieka zatwierdzania każdego odczytu pliku, każdego uruchomienia podprocesu i każdego żądania sieciowego. Taki łańcuch zatwierdzeń zamienia pięciominutowe zadanie refaktoryzacji w godzinę pilnowania agenta. Z drugiej strony, przyznanie agentowi nieograniczonego dostępu do katalogu domowego nie jest znacznie bezpieczniejsze niż oddanie laptopa nieznajomemu.
Jedynym rozsądnym punktem wyjścia jest traktowanie agenta jako wrogiego domyślnie, a następnie udowadnianie bezpieczeństwa poprzez strukturę, a nie nadzieję.
System kontenerów Apple został zaprojektowany właśnie z myślą o takim podejściu.
Gdy izolacja staje się celem
Każdy kontener Apple działa wewnątrz własnej lekkiej maszyny wirtualnej z własnym jądrem. W świecie Dockera to herezja. Tracisz deduplikację pamięci. Tracisz szybkość współdzielonego jądra. Tracisz możliwość upakowania setek obciążeń na jednym hoście.
Jednak dla jednego niepewnego agenta, prywatne jądro jest fortecą. Jeśli agent ucieknie ze swojej przestrzeni użytkownika, wciąż uderzy w barierę, która nie jest Twoim jądrem hosta. To nie jest marnotrawstwo. To funkcja, za którą płacisz tymi dodatkowymi megabajtami.
Apple rozszerza tę barierę poprzez mcpbridge. Wiele agentów programistycznych komunikuje się z narzędziami za pomocą Model Context Protocol, czyli MCP. Apple przechwytuje te polecenia i tłumaczy je na XPC – ten sam framework międzyprocesowy, który wymusza drobnoziarniste uprawnienia w macOS i iOS. Agent nie może po prostu grzebać w Twoim systemie plików czy sieci. Każde wywołanie narzędzia musi najpierw przejść przez rygorystyczny model uprawnień Apple.
Istnieje również podział obliczeń. Same ciężkie modele AI pozostają na Macu hosta, działając na Neural Engine. Kontener nie marnuje pamięci RAM na wagi modeli czy silniki wnioskowania. Przechowuje jedynie narzędzia agenta i przestrzeń roboczą. Ciężka praca odbywa się tam, gdzie sprzęt jest najsilniejszy; ryzykowna praca odbywa się wewnątrz klatki.
Ta architektura odzwierciedla filozofię stojącą za inicjatywą Apple Private Cloud Compute. Nie proś użytkownika, aby ufał Ci ślepo. Udowodnij istnienie bariery poprzez strukturę samego systemu.