Od modelu do agenta: wyposażenie interfejsu Responses API w środowisko komputerowe

Obecnie następuje odejście od modeli, które świetnie radzą sobie z konkretnymi zadaniami, na rzecz z agentów zdolnych do obsługi złożonych procesów. Wprowadzając polecenia do modeli, możesz uzyskać dostęp wyłącznie do wytrenowanej inteligencji. Jednak udostępnienie modelowi środowiska komputerowego pozwala na znacznie szerszy zakres zastosowań, takich jak uruchamianie usług, pobieranie danych z interfejsów API lub generowanie bardziej użytecznych artefaktów, takich jak arkusze kalkulacyjne lub raporty.

Podczas tworzenia agentów pojawia się kilka praktycznych problemów: gdzie umieścić pliki pośrednie, jak uniknąć wklejania dużych tabel do polecenia, jak zapewnić procesowi dostęp do sieci bez koszmaru związanego z bezpieczeństwem oraz jak obsługiwać limity czasu i ponowne próby bez konieczności samodzielnego tworzenia procesu.

Zamiast przerzucać na programistów obowiązek budowania własnych środowisk wykonawczych, stworzyliśmy niezbędne komponenty, aby wyposażyć interfejs Responses API⁠(otwiera nowe okno) w środowisko komputerowe umożliwiające niezawodne wykonywanie rzeczywistych zadań.

Interfejs Responses API od OpenAI, wraz z narzędziem powłoki i hostowaną przestrzenią roboczą kontenera, został zaprojektowany z myślą o rozwiązaniu tych kwestii. Model proponuje kroki i polecenia; platforma uruchamia je w izolowanym środowisku z systemem plików na potrzeby danych wejściowych i wyjściowych, opcjonalną ustrukturyzowaną pamięcią masową (np. SQLite) oraz ograniczonym dostępem do sieci. 

W tym wpisie wyjaśnimy, jak zbudowaliśmy środowisko komputerowe dla agentów i podzielimy się spostrzeżeniami na temat tego, jak wykorzystać je do przyspieszenia, ujednolicenia i zwiększenia bezpieczeństwa procesów produkcyjnych.

Skuteczny proces agenta zaczyna się od zwartej pętli wykonawczej: model proponuje działanie, takie jak odczytanie plików lub pobranie danych za pomocą API, platforma je realizuje, a wynik jest wykorzystywany w kolejnym etapie. Zaczniemy od narzędzia powłoki – najprostszego sposobu, aby zobaczyć tę pętlę w akcji – a następnie omówimy przestrzeń roboczą kontenera, sieć, umiejętności do ponownego wykorzystania i kompresję kontekstu.

Aby zrozumieć narzędzie powłoki, najpierw warto poznać ogólny sposób, w jaki model językowy korzysta z narzędzi: na przykład w celu wywołania funkcji lub interakcji z komputerem. Podczas treningu modelowi pokazuje się przykłady tego, jak używa się narzędzi i jakie są tego efekty, krok po kroku. Pomaga to modelowi nauczyć się decydować, kiedy i jak użyć narzędzia. Kiedy mówimy o użyciu narzędzia, mamy na myśli, że model w rzeczywistości proponuje jedynie wywołanie narzędzia. Samodzielne wykonanie przez niego tego wywołania jest niemożliwe.

Narzędzie powłoki znacznie zwiększa możliwości modelu: wchodzi w interakcję z komputerem za pośrednictwem wiersza poleceń, aby wykonywać szeroki zakres zadań – od wyszukiwania tekstu po wysyłanie żądań API na komputerze. Nasze narzędzie powłoki, oparte na znanych narzędziach systemu Unix, oferuje wszystkie oczekiwane funkcje, a narzędzia takie jak grep, curl i awk są dostępne od razu po uruchomieniu.

W porównaniu z naszym dotychczasowym interpreterem kodu, który obsługuje wyłącznie język Python, narzędzie powłoki umożliwia znacznie szerszy zakres zastosowań, takich jak uruchamianie programów w językach Go lub Java czy uruchamianie serwera NodeJS. Ta elastyczność pozwala modelowi realizować złożone zadania agentowe.

Sam model może jedynie proponować polecenia powłoki, ale w jaki sposób są one wykonywane? Potrzebujemy koordynatora, aby uzyskać dane wyjściowe modelu, wywoływać narzędzia i przekazywać odpowiedź narzędzia z powrotem do modelu w pętli, aż zadanie zostanie ukończone.

