Projektowanie agentowe to projektowanie powierzchni sterowania

Większość prac nad interfejsami AI nadal traktuje agenta jak inteligentniejsze pole tekstowe. Projektowanie agentowe wychodzi z innego założenia: gdy oprogramowanie może działać w czasie, wywoływać narzędzia, operować na plikach, wydawać pieniądze albo zmieniać stan produkcyjny, problem projektowy staje się problemem powierzchni sterowania.

Projektowanie agentowe to dyscyplina czynienia autonomicznego oprogramowania widocznym, możliwym do przerwania, sprawdzalnym, odwracalnym i godnym zaufania. Produktem nie jest zapis czatu. Produktem jest powierzchnia, która pozwala człowiekowi zrozumieć, co robi agent, zdecydować, co agent może zrobić dalej, oraz zweryfikować, co już zrobił.

Ta rama ma znaczenie, bo agenci nie zawodzą tak jak zwykłe formularze, panele analityczne czy copiloci. Formularz zawodzi w chwili wysyłania. Panel analityczny zawodzi, pokazując nieaktualne dane. Copilot zawodzi, proponując zły tekst. Agent zawodzi w ruchu: wybiera niewłaściwą ścieżkę, sięga po złe narzędzie, pomija właściwy dowód, traci kontekst, nadużywa uprawnień, kończy za wcześnie albo odnosi lokalny sukces, osłabiając cały produkt.

Projektowanie musi przejść od dopracowywania poleceń wejściowych do kontroli operacyjnej.

TL;DR

Projektowanie agentowe nie jest abstrakcyjnym „UX dla AI”. To projektowanie powierzchni sterowania dla systemów, które działają. Microsoft ujął interakcję człowieka z AI jako odrębny problem projektowania interfejsów wiele lat przed dzisiejszymi agentami programistycznymi, a Google PAIR podtrzymuje ten sam, skoncentrowany na człowieku wątek w swoich wytycznych projektowania AI.¹² Współczesne produkty agentowe jeszcze wyraźniej pokazują tę potrzebę: OpenAI opisuje Codex jako agenta chmurowego działającego w odizolowanym środowisku, a Claude Code udostępnia punkty zaczepienia, które mogą przechwytywać wywołania narzędzi przed wykonaniem.⁵⁴

Praktyczny wniosek: produkty agentowe potrzebują powierzchni dla statusu, uprawnień, śladów wykonania, pamięci, dowodów, cofania zmian i nadzoru. Czat może pozostać wejściem. Nie może pozostać całym interfejsem.

Najważniejsze wnioski

Dla projektantów produktów: - Najpierw należy zaprojektować stan agenta, dopiero potem wejście na polecenie użytkownika. Użytkownik musi wiedzieć, czy agent planuje, działa, jest zablokowany, czeka, weryfikuje czy zakończył pracę. - Przegląd uprawnień należy traktować jako podstawowy przepływ pracy. Ryzykowne wywołanie narzędzia nie powinno wyglądać jak zwykła przerwa w czacie.

Dla twórców agentów: - Należy rejestrować wystarczająco dużo szczegółów wykonania, aby zasilić powierzchnię śladu. Same nazwy narzędzi nie wystarczą; powierzchnia potrzebuje argumentów, wyników, stanów zakończenia, ścieżek plików i skutków ubocznych. - Przerwanie i odzyskiwanie powinny być funkcjami pierwszej klasy. Użytkownik powinien móc wstrzymać, sprawdzić, przekierować, cofnąć albo rozgałęzić pracę agenta bez czytania całego zapisu rozmowy.

Dla zespołów wdrażających agentów: - Nie należy mierzyć jakości interfejsu płynnością czatu. Należy mierzyć, czy operator potrafi odpowiedzieć: co się wydarzyło, dlaczego, z jakim uprawnieniem i na podstawie jakich dowodów? - W obiegu musi pozostać wyczucie jakości. Poprawne działanie agenta nadal może zaszkodzić spójności, godności użytkownika albo jakości produktu.

