Chat to niewłaściwy interfejs dla agentów AI

Chat to dobry prymityw wejściowy, ale złe środowisko operacyjne dla agentów. Gdy oprogramowanie działa w czasie — utrzymując stan, wywołując narzędzia, podejmując decyzje, ponosząc porażki i odzyskując sprawność — interfejs musi przejść od konwersacji do operacji. Poniższe sześć wzorców interfejsu definiuje, czego faktycznie wymagają powierzchnie kontrolne agentów.

Większość agentów AI jest dostarczana jako okna czatu. Claude Code to konwersacja terminalowa. Cursor to konwersacja w edytorze. Codex uruchamia konwersacje w chmurze. Devin opakowuje konwersację wokół przeglądarki, terminala i edytora. Rama konwersacyjna jest tak dominująca, że „rozmowa z AI” stała się synonimem „korzystania z AI”. Metafora miała sens, gdy model interakcji opierał się na schemacie prompt-odpowiedź: pytasz, AI odpowiada, oceniasz. Jedna tura. Dwie tury. Może dziesięć.

Metafora załamuje się w momencie, gdy agenty działają autonomicznie.

Moja pętla Ralph uruchamia Claude Code przez całą noc. Świeży kontekst w każdej iteracji, pamięć systemu plików między sesjami, hooki zatrzymania zapobiegające przedwczesnemu zakończeniu. Pojedyncze nocne uruchomienie generuje 8-15 iteracji, każda z pełnym oknem kontekstowym 200K tokenów. System dostarczył 3455 linii produkcyjnego kodu Python w ramach wielu nienadzorowanych sesji.¹ Nadzorowanie tych sesji poprzez przewijany transkrypt czatu wymagałoby czytania tysięcy linii przeplatanych wywołań narzędzi, diffów plików i śladów rozumowania. Nikt tego nie robi. Nikt nie jest w stanie tego robić. Interfejs czatu załamuje się pod ciężarem autonomicznego działania.

Praktycy uczą się, że metafora czatu jest błędna. Codex od OpenAI działa bezgłowo w chmurze i zwraca ukończoną pracę. Claude Routines od Anthropic wykonują wielokrokowe przepływy pracy z sesjami do przeglądu. Devin dzieli ekran na panele przeglądarki, terminala, edytora i czatu. Każdy produkt odchodzi od czystej konwersacji w kierunku czegoś bardziej operacyjnego. Żaden nie dotarł do pełnego rozwiązania. Przepaść między „czatem z diffami plików” a „dashboardem operacji agentowych” pozostaje największym nierozwiązanym problemem UX w narzędziach AI.

Pięć sposobów, w jakie chat zawodzi w przypadku agentów

Brak osi czasu śledzenia

90-minutowa sesja agenta generuje setki zdarzeń: odczyty plików, zapisy plików, polecenia bash, zapytania wyszukiwania, spawny sub-agentów, zdarzenia kompakcji i kroki rozumowania. Chat prezentuje te zdarzenia jako liniowy przewijany strumień konwersacji. Format uniemożliwia odpowiedź na pytanie „co się wydarzyło między 30. a 45. minutą?” bez czytania wszystkiego pomiędzy.

Mój system hooków przechwytuje 15 typów zdarzeń w ramach każdego wywołania narzędzia, produkując ustrukturyzowaną telemetrię, której interfejs czatu nie wyświetla.² Telemetria istnieje. Wizualizacja nie. Gdy debuguję nieudaną sesję nocną, przeszukuję pliki logów poleceniem grep. Nie przewijam czatu.

Oś czasu śledzenia prezentowałaby zdarzenia jako filtrowalną, skalowalną sekwencję. Pokaż mi tylko zapisy plików. Pokaż mi tylko polecenia bash, które zmodyfikowały system plików. Pokaż mi punkty decyzyjne, w których agent wybrał ścieżkę A zamiast ścieżki B. Rejestratory danych lotu nie prezentują zdarzeń z kokpitu jako transkryptu rozmowy. Interfejsy agentów też nie powinny.

Brak powierzchni przeglądu uprawnień

