W jaki sposób API agentów OpenAI zmienia ekonomikę pracy z wykorzystaniem sztucznej inteligencji

API Agents firmy OpenAI została stworzona do uruchamiania agentów chmurowych przez długie sesje, wyposażonych w narzędzia, środowiska testowe, pliki, mechanizmy obsługi kontekstu oraz podagenty pracujące równolegle. Agent może przeanalizować problem, uruchomić kod, przekazać zadanie innym, przechowywać wyniki pośrednie i kontynuować pracę aż do jej zakończenia.

To zmienia nie tylko sposób, w jaki programiści tworzą agenty, ale także sposób, w jaki firma powinna obliczać ich koszt.

Jedna prośba może teraz uruchomić łańcuch operacji: wywołań modeli, narzędzi, działań w środowiskach testowych, prób ponownych, przechowywania wyników oraz zatwierdzeń przez ludzi. Tokeny nadal pojawiają się na fakturze, ale już nie wskazują, ile naprawdę kosztowała praca. Jednostką, którą należy śledzić, jest ukończone zadanie: poprawne, możliwe do odzyskania, poddawalne audytowi i warte tyle, ile kosztowało jego stworzenie.

Prośba nie jest już jednostką pracy

Zwykłe wywołanie modelu ma wyraźne ramy. Aplikacja wysyła dane wejściowe, model zwraca wynik, a aplikacja może kontynuować swoją pracę.

API Agents zostało zaprojektowane do zupełnie innego rodzaju działania. Agent otrzymuje cel i decyduje, jak go osiągnąć. Załóżmy, że poprosimy go o zbadanie wzrostu błędów typu 5xx:

Określ przyczynę niezwykłego wzrostu błędów w service-api w ciągu ostatnich 30 minut i zaproponuj bezpieczne rozwiązanie.

Konwencjonalny asystent opisałby, w jaki sposób inżynier mógłby to zbadać. Agent połączony z odpowiednimi systemami może od razu zacząć działać. Sprawdza najnowsze wdrożenia, analizuje logi aplikacji, porównuje wersje zależności, obserwuje metryki infrastruktury, zleca oddzielne analizy, uruchamia kod diagnostyczny, przechowuje dowody i czeka na zatwierdzenie przed jakimikolwiek zmianami.

Użytkownik widzi jedną prośbę. System przeprowadził cały proces pracy.

Praktyczny przewodnik OpenAI dotyczący tworzenia agentów nazywa to „wykonywaniem”: pętlą, która trwa, dopóki agent nie ukończy zadania, nie wygeneruje końcowego wyniku, nie napotka błędu lub nie osiągnie ustalonego limitu. Koszt narasta wewnątrz tej pętli.

Czas wykonywania ma ukrytą rachunek

Tokeny są częścią rachunku. To po prostu ta część, którą najłatwiej zauważyć.

Z powrotem do incydentu w produkcji. Najpierw agent pobiera najnowsze wskaźniki błędów z narzędzia monitoringu, następnie czyta historię wdrożeń, a potem przeszukuje logi. Każda z tych operacji ma swoją cenę, opóźnienie, zestaw uprawnień oraz własny sposób awarii.

Następnie narzędzie do logowania zwraca 500 rekordów. Brzmi to pomocnie, dopóki nie zobaczymy, co dzieje się dalej. Rekordy te muszą zostać przeniesione, przetworzone i umieszczone w kontekście modelu. Większość z nich jest nieistotna, a model traci czas na analizowanie niepotrzebnych danych, zanim znajdzie te pięć zdarzeń, które wyjaśniają incydent.

Dlatego projektowanie narzędzia to w rzeczywistości projektowanie kosztów. Narzędzie wyszukiwania, które zwraca krótkie, ustrukturyzowane podsumowanie, może być tańsze i bardziej niezawodne niż takie, które pokazuje każdy odpowiadający rekord. Odpowiedzią API jest wyszukiwanie narzędzi w połączeniu z programowym wywoływaniem narzędzi, co umożliwia pokazywanie definicji narzędzi tylko wtedy, gdy jest to konieczne, oraz filtrowanie lub łączenie wyników przed ich dostarczeniem do modelu.

Ta sama logika dotyczy również wykonywania w środowisku sandbox. Skrypt diagnostyczny zużywa zasoby CPU, pamięci, przestrzeni dyskowej, czas na instalację pakietów, a może także dostęp do sieci. Jeśli generuje raport lub zbiór dowodów, te pliki muszą zostać przechowane, skatalogowane, przeanalizowane lub zachowane.

