Google Harness2 udostępnia samodoskonalenie agentów jako open source, lecz weryfikacja pozostaje kluczowym sprawdzianem

Google udostępnił jako open source Google Harness2 po przedstawieniu wyników wskazujących na poprawę sięgającą 11,5 punktu dzięki zmianie otaczającego agenta oprogramowania zamiast samego modelu. To rozróżnienie tworzy główne napięcie. Framework pozwala agentowi zmieniać prompty, narzędzia, pamięć i inne instrukcje operacyjne, lecz musi oceniać te zmiany bez znanych poprawnych odpowiedzi.

Projekt, nazwany przez autorów Harness², pochodzi od badaczy związanych z Google Cloud AI Research i Northwestern University. Jego kod pojawił się wraz z artykułem badawczym z 9 października 2026 roku i jest dostępny na licencji Apache 2.0. Wydanie przekształca metodę badawczą w oprogramowanie, które deweloperzy mogą analizować, uruchamiać i modyfikować.

Projekt podważa także znane założenie dotyczące agentów AI. Lepsze wyniki nie zawsze wymagają nowszego lub większego modelu. Mogą wynikać ze zmiany harnessu, czyli oprogramowania i instrukcji, które przekształcają model językowy w system wykonujący działania.

Ten argument wywiera presję na statyczne frameworki agentowe. OpenCode, Codex, Claude Code i podobne systemy łączą modele z promptami, narzędziami, pamięcią i orkiestracją. Google Harness2 pyta, czy te otaczające komponenty powinny pozostawać niezmienne po wdrożeniu.

Odpowiedź ma znaczenie wykraczające poza rankingi benchmarków. Harness samodzielnie wprowadzający zmiany może dostosować się do nieznanych zadań prawnych, biurowych, internetowych i programistycznych. Może również utrwalić błędne założenie, wybrać słabszą zmianę lub zużyć znacznie więcej mocy obliczeniowej, aby dojść do odpowiedzi.

Google Harness2 zmienia oprogramowanie wokół zamrożonego modelu

Wydanie przenosi rekurencyjne ulepszanie z trenowania modelu do ośmiu edytowalnych części środowiska uruchomieniowego agenta.

Agent AI to coś więcej niż model językowy odpowiadający na prompty. Zależy także od instrukcji, dostępnych narzędzi, przechowywanego kontekstu, zasad delegowania i oprogramowania kontrolującego każde działanie. Łącznie te komponenty tworzą harness agenta.

Google Harness2 udostępnia do modyfikacji osiem komponentów: prompt systemowy, zabezpieczenia, pamięć, wskazówki dotyczące narzędzi, subagentów, umiejętności, skrypty i wtyczki middleware. Każdy komponent jest reprezentowany jako plik montowany w środowisku uruchomieniowym. Bazowe wagi modelu pozostają zamrożone.

To rozdzielenie jest istotne. Trenowanie lub dostrajanie modelu wymaga wyspecjalizowanej infrastruktury, przygotowanych danych i odrębnego procesu wdrożeniowego. Edycja promptu, umiejętności lub instrukcji narzędzia może nastąpić, gdy agent pracuje nad zadaniem.

Repozytorium open source udostępnia tę metodę jako projekt Python dla systemu Linux. Obsługuje Python 3.12, równoległe i sekwencyjne udoskonalanie oraz integracje z wykonawcami OpenCode i Codex. Dołączona demonstracja korzysta z deterministycznych edytorów i lokalnego wykonywania Pythona, dzięki czemu deweloperzy mogą przeanalizować workflow bez poświadczeń modelu.

Oceny wspierane przez modele wymagają większej infrastruktury. Repozytorium wskazuje Node.js, uwierzytelnianie Google Cloud, dostęp do modeli przez Vertex AI oraz zależności właściwe dla benchmarków. WorkBuddy-Bench wymaga Dockera, natomiast benchmark prawny wymaga narzędzi do przetwarzania dokumentów.

Ta konfiguracja wskazuje na obecnych odbiorców projektu. To oprogramowanie badawcze dla zespołów gotowych prowadzić kontrolowane ewaluacje, a nie funkcja konsumencka, która po cichu ulepsza każdego agenta. Wydanie dostarcza mechanizmy do eksperymentowania, lecz użytkownicy nadal potrzebują zadań, środowisk wykonawczych, oceniających i limitów operacyjnych.

