Kontrola kosztów agentów: FinOps dla autonomicznego AI

Bo agent to nie jedno wywołanie, lecz pętla: planuje, wywołuje narzędzie, czyta wynik, decyduje i powtarza, często wielokrotnie, zanim jedno zadanie się zamknie. Każde z tych przejść wydaje tokeny, i na rozumowanie modelu, i na ponowne czytanie kontekstu, który niesie dalej, więc rachunek skaluje się z liczbą kroków, a nie z pozorną wielkością pytania. Dwie rzeczy jeszcze go wzmacniają. Wielki kontekst wysyłany ponownie w każdej iteracji mnoży zużycie tokenów przez całą pętlę, a systemy wieloagentowe dokładają na wierzch wiadomości między agentami, gdzie agenci wydają tokeny na rozmowę ze sobą. W rezultacie jedno złożone zadanie potrafi kosztować rzędy wielkości więcej niż pojedyncza odpowiedź, która zdaje się leżeć w jego sercu, a ponieważ ścieżka się zmienia, to samo zadanie może kosztować bardzo różnie z przebiegu na przebieg. Właśnie dlatego koszt musi być monitorowanym sygnałem produkcyjnym dla agentów, nie szacunkiem na kolanie z ceny za token.

Pętle i ponowienia, tuż za nimi ponowne czytanie wielkiego kontekstu w każdej iteracji. Zdrowy agent robi postęp w każdym przejściu; niezdrowy powtarza kroki, ponawia tę samą zawodną akcję albo krąży bez zbieżności, a ponieważ nie zgłasza błędu, potrafi po cichu nabić duży rachunek, zanim ktoś spojrzy na fakturę. Ponowne czytanie kontekstu to cichszy kuzyn: jeśli każda iteracja ponownie wysyła pełną historię i wielki pobrany dokument, płacisz za te tokeny raz za razem, nawet gdy pętla zachowuje się dobrze. Oba są podstępne właśnie dlatego, że nic się nie wywala — agent wygląda na zajętego, a koszt narasta w tle. Kontrole, które je łapią, to wykrywanie pętli, zatrzymujące agenta powtarzającego bez postępu, oraz budżety na zadanie, które ograniczają wydatek pojedynczego przebiegu i bezpiecznie go przerywają po osiągnięciu limitu. Razem zamieniają otwarty najgorszy przypadek w ograniczony.

Dołącz atrybuty tokenów i kosztu do każdego spanu w traces, potem agreguj te dane per zadanie, per agent i per narzędzie, byś widział nie tylko sumę, ale gdzie się koncentruje. Dyscyplina per span ma znaczenie, bo jedna liczba na miesięcznej fakturze nic Ci nie podpowiada; koszt rozbity na kroki mówi, że jedno narzędzie albo jeden zapętlony podagent odpowiada za większość wydatku. Gdy koszt stanie w dashboardach obok opóźnienia i wskaźnika ukończenia, przestaje być niespodzianką sprzed tygodni, a staje się metryką, którą zarządzasz na bieżąco, z alarmami na anomalie i budżetami do egzekwowania. Dlatego koszt jest w gruncie rzeczy problemem obserwowalności: nie skontrolujesz liczby, której nie widzisz, a ten sam tracing, który pozwala zdebugować przebieg, pozwala go też wycenić. W wielu zespołach uczynienie kosztu widocznym jest też tym, co finansuje cały wysiłek obserwowalności, bo finanse rozumieją rozbiegany rachunek szybciej niż inżynierską abstrakcję.

Często tak, jeśli kierujesz ruch według trudności, zamiast używać jednego dużego modelu do wszystkiego, bo wiele z tego, co agent robi w każdej pętli, jest rutynowe — klasyfikacja, ekstrakcja, wybór następnego kroku — i nie potrzebuje Twojego najmocniejszego modelu. Wzorzec to dobór rozmiaru modelu: użyj małego, taniego modelu do częstych, łatwych kroków, a największy zostaw do naprawdę trudnego rozumowania, z jasną regułą, kiedy eskalować. Zrobione dobrze, znacząco tnie koszt, zostawiając jakość end-to-end zasadniczo bez zmian, bo trudne kroki wciąż dostają mocny model. Ryzyka są realne i warte zarządzania: zbyt agresywne zejście w dół potrafi po cichu obniżyć wskaźnik ukończenia, a zła decyzja kierowania może wysłać trudny krok do słabego modelu, więc potrzebujesz gotowych ewaluacji i metryki ukończenia, by wykryć regresje, zanim dotrą do użytkowników. Traktuj to jako optymalizację, którą mierzysz, nie hurtowe przełączenie — zmień kierowanie, potem obserwuj jakość i koszt razem, i tańszą ścieżkę zostaw tylko tam, gdzie trzyma jakość.