Microsoft Otwiera Orchard, ale wielokrotne wykorzystanie treningu agentów wciąż ma problem ze skalą

Microsoft Research udostępnił Orchard wraz z trzema recepturami treningu agentów, podważając założenie, że każdy projekt agenta potrzebuje własnej, wyspecjalizowanej infrastruktury. Framework obejmuje inżynierię oprogramowania, interakcje z przeglądarką i zadania osobistego asystenta. Jego główna obietnica dotyczy ponownego wykorzystania: jedna warstwa środowiska może obsługiwać zbieranie danych, trening nadzorowany, uczenie ze wzmocnieniem i ewaluację.

To istotne, ponieważ otwarte badania nad agentami mają problem infrastrukturalny. Badacze mogą analizować wiele bibliotek orkiestracyjnych, ale odtworzenie systemów treningowych stojących za zaawansowanymi agentami pozostaje trudne. Piaskownice, interfejsy narzędziowe, funkcje nagrody i długotrwałe trajektorie często stają się ściśle powiązane z jednym zadaniem.

Microsoft Orchard próbuje rozdzielić te elementy. Zamiast przedstawiać kolejny framework aplikacyjny, koncentruje się na środowisku, w którym agenci działają i uczą się. To rozróżnienie zbliża go bardziej do eksperymentalnej platformy treningowej niż do Microsoft Agent Framework czy AutoGen, które przede wszystkim pomagają deweloperom tworzyć i obsługiwać aplikacje agentowe.

Przedstawione wyniki są znaczące. Pozostają jednak wynikami badawczymi zespołu projektu, a nie niezależnymi potwierdzeniami wydajności lub dostępności. Wydanie wiąże się też z praktycznym napięciem: oprogramowanie wielokrotnego użytku może ograniczać powielanie prac inżynieryjnych, podczas gdy trening agentów na dużą skalę nadal wymaga modeli, mocy obliczeniowej, środowisk zadań i wiedzy operacyjnej.

Orchard Przekształca Środowisko Agenta We Wspólną Infrastrukturę

Istotną zmianą nie jest kolejny interfejs agenta. Jest nią warstwa środowiska wielokrotnego użytku, która towarzyszy agentowi przez cały cykl treningowy.

Projekt koncentruje się na Orchard Env, usłudze natywnej dla Kubernetes służącej do zarządzania izolowanymi środowiskami. Piaskownica to kontrolowana przestrzeń robocza, w której agent może wykonywać polecenia, modyfikować pliki, przeglądać aplikacje i otrzymywać obserwacje bez nieograniczonego dostępu do systemu hosta.

Według frameworka modelowania agentowego projektu usługa udostępnia wspólne operacje przez interfejs REST. Operacje te obejmują tworzenie i usuwanie piaskownic, wykonywanie poleceń, odczytywanie lub zapisywanie plików oraz stosowanie zasad sieciowych.

Środowisko pozostaje oddzielone od uprzęży agenta, czyli oprogramowania tłumaczącego wyniki modelu na działania narzędziowe. Pozostaje również oddzielone od systemu inferencji i algorytmu treningowego. Badacze mogą więc zmieniać model lub uprząż bez przebudowywania każdego komponentu zarządzania środowiskiem.

To rozdzielenie odpowiada na powracające źródło trudności. Agent programistyczny może potrzebować migawki repozytorium, narzędzi do budowania i ukrytych testów. Agent przeglądarkowy potrzebuje interfejsu wizualnego oraz stanu strony internetowej. Osobisty asystent potrzebuje interfejsów API narzędzi i weryfikacji specyficznej dla zadania.

Na poziomie aplikacji te konfiguracje wyglądają inaczej. U ich podstaw każda wymaga izolowanego środowiska, menedżera cyklu życia, kanału obserwacji i metody oceniania wyników. Framework próbuje wyraźnie określić te wspólne wymagania.

Microsoft podaje, że w testach usługa osiągała średnio 0,28 sekundy na wykonanie polecenia. Towarzysząca publikacja opisuje również test obciążeniowy obejmujący 1 000 piaskownic ze 100-procentowym wskaźnikiem powodzenia. Pomiary te opisują konfigurację badaczy i nie powinny być traktowane jako uniwersalne gwarancje produkcyjne.