Model uprawnień Claude Code przerywa konwersację, aby poprosić o zatwierdzenie. „Zezwolić na to polecenie bash?” pojawia się w linii z rozumowaniem agenta, a użytkownik musi przełączyć kontekst z czytania analizy na ocenę ryzyka. Model przerywania sprawdza się w sesjach interaktywnych. Całkowicie zawodzi w przypadku operacji autonomicznych, gdzie agent potrzebuje zbiorczych zatwierdzeń i uprawnień z podziałem na poziomy ryzyka.

Moich 95 hooków funkcjonuje jako programowa warstwa uprawnień. Polecenia z białej listy przechodzą bezgłośnie. Zablokowane wzorce zatrzymują wykonanie. Hooki rozwiązują problem automatyzacji, ale rozwiązują go kodem, nie interfejsem.³ Interfejs bramki uprawnień prezentowałby oczekujące zatwierdzenia w kolejce, posortowane według poziomu ryzyka, z zatwierdzeniem lub odrzuceniem jednym kliknięciem. Operacje wysokiego ryzyka (force push, wdrożenia produkcyjne, polecenia destrukcyjne) byłyby wyświetlane inaczej niż operacje niskiego ryzyka (odczyty plików, zapytania wyszukiwania). Interfejs komunikowałby ryzyko zanim użytkownik oceni treść.

Brak przeglądarki pamięci

Kompakcja kontekstu wymazuje to, co agent wiedział. Okno 200K tokenów wypełnia się, system podsumowuje wcześniejsze tury, a informacje znikają. Moje pomiary z 50 sesji wykazały degradację jakości wyjściowej przy około 60% wykorzystania kontekstu, na długo przed tym, zanim twardy limit uruchomił kompakcję.⁴ Badania nad degradacją pamięci agentów z Microsoft Research i Salesforce potwierdziły problem strukturalny: średni spadek wydajności o 39% z interakcji jednoturowej do wieloturowej w 15 LLMach i ponad 200 000 symulowanych konwersacji.⁵

Użytkownik nie ma wglądu w to, co przetrwało kompakcję, a co nie. Czy agent zapomniał kontrakt API ustalony 40 minut temu? Czy graf zależności modułów przetrwał ostatnie podsumowanie? Interfejs czatu nie zapewnia sposobu, aby odpowiedzieć na te pytania. Przeglądarka pamięci pokazywałaby, co agent aktualnie trzyma w kontekście, co zostało skompaktowane, co utracono, a co utrzymuje się w pamięci systemu plików. Wzorzec pętli Ralph oparty na systemie plików jako pamięci kompensuje straty z kompakcji, ale operator wciąż nie może sprawdzić pamięci roboczej agenta bez czytania surowych plików stanu.

Brak miernika budżetu kontekstu

Zużycie tokenów jest niewidoczne. Użytkownik nie wie, czy okno kontekstowe jest wypełnione w 40% czy w 90%. Pierwszym sygnałem wyczerpania jest pogorszona jakość wyjściowa: zapomniane instrukcje, powtarzane sugestie, tunelowa wizja jednego pliku tam, gdzie agent minutę wcześniej utrzymywał spójność wielu plików.⁴ Zanim użytkownik to zauważy, szkoda jakościowa nawarstwiła się przez kilka tur.

Miernik budżetu kontekstu pokazywałby na żywo zużycie tokenów, prognozowane wyczerpanie na podstawie bieżącego tempa konsumpcji oraz próg kompakcji. Miernik funkcjonowałby jak wskaźnik paliwa — nie informacja sprawdzana co sekundę, ale taka, którą warto znać przed rozpoczęciem długiej operacji. „To zadanie refaktoryzacji zużyje około 80K tokenów; pozostały budżet to 60K” zmienia kalkulus decyzyjny użytkownika. Żaden interfejs czatu nie dostarcza tej informacji.

Brak audytu wywołań narzędzi

Agenty wykonują narzędzia z argumentami, których użytkownik nigdy nie sprawdza. Polecenie bash się uruchamia. Plik zostaje zapisany. API zostaje wywołane. Interfejs czatu pokazuje nazwę narzędzia i czasami wyjście. Argumenty (faktyczne instrukcje, które agent wysłał do narzędzia) przewijają się w formacie zniechęcającym do czytania.