Interfejs API Responses służy programistom do komunikacji z modelami OpenAI. W przypadku użycia z narzędziami niestandardowymi interfejs API Responses przekazuje kontrolę z powrotem do klienta, a klient wymaga własnego środowiska testowego do uruchamiania narzędzi. Jednak ten interfejs API może również koordynować współpracę między modelem a hostowanymi narzędziami. 

Gdy interfejs API Responses otrzymuje polecenie, zestawia kontekst modelu: polecenie użytkownika, wcześniejszy stan rozmowy oraz instrukcje narzędzi. Aby wykonywanie polecenia w powłoce zadziałało, musi ono zawierać informację o użyciu narzędzia powłoki oraz wybrany model musi być przeszkolony do proponowania poleceń powłoki – tak jak model GPT‑5.2 i nowsze. Biorąc pod uwagę wszystkie te czynniki, model następnie decyduje o kolejnym kroku. Jeśli wybierze wykonanie polecenia w powłoce, zwraca jedno lub więcej poleceń powłoki do usługi Responses API. Usługa API przekazuje te polecenia do środowiska uruchomieniowego kontenera, strumieniuje z powrotem dane wyjściowe powłoki i przekazuje je do modelu w kontekście kolejnego żądania. Model może następnie przeanalizować wyniki, wydać dodatkowe polecenia lub wygenerować ostateczną odpowiedź. Interfejs Responses API powtarza tę pętlę, dopóki model nie zwróci zakończonej odpowiedzi bez dodatkowych poleceń powłoki.

Gdy interfejs Responses API wykonuje polecenie powłoki, utrzymuje strumieniowe połączenie z usługą kontenera. W miarę generowania danych wyjściowych interfejs API przekazuje je do modelu niemal w czasie rzeczywistym, aby ten mógł zdecydować, czy poczekać na więcej danych wyjściowych, uruchomić kolejne polecenie czy przejść do ostatecznej odpowiedzi.

Model może zaproponować wiele poleceń powłoki w jednym kroku, a interfejs Responses API może je wykonywać równolegle, korzystając z oddzielnych sesji kontenera. Każda sesja strumieniuje dane wyjściowe niezależnie, a API łączy je z powrotem w uporządkowane wyniki narzędzia, tworząc kontekst. Innymi słowy, pętla agenta może równolegle wykonywać takie zadania jak przeszukiwanie plików, pobieranie danych czy weryfikowanie wyników pośrednich.

Gdy polecenie obejmuje działanie na plikach lub przetwarzanie danych, dane wyjściowe powłoki mogą osiągać duże rozmiary i wyczerpać limit kontekstu, nie dostarczając przy tym żadnych użytecznych informacji. Aby temu zaradzić, model określa limit danych wyjściowych na polecenie. Responses API egzekwuje ten limit i zwraca ograniczony wynik, który zachowuje zarówno początek, jak i koniec danych wyjściowych, jednocześnie oznaczając pominiętą treść. Na przykład możesz ograniczyć wynik do 1000 znaków, zachowując początek i koniec:

tekst na początku ... usunięto 1000 znaków ... tekst na końcu

Równoległe wykonywanie zadań i ograniczone dane wyjściowe sprawiają, że pętla agenta jest zarówno szybka, jak i efektywna pod kątem kontekstu, dzięki czemu model może nadal rozumować na podstawie istotnych wyników, nie będąc obciążony surowymi danymi z logów terminala.

Jednym z potencjalnych problemów związanych z pętlami agenta jest to, że zadania mogą być aktywne przez długi czas. Długotrwałe zadania wypełniają okno kontekstu, co ma kluczowe znaczenie dla zapewnienia spójności kontekstowej między turami i agentami. Wyobraźmy sobie agenta wywołującego umiejętność, otrzymującego odpowiedź, dodającego wywołania narzędzi i podsumowania rozumowania – ograniczone okno kontekstu szybko w takiej sytuacji się zapełnia. Aby uniknąć utraty ważnego kontekstu, gdy agent jest aktywny, potrzebujemy sposobu na zachowanie kluczowych szczegółów i usunięcie wszystkiego, co zbędne. Zamiast wymagać od programistów projektowania i utrzymywania niestandardowych systemów do podsumowywania lub przenoszenia stanu, dodaliśmy w Responses API natywną kompresję, zaprojektowaną tak, aby była zgodna ze sposobem działania modelu oraz z tym, jak został on wytrenowany

