Agent sztucznej inteligencji to model sztucznej inteligencji w połączeniu z narzędziem pomocniczym: co robi to narzędzie i dlaczego.
Agent to model w połączeniu z narzędziem pomocniczym. Zobacz, jak takie narzędzia dodają funkcje takie jak narzędzia, pamięć, pętle i zasady bezpieczeństwa, w jaki sposób różnią się agenci o otwartym kodzie źródłowym i bez ograniczeń, oraz dlaczego oceny są ważne.
Przez jakiś czas historia postępów w dziedzinie sztucznej inteligencji była opowiadana poprzez wprowadzanie nowych modeli: coraz większe i bardziej zaawansowane modele podstawowe pojawiały się co kilka miesięcy. Ta historia jest niekompletna. Model językowy, duży czy mały, dostarcza surowej inteligencji, ale to, jak duża część tej inteligencji dociera do użytkownika, zależy od oprogramowania, które go otacza. To oprogramowanie nazywane jest „harnessem”, a coraz więcej badań wskazuje, że może mieć takie samo znaczenie jak model wewnątrz. Najnowsze badania nad dostosowywaniem „harnessów” do mniejszych modeli sugerują, że starannie dostrojony „harness” może umożliwić małemu modelowi osiągnięcie znacznej części wydajności modelu zaawansowanego przy znacznie niższych kosztach. Dokładne dane znajdują się w oryginalnych pracach naukowych, ale tendencja jest zgodna z tym, co obserwują praktycy: najpotężniejszy model nie zawsze daje najskuteczniejszy system.
Zatem rywalizacja coraz bardziej dotyczy tego, kto stworzy najlepszy „ Harness”, a nie tylko kto zbuduje największy model.
Dlaczego inteligentny model nadal potrzebuje „ Harness”
Model językowy może wygenerować odpowiedź. Samodzielnie nie może przeglądać folderów, wybierać narzędzi, przechowywać pamięci roboczej między wywołaniami, weryfikować to, co napisał, naprawiać błędy ani dążyć do osiągnięcia celu. To właśnie te luki mają za zadanie wypełnić agenci. W agencie „ Harness” otacza model i przekształca jego inteligencję w strukturyzowane, powtarzalne działania ukierunkowane na cel.
Model kontra agent
Model przyjmuje dane wejściowe i wytwarza wynik, po czym jego praca jest zakończona. Agent kontynuuje pracę po pierwszej odpowiedzi. Czyta pliki, używa narzędzi, wykonywa polecenia, pamięta wcześniejsze wyniki, podejmuje decyzje i postępuje krok po kroku, aż zadanie zostanie zakończone.
Jak to może się zdarzyć, skoro model jest budowany wyłącznie w celu przewidywania następnego wyniku? Dzięki systemowi obsługi modelu – inżynieryjnej strukturze otaczającej go. Ten system decyduje, jaki kontekst trafia do modelu, jakie narzędzia są dostępne, w jaki sposób wykonywane są ich wywołania, co zostaje zapamiętane, kiedy model jest ponownie wywoływany oraz które działania są odrzucane lub wymagają zatwierdzenia.
System obsługi tworzy również pętlę roboczą:
Cykl przebiega w ten sposób: model odczytuje zawartość swojego kontekstu, wybiera działanie, wywołuje narzędzie, sprawdza uzyskany wynik, łączy go z kontekstem i rozpoczyna cykl od nowa.
To właśnie ta pętla odróżnia odpowiadanie od realizacji zadania. Może być również powiązana z planerem lub zewnętrznym wyzwalaczem, dzięki czemu agent uruchamia się sam w określonym czasie lub po wystąpieniu jakiegoś zdarzenia.
Równanie: agent = model + system obsługi
Model to ta część, która przewiduje. Na podstawie dostarczonego mu kontekstu wytwarza najbardziej przydatną kolejną odpowiedź lub działanie. „Opancerzenie” to oprogramowanie otaczające go, które przekształca tę surową zdolność w kontrolowane, wieloetapowe zachowanie.
Zobaczmy, co się dzieje, gdy ten sam model zostanie wdrożony w różne „opancerzenia”:
- Z zwykłym interfejsem do rozmów staje się asystentem konwersacyjnym.
- Gdy dodamy funkcje wyszukiwania w sieci, pobierania danych, oceny źródeł i sprawdzania cytatów, staje się agentem badawczym.
- Jeśli damy mu repozytorium, edytora, terminal oraz narzędzia do testowania wyników, staje się agentem programistycznym.
- Gdy połączymy go z danymi klientów, regułami biznesowymi, narzędziami do komunikacji, mechanizmami wyzwalającymi i procesami zatwierdzania, otrzymujemy agenta operacyjnego.
Model nigdy się nie zmienił. Zmieniła się natomiast infrastruktura wspierająca. To również tłumaczy, dlaczego dwa produkty oparte na tym samym modelu podstawowym mogą zachowywać się zupełnie inaczej. Jeden pozyskuje odpowiednie dowody, wybiera właściwy narzędzie, odradza się po nieudanych próbach, utrzymuje uporządkowany kontekst i weryfikuje wynik. Drugi traci kluczowe informacje, nadal używa niewłaściwych narzędzi lub ogłasza zwycięstwo bez sprawdzenia. Zdolności produktu nie można oceniać wyłącznie na podstawie jego modelu: model określa to, co system potrafi zrozumieć, natomiast infrastruktura określa to, co może osiągnąć.
Rozróżnianie warstw
Ludzie często używają terminów model, agent i infrastruktura zamiennie, chociaż są to odrębne warstwy.
Codex i Claude Code dobrze ilustrują ten wzorzec wśród agentów programistycznych. Każdy z nich łączy własne modele dostawcy z narzędziem obsługującym kontekst repozytorium, dostęp do plików, narzędzia, polecenia wiersza poleceń, pamięć, wykonywanie, informacje zwrotne z testów oraz pętle powtarzające. OpenCode, Goose, Pi, Letta i AutoGPT stosują ten sam wzorzec co środowiska wykonawcze lub frameworki, różnią się jednak obsługiwanymi modelami, zestawami narzędzi, architekturą pamięci oraz stopniem otwartości.
Agent to kompletny system, model dostarcza inteligencji, a narzędzie określa, w jaki sposób ta inteligencja oddziałuje na świat zewnętrzny.
Otwarte wagi a oprogramowanie otwarte to różne rzeczy
Produkty takie jak Codex i Claude Code to gotowe agenty, w których model oraz narzędzia do jego obsługi są rozwijane i dostosowywane wspólnie przez jedną firmę. Agent typu open-weight natomiast łączy model do pobrania z istniejącymi lub dostosowanymi narzędziami. Dzięki temu programiści mają większą kontrolę nad implementacją, narzędziami, pamięcią, prywatnością, kosztami oraz zachowaniem agenta. Te modele mogą działać na własnej infrastrukturze i, jeśli pozwala to licencja, być dalej dostosowywane. Typowym połączeniem jest Goose z modelem open-weight, np. gpt-oss-120b, lub OpenCode z modelem Qwen lub Gemma.
Agent o otwartym kodzie to coś innego: kod narzędzi do obsługi modelu jest dostępny publicznie. Każdy może przeczytać i zmienić sposób, w jaki model jest angażowany do pracy, jakie narzędzia są oferowane, w jaki sposób przechowywana jest pamięć, jak działają pętle, z czym agent się integruje oraz jak radzi sobie z uprawnieniami i kontekstem. OpenCode, Goose i AutoGPT to przykłady takich otwartych narzędzi.
Dwie te cechy są niezależne:
- Harness o kodzie otwartym nadal może wywoływać model proprietarny za pośrednictwem API. OpenCode może uruchamiać modele GPT lub Claude, więc jego interfejs, logika sterowania oraz wykonywanie narzędzi są otwarte, podczas gdy sam model pozostaje zamknięty.
- Model o wagach otwartych sam w sobie nie jest agentem. Model taki jak gpt-oss-20b potrafi przewidywać i podejmować decyzje, ale nie może przeglądać folderów, uruchamiać narzędzi, przechowywać stanu zadań ani zakończyć procesu roboczego, dopóki nie zostanie otoczony harnessem takim jak Goose, OpenCode lub własnym frameworkiem.
W zwięzłej formie: agent o kodzie otwartym to harness o kodzie otwartym w połączeniu z dowolnym kompatybilnym modelem, natomiast agent o wagach otwartych to harness wraz z pobieralnymi wagami modelu.
Dlaczego istotne są otwarte ekosystemy
Wiele laboratoriów dostarcza obecnie przystępne pod względem kosztów modele o otwartym kodzie wraz z narzędziami typu agent opartymi na oprogramowaniu open source, tworząc w ten sposób hybrydowe otwarte ekosystemy. Takie rozwiązania sprawiły, że takie platformy stały się poważnymi konkurentami dla systemów opartych na własności intelektualnej w wybranych testach, choć nie zawsze przewyższają je we wszystkim. Oceny dostawców często pokazują, że modele własnościowe wciąż wygrywają w kilku testach programistycznych. Kluczowym punktem nie jest to, że jeden model przewyższa wszystkie inne, lecz fakt, że przystępny pod względem kosztów model o otwartym kodzie, połączony z starannie zaprojektowanym narzędziem wspomagającym, może konkurować z drogimi systemami zamkniętymi.
Czym powinno się charakteryzować dobre narzędzie wspomagające
Wydajność wynika z połączenia modelu i narzędzia wspomagającego, a to drugie składa się z kilku elementów:
- Wybór kontekstu. Decydowanie o tym, co zostanie przekazane przy każdym wywołaniu modelu, tak aby obecny był odpowiedni plik, rekord lub dokument, a brakowało szumów.
Wybory projektowe kształtujące system
Każdy framework podejmuje decyzje, które po cichu ustalają granice tego, co agent może zrobić, a niektóre z nich wymagają uwagi już na wczesnym etapie.
Ile narzędzi i w jaki sposób są opisane. Przydzielenie modelowi dwudziestu nakładających się na siebie narzędzi zazwyczaj szkodzi bardziej niż pięciu dobrze określonych. Nazwy, opisy oraz struktura argumentów stanowią w rzeczywistości instrukcje, więc niejasne definicje narzędzi powodują błędne wywołania.
Ile informacji należy zapamiętać.Długie historie zastępują się przydatnym kontekstem. Frameworki zazwyczaj skracają, podsumowują lub przechowują notatki poza instrukcjami i przywołują je, gdy są potrzebne. To, co zostaje zachowane i na jak długo, ma duży wpływ na to, czy agent będzie zachowywać spójność podczas długiego zadania.
Gdzie umieścić człowieka. Niektóre działania, takie jak odczytywanie pliku, można bezpiecznie zautomatyzować. Inne, takie jak usuwanie danych lub przesyłanie pieniędzy, wymagają kroku zatwierdzenia. Ustawienie tych reguł to decyzja operatora, a nie modelu.
Co uznaje się za zakończone zadanie. Pętla potrzebuje reguły zatrzymania, np. przejścia testów, zweryfikowanej odpowiedzi lub wykorzystania całego budżetu kroków. Bez niej agent albo kończy pracę wcześniej, albo kontynuuje działanie.
Praktyczny sposób na rozpoczęcie
Jeśli budujesz agenta, zacznij od najprostszego zestawu narzędzi, który może sfinalizować jedno rzeczywiste zadanie od początku do końca: jeden model, dwa lub trzy narzędzia, pętla z ograniczeniem liczby kroków oraz pisemna definicja sukcesu. Następnie zebraj od dziesięciu do dwudziestu rzeczywistych zadań, uruchom je, przeanalizuj wyniki i najpierw napraw najczęstsze błędy. Zmiana modelu nastąpi później, gdy już dowiesz się, że to nie zestaw narzędzi jest czynnikiem ograniczającym. Taka kolejność zapobiega przypisywaniu winy modelowi za problemy, które w rzeczywistości wynikają z otaczających go narzędzi.
Jak działa dostęp do plików
Model nie może bezpośrednio dotykać plików na komputerze. Narzędzie to udostępnia kontrolowane funkcje takie jak wyświetlanie katalogów, wyszukiwanie nazw plików, pobieranie odpowiednich treści, otwieranie i edytowanie plików, wykonywanie kodu oraz zapisywanie wyników. Model decyduje, jakie informacje lub działania są mu potrzebne dalej. Narzędzie weryfikuje i realizuje tę prośbę, zwraca wynik i dodaje go do kontekstu. Ten proces powtarza się, aż model uzna zadanie za zakończone:
Model żąda wykonania określonej akcji, narzędzie ją realizuje, następnie zwraca wynik, a model wybiera kolejną akcję.
Na przykład, gdy zostanie poproszony o naprawę nieudanego testu, model może najpierw poprosić o wyświetlenie katalogów, potem o otwarcie pliku testowego oraz modułu poddawanego testowi, zaproponować zmiany i poprosić o ponowne przetestowanie. Na każdym kroku narzędzie decyduje, czy prośba jest dozwolona, ją realizuje i informuje o tym, co się stało.
Układ do oceny ma takie samo znaczenie
Budowa układu dla agenta to tylko połowa pracy. Drugą połową jest układ do oceny, który pokazuje, czy agent funkcjonuje prawidłowo. W warunkach przypominających rzeczywiste środowisko testuje on, czy cały system potrafi wybrać odpowiednie narzędzia, odzyskać się po awariach, utrzymać koszty pod kontrolą, przestrzegać zasad bezpieczeństwa i konsekwentnie realizować zadania. To znacznie więcej niż tylko przejście izolowanego testu wydajnościowego.
Układ dla agenta składa się z wielu wzajemnie oddziałujących elementów, a w każdym z nich może się ukryć regresja: prompty, zasady kontekstowe, narzędzia, polityki pamięci, pętle planowania, weryfikacja, uprawnienia i mechanizmy odzyskiwania. Bez zestawu do oceny zespół nie może stwierdzić, czy zmiana jednego z tych elementów przyniosła korzyść, czy po cichu spowodowała nową awarię. Dlatego te dwa układy tworzą cykl sprzężenia zwrotnego:
- Zbierz przykładowe zadania, w tym realistyczne procesy pracy, trudne przypadki oraz wcześniej wystąpiłe błędy.
- Zaprowadź w działanie cały system wraz z aktualnym modelem i narzędziem.
- Przeglądaj wyniki: sukcesy, ślady działania, wywołania narzędzi, błędy, koszt oraz opóźnienia.
- Zmień jeden komponent – czy to prompt, narzędzie, model, zasady zarządzania pamięcią, pętlę czy regułę routingu.
- Ponownie przeprowadź oceny na zadaniach pozostawionych na boku oraz w przypadkach regresji.
- Zachowaj tylko te zmiany, które faktycznie poprawiają wymagany balans między dokładnością, niezawodnością, bezpieczeństwem, szybkością i kosztem.
Mówiąc krótko: buduj, oceniaj, znajdź błędy, ulepsz narzędzie, oceniaj ponownie.
Czytanie śladu działania
Ocena jest najłatwiejsza, gdy można przeczytać, co dokładnie zrobił agent. Przydatny zapis śledzenia rejestruje każde wezwanie modelu, żądany narzędzie, argumenty, zwrócony wynik, użyte tokeny oraz czas trwania. Gdy zadanie się nie powiedzie, sprawdź zapis śledzenia pod kątem pierwszego błędnego kroku, a nie ostatniego. Często przyczyna leży wcześniej: brakuje pliku w kontekście, opis narzędzia jest niejasny lub popełniono błędne założenie, które przenosi się na kolejne kroki. Poprawa tego jednego elementu zazwyczaj naprawia całą serię błędów, dlatego analiza zapisu śledzenia jest jednym z najbardziej efektywnych nawyków, które może przyjąć zespół.
Czy model nadal ma znaczenie?
Tak. Nowsze modele stale poprawiają swoje umiejętności rozumowania, programowania, wykonywania instrukcji, dokładności wywoływania narzędzi, pojemności kontekstowej, szybkości, efektywności kosztowej oraz umiejętności multimodalnych, a narzędzie integracyjne nie może w sposób pewny stworzyć funkcji, której model nie posiada. Jednak model już nie jest całym produktem.
Gdy kilka modeli jest wystarczająco dobrych do wykonania zadania, narzędzie integracyjne może skutkować znikomą różnicą pomiędzy produktami. Mechanizmy wyszukiwania odpowiednich plików, narzędzia o oczywistych działaniach, systemy zarządzania stanem zapamiętujące zakończone prace, funkcje weryfikacji wykrywające błędne edycje, uprawnienia zapobiegające niebezpiecznym krokom oraz mechanizmy odzyskiwania po awariach – wszystko to ma znaczenie.
To wskazuje na prosty podział pracy, który stanowi również przydatną listę kontrolną do przeglądania każdego projektu agenta. Należy zapytać, co model może rozsądnie robić, co musi dodać „harness”, aby ta zdolność była niezawodna, oraz jakie dowody dostarczają oceny potwierdzające to.
- Model określa zewnętrzną granicę tego, co system może robić.
- „Harness” przekształca tę granicę w niezawodne, powtarzalne wyniki.
- Ocena potwierdza, czy ukończony system rzeczywiście spełnił oczekiwania, co to osobne pytanie od tego, czy model jest inteligentny.
Dlatego tak wiele działań w inżynierii aplikacji skupia się obecnie na „harnessach” i ocenach. To właśnie w „harnessie” zespół buduje trwałą przewagę dzięki prywatnemu kontekstowi, bezpieczniejszym narzędziom, procesom pracy w danej dziedzinie, pamięci, przywracaniu błędów oraz dobrej jakości doświadczeniu użytkownika.
Odpowiedź na kluczowe pytanie
Czy model może stać się prawdziwym, funkcjonalnym agentem bez „opaski”? Nie. Sam model nie posiada środowiska niezbędnego do wykonywania działań, łączenia się z zewnętrznymi systemami, zapamiętywania zakończonych kroków, obserwowania skutków swoich decyzji oraz dalszej pracy w kierunku celu. Model to mózg i silnik rozumowania. „Opaska” to ciało, narzędzia, pamięć, pętle sprzężenia zwrotnego, uprawnienia oraz zasady bezpieczeństwa, które przekształcają prognozy w kontrolowane działania.
Lub jednym zdaniem: agent AI to model AI plus „opaska”.