Agent buduje agenta: metodologia weryfikowalnej automatyzacji

Zawód jako ukryty język

Na tablecie diagnostycznym dwie podobne komendy mogą oznaczać odczyt danych albo zmianę stanu sterownika. Doświadczony technik rozumie etap diagnostyki, wcześniejsze sprawdzenia i konsekwencję następnego kroku. Dla naiwnego systemu AI pozostają jedynie napisy i prostokąty. Nagrania mogą stworzyć przekonującą demonstrację następnego kliknięcia, lecz nie dowodzą bezpiecznego działania ani zdolności zatrzymania się.

Ten case bada inną drogę. Najpierw powstaje obserwacja i telemetria, potem osobna warstwa zamienia je w dane strukturalne. Kolejne role wydobywają powtarzalne decyzje, projektują kontrakty i próbują konstrukcję złamać. Agent runtime otrzymuje prawo do działania dopiero po sprawdzeniu: najpierw w symulacji, potem w trybie obserwacji, a na końcu w ograniczonej pętli wykonawczej.

Od nagrania do znaczenia

Instrukcje rzadko zapisują mikrodecyzje: czy ekran się ustabilizował, czy lista biegnie niżej, czy identyczne etykiety należą do różnych modułów oraz czy raport dowodzi kompletności. Wideo zachowuje obraz procesu, nie jego sprawdzalną strukturę. Współrzędne dotknięć psują się po przewinięciu, zmianie wersji aplikacji lub zmianie stanu ekranu.

Każdy krok potrzebuje więc śladu dowodowego: co specjalista widział, jakie wykonał działanie, jakie były stany pośrednie, jaki ekran ustabilizował się później, jaka zmiana była oczekiwana i co pozostało niepewne. Nie wolno utożsamiać tekstu na ekranie, fizycznego dotknięcia, zawodowego sensu działania i powodu jego wyboru.

Fabryka agentów, nie samodoskonalący się model

„Agent buduje agenta” nie oznacza modelu, który sam pisze kod, sam się egzaminuje i ogłasza gotowość. Oznacza podział pracy i uprawnień. Agent deweloperski tworzy bezpieczne probes, recorder, schematy danych, walidatory i testy, lecz obserwuje operatora, a nie steruje aplikacją. Agent obserwator opisuje typ ekranu, warstwę, tekst, kontrolki, okna modalne i niepewność. Kurator sprawdza archiwa, łączy zdarzenia i wykrywa braki; analityk wydobywa graf stanów oraz decyzji zamiast makra.

Architekt może przygotować typowane wejścia i wyjścia, ograniczony słownik intencji, pamięć postępu i zasady zakończenia. Działania o skutkach nadal pozostają w deterministycznym hoście. Niezależny agent testowy szuka pominiętych gałęzi, niedowiedzionych przejść, niestabilnych ekranów i nadmiernych uprawnień. Wynik negatywny staje się częścią korpusu.

Przenieść regułę, nie trasę

Wartością jest sprawdzalna trajektoria: stan, dozwolony cel, krok, wynik, potwierdzenie i granica stosowalności. Zamiast reguły „naciśnij współrzędną X” pojawia się reguła warunkowa: jeżeli wybrano ten moduł, występuje ten błąd, ekran jest stabilny, a poprzednia gałąź zamknięta, można zaproponować działanie z ograniczonego zbioru. W przeciwnym razie system pyta człowieka albo bezpiecznie się zatrzymuje. Model może proponować intencję, ale nie staje się ona działaniem, zanim nie zostanie dopasowana do stanu i dozwolonej umiejętności.^saycan

Model przewiduje, system pozwala

Model rozpoznaje sytuację, proponuje warianty i sygnalizuje niepewność. Działanie z konsekwencjami musi jednak zostać zatwierdzone przez kod i bieżący stan. Warstwa uprawnień sprawdza świeżość obserwacji, zgodność intencji z pojedynczym działaniem, dozwoloną operację, brak sprzecznych warunków i potwierdzenie po wykonaniu. Gdy dowodów brakuje, poprawnym wynikiem jest ask human albo safe stop, a nie zgadywanie.

Agent sprawdza agenta

Model może mieć rację z niewłaściwego powodu, wykorzystać przyszły ekran, pomylić kontekst lub ogłosić zakończenie zadania z niewidoczną gałęzią. Sesje historyczne należy odtwarzać przyczynowo: na każdym kroku agent widzi tylko to, co istniało wówczas. Propozycję porównuje się z celem procesu, zasadami bezpieczeństwa i dowodem zakończenia, a nie tylko z kliknięciem człowieka. Testy obejmują opóźnienia, modale, podobne etykiety, nieudane próby i sprzeczne dane.

Granice automatyzacji i prawa

Automatyzacja może wspierać powtarzalny wywiad, przygotowanie sekwencji pracy, kontrolę kompletności, raporty i wykrywanie odchyleń. Nie uzyskuje automatycznie prawa do fizycznego potwierdzenia, spornej diagnozy, zmiany stanu sterownika ani decyzji o odpowiedzialności. Człowiek określa cel, zatwierdza granice i rozstrzyga wyjątki.

Nagrywanie doświadczenia jest również przetwarzaniem danych. Trzeba określić cel, zakres, retencję, dostęp, anonimizację i rozdzielenie dowodów pierwotnych od odniesień badawczych. Zasady GDPR, w tym minimalizacja danych i privacy by design, wpływają na projekt od początku.^gdpr AI Act dodaje wymogi przejrzystości i ocenę ryzyka; kwalifikacja zależy od intended purpose, funkcji i kontekstu.^ai-act Wytyczne Data Act dla danych pojazdów są sektorowe i nie przenoszą się automatycznie na inne branże.^data-act

Ograniczenia i status

Projekt pozostaje na etapie badań i stopniowej walidacji. Nie deklaruje certyfikacji bezpieczeństwa, zgodności z określoną kategorią AI Act, dostępu do danych producentów, gotowości do autonomicznego sterowania funkcjami pojazdu ani potwierdzonych metryk produkcyjnych.

Narzędzia AI wspierały strukturę i redakcję. Autor sprawdza fakty, wnioski i opublikowaną wersję oraz ponosi za nią odpowiedzialność redakcyjną.

Źródła

1. Brown, T. B. et al. Language Models are Few-Shot Learners, 2020.^few-shot
2. Ahn, M. et al. Do As I Can, Not As I Say: Grounding Language in Robotic Affordances, 2022.^saycan
3. Brohan, A. et al. RT-2: Vision-Language-Action Models Transfer Web Knowledge to Robotic Control, 2023.^rt2
4. Regulation (EU) 2016/679 (GDPR), art. 5 i 25.^gdpr
5. Regulation (EU) 2024/1689 (AI Act), art. 4 i 50.^ai-act
6. European Commission, Guidelines on transparency obligations under Article 50 of the AI Act, 2026.^{ai-transparency}
7. European Commission, Guidance on vehicle data, accompanying the Data Act, 2025.^data-act