Z agentami przy moim blogu pracuję od niecałego miesiąca. Efekty w postaci zmienionej szaty graficznej już widać. Cały szablon jest bardziej przyjazny wyszukiwarkom. To tylko początek zmian. Aby to wszystko dobrze działało, trzeba dostarczyć modelowi wielu informacji oraz narzędzi. Bez nich AI będzie błądzić i będzie mało skuteczne.
W skrócie
- Harness = agent minus model. Pętla, narzędzia, kontekst, uprawnienia, pamięć, weryfikacja, bezpieczniki.
- To on, a nie sam model, w dużej mierze decyduje o jakości pracy agenta — ten sam model w pustym czacie i w dobrym harnessie daje inne wyniki.
- Dobry harness ogranicza agenta tak samo, jak mu pomaga: domyślnie próba bez zapisu, blokada przed nadpisaniem cudzych zmian, możliwość cofnięcia.
- Błąd agenta powinien kończyć się nową regułą w harnessie, a nie tylko poprawką jednego wyniku.
Czym jest harness agenta AI
Model językowy sam w sobie robi jedno: dostaje tekst i zwraca tekst. Nie otwiera plików, nie wywołuje API, nie pamięta wczorajszej rozmowy. Żeby mógł cokolwiek zrobić, ktoś musi go otoczyć narzędziami, które:
- uruchamiają go w pętli (pomyśl → użyj narzędzia → zobacz wynik → pomyśl dalej) — to tzw. agent loop,
- decydują, do czego ma dostęp,
- przekazują mu instrukcje i kontekst,
- zapamiętują stan między sesjami,
- sprawdzają efekty i zatrzymują go, gdy coś idzie źle.
Ta warstwa to właśnie harness (po angielsku agent harness; po polsku bywa tłumaczony jako „uprząż” albo „oprzyrządowanie”, ale w praktyce używa się angielskiego słowa). Gotowe agenty programistyczne, jak Claude Code, to już harnessy — ale każdy projekt może dołożyć własną warstwę, dopasowaną do jego zadań.
Prompt to jedna z części harnessu, nie cały harness. Dobrze napisane polecenie nie zastąpi narzędzi, pamięci ani zabezpieczeń.
Z czego składa się harness
1. Pętla i orkiestracja
Kto decyduje, kiedy agent kończy? Ile razy może spróbować? Czy może uruchamiać podagentów? To szkielet, na którym wisi reszta.
2. Narzędzia
Wszystko, co agent może zrobić poza pisaniem tekstu: czytać pliki, uruchamiać komendy, pytać API. Jakość narzędzi często waży więcej niż sprytniejszy model — narzędzie, które zwraca zwięzły, czytelny wynik, oszczędza agentowi błądzenia.
3. Instrukcje i kontekst
Plik z zasadami projektu, opis konwencji, lista pułapek. To wiedza, której agent nie wyczyta z kodu, bo nie jest w kodzie zapisana.
4. Uprawnienia i dostęp
Do czego agent ma dostęp i w jakim zakresie. Osobne konto o ograniczonych prawach zamiast Twojego własnego to podstawa.
5. Pamięć i stan
Model nie pamięta poprzedniej sesji. Jeśli praca ma trwać tygodniami, stan trzeba zapisywać na zewnątrz: lista zadań, dziennik zmian, notatki.
6. Weryfikacja
Skąd wiadomo, że zadanie zostało wykonane? „Zrobione” w odpowiedzi agenta to deklaracja; sprawdzenie efektu przez kod to dowód.
7. Bezpieczniki
Tryb próbny, blokada przed nadpisaniem, kopie zapasowe, możliwość cofnięcia. Agent będzie się mylił — pytanie, ile kosztuje pomyłka.
Dlaczego harness waży tyle co model
Bardzo dobrze to widać na przykładzie samego czatu z AI, np. ChatGPT. Gdy spytasz o jakąś poradę, np. SEO dla swojej strony internetowej, dostaniesz ogólną odpowiedź, która może się spodobać i dać wrażenie, że kierunek jest dobry. Jednak gdy to samo pytanie zadasz w Claude Code, który ma dostęp do wielu narzędzi, może się okazać, że nie jest już tak różowo. Ile razy już się na tym przejechałem, to głowa mała.
Dwa obserwowalne skutki:
- Powtarzalność. Bez harnessu każda sesja zaczyna od zera i agent rozwiązuje ten sam problem inaczej. Z harnessem zasady i narzędzia są te same za każdym razem.
- Zaufanie. Agent, którego nie da się cofnąć ani sprawdzić, trzeba pilnować na każdym kroku. Taki, którego błędy są tanie, można zostawić z zadaniem.
Przykład: harness przy odbudowie mojego bloga
Highlab.pl to mój blog o technologii, nad którym pracuję z agentem AI. Cel biznesowy to odbudowa ruchu i wiarygodności treści (E-E-A-T: doświadczenie, ekspertyza, autorytet, zaufanie). Sam cel nie jest harnessem — harness to mechanizmy, dzięki którym agent pracuje nad nim bezpiecznie.
W praktyce wygląda to tak, że agent pomógł mi przeanalizować logi serwera i znaleźć wpisy, które straciły najwięcej ruchu i widoczności. Dalej: aktualizowanie postępu prac, żeby zadania się nie dublowały. Ogarnięcie ponad 1000 wpisów i setek tysięcy rekordów z Google Search Console byłoby bardzo karkołomnym zadaniem. Jeszcze dalej: twarde reguły, których agent nie może przekroczyć.
Narzędzia: dane zamiast domysłów
Przed każdą poprawą wpisu agent uruchamia skrypt, który zbiera dane z Google Search Console i aktualną wersję wpisu, a na końcu daje zalecenia. Szkic powstaje z briefu, nie z ogólnej wiedzy modelu o SEO. Osobne narzędzie robi to samo dla nowych wpisów, mierząc popyt na temat w całym serwisie.
Instrukcje: wiedza zapisana po wpadce
Plik z zasadami projektu zawiera pułapki, na które już wpadliśmy — np. jak łatwo zepsuć klasyfikację szablonów wpisów albo czemu nie wolno zapisywać treści jedną konkretną funkcją WordPressa. Agent czyta to na początku każdej sesji.
Dostęp: osobne konto
Agent łączy się z produkcyjnym WordPressem przez REST API z osobnego konta bota, a nie z moich danych. Wiadomo, co zrobił on, i da się ten dostęp odciąć jednym ruchem.
Pamięć: dziennik, który musi być aktualny
Jedna lista „co trzeba zrobić na produkcji” i rejestr zmian. Zasada jest prosta: ta sama zmiana, która tworzy zadanie, aktualizuje listę. Dzięki temu nowa sesja wie, na czym skończyła poprzednia.
Bezpieczniki: próba, blokada, cofnięcie
Masowe zmiany w treści przechodzą trzy etapy: audyt (nic nie zapisuje), plan (decyzja zapisana w pliku) i wykonanie, które domyślnie jest tylko próbą. Każdy wpis ma sumę kontrolną sprzed zmiany — jeśli treść zmieniła się w międzyczasie, wpis jest pomijany, nie nadpisywany. Każde wykonanie zapisuje wynik w osobnym pliku, więc można je cofnąć.
Każda zmiana na moim blogu, jeśli chodzi o treści czy o to, czy mają być zaindeksowane, musi być odwracalna. Stąd każdy skrypt czy automatyzacja musi mieć opcję backupu. Przez brak backupu nie mogłem cofnąć skutków jednego skryptu. Przywrócenie poprzedniego stanu kosztowało mnie dużo czasu. Teraz każde zadanie jest dzielone na dużo mniejsze etapy. Dzięki temu błędów jest dużo mniej i łatwiej je wyłapać.
Weryfikacja: kod sprawdza stronę, nie agent
Po publikacji skrypt pobiera stronę na żywo i sprawdza m.in. nagłówek H1, brak niewyrenderowanych shortcode’ów, dane strukturalne i opis. „Opublikowane” znaczy: sprawdzone.
Granice agenta: czego nie robi za człowieka
To dla E-E-A-T najważniejsze. Agent może zebrać dane, napisać szkic i uporządkować strukturę, ale nie ma własnego doświadczenia z testowania sprzętu. Dlatego szkice mają jawne miejsca na doświadczenie autora, a skrypt publikacji blokuje wpisy z nieuzupełnionymi uwagami. Harness pilnuje, żeby agent nie udawał kogoś, kim nie jest.
Jak zacząć budować własny harness
Tak to wygląda z mojej perspektywy. Najważniejszy jest plan, następnie narzędzia, z których każde odpowiada za jedną rzecz. Dodatkowo wszystko musi być bardzo dobrze opisane. Na koniec trzeba wszystko weryfikować. Zostawienie wszystkiego w trybie auto nie da tak dobrych efektów.
- Zacznij od pliku z instrukcjami i uzupełniaj go po każdej wpadce.
- Daj agentowi jedno narzędzie, które dobrze robi jedną rzecz.
- Dodaj tryb próbny i możliwość cofnięcia, zanim pozwolisz cokolwiek zapisywać.
- Prowadź zewnętrzny dziennik, który agent czyta na starcie.
- Weryfikuj efekt kodem, nie deklaracją.