Tryb awarii nie jest hipotetyczny. Deweloper zgłosił, że Claude Code usunął całą konfigurację produkcyjną, włącznie z bazą danych i 2,5 roku snapshotów.⁶ Agent wykonał destrukcyjne polecenia bez monitu potwierdzenia i bez przechwycenia przez hooki. Incydent sprowadza się do awarii interfejsu: użytkownik nie mógł skutecznie przejrzeć tego, co agent zamierzał zrobić.

Powierzchnia audytu wywołań narzędzi prezentowałaby każde wywołanie z pełnymi argumentami, diffy przed/po dla operacji na plikach oraz możliwość wycofania dla akcji destrukcyjnych. Bramka dowodowa rozwiązuje problem weryfikacji na warstwie wyjściowej, wymagając od agentów cytowania ścieżek plików, wyników testów i nazw wzorców przed oznaczeniem pracy jako ukończonej. Audyt wywołań narzędzi rozwiązuje ten sam problem na warstwie wykonania — zanim dojdzie do szkody.

Sześć wzorców interfejsu dla operacji agentowych

Chat zawodzi, ponieważ traktuje operacje agentowe jako konwersację. Poniższe sześć wzorców traktuje operacje agentowe jako operacje.

1. Oś czasu śledzenia

Chronologiczny log zdarzeń z rozwijalnym szczegółem w każdym węźle. Każdy odczyt pliku, zapis pliku, polecenie bash, wywołanie API, spawn sub-agenta, zdarzenie kompakcji i punkt decyzyjny pojawia się na osi czasu. Użytkownicy filtrują według typu zdarzenia, przybliżają zakresy czasowe i rozwijają poszczególne zdarzenia, aby zobaczyć pełne argumenty i wyjścia.

Oś czasu rozwiązuje problem „co się stało?”, na który odpowiedź post-hoc wymaga obecnie analizy plików logów. Problem niewidocznego agenta (agenty zużywające zasoby bez widoczności dla operatora) staje się widoczny, gdy każda akcja pojawia się na filtrowalnej osi czasu z dołączonymi metrykami zużycia zasobów.

2. Interfejs bramki uprawnień

Kolejka oczekujących zatwierdzeń, posortowana według poziomu ryzyka. Operacje destrukcyjne (wdrożenia produkcyjne, migracje baz danych, force push) wyświetlają się z czerwonymi obramowaniami i wymagają jawnego potwierdzenia. Operacje tylko do odczytu (odczyty plików, zapytania wyszukiwania) zatwierdzają się automatycznie lub zbiorczo. Powierzchnia bramki pokazuje pełne polecenie, ocenę ryzyka i podany przez agenta powód działania.

Zbiorcze zatwierdzanie transformuje model interakcji. Zamiast przerywać konwersację 47 razy podczas sesji nocnej, bramka uprawnień prezentuje „oto 12 operacji, które przekroczyły próg automatycznego zatwierdzenia” na jednej powierzchni przeglądu. Użytkownik przetwarza wszystkie 12 w dwie minuty zamiast przełączać kontekst 12 razy w ciągu sześciu godzin.

3. Przeglądarka pamięci

Trzypanelowy widok: aktywny kontekst (co agent aktualnie przechowuje), skompaktowane podsumowania (co zostało podsumowane i kiedy) oraz pamięć systemu plików (co utrzymuje się na dysku między sesjami). Każdy panel jest przeszukiwalny. Użytkownicy mogą promować skompaktowane elementy z powrotem do aktywnego kontekstu lub oznaczać wspomnienia z systemu plików jako nieaktualne.

Przeglądarka czyni stan wiedzy agenta inspekcjonowalnym. Gdy agent produkuje wyjście sprzeczne z wcześniejszą decyzją, operator może sprawdzić, czy wcześniejsza decyzja przetrwała kompakcję. Problem degradacji pamięci agenta nie znika dzięki przeglądarce. Przeglądarka czyni degradację widoczną, diagnozowalną i częściowo odwracalną.

4. Miernik budżetu kontekstu

Licznik tokenów na żywo pokazujący bieżące wykorzystanie, prognozowane wyczerpanie na podstawie kroczącej stopy konsumpcji oraz próg kompakcji. Miernik zawiera rozbicie: ile tokenów to prompt systemowy, ile to historia konwersacji, ile to wyjścia narzędzi, ile to zawartość plików. Rozbicie ujawnia, dokąd idzie budżet. Często wyjścia narzędzi konsumują 60-70% okna.