Architektura wykorzystuje dynamiczne wstrzykiwanie agentów podczas działania, dzięki czemu obrazy kontenerów specyficzne dla zadań mogą pozostać oddzielone od usługi kontrolnej. Kieruje również wykonanie i operacje na plikach bezpośrednio do adresów podów piaskownic. Autorzy publikacji twierdzą, że pozwala to uniknąć części narzutu związanego z kanałami wykonawczymi Kubernetes.

Inne szczegóły operacyjne pokazują, jak rozbudowanej infrastruktury wymaga trening agentów. System obejmuje asynchroniczne tworzenie piaskownic, monitorowanie gotowości, czyszczenie oparte na sygnałach heartbeat, izolację sieciową, ponawianie prób i eskalację zasobów. Nie są to efektowne funkcje, ale awaria którejkolwiek z nich może unieważnić lub zatrzymać przebieg treningu.

Ta rozpiętość wyjaśnia wartość badawczą projektu. Zespoły badające różne zadania agentowe mogą ponownie wykorzystywać tę samą warstwę kontrolną, zachowując własne modele, narzędzia i systemy nagród. Teoretycznie eksperymenty stają się łatwiejsze do porównania, ponieważ między nimi zmienia się mniej zmiennych infrastrukturalnych.

Framework nie eliminuje potrzeby wyspecjalizowanego projektowania zadań. Badacze nadal muszą tworzyć prawidłowe środowiska, definiować dozwolone działania, zabezpieczać piaskownice i opracowywać znaczące ewaluatory. Ogranicza powtarzalne prace inżynieryjne wokół tych decyzji, zamiast sprawiać, że same decyzje znikają.

Główna Presja Dotyczy Stosów Treningowych Specyficznych Dla Zadań

Orchard podważa założenie, że agenci programistyczni, przeglądarkowi i asystenccy wymagają oddzielnych, kompleksowych systemów treningowych.

Większość publicznych frameworków agentowych koncentruje się na orkiestracji. Pomagają one modelom wywoływać narzędzia, wymieniać wiadomości, realizować przepływy pracy lub koordynować wielu agentów. Te możliwości są istotne dla aplikacji, ale nie tworzą automatycznie danych i sprzężenia zwrotnego potrzebnych do ulepszania modelu.

Trening dodaje kolejną warstwę. Agent musi wykonywać zadania w kontrolowanym środowisku, generować wieloetapowe trajektorie, otrzymywać wiarygodne nagrody i przekształcać te interakcje w aktualizacje modelu. Każdy etap może zależeć od innego oprogramowania i infrastruktury.

Trajektoria to pełna sekwencja rozumowania, działań, odpowiedzi narzędziowych i stanów środowiska wygenerowana podczas zadania. Te zapisy mogą stać się przykładami treningowymi, lecz tylko wtedy, gdy system zachowuje ich strukturę i określa, które zachowanie pomogło.

To wyzwanie staje się bardziej wyraźne w zadaniach o długim horyzoncie. Agent programistyczny może przeanalizować kilka plików, spróbować wprowadzić poprawkę, uruchomić testy, zmienić podejście i mimo to ostatecznie ponieść porażkę. Prosta etykieta sukcesu lub porażki nie wyjaśnia, które decyzje pośrednie były użyteczne.

Odpowiedzią projektu jest ponowne wykorzystywanie zarówno środowisk, jak i trajektorii na kolejnych etapach pipeline'u. Ta sama usługa środowiskowa obsługuje zbieranie danych przez model nauczyciela, dostrajanie nadzorowane, przebiegi uczenia ze wzmocnieniem oraz końcową ewaluację. Badacze nie potrzebują oddzielnych systemów piaskownic dla każdego etapu.

Ten projekt kontrastuje z orkiestracją zorientowaną na produkcję. Oddzielny framework aplikacji agentowych Microsoftu jest przeznaczony do tworzenia i wdrażania agentów w Pythonie i .NET. AutoGen również ustanowił wspólne wzorce dla rozmów wieloagentowych i korzystania z narzędzi.

