Agenci Google Gemini w Minecraft pokonali Ender Dragona bez ludzkiego sterowania

Google twierdzi, że czterech agentów Google Gemini w Minecraft pokonało Ender Dragona bez ludzkiego sterowania po 27 godzinach i 14 minutach. Wynik opisuje zespół utrzymujący wspólny cel mimo powtarzających się porażek, a nie podążający za instrukcją napisaną przez człowieka. Rodzi też węższe pytanie: jak dużą koordynację potrafią samodzielnie zorganizować agenci programujący ogólnego przeznaczenia?

Według badaczy Maxence’a Faldora, Satindera Singha i Roberty Raileanu agenci korzystali z Gemini 4 Argon. Ich badanie agentów Minecraft, zgłoszone 15 października, odnotowuje 2 783 programy i 605 śmierci przed zwycięstwem. Zespół grał w jednym losowo wygenerowanym świecie przetrwania na łatwym poziomie trudności.

Istotne porównanie dotyczy systemów takich jak Voyager, który łączył model językowy ze specjalnie zaprojektowanym frameworkiem Minecraft. Eksperyment Google przesuwa uwagę na to, co ogólni agenci programujący mogą tworzyć podczas wykonywania zadania. To sprawia, że dla zrozumienia wyniku kluczowe staje się rozróżnienie między dostarczoną infrastrukturą a strategią stworzoną przez agentów.

Co faktycznie ukończyli agenci Google Gemini w Minecraft

Zgłoszone osiągnięcie to autonomiczne ukończenie zadania w określonych warunkach, a nie ogólna ocena wyników w Minecraft.

W tym eksperymencie ukończenie Minecraft oznaczało pokonanie Ender Dragona. Każdy agent sterował graczem za pośrednictwem Mineflayer, biblioteki JavaScript do interakcji z grą. Agenci koordynowali działania przez czat i współdzieloną pamięć, trwały zapis dostępny dla członków zespołu.

Badacze twierdzą, że nie dostarczyli przypisanych ról ani napisanej przez człowieka strategii gry. Agenci tworzyli i debugowali programy realizujące ich działania. Ludzie monitorowali sesję i zachowali możliwość jej wstrzymania lub zakończenia, ale według doniesień nie interweniowali.

Te szczegóły wyznaczają zakres pojęcia „braku interwencji człowieka”. Odnosi się ono do sterowania podczas opisanego przebiegu. Ludzie nadal wybrali model, skonfigurowali środowisko, dostarczyli narzędzia i zdefiniowali cel.

To rozróżnienie ma znaczenie, ponieważ autonomia zawsze działa w ramach układu uprawnień i możliwości. System może niezależnie wybierać kolejne działanie, jednocześnie opierając się na rozbudowanej inżynierii stworzonej przez ludzi. Ocena tej niezależności wymaga jasnego opisania obu części.

Znaczenie ma też punkt końcowy. Pokonanie zdefiniowanego bossa daje wyraźniejsze kryterium ukończenia niż otwarta prośba o poczynienie postępów. Daje badaczom coś konkretnego do sprawdzenia względem środowiska.

Dla czytelników sprawia to, że jest to bardziej informacyjne twierdzenie niż sytuacja, w której agent jedynie ogłasza, że zakończył zadanie. Przekonujące ukończenie wymaga dowodów poza własną narracją agenta. To rozróżnienie staje się szczególnie ważne, gdy kilku agentów wymienia raporty o pracy, której nie wszyscy mogą bezpośrednio obserwować.

Minecraft uwidacznia również zależności. Późniejszy cel może wymagać zasobów lub dostępu zdobytych znacznie wcześniej. Lokalny postęp musi więc przyczyniać się do większej sekwencji działań.

Analityczne zainteresowanie polega na utrzymaniu tej sekwencji mimo przerw i nieudanych działań. Agent, który potrafi opisać cały plan, nadal musi rozpoznać, kiedy okoliczności unieważniają jego część. Członkowie zespołu potrzebują następnie wystarczająco aktualnych informacji, by kontynuować produktywną pracę.

Zgłoszone zwycięstwo daje badaczom konkretny przykład do zbadania. Nie ustala, jak często ta sama konfiguracja ukończyłaby kolejny świat. Ani upływ czasu sam w sobie nie mówi, czy zespół efektywnie wykorzystywał zasoby.