Miernik zmienia zachowanie. Moje praktyki zarządzania oknem kontekstowym (proaktywna kompakcja, delegowanie do sub-agentów, pamięć oparta na systemie plików) wyłoniły się z pomiarów zużycia tokenów w 50 sesjach. Miernik na żywo udostępnia te same pomiary każdemu użytkownikowi w czasie rzeczywistym, przekształcając zarządzanie kontekstem z praktyki eksperckiej w widoczne ograniczenie zasobowe.

5. Przegląd wywołań narzędzi

Powierzchnia inspekcji dla każdego wywołania narzędzia. Operacje na plikach pokazują diffy przed/po. Polecenia bash pokazują pełne polecenie, katalog roboczy i kod wyjścia. Wywołania API pokazują ładunki żądania i odpowiedzi. Każde wywołanie narzędzia zawiera przycisk wycofania, który odwraca operację (dla operacji odwracalnych) lub oznacza operację do ręcznego przeglądu (dla nieodwracalnych).

Powierzchnia przeglądu pełni podwójną rolę: nadzór w czasie rzeczywistym podczas sesji interaktywnych oraz audyt post-hoc podczas uruchomień autonomicznych. Warstwa weryfikacji ciemnej fabryki bada, jak systemy autonomiczne radzą sobie z weryfikacją bez obecności człowieka. Przegląd wywołań narzędzi to dopełnienie po stronie obecności człowieka, zapewniające powierzchnię inspekcji umożliwiającą świadome zaufanie zamiast ślepego zaufania.

6. Kolejka nadzorcza

Dashboard wieloagentowy, który wyświetla priorytetowe alerty z równoczesnych sesji. Przy uruchamianiu wielu agentów (agent refaktoryzacji, agent pisania testów, agent dokumentacji) kolejka agreguje ich status, podświetla awarie i kieruje decyzje wymagające obecności człowieka na jedną powierzchnię.

Kolejka nadzorcza ma znaczenie, ponieważ użycie agentów skaluje się horyzontalnie. Jeden deweloper uruchamiający jednego agenta to konwersacja. Jeden deweloper uruchamiający pięciu agentów na pięciu zadaniach to operacje. Interfejsem dla operacji jest dashboard, nie pięć okien czatu. Kolejka priorytetyzuje według pilności: nieudane wdrożenie produkcyjne wypływa ponad pytanie o formatowanie dokumentacji.

Co istnieje dzisiaj

Żaden produkt nie zbudował pełnego dashboardu operacyjnego. Kilka zbudowało fragmenty.

Claude Code zapewnia najsilniejszą warstwę programową. Hooki przechwytują 15 typów zdarzeń z decyzjami zezwól/zablokuj/zmodyfikuj. Polecenie /cost pokazuje zużycie tokenów sesji. System kontekstowy CLAUDE.md zapewnia pamięć systemu plików. Jednak powierzchnią jest terminal. Brak wizualnej osi czasu. Brak kolejki uprawnień. Brak przeglądarki pamięci. Infrastruktura istnieje bez interfejsu.⁷

Cursor zbudował diffy inline — prymitywny przegląd wywołań narzędzi dla operacji na plikach. Powierzchnia diffów pokazuje stan przed/po i obsługuje akceptację/odrzucenie na poziomie fragmentu. Wzorzec jest poprawny, ale wąski: diffy obejmują zapisy plików, ale nie polecenia bash, wywołania API ani koordynację sub-agentów.

Devin jest najbliżej interfejsu operacyjnego. Produkt dzieli ekran na panele przeglądarki, terminala, edytora i czatu — cztery powierzchnie, które jednocześnie uwidaczniają różne aspekty zachowania agenta. Układ panelowy potwierdza, że sama konwersacja jest niewystarczająca. Panele to jednak prezentacja, nie powierzchnie kontrolne. Użytkownik obserwuje pracę agenta. Użytkownik nie kolejkuje zatwierdzeń, nie sprawdza stanu pamięci ani nie audytuje argumentów narzędzi przez te panele.⁸

