Debata OpenAI i Anthropic o harnessach: silniejsze modele, przeciwstawne zakłady inżynieryjne

Inżynierowie OpenAI ponownie otworzyli istotny spór z Anthropic: silniejsze modele AI powinny potrzebować lżejszych harnessów, jednak wymagające zadania nadal zyskują na bardziej rozbudowanym nadzorze.

Ta debata OpenAI i Anthropic o harnessach nie dotyczy wyłącznie promptów ani preferencji interfejsu. Obejmuje oprogramowanie otaczające model, w tym narzędzia, pamięć, uprawnienia, planowanie, ewaluację i zatwierdzanie przez człowieka.

OpenAI twierdzi, że nadmierne rusztowanie może utrwalać ograniczenia, których następny model już nie będzie miał. Niedawne eksperymenty Anthropic doprowadziły do bardziej warunkowego wniosku. Lepsze modele usunęły część orkiestracji, lecz planiści i niezależni ewaluatorzy pozostali wartościowi, gdy zadania zbliżały się do granic możliwości modelu.

Spór dotyczy czegoś więcej niż Codex i Claude Code. Firmy przekształcają modele ogólnego przeznaczenia w agentów, którzy edytują repozytoria, obsługują przeglądarki, analizują dokumenty i koordynują długotrwałe projekty. Każda dodatkowa kontrola może zwiększać niezawodność, ale dodaje też opóźnienia, złożoność i kolejne założenie, które może się zdezaktualizować.

Kluczowe pytanie nie brzmi więc, czy harnessy mają znaczenie. Prace inżynieryjne obu firm pokazują, że tak. Chodzi o to, czy postęp przenosi wartość do modelu, na zewnątrz — do harnessu — czy wielokrotnie między obiema warstwami.

Co faktycznie zmieniły OpenAI i Anthropic

Obie firmy traktują dziś harness agenta jako warstwę definiującą produkt, ale różnią się co do tego, ile inteligencji powinna zawierać ta warstwa.

Harness agenta to środowisko wykonawcze łączące model z narzędziami, kontekstem, pamięcią, pętlami informacji zwrotnej i kontrolami użytkownika. Model podejmuje decyzje. Harness określa, jakie informacje widzi, jakie działania może wykonać i jak wychwytywane są błędy.

Stanowisko OpenAI wyraźnie ujawniło się w sierpniowych doniesieniach o wysiłkach firmy na rzecz rozszerzenia działania agentów poza rozwój oprogramowania. Jej inżynierowie opisywali dobre projektowanie harnessów jako dostarczanie modelowi precyzyjnych narzędzi i informacji, których potrzebuje, bez otaczania go zbędnymi regułami.

Inżynier Nick Gershenson powiedział TechCrunch, że rozbudowane zestawy logiki warunkowej i narzędzi mogą przynosić krótkoterminowe korzyści. Argumentował jednak, że nowy model może w ciągu kilku miesięcy uczynić te dodatki zbędnymi. Preferuje powściągliwy interfejs, który pozwala zdolnemu modelowi samodzielnie rozwiązywać większą część problemu.

Zasada ta nawiązuje do gorzkiej lekcji, wpływowego argumentu Richa Suttona, że ogólne obliczenia przewyższają systemy budowane wokół rozległej ludzkiej wiedzy. W zastosowaniu do agentów lekcja ta sprzyja modelom o szerokich możliwościach zamiast ręcznie projektowanych przepływów pracy dla każdej przewidywanej porażki.

OpenAI nie porzuciło inżynierii harnessów. Własny opis inżynierii Codex wskazuje repozytoria, dokumentację, testowanie, pętle informacji zwrotnej i plany odczytywalne maszynowo jako niezbędną infrastrukturę. Firma podała średnio 3,5 pull requesta na inżyniera dziennie w jednym wewnętrznym projekcie.

Różnica polega na tym, gdzie OpenAI chce umieścić złożoność. Jej inżynierowie preferują czytelne środowiska i jasną informację zwrotną zamiast coraz bardziej złożonych rozgałęzień dyktujących, jak model ma rozumować.

Badania Anthropic z 24 marca przedstawiły inny test obciążeniowy. Badacz Prithvi Rajasekaran wykorzystał planistę, generator i ewaluatora do tworzenia kompletnych aplikacji podczas długich autonomicznych sesji.