Nowy stos badawczy odpowiada na inne pytanie: jak zespoły mogą trenować bazową politykę decydującą o tym, co agent powinien zrobić dalej? Ta różnica wyklucza bezpośrednie porównanie produktów. Framework aplikacyjny i środowisko treningowe mogą się wzajemnie uzupełniać.

Presja dotyczy natomiast zamkniętych, pionowo zintegrowanych pipeline'ów badawczych. Jeśli ta sama otwarta warstwa środowiska działa w wielu dziedzinach, zespoły mają mniej powodów, by akceptować nierozdzielny pakiet modelu, uprzęży, piaskownicy i ewaluatora.

Mniejsze grupy badawcze odnoszą teoretycznie największe korzyści. Mogą zacząć od współdzielonych prymitywów środowiskowych i opublikowanych receptur, zamiast tworzyć całą rozproszoną usługę piaskownic. Mogą też testować mniejsze modele na zadaniach wcześniej kojarzonych ze znacznie większymi systemami.

Mimo to „mniejsze” pozostaje pojęciem względnym. Uruchamianie piaskownic Kubernetes, serwerów inferencji, modeli nauczycieli i zadań uczenia ze wzmocnieniem nadal wymaga zaawansowanych kompetencji technicznych. Wydanie obniża jedną kategorię złożoności, nie zmieniając treningu agentów w zwykły proces na laptopie.

Organizacje potrzebują również zdyscyplinowanego zarządzania wiedzą wokół tych eksperymentów. Trajektorie, błędy ewaluacji, zmiany konfiguracji i definicje zadań szybko stają się trudne do przeszukiwania. Techniczna baza wiedzy może zachować uzasadnienie wyników, a nie tylko końcowy wynik benchmarku.

Strategiczna zmiana dotyczy więc modułowości. Badacze mogą zachować preferowany model i interfejs agenta, zastępując własny backend środowiska. Jeśli ten wzorzec zyska popularność, ponowne wykorzystanie infrastruktury może stać się podstawowym oczekiwaniem w otwartych badaniach nad agentami.

Microsoft Orchard Uczy Się Z Użytecznych Elementów Porażki

Najsilniejsza idea frameworka polega na tym, że nieudany przebieg agenta nadal może zawierać wartościowe dowody treningowe.

Receptura inżynierii oprogramowania, nazwana Orchard-SWE, zaczyna od około 107 000 trajektorii wyodrębnionych z MiniMax-M2.5 i Qwen3.5-397B. Microsoft podaje, że zbiór obejmuje 2 788 repozytoriów GitHub.

Projektowy zbiór danych trajektorii opisuje 107 185 rekordów inżynierii oprogramowania. Wymienia 74 649 rozwiązanych trajektorii i 32 536 nierozwiązanych trajektorii. Rozwiązany rekord oznacza, że końcowa poprawka przeszła ukryty zestaw testów danego zadania.

Tradycyjne dostrajanie nadzorowane faworyzuje udane przykłady. Ma to intuicyjny sens, ponieważ model uczy się odtwarzać zachowanie, które doprowadziło do właściwego wyniku. Jednak odrzucanie każdej nieudanej trajektorii może marnować użyteczną pracę pośrednią.

Nieudany przebieg programistyczny może prawidłowo zlokalizować odpowiedni moduł, zidentyfikować błędny warunek i napisać większość poprawnej poprawki. Jedna późniejsza edycja może zepsuć rozwiązanie. Traktowanie całej trajektorii jako bezwartościowej powoduje utratę wcześniejszego postępu.

Receptura wprowadza dostrajanie nadzorowane z przypisywaniem zasług, aby odzyskać ten sygnał. Przypisywanie zasług oznacza określanie, które działania przyczyniły się do postępu, zamiast przypisywania jednego wyniku każdemu krokowi.

W przypadku nierozwiązanych przebiegów model nauczyciela analizuje pełną trajektorię wraz z końcowym wynikiem testu. Szacuje, jak po każdym kroku zmieniało się prawdopodobieństwo rozwiązania zadania. Następnie pipeline wybiera ciągłe segmenty, w których to oszacowane prawdopodobieństwo wzrosło.