Użytkownik się zmienił

Użytkownik produktu agentowego nie jest już tylko osobą wpisującą polecenia. Staje się operatorem.

Osoba wpisująca polecenie prosi o odpowiedź. Operator nadzoruje proces. Pierwszą interesuje, czy tekst brzmi dobrze. Drugiego interesuje, czy system operował na właściwych plikach, użył właściwych źródeł, zachował właściwe ograniczenia i zatrzymał się we właściwym momencie.

Ta różnica zmienia interfejs. Pola poleceń użytkownika optymalizują ekspresję. Powierzchnie sterowania optymalizują stan, ryzyko, czas i dowód.

Tradycyjne oprogramowanie może ukrywać proces, ponieważ użytkownik bezpośrednio wyzwala większość zmian stanu. Przycisk mówi „Wyślij”. Użytkownik klika. Aplikacja wysyła. Oprogramowanie agentowe wstawia między intencję a działanie środowisko wykonawcze podejmujące decyzje. Użytkownik prosi o wynik, a system wybiera drogę. Interfejs musi ujawnić wystarczająco dużo tej drogi, aby użytkownik mógł pozostać odpowiedzialny za rezultat.

Wytyczne Microsoftu dotyczące interakcji człowieka z AI wskazują właśnie ten kierunek. Obejmują zachowanie systemów AI w czasie interakcji: ustawianie oczekiwań, dopasowanie do kontekstu społecznego, pokazywanie statusu, wspieranie korekty i obsługę awarii.¹ Dawna lekcja bardzo dobrze pasuje do agentów, ale agenci podnoszą stawkę, bo zachowanie AI nie kończy się już na rekomendacji. Może stać się wywołaniem narzędzia.

Projektowanie agentowe zaczyna się od stanu

Dobre projektowanie agentowe pokazuje stan, zanim poprosi o zaufanie.

Agent ma więcej stanów niż „myśli” i „gotowe”:

Większość produktów czatowych sprowadza te stany do jednej animowanej ikony ładowania. Taka ikona mówi tylko, że system się nie zatrzymał. Nie mówi, czy agent czyta, pisze, czeka, ponawia próbę czy utknął.

Stan agenta potrzebuje bogatszego słownika. Powierzchnia powinna pokazywać bieżącą fazę, ostatnie znaczące działanie, następne zamierzone działanie oraz powód, dla którego agent jeszcze nie skończył. Dobra powierzchnia statusu zmniejsza niepokój użytkownika, bo zastępuje tajemnicę możliwym do sprawdzenia ruchem.

Trudnym pytaniem projektowym jest gęstość informacji. Poważny agent może wygenerować tysiące zdarzeń podczas długiego przebiegu. Pokazanie każdego zdarzenia tworzy szum. Ukrycie każdego zdarzenia tworzy ślepe zaufanie. Powierzchnia sterowania musi domyślnie podsumowywać i rozwijać szczegóły na żądanie.

Uprawnienie jest tworzywem projektowym

Uprawnienie nie jest stroną ustawień. Jest jednym z głównych tworzyw projektowania agentowego.

Agenci działają dzięki upoważnieniu udzielonemu przez użytkownika. Zapisy do plików, polecenia powłoki, działania w przeglądarce, wywołania API, kroki wdrożeniowe, operacje płatnicze i działania wpływające na klientów niosą różne poziomy ryzyka. Interfejs musi uczynić to ryzyko czytelnym w chwili decyzji.