Planista przekształcał krótkie żądanie w ustrukturyzowaną specyfikację. Generator wdrażał ten plan. Ewaluator obsługiwał aplikację, sprawdzał uzgodnione kryteria i przekazywał usterki do poprawy.

Początkowe porównanie Anthropic wykazało, że uruchomienie z pojedynczym agentem stworzyło aplikację, której centralna funkcja rozgrywki nie działała. Wieloagentowy harness dostarczył szerszy, funkcjonalny rezultat, choć błędy pozostały.

Nie był to dowód, że bardziej rozbudowane rozwiązanie zawsze wygrywa. Anthropic później usunęło dekompozycję na poziomie sprintu, gdy Claude Opus 4.6 spójniej radził sobie z dłuższą pracą. Jednak planista i ewaluator nadal wykrywali brakujące lub powierzchownie zrealizowane funkcje.

To wydarzenie jest więc jednocześnie zbieżnością i sporem. OpenAI i Anthropic upraszczają harnessy, gdy modele przejmują dawne obowiązki. Różnią się w kwestii tego, jak szybko programiści powinni zaufać temu transferowi.

Dlaczego debata OpenAI i Anthropic o harnessach ma teraz znaczenie

Presja wynika z przechodzenia agentów poza ograniczone zadania programistyczne do pracy, w której sukces trudniej zdefiniować, a porażkę trudniej odwrócić.

Programowanie zapewniło agentom pierwsze sprzyjające środowisko. Repozytoria zawierają uporządkowane pliki, kompilatory ujawniają błędy, a testy często generują jasne sygnały zaliczenia lub niepowodzenia. Harness może przekształcić te sygnały w kolejną próbę modelu.

Ogólna praca oparta na wiedzy oferuje mniej niezawodnych kontroli. Notatka strategiczna może wydawać się spójna, opierając się na słabych założeniach. Arkusz kalkulacyjny może poprawnie obliczać dane, jednocześnie odpowiadając na niewłaściwe pytanie biznesowe. Agent może ukończyć dopracowaną prezentację, nie zauważając, że jej dowody są nieaktualne.

OpenAI rozszerza swoje podejście do agentów na te mniej ustrukturyzowane środowiska. To wywiera na firmę presję, aby zachować prostotę kojarzoną z silniejszymi modelami, jednocześnie dodając kontrole wymagane przez zwykłych użytkowników.

Anthropic mierzy się z przeciwną presją. Claude Code zbudował znaczną część swojej atrakcyjności wokół widocznego postępu, częstej interakcji i udziału użytkownika. Takie podejście może wydawać się bezpieczniejsze, ale powtarzające się pytania i zatwierdzenia zwiększają obciążenie operatora.

Rywalizacja odzwierciedla dwa instynkty produktowe. OpenAI często dążyło do doświadczenia polegającego na powierzeniu celu i otrzymaniu gotowego rezultatu. Anthropic na ogół ujawniało więcej pośredniego procesu rozumowania poprzez plany, alternatywy i prośby o uprawnienia.

Żaden z tych instynktów nie jest uniwersalnie lepszy. Autonomia staje się atrakcyjna, gdy cel jest jasny, a weryfikacja tania. Współpraca staje się wartościowa, gdy preferencje nie zostały wyrażone albo konsekwencje trudno zmierzyć.

Wyjaśnia to, dlaczego interfejs może zmieniać pozorną jakość identycznego modelu. Harness kontroluje wybór kontekstu, opisy narzędzi, zachowanie przy ponownych próbach, dostęp do plików i moment interwencji użytkownika. Te decyzje kształtują każde działanie modelu.

Niezależni twórcy frameworków zaobserwowali tę samą zależność. LangChain podał, że profile harnessów specyficzne dla modeli przyniosły poprawę o 10–20 punktów w podzbiorze tau2-bench w porównaniu z konfiguracją domyślną. Ich profile harnessów dostosowują prompty, narzędzia i middleware do różnych zachowań modeli.

Wynik ten podważa prostą wersję tezy OpenAI. Gdyby harness był wyłącznie tymczasową protezą, jego zmiana nie powinna tworzyć dużych różnic w wydajności, gdy podstawowy model pozostaje niezmieniony.

