Google Research prezentuje Harness², metodę mającą na celu poprawę działania agenta AI bez ingerencji w jego model, poprzez dostrojenie otaczającego go systemu. Ten system, zwany „uprzężą » (harness), obejmuje instrukcje, narzędzia, pamięć i pętlę kontrolną, które zarządzają modelem. Podejście ma na celu adaptację tej uprzęży w czasie rzeczywistym, także dla zadań nieprzewidzianych przez jej twórców.
Punkt wyjścia jest prosty: żadna uprząż nie jest najlepsza we wszystkim. Według przedstawionych danych, Claude Code osiąga lepsze wyniki w kodzie i arkuszach kalkulacyjnych, podczas gdy Codex prowadzi w zadaniach webowych. Sztywna uprząż pozostawia więc niewykorzystany potencjał.
Dlaczego automatyczne przepisywanie instrukcji zawodzi
Pozwolenie agentowi na przepisanie własnego promptu systemowego, czyli początkowych instrukcji, które otrzymuje, wydaje się obiecujące. W praktyce może to pogorszyć wyniki. Te instrukcje są odczytywane przez całe zadanie, a im bardziej się wydłużają, tym więcej zużywają tokenów, jednostek tekstu przetwarzanych przez model. Gdy ten budżet zostanie wyczerpany, agent może ponieść porażkę przed ukończeniem zadania.
Harness² nie działa więc na tekście instrukcji. Modyfikuje osiem komponentów pogrupowanych w cztery rodziny: kontekst, interfejs narzędzi, delegację do podagentów oraz „middleware », czyli rozszerzenia działające w pętli korzystania z narzędzi. Zasada zapisana w prompcie pozostaje sugestią, podczas gdy zasada umieszczona w pętli kontrolnej jest egzekwowana. Dwie poprawki ilustrują tę różnicę: mechanizm monitorowania, który zmusza agenta do pisania przed wyczerpaniem budżetu, oraz skrypt blokujący zakończenie zadania dopóki arkusz kalkulacyjny zawiera brakujące formuły.
Proponuj, testuj, komponuj
Proces przebiega w trzech etapach. Agent wykonuje zadanie raz, następnie dwaj edytorzy analizują dziennik wykonania: jeden bada mechanikę przepływu pracy, drugi proponuje reguły biznesowe. Zmodyfikowana uprząż jest potem ponownie uruchamiana na tym samym zadaniu, a obie próby są porównywane. Modyfikacja jest zachowywana tylko wtedy, gdy naprawia konkretną i obserwowalną usterkę. Według badań ten etap testowania jest kluczowy: bez niego wydajność spadłaby o około 10%.
Ogłoszone wyniki i ograniczenia
Testy obejmują trzy zestawy benchmarków zawodowych, w czterech konfiguracjach modelu i uprzęży, z GLM-5 i Gemini 3.5 Flash. Zgłaszane zyski sięgają do 11,5 punktów na WorkBuddy-Bench, 4,5 punktu na JobBench i 11,8 punktu procentowego na LAB, w wskaźniku częściowego sukcesu. Uprząż zoptymalizowana z potężnym modelem poprawiła też wyniki mniejszego modelu o 17 punktów. Odwrotnie, ReasoningBank, baza pamięci referencyjnej, uzyskała o 6,6 punktu mniej niż podstawowa uprząż w zadaniach programistycznych.
Autor artykułu źródłowego zainstalował projekt, który działa na Linuxie z Pythonem 3.12, i uruchomił jego demonstrację, która zakończyła się bez porażki na dwóch zadaniach księgowych. Podkreśla jednak, że demonstracja to nie metoda: większość komponentów pozostaje pusta lub w stanie prostych placeholderów, a część opisana w artykule pojawia się dopiero po podłączeniu modelu.