Claude Routines (wydane w kwietniu 2026) wykonują wielokrokowe przepływy pracy w tle, a każde uruchomienie tworzy sesję Claude Code do przeglądu. Powierzchnia przeglądu to oś czasu śledzenia: użytkownicy mogą przejrzeć, co agent zrobił po fakcie. Wzorzec potwierdza główny argument: wykonanie w tle wymaga powierzchni przeglądu, która nie jest oryginalną konwersacją.⁹

OpenAI Codex działa bezgłowo w chmurze i zwraca diffy. Model izolacji (środowisko piaskownicy na zadanie) eliminuje część obaw dotyczących uprawnień, ale wprowadza inne: użytkownik rezygnuje z całego nadzoru w czasie rzeczywistym w zamian za bezpieczeństwo piaskownicy. Brak dedykowanej osi czasu operacji czy powierzchni kontrolnej w trakcie uruchomienia. Kompromis ujawnia napięcie projektowe: pełna autonomia lub pełny nadzór, bez niczego pomiędzy.¹⁰

Przepaść między tymi częściowymi rozwiązaniami a kompletnym interfejsem operacji agentowych definiuje kolejną granicę konkurencyjności w narzędziach AI.

Interfejsy agentowe to problem projektowy

Powyższe wzorce interfejsu to specyfikacje inżynieryjne. Ich budowa wymaga osądu projektowego, którego same specyfikacje inżynieryjne nie są w stanie zapewnić.

Jak bramka uprawnień komunikuje ryzyko? Sam kolor nie wystarczy: czerwony oznacza „niebezpieczne” w kontekstach zachodnich i „dobrobyt” w kontekstach chińskich. Wybór ikon, pozycjonowanie przestrzenne, timing animacji i ton komunikatów — wszystko to wpływa na ocenę ryzyka przez użytkownika. Bramka uprawnień, która technicznie wyświetla właściwe informacje, ale komunikuje je źle, nauczy użytkowników klikać „zatwierdź” bez czytania. Bramka staje się teatrem.

Jak miernik budżetu kontekstu komunikuje pilność bez wywoływania lęku? Miernik, który zmienia kolor na czerwony przy 80% wykorzystania, może powodować przedwczesną kompakcję. Miernik, który pozostaje zielony do 95%, może powodować niespodziewane wyczerpanie. Krzywe progowe, przejścia kolorów i timing powiadomień to decyzje smaku z konsekwencjami operacyjnymi.

Jak oś czasu śledzenia radzi sobie z gęstością informacji bez przytłaczania użytkownika? 12-godzinna sesja autonomiczna generuje tysiące zdarzeń. Pokazanie wszystkich zdarzeń produkuje szum. Filtrowanie do „ważnych” zdarzeń wymaga, by interfejs zdefiniował ważność — osąd, który różni się w zależności od użytkownika, zadania i trybu awarii.

To te same pytania, na które Dieter Rams odpowiedział dla elektroniki użytkowej, a Kenya Hara dla projektowania informacji. Pytania nie są nowe. Domena jest. Smak to system techniczny: ograniczenia, kryteria oceny, rozpoznawanie wzorców i kontrole spójności, które rozkładają się na infrastrukturę inżynieryjną. Projektowanie interfejsów agentowych wymaga infrastruktury smaku zbudowanej celowo dla operacyjnego UX: zdolności komunikowania ryzyka, pewności, niepewności i stanu zasobów poprzez powierzchnie wizualne wspierające szybkie podejmowanie decyzji pod presją czasu.

Firma, która potraktuje interfejsy agentowe jako problem projektowy, a nie tylko listę funkcji, zbuduje interfejs, któremu operatorzy zaufają przy obciążeniach produkcyjnych. Firma, która potraktuje interfejsy agentowe wyłącznie jako problem inżynieryjny, zbuduje dashboard technicznie kompletny i operacyjnie bezużyteczny.

Następna fosa

Model nie jest fosą. Modele frontierowe zbiegają się w benchmarkach wydajności co kwartał. Fine-tuning i RLHF produkują znaczące, ale tymczasowe zróżnicowanie. Warstwa modeli to wyścig towarowy z malejącymi zwrotami z przewagi konkurencyjnej.¹¹

Warstwa kontekstu też nie jest fosą. Okna kontekstowe rosną ze 128K do 200K do 1M tokenów. Każdy dostawca dorównuje w ciągu miesięcy. Dłuższy kontekst poprawia możliwości, ale nie różnicuje produktów.