Jednocześnie wspiera krytykę OpenAI dotyczącą niepotrzebnej abstrakcji. LangChain nie znalazł jednej coraz bardziej skomplikowanej architektury, która poprawiałaby każdy model. Stwierdził, że różne modele reagują na różne konfiguracje.

Praktyczna presja spada na zespoły produktowe. Muszą zdecydować, czy ściśle optymalizować pod jednego dostawcę, czy utrzymywać przenośną warstwę dla kilku modeli.

Ścisła optymalizacja może zapewnić lepsze natychmiastowe wyniki. Może też tworzyć zależność od narzędzi, promptów i zachowania kontekstu specyficznych dla dostawcy. Przenośność ogranicza tę zależność, ale ogólny harness może pozostawić część możliwości modelu niewykorzystaną.

Wybory te stają się bardziej znaczące, gdy agenci otrzymują szersze uprawnienia. Asystent programistyczny sugerujący łatkę ma ograniczoną rolę. Agent, który czyta komunikację, edytuje współdzielone dokumenty i uruchamia systemy biznesowe, przekracza kilka granic zaufania.

Zespoły oceniające te produkty powinny zatem patrzeć dalej niż na benchmarki modeli. Potrzebują dowodów dotyczących pełnego połączenia modelu i harnessu w realistycznych warunkach uprawnień, danych i awarii.

OpenAI chce, by model prowadził

Argument OpenAI za lżejszym harnessiem głosi, że programiści powinni jasno udostępniać środowisko, a następnie pozwolić modelowi zapewniać większość zachowań adaptacyjnych.

Stanowisko to nie oznacza usuwania testów, uprawnień ani zarządzania kontekstem. Oznacza sprzeciw wobec ręcznie budowanych procedur rozumowania, które kompensują ograniczenia mające wkrótce zniknąć.

Doświadczenia OpenAI z pierwszą aplikacją internetową Codex pomagają wyjaśnić to przekonanie. Firma początkowo postawiła na model wykonujący zadania przy minimalnym udziale użytkownika. Bardziej interaktywne podejście Anthropic w Claude Code okazało się lepiej dopasowane do tego, co modele mogły wówczas niezawodnie robić.

OpenAI później dodało użytkownikom więcej możliwości kierowania Codex. Jeden z inżynierów przyznał, że wcześniejszy produkt wyprzedzał możliwości tego, co jego model i harness mogły obsłużyć.

Ta historia ma znaczenie, ponieważ pokazuje zagrożenia po obu stronach. Harness może zawierać zbyt wiele sztywnej logiki. Może też zakładać większe kompetencje modelu, niż faktycznie otrzymują użytkownicy.

Obecne podejście OpenAI próbuje uniknąć kolejnego niedopasowania dzięki czytelniejszym środowiskom i silniejszej informacji zwrotnej. Wewnętrzny opis inżynieryjny firmy podkreśla ustrukturyzowaną dokumentację, zasady repozytorium, plany i zautomatyzowane kontrole.

Elementy te są lżejsze niż przepływ pracy nakazujący każdy krok rozumowania. Nadal jednak stanowią rozbudowaną inżynierię. Harness deleguje osąd, jednocześnie ułatwiając kontrolę sukcesu.

Podejście to pasuje również do ambicji produktowych OpenAI. Agent ogólnego zastosowania w miejscu pracy nie może polegać na tym, że projektanci przewidzą każdą sekwencję, o którą może poprosić użytkownik. Przestrzeń możliwych zadań jest zbyt szeroka.

System prowadzony przez model może wybierać narzędzia i rewidować plany wraz ze zmianą warunków. Ta elastyczność jest atrakcyjna, gdy użytkownicy przechodzą od badań do arkuszy kalkulacyjnych, wiadomości, kodu i prezentacji w ramach jednego zadania.

Minimalny harness przenosi jednak więcej odpowiedzialności na model. Model musi zauważać niejednoznaczność, prosić o brakujące informacje i rozpoznawać, kiedy działanie zasługuje na potwierdzenie.

Takie zachowania nie są gwarantowane samą ogólną zdolnością. Model może lepiej wykonywać instrukcje, nie stając się równie dobry w wykrywaniu wadliwego celu.

Ryzyko to potęguje doświadczenie użytkownika. Ethan Mollick, profesor Wharton badający AI w miejscu pracy, porównywał systemy próbujące natychmiast ukończyć pracę z tymi, które pokazują porównania i proszą o informację zwrotną.

