Trasy biegowe GPT-6 Astra działały, ale kod zniknął
GPT-6 Astra spędził 27 minut na generowaniu tras biegowych od domu Simona Willisona, a następnie dostarczył mapy i pliki do pobrania zgodne z jego prośbą. Udany rezultat jeszcze bardziej uwidocznił brak dowodów. ChatGPT Work pokazał mu gotową trasę, lecz nie kod Python ani pełną historię jej wykonania.
Willison poprosił o pętle 5K i 10K, które zaczynały się i kończyły pod jego adresem. Polecił ChatGPT Work użycie danych OpenStreetMap. Według jego relacji dotyczącej tras biegowych agent zwrócił osadzoną wizualizację, pliki GPX do pobrania oraz pliki GeoJSON.
To zadanie jest wyjątkowo konkretnym przykładem tego, jak agentowa AI staje się użyteczna poza tradycyjną pracą biurową. W jednej rozmowie połączono geokodowanie, pobieranie danych mapowych, analizę grafów, wybór tras, generowanie plików i wizualizację.
Rezultat ujawnił jednak również konflikt leżący u podstaw agentów AI. System może ukończyć trudne zadanie, jednocześnie nie pozwalając użytkownikowi odtworzyć sposobu, w jaki doszedł do odpowiedzi.
Ten konflikt ma większe znaczenie niż sama trasa. OpenAI przedstawia GPT-6 Astra jako model do długotrwałej pracy przy komputerze, w której użytkownicy delegują złożone cele, zamiast prosić o pojedyncze odpowiedzi. Taka delegacja zwiększa wartość rejestrów wykonania, plików pośrednich i kodu umożliwiającego odtworzenie wyników.
Przykład tras biegowych GPT-6 Astra sprawdza więc jednocześnie dwie obietnice. Astra wydaje się zdolna do realizacji wyspecjalizowanego przepływu pracy geospatialnej. ChatGPT Work wydaje się mniej przygotowany do zachowania dowodów potrzebnych do późniejszego zbadania tego procesu.
Trasy biegowe GPT-6 Astra połączyły kilka narzędzi w jeden wynik
Istotna zmiana nie polegała na tym, że AI zasugerowała trasę do joggingu, lecz na tym, że z krótkiej prośby stworzyła użyteczny geospatialny rezultat.
Willison poprosił system o zlokalizowanie jego adresu i wyznaczenie dwóch pętli z użyciem danych OpenStreetMap. Pętla miała zaczynać się i kończyć w tym samym miejscu, pozostając przy tym w rozsądnej odległości od docelowego dystansu.
To trudniejsze niż poproszenie usługi mapowej o wskazówki między dwoma ustalonymi punktami. Agent najpierw musiał ustalić współrzędne geograficzne punktu startowego. Następnie potrzebował lokalnej sieci dróg i szlaków, z których mógłby skorzystać biegacz.
ChatGPT później przekazał Willisonowi, że użył Nominatim do zlokalizowania adresu. Nominatim to geokoder, czyli narzędzie przekształcające zapisane miejsce lub adres we współrzędne geograficzne.
System podał, że użył Overpass do pobrania pobliskich dróg i szlaków z OpenStreetMap. API Overpass umożliwia wykonywanie ustrukturyzowanych zapytań wobec danych OpenStreetMap, w tym cech geograficznych i ich opisowych tagów.
Pozostałe działania miały podobno odbyć się lokalnie. Agent musiał przekształcić elementy mapy w połączoną sieć, zidentyfikować kandydatów na pętle, oszacować ich długości i wybrać trasy zbliżone do pięciu i dziesięciu kilometrów.
Willison nie otrzymał implementacji, więc te konkretne kroki algorytmiczne pozostają świadomą rekonstrukcją. Krótkie wyjaśnienie agenta nie wskazywało biblioteki grafowej, metody wyszukiwania, zasad punktowania tras ani logiki filtrowania.
Widoczne wyniki były bardziej konkretne. ChatGPT Work wygenerował 5,1-kilometrową pętlę wzdłuż portu i wyświetlił ją w rozmowie. Udostępnił także pliki GPX i GeoJSON, dwa popularne formaty wymiany geometrii tras.
GPX to format oparty na XML, obsługiwany przez wiele urządzeń fitness i aplikacji mapowych. GeoJSON przedstawia obiekty geograficzne za pomocą JSON, co czyni go wygodnym dla map internetowych i potoków oprogramowania.
Osadzona mapa sama była wygenerowanym artefaktem. Willison odkrył, że ChatGPT utworzył plik HTML zawierający geometrię trasy i JavaScript, który renderował wizualizację za pomocą D3.
HTML przechowywał geometrię w elemencie danych aplikacji. Oznaczało to, że wyświetlana trasa nie była jedynie statycznym zrzutem ekranu. Zawierała współrzędne, które oprogramowanie mogło odczytać i ponownie narysować.
Ta kombinacja ma znaczenie, ponieważ przekracza granicę między odpowiedzią a gotowym rezultatem. Lista nazw ulic nadal wymagałaby znacznej pracy, zanim biegacz mógłby z niej skorzystać.
Wygenerowane pliki można było importować gdzie indziej, sprawdzać lub przenosić na zgodne urządzenia. Mapa dała użytkownikowi natychmiastową kontrolę wizualną bez konieczności używania innej aplikacji.
OpenAI opisuje ChatGPT Work jako agenta do dłuższych, wieloetapowych zadań i gotowych rezultatów. Obecna dokumentacja Work odróżnia to doświadczenie od zwykłej pomocy konwersacyjnej.
Zadanie dotyczące trasy ściśle odpowiada tej definicji. Zaczęło się od celu wyrażonego językiem naturalnym, wykorzystało dane zewnętrzne, przeprowadziło lokalne obliczenia i zwróciło kilka skoordynowanych wyników.
Jednak sukces na tym poziomie zmienia potrzeby użytkowników wobec interfejsu. Gdy agent wykonuje istotne obliczenia, jego proces staje się częścią produktu, a nie jednorazową aktywnością w tle.
Dlaczego to niewielkie zadanie mapowe ma znaczenie
Trasa jest zwięzłą demonstracją tego, jak agenci AI mogą zamieniać specjalistyczne przepływy pracy w zwykłe prośby.
Ręczne stworzenie takiej trasy zwykle wymagałoby kilku narzędzi. Użytkownik mógłby geokodować adres, pobrać dane mapowe, skonfigurować oprogramowanie do wyznaczania tras, sprawdzić potencjalne ścieżki i wyeksportować wybraną geometrię.
Każdy etap wymaga innego rodzaju wiedzy. Geokodowanie wymaga znajomości usług wyszukiwania miejsc. Pozyskiwanie danych z OpenStreetMap wymaga składni zapytań lub odpowiedniego interfejsu.
Obliczanie trasy wprowadza pojęcia grafowe, takie jak węzły, krawędzie, wagi ścieżek i spójność. Eksport plików wymaga znajomości formatów akceptowanych przez aplikacje fitness i mapowe.
ChatGPT Work najwyraźniej skoordynował te elementy bez wymagania od Willisona nadzorowania każdej technicznej decyzji. Interfejs pozwolił mu opisać rezultat zamiast określać pełną implementację.
To centralna propozycja wartości ogólnego agenta. Może on dobierać i łączyć narzędzia zgodnie z celem, zamiast ograniczać użytkownika do z góry ustalonego przepływu pracy.
Istotne jest także wyczucie czasu. OpenAI wprowadziło Astrę, podkreślając jej możliwości w programowaniu, przeglądaniu internetu, obsłudze komputera i złożonej pracy profesjonalnej. Jej strona premierowa Astra przedstawia model jako zdolny do tworzenia plików, wykresów, stron internetowych i innych ukończonych artefaktów.
OpenAI podaje, że Astra uzyskała wynik 72,6 procent w przytaczanej przez firmę konfiguracji OSWorld 2.0. GPT-5.6 Sol uzyskał 65,7 procent w tym samym raportowanym ustawieniu.
Firma twierdzi również, że Astra ukończyła te symulowane zadania komputerowe w około 40 minut, wobec około 75 minut w przypadku GPT-5.6 Sol. Nadal są to zgłoszone przez firmę wyniki benchmarków, a nie niezależna walidacja trasy Willisona.
Mimo to 27-minutowe zadanie biegowe nadaje tym szerszym deklaracjom rozpoznawalny kształt. Model nie tylko obsługiwał znaną stronę internetową ani nie wypełniał pól w standardowym formularzu.
Najwyraźniej improwizował przepływ pracy wokół otwartej infrastruktury geograficznej. Wybrał usługi, pobrał dane, przeprowadził obliczenia, utworzył przenośne pliki i zbudował niestandardową warstwę prezentacji.
Ta elastyczność wywiera presję na dwie kategorie oprogramowania. Pierwszą stanowią wyspecjalizowane narzędzia konsumenckie oparte na stałych interfejsach do planowania tras.
Ogólny agent nie musi całkowicie zastępować tych produktów. Może natomiast obsługiwać nietypowe prośby, które sztywne interfejsy mają trudność wyrazić.
Biegacz może poprosić o pętlę o precyzyjnie określonym dystansie, omijającą konkretną drogę, preferującą szlaki, przebiegającą obok fontanny z wodą lub kończącą się przed zachodem słońca. Język naturalny może łatwo łączyć takie ograniczenia.
Drugą kategorią pod presją jest sam tradycyjny chatbot. Gdy użytkownicy zobaczą agenta wykonującego taką pracę, odpowiedź tekstowa zaczyna wydawać się niepełna.
Oczekują wygenerowanych plików, interaktywnych widoków, edytowalnych obliczeń i zapisu wykonanych kroków. Rezultat staje się standardem, według którego oceniana jest rozmowa.
Wrześniowe informacje o wydaniu OpenAI opisują Astrę jako usprawnienie dla pracy wieloetapowej. Stwierdzają również, że ChatGPT Work może, za zgodą, korzystać z lokalnych plików i narzędzi obsługiwanych stron internetowych.
Przykład trasy sugeruje, że te możliwości mogą wykraczać poza dokumenty biurowe. Mogą wspierać osobiste projekty z wymaganiami technicznymi, które wcześniej wymagały niestandardowego oprogramowania.
Nie sprawia to automatycznie, że wynik jest godny zaufania. Sprawia, że weryfikacja staje się ważniejsza, ponieważ agent może teraz tworzyć artefakty wyglądające na wystarczająco kompletne, by użyć ich od razu.
Główny konflikt to zdolność kontra audytowalność
ChatGPT Work ukończył zlecone zadanie, ale nie zachował wystarczająco widocznych dowodów, aby użytkownik mógł odtworzyć wynik.
Willison zapytał, jak utworzono trasę, po otrzymaniu rezultatów. ChatGPT przekazał ogólne wyjaśnienie dotyczące Nominatim, Overpass i lokalnych obliczeń.
Wyjaśnienie wskazywało szeroką architekturę. Nie ujawniało, z jakimi punktami końcowymi usług się połączono, jakie zapytania przesłano ani które tagi mapowe uznano za odpowiednie dla biegaczy.
Nie ujawniało również sposobu generowania kandydatów na pętle. Skrypt wyznaczający trasy mógł korzystać z wyszukiwania najkrótszych ścieżek, próbkowania punktów pośrednich, wykrywania cykli, optymalizacji lub kilku połączonych metod.
Te wybory wpływają na końcową trasę. Mogą decydować o tym, czy system preferuje utwardzone drogi, nadbrzeżne szlaki, przejścia, strome odcinki czy ścieżki z niepełnymi informacjami o dostępie.
Willison następnie poprosił o kod Python. ChatGPT nie mógł go już dostarczyć, najwyraźniej dlatego, że rozmowa przeszła kompresję kontekstu.
Kompresja kondensuje wcześniejszy kontekst, aby długo działający agent mógł kontynuować pracę w dostępnym oknie kontekstowym. Może pomóc systemowi zachować działanie, ale szczegóły mogą zniknąć z aktywnego kontekstu.
Willison argumentował, że systemy korzystające z kompresji powinny zachowywać oryginalny materiał. Chce również, aby agenci mogli odzyskiwać ten materiał za pomocą narzędzi, gdy wymaga tego późniejsza prośba.
Jego krytyka wskazuje problem interfejsu, a nie problem inteligencji modelu. System mógł stworzyć poprawny kod, a mimo to nie zapewnić odpowiedniego zapisu.
To rozróżnienie jest kluczowe. Zdolność modelu odpowiada na pytanie, czy agent potrafi ukończyć zadanie. Audytowalność odpowiada na pytanie, czy człowiek potrafi zrozumieć, zweryfikować, powtórzyć lub zakwestionować to wykonanie.
W przypadku swobodnego tworzenia pomysłów zwięzłe podsumowanie procesu może wystarczyć. W przypadku wygenerowanych tras, obliczeń finansowych, zbiorów danych badawczych lub plików biznesowych często tak nie jest.
Użyteczny ślad audytowy nie wymaga ujawniania prywatnego rozumowania chain-of-thought. Może składać się z operacyjnych dowodów należących do zadania.
Takie dowody mogłyby obejmować wygenerowane skrypty, polecenia terminala, adresy URL źródeł danych, znaczniki czasu, odpowiedzi narzędzi, ostrzeżenia, pliki pośrednie i wersje istotnych bibliotek.
Takie zapisy różnią się od ukrytego wewnętrznego rozumowania. Dokumentują obserwowalne działania i przekształcenia, podobnie jak dziennik kompilacji dokumentuje sposób utworzenia oprogramowania.
HTML trasy przetrwał, ponieważ stanowił część końcowego rezultatu. Implementacja Python nie przetrwała, choć była prawdopodobnie ważniejsza dla weryfikacji.
Ta asymetria zachęca użytkowników do ufania prezentacji bardziej niż pochodzeniu danych. Dopracowana mapa może wyglądać wiarygodnie, jednocześnie ukrywając założenia, które istotnie wpływają na bezpieczeństwo i dokładność.
Problem staje się jeszcze wyraźniejszy, gdy agent pracuje przez 27 minut. Dłuższe zadanie może obejmować więcej stanu, więcej wywołań narzędzi, więcej decyzji pośrednich i więcej okazji do cichych błędów.
Użytkownicy nie powinni musieć przewidywać, którego artefaktu będą potrzebować później. System powinien zachować uporządkowany pakiet zadania, zanim kompresja kontekstu usunie istotne szczegóły.
Solidny pakiet łączyłby każdy wynik z jego źródłem. Plik GPX powinien być powiązany z dokładnym skryptem, danymi źródłowymi, parametrami i wykonaniem, które go utworzyły.
Przypomina to prowadzenie przepływu pracy AI z możliwymi do prześledzenia danymi wejściowymi i wynikami. Temat jest inny, ale zasada dokumentowania pozostaje taka sama.
Podstawowym konfliktem w tej historii jest zatem zdolność działania kontra audytowalność. Astra osiągnęła imponujący rezultat, lecz otaczający ją produkt nie pozwolił na pełne zbadanie sposobu jego uzyskania.
OpenStreetMap rodzi pytania dotyczące zasad i bezpieczeństwa
Trasa może być technicznie poprawna, a jednocześnie nieodpowiednia, niebezpieczna lub niezgodna z zasadami regulującymi jej źródła danych.
Wygenerowany wynik opierał się na OpenStreetMap, współtworzonej bazie danych geograficznych, której zasięg i oznaczenia różnią się zależnie od lokalizacji. Jej otwartość umożliwia nietypowe przepływy pracy, ale nie eliminuje niepewności.
Droga lub szlak może istnieć w bazie danych, nie będąc odpowiednim dla każdego biegacza. Ograniczenia dostępu, tymczasowe zamknięcia, stan nawierzchni, oświetlenie, przejścia, prace budowlane i lokalne zagrożenia mogą być nieobecne lub nieaktualne.
Obliczenie na grafie może również wygenerować połączoną pętlę, która wygląda rozsądnie na ekranie, lecz sprawdza się słabo w terenie. Sama łączność nie gwarantuje komfortu ani bezpieczeństwa.
Brak kodu źródłowego uniemożliwia osobom z zewnątrz sprawdzenie, jak agent uwzględnił te czynniki. Nie wiadomo, które klasy dróg były dozwolone ani czy wykluczono tagi prywatnego dostępu.
Nie wiadomo też, czy agent rozpoznał chodniki, ograniczenia dla pieszych, nieutwardzone nawierzchnie, schody, połączenia promowe lub odcinki szlaków o ograniczonym dostępie.
Willison poinformował, że system stworzył dokładnie to, o co prosił. To użyteczny dowód z pierwszej ręki na ukończenie zadania, ale nie stanowi kompleksowej walidacji jakości trasy.
Przykład obejmuje tylko jednego użytkownika, jeden obszar i jedną parę żądanych dystansów. Artykuł nie opisywał testu terenowego, analizy przewyższeń, przeglądu dostępności ani niezależnego porównania.
Etap geokodowania rodzi kolejną obawę, ponieważ dokładny adres domowy jest informacją wrażliwą. Użytkownicy powinni rozumieć, dokąd agent wysyła ten adres i które dzienniki mogą go zachować.
OpenAI podaje, że Work może korzystać z plików, przeglądania internetu i kontekstu zadania zgodnie z uprawnieniami wybranego środowiska. Konta zarządzane mogą również podlegać organizacyjnym ustawieniom przechowywania i nadzoru.
Przywołany opis generowania trasy nie ustala, z którą instancją Nominatim połączył się agent. Nie może więc potwierdzić, jakie dzienniki, limity lub zasady przechowywania miały zastosowanie do tego żądania.
Jeśli agent korzystał z publicznej usługi OpenStreetMap Foundation, znaczenie miałaby polityka Nominatim. Polityka ogranicza intensywne wykorzystanie oraz wymaga identyfikowalnych żądań i odpowiedniego przypisania autorstwa.
Polityka nakłada również ograniczenia na automatycznie generowane, ogólne usługi geokodowania. Pojedyncze prywatne wyszukanie różni się od wdrożenia masowego produktu do wyznaczania tras, lecz agenci muszą rozróżniać te przypadki.
Overpass wiąże się z podobnymi kwestiami operacyjnymi. Jego publiczne serwery obsługują małe projekty, ale mogą zostać przeciążone, zgodnie z wytycznymi Overpass.
Wytyczne zachęcają regularnych lub komercyjnych użytkowników do buforowania żądań, ograniczania zużycia zasobów, korzystania z ekstraktów lub uruchamiania odpowiedniej infrastruktury. Publiczne punkty końcowe są współdzielonymi zasobami, a nie nieograniczonym zapleczem dla agentów.
Możliwy do audytu zapis wykonania pomógłby rozstrzygnąć te kwestie. Mógłby pokazać dokładne punkty końcowe, nagłówki żądań, liczbę zapytań, przypisanie autorstwa i rozmiary odpowiedzi.
Bez takiego zapisu użytkownik nie może potwierdzić, czy agent przestrzegał odpowiednich zasad usług. Gotowe pliki dostarczają niewielu dowodów na to, w jaki sposób pozyskano dane.
Bezpieczeństwo wymaga również przedstawiania tras jako sugestii, a nie zweryfikowanych instrukcji. Biegacz powinien sprawdzić nieznane odcinki i uwzględnić aktualne warunki lokalne, zanim zaufa automatycznie wygenerowanej pętli.
System powinien przedstawiać założenia trasy prostym językiem. Mógłby wskazywać, że wykluczono drogi prywatne, preferowano ścieżki piesze, dopuszczono nieutwardzone szlaki i nie uwzględniono aktualnych danych o zamknięciach.
Takie ujawnienia nie są ozdobnymi zastrzeżeniami. Pomagają użytkownikom zdecydować, czy wynik odpowiada ich potrzebom i czy konieczna jest dalsza weryfikacja.
Agent generujący trasy potrzebuje także sposobu raportowania niepewności. Jeśli tagi mapy są sprzeczne lub status dostępu do szlaku jest niejasny, ta niejednoznaczność powinna zostać zachowana w końcowym rezultacie.
Rezultat Astry pokazuje, że otwarte dane mapowe mogą wspierać zaawansowane zadania osobiste. Brak śladu pokazuje, dlaczego dostęp do otwartych danych nie zastępuje przejrzystego wykonania.
Co powinna zachowywać przejrzysta praca agentów
Kolejnym sprawdzianem dla ChatGPT Work będzie to, czy udane zadania staną się odtwarzalnymi zapisami projektów, a nie jednorazowymi rozmowami.
Najbardziej bezpośrednim sygnałem będzie trwały dostęp do wygenerowanego kodu i poleceń. Użytkownicy powinni móc ponownie otworzyć ukończone zadanie i odzyskać każdy artefakt utworzony podczas jego wykonywania.
Nie wymaga to domyślnego wyświetlania ciągłego wyjścia terminala. Zwarty interfejs mógłby najpierw pokazywać wynik, zachowując kompletny zapis aktywności za kontrolką inspekcji.
Drugim sygnałem będzie pochodzenie przypisane do każdego materiału wynikowego. Plik powinien wskazywać dane wejściowe, narzędzia, przekształcenia i ostrzeżenia związane z jego utworzeniem.
W przypadku zadania GPT-6 Astra dotyczącego tras biegowych informacje o pochodzeniu połączyłyby pliki GPX i GeoJSON z tym samym obliczeniem trasy. Zachowałyby również odpowiednie zapytanie OSM i wygenerowany skrypt Python.
Trzecim sygnałem będzie lepsza obsługa kompresji kontekstu. Skompresowana rozmowa powinna zachowywać możliwe do odzyskania archiwum, nawet gdy model nie przechowuje już aktywnie wszystkich szczegółów.
Agent mógłby przeszukiwać to archiwum, gdy użytkownik pyta, co wydarzyło się wcześniej. Oddzieliłoby to wydajny aktywny kontekst od trwałej historii zadania.
Zmiany te wzmocniłyby deklaracje OpenAI dotyczące przejrzystości bez ujawniania prywatnego rozumowania modelu. OpenAI podaje, że Astra kładzie nacisk na zgodność, granice zadań i bardziej przejrzyste zachowanie podczas pracy delegowanej.
Zapisy operacyjne uczyniłyby te deklaracje weryfikowalnymi na poziomie produktu. Użytkownicy mogliby sprawdzić, czy agent pozostał w zakresie zadania, zamiast polegać wyłącznie na jego podsumowaniu.
Konkurenci tworzący agentów ogólnego przeznaczenia stoją przed tym samym wyzwaniem. Szybsza realizacja zadań i lepsze wyniki w benchmarkach będą miały mniejsze znaczenie, gdy użytkownicy nie mogą zweryfikować wyników o kluczowym znaczeniu dla biznesu.
Deweloperzy już oczekują odtwarzalnych środowisk, historii wersji i dzienników. Pracownicy umysłowi rozwiną podobne oczekiwania, gdy agenci zaczną tworzyć analizy, prezentacje, zbiory danych i zmiany operacyjne.
Interfejs powinien również umożliwiać użytkownikom eksport pełnego pakietu zadania. Taki pakiet mógłby zawierać polecenie, zatwierdzone uprawnienia, skrypty, dzienniki, odniesienia do źródeł, artefakty oraz zwięzłe podsumowanie wykonania.
Pakiet, który można udostępnić, poprawiłby współpracę. Współpracownik mógłby przeanalizować metodę bez odtwarzania całej rozmowy ani ufania zrzutowi ekranu.
Wspierałby również korekty. Gdyby trasa obejmowała nieodpowiedni szlak, użytkownik mógłby wskazać odpowiedzialną regułę i ponownie uruchomić przepływ pracy ze zmienionym ograniczeniem.
Trwałe zapisy sprawiłyby, że praca agentów byłaby kumulatywna. Udana trasa 5K mogłaby stać się punktem wyjścia dla późniejszych żądań dotyczących wzniesień, nawierzchni, oświetlenia lub sezonowych zamknięć.
Bez takich zapisów każde kolejne działanie może stać się nowym wnioskowaniem. Agent może wygenerować inną metodę, przedstawiając ją jako kontynuację pierwotnego zadania.
Nie należy umniejszać podstawowego osiągnięcia. Krótka instrukcja w języku naturalnym pozwoliła w 27 minut stworzyć dwie pętle o określonych dystansach, interaktywną mapę i przenośne pliki geoprzestrzenne.
To wiarygodny przykład agenta ogólnego przeznaczenia koordynującego narzędzia dla konkretnego osobistego celu. Pokazuje, dlaczego gotowe materiały wynikowe mogą mieć większe znaczenie niż płynne odpowiedzi.
Przypadek ten pokazuje również, że jakość wyniku nie może być jedyną miarą sukcesu. Użytkownicy potrzebują trwałych dowodów, gdy proces agenta wpływa na wiarygodność, bezpieczeństwo lub legalność jego pracy.
Przyszłe trasy biegowe GPT-6 Astra należy zatem oceniać według dwóch rezultatów. Czy trasa spełniła żądanie i czy użytkownik może dokładnie odtworzyć sposób jej wygenerowania?
Jeśli OpenAI doda trwałe historie wykonania, pochodzenie artefaktów i możliwe do odzyskania zapisy sprzed kompresji, przykład ten będzie wyglądał jak wczesna luka produktowa. Jeśli tego nie zrobi, ukryta praca stanie się większym obciążeniem, gdy agenci podejmą zadania o wyższej stawce.
Praktyczną odpowiedzią jest prośba o dowody, dopóki zadanie jest jeszcze aktywne. Wraz z końcowym rezultatem należy poprosić o skrypt, źródłowe punkty końcowe, założenia, pliki pośrednie i notatki z weryfikacji.
Ten nawyk nie powinien pozostać konieczny na zawsze. Dojrzały interfejs agenta powinien automatycznie zachowywać te materiały i pozwalać użytkownikowi decydować, kiedy je sprawdzić.
Trasa zadziałała. Kolejnym kamieniem milowym jest uczynienie pracy stojącej za nią tak samo przenośną, możliwą do przeglądu i trwałą jak sam plik GPX.