Dlatego nagłówek zasługuje zarówno na uwagę, jak i precyzję. Google informuje o ukończonym zadaniu bez ludzkiego sterowania podczas gry. Szersze znaczenie zależy od tego, które elementy tego wyniku przetrwają kontrolowane porównanie i powtórzenie.

Presja spada na ręcznie tworzone przepływy pracy agentów

Eksperyment skłania deweloperów do wyjaśnienia, których instrukcji specyficznych dla zadania ich agenci nadal potrzebują.

Agent programujący ogólnego przeznaczenia to model połączony z narzędziami, które pozwalają mu analizować, modyfikować i wykonywać kod. Jego użyteczność zależy częściowo od modelu, a częściowo od otaczającego go systemu. Wynik Minecraft kieruje uwagę na ten system.

Twórca agenta ma kilka miejsc, w których może umieścić wiedzę ekspercką. Deweloperzy mogą zakodować szczegółowy przepływ pracy przed wykonaniem zadania. Mogą też zapewnić bardziej ogólne narzędzia i poprosić agenta o skonstruowanie podejścia.

Te wybory wpływają na utrzymanie. Szczegółowy przepływ pracy może ułatwiać analizę oczekiwanego zachowania. Może też wymagać zmian, gdy środowisko się zmienia lub pojawia się nieznana awaria.

Agent, który tworzy własne procedury, oferuje inną możliwość. Deweloperzy przekazują większą część ciężaru planowania etapowi wykonania. Potrzebują wtedy skuteczniejszych sposobów sprawdzania, czy wynikające z tego zachowanie jest poprawne.

Agenci Google Gemini w Minecraft czynią to pytanie projektowe konkretnym. Interesujące porównanie dotyczy tego, jak wiele użytecznej strategii wyłania się po dostarczeniu celu. Sam ukończony przebieg nie rozstrzyga, która architektura zapewnia najlepszy ogólny wynik.

Zespoły budujące produkty agentowe powinny zatem powstrzymać się od traktowania mniejszej liczby instrukcji jako automatycznej zalety. Instrukcja może oznaczać niepotrzebną sztywność, cenną wiedzę dziedzinową lub niezbędną granicę operacyjną. Jej wartość zależy od tego, co dzieje się po jej usunięciu.

To samo rozumowanie dotyczy narzędzi wielokrotnego użytku. Wyspecjalizowane działanie może ukrywać znaczący wysiłek człowieka. Może też zapewniać niezawodny interfejs, który czyni trudny przepływ pracy praktycznym.

Użyteczne pytanie badawcze brzmi, czy agenci potrafią tworzyć równoważne możliwości, gdy są potrzebne. Drugie pytanie dotyczy tego, czy możliwości te pozostają niezawodne po zmianie bezpośredniej sytuacji. Oba wymagają dowodów wykraczających poza udane zakończenie.

Wywiera to presję na demonstracje produktów, które pokazują wyłącznie końcowy artefakt. Kupujący muszą rozumieć, co dostarczono z wyprzedzeniem, co stworzył agent i co wymagało naprawy przez człowieka. Bez tych informacji pozornie podobne demonstracje mogą reprezentować bardzo różne możliwości.

Dla nabywców korporacyjnych sugeruje to bardziej produktywną rozmowę oceniającą. Poproście dostawców o opisanie założeń, jakie ich system przyjmuje na temat zadania. Następnie sprawdźcie, jak agent zachowuje się, gdy te założenia przestają obowiązywać.

Dla deweloperów wniosek jest równie praktyczny. Ogólne narzędzia zasługują na ocenę obok starannie skryptowanych przepływów pracy. Właściwe porównanie mierzy ukończenie, nadzór, odzyskiwanie sprawności i wykorzystanie zasobów w równoważnych warunkach.

Wynik Google daje temu porównaniu wyrazisty przykład. Nie dowodzi, że każda organizacja powinna zastąpić jawne przepływy pracy autonomicznym planowaniem. Wzmacnia argument za testowaniem, gdzie takie zastąpienie działa.

Bezpośrednia presja spada więc na standardy dowodowe. Twórcy agentów muszą pokazać wkład swojej orkiestracji, czyli oprogramowania organizującego działania agentów. Zarówno możliwości modelu, jak i projekt przepływu pracy zasługują na analizę.

Współdzielona pamięć nadaje indywidualnym działaniom kontekst zespołowy

Koordynacja staje się użyteczna, gdy informacje zmieniają to, co członkowie zespołu robią później.