Te rosnące segmenty stają się celami nadzorowanymi. Wcześniejsze obserwacje pozostają dostępne jako kontekst, podczas gdy strata treningowa koncentruje się na rozumowaniu i działaniach generowanych przez asystenta, uznanych za oznaki postępu. Odpowiedzi narzędzi są wyłączone ze straty predykcyjnej.

Ta technika nie zamienia porażki w sukces. Formułuje węższe twierdzenie: niektóre części nieudanego podejścia mogą nauczyć model, jak wygląda produktywna eksploracja. Wiarygodność tej lekcji zależy od retrospektywnych oszacowań modelu nauczyciela.

Receptura następnie dodaje uczenie ze wzmocnieniem, w którym model generuje nowe podejścia i otrzymuje nagrody na poziomie zadania. Trudność polega na uzyskaniu informatywnych grup podejść bez wydawania większości budżetu na jednorodne wyniki.

Jeśli każda próba kończy się sukcesem, grupa dostarcza niewiele informacji o tym, które wybory polityki były lepsze. Ten sam problem występuje, gdy każda próba kończy się porażką. Standardowe próbkowanie o stałej wielkości może zużyć znaczną moc obliczeniową na generowanie tych grup o niskiej wariancji.

Microsoft nazywa swoją alternatywę Balanced Adaptive Rollout. Metoda generuje podejścia stopniowo i próbuje zbudować grupę treningową zawierającą użyteczną równowagę pozytywnych i negatywnych nagród. Może zakończyć działanie po znalezieniu informatywnej grupy albo kontynuować w ramach ustalonego maksymalnego budżetu.

Podejście ma na celu efektywność, a nie wyłącznie dokładność. Przeznacza więcej próbek na prompty wymagające dodatkowych prób, aby uzyskać miarodajne porównanie. Grupy, które nadal pozostają nieodpowiednie, można odfiltrować i uzupełnić zadaniami z innych obszarów.

Projekt podaje, że model zainicjalizowany na bazie Qwen3-30B-A3B-Thinking osiągnął 64,3 procent w SWE-bench Verified po dostrajaniu nadzorowanym. Po uczeniu ze wzmocnieniem osiągnął 67,5 procent.

SWE-bench Verified sprawdza, czy agenci potrafią rozwiązywać rzeczywiste zgłoszenia GitHub w odtwarzalnych środowiskach repozytoriów. Wyniki zależą od wersji benchmarku, harnessu, ustawień inferencji i procedur ewaluacyjnych, dlatego porównania wymagają ścisłego dopasowania metodologicznego.

Microsoft opisuje swój wynik jako nowy szczyt wśród otwartych modeli o porównywalnej wielkości. To zastrzeżenie ma znaczenie. Wynik nie dowodzi przewagi nad każdym systemem agentowym, zwłaszcza nad zamkniętymi modelami korzystającymi z innych budżetów obliczeniowych lub nieujawnionego scaffolding.

Mimo to mechanizm jest ciekawszy niż pozycja w rankingu. Uczenie na podstawie częściowych postępów oraz próbkowanie pod kątem informatywnej zmienności nagrody to techniki, które inne zespoły mogą niezależnie testować. Ich wartość nie zależy całkowicie od jednego zgłoszonego wyniku.

Jedno środowisko wspiera trzech bardzo różnych agentów

Trzy receptury sprawdzają, czy ponowne wykorzystanie infrastruktury wytrzymuje zmiany wielkości modelu, interfejsu, struktury zadań i projektu nagrody.

Programowanie jest największą demonstracją, ale nie jedyną. Orchard-GUI stosuje tę samą abstrakcję środowiska do 4-miliardowego modelu językowo-wizyjnego, który obsługuje interfejsy przeglądarkowe.

Według doniesień receptura wykorzystuje około 400 destylowanych trajektorii i 2200 otwartych zadań. Microsoft twierdzi, że uzyskany model osiągnął wskaźnik powodzenia 74,1 procent w WebVoyager, 67,0 procent w Online-Mind2Web i 64,0 procent w DeepShop.

Te benchmarki obejmują różne formy interakcji z siecią. Agent przeglądarkowy musi interpretować stan wizualny, wybierać działania i dostosowywać się do reakcji witryny. W przeciwieństwie do zadania programistycznego powodzenie może zależeć od nawigowania po dynamicznych interfejsach, a nie od stworzenia testowalnej poprawki.