Dokumentacja punktów zaczepienia w Claude Code pokazuje pierwotną formę tej idei: punkt zaczepienia PreToolUse może sprawdzić polecenie Bash i zwrócić decyzję odrzucającą destrukcyjną operację, zanim wywołanie narzędzia zostanie wykonane.⁴ Ten mechanizm pokazuje kształt projektowy. Powierzchnia sterowania może sortować oczekujące operacje według ryzyka, pokazywać pełne polecenie albo pełny ładunek narzędzia, wyjaśniać powód wywołania i pozwalać użytkownikowi zatwierdzić, odrzucić, odroczyć albo przepisać żądanie.

Kluczowa zmiana: przegląd uprawnień powinien stać się kolejką, a nie przerwą.

Przerwy działają przy jednej lub dwóch decyzjach. Zawodzą, gdy agent wykonuje 40 operacji w ramach długiego zadania. Kolejka uprawnień pozwala użytkownikowi grupowo zatwierdzać działania niskiego ryzyka, wstrzymywać działania wysokiego ryzyka i oceniać cały profil ryzyka w jednym miejscu. Użytkownik przestaje być szarpany między czytaniem prozy agenta a oceną poleceń.

Prezentacja ryzyka również wymaga wyczucia. Czerwone obramowania, ikony ostrzegawcze i tarcie modalne mogą pomóc. Mogą też nauczyć użytkownika ślepego zatwierdzania alertów, jeśli wszystko wygląda pilnie. Interfejs powinien rezerwować wizualny alarm dla działań nieodwracalnych albo widocznych na zewnątrz. Wyszukiwanie tylko do odczytu nie powinno wyglądać tak samo jak migracja produkcyjnej bazy danych.

Ślad wykonania to nowa architektura informacji

Projektowanie agentowe potrzebuje architektury śladu wykonania.

Ślad to uporządkowany zapis tego, co zrobił agent: polecenia użytkownika, wywołania narzędzi, argumenty, przeczytane pliki, zmienione pliki, uruchomione polecenia, otwarte źródła, wyniki testów, decyzje dotyczące uprawnień, ponowienia prób i końcowe dowody. Zapis czatu może zawierać fragmenty tego rekordu, ale zapis czatu nie jest architekturą informacji. Jest tylko przewijanym strumieniem.

Powierzchnia śladu powinna szybko odpowiadać na cztery pytania:

Ta powierzchnia łączy się bezpośrednio z bramką dowodową. Odpowiedź końcowa mówiąca „testy przeszły” powinna wskazywać polecenie testowe i status zakończenia. Publiczny artykuł cytujący pracę naukową powinien wskazywać dokładne źródło i zgodność twierdzenia. Raport migracji deklarujący parytet powinien wskazywać konkretną ścieżkę użytkownika, która nadal działa.

Najnowsze badania nad śladami wykonania wskazują ten sam kierunek. W artykule Ślady wykonania agentów są kontraktem środowiska wykonawczego argumentowałem, że odpowiedź końcowa jest najsłabszą jednostką zaufania. Ślad jest mocniejszy, ponieważ zachowuje drogę od intencji przez działanie do dowodu.

Pamięć potrzebuje przeglądarki

Projektowanie agentowe potrzebuje także projektowania pamięci.

Agenci przenoszą kontekst w czasie. Część kontekstu mieści się w aktywnym oknie. Część w skompaktowanych podsumowaniach. Część w plikach, notatkach, magazynach wektorowych, bazach danych albo instrukcjach projektu. Część znika. Użytkownik rzadko widzi granicę.

Ta niewidoczność tworzy błąd projektowy. Gdy agent zaprzecza wcześniejszej decyzji, użytkownik nie wie, czy agent się nie zgodził, zapomniał, źle podsumował czy nigdy nie wczytał właściwej pamięci. Czat sprawia, że pamięć wydaje się ciągła nawet wtedy, gdy środowisko wykonawcze zmieniło to, co model może zobaczyć.

Przeglądarka pamięci powinna odsłaniać trzy warstwy:

Taka przeglądarka nie musi ujawniać prywatnego łańcucha rozumowania. Musi ujawniać pamięć operacyjną: instrukcje, ograniczenia, ścieżki źródeł, decyzje, artefakty i podsumowania, których system użyje do kierowania przyszłym działaniem.