Bardziej autonomiczny projekt zmniejsza tarcie, gdy agent poprawnie interpretuje cel. Gdy tak nie jest, użytkownicy mogą odkryć błąd dopiero po długim łańcuchu spójnej, lecz źle ukierunkowanej pracy.

To sprawia, że jakość kontekstu staje się kluczowa. Lekki harness działa najlepiej, gdy dostarcza zwięzłych, istotnych i aktualnych informacji. Duży, niefiltrowany kontekst może ukryć priorytety, nawet gdy model obsługuje długie okno kontekstu.

Dla pracowników wiedzy organizowanie tych dowodów pozostaje odrębnym problemem inżynieryjnym. Przeszukiwalna baza wiedzy może zmniejszyć szum wyszukiwania, zanim agent zacznie działać.

Teza OpenAI jest najsilniejsza w przypadku zadań z gęstą informacją zwrotną generowaną przez maszyny. Kompilatory, zestawy testów, lintery i kontrole w przeglądarce pozwalają agentowi oceniać postęp bez ciągłego osądu człowieka.

Staje się słabszy, gdy ukończenie zależy od gustu, historii organizacji lub nieudokumentowanych oczekiwań. Model nie może wywnioskować dowodów, które nigdy nie trafiają do jego kontekstu.

OpenAI stawia więc wykalkulowany zakład. W miarę poprawy modeli będą one samodzielnie obsługiwać więcej planowania i naprawiania błędów. Projektanci harnessów powinni zachować uniwersalność zamiast utrwalać w jutrzejszym produkcie ograniczenia modeli z wczoraj.

Anthropic Twierdzi, że Trudniejsza Praca Wciąż Wymaga Większej Struktury

Dowody Anthropic dotyczące bardziej rozbudowanych harnessów pokazują, że silniejsze modele nie eliminują orkiestracji; przesuwają jedynie granicę jej użyteczności w stronę trudniejszych zadań.

Długotrwały harness Anthropic powstał w odpowiedzi na dwie powtarzające się słabości. Modele traciły spójność podczas dłuższej pracy i zbyt łaskawie oceniały własne wyniki.

Pierwszy problem dotyczył kontekstu. Długie zadania gromadzą decyzje, wyniki narzędzi, błędy i częściowe implementacje. Nawet gdy okno kontekstowe może pomieścić ten materiał, jego organizacja wpływa na to, co model zauważa.

Anthropic stosował resetowanie kontekstu z uporządkowanymi plikami przekazania. Reset zapewniał nowej sesji agenta czysty stan roboczy, zachowując kluczowy postęp i kolejne kroki.

Drugi problem dotyczył samooceny. Ten sam model, który tworzył aplikację, często akceptował słabe rezultaty, szczególnie gdy jakość zależała od oceny projektowej.

Anthropic oddzielił tworzenie od przeglądu. Jego ewaluator korzystał z jawnych kryteriów i automatyzacji przeglądarki, aby testować funkcjonalność. Generator otrzymywał konkretne ustalenia i próbował wprowadzać poprawki.

Pierwszy pełny harness rozwinął jednoczęściowe polecenie stworzenia gry do 16 funkcji w dziesięciu sprintach. Ewaluator stosował szczegółowe kontrakty dla każdego sprintu, w tym 27 kryteriów dla jednego etapu edytora poziomów.

Anthropic podał, że wynik pracy wielu agentów oferował działającą podstawową funkcjonalność, której brakowało w próbie z jednym agentem. Wymagał jednak znacznie więcej czasu działania, orkiestracji i użycia modeli.

Ten kompromis sprawia, że eksperyment jest bardziej użyteczny niż proste zwycięstwo w benchmarku. Pokazuje, co może dać dodatkowa struktura, jednocześnie ujawniając, dlaczego zespoły nie mogą bezkrytycznie dodawać ewaluatorów.

Anthropic następnie powtórzył proces z silniejszym modelem. Opus 4.6 utrzymał główną część budowy przez ponad dwie godziny bez wcześniejszego podziału na sprinty.

Potwierdziło to główną obserwację OpenAI. Zdolność, którą wcześniej zapewniał harness, została przeniesiona do modelu, przez co część rusztowania stała się zbędna.