Badacze opisują agentów dzielących się wskazówkami, zagrożeniami, błędami i lokalizacjami. Te kategorie są istotne, ponieważ służą różnym decyzjom. Ostrzeżenie pomaga zapobiec stracie, a lokalizacja pomaga innemu graczowi działać.

Kluczowe pytanie analityczne brzmi, czy te wymiany poprawiły wykonanie zadania. Liczba wiadomości na czacie byłaby słabym substytutem odpowiedzi. Zespół może często komunikować się, jednocześnie powtarzając błędy lub realizując niezgodne plany.

Współdzielona pamięć oferuje sposób zachowania informacji poza bezpośrednią wymianą. Jednak zapisanie stwierdzenia nie czyni go dokładnym, aktualnym ani istotnym. Sprawnie działający zespół potrzebuje sposobu na połączenie zapamiętanych informacji z obecnym środowiskiem.

Rozważmy hipotetyczną migrację oprogramowania. Jeden agent odkrywa, że zależność zachowuje się inaczej niż wynika z jej dokumentacji. Zapisanie rozbieżności pomaga tylko wtedy, gdy inni agenci konsultują ją przed wprowadzeniem powiązanych zmian.

Zapis musi również zawierać wystarczająco dużo szczegółów, by wspierać działanie. Ogólne ostrzeżenie zmusza członków zespołu do odtworzenia problemu. Użyteczna notatka wskazuje warunek, zaobserwowaną konsekwencję i procedurę, która zadziałała.

To szersze znaczenie mechanizmu współdzielonej pamięci. Może on przekształcić indywidualne doświadczenie w informację dostępną dla zespołu. To, czy taka informacja poprawia wyniki, pozostaje pytaniem empirycznym.

To samo rozróżnienie dotyczy odzyskiwania sprawności po niepowodzeniu. Nieudane działanie może przynieść użyteczną korektę, nieistotne wyjaśnienie lub mylący wniosek. Trwałość ma znaczenie tylko wtedy, gdy kolejna próba korzysta z tego, co wydarzyło się wcześniej.

Dla pracowników wiedzy to połączenie jest znajome. Przeszukiwalna baza wiedzy inżynierskiej zaspokaja podobną potrzebę organizacyjną: udostępnia wcześniejsze ustalenia, gdy zależy od nich inne zadanie. Ta analogia nie oznacza identycznych systemów ani równoważnych wyników.

Pamięć agentów wprowadza dodatkowy problem weryfikacji. Automatycznie wygenerowana notatka może brzmieć autorytatywnie, nawet gdy obserwacja, na której się opiera, była słaba. Jej ponowne wykorzystanie może rozprzestrzenić pierwotny błąd wśród kilku pracowników.

Użyteczny system pamięci potrzebuje zatem czegoś więcej niż wyszukiwania. Potrzebuje dowodów, zakresu i sposobu na zastępowanie nieaktualnych wniosków. Wymagania te stają się ważniejsze wraz z wydłużaniem się zadań.

Zgłoszone zachowanie w Minecraft jest interesujące, ponieważ komunikacja dotyczyła bieżącego wykonywania zadania. Dzielenie się informacjami o zagrożeniach lub odzyskiwanie przedmiotów członka zespołu łączy koordynację z bezpośrednią konsekwencją. Daje badaczom coś bardziej konkretnego do zbadania niż płynność konwersacji.

Mimo to udany ratunek nie dowodzi istnienia ogólnie niezawodnej polityki koordynacji. Badacze musieliby przeanalizować przeoczone ostrzeżenia, niepotrzebne powielanie działań i błędne wspólne przekonania. Niepowodzenia powinny należeć do analizy obok pomocnych wymian.

Dobre badanie uzupełniające prześledziłoby pojedynczą informację od obserwacji do działania. Czy inny agent ją przeczytał, zmienił plan i uniknął mierzalnego niepowodzenia? Taki łańcuch dostarczyłby wyraźniejszych dowodów na wkład współdzielonej pamięci.

Dla zespołów produktowych wniosek polega na ocenie pamięci przez pryzmat dalszych decyzji. Zapisywanie większej liczby notatek nie wystarczy. Istotnym wynikiem jest to, czy agenci podejmują lepsze decyzje, gdy notatki stają się dostępne.

Voyager i agenci opierający się na wideo dostarczają różnych porównań

Wcześniejsze badania pokazują, dlaczego interfejs i dostarczony framework powinny należeć do każdego porównania.

