Harness² od Google Research: popraw agenta bez zmiany modelu

• Harness² to projekt Google Research, który zmienia otoczenie agenta AI (prompty, narzędzia, pamięć, pętlę sterowania), a nie sam model.
• Badacze zgłaszają wzrosty do 11,5 pkt na WorkBuddy-Bench, do 4,5 pkt na JobBench i do 11,8 pp na LAB, na modelach GLM-5 i Gemini 3.5 Flash.
• Kod jest w repozytorium google-research/harness2 na GitHubie. Darmowe demo działa bez kluczy API, ale pokazuje tylko, że instalacja się spina, a nie samą metodę.
• Pełny przebieg wymaga poświadczeń Vertex AI i kosztuje 4-20 pełnych przebiegów agenta na zadanie.

Google Research stoi za Harness², projektem, który zamiast wymieniać model agenta na lepszy, poprawia wszystko wokół niego. W tekście Analytics Vidhya z 30.10.2026 autor zainstalował projekt i uruchomił demo. Liczby poniżej to deklaracje badaczy, a nie niezależny test.

Agent się wywala? Najpierw sprawdź, co go otacza

Kiedy agent nie kończy zadania, odruch jest jeden: wziąć mocniejszy model. To normalny odruch, dopóki nikt nie pokaże Ci, że jest druga dźwignia. Bez technobełkotu: harness to wszystko, co otacza model. Instrukcje, narzędzia, pamięć i pętla, która pilnuje, co agent robi krok po kroku.

Według opisu Harness² żaden harness nie wygrywa wszędzie. Claude Code radzi sobie lepiej w kodowaniu i arkuszach, a Codex prowadzi w zadaniach webowych. Stały harness zostawia więc wynik na stole. Harness² ma się dostosowywać w trakcie testu, także do zadań, których jego twórcy nie przewidzieli. Podobny wątek rozwijamy w tekście o tym, że system wokół modelu decyduje o agencie AI.

Dlaczego agent nie powinien dopisywać sobie instrukcji

Pomysł, żeby agent sam przepisywał swój prompt systemowy, wygląda rozsądnie, a w praktyce może pogorszyć wyniki. Prompt systemowy jest przetwarzany wielokrotnie w trakcie zadania. Im dłuższy, tym więcej tokenów zjada i tym mniej zostaje na właściwą pracę. Gdy budżet tokenów się kończy, agent może polec, zanim skończy.

Osiem komponentów, które nic nie kosztują, dopóki nie zadziałają

Harness² udostępnia osiem edytowalnych komponentów. Większość z nich śpi, dopóki coś ich nie wyzwoli, więc nie obciążają budżetu tak, jak dopisany tekst w prompcie.

• Kontekst: prompt systemowy, guardrails, pamięć, umiejętności (to, co model widzi przed działaniem).
• Interfejs narzędzi: wskazówki do narzędzi i skrypty.
• Delegowanie: subagenci, czyli praca przekazana do czystego kontekstu.
• Middleware: wtyczki działające wewnątrz pętli narzędzi.

Reguła w kodzie zamiast prośby w prompcie

Najciekawsze jest rozróżnienie z opisu projektu: reguła w prompcie to rada, reguła w pętli sterowania jest egzekwowana. Prośba w prompcie to kartka „prosimy nie wchodzić”. Reguła w pętli to zamek w drzwiach.

Dwa przykłady poprawek, które agent sam sobie zbudował:

• Koniec z niekończącym się szukaniem: watchdog liczy kroki agenta i zmusza go do pisania, zanim skończy się budżet tokenów.
• Arkusze bez dziur: agent nie może uznać zadania za gotowe, dopóki skrypt nie potwierdzi, że w arkuszu nie brakuje formuł.

Taki bezpiecznik działa niezależnie od tego, czy model ma ochotę słuchać poleceń. Watchdog w roli strażnika pojawia się też w prototypie Super-agenta od DeepSeek, więc podobny wzorzec widać w więcej niż jednym projekcie.

Dwa przebiegi zamiast ślepej wiary w poprawki

Trudność polega na tym, że w prawdziwym zadaniu nie masz klucza odpowiedzi, więc nie wiesz, czy zmiana pomogła. Harness² radzi sobie z tym w trzech krokach:

• Propose: agent wykonuje zadanie raz. Dwóch edytorów czyta log. Jeden szuka problemów z mechaniką pracy (np. zepsute wywołania narzędzi), drugi działa jak specjalista dziedzinowy i proponuje reguły merytoryczne.
• Probe: poprawiony harness wykonuje to samo zadanie drugi raz.
• Compose: oba przebiegi są porównywane. Poprawka zostaje tylko wtedy, gdy naprawiła konkretną, widoczną awarię z pierwszego przebiegu. Reszta wylatuje.

Sygnałem są różnice między wykonaniami, a nie wynik względem znanej odpowiedzi. Krok probe nie jest ozdobą: bez niego wydajność spadła o około 10%. Ślepe zaufanie poprawkom agenta wypadło gorzej niż brak jakichkolwiek poprawek. Podobną logikę (najpierw sprawdź, potem ufaj) znajdziesz w testach E2E z agentem AI.

Co zgłaszają badacze, a co pokazuje demo

Wyniki z badania

Badanie objęło trzy profesjonalne benchmarki i cztery konfiguracje model-harness, na GLM-5 i Gemini 3.5 Flash. Pojedynczy krok poprawił wynik względem bazowego harnessu w każdej z nich. Zgłoszone liczby:

• WorkBuddy-Bench: do 11,5 pkt.
• JobBench: do 4,5 pkt.
• LAB (częściowy wskaźnik zaliczeń): do 11,8 pp.
• Pięć kandydatów sprawdzanych równolegle: dodatkowe 2,9-3,9 pkt na WorkBuddy-Bench.
• Legal redlining i budget reconciliation: 35-50 pkt w jednym kroku.
• Harness wyewoluowany na silnym modelu i przekazany mniejszemu: 17 pkt od razu.

Jest też wynik na minus. Metoda pamięci ReasoningBank wypadła w kodowaniu o 6,6 pkt gorzej niż bazowy harness, więc samo gromadzenie wspomnień agenta nie gwarantuje poprawy.

Co sprawdził autor tekstu

Autor Analytics Vidhya zainstalował projekt na Linuksie (Python 3.12, uv; projekt wymaga Pythona od 3.12 do poniżej 3.14) i uruchomił demo bez kluczy API. Dwa zadania księgowe zakończyły się bez błędów: 28 wykonań, 32 wywołania edytora, 2360 plików o łącznej wadze około 265 KB. Przebieg kosztował 6-8 pełnych przebiegów agenta przy k=2, czyli mieścił się w dolnej części zakresu 4-20 podawanego przez badaczy.

Autor ostrzega, że demo sprawdza instalację i przepływ, a nie metodę. Większość komponentów jest pusta albo jest atrapą (prompt systemowy ma 56 bajtów), a deterministyczne edytory nie tworzą prawdziwej treści, więc żaden harness nie jest realnie przepisywany. Żeby zobaczyć właściwą metodę, potrzebujesz modelu i prawdziwego benchmarku: Node.js 20+, Google Cloud CLI i poświadczeń Vertex AI. LAB wymaga dodatkowo Pandoc i Poppler, a WorkBuddy Dockera. Koszt w złotówkach zależy od modelu, więc sprawdzisz go w cenniku wybranego dostawcy.

Jeśli sam zdecydujesz się na test, autor radzi zacząć od --dry-run, który pokazuje wybór zadań bez wydawania pieniędzy, a potem od --max-tasks 1, bo każde zadanie odpala wiele wykonań. To nie magia, to system, i ten system ma rachunek za każdy przebieg. Wynik z benchmarku warto czytać razem z tym rachunkiem.

Jeśli nie programujesz, z tej historii wyniesiesz jedno: awarię trzeba opisać konkretnie, zanim zaczniesz szukać rozwiązania. Harness² też od tego startuje. Weź jedno zadanie, które AI ostatnio zepsuło (raport bez wniosków, arkusz z brakującymi formułami, odpowiedź urwana w połowie) i zapisz w jednym zdaniu, co dokładnie poszło nie tak, tak żeby dało się to sprawdzić okiem. Potem dopisz to do swojego promptu jako końcową kontrolę: „zanim uznasz zadanie za skończone, sprawdź X i pokaż mi wynik”. W zwykłym czacie to nadal prośba, a nie blokada, bo kod egzekwuje reguły dopiero w pętli agenta. Za to konkretna, widoczna awaria opisana wprost da Ci punkt odniesienia, czy kolejna poprawka cokolwiek zmieniła. Jeśli chcesz zobaczyć, jak inni składają agentów z narzędzi, zajrzyj do opisu DeepSeek Harness.