Lokalny agent AI jako operator komputera
Model, który nie tylko odpowiada tekstem, ale rozpoznaje intencję, wybiera narzędzie, uruchamia je i sprawdza własny wynik. Architektura, uprawnienia i miejsca, w których to się psuje.
Czat, który odpowiada tekstem, jest wygodny przez pierwszy tydzień. Potem zaczyna irytować: model wie, jak coś zrobić, ale robi to człowiek. Agent operacyjny zamyka tę lukę — dostaje prawo uruchomienia narzędzia i obowiązek sprawdzenia, co z tego wyszło.
Problem
Typowe polecenie w warsztacie brzmi: „znajdź zdjęcia produktu ABDA7517F2 i przygotuj zestawienie”. To jedno zdanie zawiera cztery różne czynności: przeszukanie dysku, rozpoznanie formatu, grupowanie i eksport. Model językowy sam z siebie żadnej z nich nie wykona — potrafi tylko opisać, jak by je wykonał.
Architektura
Rozbicie na dziesięć kroków nie jest ozdobnikiem, tylko sposobem na kontrolę. Trzy z nich są krytyczne i to na nich siedzi cała odpowiedzialność systemu.
- Klasyfikacja zadania — rozmowa, pliki, internet, aplikacja czy kod. Zła klasyfikacja to zmarnowane wszystkie kolejne kroki, więc ten wybór robimy osobnym, krótkim zapytaniem, a nie przy okazji generowania planu.
- Sprawdzenie uprawnień — agent działa w piaskownicy z jawną listą katalogów do odczytu i zapisu. Operacja poza listą nie jest odrzucana po cichu, tylko wraca do użytkownika jako pytanie.
- Walidacja wyniku — model ocenia własny rezultat według kryterium z planu. Jeśli plan mówił „38 plików”, a wynik ma 12, uruchamia się korekta.
Uprawnienia jako element architektury, nie dodatek
Agent, który może uruchomić dowolny program, jest wygodny do pierwszej pomyłki. U nas każde narzędzie ma deklarację: co czyta, co zapisuje, czy sięga do sieci i ile może działać. Operacje zapisujące wymagają potwierdzenia przy pierwszym użyciu w danej sesji.
Limit czasu okazał się ważniejszy, niż zakładaliśmy. Skrypt, który wpadł w pętlę przy przeszukiwaniu zamontowanego dysku sieciowego, potrafił zająć maszynę na kwadrans, zanim ktokolwiek zauważył.
Walidacja i korekta
Najciekawszy element to pętla 9 → 7: korekta wraca do wykonania, a nie do planowania. Powtórne planowanie zwykle daje ten sam plan, więc byłoby stratą czasu — problem prawie zawsze siedzi w parametrach wywołania, nie w koncepcji.
Limit powtórzeń ustawiliśmy na dwa. Trzecia nieudana próba kończy się komunikatem dla człowieka wraz z całym śladem: co model chciał zrobić, czym, i co wróciło. Ten ślad okazał się najbardziej praktyczną częścią całego systemu — z niego wynika, czy zawiódł model, narzędzie, czy opis zadania.
Wynik
Zadania złożone z jednego narzędzia agent wykonuje poprawnie w zdecydowanej większości przypadków. Przy zadaniach łączących trzy i więcej narzędzi skuteczność wyraźnie spada, a najczęstszą przyczyną jest niejednoznaczne polecenie, nie model.
Praktyczny wniosek po kilku miesiącach: opłaca się inwestować w opis narzędzi, nie w większy model. Narzędzie z precyzyjnym opisem parametrów jest wybierane trafnie nawet przez mniejszy model; narzędzie opisane ogólnikowo myli nawet duży.
