Agent na okularach z Android XR to system z czterech części

Serwisant patrzy na pompę i mówi: „zapisz odczyt drgań i zamów zestaw uszczelek”. Dwie sekundy później okulary pokazują potwierdzenie. Wygląda to na jedną czynność jednego asystenta. Za nią stoją co najmniej cztery miejsca, w których działało oprogramowanie, dwie tożsamości, które mogły to zamówienie zatwierdzić, i jeden system ewidencyjny, w którym leży teraz zapotrzebowanie, którego nikt nie wpisał.

Na tym polega problem inżynierski z agentami na okularach. Interfejs sprawia, że wydają się jedną rzeczą. W rzeczywistości to system rozproszony — i psuje się jak system rozproszony.

Gdzie naprawdę działa agent

Android XR to platforma Google dla urządzeń XR — gogli, okularów z wyświetlaczem i okularów audio — rozwijana z Samsungiem i Qualcommem, z Gemini jako warstwą asystenta. Dla okularów Android XR SDK oferuje Jetpack Projected, w którym aplikacja działa na urządzeniu gospodarzu, na przykład telefonie, i przesyła swoje doświadczenie do okularów, oraz Jetpack Compose Glimmer do interfejsów na przezroczystych wyświetlaczach. Opis okularów audio idzie dalej: okulary są głosem i kamerą, a agent wykonuje wieloetapowe zadania na telefonie, w tle.

Niektóre okulary mają też własną moc obliczeniową. XREAL Aura, pierwsze wycenione urządzenie z Android XR w klasie okularów z wyświetlaczem, łączy się z krążkiem obliczeniowym o mocy 48 TOPS dla zadań AI. Prawdziwe wdrożenie może więc obejmować cztery warstwy.

Infografika

Cztery warstwy, jedna czynność

1. 01OkularyKamera, mikrofony, wyświetlacz. Rejestrują i pokazują; część przetwarzania może dziać się lokalnie.
2. 02Urządzenie gospodarzTelefon albo jednostka obliczeniowa z waszą aplikacją i, często, wywołaniami narzędzi agenta.
3. 03ChmuraModel asystenta i usługi, które wywołuje. Co dokładnie dzieje się tutaj, nie jest w pełni opisane.
4. 04Wasze systemyUtrzymanie ruchu, magazyn, zamówienia, ewidencja. Tu czynność przestaje być propozycją.

Ani Google, ani XREAL nie rozpisują publicznie, ile pracy agenta dzieje się na urządzeniu, ile na telefonie, a ile w chmurze. Warto to powiedzieć wprost, bo wokół tego architektura musi podjąć pierwszą decyzję. Traktujcie to jako niewiadomą, projektujcie tak, żeby odpowiedź mogła się zmienić, i pytajcie dostawców na piśmie.

Gdzie takie systemy się psują

Zgoda na patrzenie myli się ze zgodą na działanie. Platforma pyta użytkownika o dostęp do kamery i mikrofonu. Nie wie, że zamówienie uszczelek powyżej pewnej kwoty wymaga zgody kierownika. Ta granica musi żyć w waszej warstwie narzędzi, w kodzie, a nie w prompcie — to ten sam argument co w tekście na czyich uprawnieniach działa wasz agent.

Tożsamość jest niejednoznaczna. Zamówienie składa serwisant, konto telefonu, konto usługowe za waszą aplikacją czy asystent? Jeśli na każdej warstwie odpowiedź jest inna, nikt potem nie powie, kto to zrobił.

Zapis jest rozsiany po dostawcach. Okulary, asystent platformy, wasza aplikacja i zaplecze trzymają — jeśli w ogóle — fragmenty. Analiza incydentu potrzebuje jednej sekwencji: co zostało zobaczone, co usłyszane, co zaproponowane, kto potwierdził, co się zmieniło.

Zachowanie bez sieci jest nieokreślone. Na obiekcie ze słabym zasięgiem połączenie między warstwami zerwie się w środku zadania. Bez decyzji, co trafia do kolejki, czego się odmawia i co słyszy użytkownik, agent albo zadziała dwa razy, albo po cichu wcale.

Aktualizacje przychodzą z czterech stron. Oprogramowanie okularów, asystent platformy, wasza aplikacja i model za nią mogą zmieniać się każde we własnym rytmie. Agent, który przeszedł ewaluację w maju, w październiku jest już innym systemem.

Co budować zamiast

Każda czynność za waszą własną warstwą narzędzi. Agent może proponować cokolwiek; zrobić może tylko to, na co pozwala typowane, uprawnione narzędzie po waszej stronie, z limitami kwot i krokiem potwierdzenia przy wszystkim, czego nie da się cofnąć. Funkcje asystenta platformy mogą służyć do czytania i nawigacji bez prawa zapisu w waszych systemach.

Jedna tożsamość przez cały łańcuch. Tożsamość samego użytkownika, przeniesiona z urządzenia gospodarza do waszych systemów, z agentem działającym w jego imieniu i w granicach jego uprawnień. Konta urządzeń i konta usługowe do transportu, nigdy jako autor czynności biznesowej.

Własny rejestr decyzji. Zapisujcie na swojej granicy, co agent dostał, co zaproponował, kto potwierdził i co się zmieniło — niezależnie od tego, co trzyma platforma. To zapis, którego będziecie potrzebować w pierwszej godzinie incydentu z agentem, i ten, o który warto prosić każdego dostawcę.

Od pierwszego dnia jako usługa zarządzana. Zestaw ewaluacyjny uruchamiany przy każdej aktualizacji którejkolwiek z czterech warstw, ewidencja urządzeń, sposób na zawężenie tego, co agent może robić bez nadzoru, i ktoś odpowiedzialny za całość. Do tej ciągłej pracy służą usługi zarządzane AI.

Zacznijcie od urządzenia gospodarza. Dzięki Jetpack Projected i emulatorowi okularów warstwę narzędzi, tożsamość, rejestr i reguły pracy bez sieci można zbudować i przetestować na telefonach już teraz. Okulary mogą przyjść później — co ma znaczenie w Polsce, bo pierwsza fala okularów z wyświetlaczem, takich jak XREAL Aura, do Europy jeszcze nie trafia. Jak zaplanować pierwszy pilotaż, opisujemy w tekście okulary z agentem AI: od pokazu do pilotażu, który coś dowodzi.

Test na dziś

Wybierzcie jedną czynność, którą chcielibyście powierzyć agentowi na okularach. Na jednej stronie zapiszcie, która z czterech warstw widzi polecenie, która decyduje, pod jaką tożsamością czynność zostaje zapisana i gdzie leży rejestr. Jeśli w którejś linijce stoi „platforma to załatwia”, sprawdźcie w dokumentacji dostawcy, czy na pewno. Tam, gdzie dokumentacja milczy, zaczyna się wasza praca projektowa.

Nasza część

W inżynierii agentów AI budujemy tę część, która należy do was: warstwę narzędzi, uprawnienia, zestaw ewaluacyjny i rejestr decyzji, zaprojektowane tak, żeby urządzenie albo platforma pod spodem mogły się zmienić. Nie odsprzedajemy sprzętu ani platform. Więcej o predictes na stronie głównej.