Zgłoszona wielkość danych jest godna uwagi, ponieważ jest znacznie mniejsza niż korpus inżynierii oprogramowania. Wspiera argument Microsoftu, że skoncentrowana receptura i stabilne środowisko mogą pomóc mniejszemu modelowi konkurować bez dorównywania największym systemom własnościowym pod względem liczby parametrów.

Sukces w benchmarkach nie gwarantuje jednak niezawodnego przeglądania poza rozkładem testowym. Witryny się zmieniają, interfejsy prezentują niejednoznaczny stan, a niewielkie różnice wizualne mogą skierować agenta na inną ścieżkę. Ewaluatorzy potrzebują też precyzyjnej definicji ukończenia zadania.

Trzecia receptura, Orchard-Claw, jest skierowana do agentów asystentów osobistych. Według publikacji wykorzystuje ona bazowy model Qwen3-30B-A3B-Thinking i około 200 syntetycznych zadań.

Microsoft podaje wynik 59,6 procent pass@3 w Claw-Eval. Pass@3 daje agentowi maksymalnie trzy próby i uznaje zadanie za udane, gdy powiedzie się co najmniej jedna z nich. Wynik rośnie do 73,9 procent, gdy model działa z silniejszym harnessem ZeroClaw.

Ta różnica ilustruje kluczową lekcję dotyczącą benchmarków agentów. Model jest tylko jedną częścią systemu agentowego. Projekt harnessu, formatowanie narzędzi, zachowanie przy ponawianiu prób, zarządzanie kontekstem i zasady ewaluacji mogą istotnie wpływać na wynik końcowy.

Komplikuje to również twierdzenia dotyczące mniejszych modeli. Kompaktowa polityka może dobrze działać w otoczeniu skutecznej infrastruktury, ale cały system nadal może być wymagający operacyjnie. Sama liczba parametrów nie mierzy kosztu ani złożoności wdrożenia.

Łącznie trzy receptury tworzą bardziej wiarygodny test przenośności niż trzy warianty jednego benchmarku programistycznego. Obejmują tekst i obraz, deterministyczne testy i otwarte interfejsy, a także różne skale modeli.

Wspólna warstwa nie czyni wszystkich domen identycznymi. Każda receptura nadal ma własne zbieranie danych, obliczanie nagrody, model bazowy i harness agenta. Ponowne wykorzystanie zachodzi poniżej tych decyzji specyficznych dla zadania.

Ta granica ma sens. Uniwersalna usługa środowiskowa powinna standaryzować prymitywy cyklu życia i komunikacji, nie udając przy tym, że zadanie przeglądarkowe i naprawa repozytorium mają te same kryteria powodzenia.

Szerszym pytaniem jest to, czy zespoły zewnętrzne potrafią odtworzyć taki podział. Wewnętrzne systemy badawcze często wyglądają modularnie na diagramach, lecz zależą od nieudokumentowanych konwencji, konfiguracji chmurowych lub etapów przygotowania danych. Wykorzystanie przez społeczność pokaże, czy interfejsy są rzeczywiście przenośne.

Deklaracja open source nadal musi przejść test odtwarzalności

Opublikowana architektura i mocne wyniki benchmarków to dopiero początek otwartego wydania badawczego.

Publikacja zawiera rozbudowane szczegóły implementacyjne, opisy algorytmów i ustawienia eksperymentalne. Materiały projektowe Microsoftu wskazują także badaczy, modele, źródła zadań i główne wyniki ewaluacji.

Praktyczna otwartość ma jednak kilka warstw. Badacze potrzebują dostępnego kodu, instrukcji instalacji, kompatybilnych zbiorów danych, checkpointów modeli, obrazów środowisk, licencji oraz wystarczającej liczby szczegółów konfiguracji, aby odtworzyć eksperymenty.

Strona zbioru danych wyświetla obecnie informację, że jego publikacja została wstrzymana i dane zostaną ponownie przesłane. Stwierdza, że udokumentowany schemat jest dokładny, ale może nie odpowiadać ostatecznej formie. Zespoły powinny zweryfikować status strony przed zaprojektowaniem wokół niej pipeline'u.