Ewaluator nadal wykrył istotne braki. Zidentyfikował kluczowe funkcje audio, które istniały jedynie jako powierzchowne elementy interfejsu lub placeholdery. Generator następnie usunął kilka z tych pominięć.

Wniosek Anthropic nie brzmiał, że każde zadanie potrzebuje trzech agentów. Ewaluator zapewniał największą wartość, gdy praca znajdowała się blisko granicy tego, co generator potrafił niezawodnie ukończyć.

Ta granica jest dynamiczna. Wydanie nowego modelu przesuwa ją na zewnątrz. Bardziej wymagające zadanie ponownie przesuwa ją do wewnątrz.

Prowadzi to do innej interpretacji gorzkiej lekcji. Modele ogólnego przeznaczenia zastępują ręcznie tworzone rozwiązania dla problemów z wczoraj, ale umożliwiają też realizację celów, które wcześniej były niepraktyczne.

Gdy zespoły podejmują się takich celów, pojawiają się nowe tryby awarii. Harness nie znika. Podąża za granicą możliwości.

Stanowisko Anthropic uznaje również, że ewaluacja jest częścią produktu. System generujący więcej wyników nie staje się automatycznie bardziej użyteczny. Ktoś lub coś musi ustalić, czy te wyniki spełniają faktyczne wymagania.

Dla programistów dużą część tej oceny mogą zapewnić zestawy testów. W przypadku projektowania, badań i pracy zarządczej kryteria często trzeba określić przed działaniem agenta.

Architektura planista-ewaluator czyni te oczekiwania jawnymi. Może też wzmacniać złe kryteria. Ewaluator będzie egzekwował otrzymany mierzalny wskaźnik zastępczy, nawet gdy nie odzwierciedla on tego, co cenią użytkownicy.

Bardziej rozbudowane harnessy tworzą zatem własny problem zarządzania. Więcej komponentów oznacza więcej promptów, uprawnień, logów, przekazań i ścieżek awarii do utrzymania.

Dowody Anthropic przemawiają za selektywną strukturą, a nie trwałą złożonością. Usuń to, z czym silniejszy model potrafi już sobie poradzić, a następnie ponownie zainwestuj wysiłek inżynieryjny tam, gdzie weryfikacja nadal przynosi znaczącą korzyść.

Test Modelu Kontra Harnessu Wciąż Pozostaje Nierozstrzygnięty

Żadna ze stron nie wykazała, że preferowana przez nią architektura wygrywa we wszystkich modelach, zadaniach, budżetach i poziomach ryzyka.

Debata OpenAI i Anthropic dotycząca harnessów w dużej mierze opiera się na wewnętrznych eksperymentach i obserwacjach produktowych. Źródła te ujawniają wybory inżynieryjne, ale nie dostarczają kontrolowanego porównania między Codex a Claude Code.

Relacja OpenAI odzwierciedla jego własne modele, repozytoria i praktyki zespołowe. Przykłady Anthropic wykorzystują modele Claude w wybranych zadaniach budowania aplikacji. Każda firma wybrała środowisko i kryteria sukcesu.

Nawet szczegółowe porównanie Anthropic zmieniło jednocześnie kilka zmiennych. Pełny system dodał planowanie, ewaluację, dekompozycję, dłuższe wykonanie i więcej wywołań modelu. Wynik nie pozwala wyizolować, który komponent przyniósł każdą poprawę.

Firma później zastosowała usuwanie komponentów, aby zbadać to pytanie. Jej wnioski nadal opierały się jednak na niewielkim zbiorze demonstracji, a nie na szerokiej niezależnej replikacji.

Benchmarki stron trzecich pomagają, ale wprowadzają dodatkowe komplikacje. Harness może działać dobrze, ponieważ benchmark przypomina preferowany przez niego przepływ pracy. Inna konfiguracja może zamiast tego optymalizować wykorzystanie tokenów, wskaźnik zaliczeń, opóźnienie lub możliwość odzyskania sprawności.

Ten sam wynik może też ukrywać różne ryzyka operacyjne. Jeden agent może wyraźnie ponieść porażkę i się zatrzymać. Inny może stworzyć wiarygodny, lecz błędny rezultat, który przejdzie automatyczną kontrolę.

