Badanie: rozbudowane harnessy agentów AI kosztują więcej, nie lepsze

Nowe badanie podważa jeden z popularnych mitów wokół agentów kodujących: że rozbudowana „uprząż” (harness) — czyli system promptów, narzędzi i mechanizmów zarządzania kontekstem otaczających model językowy — realnie poprawia skuteczność rozwiązywania zadań programistycznych. Dwaj badacze z Shandong University sprawdzili to empirycznie, trzymając model stały i zmieniając wyłącznie harness. Wyniki są jednoznaczne: różnice między harnessami mieszczą się w granicach zwykłego szumu pomiarowego, a jednocześnie koszty mogą wzrosnąć nawet trzykrotnie.

Agent kodujący to połączenie modelu językowego z harnessem — systemem, który dostarcza modelowi system prompt, narzędzia i mechanizmy zarządzania kontekstem umożliwiające pracę w repozytorium kodu. Nowe harnessy pojawiają się niemal codziennie, a leaderboardy często mieszają je bez rozróżnienia. Tytuł pracy naukowców mówi sam za siebie: „Co właściwie daje harness? Głównie tokeny”.

Kluczowe wnioski

• Zmiana harnessu wpływa na wyniki tak samo mało, jak zwykłe powtórzenie tego samego testu — różnice mieszczą się w szumie pomiarowym.
• Na dużej puli 447 zadań Claude Code i mini-SWE-agent (najcięższy i najlżejszy harness) różnią się o mniej niż dwa punkty.
• Harnessy zużywają od dwóch do trzech razy więcej tokenów niż najbardziej oszczędna opcja, mimo porównywalnej skuteczności.
• Jedynym statystycznie istotnym efektem jest stały deficyt OpenCode — do dziewięciu punktów poniżej pozostałych harnessów na dużej puli zadań.
• Wcześniejsze porównania harnessów, pokazujące różnice powyżej 20 punktów, najprawdopodobniej mierzyły szum, a nie realne różnice jakościowe.

Wcześniejsze porównania mierzyły szum, a nie jakość

Autorzy badania, Liu i Han, zwracają uwagę, że większość dotychczasowych zestawień harnessów opierała się na pojedynczym uruchomieniu testu. Tymczasem same powtórzenia identycznej konfiguracji potrafią różnić się nawet o sześć punktów na benchmarku SWE-bench Verified. Przykładem jest Zhipu AI, które reklamuje własny harness jako lepszy od Claude Code o 2,4 punktu — margines mieszczący się dokładnie w tym paśmie szumu. Dodatkowym problemem jest sposób integracji harnessów z benchmarkiem, który często różni się między testami, co jeszcze bardziej zaburza porównywalność wyników.

Badacze przetestowali pięć modeli w trzech harnessach w ich gotowych, fabrycznych wersjach: Claude Code, OpenCode oraz mini-SWE-agent. Ten ostatni daje modelowi wyłącznie narzędzie Bash i nie ma żadnego zarządzania kontekstem. Claude Code i OpenCode oferują natomiast wyspecjalizowane narzędzia do pracy z plikami i wyszukiwania, rozbudowane system prompty oraz automatyczną kompresję historii rozmowy.

Do testów użyto modeli Qwen3.6, Qwen3.8, Deepseek-V4-Flash, GLM-5.3-Flash oraz HY4-Preview. Claude Opus 5 posłużył jedynie jako punkt odniesienia, uruchamiany wyłącznie w Claude Code. Testy obejmowały 45 najtrudniejszych zadań z SWE-bench Verified oraz pulę 447 kolejnych zadań, a część konfiguracji uruchamiano dwukrotnie, by zmierzyć poziom szumu.

Wszystkie testy przeprowadzono offline. We wcześniejszych próbach z dostępem do internetu 71 procent prób modeli Deepseek i Qwen polegało na pobraniu gotowej poprawki bezpośrednio z GitHuba, zamiast samodzielnie rozwiązać zadanie. Modele Claude niemal nigdy tego nie robiły. Badacze odrzucili te wyniki — nie twierdzą przy tym, że którykolwiek producent trenował modele na danych testowych — ale sama skala zjawiska była na tyle wyraźna, że zdecydowali się odciąć dostęp do internetu we wszystkich pozostałych testach.

Zmiana harnessu to niemal to samo co rerun

Na większej puli 447 zadań Claude Code i mini-SWE-agent — odpowiednio najcięższy i najlżejszy z testowanych harnessów — różnią się o mniej niż dwa punkty dla obu testowanych modeli. W paśmie pięciu punktów są statystycznie równoważne.