Framework rozpoczyna każde przychodzące zadanie od wspólnego bazowego harnessu. Nie przenosi po prostu najnowszej konfiguracji specyficznej dla zadania do kolejnego zlecenia. Zamiast tego tymczasowo udoskonala bieżący harness i zapisuje możliwe do ponownego użycia wnioski w oddzielnej bibliotece ulepszeń.

Ta decyzja rozwiązuje częsty problem systemów adaptacyjnych. Instrukcja pomagająca w analizie umowy może zaszkodzić zadaniu dotyczącym arkusza kalkulacyjnego. Bezpośrednie gromadzenie każdej skutecznej edycji sprawiłoby, że harness stawałby się coraz bardziej wyspecjalizowany i trudny do zrozumienia.

Harness² próbuje natomiast zachować dowody wyjaśniające, dlaczego dana edycja pomogła. Przyszłe zadanie może skorzystać z tego doświadczenia, nie dziedzicząc całej wcześniejszej konfiguracji wykonawczej.

Projekt reprezentuje zatem dwie formy oprogramowania. Jeden harness wykonuje pracę, a drugi ulepsza system, który ją wykonuje. Ta druga warstwa sprawia, że autorzy opisują tę metodę jako rekurencyjne tworzenie harnessów agentowych, a nie zwykłą optymalizację promptów.

Dla deweloperów, którzy już ręcznie utrzymują instrukcje agentów, wydanie formalizuje rozpoznawalny workflow. Zespoły analizują błędy, zmieniają instrukcje, ponownie uruchamiają zadania i zachowują użyteczne techniki. Google Harness2 przekazuje znaczną część tej pętli agentom i zapisuje wynikające z niej zmiany jako ustrukturyzowane artefakty.

Jak Google Harness2 udoskonala agenta bez poprawnych odpowiedzi

Jego podstawowy mechanizm porównuje zachowanie w dopasowanych warunkach, zamiast wymagać od idealnego weryfikatora wskazania właściwego wyniku.

Framework nazywa główny proces na poziomie zadania Propose-Probe-Compose. Proposer najpierw analizuje pierwotne wykonanie i sugeruje ukierunkowane zmiany harnessu. Probe ponownie uruchamia to samo zadanie z tymi kandydatami. Następnie composer łączy zmiany potwierdzone różnicami między powstałymi trajektoriami.

Trajektoria to zarejestrowana sekwencja odpowiedzi modelu, wywołań narzędzi, obserwacji i wygenerowanych plików. Daje systemowi więcej dowodów niż sama odpowiedź końcowa. Edytor może zobaczyć, czy jedna zmiana znalazła brakujące dane wejściowe, uruchomiła odpowiednie narzędzie lub zweryfikowała dokument przed przesłaniem.

System dzieli propozycje na dwa zakresy. Edytor niezmienników skupia się na ogólnym zachowaniu wykonawczym, takim jak sprawdzanie wyników po ich zapisaniu. Edytor domenowy koncentruje się na wiedzy, formatach lub procedurach specyficznych dla zadania.

To rozdzielenie zmniejsza prawdopodobieństwo, że każdy problem otrzyma tę samą ogólną poprawkę. Pozwala też composerowi połączyć szeroko użyteczną zasadę procesu ze specjalistycznymi wskazówkami, gdy oba rodzaje zmian prowadzą do pomocnych różnic w zachowaniu.

Co kluczowe, proces online nie otrzymuje klucza odpowiedzi benchmarku. Artykuł badawczy opisuje środowisko otwartego świata, w którym zadania pojawiają się po zaprojektowaniu harnessu. Podczas wykonania może nie istnieć wiarygodny weryfikator prawdy referencyjnej.

Zamiast uznawać jednego kandydata za poprawnego, system szuka kontrastów. Załóżmy, że bazowy agent pomija kilka plików źródłowych. Jedna zmiana tworzy spis wszystkich danych wejściowych, a inna dodaje wskazówki dotyczące uzgadniania arkuszy kalkulacyjnych. Ich trajektorie pokazują, czy te interwencje zmieniły proces agenta.

