Dryf celu w systemach agentowych
Automatyzacja tworzenia oprogramowania agentami AI stawia nowe wyzwania nie tylko w dziedzinie bezpieczeństwa. Modele LLM są dziś tak dobre, że AI często potrafi przejąć znaczną część projektowania zmian, implementacji i testowania oprogramowania. Jednak sprawność i jakość wykonywania poszczególnych zadań nie wystarcza, jeżeli cały proces przestaje prowadzić do zakładanego rezultatu.
Coraz lepsza jakość modeli LLM powoduje, że AI częściej zlecamy bardziej skomplikowane zadania. Wymagają one wieloetapowej realizacji, a nasza kontrola nad procesem i rezultatami przesuwa się na wyższy poziom. Nie sprawdzamy już implementacji poszczególnych klas, weryfikacji poszczególnych testów. Skupiamy się na dostarczeniu kontekstu, zdefiniowaniu celów, weryfikacji rezultatów działania, testach bezpieczeństwa. Proces rozwiązywania problemów przez AI staje się coraz bardziej automatyczny, a co za tym idzie decyzje podejmowane przez człowieka są coraz rzadsze i bardziej wysokopoziomowe. W takim procesie może ujawnić się dryf celu, którego skutki są tym dotkliwsze im później zostanie zaobserwowany.
Dryf celu nie musi objawiać się porzuceniem planu ani deklarowaniem fałszywych sukcesów. Może polegać na powstawaniu kolejnych, uzasadnionych lokalnie zadań, które finalnie nie doprowadzają jednak do rozstrzygnięcia. Arike i współautorzy badają dryf jako obserwowalne odchodzenie działań agenta od pierwotnie zadanego celu. Jeden z ich scenariuszy sprawdza, czy agent potrafi wrócić do celu nadrzędnego po realizacji celu pomocniczego [1]. W opisanym tu studium analizuję pokrewny problem w procesie programistycznym, nie zakładając jednak, że jego mechanizm jest identyczny z mechanizmem badanym w symulacji.
Lokalne postępy a brak realizacji celu. Studium przypadku.
W jednym z projektów zleciłem agentom AI poprawę procesu klasyfikacji i ekstrakcji danych z dokumentów nieustrukturyzowanych do istniejącego i niezmiennego modelu dziedzinowego. Zadanie obejmowało zmiany kodu i architektury oraz optymalizację promptów modeli wykorzystywanych przez ten proces. Opisywany dryf dotyczy pracy agentów tworzących oprogramowanie, natomiast wyniki ekstrakcji są jedną z miar jej wyników. W sumie zaplanowanych było 9 etapów E01-E09.
Dostępny był kontekst, zestaw danych typu Golden Set, początkowe wartości i cel do osiągnięcia oraz ograniczenia brzegowe. Niezależne testy pilnowały spójności modeli dziedzinowych i innych modułów zabezpieczając oprogramowanie przed niekontrolowanymi zmianami poza obszarem wyznaczonym agentom AI.
Agent miał możliwość tworzenia kolejnych zadań koniecznych do rozwiązania napotykanych problemów. Każde zadanie kończyło się raportem z wykonanych prac, testów, ograniczeń i decyzji wymagających mojego zatwierdzenia. Po wybranych iteracjach uruchamiano również pomiar jakości całego procesu, obejmujący precyzję, czułość i F1. Do wykonania zadań zostali oddelegowani agenci AI oparci na modelach GPT-6 Sol i Luna.
Pierwsze dwa etapy E01 i E02 zostały wykonane sprawnie, agenci AI stworzyli zadania, które zrealizowały założenia i rozwiązały zauważone problemy. Powstały uzgodnione kontrakty, zbiór wzorcowy, ewaluator i zostały wykonane bazowe pomiary. Postęp był widoczny, a proces uporządkowany i wydawało się, że był na dobrej drodze do realizacji celu. Jednak w trzecim etapie E03 coś zaczęło iść źle mimo lokalnych sukcesów.
Agenci AI zaczęli dodawać i realizować kolejne zadania rozwiązując napotykane problemy, co widać na poniższym wykresie.
Wykres przedstawia zrekonstruowaną na podstawie raportów głębokość celów dla kolejnych zadań: od bezpośredniej pracy nad celem głównym do kolejnych poziomów celów pomocniczych. Poziomy nie są więc miarą błędu, a klasyfikacją analityczną. Oś pozioma oznacza kolejność zadań, a nie czas ich trwania.
| Poziom | Znaczenie |
| 0 | Bezpośrednia praca nad wynikiem, ustaleniem jego poprawności, pomiarem albo strategiczną korektą sposobu osiągnięcia celu. |
| 1 | Cel pomocniczy: przygotowanie narzędzia, protokołu lub mechanizmu potrzebnego do realizacji celu głównego. |
| 2 | Cel podporządkowany w/w mechanizmowi, którego kontrola, naprawa lub przygotowanie narzędzia umożliwiającego jego sprawdzenie. |
| 3 | Głębsze zagnieżdżenie – dalsza praca nad mechanizmem, który miał zapewnić poprawność wcześniejszego mechanizmu pomocniczemu. |
W AgentProcessBench Fan i współautorzy oceniają kroki agentów z uwzględnieniem działań poprawnych, błędnych oraz neutralnych lub eksploracyjnych, by nie utożsamiać każdego braku bezpośredniego postępu z błędem [4]. Mój wykres opisuje inny aspekt, mianowicie zagnieżdżenie celów. Dlatego jego interpretacja wymaga zestawienia poziomu zadania z jego uzasadnieniem i rzeczywistym skutkiem.
Błąd wykonania a błąd kierunku
Punktem wyjścia jest rozróżnienie błędu wykonania zadania i błędu obranego kierunku rozwiązania zagadnienia przez agentów. Gdy agent współtworzy serię kolejnych zadań, sam wybiera co naprawić, co sprawdzić i co uznać za warunek kontynuacji działań. Ocenie wówczas podlega nie tylko poprawność poszczególnych zadań, lecz także zasadność ich wykonania. Krakovna i współautorzy opisują „specification gaming” jako spełnienie literalnej specyfikacji bez osiągnięcia zamierzonego rezultatu [2].
Sam wzrost liczby zadań nie mierzy ani nakładu pracy, ani dryfu. Zadania mogą różnić się zakresem i stopniem rozdrobnienia. W etapach E03 i E04 część korekt przynosiła lokalne korzyści, ale to nie przybliżało procesu do trwałego spełnienia celu etapu.
Dlaczego agenci AI, mając informacje o narastających problemach, tak długo brnęli w rozwiązywanie zadań wewnątrz przyjętego podejścia, zamiast przejść do jego ponownej oceny?
W omawianym przypadku dwukrotnie zdecydowałem o przerwaniu prac agentom. Za pierwszym razem ograniczyłem zakres dalszych korekt w E03. Za drugim zatrzymałem dotychczasowy tryb pracy i przeformułowałem plan oraz cele cząstkowe, zachowując oczekiwany rezultat i kryteria jego oceny, co doprowadziło do osiągnięcia celu.
Dwanaście niepokojących symptomów
Jakie były przesłanki do podjętych decyzji? Intuicja? Na początku w pewnym sensie tak. W etapie E03 pojawił się intuicyjny alarm wywołany narastającą liczbą informacji o problemach. Przerwałem pracę agentów i przeanalizowałem sekwencję raportów i wyników. Notabene tworzyły one naturalny szereg czasowy, który stosunkowo łatwo było zbadać. W etapie E04 rozpoznałem podobny sposób narastania prac na podstawie wcześniejszego doświadczenia.
W etapie E03 z analizy wynikało, że dalsza lokalna poprawa rozwiązania nie powodowała trwałego polepszenia wyników. Co więcej wyniki okresowo się pogarszały w wyniku wprowadzania większej kontroli, wzrastała liczba napraw własnych mechanizmów. Przede wszystkim wciąż nie było na horyzoncie odpowiedzi na główne cele etapu, choć wydawało się, że są one tuż-tuż.
W etapie E04 bardzo szybko zaczęły powtarzać się wzorce występujące w E03, co doprowadziło mnie do wniosku, że kontynuacja w dotychczasowym trybie nie doprowadzi do celu w dającym się przewidzieć horyzoncie czasowym.
Raporty nie ukrywały niepowodzeń, a zakończenie zadania nie oznaczało akceptacji jakości całego etapu. Problemem było to, że kolejne rozpoznane niepowodzenia prowadziły przede wszystkim do następnych lokalnych korekt.
Poniżej zebrałem listę niepokojących dwunastu symptomów, która jest wynikiem retrospektywnej analizy obu etapów. Nie wszystkie opisane niżej przesłanki zostały rozpoznane w chwili pierwszego alarmu.
1. Testy potwierdzały poprawność lokalną, ale nie przekładało się to na wynik zadania.
Kolejne pozytywne wyniki testów nie dawały wystarczającej podstawy, aby oczekiwać, że następna lokalna poprawka doprowadzi do działającego procesu. Należało sprawdzić adekwatność sposobu weryfikacji i kolejność prac, a nie tylko dopisywać następne testy.
W opracowaniu dotyczącym długotrwałej pracy agentów Anthropic opisuje przypadki, w których zmiany kodu i testy jednostkowe nie ujawniały, że funkcja nadal nie działa [7]. Autorzy wskazują znaczenie weryfikacji z perspektywy użytkownika, zamiast uznawania lokalnego wyniku testów za wystarczające potwierdzenie ukończenia funkcji.
2. Poprawa nie była trwała, odzyskiwano jedne wyniki, tracąc wcześniej poprawne.
Przebieg przestawał przypominać stopniowe domykanie listy usterek. Zaczynał przypominać przesuwanie błędów między obszarami, przy niewystarczającej stabilności całego rozwiązania.
3. Coraz bardziej rozbudowana kontrola nie eliminowała błędów, dla których ją dodawano.
Strategia „Dodanie bardziej szczegółowego protokołu i kolejnej oceny rozwiąże problem poprawności semantycznej” nie dawała poprawy.
4. Część pracy naprawczej dotyczyła problemów wytworzonych przez wcześniejsze zmiany.
Pojawiał się udokumentowany ciąg zdarzeń: naprawa -> nowy mechanizm -> nowy defekt tego mechanizmu -> kolejna naprawa.
5. Lokalny błąd lub niepewność powodowały nieproporcjonalnie szeroką utratę wyniku.
Powtarzał się problem zasięgu skutków błędu, a nie wyłącznie trafności modelu. Uszkodzenie jednego elementu pozbawiało użyteczności inne, niezależne elementy.
6. Użyteczna informacja była odrzucana z powodu technicznej reprezentacji.
Dla części przypadków ekstrakcji danych błąd technicznej reprezentacji informacji unieważniał również samą uzyskaną informację.
7. Poszczególne komponenty były ukończone, ale ważny rezultat nie miał domkniętej ścieżki realizacji.
Podział problemu na zadania nie zapewniał kompletnej odpowiedzialności za rezultat. Każdy komponent mógł respektować swój lokalny zakres, a funkcja celu nadal nie miała pełnej realizacji.
8. Narzędzie porównawcze uniemożliwiało rozstrzygnięcie pytania, któremu miało służyć.
Kolejne wyniki testu eksperymentu nie zawsze przybliżały do decyzji architektonicznej. Konieczna była zmiana sposobu porównania wyników albo zakres sprawdzanej hipotezy, zamiast wyłącznie ponawianie testu.
9. Rozbudowa protokołu przekraczała praktyczne możliwości jego wykonania.
Należało ocenić uzysk z dodatkowej kontroli w relacji do jej kosztu i wykonalności. Sam wzrost kosztu nie jest symptomem dryfu, ale wzrost nakładu połączony z nowymi awariami kontroli i niepotwierdzoną korzyścią już nim może być.
10. Historia wykonania nie pozwalała dostatecznie wykorzystać wcześniejszych prób.
Proces generował raporty i wyniki, ale część najważniejszych danych potrzebnych do oceny zmian pozostawała niedostępna. Więcej prób nie przekładało się w pełni na możliwość rzetelnego uczenia się z nich.
11. Kolejne poprawki kodu nie mogły usunąć wszystkich przyczyn blokady etapu.
Należało odróżnić defekt możliwy do naprawienia kodem od warunku wynikającego z danych lub decyzji projektowej. Dla niektórych scenariuszy liczebność zbioru danych testowych była zbyt mała i nawet skuteczniejszy mechanizm nie zwiększyłby ilości tych danych.
12. Negatywny wynik systematycznie prowadził do następnej korekty, zamiast do retrospektywy i porównania strategii.
Symptomem był powtarzalny sposób reagowania na niepowodzenie. Negatywny wynik prowadził do następnej korekty, zamiast uruchamiać retrospektywę strategiczną i porównanie podejść.
W benchmarku ToolMaze Zhu i współautorzy rozdzielają systematyczne przeplanowanie po awarii od nieproduktywnego ciągu prób i błędów. W badanych układach złożona struktura zależności utrudniała agentom odzyskanie skutecznej drogi działania [5].
Rola człowieka
Człowiek może diagnozować błędy w procesie, w wykonywaniu zadań oraz podejmować lokalnie ważne decyzje.
Rolą człowieka powinna jednak być przede wszystkim odpowiednio wczesna samodzielna ocena strategiczna, nim proces sam dotrze do momentu, w którym dostarczy dowód, że dalsza kontynuacja jest niewłaściwa, a osiągnięte rozwiązanie jest ślepą uliczką.
Wnioski
Należy zauważyć, że wzrastająca liczba zadań, a przez to nakład pracy, korekty zadań i brak natychmiastowej poprawy nie oznaczają dryfu celu. W tym przypadku dopiero współwystępowanie kilku symptomów uzasadniało podejrzenie dryfu i przegląd strategii osiągnięcia celu.
W procesie wytwarzania oprogramowania za pomocą agentów AI, należy monitorować nie tylko, czy zadania są wykonywane, lecz przede wszystkim czy kolejne zadania przybliżają nas do realizacji celu, zamiast skupiać się głównie na naprawie problemów stworzonych przez sam proces. Cai i współautorzy badają zdolność agentów do doprowadzania zadań ilościowych do stanu potwierdzonego przez zewnętrzny weryfikator, odróżniając rzeczywisty postęp od powtarzania pracy i deklaracji ukończenia [3]. W moim przypadku analogiczne rozróżnienie wymaga dodatkowo sprawdzania, czy wykonywane czynności nadal służą właściwemu celowi, czy tylko zwiększają liczbę zamkniętych zadań.
Twarde dane nie kłamią
Raporty dostarczane przez AI mogą być przekonujące, zwłaszcza gdy każdy z nich przedstawia logiczne uzasadnienie kolejnej poprawki. Ocena każdego z nich osobno może prowadzić do błędnej pewności co do działania procesu. Zheng i współautorzy pokazują zarówno użyteczność ocen generowanych przez LLM, jak i ich podatność na wpływ kolejności odpowiedzi, rozwlekłości oraz preferowania własnych odpowiedzi [6]. Dlatego klasyfikację raportów wykonaną przez model również należy traktować jako materiał do weryfikacji.
Zestawiłem chronologicznie zadania, opisy zmian i napotykane problemy z odpowiadającymi im wynikami procesu. Taka równoległa analiza dostarcza twardych danych o przebiegu pracy i pozwala sprawdzić, czy lokalne poprawki prowadzą do trwałej poprawy rezultatu, czy też generują przede wszystkim potrzebę następnych korekt. Narzędzia Data Science pomagają ujawnić te zależności, a modele LLM mogą wspierać przekształcanie opisów w kategorie analityczne powiązane z konkretnymi fragmentami raportów. Trzeba jednak pamiętać, że etykieta analityczna powinna wskazywać źródło i uzasadnienie.
W omawianym przypadku nie zabrakło informacji o błędach. Zabrakło odpowiednio wczesnego wykorzystania historii tych błędów do zakwestionowania sposobu dalszej pracy, a inicjatywa takiej zmiany pochodziła od człowieka.
W kolejnych artykułach spróbuję wyjaśnić dynamikę dryfu, osiągalność celu oraz omówię sposób jak pilnować celu, nie blokując jednocześnie agentowi drogi.
Literatura
- Arike, R., Donoway, E., Bartsch, H., Hobbhahn, M. (2025). „Evaluating Goal Drift in Language Model Agents”. AIES, 8(1), 192–203.
https://ojs.aaai.org/index.php/AIES/article/view/36541 - Krakovna, V. i in. (2020). „Specification gaming: the flip side of AI ingenuity”. Google DeepMind.
https://deepmind.google/blog/specification-gaming-the-flip-side-of-ai-ingenuity/ - Cai, Y. i in. (2026). „Push Your Agent: Measuring and Enforcing Quantitative Goal Persistence in Long-Horizon LLM Agents”. Preprint, arXiv:2605.23574.
https://arxiv.org/abs/2605.23574 - Fan, S. i in. (2026). „AgentProcessBench: Diagnosing Step-Level Process Quality in Tool-Using Agents”. Preprint, arXiv:2603.14465.
https://arxiv.org/abs/2603.14465 - Zhu, D. i in. (2026). „When Tools Fail: Benchmarking Dynamic Replanning and Anomaly Recovery in LLM Agents”. Preprint, arXiv:2606.05806; benchmark ToolMaze.
https://arxiv.org/abs/2606.05806 - Zheng, L. i in. (2023). „Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena”. NeurIPS 2023, Datasets and Benchmarks.
https://proceedings.neurips.cc/paper_files/paper/2023/hash/91f18a1287b398d378ef22505bf41832-Abstract-Datasets_and_Benchmarks.html - Anthropic (2025). „Effective harnesses for long-running agents”. Opracowanie inżynierskie, 26 listopada.
https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