Wszystkie trzy harnessy zużywają od dwóch do trzech razy więcej tokenów na model niż najbardziej oszczędna opcja, podczas gdy odsetek rozwiązanych zadań pozostaje w granicach niepewności pomiarowej. Statystycznie istotny okazał się jedynie deficyt OpenCode na dużej puli zadań.

Na 45 najtrudniejszych zadaniach badacze spodziewali się największego efektu harnessu. Tymczasem różnice między harnessami wynoszą od dwóch do pięciu rozwiązanych zadań na model, a samo powtórzenie tej samej konfiguracji zmienia ten wynik nawet o trzy zadania. Raz przewagę ma mini-SWE-agent, raz Claude Code.

Podobną historię opowiadają tzw. flip rates, czyli odsetek zadań, których wynik zmienia się między uruchomieniami. Między dwoma rerunami mediana zmiany wynosi 13 procent. Między dwoma różnymi harnessami — również 13 procent. Zmiana modelu podnosi ten wskaźnik do 22 procent. To, które zadania wygrywa dany harness, zmienia się z uruchomienia na uruchomienie niemal jak przy rzucie monetą. Jak piszą autorzy, różnica między harnessami zachowuje się jak „świeży losowy rysunek z tego samego szumu”.

Te niewielkie próby ograniczają też to, co w ogóle da się wykryć statystycznie. Przy 45 zadaniach nawet różnica 13 punktów ujawnia się tylko w połowie przypadków. Przy 447 zadaniach wiarygodnie wykrywalne stają się różnice rzędu pięciu punktów. Deklarowana przez Zhipu przewaga 2,4 punktu nie przekracza żadnego z tych progów — podobnie jak wiele innych reklamowanych usprawnień.

OpenCode odstaje, reszta kosztuje więcej bez powodu

Jedynym mierzalnym efektem harnessu okazał się stały deficyt OpenCode. Na dużej puli zadań traci on do dziewięciu punktów względem pozostałych dwóch harnessów. Mniej więcej połowa tej różnicy wynika z limitu długości wyjścia. Gdy model przekracza ten limit w trakcie rozumowania, Claude Code każe mu kontynuować pracę. OpenCode pozwala, by krok zakończył się w tym momencie, a próba zwykle kończy się porażką.

Dodanie do OpenCode zachęty do kontynuowania w stylu Claude Code nie pomogło, bo to samo zadanie rzadko wywołuje ten sam problem przy ponownej próbie. Dla reszty luki badacze nie mają wyjaśnienia — jedynie obserwację, że pod OpenCode modele znacznie szybciej przerywają pracę. Dodatkowo przy modelach uruchamianych lokalnie OpenCode miał znacznie ciaśniejszy limit czasowy niż Claude Code, co autorzy sami oznaczają jako niekontrolowaną zmienną, mogącą zniekształcać wyniki.

Mini-SWE-agent napotyka z kolei ograniczenia okna kontekstu, bo brakuje mu mechanizmów zarządzania kontekstem — głównie w zadaniach, w których zawodzą też pozostałe harnessy. Narzędzia wyszukujące w OpenCode przy pierwszym użyciu próbują z kolei pobrać plik binarny i zawodzą w trybie offline.

Różnice w kosztach mają prostsze źródło niż sama skuteczność. Przy tym samym modelu, tych samych zadaniach i tym samym cenniku pojedyncze zadanie może kosztować nawet trzy razy więcej w zależności od harnessu, choć same wyniki narzędzi zwracane przez te systemy mają porównywalną objętość tekstu. Prawdziwa różnica tkwi w systemowym promptcie i opisach narzędzi, które są ponownie wysyłane przy każdym kroku. W przypadku Claude Code zajmują one około 16 600 tokenów, w OpenCode około 7 000, a w mini-SWE-agent poniżej 1 000. Według rekonstrukcji badaczy Claude Code dodatkowo przechowuje w historii rozmowy ślad rozumowania modelu, co jeszcze bardziej podbija zużycie tokenów od samego startu — dalszy wzrost kontekstu przebiega już podobnym tempem we wszystkich trzech harnessach.

Dla zespołów budujących lub wybierających agentów kodujących wnioski są praktyczne: rozbudowana architektura harnessu sama w sobie nie gwarantuje lepszych wyników, a może znacząco podnieść rachunek za tokeny. Zanim porówna się dwa narzędzia tego typu — na przykład w kontekście integracji poprzez MCP czy CLI — warto sprawdzić, czy różnice w wynikach wykraczają poza zwykły szum pomiarowy, bo jak pokazuje badanie Shandong University, w wielu przypadkach tak nie jest.