Composer wykorzystuje te dowody do skonstruowania kolejnego harnessu i ponownego uruchomienia zadania. Podejście nie eliminuje osądu. Przenosi osąd z porównywania wyniku ze znaną odpowiedzią na porównywanie obserwowalnego zachowania między wykonaniami.

Deweloperzy mogą przeznaczyć dodatkową moc obliczeniową w czasie testowania na dwa sposoby. Równoległa rekurencja bada jednocześnie wiele kandydackich zmian, a następnie łączy dowody z tych prób. Rekurencja sekwencyjna stosuje kolejne udoskonalenie po każdej wcześniejszej zmianie.

Zmienna k kontroluje budżet tej eksploracji. Większa wartość daje systemowi więcej okazji do znalezienia i przetestowania zmian, lecz każda okazja zwiększa liczbę wywołań modelu, użycie narzędzi i czas wykonania.

Po zakończeniu zadania drugi poziom rekurencji aktualizuje harness ciągłego ulepszania. Reflector zapisuje przyjęty harness oraz plik doświadczeń opisujący interwencję, dowody i wynik. Późniejsze propozycje mogą korzystać z tej biblioteki.

Ta konstrukcja sprawia, że doświadczenie jest bardziej przenośne niż gotowy prompt. Zapamiętana lekcja może wskazywać, że zadania generowania dokumentów zyskują na ponownym otwarciu finalnych plików i sprawdzeniu wymaganych sekcji. Taki proces można stosować w różnych domenach, nawet gdy konkretne dokumenty się różnią.

To rozróżnienie łączy framework również z codzienną pracą opartą na wiedzy. Agent może potrzebować połączyć notatki ze spotkań, arkusze kalkulacyjne, polityki i dokumenty projektowe przed przygotowaniem notatki decyzyjnej. Trudność często polega na śledzeniu twierdzeń w różnych źródłach, a nie na tworzeniu płynnego tekstu.

Zespoły mogą już zmniejszyć to obciążenie, budując przeszukiwalną bazę wiedzy. Harness² rozszerza tę ideę na politykę wykonawczą: agent może zmieniać sposób gromadzenia, sprawdzania i wykorzystywania tych materiałów dla konkretnego zadania.

Mechanizm pozostaje jednak eksperymentalny. Kontrast zachowań jest dowodem, a nie prawdą. Dwaj kandydaci mogą podzielać to samo błędne założenie, a dopracowana trajektoria nadal może prowadzić do słabego rezultatu.

Wzrosty w benchmarkach wywierają presję na statyczne harnessy agentów

Przedstawione wyniki sugerują, że projekt harnessu może zmieniać wydajność równie mocno jak wymiana modeli, zwłaszcza w słabszych systemach wyjściowych.

Badacze ocenili Harness² w trzech profesjonalnych benchmarkach. WorkBuddy-Bench obejmuje zadania programistyczne, internetowe i biurowe. JobBench testuje pracę profesjonalną, a Legal Agent Benchmark firmy Harvey mierzy wyniki w zadaniach prawnych.

Testy objęły cztery kombinacje dwóch modeli i dwóch początkowych harnessów. Modelami były Gemini 3.5 Flash i GLM-5. Początkowymi harnessami wykonawczymi były OpenCode i Codex, natomiast Claude Opus 4.8 pełnił rolę domyślnego edytora w głównych eksperymentach.

Według autorów pojedynczy krok udoskonalenia poprawił każdą testowaną kombinację modelu i harnessu we wszystkich trzech benchmarkach. Największe zgłoszone wzrosty wyniosły 11,5 punktu w WorkBuddy-Bench, 4,5 punktu w JobBench oraz 11,8 punktu procentowego w częściowym wskaźniku zaliczenia benchmarku prawnego.

Największa zmiana w WorkBuddy-Bench pojawiła się dla GLM-5 w OpenCode. Średni wynik wzrósł z 64,2 do 75,7 po jednym kroku. Gemini 3.5 Flash w OpenCode wzrósł z 72,4 do 77,5.

