Kotlin Multiplatform dla agentów AI: zalety, wady i pułapki wydawnicze
Rozwój dwóch aplikacji w Kotlin Multiplatform (KMP) przez pół roku ujawnił kluczowe aspekty: ponowne wykorzystanie kodu na Androidzie, iOS, Webie, Desktopie i backendzie. Wspólny kod agentów zintegrowano z bibliotekami takimi jak koog, mcp-sdk i cactus dla lokalnych modeli. Doświadczenie pokazało balans między ekosystemem JVM a ograniczeniami specyficznymi dla platform.
Główne zalety KMP
KMP pozwala scentralizować logikę biznesową agentów, minimalizując duplikację. Ekosystem JVM zapewnia SDK dla dostawców LLM, a Compose Multiplatform upraszcza UI z hot reload. Natywne buildy dla Androida używają Skia na iOS, choć Desktop opiera się na wrapperach JAR.
Kluczowe zalety:
- Ponowne wykorzystanie kodu niespecyficznego dla 4+ platform.
- Bogaty ekosystem JVM dla agentów i modeli.
- Stabilny Kotlin z kompatybilnością wsteczną.
- Compose z minimalnymi błędami UI.
Oczywiste ograniczenia
Obsługa wielu platform wymaga expect/actual dla kodu specyficznego. Aplikacje desktopowe rosną z powodu JVM i Swing, Web jest w fazie beta z błędami bibliotek i problemami SEO. Debugowanie na iOS jest prymitywne, interoperacyjność ze Swifem ustępuje JVM. UI na Desktopie wygląda nienaturalnie.
Niewidoczne problemy rozwoju
Wydawnicze buildy dla macOS zajmują tygodnie: dwa app ID (JRE i aplikacja), trzy klucze podpisu, oddzielne konfiguracje dla sklepów i DMG z notaryzacją (15+ min na iterację). Natywne biblioteki komplikują proces — zasoby w JAR przed podpisem, wyjątki ProGuard, kompatybilność z Catalina (63% użytkowników). Wymagane JDK 18+ dla TestFlight, oddzielne buildy aarch64/x86_64.
Przykład typowych kroków dla wydawczego builda:
- Generowanie kluczy dla sklepu i dystrybucji bezpośredniej.
- Umieszczanie natywnych zasobów w JAR.
- Obsługa obfuskacji ProGuard.
- Notaryzacja i debugowanie (5+ iteracji).
- Testy na starych macOS.
Brak seniorów specjalizujących się w KMP: rynek skupia się na jednej platformie. Zadania specyficzne dla platform (certyfikaty MinCyfry na iOS vs Android) wymagają głębokiej wiedzy. LLM nie zawsze radzą sobie z niestandardowymi scenariuszami.
Konflikty bibliotek i nadmierne inżynierstwo
Alfa-biblioteki jak kotlinx-datetime powodują konflikty wersji: koog ciągnie niekompatybilne zależności od września. Web bez Dispatchers.IO zmusza do rozgałęzień we wspólnym kodzie. Wyodrębnienie logiki JVM dla Android/Desktop/backend dodaje kompilację, ale duplikuje refleksję.
Rozwiązania wyboru:
- Wspólny kod JVM: kompromis w refleksji.
- Loggery: balans logback i rozsądne domyślne ustawienia.
- Testy: mockowanie kontekstu Android, dodanie Desktop dla prędkości.
XCode pogarsza ból: wolny start, spowalniające autouzupełnianie, losowe błędy. 6,1% deweloperów na Stack Overflow 2025 gotowych to znosić.
Realizacja agentów AI bez frameworków
Odrzucenie langchain4j (wzdęty, legacy) i koog (alfa, zbędne zależności jak simpleOpenAIExecutor). Własna realizacja: graf węzłów z callbackami na przejścia, klasyfikacja, RAG, obsługa błędów. Zalety — kontrola, minimum zależności, bez OpenTelemetry.
Graf agenta wizualizowany do debugowania, trwałość state machine ręczna dla odporności na awarie. Testowanie skupione na wspólnym kodzie, z mockami specyficznymi dla platform.
Testowanie kodu agentów
Testy uruchamiane na iOS/Android z mockowaniem kontekstu. Desktop przyspiesza CI. Problemy: długa kompilacja, Dispatchers zależne od platformy. Rekomendacja — testy jednostkowe na JVM, integracyjne na docelowych platformach.
Co ważne:
- Wydanie macOS wymaga tygodni na klucze, notaryzację, ProGuard.
- Konflikty wersji alfa-bibliotek (kotlinx-datetime) psują buildy.
- Własne agenty prostsze niż frameworki dla niszowych LLM (GigaChat).
- Seniorzy KMP to rzadkość; potrzebne umiejętności specyficzne dla platform.
- XCode — wąskie gardło dla rozwoju iOS.
Ogólne doświadczenie: KMP się opłaca dla agentów AI z backendem JVM, ale wydanie i iOS/Web wymagają ekspertyzy.
— Editorial Team
Brak komentarzy.