Długotrwałe działanie agenta generuje również coś więcej niż tylko tekst. Podczas badania incydentu dowody stanowiące podstawę diagnozy mogą mieć większe znaczenie niż pisemny podsumowanie. W pracy nad kodem plik z poprawkami jest jednym z elementów wyniku, natomiast wyniki testów i analiza zależności mogą być równie cenne.

Niewielki przykład SDK agenta pokazuje, gdzie znajduje się granica wykonywania:

from agents import Agent, Runner, function_tool
@function_tool
def get_error_rate(service: str, minutes: int = 30) -> str:
    """Return the recent error rate for a service."""
    return f"{service}: 8.4% errors over {minutes} minutes"
investigator = Agent(
    name="Incident investigator",
    instructions=(
        "Investigate the incident, use evidence, and recommend "
        "the safest next action. Do not change production state."
    ),
    tools=[get_error_rate],
)
result = Runner.run_sync(
    investigator,
    "Investigate the elevated 5xx rate in service-api."
)

Funkcja jest mała. Ekonomia tego procesu nie jest. Wszystko to zależy od agenta: od tego, czy zostanie on wezwany, czy po raz drugi, jak zostaną odczytane jego wyniki oraz czy potrzebne jest inne narzędzie lub zatwierdzenie człowieka.

Niezawodność, kontrola i akceptacja definiują sukces

SDK dostarcza elementy niezbędne do działania tego mechanizmu: agenty, narzędzia, procedury przekazywania danych, sesje, zasady bezpieczeństwa oraz funkcje śledzenia. Są one ważne, ponieważ rzeczywiste procesy pracy rzadko kończą się sukcesem przy pierwszej próbie.

Zapytanie do dziennika może zostać przerwane z powodu czasu oczekiwania, więc agent próbuje ponownie. Drugie zapytanie działa, ale zwraca niekompletne dane. Agent przepisuje zapytanie, pobiera większy zbiór danych i prosi specjalistycznego agenta o przeanalizowanie historii implementacji. Ostatecznie dochodzi do rozwiązania problemu.

Dla użytkownika agent zakończył zadanie. Z ekonomicznego punktu widzenia zadanie to obejmowało również nieudane próby, dodatkowe iteracje modelu, większą liczbę wywołań narzędzi oraz dłuższy czas trwania procesu.

Ponawianie prób nie jest automatycznie marnotrawstwem. Ponowna próba, która pozwala przezwyciężyć tymczasową awarię, może być właśnie tym, co czyni agenta niezawodnym. Problem pojawia się, gdy te ponowne próby są łączone w jedną ogólną liczbę sukcesów.

Agenci równoległe zamieniają czas na koszty

API może rozdzielić złożone zadania pomiędzy podagentami działającymi równocześnie. Badanie incydentu może przekazać jednemu specjaliście historię wdrażania, drugiemu błędy aplikacji, a trzeciemu zmiany w zależnościach, podczas gdy koordynator łączy ich ustalenia.

Czas mierzony zegarem może się skrócić, ponieważ wszystko działa jednocześnie. Łączna kwota może jednak wzrosnąć, ponieważ trzeba będzie zapłacić za kilka oddzielnych kontekstów modeli, wiele łańcuchów wywołań narzędzi, koordynację, krok syntezy, a także, co dość prawdopodobne, za dwukrotne przetwarzanie tych samych danych.

Dlatego systemy wieloagentowe przypominają systemy rozproszone z modelami językowymi w obiegu. Koordynator pełni rolę planisty, specjaliści są pracownikami, narzędzia zewnętrzne to usługi, a pliki i bazy danych stanowią wspólny stan. Pojawiają się typowe problemy: częściowe awarie, ponawiane próby, niespójny stan, powtarzająca się praca, ograniczenia konkurencji oraz niejasne przypisywanie kosztów. Więcej agentów nie oznacza automatycznie lepszego rozumowania. Paralelizm powinien być uzasadniony sposobem strukturyzacji zadania oraz tym, ile jest warte czas.

Akceptacja to linia mety

Proces generowania może się zakończyć na długo przed zakończeniem rzeczywistej pracy. W przypadku zgłoszenia wsparcia oznacza to, że problem klienta został rozwiązany bez niepotrzebnego eskalowania. W zadaniu programistycznym może to oznaczać, że testy przeszły pomyślnie, spełniono standardy przeglądu i zmiana została włączona do kodu. W reagowaniu na incydenty może to oznaczać, że diagnoza została potwierdzona dowodami i doprowadziła do bezpiecznego złagodzenia skutków. Wynikającą z tego miarą jest:

cost per accepted task =
    total execution cost / tasks accepted without rework

Jeśli agent odpowiada w dziesięć sekund, a osoba poświęca następnie dziesięć minut na naprawę, to odpowiedź w dziesięć sekund nie była najtańszym rozwiązaniem. Była to jedynie najtańsza próba.

To, że ktoś sprawdza wynik, nie oznacza, że automatyzacja zawiodła. W przypadku prac o wysokim ryzyku akceptowalność automatyzacji może zależeć właśnie od formalnego zatwierdzenia. Chodzi o to, aby wymagało to jak najmniejszego wysiłku ludzkiego, przy jednoczesnym zachowaniu rzeczywistej kontroli przez człowieka.

SDK oferuje zasady dotyczące wejścia, wyjścia oraz narzędzi, a jego dokumentacja oddziela sprawdzania na poziomie agenta od tych na poziomie narzędzi: konfiguracje z delegowanymi specjalistami mogą wymagać kontroli operacji pojedynczych funkcji-narzędzi oraz operacji MCP. Zasady te wymagają wysiłku i czasami dodatkowych wywołań modeli. Mogą one również zapobiec znacznie większym kosztom wynikającym z błędnych działań, ujawnienia danych, naruszeń zasad lub problemów regulacyjnych. Wyjście staje się ukończonym zadaniem dopiero po sprawdzeniach jakości i odpowiednim stopniu kontroli ludzkiej.

Od śladów do wartości biznesowej

Każde nowe narzędzie rozszerza możliwości agenta. Równocześnie powiększa uprawnienia systemu, opóźnienia, możliwe błędy oraz wymagania dotyczące zarządzania.

API obsługuje funkcje niestandardowe, wbudowane narzędzia oraz serwery MCP. Standard MCP ujednolica sposób, w jaki aplikacje AI łączą się z zewnętrznymi narzędziami, zasobami i poleceniami. To zmniejsza trudności integracyjne, ale nie czyni narzędzia zdalnego automatycznie godnym zaufania. Specyfikacja MCP ostrzega, że opisy i adnotacje narzędzi pochodzących z niepewnych serwerów nie powinny być automatycznie uznawane za wiarygodne, i zaleca widoczne wywoływanie narzędzi oraz ludzką aprobatę dla wszystkich operacji. Zdalna autoryzacja rodzi dodatkowe problemy, takie jak weryfikacja grupy docelowej tokena, bezpieczne przechowywanie tokenów, zastosowanie PKCE oraz zapobieganie atakom typu confused-deputy. Każda dodana funkcjonalność tworzy nowe granice w zakresie autoryzacji, audytu i zarządzania.

Ślady to dane księgowe

Ostateczna odpowiedź niewiele ujawnia na temat sposobu jej uzyskania. Nie można zobaczyć, jakie narzędzia zostały przeanalizowane, ile z nich działało, czy jakiś podagent się zepsuł, ani co skłoniło do włączenia danej osoby.

SDK dostarcza śledzenie, które obejmuje generacje, wywołania narzędzi, przekazywanie zadań, zasady bezpieczeństwa oraz własne zdarzenia. Śledzenie jest zazwyczaj wprowadzane jako narzędzie do debugowania, ale stanowi również system rozliczeniowy. Śledzenie może ujawnić, że to jedno narzędzie powoduje większość opóźnień, że proces pracy ciągle powtarza tę samą wyszukiwankę lub że pewny wybór modelu zapewnia wyższą akceptację przy mniejszej liczbie prób. Bez śledzenia zespoły optymalizują średnie wartości, natomiast dzięki niemu mogą optymalizować poszczególne etapy procesu pracy.

Karta wyników powinna łączyć dane dotyczące realizacji z danymi wynikowymi: koszt każdego przyjętego zadań wraz z informacją o liczbie iteracji modelu i wywołań narzędzi, czas spędzony w środowisku testowym, częstotliwość ponawiania prób oraz częstotliwość ich powodzenia, a także koszty przeróbek, czas poświęcony na przeglądanie przez recenzentów, sytuacje eskalacji oraz wartość przyniesiona. Dokładny interfejs analityczny zależy od procesu pracy. Zespół obsługi klienta może być zainteresowany przypadkami zamkniętymi bez eskalacji, zespół platformy – incydentami złagodzonymi, a zespół produktowy – ochroną przychodów lub oszczędzeniem czasu pracowników. To, co się zmienia, to to, czym dokonujemy dzielenia.