Te liczby wspierają praktyczny wniosek. Harness może zmniejszyć część różnicy między modelami, korygując zachowania wykonawcze, których sama zdolność modelu nie rozwiązuje.

Wyniki różniły się zależnie od konfiguracji. GLM-5 w Codex zyskał zaledwie 1,2 punktu w JobBench, przechodząc z 23,6 do 24,8. Gemini w OpenCode poprawił się o 4,5 punktu w tym samym benchmarku.

Ta zmienność jest ważniejsza niż najwyższa liczba z nagłówków. Metoda nie przyniosła jednej, jednolitej poprawy dla każdego modelu, harnessu i zadania. Jej wartość zależała od systemu wyjściowego i domeny.

Badacze zwiększyli także budżet rekurencji. W przypadku Gemini w OpenCode przejście od jednego kroku udoskonalenia do równoległej rekurencji przy k=5 dodatkowo podniosło wyniki WorkBuddy-Bench. Kod osiągnął 80,8, internet 81,7, a zadania biurowe 83,4.

Artykuł podaje, że wyniki zarówno równoległe, jak i sekwencyjne rosły wraz ze zwiększaniem budżetu z jednego do pięciu w wybranych domenach WorkBuddy-Bench. Konkurencyjne metody wykazały w tych testach mniejsze lub mniej spójne zmiany.

Większa eksploracja nie była jedynym wyjaśnieniem. W badaniu ablacyjnym usunięcie biblioteki ulepszeń obniżyło średnią wydajność WorkBuddy-Bench o 3,1 punktu. Usunięcie wyspecjalizowanych ról edytorów kosztowało 2,9 punktu, a pominięcie kompozycji 1,6 punktu.

JobBench wykazał podobny wzorzec. Usunięcie biblioteki obniżyło wynik o 1,8 punktu, ogólni edytorzy stracili 3,7 punktu, a pominięcie kompozycji 1,9 punktu. Wyniki te wskazują, że zachowane doświadczenie, wyspecjalizowane propozycje i łączenie oparte na dowodach wniosły osobny wkład.

Studium przypadku JobBench ilustruje ten mechanizm. Agent bazowy nie zdołał uzgodnić informacji między plikami źródłowymi i nie otworzył ponownie końcowego wyniku w celu weryfikacji. Uzyskał wynik 43,1.

Jedna z proponowanych interwencji wymagała spisu wszystkich danych wejściowych i jawnego śledzenia źródeł. Druga dodawała wskazówki domenowe dotyczące uzgadniania harmonogramu, miejsca, pracy i budżetu. Kompozytor zachował wszystkie cztery zmiany wprowadzone przez te interwencje, a ponowne uruchomienie uzyskało wynik 77,8.

Ten przykład wzmacnia argument za ulepszaniem harnessu agenta, ponieważ porażka miała charakter proceduralny. Modelowi nie brakowało ani podstawowych zdolności językowych, ani dostępu do plików. Brakowało mu niezawodnej metody działania.

Stałe harnessy nadal osiągały różne wyniki w zależności od domeny. Porównanie w pracy wykazało, że Claude Code przewodził wśród systemów o stałym harnessie w zadaniach programistycznych i biurowych, podczas gdy Codex prowadził w zadaniach webowych. Żaden niezmieniony harness nie dominował wszędzie.

Wychodząc od OpenCode z większym budżetem rekurencji, Harness² przewyższył najsilniejszą stałą alternatywę o 4,6 punktu w kodzie, 5,8 w sieci i 4,9 w zadaniach biurowych. Autorzy wyraźnie zaznaczają, że ten adaptacyjny wynik wykorzystywał dodatkowe zasoby obliczeniowe w czasie testowania.

Presja konkurencyjna dotyczy więc podejścia opartego na stałym harnessie, a nie jednego konkretnego produktu. Dostawca może ulepszać swój model, lecz użytkownicy nadal mogą otrzymywać niespójne wyniki, jeśli otaczające go instrukcje i narzędzia nie potrafią się dostosować.

Samoulepszające się harnessy agentów nadal wymagają niezależnej kontroli