Nasze najnowsze modele są trenowane tak, aby analizować wcześniejszy stan rozmowy i tworzyć element kompresji, który zachowuje kluczowy wcześniejszy stan w zaszyfrowanej, oszczędnej pod względem tokenów reprezentacji. Po kompresji kolejne okno kontekstu składa się z tego elementu kompresji oraz najbardziej wartościowych fragmentów wcześniejszego okna. Pozwala to na spójne kontynuowanie procesów między oknami, nawet w rozbudowanych, wieloetapowych sesjach opartych na narzędziach. Codex opiera się na tym mechanizmie, obsługując długotrwałe zadania kodowania i iteracyjne wykonywanie narzędzi bez pogarszania jakości.

Kompresja jest albo wbudowana na serwerze, albo dostępna poprzez samodzielny punkt końcowy. Kompresja po stronie serwera umożliwia skonfigurowanie progu, a system automatycznie zarządza czasem kompresji, eliminując potrzebę stosowania złożonej logiki po stronie klienta. To zapewnia nieco większe efektywne okno kontekstu danych wejściowych, co z kolei pozwala na niewielkie przekroczenia tuż przed kompresją, dzięki czemu żądania zbliżające się do limitu mogą być nadal przetwarzane i kompresowane, a nie odrzucane. W miarę rozwoju trenowania modeli OpenAI z każdą kolejną wersją ewoluuje również natywne rozwiązanie do kompresji.

Codex pomógł nam zbudować system kompresji, jednocześnie pełniąc rolę jego wczesnego użytkownika. Gdy jedna instancja napotykała błąd kompresji, uruchamialiśmy drugą, aby to zbadać. W rezultacie Codex uzyskał natywny, skuteczny system kompresji. Ta zdolność narzędzia Codex do analizowania i udoskonalania samego siebie stała się szczególnie interesującym aspektem pracy w OpenAI. Większość narzędzi wymaga jedynie, aby użytkownik umiał z nich korzystać. Codex natomiast uczy się razem z nami.

Przejdźmy teraz do stanu i zasobów. Kontener służy nie tylko do uruchamiania poleceń, ale także stanowi roboczy kontekst dla modelu. W ramach kontenera model może odczytywać pliki, wysyłać zapytania do baz danych i uzyskiwać dostęp do systemów zewnętrznych zgodnie z zasadami polityki sieciowej.

Pierwszą częścią kontekstu kontenera jest system plików do przesyłania, organizowania i zarządzania zasobami. Stworzyliśmy interfejsy API kontenera i pliku⁠(otwiera nowe okno), aby zapewnić modelowi mapę dostępnych danych i pomóc mu wybierać ukierunkowane operacje na plikach zamiast wykonywać generujące szum skanowania o szerokim zakresie.

Powszechnym błędem jest upychanie wszystkich danych wejściowych bezpośrednio w kontekście polecenia. Wraz ze wzrostem ilości danych wejściowych przepełnianie polecenia staje się kosztowne i trudne do przetworzenia przez model. Lepszym wzorcem jest przygotowanie zasobów w systemie plików kontenera i pozwolenie modelowi zdecydować, co otworzyć, przeanalizować lub przekształcić za pomocą poleceń powłoki. Modele, podobnie jak ludzie, lepiej działają na bazie uporządkowanych informacji.

Drugą częścią kontekstu kontenera są bazy danych. W wielu przypadkach sugerujemy, aby programiści przechowywali dane strukturalne w bazach danych w ramach systemu SQLite i wykonywali na nich zapytania. Zamiast kopiować całe arkusze kalkulacyjne do polecenia, można na przykład podać modelowi opis tabel – wykaz kolumn i ich funkcję – i pozwolić mu pobrać te wiersze, których potrzebuje.

Jeśli na przykład zapytasz: „Które produkty zanotowały spadek sprzedaży w tym kwartale?”, model może wykonać zapytanie tylko w zakresie odpowiednich wierszy zamiast skanować cały arkusz. Takie rozwiązanie jest szybsze, tańsze i lepiej skalowalne w przypadku większych zbiorów danych.

Trzecim elementem kontekstu kontenera jest dostęp do sieci, który stanowi kluczową część obciążeń roboczych agenta. Proces roboczy agenta może wymagać pobierania danych w czasie rzeczywistym, wywoływania zewnętrznych interfejsów API lub instalowania pakietów. Jednocześnie zapewnienie kontenerom nieograniczonego dostępu do internetu może być ryzykowne: może skutkować ujawnieniem informacji zewnętrznym witrynom, nieumyślne naruszenie wrażliwych systemów wewnętrznych lub systemów podmiotów trzecich, a także utrudnić ochronę przed kradzieżą danych uwierzytelniających i wyciekiem danych.

