Tworzenie agentów AI, którzy przetrwają produkcję

Tworzenie agentów AI to budowanie oprogramowania, w którym model językowy decyduje, jaki krok wykonać, wywołuje prawdziwe narzędzia, aby go wykonać, czyta wynik i decyduje ponownie — aż cel zostanie osiągnięty albo zatrzyma go ustalony limit. Produktem nie jest model, tylko pętla wokół niego. To w niej mieszka inżynieria: co agent może wywołać, jak wracają do niego błędy, jak stan przechodzi między krokami, co dzieje się, gdy zboczy z kursu, i skąd potem wiadomo, czy wykonał pracę. Chatbot odpowiada. Agent działa — i to działanie czyni z tego projekt programistyczny, a nie prompt.

Działający prototyp wąskiego zadania zajmuje zwykle od jednego do trzech tygodni. Doprowadzenie go do stanu, w którym pokazałbyś go klientom, trwa znacznie dłużej — zwykle od dwóch do czterech miesięcy — i prawie nic z tego czasu nie idzie na prompty. Idzie na integracje, które psują się w sposób, z którym model musi sobie poradzić, na zestaw ewaluacyjny wychwytujący regresje, na uprawnienia, na logi umożliwiające debugowanie oraz na ścieżkę przekazania człowiekowi w przypadkach, których agent nie powinien rozstrzygać sam. Zespoły, które budżetują demo, a nie drugi etap, nigdy nie wychodzą poza pilotaż.

Zacznij od najlżejszego narzędzia, które rozwiązuje zadanie. Dla pojedynczego agenta z kilkoma narzędziami SDK dostawcy modelu i własnoręcznie napisana pętla to często całość pracy — i zostawia cię z możliwością debugowania każdego kroku. Po framework orkiestracyjny sięgnij, gdy naprawdę potrzebujesz trwałego stanu, rozgałęzionego sterowania, ponawiania długich kroków albo kilku współpracujących agentów. Kosztem frameworka nie jest API, tylko to, że elementy, które w gorszy dzień musisz obejrzeć najdokładniej, siedzą w cudzej abstrakcji. Cokolwiek wybierzesz, trzymaj prompty, definicje narzędzi i zestaw ewaluacyjny poza frameworkiem, żeby zmiana zajęła dzień, a nie przepisanie całości.

Są dwa koszty i zespoły regularnie planują niewłaściwy. Koszt budowy: wąski agent wewnętrzny to zwykle 8000–30 000 $ pracy inżynierskiej; agent dla klientów, z realnymi integracjami, ewaluacją i monitoringiem, częściej 30 000–120 000 $. Koszt utrzymania: wydatek na tokeny jest zwykle mniejszą pozycją i najłatwiej go obniżyć — kierowanie prostych kroków do tańszego modelu, cache i przycinanie kontekstu często zmniejszają go o połowę. Zapominaną pozycją jest utrzymanie: modele są wycofywane, API się zmieniają, zestaw ewaluacyjny trzeba przepuścić ponownie. Zaplanuj około 15–25% kosztu budowy rocznie.

Ograniczając to, co może zrobić, zamiast liczyć na jego dobre zachowanie. W praktyce: opieraj odpowiedzi na pobranych dokumentach i każ cytować użyte źródło; dawaj narzędziom ścisłe, typowane argumenty i waliduj je przed wykonaniem; pozwól narzędziu uczciwie zwrócić „nie znaleziono” i naucz agenta, że brak wyniku jest dopuszczalnym rezultatem; ogranicz liczbę kroków i wydatek na jedno uruchomienie; a przed wszystkim, czego nie da się cofnąć — płatności, usunięcia, wiadomości do klientów — postaw bramkę akceptacji człowieka. Potem mierz. Zestaw pięćdziesięciu prawdziwych przypadków, także tych niewygodnych, mówi o niezawodności więcej niż jakiekolwiek strojenie promptów.

Wybierz platformę no-code, gdy zadanie jest standardowe, wolumen umiarkowany, a koszt błędnej odpowiedzi niski — kierowanie wewnętrznego FAQ, triaż zgłoszeń, szkice pierwszych odpowiedzi. Naprawdę szybciej prowadzą do wyniku i uczą, czego zadanie faktycznie wymaga. Buduj po swojemu, gdy agent ma sięgać do twoich systemów z realnymi uprawnieniami, gdy przy twoim wolumenie liczy się opóźnienie lub koszt jednostkowy, gdy potrzebujesz własnej ewaluacji i śladu audytowego albo gdy agent jest częścią sprzedawanego produktu. Zwykła droga jest rozsądna: udowodnij przepływ na platformie, a potem przepisz te części, które na to zasłużyły.