Badania nad produkcyjnymi systemami programistycznymi coraz częściej traktują model i harness jako połączoną całość. Niedawne badanie kodu źródłowego przeanalizowało 11 harnessów programistycznych, w tym Claude Code, Codex CLI, Gemini CLI, Pi, OpenCode i OpenHands.

Ta różnorodność osłabia ideę jednego optymalnego harnessu. Systemy te różnią się zarządzaniem kontekstem, punktami rozszerzeń, planowaniem, izolacją i wykonywaniem narzędzi, ponieważ ich projektanci kierują je do różnych użytkowników.

Przenośność stanowi kolejną nierozstrzygniętą kwestię. Doniesienia przywoływały porównanie, w którym otwartoźródłowy harness Pi przewyższał Codex, używając tego samego modelu OpenAI.

Taki wynik sugeruje, że dostawca modelu nie tworzy automatycznie najlepszego środowiska dla każdego zadania. Nie dowodzi, że Pi wygrywa szeroko, ponieważ konfiguracja benchmarku i ustawienia pozostają decydujące.

Otwarte harnessy mogą ujawniać ślady działania, wykorzystanie tokenów i szczegóły konfiguracji, które produkty własnościowe ukrywają. Ta przejrzystość pomaga zespołom diagnozować awarie i zmieniać dostawców.

Harnessy kontrolowane przez dostawców otrzymują wcześniejszy dostęp do funkcji specyficznych dla modelu. Ich twórcy mogą dostrajać systemy wokół nieudokumentowanego zachowania i wdrażać skoordynowane aktualizacje.

Znaczenie mają też zachęty biznesowe. Zarówno OpenAI, jak i Anthropic odnoszą korzyści, gdy klienci używają ich modeli za pośrednictwem własnych interfejsów. Posiadanie harnessu wzmacnia dystrybucję i może zwiększać koszty zmiany dostawcy poprzez zapisany kontekst, integracje i wyuczone przepływy pracy.

Nie czyni to ich twierdzeń inżynieryjnych fałszywymi. Oznacza to, że klienci powinni oddzielać dowody techniczne od strategii platformowej.

Kolejną niewiadomą jest koszt, nawet bez porównywania publicznych cen. Planowanie i ewaluacja przez wielu agentów zużywają dodatkowe tokeny i czas. Wyższy wskaźnik ukończenia może uzasadniać ten narzut, gdy awaria jest kosztowna.

Odwrotnie jest w przypadku rutynowej, odwracalnej pracy. Uruchamianie ewaluatora dla każdej drobnej edycji może zużywać więcej zasobów niż poprawienie okazjonalnego błędu.

Bezpieczeństwo dodatkowo komplikuje tezę o lżejszym harnessie. Lepsze modele mogą wykonywać dłuższe sekwencje działań i skuteczniej korzystać z narzędzi. Te ulepszenia zwiększają konsekwencje źle zrozumianych instrukcji.

Granice uprawnień, logi audytowe, sandboxing i potwierdzenia to funkcje harnessu. Silniejsze możliwości mogą zwiększać ich znaczenie, nawet jeśli zmniejszają potrzebę rusztowań planistycznych.

Zespoły powinny więc odrzucać jednowymiarowe testy. Użyteczna ocena musi mierzyć ukończenie zadań, ukryte wady, czas przeglądu przez człowieka, zużycie zasobów oraz odzyskiwanie sprawności po awarii.

Powinna także porównywać konfiguracje przy tym samym modelu. W przeciwnym razie zespół może kupić bardziej zaawansowany model, choć problem rozwiązałaby zmiana kontekstu lub narzędzia.

Obecne dowody wspierają warunkową zasadę. Używaj najlżejszego harnessu, który spełnia zdefiniowany próg niezawodności, a następnie dodawaj strukturę tam, gdzie uzasadniają to zaobserwowane awarie.

Ta zasada brzmi jak kompromis, ale tworzy wymagającą pracę operacyjną. Zespoły potrzebują powtarzalnych ocen, inspekcji śladów działania i wersjonowanych konfiguracji, aby wiedzieć, kiedy komponent nadal jest użyteczny.

Bez tych dowodów „lżejszy” staje się wiarą w następny model. „Cięższy” staje się nagromadzoną folklorystyczną wiedzą zakodowaną w promptach i gałęziach przepływu pracy.

Trzy Sygnały Zdecydują, Które Podejście Wygra

O kolejnej fazie zdecydują dowody porównawcze, a nie preferowany przez którąkolwiek firmę opis jej architektury.

