Harness to wszystko wokół modelu AI, co robi z niego działającego agenta: pętla wykonania, narzędzia, instrukcje, zarządzanie kontekstem, uprawnienia, testy i sposób sprawdzania wyniku. Model proponuje kolejny krok. Harness decyduje, co model widzi, co może wykonać, kiedy ma się zatrzymać i co się stanie, gdy coś pójdzie źle. Stąd skrót, który często pojawia się w tekstach o agentach: agent = model + harness.
Harness engineering to praca nad tą warstwą. Nie zmieniasz wag modelu, tylko środowisko, w którym on pracuje: co dostaje na starcie, jakie ma narzędzia, jak dowiaduje się o błędach i jak udowadnia, że skończył. Słowo dosłownie znaczy „uprząż”. Po polsku nie ma jeszcze ustalonego odpowiednika, więc w praktyce mówi się po prostu „harness”.
Agenci AI to dziś większość mojej pracy. Sam pracuję na zmianę w Codexie i Claude Code i trzymam dla nich wspólne instrukcje i skille. Poniżej zebrałem, co o harnessach wiadomo na koniec października 2026 i jak przełożyć to na agenta w firmie.
Skąd wziął się termin harness engineering?
Termin spopularyzował wpis OpenAI z 11 lutego 2026. Ryan Lopopolo opisał w nim pięciomiesięczny eksperyment: zespół zbudował wewnętrzną betę produktu bez ani jednej linijki kodu napisanej ręcznie. Kod, testy, CI, dokumentację i narzędzia wewnętrzne pisał Codex.
Kilka liczb z tego wpisu:
- pierwszy commit pod koniec sierpnia 2025, po pięciu miesiącach repozytorium miało rząd miliona linii kodu,
- około 1 500 pull requestów, na początku trzech inżynierów, później siedmiu, średnio 3,5 PR na inżyniera dziennie,
- zespół szacuje, że zrobił to w około 1/10 czasu potrzebnego przy pisaniu ręcznym,
- pojedyncze uruchomienia Codexa pracowały nad jednym zadaniem nawet ponad sześć godzin.
Najciekawsze jest to, co OpenAI uznało za główną pracę inżynierów. Na początku postęp był wolniejszy niż zakładano. Nie dlatego, że model sobie nie radził, tylko dlatego, że środowisko było niedookreślone. Gdy coś nie działało, zespół nie kazał agentowi „bardziej się starać”, tylko pytał, jakiej możliwości brakuje i jak ją udostępnić agentowi tak, żeby dało się ją wyegzekwować.
W marcu 2026 Anthropic opisał harness dla długich zadań programistycznych z trzema rolami: planner rozpisuje krótki pomysł na specyfikację, generator buduje po jednej funkcji na sprint, a evaluator klika w działającą aplikację przez Playwright MCP i ocenia sprint według twardych progów. Przed każdym sprintem generator i evaluator uzgadniają, co znaczy „gotowe”.
Z czego składa się harness agenta?
Różne źródła dzielą harness trochę inaczej. Dobrą, konkretną listę podaje praca Google Cloud AI Research o Harness², w której każdy element harnessu to osobny plik, więc każda zmiana jest zwykłym diffem:
| Element | Kiedy trafia do kontekstu | Do czego służy | Odpowiednik w Claude Code i Codexie |
|---|---|---|---|
| System prompt | zawsze | rola i ogólna procedura | wbudowany prompt narzędzia |
| Guardrails | zawsze | twarde zasady niezależne od zadania | reguły w AGENTS.md / CLAUDE.md, uprawnienia |
| Pamięć | zawsze | trwałe fakty o projekcie lub domenie | AGENTS.md, CLAUDE.md, pliki pamięci |
| Wskazówki do narzędzi | zawsze | kiedy i jak używać danego narzędzia | opisy narzędzi, opisy serwerów MCP |
| Skille | na żądanie | procedura ładowana, gdy pasuje do zadania | SKILL.md |
| Skrypty | uruchamiane przez powłokę | deterministyczna operacja zamiast „liczenia w głowie” modelu | skrypty w repo i w skillach |
| Subagenci | na żądanie | osobne okno kontekstu, zwracają tylko wynik | subagenci w Claude Code |
| Middleware (hooki) | w pętli narzędzi | wymusza zachowanie, którego model nie może pominąć | hooki w Claude Code |
Do tego dochodzą rzeczy, których nie widać w plikach, ale bez których agent na produkcji jest niebezpieczny: sandbox, sieć, konto i token, logi oraz weryfikacja wyniku. Opisałem je osobno w tekście o środowisku agenta AI: sandbox, logi i uprawnienia.
Ważne rozróżnienie: instrukcja w AGENTS.md to kontekst, nie konfiguracja. Model zwykle jej słucha, ale nic go do tego nie zmusza. Hook, linter albo test wykonują się zawsze. Dlatego zasady, od których naprawdę coś zależy, warto przenosić z prozy do kodu.
Co działa w praktyce: lekcje OpenAI i Anthropic
AGENTS.md jako spis treści, nie encyklopedia
OpenAI próbowało jednego dużego AGENTS.md i to się nie sprawdziło. Za długi plik wypycha z kontekstu samo zadanie, szybko się starzeje i trudno go automatycznie sprawdzać. Skończyło się na pliku o długości około 100 linii, który działa jak mapa i wskazuje, gdzie w katalogu docs/ szukać szczegółów: architektury, planów, specyfikacji produktu, zasad bezpieczeństwa.
To ta sama idea co progressive disclosure w Agent Skills: na starcie agent dostaje mały, stabilny punkt wejścia, a resztę doczytuje, gdy jest potrzebna. Więcej o tym, jak dobierać to, co trafia do okna modelu, piszę w tekście o context engineering.
Zasady wymuszone mechanicznie
W repozytorium OpenAI granice architektury pilnują własne lintery i testy strukturalne. Komunikaty błędów lintera są napisane tak, żeby od razu mówiły agentowi, jak naprawić problem. Osobny agent regularnie szuka nieaktualnej dokumentacji i otwiera PR z poprawkami.
Zespół przyznaje też, że agent kopiuje wzorce, które już są w repo, także te słabe. Na początku ludzie spędzali każdy piątek, czyli 20% tygodnia, na sprzątaniu „AI slop”. To się nie skalowało, więc zapisali zasady w repozytorium i puścili cykliczne zadania w tle, które wyłapują odstępstwa i otwierają małe PR-y z refaktorem.
Osobny weryfikator zamiast samooceny
U Anthropic aplikacje z wcześniejszych wersji harnessu często dobrze wyglądały, ale miały prawdziwe błędy, gdy ktoś zaczynał ich używać. Dlatego evaluator testuje działającą aplikację jak użytkownik: interfejs, endpointy API i stan bazy. Jeśli którekolwiek kryterium spada poniżej progu, sprint jest odrzucany, a generator dostaje konkretną informację, co poprawić. O tym, jak budować takie testy dla agentów, piszę w tekście o evals i trace.
Usuwaj to, czego model już nie potrzebuje
Anthropic w artykule o projektowaniu harnessu zaleca regularnie pytać, co harness może przestać robić, bo zapisuje on założenia o tym, czego model nie potrafi. Z każdą nową wersją modelu część tych założeń przestaje być prawdziwa. Przykład z wspomnianego tekstu o długich zadaniach: Sonnet 4.5 zaczynał kończyć pracę za wcześnie, gdy uznawał, że zbliża się do limitu kontekstu, więc harness czyścił kontekst i startował świeżego agenta. Przy Opus 4.5 to zachowanie w dużej mierze zniknęło i resety kontekstu dało się usunąć.
W innym tekście o łączeniu subagentów z główną pętlą Anthropic pisze, że w kilku wdrożeniach firmowych jeden agent ze skillami często wypadał lepiej niż zestaw wyspecjalizowanych subagentów. Jedna firma po przejściu na pojedynczą pętlę miała mniej więcej dwa razy krótszy czas działania. Z tego samego tekstu: przy ponad 30-50 definicjach narzędzi model zaczyna gorzej wybierać narzędzie, a system prompt Claude Code dla nowszych modeli skrócono o ponad 80%. Szerzej o tym, kiedy subagent ma sens, piszę w tekście o skillach, subagentach i systemach multi-agentowych.
Co pokazują badania z października 2026
Dwie nowe prace dają mniej oczywisty obraz, niż sugerują marketingowe porównania harnessów.
Harness ustala rachunek, nie wynik
Praca „What Does a Harness Buy? Tokens, Mostly” porównała trzy produkcyjne harnessy (Claude Code, mini-SWE-agent i OpenCode) z tymi samymi modelami na SWE-bench Verified. Autorzy powtarzali te same konfiguracje, żeby zmierzyć zwykły szum między uruchomieniami.
- Na 447 zadaniach Claude Code i mini-SWE-agent, najcięższy i najlżejszy harness, okazały się równoważne w granicach 5 punktów procentowych.
- Na 45 najtrudniejszych zadaniach zmiana harnessu zmieniała wynik w 13% zadań, tyle samo co ponowne uruchomienie tego samego harnessu.
- Koszt jednego zadania przy tym samym modelu różnił się nawet trzykrotnie. Decyduje o tym głównie stała część wysyłana przy każdym kroku (system prompt i schematy narzędzi): około 16,6 tys. tokenów w Claude Code, 7 tys. w OpenCode i poniżej tysiąca w mini-SWE-agent, pomnożona przez liczbę kroków.
- Jedyne efekty harnessu, które wyszły ponad szum, to sposoby na przegranie zadania: ucięcie odpowiedzi bez próby wznowienia, przepełnienie okna kontekstu bez kompakcji, narzędzie, które nie działa offline.
Wniosek autorów: dobry harness kupuje przede wszystkim mniej sposobów na porażkę i niższy rachunek. Pojedynczy test na kilkudziesięciu zadaniach nie wystarczy, żeby powiedzieć, który harness jest lepszy.
Harness dopasowany do zadania podnosi wynik
Harness² od Google Cloud AI Research testuje coś innego: agenta, który sam poprawia swój harness pod konkretne zadanie. Proponuje zmiany w plikach harnessu, uruchamia je na tym samym zadaniu i zostawia tylko te, które coś realnie zmieniły. Na zadaniach biurowych, zawodowych i prawniczych jeden taki krok dawał do 11,5 punktu na WorkBuddy-Bench, 4,5 na JobBench i 11,8 punktu procentowego na benchmarku prawniczym LAB. Słabszy model (GLM-5) z poprawionym harnessem wyprzedził mocniejszy model z harnessem bazowym. Gdy z poprawionego harnessu usuwano po jednej grupie elementów, średnio najwięcej kosztowało wyjęcie skilli (5,3 punktu), potem skryptów (3,7).
Te wyniki się nie wykluczają. Dojrzałe, ogólne harnessy do kodowania dają podobny wynik na standardowym benchmarku. Różnicę robi dopasowanie do konkretnej pracy: skill z procedurą danej domeny, skrypt do sprawdzenia wyniku, reguła, która każe agentowi po zapisaniu pliku otworzyć go jeszcze raz i sprawdzić. Ten ostatni przykład pochodzi wprost z analizy przypadku w pracy o Harness²: agent zapisywał pliki i nigdy ich nie weryfikował, a po dodaniu takiej reguły i skryptu wynik zadania wzrósł z 43,1 do 77,8. To jest to, co firma może dołożyć sama.
Jak to wygląda u mnie
Codzienne poprawki SEO na tej stronie robi agent. Jego harness to w praktyce kilka plików i komend: skill z procedurą (od danych z Search Console do gotowej strony), świeży klon repozytorium, build i lint, pull request, a na końcu skrypt, który sprawdza produkcję: kod HTTP 200, dane strukturalne i obecność adresu w sitemapie. Każdy dzień kończy się notatką z liczbami, żeby po tygodniu dało się sprawdzić efekt.
Najważniejsza zasada, której się trzymam: dowód z właściwego środowiska, nie zielony CI. Agent ma pokazać działającą stronę na produkcji, a nie tylko zgłosić, że build przeszedł. To ta sama lekcja co u OpenAI i Anthropic: weryfikacja musi być częścią harnessu, a nie dobrą wolą modelu.
Checklista: harness dla agenta w firmie
- Opisz zadanie i definicję „gotowe” tak, żeby dało się ją sprawdzić automatycznie.
- Krótki
AGENTS.md(alboCLAUDE.md) jako mapa projektu, szczegóły w osobnych plikach. - Procedury, które przydają się od czasu do czasu, przenieś do skilli zamiast do stałego promptu.
- Daj agentowi kilka dobrze opisanych narzędzi zamiast dziesiątek podobnych.
- Operacje powtarzalne (konwersje, walidacje, liczenie) zamknij w skryptach.
- Zasady krytyczne egzekwuj kodem: hook, linter, test, bramka zatwierdzenia.
- Ustal limity: liczba kroków, koszt, czas, akcje wymagające zgody człowieka.
- Wbuduj weryfikację wyniku na prawdziwym środowisku (osobny evaluator, skrypt, test end-to-end).
- Mierz koszt jednego zadania i liczbę kroków, nie tylko odsetek sukcesów. Każde porównanie uruchom więcej niż raz.
- Po zmianie modelu sprawdź, które elementy harnessu można usunąć.
Jeśli wybierasz model do takiego agenta, przyda się też tekst o model routingu.
Kiedy warto zbudować własny harness
Jeśli agent ma robić w firmie jedną powtarzalną rzecz (obsługę zgłoszeń, przygotowanie raportu, przegląd dokumentów, zmiany w kodzie), sam model i ogólny agent to dopiero początek. Resztę trzeba dopisać pod waszą pracę: dostęp do danych, procedury z waszej domeny, uprawnienia i sposób sprawdzenia wyniku. To właśnie jest harness.
Projektuję i wdrażam takich agentów, od warsztatu, przez wycenę i UX, po dwutygodniowe sprinty. Zobacz agentów AI dla firm, wdrożenie AI w firmie albo wszystkie usługi.
Najczęstsze pytania
Co to jest harness w AI?
To warstwa oprogramowania wokół modelu językowego, która zamienia go w agenta. Obejmuje pętlę wykonania, narzędzia, instrukcje, pamięć, zarządzanie kontekstem, uprawnienia i weryfikację wyniku. Model generuje tekst i wywołania narzędzi, a harness decyduje, co z nich naprawdę się wykona.
Czym harness różni się od frameworka?
Framework, na przykład SDK do budowy agentów, to biblioteka, z której składasz agenta. Harness to gotowa, działająca warstwa wokół modelu: konkretne prompty, narzędzia, skille, limity i testy. Claude Code i Codex to przykłady gotowych harnessów do kodowania.
Czy harness engineering to to samo co prompt engineering?
Nie. Prompt engineering dotyczy treści instrukcji. Harness engineering obejmuje też narzędzia, sposób ładowania kontekstu, skrypty, hooki, sandbox, limity i weryfikację. Prompt jest tylko jednym z elementów harnessu. OpenAI skróciło swój AGENTS.md do około 100 linii, a Anthropic skrócił system prompt Claude Code dla nowszych modeli o ponad 80%.
Czy lepszy harness da lepsze wyniki niż lepszy model?
Zależy od zadania. Badanie z października 2026 na SWE-bench Verified pokazało, że zmiana dojrzałego harnessu do kodowania zmienia wynik w granicach szumu, ale koszt nawet trzykrotnie. Przy pracy w konkretnej domenie dopasowany harness (skille, skrypty, weryfikacja) potrafił podnieść słabszy model ponad mocniejszy.
Od czego zacząć budowę harnessu dla agenta w firmie?
Od zestawu prawdziwych przykładów zadań z oczekiwanym wynikiem. Anthropic proponuje na start około 10 wzorcowych przykładów. Potem krótki plik z zasadami projektu, kilka narzędzi, sposób sprawdzenia wyniku i limity. Każdą kolejną zmianę harnessu porównuj na tych samych przykładach, uruchamiając je więcej niż raz.
Źródła
- OpenAI: Harness engineering: leveraging Codex in an agent-first world (11.02.2026)
- Anthropic: Harness design for long-running application development (24.03.2026)
- Anthropic: Agent harness design: 3 patterns for harnessing Claude's intelligence
- Anthropic: Building agents: When to fold subagents into your main agent loop
- Liu, Han: What Does a Harness Buy? Tokens, Mostly (arXiv 2610.04433)
- Google Cloud AI Research: Harness²: Recursive Agent Harnessing for an Open World (arXiv 2610.14224)
Chcesz zbudować agenta AI, MVP albo aplikację?
Projektuję i buduję produkty z AI od pierwszej wersji do produkcji: MVP, aplikacje mobilne w React Native, web appy i agentów AI. Napisz, co chcesz zbudować, a odpowiem, od czego zacząć.