Badanie Voyager opisywało agenta Minecraft zbudowanego wokół GPT-4. Jego framework łączył automatyczny program nauczania, rosnącą bibliotekę wykonywalnych umiejętności oraz ulepszanie programów oparte na informacji zwrotnej. Komponenty te organizowały eksplorację i pomagały ponownie wykorzystywać skuteczne zachowania.

Praca ta stanowi użyteczny punkt odniesienia dla eksperymentu Google. Obie dotyczą modeli językowych przekształcających wiedzę w wykonywalne działania. Ich otaczające systemy i cele różnią się, więc wspólna gra nie tworzy kontrolowanego porównania.

Automatyczny program nauczania wybiera zadania wspierające dalsze uczenie się lub eksplorację. Stały cel końcowy nakłada inne wymagania na planowanie. Żaden z tych wyborów nie jest z natury lepszy bez określenia, co mierzy ewaluacja.

Podobnie biblioteka umiejętności przechowuje zachowania do późniejszego ponownego użycia. Ocena jej wkładu wymaga zbadania, co było dostępne na początku i co dodał agent. W przeciwnym razie trudno odróżnić model od zgromadzonego wokół niego systemu wsparcia.

Wcześniejsze badanie Video PreTraining analizowało inną drogę. Wykorzystało nagrania rozgrywki online do uczenia zachowań poprzez półnadzorowane uczenie przez naśladowanie, łączące oznaczone przykłady z większymi nieoznaczonymi zbiorami danych. Jego agenci działali za pośrednictwem interfejsu myszy i klawiatury.

Ten interfejs zmienia charakter problemu. Sterowanie wizualne wymaga interpretowania ekranu i wybierania działań niskiego poziomu. Interfejs programistyczny udostępnia inny zestaw obserwacji i operacji.

To rozróżnienie przypomina różnicę między obsługą oprogramowania przez jego interfejs a korzystaniem z udokumentowanego połączenia programistycznego. Oba podejścia mogą prowadzić do użytecznej pracy. Stawiają jednak odmienne wymagania w zakresie percepcji, nawigacji i wykonania.

Z tego powodu „pokonuje Minecrafta” to niepełne określenie porównawcze. Fraza wskazuje rezultat, ale pomija ważne warunki. Czytelnicy potrzebują informacji o interfejsie, celu, zasobach początkowych i procedurze ewaluacji.

Wyjaśnia to również, dlaczego historyczne wyniki nie powinny być sprowadzane do prostego rankingu. Rezultaty eksploracji Voyager nie mierzą bezpośrednio tego samego wyniku co pokonanie smoka. Sterowanie oparte na wideo ocenia zdolności, które rozgrywka pośredniczona przez kod może ominąć.

Wniosek dla branży jest taki, że badania nad agentami potrzebują kilku uzupełniających się testów. Jeden może badać interakcję wizualną, drugi syntezę programów, a kolejny koordynację zespołową. Pojedyncza demonstracja nie może równie dobrze reprezentować wszystkich tych zdolności.

W automatyzacji oprogramowania środowiska pośredniczone przez kod pozostają bardzo istotne. Wiele zadań w pracy już teraz udostępnia ustrukturyzowane dane i programowalne operacje. Sukces w takim środowisku nie musi naśladować ludzkich ruchów myszą, aby mieć praktyczną wartość.

Jednocześnie ustrukturyzowany dostęp może upraszczać ważne elementy zadania. Porównanie powinno uwidaczniać tę przewagę. W przeciwnym razie czytelnicy mogą pomylić lepszy dostęp do środowiska z szerszym wzrostem zdolności rozumowania.

Właściwy wniosek ma zatem charakter architektoniczny. Raportowany przez Google wynik dostarcza dowodów dotyczących ogólnych agentów programistycznych realizujących dłuższy wspólny cel. Wcześniejsze systemy pomagają określić, które zdolności się pokrywają, a które pozostają poza zakresem tych dowodów.

Takie ujęcie zachowuje wagę osiągnięcia, nie zmieniając go w niepoparty rywalizacyjny pojedynek marek modeli.

Udane uruchomienie pozostawia niezbadną niezawodność

Ukończenie potwierdza, że wynik wystąpił w raportowanych warunkach; niezawodność wymaga szerszego zbioru danych.

Pojedyncze uruchomienie nie może ujawnić rozkładu możliwych wyników. Inny świat mógłby przynieść szybsze ukończenie, dłuższą walkę albo brak ukończenia w dozwolonym budżecie. Udany punkt końcowy nie mówi, który wynik jest typowy.