Ta przerwa nie podważa badań. Ogranicza jednak natychmiastową odtwarzalność, zwłaszcza w przypadku receptury inżynierii oprogramowania, której wartość silnie zależy od zbioru trajektorii.

Licencjonowanie również wymaga starannej uwagi. Dokumentacja zbioru danych ostrzega, że trajektorie odnoszą się do repozytoriów źródłowych objętych własnymi licencjami. Badacze redystrybuujący poprawki, materiały testowe lub artefakty pochodne muszą indywidualnie przeanalizować te warunki.

Kolejnym ograniczeniem jest bezpieczeństwo. Uczenie agentów celowo wykonuje działania generowane przez model. Nawet odizolowane środowiska wymagają polityk sieciowych, limitów zasobów, kontroli poświadczeń, skanowania obrazów i procedur czyszczenia.

Publikacja opisuje izolację sieciową i mechanizmy obsługi błędów, ale każde wdrożenie kontroluje własną granicę zagrożeń. Klaster badawczy obsługujący publiczne repozytoria wiąże się z innymi ryzykami niż środowisko przedsiębiorstwa zawierające prywatny kod lub wewnętrzne narzędzia.

Kontaminację benchmarków nadal trudno jednoznacznie wykluczyć. Modele nauczycielskie mogły zetknąć się podczas pretreningu z publicznymi zgłoszeniami, poprawkami lub powiązanym kodem. Ukryte testy ewaluacyjne ograniczają część ryzyk, ale nie rozstrzygają wszystkich pytań dotyczących zapamiętywania.

Metoda retrospektywnego przypisywania zasług wprowadza dodatkową niepewność. Model nauczycielski szacuje, czy kroki pośrednie zwiększyły prawdopodobieństwo sukcesu. Takie szacunki są użytecznymi etykietami tylko wtedy, gdy nauczyciel potrafi wiarygodnie interpretować trajektorię i wynik testu.

Błędny szacunek może nagradzać zachowanie wiarygodne, lecz nieistotne. Może również pominąć krok, którego wartość staje się jasna dopiero później. Niezależne ablacj e powinny sprawdzić, jaka część wyników wynika z danych o częściowych porażkach, a nie ze skali modelu, jakości nauczyciela czy składu zbioru danych.

Balanced Adaptive Rollout wymaga podobnej kontroli. Wybieranie grup z użyteczną zmiennością nagrody może poprawić efektywność treningu, jednak rzeczywiste awarie środowiska mogą wyglądać jak porażki polityki. Limity czasu, błędy kontenerów lub uszkodzone testy nie mogą stawać się mylącymi nagrodami.

Microsoft informuje o logice ponawiania prób, kontrolach limitów czasu i filtrach dla nieużytecznych grup. Zespoły zewnętrzne muszą ustalić, czy te zabezpieczenia pozostają skuteczne w różnych klastrach, przy różnych obciążeniach i rozkładach zadań.

Zgłoszone liczby należy zatem traktować jako dowody wspierające projekt, a nie ostateczny dowód jego uniwersalności. Odtworzenie wyników w niezależnej infrastrukturze wzmocniłoby argumentację. Wyniki w nowych domenach sprawdziłyby, czy abstrakcja środowiska wykracza poza trzy przygotowane receptury.

Najważniejszym rezultatem może nie być kolejny rekord benchmarku. Może nim być wspólne podłoże eksperymentalne, które pozwoli badaczom porównywać metody uczenia bez przebudowywania mechaniki leżącej u podstaw każdego eksperymentu.

Co badacze powinni obserwować dalej

Trzy sygnały zdecydują, czy Orchard stanie się powszechną infrastrukturą badawczą, czy pozostanie imponującą referencyjną implementacją Microsoftu.

Pierwszym sygnałem jest kompletność wydania. Badacze powinni obserwować przywrócenie dostępu do zbioru danych, stabilne repozytoria kodu, odtwarzalne instrukcje instalacji, artefakty modeli i wersjonowane definicje środowisk.

