Projektowanie systemów agentowych: kompletny przewodnik

Projektowanie konwencjonalnego systemu informatycznego to pytanie o funkcjonalność: jakie są wejścia, jakie wyjścia, jaki model danych, gdzie są granice. Projektowanie systemu agentowego to pytanie o zachowanie: pod jakimi warunkami agent działa na własną rękę, skąd wie, że się myli, co go zatrzymuje, gdy wpada w spiralę, i co po sobie zostawia, by człowiek mógł zrekonstruować, co się stało. Artefakty są różne, bo różne są tryby awarii — zwykły system zawodzi przez wywrócenie się, agentowy zawodzi przez pewne siebie robienie złej rzeczy na skalę.

Ta zmiana to cała dyscyplina. Poniżej praktyczny po niej przewodnik, zbudowany wokół czterech pytań projektowych, na które każdy system agentowy musi odpowiedzieć, zanim tknie produkcję.

Zaczynaj od małego: autonomię się zarabia, a nie nadaje

Najczęstszym błędem jest nadanie agentowi szerokiej autonomii pierwszego dnia, bo demo dobrze wyglądało. Dyscyplina jest przeciwna: zaczynaj od najwęższej autonomii, która jest jeszcze użyteczna, i rozszerzaj ją tylko w miarę, jak system zdobywa zaufanie.

Konkretnie oznacza to, że pierwsza wersja agenta powinna działać w ciasnym pudełku — mały zbiór dozwolonych akcji, w miarę możliwości głównie do odczytu, z człowiekiem zatwierdzającym wszystko, co ma konsekwencje. W miarę gromadzenia dowodów, że zachowuje się poprawnie na realnych wejściach, poszerzasz pudełko: więcej akcji, mniej zatwierdzeń, większy promień rażenia. Każde rozszerzenie jest decyzją popartą danymi, a nie domyślnym ustawieniem, z którym wyszedłeś.

To odwzorowuje się wprost na to, czego pole już nauczyło się o pętlach: własne dane Anthropic pokazują, że programiści w pełni delegują tylko 0–20% zadań nawet przy zdolnych agentach, bo zaufanie zarabia się powoli. Projektowanie pod autonomię stopniowaną to nie nieśmiałość — to jedyna droga, która nie wybucha za pierwszym razem, gdy agent napotka wejście, którego nie przewidziałeś. Operacyjną wersję tego argumentu postawiliśmy w projektowaniu pętli agentowych, które działają, gdy śpisz: autonomia, którą dajesz pętli bez nadzoru, powinna być dokładnie tak szeroka, jak silne są twoje guardrails — i ani trochę szersza.

Logi decyzji: jeśli nie umiesz tego zrekonstruować, nie możesz temu ufać

Zwykły system loguje zdarzenia — żądania, błędy, przejścia stanów. System agentowy musi logować decyzje: nie tylko „agent wywołał API zwrotu”, ale „agent zdecydował się wydać zwrot, bo wywnioskował, że klient się kwalifikuje, przeczytawszy te trzy wiadomości i zważywszy je w ten sposób”. Rozumowanie to ta część, której potrzebujesz, bo to w rozumowaniu agenty błądzą.

Log decyzji rejestruje dla każdej brzemiennej w skutki akcji: co agent próbował zrobić, jaki miał kontekst, jakie opcje rozważał, dlaczego wybrał tę, którą wybrał, i co się stało. To różnica między incydentem, który zdiagnozujesz w dziesięć minut, a takim, w który wpatrujesz się przez dzień. Gdy agent robi coś zdumiewającego, log decyzji to jedyna rzecz, która mówi ci, czy to był zły wniosek, zły wynik narzędzia, czy zła specyfikacja — a te mają zupełnie różne naprawy.

Obserwowalność to funkcja, a nie refleksja po fakcie

W zwykłym systemie monitoring można doczepić po starcie. W systemie agentowym obserwowalność jest częścią projektu, bo zachowanie systemu jest emergentne i nie da się go przewidzieć z samego kodu. Jeśli nie widzisz, co robią twoje agenty — zbiorczo i indywidualnie — lecisz na ślepo nad systemem, który podejmuje autonomiczne akcje.

Pierwszoklasowa obserwowalność dla agentów oznacza kilka konkretnych rzeczy:

Śledzenie na poziomie akcji — każde wywołanie narzędzia, z wejściami, wyjściami i kontekstem decyzyjnym, który je wytworzył, możliwe do odpytania po fakcie.
Pulpity zachowań zbiorczych — co agenty robią w tysiącach uruchomień? Które akcje gwałtownie rosną? Gdzie najczęściej żądana jest zgoda? Dryf ujawnia się w ujęciu zbiorczym na długo, zanim którekolwiek pojedyncze uruchomienie wygląda źle.
Śledzenie wyników — nie tylko „czy akcja się udała”, ale „czy była właściwa”, mierzone wobec tego, jaki tylko grunt prawdy zdołasz uzyskać. Agent, który wykonuje złe zadanie ze statusem 200, to niebezpieczny przypadek, jaki monitoring-jako-refleksja-po-fakcie przeoczy.

To ten sam punkt, który wciąż stawiamy, że harness jest produktem. Model generuje; system wokół niego — w tym ta część, która obserwuje — jest tym, co czyni zachowanie godnym zaufania. Obserwowalność to nie narzut operacyjny. To organ zmysłu systemu autonomicznego.

Guardrails, bezpieczniki i limity iteracji

Ostatnie pytanie projektowe jest najbardziej dosadne: co zatrzymuje agenta, gdy schodzi na manowce? Generowanie jest tanie i szybkie, co znaczy, że źle zachowujący się agent produkuje szkody też tanio i szybko. Mechanizmy, które go powstrzymują, muszą być wprojektowane, a nie dodane po pierwszym incydencie.

Guardrails ograniczają to, co agentowi wolno robić — twarde limity na akcje, wydatki, zakres i operacje niszczące, egzekwowane przez system, a nie wypraszane w promptcie. Guardrail, który model potrafi sobie wygadać, nie jest guardrailem.
Bezpieczniki zatrzymują agenta, gdy zaskoczy sygnał zagrożenia — powtarzające się awarie, anomalne wydatki, skok wskaźnika błędów, akcja poza oczekiwanymi granicami. Jak ich elektryczny imiennik, zawodzą bezpiecznie: w razie wątpliwości zatrzymaj się i eskaluj do człowieka.
Limity iteracji ograniczają pętlę. Agent, który może próbować w nieskończoność, czasem będzie próbował w nieskończoność — paląc budżet i pogłębiając błędne podejście. Twardy limit iteracji zamienia awarię nieskończoną w skończoną, możliwą do naprawienia.

To nie pesymizm. To właśnie czyni optymizm na nasz koszt dostępnym. Jak argumentowaliśmy w zła pętla szybciej wysyła zły kod, prędkość systemów autonomicznych tnie w obie strony: ta sama pętla, która dostarcza funkcje przez noc, przez noc dostarcza pomyłki, o ile coś nie jest zaprojektowane, by je wyłapać. Guardrails i bezpieczniki są tym czymś.

Dlaczego to inżynieria o wysokiej dźwigni dla Azji Południowo-Wschodniej

Oto część, która liczy się dla regionu. Projektowanie systemów agentowych to przenośna, wolna od GPU inżynieria o wysokiej dźwigni — a ten profil pasuje do programistów Azji Południowo-Wschodniej idealnie. Żadna z czterech powyższych dyscyplin nie wymaga klastra GPU w skali frontiera ani setek milionów kapitału. Wymagają starannego myślenia systemowego: jak zawęzić autonomię, jak oprzyrządować zachowanie, jak budować mechanizmy, które zawodzą bezpiecznie. To inwestycja w umiejętności, a nie w kapitał — ta sama trwała zdolność, którą — jak wciąż twierdzimy — region powinien budować.

A popyt na nią jest lokalny w równym stopniu co globalny. W miarę jak agenty wchodzą do kambodżańskich banków, usług publicznych i platform rolniczych, ktoś musi zaprojektować autonomię, logi decyzji, obserwowalność i bezpieczniki dla tamtych systemów — z ich konkretnymi regułami, językami i trybami awarii. Frontierowe laboratorium wynajmie ci model. Nie zaprojektuje bezpiecznego, obserwowalnego, dobrze ograniczonego systemu agentowego, który rozwiązuje problem nigdy przez nie niewidziany. Ta praca projektowa jest przenośna przez każdą domenę i każdy rynek, i jest dokładnie tym rodzajem inżynierii, który mały, bystry zespół może wziąć na własność.

Agent jest teraz łatwą częścią — zdolnego wynajmiesz od tokena. System, który decyduje, kiedy agent działa, obserwuje, co robi, i zatrzymuje go, gdy się myli: to jest inżynieria, i to ona jest pracą wartą dobrego wykonania.