Harness² może usprawnić proces działania agenta, ale jego własne dowody pokazują, że rekurencyjne zmiany czasem wybierają gorsze zachowanie lub rozpowszechniają błędne założenie.

Wyniki benchmarków pochodzą od autorów projektu i nie potwierdziły jeszcze niezawodności produkcyjnej w niezależnych wdrożeniach. Praca raportuje średnie z trzech uruchomień, co pomaga mierzyć zmienność, ale nie zastępuje zewnętrznej replikacji.

Metoda zużywa też dodatkowe zasoby obliczeniowe przed dostarczeniem końcowego wyniku. Każda propozycja, sonda, kompozycja i ponowne uruchomienie konsumuje tokeny oraz czas wykonania. Przetwarzanie równoległe może skrócić czas oczekiwania, gdy dostępna jest odpowiednia przepustowość, ale nie eliminuje podstawowego kosztu zasobowego.

Praca umieszcza oceniane konfiguracje na empirycznej granicy wydajności obliczeniowej dla JobBench i WorkBuddy-Bench. Oznacza to, że zmierzone zyski wypadały korzystnie na tle testowanych alternatyw. Nie oznacza to, że rekurencja będzie ekonomiczna dla każdego obciążenia produkcyjnego.

Zadanie o niskiej wartości może nie uzasadniać kilku wykonań modelu. Opinia prawna lub decyzja operacyjna mogą uzasadniać dokładniejszą kontrolę, lecz te dziedziny wymagają również bardziej rygorystycznych zabezpieczeń niż zapewnia uruchamianie benchmarku.

Najważniejsze ostrzeżenie wynika z własnej analizy niepowodzeń autorów. Zbadali dziewięć regresji i podzielili je na błędy wyboru kandydatów, wspólne nieprawidłowe przesłanki oraz niepewność oceny lub wykonania.

W jednym przykładzie programistycznym framework wybrał wynik oceniony na 55 zamiast alternatywy ocenionej na 95. W zadaniu prawnym węższa rewizja ograniczyła zakres i obniżyła wynik z 54 do 26.

Inne niepowodzenia zaczynały się od błędnego założenia wspólnego dla kandydatów. Błędy te powodowały straty od 2 do 11 punktów. Jeśli każda proponowana zmiana przyjmuje tę samą fałszywą przesłankę, porównywanie ich zachowania nie ujawnia pierwotnego błędu.

Praca wskazuje również brakujące decyzje sędziego i zwykłą zmienność między uruchomieniami jako problemy z atrybucją. Zmieniony wynik może odzwierciedlać zmianę, stochastyczne wykonanie albo szum ewaluacyjny. Więcej sond pomaga, ale zwiększa koszt.

Aktywność w repozytorium ujawniła również ryzyka implementacyjne. Otwarte zagadnienie dotyczące tożsamości pamięci podręcznej zgłasza, że wznowione eksperymenty mogą ponownie wykorzystywać wcześniejsze wyniki po zmianie instrukcji zadania lub plików źródłowych, jeśli identyfikatory zadań pozostają stałe.

Autor zgłoszenia odtworzył to zachowanie bez wywołań modelu i zauważył, że treść danych wejściowych nie występuje w części zapisanej tożsamości uruchomienia. Raport nie określa ilościowo wpływu na opublikowane wyniki benchmarków, a podczas przeglądu nie dołączono rozwiązania od opiekuna projektu.

Mimo to zgłoszenie ilustruje szersze wyzwanie operacyjne. System rekurencyjny potrzebuje wiarygodnej historii pochodzenia zadań, materiałów źródłowych, rewizji harnessu, wyników z pamięci podręcznej i ustawień ewaluacji. W przeciwnym razie pozorna poprawa może wynikać z nieaktualnych dowodów.

Bezpieczeństwo rodzi kolejną obawę. Osiem edytowalnych komponentów obejmuje zabezpieczenia, skrypty, wtyczki i instrukcje narzędziowe. Pliki te mogą wpływać na to, do czego agent uzyskuje dostęp i jakie działania wykonuje.