Wyszukiwanie należy do tej samej rodziny projektowej. Wynik grep/vector z poprzedniego artykułu pokazał, że jakość wyszukiwania zależy od środowiska wykonawczego, ścieżki dostarczenia wyników i zdolności modelu do domknięcia pętli narzędzia, a nie tylko od retrievera.⁶ Jeśli wyszukiwanie żyje w środowisku wykonawczym, jego widoczność należy do interfejsu. Użytkownik musi wiedzieć, czego agent szukał, co pominął, co otworzył i dlaczego następne zapytanie się zmieniło.

Nadzór nie jest mikrozarządzaniem

Produkty agentowe często przedstawiają nadzór człowieka jako tarcie. Silne projektowanie agentowe traktuje nadzór jako produkt.

NIST opisuje AI Risk Management Framework jako sposób włączania kwestii wiarygodności do projektowania, rozwoju, używania i oceny systemów AI.³ To sformułowanie ma znaczenie. Wiarygodność nie pojawia się tylko na etapie trenowania modelu. Pojawia się w czasie projektowania, używania i oceny.

W przypadku agentów nadzór oznacza, że użytkownik może:

• zobaczyć, co robi agent;
• przerwać przed nieodwracalnym działaniem;
• sprawdzić ścieżkę dowodową;
• wrócić do działania po nieudanej odnodze;
• porównać alternatywne odnogi;
• zatwierdzić albo odrzucić końcowy artefakt;
• zrozumieć, co pozostaje niezweryfikowane.

Mikrozarządzanie każe użytkownikowi zatwierdzać każde naciśnięcie klawisza. Nadzór daje użytkownikowi właściwą kontrolę na właściwym poziomie. Starszy inżynier nie musi obserwować każdego odczytu pliku. Musi jednak zobaczyć proponowaną migrację bazy danych, ponowienie po nieudanym teście, zmienione publiczne twierdzenie albo polecenie dotykające stanu produkcyjnego.

Dobre powierzchnie nadzoru zachowują płynność, odsuwając szczegóły niskiego ryzyka z głównego toru i wyciągając na pierwszy plan momenty wysokiego ryzyka. Wyzwanie projektowe nie brzmi „więcej widoczności”. Brzmi: skalibrowana widoczność.

Warstwa wyczucia jakości nadal ma znaczenie

Projektowanie agentowe może spełnić każde wymaganie operacyjne i nadal sprawiać złe wrażenie.

Kolejka uprawnień może pokazywać właściwe fakty, a jednocześnie sprawiać, że użytkownik czuje się karany. Oś śladu może zawierać każde zdarzenie, a mimo to uniemożliwiać zrozumienie. Przeglądarka pamięci może pokazywać każdy zapisany element i przez bałagan niszczyć zaufanie użytkownika. Miernik statusu może mówić prawdę, a jednocześnie sprawiać wrażenie, że system jest zepsuty.

Wyczucie jakości decyduje, jak powierzchnia niesie ryzyko, pewność, niepewność i dowód. Wyczucie jakości jest systemem technicznym: ograniczenia, kryteria oceny, rozpoznawanie wzorców i spójność. Projektowanie agentowe potrzebuje wszystkich czterech.

Ograniczenia decydują, co agent może zrobić bez przeglądu. Kryteria oceny decydują, co końcowy artefakt musi udowodnić. Rozpoznawanie wzorców wychwytuje przepływ pracy, który wygląda na udany, ale sprawia wrażenie kruchego. Spójność pyta, czy praca agenta poprawiła cały produkt, czy tylko domknęła lokalne zadanie.