Kompletne wydanie wzmocniłoby twierdzenie Microsoftu, że mniejsze zespoły mogą ponownie wykorzystywać system. Utrzymujące się braki osłabiłyby je, ponieważ najtrudniejsze elementy uczenia agentów często kryją się w przygotowaniu danych i konfiguracji operacyjnej.

Drugim sygnałem jest niezależne odtworzenie. Wiarygodny test wykorzystywałby opublikowane receptury na osobno zarządzanej infrastrukturze oraz raportował zarówno wyniki benchmarków, jak i całkowite wymagania zasobowe.

Dokładne powtórzenie czołowego wyniku nie jest jedynym użytecznym rezultatem. Badacze powinni dokumentować czas konfiguracji, wskaźniki awarii sandboxów, przepustowość trajektorii, zużycie mocy obliczeniowej oraz wrażliwość na wybory dotyczące harnessu. Te pomiary ujawniają, czy ponowne wykorzystanie przynosi znaczące oszczędności.

Niezależne eksperymenty powinny również wyizolować wkład dostrajania opartego na przypisywaniu zasług. Porównania mogą trenować równoważne modele wyłącznie na udanych trajektoriach, na pełnych nierozwiązanych trajektoriach oraz na wybranych segmentach postępu.

To samo podejście dotyczy adaptacyjnych rolloutów. Badacze mogą porównać stałe próbkowanie ze zrównoważonym próbkowaniem, zachowując stałe modele, zadania, funkcje nagrody i budżety. Pokazałoby to, czy metoda zapewnia więcej sygnału uczenia na każdą wygenerowaną trajektorię.

Trzecim sygnałem jest zastosowanie poza przygotowanymi przez Microsoft domenami. Nowe środowisko zapewniłoby najsilniejszy test, zwłaszcza takie z innymi narzędziami i strukturami nagrody.

Analiza bezpieczeństwa, praca z danymi, przepływy naukowe i aplikacje biurowe są prawdopodobnymi kandydatami. Każdy z nich wprowadza wymagania środowiskowe odmienne od naprawy repozytorium czy nawigacji w przeglądarce. Udane ponowne wykorzystanie wsparłoby twierdzenie, że abstrakcja jest rzeczywiście niezależna od harnessu.

Reakcje konkurencji również mają znaczenie, choć powinny pozostać dowodem pomocniczym, a nie główną osią historii. Inne projekty uczenia agentów mogą przyjąć kompatybilne interfejsy środowiskowe, opublikować alternatywne backendy lub standaryzować formaty trajektorii.

Interoperacyjność stworzyłaby większą wartość niż mnożenie frameworków. Badacze mogliby przenosić zbiory danych, polityki i ewaluatory między systemami bez tłumaczenia każdego formatu działania i obserwacji.

Tymczasem deweloperzy powinni powstrzymać się od traktowania wydania jako gotowego agenta produkcyjnego. Projekt jest infrastrukturą badawczą do tworzenia i oceniania polityk. Systemy produkcyjne nadal potrzebują logiki aplikacji, uprawnień użytkowników, monitorowania, zachowania awaryjnego i przeglądu bezpieczeństwa.

Dla nabywców korporacyjnych istotne pytanie nie brzmi, czy framework wygrywa jeden benchmark. Chodzi o to, czy modułowa infrastruktura treningowa zmniejsza zależność od jednego własnościowego modelu lub kontrolowanego przez dostawcę stosu ewaluacyjnego.

Dla badaczy kolejny praktyczny krok jest węższy. Przeanalizuj research paper, sprawdź, które artefakty są dostępne, i wybierz jedną recepturę pasującą do istniejącego środowiska ewaluacyjnego. Mierz koszt operacyjny równolegle z wydajnością wykonania zadań.

Microsoft przedstawił jasną tezę: badania nad otwartymi agentami rozwijają się lepiej, gdy środowiska stają się infrastrukturą wielokrotnego użytku, a nie ukrytym zapleczem poszczególnych projektów. Teraz społeczność musi sprawdzić trudniejszą połowę tej tezy. Czy niezależne zespoły potrafią odtworzyć wyniki, przenieść tę infrastrukturę do nowych zadań i zachować obiecaną efektywność poza własnym środowiskiem Microsoftu?