Powierzchnia kontrolna jest fosą. Interfejs, który czyni autonomiczne operacje agentowe widocznymi, audytowalnymi i zarządzalnymi — ta powierzchnia decyduje, któremu produktowi przedsiębiorstwa zaufają przy obciążeniach produkcyjnych. Adopcja korporacyjna wymaga odpowiedzi na pytania, na które interfejsy czatu odpowiedzieć nie mogą: Co agent zrobił? Dlaczego agent to zrobił? Jakie uprawnienia agent wykonał? Jakie zasoby agent zużył? Czy mogę wycofać działania agenta? Czy mogę udowodnić audytorowi, co agent zrobił?

To nie są pytania o promptowanie. To pytania operacyjne. Produkt, który na nie odpowie, wygrywa rynek, który się liczy.

Moich 95 hooków to programowa odpowiedź na te pytania, zbudowana z terminala, egzekwowana przez skrypty powłoki, utrzymywana przez pliki konfiguracyjne. Hooki działają. Hooki reprezentują również stan sztuki: infrastrukturę poziomu eksperckiego, której żaden nieekspert nie odtworzy. Bramka dowodowa weryfikuje wyjście agenta. Warstwy obserwowalności niewidocznego agenta monitorują zachowanie agenta. Praktyki zarządzania oknem kontekstowym utrzymują jakość sesji. Każdy system odpowiada na realną potrzebę operacyjną. Każdy system istnieje jako kod, nie jako interfejs.

Następny krok jest oczywisty. Przekształcić kod w powierzchnie kontrolne. Przekształcić hooki w bramkę uprawnień. Przekształcić telemetrię w oś czasu śledzenia. Przekształcić pomiary tokenów w miernik budżetu. Przekształcić pamięć systemu plików w przeglądalny stan wiedzy. Przekształcić bramkę dowodową w powierzchnię przeglądu wywołań narzędzi.

Infrastruktura już istnieje. Interfejs nie. Budowa interfejsu to problem projektowy, problem inżynieryjny i problem smaku. Zespół, który rozwiąże wszystkie trzy, dostarczy produkt definiujący następną erę inżynierii AI.

FAQ

Dlaczego nie ulepszyć czatu lepszym formatowaniem?

Lepsze formatowanie leczy objaw. Problem jest strukturalny: chat to sekwencyjne medium z dopisywaniem na końcu. Operacje agentowe wymagają inspekcji z dostępem swobodnym (skok do dowolnego zdarzenia), widoków równoczesnych (stan pamięci obok wywołań narzędzi) i interakcji zbiorczej (zatwierdzenie pięciu operacji naraz). Ulepszenia formatowania w ramach czatu (zwijane sekcje, kolorowanie składni, diffy inline) pomagają marginalnie, ale nie mogą zapewnić dostępu swobodnego, widoków równoczesnych ani interakcji zbiorczej w ramach przewijanego transkryptu.

Czy bramki uprawnień mogą zastąpić ludzki osąd?

Bramki uprawnień wspomagają osąd, prezentując decyzje w formacie zoptymalizowanym pod kątem szybkiej i trafnej oceny. Bramka nie decyduje. Bramka wyświetla decyzję z kontekstem: pełne polecenie, poziom ryzyka, rozumowanie agenta i potencjalny wpływ. Człowiek decyduje szybciej i trafniej, ponieważ interfejs redukuje obciążenie poznawcze wydobywania istotnych informacji z przewijanej konwersacji.

Jak te wzorce odnoszą się do agentów niekodujących?

Każdy wzorzec jest uniwersalny. Agent obsługi klienta potrzebuje osi czasu śledzenia (co agent powiedział klientowi?), bramki uprawnień (czy agent może wydać zwrot powyżej 500 USD?) i audytu wywołań narzędzi (jakie zapytania bazodanowe agent wykonał?). Agent badawczy potrzebuje przeglądarki pamięci (jakie źródła agent skonsultował?) i miernika budżetu kontekstu (ile pojemności wyszukiwania pozostaje?). Wzorce są niezależne od domeny, ponieważ wyzwania operacyjne (widoczność, uprawnienia, pamięć, zasoby, audyt, nadzór) są uniwersalne dla autonomicznego oprogramowania.

Źródła