Renderowanie agenta do interfejsu (A2UI) w Jetpack Compose zapewnia implementację protokołu A2UI, umożliwiając agentom AI generowanie rozbudowanych, interaktywnych interfejsów użytkownika, które renderują natywne komponenty Compose – bez wykonywania dowolnego kodu. Ta biblioteka mapuje protokół JSON A2UI na elementy pierwotne Compose, zachowując idiomatyczne zarządzanie stanem i zapewniając precyzyjną reaktywność opartą na systemie stanu Compose Snapshot.
Biblioteka renderująca A2UI w Compose oferuje te możliwości:
- Wysoka wydajność reaktywności (
androidx.a2ui.compose:compose-runtime): zapewnia szczegółowe aktualizacje interfejsu dzięki wykorzystaniu systemu stanu migawek Compose, co gwarantuje, że tylko określone komponenty, na które mają wpływ aktualizacje agenta strumieniowania lub interakcje użytkownika, są ponownie komponowane. - Elastyczne interfejsy API komponentów i dostosowywanie
(
androidx.a2ui.compose:compose-ui): zapewnia ustrukturyzowany wzorzec definiowania katalogów implementacji komponentów, które mapują schematy protokołu JSON na natywny interfejs Compose. Umożliwia to tworzenie komponentów, które obsługują progresywne renderowanie, niestandardowe stany wczytywania subkomponentów, animowane przejścia i dwukierunkowe powiązania danych, które mogą przesyłać dane z powrotem do agenta. - Rdzeń niezależny od systemu projektowania: warstwy środowiska wykonawczego i renderowania interfejsu są niezależne od konkretnego systemu projektowania, co umożliwia tworzenie niestandardowych katalogów dla systemu projektowania aplikacji lub korzystanie z dostarczonego katalogu podstawowego.
- Prawidłowe obsługiwanie halucynacji AI (
androidx.a2ui:a2ui-modeliandroidx.a2ui:a2ui-engine): zapewnia weryfikację schematu, aby przechwytywać nieprawidłowo sformatowane ładunki, zanim dotrą do modeli stanu, prawidłową obsługę błędów za pomocą stanów błędów komponentów oraz automatyczne raportowanie błędów do agenta w celu samokorekty. - Wbudowany katalog podstawowy
(
androidx.compose.material3:material3-a2ui): zawiera gotową do użycia implementację katalogu podstawowego z komponentami Material 3, która obsługuje progresywne renderowanie i motywy Material na podstawie renderera Compose.
Architektura wysokiego poziomu
Każdy interfejs A2UI jest oparty na katalogu komponentów. Zamiast generować dowolny kod interfejsu lub wymyślać niezarejestrowane komponenty, katalog działa jak umowa, która określa konkretne elementy interfejsu, właściwości i funkcje dostępne dla agenta. Katalog deklaruje komponenty, a agent używa ich do tworzenia interfejsów użytkownika.
Aby obsługiwać ten model, moduł renderujący A2UI w Compose oddziela podstawowy silnik renderowania niezależny od systemu projektowania od konkretnych implementacji katalogu w artefaktach Jetpack opisanych wcześniej i udostępnia dedykowane interfejsy API do testowania w androidx.a2ui.compose:compose-ui-testing.
Ewolucja protokołu i zgodność interfejsu API
Renderowanie A2UI w Compose obsługuje obecnie wersję 0.9.1 specyfikacji A2UI.
Warstwy interfejsu użytkownika (androidx.a2ui.compose:compose-ui) i środowiska wykonawczego (androidx.a2ui.compose:compose-runtime) udostępniają interfejs API dla aplikacji i katalogów komponentów, a warstwa danych (androidx.a2ui:a2ui-model i androidx.a2ui:a2ui-engine) zarządza analizowaniem i przetwarzaniem wiadomości w sposób dostosowany do wersji protokołu. Ponieważ te biblioteki są częścią Androida X, obowiązują w ich przypadku ścisłe reguły zgodności binarnej. Na przykład po osiągnięciu przez publiczny interfejs API stabilnej wersji 1.0.0 nie będą wprowadzane żadne zmiany powodujące niezgodność w publicznych interfejsach API, takich jak klasy i interfejsy.
Renderowanie A2UI w Compose wykorzystuje te strategie, aby obsługiwać ewolucję protokołu.
Rozwijanie interfejsów API renderowania interfejsu i środowiska wykonawczego
W miarę rozwoju protokołu A2UI lub dodawania do niego nowych funkcji interfejsy API renderowania obsługują te zmiany w następujący sposób:
- Dodawanie funkcji do interfejsu API bez powodowania błędów: gdy wprowadzana jest nowa funkcja, staje się ona częścią podstawowego interfejsu publicznego (np.
A2uiComponentlubA2uiCatalog) z domyślną implementacją. Dzięki temu komponenty aplikacji mogą być nadal kompilowane i działać bez zmian. - Zmiany powodujące niezgodność oznaczają, że starsze interfejsy stają się przestarzałe: jeśli przyszła aktualizacja protokołu wprowadzi zmianę powodującą niezgodność, stare, niezgodne interfejsy (np.
A2uiComponent) zostaną wycofane, a nowe interfejsy, takie jakA2uiComponentV2, zostaną wprowadzone i będą obsługiwane równolegle.
Katalog wersji i schematy komponentów
Definicja schematu katalogu jest powiązana z konkretną wersją protokołu. Wraz z rozwojem protokołu zmienia się definicja katalogu i zwiększa się jego wersja. Implementacje komponentów w tej „następnej” wersji mogą korzystać z zaktualizowanych interfejsów API renderowania.
Aby umożliwić bezproblemową migrację, klient może zadeklarować wiele obsługiwanych wersji katalogu, które agent otrzymuje podczas negocjacji możliwości.