Aby rozwiązać te problemy bez ograniczania użyteczności agentów, zbudowaliśmy hostowane kontenery, które korzystają z proxy wychodzącego typu sidecar. Wszystkie wychodzące żądania sieciowe przepływają przez scentralizowaną warstwę zasad, która wymusza listy dozwolonych adresów i kontrole dostępu, jednocześnie zapewniając możliwość monitorowania ruchu sieciowego. W przypadku danych uwierzytelniających stosujemy wstrzykiwanie sekretów w zakresie domeny na etapie wyjścia. Model i kontener widzą tylko symbole zastępcze, natomiast surowe wartości sekretów pozostają poza kontekstem widocznym dla modelu i są stosowane wyłącznie w zatwierdzonych miejscach docelowych. Zmniejsza to ryzyko wycieku, jednocześnie umożliwiając uwierzytelnione wywołania zewnętrzne.

Polecenia powłoki są potężne, ale wiele zadań powtarza te same wieloetapowe wzorce. Agenty muszą za każdym uruchomieniem na nowo odkrywać przebieg procesu – ponownie planować, wydawać polecenia i uczyć się zasad – co prowadzi do niespójnych wyników i marnowania zasobów. Umiejętności agenta⁠(otwiera nowe okno) łączą te wzorce w gotowe do ponownego wykorzystania, modułowe elementy. W praktyce umiejętność to pakiet folderów zawierający plik „SKILL.md⁠(otwiera nowe okno)” (z metadanymi i instrukcjami) oraz wszelkie zasoby pomocnicze, takie jak specyfikacje API i zasoby UI.

Ta struktura naturalnie odpowiada architekturze uruchomieniowej, którą opisaliśmy wcześniej. Kontener zapewnia trwałe pliki i kontekst wykonywania, a narzędzie powłoki zapewnia interfejs wykonywania. Gdy oba elementy są gotowe, model może w razie potrzeby odnajdywać pliki umiejętności za pomocą poleceń powłoki (takich jak „ls” czy „cat”), interpretować instrukcje i uruchamiać skrypty umiejętności – a to wszystko w ramach tej samej pętli agenta.

Udostępniamy interfejsy API⁠(otwiera nowe okno) do zarządzania umiejętnościami na platformie OpenAI. Programiści przesyłają i przechowują foldery umiejętności jako wersjonowane pakiety, które można później pobrać na podstawie identyfikatora umiejętności. Przed wysłaniem polecenia do modelu interfejs API Responses ładuje umiejętność i uwzględnia ją w kontekście modelu. Ta sekwencja jest deterministyczna:

1. Pobierz metadane umiejętności, w tym nazwę i opis.
2. Pobierz pakiet umiejętności, skopiuj go do kontenera i rozpakuj.
3. Zaktualizuj kontekst modelu, dodając metadane umiejętności i ścieżkę kontenera.

Podejmując decyzję, czy dana umiejętność jest istotna, model stopniowo analizuje jej instrukcje i wykonuje jej skrypty za pomocą poleceń powłoki w kontenerze.

Podsumowując: Responses API zapewnia koordynację, narzędzie powłoki umożliwia wykonywanie działań, hostowany kontener zapewnia trwały kontekst środowiska uruchomieniowego, warstwa umiejętności dostarcza logikę procesów nadającą się do ponownego wykorzystania, a kompresja pozwala agentowi działać przez długi czas z niezbędnym kontekstem.

Dzięki tym podstawowym elementom pojedyncze polecenie może rozwinąć się w kompleksowy proces: wyszukanie właściwych umiejętności, pobranie danych, przekształcenie ich w lokalny, ustrukturyzowany stan, wydajne tworzenie zapytań i generowanie trwałych wyników. 

Poniższy schemat pokazuje, jak ten system działa podczas tworzenia arkusza kalkulacyjnego z danych na żywo.

Aby zapoznać się ze szczegółowym przykładem łączenia narzędzia powłoki i środowiska komputerowego w kompleksowych procesach roboczych, sprawdź nasz wpis na blogu dla programistów⁠(otwiera nowe okno) oraz poradnik⁠(otwiera nowe okno), w których krok po kroku opisano pakowanie umiejętności i uruchamianie jej za pośrednictwem interfejsu Responses API.

Jesteśmy ciekawi, co programiści zbudują z tym zestawem elementów podstawowych. Modele językowe mają służyć nie tylko do generowania tekstu, obrazów i dźwięku – będziemy nadal rozwijać naszą platformę, aby była coraz bardziej wydajna w realizacji złożonych, rzeczywistych zadań na dużą skalę.