To ostatnie pytanie nabiera znaczenia, gdy agenci stają się tańsi. AI czyni wyniki obfitymi. Obfitość podnosi wartość odmowy, redakcji, spójności i wyczucia jakości. Najlepszy interfejs agentowy nie będzie maksymalizował liczby działań. Pomoże operatorowi zdecydować, które działania zasługują na wykonanie.

Minimalna lista kontrolna projektowania agentowego

Na początek potrzeba siedmiu powierzchni:

Żadna z tych powierzchni nie wymaga interfejsu science fiction. Pierwsza wersja może składać się ze zwykłych tabel, rozwijanych wierszy i nudnych filtrów. Efektowna animacja ma mniejsze znaczenie niż uczciwy stan. Powierzchnia sterowania powinna szybko mówić prawdę.

Pytanie projektowe dla każdej funkcji agentowej staje się proste:

Co człowiek musi zobaczyć, zdecydować, przerwać albo zweryfikować, zanim następne działanie agenta stanie się rzeczywiste?

Jeśli interfejs nie potrafi odpowiedzieć na to pytanie, produkt nadal opiera się na teatrze zaufania.

Krótkie podsumowanie

Projektowanie agentowe to projektowanie powierzchni sterowania. Czat pozostaje przydatny jako prymityw wejściowy, ale autonomiczna praca wymaga widocznego stanu, kolejek uprawnień, śladów wykonania, przeglądarek pamięci, powierzchni dowodowych, kontrolek odzyskiwania i widoków nadzoru. Microsoft, Google i NIST wskazują na projektowanie AI skoncentrowane na człowieku oraz wiarygodność jako odpowiedzialność produktu, a nie tylko właściwość modelu.¹²³ Narzędzia agentowe konkretyzują tę tezę: środowisko wykonawcze już ma punkty zaczepienia, kontenery, ślady, pliki, polecenia i skutki uboczne.⁴⁵ Interfejs musi uczynić te części czytelnymi.

Zwycięskim produktem agentowym nie będzie ten z najbardziej ujmującym czatem. Wygra produkt, który da operatorom najczytelniejszą, najostrzejszą i najbardziej godną zaufania powierzchnię do pracy autonomicznej.

FAQ

Czy projektowanie agentowe różni się od AI UX?

Tak. AI UX obejmuje każde doświadczenie wykorzystujące uczenie maszynowe albo generatywną AI. Projektowanie agentowe obejmuje systemy, które działają w czasie. Różnicą jest sprawczość: wywołania narzędzi, uprawnienia, zmiany stanu, pamięć, skutki uboczne i odzyskiwanie. Te właściwości wymagają powierzchni sterowania, a nie tylko pomocnej treści albo wejścia na polecenie użytkownika.

Czy każdy produkt agentowy potrzebuje wszystkich siedmiu powierzchni?

Nie. Zakres powierzchni powinien odpowiadać ryzyku. Asystent pisania o niskiej stawce może potrzebować statusu, dowodów i historii wersji. Agent programistyczny albo operacyjny potrzebuje uprawnień, śladu, odzyskiwania, pamięci i nadzoru. Agent wpływający na klientów potrzebuje jeszcze mocniejszych kontroli audytu i zatwierdzania.

Dlaczego nie trzymać wszystkiego w czacie?

Czat jest sekwencyjny i tylko dopisywany. Nadzór nad agentem wymaga dostępu losowego, filtrowania, porównywania, przeglądu zbiorczego i kontroli stanu. Składane bloki czatu mogą poprawić czytelność, ale nie zastąpią kolejki uprawnień, osi śladu, przeglądarki pamięci ani powierzchni odzyskiwania.

Jaką powierzchnię sterowania zbudować jako pierwszą?

Najpierw należy zbudować ślad. Bez śladu każda inna powierzchnia staje się zgadywaniem. Ślad dostarcza danych dla dowodów, uprawnień, odzyskiwania, audytu i nadzoru. Produkt może zacząć od prostej tabeli zdarzeń i z czasem ulepszać projekt.

Bibliografia