To kluczowe ograniczenie dotyczące agentów Google Gemini w Minecraft. Raportowany wynik wspiera twierdzenie o zdolności wykazanej w jednym wykonaniu. Nie zapewnia jednak wiarygodnej prognozy dla każdego przyszłego wykonania.

Ustawienie Easy również należy uwzględnić w interpretacji. Poziom trudności jest częścią warunku eksperymentalnego, a nie przypisem, który czytelnicy powinni odkryć później. Jego zmiana stworzyłaby inny test.

To samo dotyczy monitorowania przez człowieka. Uruchomienie może przebiegać bez interwencji, pozostając jednocześnie nadzorowane. To, czy taki monitoring jest konieczny, opcjonalny lub skalowalny, wymaga odrębnych badań.

Niezależna replikacja odpowiedziałaby na inne pytanie. Sprawdziłaby, czy ktoś spoza pierwotnego zespołu może odtworzyć rezultat na podstawie wystarczająco pełnego opisu. To coś innego niż weryfikacja, czy autorzy dokładnie zarejestrowali swoją sesję.

Te rozróżnienia mają znaczenie dla wdrożeń w przedsiębiorstwach, ponieważ błędy niosą różne konsekwencje w różnych środowiskach. Gra dopuszcza formy ponawiania prób, na które zewnętrzny proces biznesowy może nie pozwalać. Ewaluacja musi uwzględniać koszt każdego nieudanego działania.

Rozważmy hipotetyczny proces zakupowy. Ponowienie nieskutecznego wyszukiwania jest stosunkowo łatwe do odwrócenia. Ponowienie zrealizowanego zamówienia, ponieważ potwierdzenie zostało źle zrozumiane, stwarza inny problem.

To porównanie pokazuje, dlaczego odzyskiwania sprawności nie można mierzyć wyłącznie końcowym ukończeniem. System musi także rozpoznawać działania nieodwracalne i unikać ich powielania. Musi zachować różnicę między kolejną próbą a wyrządzeniem dodatkowej szkody.

Kolejna niepewność dotyczy wkładu wielu agentów. Sukces zespołu nie dowodzi, że zespół przewyższa pojedynczego agenta. Większa liczba pracowników może rozdzielać wysiłek, ale tworzy też wymagania komunikacyjne i koordynacyjne.

Kontrolowane porównanie powinno utrzymywać spójność środowiska i przydziału zasobów. W przeciwnym razie dodatkowe obliczenia można pomylić z przewagą pracy zespołowej. Badacze muszą rozdzielić te wyjaśnienia.

Pamięć zasługuje na takie samo podejście. Jeśli zespół kończy pracę ze współdzielonymi notatkami, nie wyodrębnia to, w jakim stopniu te notatki pomogły. Porównanie bez współdzielonej pamięci wyjaśniłoby mechanizm, pod warunkiem że inne warunki pozostaną porównywalne.

Są to pytania badawcze, a nie powody do odrzucenia wyniku. Eksploracyjna demonstracja może wskazać zachowanie warte zbadania, zanim powstanie szeroki benchmark. Jej wartość rośnie, gdy kolejne eksperymenty celują w ujawnione przez nią niepewności.

Dla kupujących praktyczna lekcja jest taka, by prosić o rozkłady wyników. Typowy czas ukończenia, nieudane próby i wymagania dotyczące napraw przez człowieka są równie ważne jak najsilniejszy przykład. Dopracowana historia sukcesu nie może zastąpić tych pomiarów.

Dla badaczy szansą jest połączenie widocznego zwycięstwa z dowodami przyczynowymi. Które składniki były konieczne, które pomocne, a które dodawały złożoności? Odpowiedzi na te pytania ułatwiłyby zastosowanie wyniku w innych miejscach.

Obserwuj powtarzalność, porównania zespołów i transfer

Kolejne użyteczne dowody powinny badać powtarzalność, wyodrębniać koordynację i analizować inne zadanie.

Pierwszym sygnałem, który warto obserwować w nadchodzących miesiącach, jest powtarzana ewaluacja w losowo generowanych światach. Użyteczny raport obejmowałby każdą próbę, jej regułę zatrzymania i wynik. Pokazałoby to, czy ukończenie jest powszechne przy określonym budżecie.

