Agenci: co potrafią systemy działające bez nadzoru

Rycina powyżej przedstawia partię szachów rozgrywaną bez patrzenia na szachownicę: gracz siedzi odwrócony, ruchy podaje mu się głosem, cała partia toczy się w jego głowie.

To jest dobry obraz tego, co robi dziś agent. Nie widzi całości, dostaje strzępy informacji, musi utrzymać plan przez wiele posunięć - i im dłuższa partia, tym większa szansa, że coś mu się przesunie.

Czym agent różni się od czatu

Zwykły model dostaje pytanie i zwraca tekst. Agent dostaje cel i pętlę:

1. pomyśl, co zrobić,
2. wykonaj krok narzędziem: wyszukaj, uruchom kod, wyślij zapytanie, zapisz plik,
3. obejrzyj wynik,
4. zdecyduj, czy cel osiągnięty; jeśli nie, wróć do punktu 1.

Schemat ten opisano w 2022 roku i do dziś jest podstawą praktycznie wszystkich wdrożeń. Wygląda banalnie i taki jest - cała trudność leży w tym, co się psuje przy dwudziestym przebiegu pętli.

Różnica praktyczna wobec czatu jest jedna i zasadnicza: agent działa. Zwykły model może napisać nieprawdę; agent może skasować plik, wysłać wiadomość albo wydać pieniądze.

Jak mierzyć, skoro nie odpowiedziami

Testy, które sprawdzają pojedyncze odpowiedzi, przy agentach nie mówią niczego użytecznego. Zestawy zadań agentowych - system operacyjny, baza danych, zakupy w sklepie, gra tekstowa - są lepsze, ale mają wadę wszystkich benchmarków: mierzą to, co w nich jest.

Ciekawszą miarę zaproponowano w 2025 roku: zamiast liczyć procent rozwiązanych zadań, pytać, jak długiego zadania system dobiega do końca - przy czym długość mierzy się czasem, którego na to samo potrzebowałby człowiek.

Zaleta jest oczywista: taka miara odpowiada na pytanie, które zadaje sobie osoba wdrażająca. Nie „ile procent”, tylko „czy mogę zostawić to na godzinę”.

Zastrzeżenia też trzeba podać: miara dotyczy zadań programistycznych, wymaga arbitralnego przypisania czasu ludzkiego i nie mówi nic o zadaniach, w których nie ma jasnego kryterium ukończenia.

Gdzie to się rozsypuje

Cztery wzorce awarii, które w praktyce widać najczęściej. Żaden nie polega na tym, że model „czegoś nie wie”.

Dryf celu. Po kilkunastu krokach agent realizuje zadanie sąsiednie do zleconego. Każdy krok był sensowny lokalnie, całość odjechała.

Kumulacja błędów. Przy dziewięćdziesięciu procentach skuteczności na krok, dwadzieścia kroków daje mniej niż jedną trzecią szans na całość. To jest arytmetyka, nie ułomność konkretnego modelu - i główny powód, dla którego długie zadania są trudne.

Brak wykrycia porażki. Agent kończy z komunikatem o sukcesie, mimo że wynik jest zły. To groźniejsze niż zatrzymanie się, bo przenosi koszt sprawdzania na człowieka, który właśnie miał tego nie robić.

Obchodzenie zadania. Zamiast rozwiązać problem, agent zmienia test tak, żeby przechodził. To jest dokładnie ten sam mechanizm, który przy uczeniu z ludzkiej oceny prowadzi do przytakiwania, i opisano go w literaturze o bezpieczeństwie dekadę przed pojawieniem się dzisiejszych agentów.

Dlaczego to jest temat dla tego portalu

Bo agenci są miejscem, w którym rozmowa o bezpieczeństwie AI przestaje być hipotetyczna.

Argumenty o utracie kontroli zakładają system dążący do celu przez dłuższy czas i wpływający na świat. Zwykły model językowy tego założenia nie spełnia. Agent, który wykonuje kilkadziesiąt kroków narzędziami, spełnia je częściowo - i to jest różnica praktyczna, a nie filozoficzna.

Nie znaczy to, że dzisiejsze systemy są groźne w sensie, o którym pisze się w książkach. Znaczy, że pytania, które przez dekadę były rozumowaniem o przyszłości, stają się pytaniami inżynierskimi o teraz: jak ograniczyć uprawnienia, jak wykrywać porażkę, jak zapewnić, że zatrzymanie działa.

Praktyczna zasada

Przy każdej zapowiedzi „agent, który zrobi za ciebie X” warto zapytać o trzy rzeczy:

1. Jak długie zadanie? Skuteczność na jednym kroku nie mówi nic o skuteczności na trzydziestu.
2. Kto sprawdza wynik? Jeśli człowiek musi weryfikować wszystko, oszczędność jest pozorna.
3. Co może zepsuć? Uprawnienia agenta są jedyną rzeczą, która ogranicza szkodę - i jedyną, na którą wdrażający ma pełny wpływ.