Ściągasz na laptopa model w otwartych wagach – dwa, trzy miliardy parametrów, bez chmury i bez opłat za token. Dajesz mu zadanie z życia: przejrzyj folder, popraw błąd w skrypcie, przygotuj zestawienie z dwóch arkuszy. Pierwsza odpowiedź brzmi sensownie. Potem model zaczyna wywoływać to samo polecenie raz po raz, po dwudziestym powtórzeniu oznajmia, że zadanie jest gotowe, choć nie powstał żaden plik, albo w połowie milknie. Wniosek narzuca się sam: model jest za mały.
Praca z 1 października (arXiv:2610.02001, autorzy z Pekinu – Uniwersytet Nauki i Technologii oraz Honor Device) przekonuje, że ten wniosek jest często mylny. Winnym jest zwykle szkielet, w którym model pracuje.
Sam model potrafi jedno: przewidzieć ciąg dalszy tekstu. Żeby zrobić cokolwiek w świecie – przeczytać plik, zapisać zmianę, uruchomić polecenie – potrzebuje programu wokół siebie. Ten program nazywa się agent harness, najbliżej po polsku: szkielet agenta. To on składa tekst w jedną całość (instrukcję, historię rozmowy, definicje narzędzi), decyduje, kiedy wywołać narzędzie, wpisuje jego wynik z powrotem do rozmowy i pilnuje, żeby pętla się skończyła. Ten sam model pod dwoma różnymi szkieletami zachowuje się jak dwa różne modele. Mingbird mierzy, jak duża to różnica.
Największy problem nie leży w samym rozumowaniu, tylko w tym, co model dostaje na wejściu. Zanim zobaczy pierwsze zdanie zadania, szkielet wciska mu katalog narzędzi: kilkadziesiąt opisów w formacie JSON, każdy z nazwami parametrów. To kilka tysięcy tokenów, a token to najmniejszy kawałek tekstu, jaki model przetwarza; okno kontekstu jest jego całym budżetem uwagi. Im więcej tekstu wpadnie przed zadaniem, tym mniej uwagi zostaje dla samego zadania, a małe modele tracą precyzję dużo wcześniej, niż zapełni się okno. Mingbird liczy ten narzut w bajtach i trzyma go na twardym limicie: fabryczna instrukcja startowa to 797 tokenów, przypięte testem jednostkowym, a każda nowa funkcja musi dodać zero – jeśli coś dochodzi, coś innego musi zostać skrócone albo wypaść.
Rozwiązanie idzie punkt po punkcie za zaobserwowanymi awariami. Trzy z dziesięciu mechanizmów pokazują sposób myślenia:
– Zamiast jednego wielkiego katalogu narzędzi szkielet najpierw rozpoznaje typ zadania i ładuje tylko narzędzia z tej kategorii, w płaskiej liście. Koszt: klasyfikator może się pomylić i schować narzędzie, którego zadanie potrzebuje, dlatego model może zażądać przeładowania.
– Model nie może ogłosić końca sam. Zanim szkielet przyjmie “gotowe”, wraca do oryginalnej treści zadania i każe modelowi sprawdzić punkt po punkcie, czy wszystko dostarczył; uruchamia też własne kontrole zadania i wpycha z powrotem do rozmowy prawdziwe błędy – nazwę pliku, numer linii, treść komunikatu. Kosztuje to jedną dodatkową turę modelu.
– Pętla ma sygnaturę: narzędzie plus znormalizowane argumenty. Sześć identycznych wywołań albo piętnaście z rzędu bez żadnego wyniku i szkielet przerywa, eskalując nacisk. W jednym z opisanych przypadków model o 4 miliardach parametrów wykonał 156 wywołań i nie stworzył niczego; po poprawce ta sama konfiguracja skończyła w 15 wywołaniach z trzema plikami.
Pomiar. Autorzy zbudowali własny zestaw testowy: cztery szkielety, cztery modele w otwartych wagach (od 2 do 35 miliardów parametrów) i 18 realnych zadań, a ocena jest automatyczna i deterministyczna – liczy się plik na dysku, nie styl odpowiedzi. Mingbird osiąga 0,886, goose 0,631, opencode 0,479, agent-mini 0,405; wszystkie 288 komórek pomiaru leżą publicznie w repozytorium. Na τ²-bench, zestawie zewnętrznym obejmującym 278 zadań (model rozmawia tam z symulowanym użytkownikiem), Mingbird wypada 0,856 wobec 0,791 i 0,737. Ten sam zestaw 18 zadań uruchomiony na modelu z najwyższej półki daje wyniki od 0,997 do 0,478 – zależnie od szkieletu. Temat nie dotyczy więc tylko małych modeli, choć dobrze zbudowane szkielety mieszczą się w granicach 0,072 od siebie.
Uczciwa uwaga, którą autorzy wysuwają na pierwszy plan: przypisanie wyniku do pojedynczych mechanizmów jest u nich kierunkowe, nie dowodowe. Powtórki tego samego wariantu w tę samą noc przesuwają średnią o 0,069, czyli o tyle, ile wynosi każda pojedyncza różnica. Jedyne porządnie sparowane porównanie daje +0,10 dla kontroli końca zadania. Innymi słowy: wiadomo, że zestaw mechanizmów działa, ale nie wiadomo dokładnie, ile wnosi każdy z nich. Zestaw LRAB też jest autorski – to pomiar wykonany przez twórców narzędzia, opisany i powtarzalny, ale nie niezależny.
Co z tego zostaje dla kogoś, kto trzyma model na własnym dysku? Przede wszystkim zmiana pytania. Kiedy mały model gubi się w zadaniu, warto najpierw sprawdzić, ile tekstu dostał przed zadaniem, czy wolno mu ogłosić koniec bez dowodu i czy ktoś pilnuje powtórzeń – a nie od razu szukać większego modelu. Kod Mingbirda jest na licencji Apache-2.0, dostępny jako aplikacja okienkowa i narzędzie wiersza poleceń, a model, narzędzia, pamięć i rozpoznawanie mowy działają lokalnie; jedyne wyjście na zewnątrz to wyszukiwarka, jeśli użytkownik ją podłączy.
O tym, jak szkielet decyduje o zachowaniu agenta, pisaliśmy już przy okazji DeepSeek Harness: https://ai.quailoop.com/pl-deepseek-harness-otwarty-framework-agentow-w-ktorym-wszystko-jest-pluginem-166-tys-gwiazdek-w-3-dni/
Treść została wygenerowana przy użyciu sztucznej inteligencji i zweryfikowana przez redaktora.
Źródła:
– Mingbird: A Local-First Agent Harness Enabling Small Open Models to Complete Real Tasks (arXiv:2610.02001, 1.10.2026) – https://arxiv.org/abs/2610.02001
– Kod, protokół testu i wszystkie 288 wyników: https://github.com/Mingbird/Mingbird-agent
– τ²-bench, zewnętrzny zestaw testowy użyty w pracy (arXiv:2506.07982) – https://arxiv.org/abs/2506.07982
Wersja angielska: https://ai.quailoop.com/mingbird-when-a-small-local-model-fails-the-harness-is-usually-the-one-to-blame/
Skomentuj
You must be logged in to post a comment.