Silniejszy wynik wykazałby, że sukces utrzymuje się w zróżnicowanych warunkach początkowych. Słabszy wynik ujawniłby częste przestoje lub zależność od wyjątkowo sprzyjających okoliczności. Każde z tych ustaleń poprawiłoby zrozumienie pierwotnej demonstracji.

Czas ukończenia powinien być raportowany obok niepowodzeń. System, który ostatecznie kończy zadanie, może nadal być nieprzewidywalny w ramach praktycznego terminu. Rozrzut wyników ma znaczenie, gdy inny proces zależy od jego pracy.

Badacze powinni także wyjaśniać, jak radzą sobie z przerwami i problemami infrastrukturalnymi. Zdarzenia te mogą wpływać zarówno na upływ czasu, jak i na uczciwość porównań. Jasne rozliczenie zapobiega sytuacji, w której techniczne ponowne uruchomienie staje się niewidoczną zmianą warunków eksperymentalnych.

Drugim sygnałem jest kontrolowane porównanie konfiguracji zespołowych. Pojedynczy agent, komunikujący się zespół i zespół bez współdzielonej pamięci testowałyby różne wyjaśnienia. Porównywalne przydziały zasobów pomogłyby oddzielić koordynację od dodatkowych obliczeń.

Pozwoliłoby to doprecyzować interpretację koordynacji agentów Gemini. Jeśli komunikacja konsekwentnie poprawia wyniki, rezultat wspierałby inwestowanie we współdzielony stan i przekazywanie zadań. Jeśli przewaga znika, prostsze systemy zasługiwałyby na bliższą uwagę.

Porównanie powinno analizować błędy, a także zwycięstwa. Zespoły mogą częściej kończyć zadania, jednocześnie tworząc więcej sprzecznych raportów. Mogą też lepiej się regenerować, ale spędzać więcej czasu na komunikacji.

Te kompromisy mają znaczenie, ponieważ użytkownicy rzadko optymalizują tylko jedną metrykę. Praktyczny system potrzebuje akceptowalnej kombinacji ukończenia, opóźnienia, nadzoru i wykorzystania zasobów. Preferowana architektura zależy od ograniczeń zadania.

Trzecim sygnałem jest transfer do innego ograniczonego procesu pracy. Zadanie utrzymania oprogramowania z ukrytymi kontrolami zapewniłoby inny test planowania i odzyskiwania sprawności. Uczyniłoby też związek z produktami agentów programistycznych bardziej bezpośrednim.

Użyteczne badanie ujawniłoby początkowe narzędzia i instrukcje. Powinno wskazywać wszelkie poprawki wprowadzane przez człowieka i odróżniać procedury napisane przez agenta od dostarczonych. Te szczegóły pokazałyby, czy mechanizm działa również poza grą.

Nie należy wnioskować o transferze na podstawie znajomo wyglądającego zachowania. Przekazanie ostrzeżenia w Minecraft i koordynowanie zmiany w kodzie mogą przypominać się organizacyjnie. Nadal wymagają odrębnych dowodów poprawnego wykonania.

Dla deweloperów te sygnały wskazują, czego oczekiwać od przyszłych demonstracji. Szukaj powtarzanych wyników, porównywalnych punktów odniesienia i zapisu interwencji. Te szczegóły ujawniają więcej niż dłuższy film z najważniejszymi momentami.

Dla pracowników umysłowych ta historia daje powód, by przyjrzeć się temu, jak informacje przetrwają przekazywanie zadań. Zespół staje się bardziej użyteczny, gdy zweryfikowane ustalenie jednego członka pomaga drugiemu działać poprawnie. Ta sama zasada obowiązuje, gdy uczestnikami są agenci oprogramowania.

Przed wdrożeniem systemu inspirowanego tym wynikiem wybierz ograniczone zadanie z jasnym punktem końcowym i działaniami możliwymi do sprawdzenia. Zapytaj, jakie dowody potwierdzają sukces, na co pozwala porażka i gdzie nadal potrzebny jest osąd człowieka. Te pytania zmieniają atrakcyjną demonstrację w ewaluację, z której możesz skorzystać.

Rozpatruj agentów Google Gemini w Minecraft w tym kontekście, gdy pojawiają się kolejne dowody. Czytaj nie tylko o końcowym zwycięstwie, lecz także analizuj warunki, które je przyniosły. Czy system powtórzył wynik, skorzystał z pracy zespołowej i przeniósł swoje podejście na inne zadanie? Wykorzystaj odpowiedzi, aby ocenić, jaką autonomię wspiera ten rezultat.