Decyzja strategiczna

Organizacje nie powinny zaczynać od pytania, jak uczynić agenta tańszym za każde wywołanie. Najpierw należy zadać trudniejsze pytanie:

Czy ten agent jest w stanie w wystarczająco niezawodny sposób radzić sobie z tym rodzajem zadań, aby całkowity koszt był niższy od kosztu obecnego procesu?

Aby to osiągnąć, potrzebny jest uczciwy punkt odniesienia dla obecnego procesu, obejmujący czas pracy personelu, czekanie w kolejkach, wielokrotne przekazywanie zadań, infrastrukturę, błędy i konieczność ich poprawki, utracone możliwości oraz wysiłki związane z przestrzeganiem norm. Agent kosztujący 2 dolary za przyjęte zadanie może stanowić doskonałą inwestycję, gdy istniejący proces kosztuje 20 dolarów. Agent kosztujący 0,10 dolara za próbę może okazać się niewystarczający, jeśli tylko połowa jego wyników jest przyjmowana, a każda awaria wymaga interwencji człowieka.

Rozsądny plan optymalizacji zaczyna się od najprostszego systemu, który potrafi sfinalizować zadanie. Wykorzystuj mniejsze modele do kierowania, filtrowania lub prostego weryfikowania, a przechodź do bardziej zaawansowanych, gdy potrzebne jest głębsze rozumowanie. Spraw, aby narzędzia zwracały zwięzłe, ustrukturyzowane wyniki. Paralizuj tylko niezależne zadania. Weryfikuj podjęte działania. Przechowuj wystarczająco dużo dowodów, aby umożliwić przegląd i naprawę sytuacji.

SDK okazuje się przydatne, gdy sam silnik wykonawczy musi zarządzać kolejnościami działań, narzędziami, sesjami, przenoszeniem obowiązków, zasadami bezpieczeństwa lub koordynacją pomiędzy agentami. API Responses pozostaje odpowiednie, gdy zespół woli samodzielnie kontrolować cały proces i zarządzać stanem. To wybór o charakterze architektonicznym, ale ma również konsekwencje finansowe.

Mierz pracę, a nie słowa

API Agents ułatwia tworzenie agentów, które mogą działać w różnych narzędziach, środowiskach, sesjach oraz z podagentami, a SDK dostarcza elementy na poziomie aplikacji do ich koordynacji, ochrony za pomocą zasad bezpieczeństwa oraz analizy poprzez ślady działania. Razem wskazują one na inny sposób myślenia o ekonomii sztucznej inteligencji.

Złożona prośba jest jedynie punktem wejścia, a nie jednostką rozliczeniową. Jednostką jest ukończony zadań, takie, które można uznać za poprawne, odzyskać w przypadku błędu, przeanalizować później oraz uzasadnić pod względem kosztów. Cena za token pozostaje przydatna jako pojedynczy pozycja rachunku. Wszystko inne – narzędzia, obliczenia, przechowywanie, próby ponowne, opóźnienia, bezpieczeństwo oraz uwaga ludzka – znajduje się w innych pozycjach rachunku.

Najlepsze systemy agentów nie będą tymi, które wytworzą najmniej tokenów. Będą to te, które wykonają najcenniejszą pracę przy rozsądnej całkowitej cenie.

Literatura pokrewna

• Budowanie systemów RAG, które wytrzymują w produkcji: od pobierania danych do możliwości obserwacji — Od dzielenia tekstu na fragmenty i hybrydowego wyszukiwania po ponowne sortowanie wyników, kontrolę dostępu, zestawy oceny i śledzenie: warstwy, które odróżniają demonstrację systemu RAG od systemu produkcyjnego.
• Rozumowanie na podstawie drzewa dokumentów zamiast wyszukiwania wektorów — PageIndex tworzy hierarchiczną indeksację, umożliwiając modelom językowym nawigację po niej bez konieczności dzielenia tekstu na fragmenty ani tworzenia wektorów reprezentacji. Jak to działa, wyniki w testach FinanceBench oraz kiedy należy go stosować.

GPT-6 Astra dla rozwojowców: Użytkowanie na komputerze, ceny i zmiany w API — Co może robić GPT-6 Astra poza czatowaniem, jak wywoływanie narzędzi wpływa na kod API oraz jak porównuje się z Claude i Gemini przy przygotowaniu do stanowisk w dziedzinie sztucznej inteligencji.