Pierwszym sygnałem jest wydajność przy zamianie harnessów. Badacze i twórcy frameworków potrzebują kontrolowanych testów, które utrzymują stałe model, zadanie, dostęp do narzędzi i limity zasobów.

Jeśli harnessy stron trzecich będą wielokrotnie przewyższać interfejsy dostawców przy użyciu tego samego modelu, wartość przesuwa się w stronę orkiestracji. Taki wynik osłabiłby przekonanie, że postęp modeli naturalnie absorbuje większość zróżnicowania produktów.

Jeśli różnice wydajności zmniejszą się między dobrze zaprojektowanymi harnessami, teza OpenAI zyska poparcie. Sugerowałoby to, że silniejsze modele potrzebują mniej wyspecjalizowanych interwencji i mogą działać w prostszych, ustandaryzowanych środowiskach.

Drugim sygnałem będzie to, jak Anthropic i OpenAI upraszczają własne systemy po każdym wydaniu modelu. Anthropic pokazał już jedną wersję tego testu, usuwając dekompozycję na sprinty z przepływów pracy Opus 4.6.

Obserwuj, które komponenty znikną jako następne. Planowanie, resetowanie kontekstu, niezależna ewaluacja i częste zatwierdzenia reprezentują różne założenia dotyczące ograniczeń modeli.

Usunięcie komponentu bez obniżenia jakości zadania wzmacnia argument za lżejszym harnessem. Przeniesienie tego komponentu do trudniejszej klasy pracy wspiera interpretację Anthropic dotyczącą przesuwającej się granicy.

Trzecim sygnałem jest adopcja poza inżynierią oprogramowania. Agenci programistyczni korzystają z repozytoriów, testów i zdigitalizowanej informacji zwrotnej. Praca z wiedzą zawiera słabsze sygnały i więcej ukrytych preferencji.

Agent kierowany przez model będzie wyglądał przekonująco, jeśli ludzie zaakceptują ukończoną pracę bez rozległych poprawek. Współpracujący harness będzie wyglądał na silniejszy, jeśli użytkownicy konsekwentnie będą potrzebować podglądów, porównań i punktów kontrolnych zatwierdzenia.

Najbardziej użyteczną metryką adopcji nie będzie liczba rozpoczętych zadań. Będzie nią odsetek zadań ukończonych poprawnie po uwzględnieniu przeglądu przez człowieka i przeróbek.

Programiści powinni także śledzić dotkliwość awarii. Harness, który kończy mniej zadań, ale bezpiecznie się zatrzymuje, może być lepszy od takiego, który kończy ich więcej, popełniając trudne do wykrycia błędy.

Nabywcy korporacyjni powinni wymagać ocen wykorzystujących ich dokumenty, uprawnienia i przepływy pracy. Publiczne rankingi nie mogą reprezentować specyficznych dla organizacji definicji poprawności.

Pracownicy wiedzy mogą przeprowadzić prostszą wersję tego procesu. Zacznij od znanego, odwracalnego zadania i porównaj wynik agenta z ustalonym ludzkim punktem odniesienia.

Zapisuj, gdzie modelowi brakowało kontekstu, gdzie wybrał niewłaściwe narzędzie lub potrzebował subiektywnych wskazówek. Te obserwacje pokażą, czy kolejna interwencja powinna znaleźć się w instrukcjach, wyszukiwaniu wiedzy, zasadach zatwierdzania czy niezależnym przeglądzie.

Debata o architekturze agentów OpenAI i Anthropic nie zakończy się tym, że jedna firma wybierze cienką warstwę, a druga zbuduje grubą. Obie już dodają i usuwają komponenty wraz ze zmianami modeli i zadań.

Trwałą przewagę zyskają zespoły, które potrafią szybko mierzyć te zmiany. Będą wiedzieć, które ograniczenia nadal zapobiegają awariom, a które jedynie utrwalają założenia pochodzące ze starszego modelu.

Dla każdego, kto wdraża agentów, najbliższe działanie jest proste: testuj model i architekturę razem, analizuj rzeczywiste ślady wykonania i zdefiniuj sukces, zanim przyznasz szerszą autonomię. Silniejsze modele zmieniają granicę inżynieryjną, ale nie eliminują potrzeby jej zlokalizowania.