Autonomiczny edytor nie powinien otrzymywać nieograniczonego uprawnienia do osłabiania kontroli dostępu, uruchamiania niezweryfikowanych skryptów ani trwałego zapisywania wrażliwych szczegółów zadań. Zastosowanie produkcyjne wymaga uprawnień na poziomie komponentów, niezmiennych granic bezpieczeństwa, dzienników audytowych i możliwości wycofania zmian.

Trwałe doświadczenie wymaga podobnej ostrożności. Użyteczna lekcja od jednego klienta, działu lub w sprawie prawnej może ujawnić poufne informacje po pobraniu jej dla innego. Biblioteka usprawnień potrzebuje zatem separacji danych i zasad retencji, a nie tylko trafności semantycznej.

Zespoły powinny także odróżniać optymalizację wydajności od walidacji bezpieczeństwa. Wynik benchmarku nagradza ukończenie zadania według jego ewaluatora. Nie mierzy automatycznie prywatności, autoryzacji, zgodności faktograficznej ani odporności na złośliwe dane wejściowe.

Google Harness2 samo pokazuje, dlaczego to rozróżnienie ma znaczenie. Jego kompozytor może preferować behawioralnie przekonującego kandydata, który obiektywnie jest słabszy. Brak prawdy referencyjnej jest problemem, którym zajmuje się framework, ale pozostaje ograniczeniem, którego framework nie może usunąć.

Rozsądny projekt produkcyjny pozwalałby systemowi modyfikować wskazówki o niższym ryzyku, jednocześnie chroniąc podstawowe polityki. Sformułowania promptów i listy kontrolne przepływu pracy mogłyby być edytowalne. Zasady dotyczące poświadczeń, granice sieciowe, bramki zatwierdzania i limity działań destrukcyjnych powinny pozostać poza uprawnieniami agenta.

Ludzka kontrola pozostaje także cenna w przypadku proponowanych zmian utrzymywanych między zadaniami. Framework może tworzyć dowody wyjaśniające, dlaczego dana zmiana została przyjęta. Operatorzy mogą wykorzystać ten zapis do zatwierdzenia, odrzucenia lub ograniczenia zmiany, zanim trafi ona do wspólnej biblioteki.

Rekurencyjne budowanie harnessów agentów zmienia mapę drogową inżynierii agentów

Kolejnym testem będzie to, czy organizacje potrafią odtworzyć te zyski, kontrolując jednocześnie koszty obliczeniowe, regresje i trwałą pamięć.

Pierwszym sygnałem, który warto obserwować, jest niezależna replikacja benchmarków. Repozytorium udostępnia kod, konfiguracje, prompty i polecenia ewaluacyjne, dając zewnętrznym zespołom praktyczny punkt wyjścia. Replikacje powinny raportować zarówno końcowe wyniki, jak i całkowite użycie modeli.

Udana replikacja u różnych dostawców wzmocniłaby główne twierdzenie. Pokazałaby, że adaptacyjne budowanie harnessu nie jest ściśle związane z testowanymi modelami, edytorem ani środowiskiem Google Cloud.

Niepowodzenie w odtworzeniu zysków osłabiłoby argument o ogólności. Badacze musieliby ustalić, czy różnica wynikała z zachowania modelu, wersji benchmarków, środowisk wykonawczych czy ustawień ewaluacji.

Drugim sygnałem jest wydajność w rzeczywistych strumieniach zadań, a nie w izolowanych uruchomieniach benchmarków. Rekurencja na poziomie harnessu obiecuje skumulowaną wartość, ponieważ lekcje z wcześniejszych zadań kierują późniejszymi propozycjami.

Praca przedstawia wstępne dowody takiego transferu. Biblioteka doświadczeń zbudowana na JobBench poprawiła jednostopniowe udoskonalanie w WorkBuddy-Bench o 0,6 punktu dla kodu, 0,5 dla sieci i 2,9 dla zadań biurowych.

Te zyski są mniejsze niż najsilniejsze wyniki na poziomie zadań, a jedna analiza wykorzystywała retrospektywnie doświadczenie z późniejszych zadań. Wdrożenie na żywo powinno pokazać, że użyteczne lekcje kumulują się w porządku chronologicznym bez importowania informacji z przyszłości.

Operatorzy powinni mierzyć wskaźniki regresji obok średniej wydajności. Powinni również śledzić częstotliwość interwencji, opóźnienia, zużycie modeli oraz odsetek trwałych zmian, które przechodzą ludzką kontrolę.

Trzecim sygnałem jest silniejsza warstwa weryfikacji i zarządzania. Autorzy zalecają sondy podważające wspólne założenia, powtarzane wykonania w celu oddzielenia zmian od zmienności oraz lepsze metody selekcji równoważące pokrycie z precyzją.

Poprawki w repozytorium mogą dostarczyć kolejnego wskaźnika. Tożsamości pamięci podręcznej uwzględniające treść, przypięte rewizje benchmarków i niezawodne unieważnianie ułatwiłyby odtwarzanie eksperymentów. Jasne granice bezpieczeństwa dla edytowalnych komponentów uczyniłyby wdrożenie bezpieczniejszym.

Szersza dziedzina badawcza przetestuje również alternatywne formy adaptacji harnessu. Meta-Harness wyszukuje konfiguracje przed wdrożeniem. ReasoningBank pobiera użyteczne doświadczenie rozumowania, pozostawiając harness niezmieniony. Harness Scaling rewiduje harness dla pojedynczych zadań.

Harness² łączy adaptację zadań online z trwałym mechanizmem ulepszania. To połączenie stanowi jego główne wyróżnienie, ale także koncentruje ryzyko. Zła rewizja na poziomie zadania wpływa na jeden wynik, natomiast źle zachowana lekcja może oddziaływać na późniejsze zadania.

Dla deweloperów praktyczny przekaz nie brzmi, że każdy agent powinien natychmiast przepisywać samego siebie. Chodzi o to, że prompty, pamięć, narzędzia i orkiestracja zasługują na ocenę jako połączony system.

Zespoły mogą zacząć od ograniczonych eksperymentów. Mogą wybrać reprezentatywne zadania, zachować niezmienny bazowy harness, zezwolić na rewizje wyłącznie w piaskownicy i porównywać jakość wyników z całkowitym zużyciem zasobów obliczeniowych. Każda trwała zmiana powinna pozostać możliwa do przypisania i odwracalna.

Pracownicy wiedzy powinni się tym interesować, ponieważ jakość harnessu kształtuje widoczne zachowanie agenta. Model może sprawiać wrażenie zawodnego, gdy jego instrukcje narzędziowe są słabe, pamięć zaszumiona albo przepływ pracy pomija weryfikację. Z drugiej strony lepsza procedura może poprawić wyniki bez zmiany modelu.

Otwarte wydanie czyni te hipotezy testowalnymi. Daje badaczom wspólną implementację do badania, w jaki sposób agenci diagnozują niepowodzenia, rewidują instrukcje działania i zachowują doświadczenie.

Google Harness2 ostatecznie przenosi debatę o samoulepszaniu z abstrakcyjnej inteligencji modeli do możliwych do zbadania artefaktów programistycznych. To użyteczna zmiana, ponieważ zespoły mogą przeglądać pliki, śledzić rewizje i mierzyć wykonania.

Nie rozwiązuje jednak najtrudniejszego pytania: kto weryfikuje ulepszający system, gdy nie istnieje klucz odpowiedzi? Framework zastępuje ślepą edycję ustrukturyzowanymi dowodami behawioralnymi, lecz dowody nadal mogą wprowadzać w błąd.

W ciągu kolejnych kilku miesięcy warto obserwować niezależne replikacje, wyniki między zadaniami na żywo oraz bardziej rygorystyczne kontrole dotyczące edytowalnych komponentów. Te sygnały zadecydują, czy rekurencyjne budowanie harnessów agentów stanie się niezawodną warstwą inżynieryjną, czy pozostanie obiecującym procesem badawczym.

Dla zespołów oceniających obecnie agentów AI natychmiastowe działanie jest proste. Testujcie model i jego harness oddzielnie, zapisujcie każdą zmianę i wymagajcie jasnych dowodów przed zachowaniem automatycznej rewizji. Google Harness2 zapewnia konkretny framework dla takiego eksperymentu, a raportowane przez niego niepowodzenia pokazują, dlaczego nadzór nadal ma znaczenie.