Dziewięć filarów architektonicznych dla systemów sztucznej inteligencji typu agentic o jakości produkcyjnej
Naucz się schematu architektury opartej na dziewięciu filarach – obejmującego sieci zero trust, warstwy danych oraz mechanizmy wiążące dowody – służącego do budowy systemów sztucznej inteligencji typu agentic o możliwościach audytowalnych i na poziomie korporacyjnym.
Luka między wersją demonstracyjną a produkcyjną, o której nikt nie mówi
Budowa prototypu agenta AI w czasie weekendu jest prosta.
Połącz model językowy z pętlą wywoływania narzędzi, podłącz go do magazynu wektorów, dodaj interfejs czatowy – i nagle masz coś, co wygląda imponująco w demonstracji. Kierownictwo jest zachwycone, inżynierowie pełni energii. Ktoś zapisuje na tablicy „pilotaż Q3”.
Następnie, gdy system zostaje wdrożony, pojawia się rzeczywistość. Prawie każda organizacja napotyka te same problemy, w innej kolejności:
Agent wypłaca zwrot w niewłaściwej kwocie — ponieważ nikt nie wyznaczył jasnej granicy pomiędzy tym, co decyduje sztuczna inteligencja, a tym, co opiera się na stałej, wykonywalnej logice. Audyt bezpieczeństwa blokuje uruchomienie — ponieważ dane klientów były potajemnie przekazywane przez zewnętrzną API do wgrzania treści. Ktoś z działu compliance pyta, dlaczego system podał określoną odpowiedź kilka miesięcy temu — a nie ma sposobu na odtworzenie toku rozumowania. Skrypt agenta staje się niemożliwy do modyfikacji — ponieważ projektowanie zapytań, reguły biznesowe oraz integracja API są ze sobą splątane w jednym pliku. Wynik zmienia się po rutynowym ponownym indeksowaniu — i nikt nie może odtworzyć tego, co asystent powiedział w poprzednim miesiącu.
Nieprzyjemna rzeczywistość jest taka:
Wybór modelu nigdy nie był trudnym elementem. Trudne jest zbudowanie systemu wokół tego modelu.
System agentowy to nie tylko cienka warstwa sztucznej inteligencji przymocowana do skryptów. To zasadniczo deterministyczny system korporacyjny, który przypadkowo zawiera rdzeń rozumowania probabilistycznego — i wymaga tej samej dyscypliny inżynieryjnej, jaką zastosowałbyś w platformie płatniczej lub infrastrukturze bankowości core.
Ta seria przedstawia kompletny plan architektoniczny budowy takiego systemu. Jest on zorganizowany wokół dziewięciu kluczowych decyzji projektowych — dziewięciu filarów — które każda platforma agentowa klasy produkcyjnej musi prawidłowo wdrożyć jednocześnie, ponieważ gdy jedna zawiedzie, pozostałe również mają tendencję do awarii.
Nasz przykład: Aurora Bank
Architektura omawiana w streszczeniach rzadko się sprawdza w praktyce. Dlatego w ramach tej serii oprzemy każdą koncepcję na konkretnym, choć fikcyjnym, scenariuszu:
Aurora Bank to bank detaliczny średniej wielkości zatrudniający 4 000 pracowników. Wprowadzają oni "Aurora Assistant" – platformę opartą na agentach, zaprojektowaną do: — odpowiadania pracownikom na pytania dotyczące polityk i wymogów prawnych, — wspierania procesowania pożyczek (pobierania dokumentów, weryfikacji danych, sporządzania decyzji), — a także zarządzania zadaniami w obszarze obsługi klienta, takimi jak zwroty pieniędzy, sprawdzanie kont i kierowanie zgłoszeniami.
Ograniczenia, pod którymi funkcjonuje Aurora, są identyczne z tymi, z którymi borykają się większość rzeczywistych przedsiębiorstw:
- Dane osobowe klientów nie mogą opuścić własnej infrastruktury banku.
- Każda automatyczna decyzja musi być wyjaśnialna dla organu nadzorczego na jego żądanie.
Pamiętaj o tych pięciu ograniczeniach podczas dalszej lektury — każdy z dziewięciu filarów został stworzony właśnie po to, by radzić sobie z takimi ograniczeniami.
Pięć zasad kierujących
Zanim przejdziemy do samych filarów, przydatne jest zrozumienie leżącej u ich podstaw filozofii:
- Traktuj model jako jeden z wielu komponentów, a nie jako samą architekturę. Modele są wymieniane co kilka miesięcy; twoja architektura musi przetrwać te zmiany.
- Zachowuj wewnętrzne rozumowanie probabilistyczne, ale spraw, by granice były deterministyczne. LLM może myśleć swobodnie, ale działania muszą przebiegać według ustalonego kodu.
- Zadbaj o to, by każde działanie tworzyło zapis. Jeśli nie możesz ponownie wykonać decyzji, nie będziesz mógł jej później obronić.
- Izoluj komponenty według poziomu zaufania i moderuj każdą prośbę o dostęp. Agenci są zdolni, i to właśnie dlatego stanowią ryzyko — celowo kontroluj to ryzyko.
- Buduj tak, jakby miała nastąpić audyt i jakby o 3 rano ktoś miał do ciebie zadzwonić. Prędzej czy później obie rzeczy się wydarzą.
A teraz przejdźmy po kolei przez każdy z tych elementów — co oznaczają, dlaczego właśnie ta struktura jest odpowiednia, ilustrujący ją diagram, konkretny przykład oraz konsekwencje pominięcia tego elementu.
Eлемент 1 — Architektura logiczna: Dlaczego sześć warstw jest właściwe
Pytanie jest tutaj proste: jakie są podstawowe elementy składowe systemu i która warstwa odpowiada za jakie zadanie?
Platforma agentowa składa się z sześciu logicznych warstw.
Dlaczego sześć, a nie trzy lub dziewięć?
Tradycyjny model trzech warstw — prezentacyjna, logiczna, danych — pomija dokładnie te elementy, które czynią system agentowy wyjątkowym: orkiestrację, wybór modelu, integrację narzędzi oraz granice zaufania. Z drugiej strony dzielenie wszystkiego na dziewięć oddzielnych elementów może prowadzić do rozdzielenia funkcjonalności, które w rzeczywistości powinny pozostać razem.
Sześć okazuje się być minimalną liczbą warstw, w których każda ma jedno zadanie, jednego odpowiedzialnego i jeden powód do zmiany. Można to sprawdzić, zadając pytanie dotyczące każdej warstwy: czy ta warstwa może ulec zmianie sama, bez konieczności zmieniania wszystkich pozostałych warstw jednocześnie?
- Szczegół warstwy doświadczenia (L1) stale się zmienia – nowe interfejsy, nowe kanały, nowe wymagania front-endu.
- Orchestracja (L2) zmienia się wraz z każdym nowym przypadkiem użycia, który dodajesz.
- Rozumowanie (L3) zmienia się za każdym razem, gdy staje się dostępny silniejszy model, więc musi być wymienialny bez wpływu na inne elementy.
- Integracja (L4) zmienia się wtedy, gdy firma łączy nowy system.
- Dane (L5) zmieniają się powoli same z siebie, ale reguły zarządzania nimi ewoluują wraz z rozwojem przepisów.
- Zarządzanie (L6) funkcjonuje jako element przenikający wszystkie warstwy, a nie jako najniższa warstwa, ponieważ kwestie identyfikacji, audytu, oceny, ograniczeń oraz kontroli kosztów muszą dotyczyć każdej innej warstwy, a nie być ograniczone tylko do jej podstawy.
Korzystnym modelem mentalnym jest kuchnia restauracyjna: jest zorganizowana w poszczególne stacje — grill, smażenie, cukiernictwo — dzięki czemu każdy kucharz może się specjalizować, a szef kuchni może zastąpić jedną ze stacji bez konieczności przebudowy całej kuchni.
Aurora w praktyce: ze względu na wymóg suwerenności omówiony w Filarze 2, bank Aurora musi ostatecznie zastąpić zewnętrzne LLM własnym, hostowanym lokalnie. Ponieważ procesy rozumowania są izolowane we własnej warstwie, zmiana polega jedynie na modyfikacji konfiguracji routingu w poziomie L3 — nie są dotykane żadne integracje narzędzi, a prompty nie muszą być przepisywane.
Jeśli to pominiesz: każdy nowy przypadek użycia zamienia się w edycję jednego rozdętego, skomplikowanego pliku. Zmiana modeli staje się nierealna. Nikt nie może z pewnością powiedzieć, gdzie dokładnie znajduje się logika audytu.
Wniosek: warstwy istnieją po to, by wskazać miejsca, gdzie dopuszczone są zmiany. Ich prawidłowe zaprojektowanie oznacza projektowanie „szwów” systemu, a nie tylko jego poszczególnych elementów.
Kolumna 2 — Architektura fizyczna: Dlaczego samodzielne wdrażanie jest możliwe
Pytanie, na które trzeba odpowiedzieć: gdzie fizycznie działa system i co – jeśli w ogóle cokolwiek – może wyjść poza Twoje granice?
„Samodzielne” w tym kontekście oznacza, że modele, dane, embeddingi oraz ślady wykonywania pozostają w infrastrukturze, którą kontrolujesz, przy czym jedyny dostęp do świata zewnętrznego zapewnia pojedynczy, rejestrowany i filtrowany bramkarz.
Dlaczego ta opcja istnieje teraz, skoro kilka lat temu nie była realna?
- Modele o otwartej wadze zamknęły tę luki. Modele takie jak Llama 3.x, Qwen 2.5 i Mistral mogą teraz być uruchamiane lokalnie i nadal dostarczają wyniki o jakości produkcyjnej do klasyfikacji, wydobywania informacji, streszczania oraz odpowiadania w oparciu o technologię RAG.
- Kwantyzacja sprawia, że są one dostępne cenowo. Techniki kwantyzacji 4-bitowej pozwalają pojedynczej karcie GPU o pojemności 80 GB obsługiwać model z klasy 70 miliardów parametrów, a mniejsze modele wymagają znacznie mniej sprzętu.
- Infrastruktura do wykonywania obliczeń jest rozwinięta. vLLM zapewnia ciągłe grupowanie zadań i wysoką wydajność w środowisku produkcyjnym, Ollama doskonale nadaje się do pracy rozwojowej, a Kubernetes może zarządzać tym procesem w taki sam sposób jak każdą inną usługę.
Ważna niuans: wybór podejścia opartego na suwerenności nie oznacza całkowitego zakazu modeli zewnętrznych. Oznacza to, że każde połączenie wychodzące wymaga wyraźnej zgody, jest ograniczone do określonej klasyfikacji danych i kierowane przez jeden bramkarz — nigdy nie jest inicjowane automatycznie na podstawie domyślnych ustawień. To właśnie tłumaczy, dlaczego bramkarz wyjściowy przedstawiono jako jedne drzwi: jedne strzeżone drzwi są lepsze niż dwadzieścia otwartych okien.
Aurora w praktyce: wszystko, co wrażliwe — embeddingi dokumentów klientów, ślady wykonywania zadań przez agenty, dane PII — pozostaje wewnątrz granic systemu. Jedyne ruchy, które mogą wyjść na zewnątrz, to anonimizowane zapytania o ceny rynkowe, a nawet one przechodzą przez bramkę, która rejestruje każdy przesłany bajt.
Jeśli to pominiesz: domyślne ustawienia niektórych narzędzi do embeddingów typu SaaS potajemnie przesyłają transkrypcje rozmów klientów do dostawcy zewnętrznego. Twoja platforma do monitorowania kończy w rezultacie przechowywanie śladów zawierających dane PII na serwerach poza krajem. Przegląd bezpieczeństwa się nie udaje — a wraz z nim zawodzi cały projekt.
Wniosek: granice systemu to decyzja, którą musisz podjąć świadomie. Jeśli tego nie zrobisz wyraźnie, domyślna konfiguracja dostawcy o to zadba za ciebie.
Kolumna 3 — Model C4: Prawidłowe dokumentowanie
Pytanie: Jak udokumentować system, aby każda grupa odbiorców widziała dokładnie ten poziom szczegółowości, który potrzebuje?
Model C4, stworzony przez Simona Browna, oferuje cztery poziomy powiększenia — można to porównać do przesuwania i powiększania mapy.
Dlaczego model C4 tak dobrze pasuje do systemów agentowych?
- Systemy agentowe są z natury mylące. Pytanie „gdzie właściwie znajduje się agent?” nie ma jednoznacznej odpowiedzi. Model C4 zmusza do precyzji: agent to nie pojedynczy element na diagramie — to zbiór kontenerów (środowisko wykonawcze, brama komunikacyjna, różne magazyny), które wymieniają się wiadomościami. Model C4 ujawnia te wymiany zamiast je ukrywać.
Aurora w praktyce: Gdy regulator pyta dokładnie, które komponenty mogą mieć dostęp do danych osobowych klientów, Aurora potrafi udzielić odpowiedzi w ciągu popołudnia. Zespół pokazuje diagram kontenerów z adnotacjami oznaczającymi strefy wprowadzone w filarze 4, a także diagram komponentów używanych podczas działania agenta — oba utworzone bezpośrednio na podstawie aktualnego stanu repozytorium, wersjonowane razem z kodem, który je stworzył.
Bез tej dyscypliny: nowi pracownicy muszą analizować architekturę od kodu źródłowego. Audytorzy otrzymują prezentację składającą się z 60 slajdów, która jest przestarzała o 14 miesięcy. Każda różnica zdań dotycząca architektury przeradza się w spór o prostokąty na tablicy.
Wniosek: dokumentacja pełni rolę interfejsu pomiędzy architekturą a każdą osobą, która musi jej ufać. C4 przekształca ten interfejs w coś wersjonowanego i podlegającego przeglądaniu, zamiast w statyczny artefakt.
Kolumna 4 — Sieci z zasadą zerowego zaufania: dlaczego dokładnie pięć stref?
Pytanie: Gdy coś zostanie skompromitowane – a prędzej czy później tak się stanie – jak ograniczyć szkody?
Zasada zerowego zaufania oznacza brak domyślnego zaufania nigdzie: każde połączenie jest uwierzytelniane (za pomocą mTLS i tożsamości obciążenia), autoryzowane poprzez sprawdzenie zasad oraz szyfrowane, nawet w przypadku ruchu, który nigdy nie opuszcza własnej sieci. W przypadku platformy opartej na agentach właściwa segmentacja dzieli się na pięć stref:
Dlaczego dokładnie pięć?
Ponieważ każda granica musi oddzielać rzeczywiście odrębny poziom zaufania — a agenci wprowadzają poziom zaufania, który w tradycyjnych architekturach w ogóle nie musiał być brany pod uwagę:
- Z1, Edge — miejsce, do którego najpierw dociera niezaufany ruch. Jest pod ciągłym atakiem, więc zakłada się, że już został naruszony.
- Z2, warstwa aplikacji — obsługuje bezpośrednio użytkowników końcowych. Półzaufany.
Mniej niż pięć stref doprowadziłoby do zaniku granic oddzielających rzeczywiście różne poziomy zaufania. Więcej niż pięć jedynie dodałoby dodatkowe bariery, nie wprowadzając żadnych nowych granic zaufania. Pięć to dokładna odpowiednia liczba.
Aurora w praktyce: atakujący wprowadza polecenie za pośrednictwem skompromitowanej strony internetowej, próbując oszukać podagenta badawczego i nakłonić go do pobrania danych o pensjach z działu kadr. Zasady strefy całkowicie blokują ścieżkę od Z3 do działu kadr, ponieważ zakres tej strefy po prostu nie obejmuje systemów HR. Hub rejestruje tę próbę, a atakujący odchodzi bez niczego poza danymi dostępnymi publicznie w internecie. Agent został zmanipulowany; dane banku pozostały nietknięte.
Bez tej segmentacji: pojedynczy wyciek klucza API łącznika dałby atakującemu — lub złośliwemu agentowi — bezprzeszkodną drogę prosto do całej warstwy danych.
Wniosek: agenci znacznie zwiększają ryzyko ruchu bocznego w sieci. Prawidłowe zonowanie przekształca kompromitowanego agenta z tematu w gazetach o naruszeniach bezpieczeństwa w pojedynczy zarejestrowany zdarzenie.
Pilier 5 — Integracja typu hub-and-spoke: odpowiedni model dla agentów
Pytanie: jak agenci mogą łączyć się z ponad 20 systemami korporacyjnymi, nie zamieniając warstwy integracji w niemożliwą do zarządzania strukturę?
Odpowiedzią jest pojedynczy Hub Integracyjny otoczony certyfikowanymi spoke’ami.
Dlaczego jest to szczególnie ważne dla agentów? Spójrzmy na matematykę. Połączenie wszystkiego bezpośrednio daje 10 systemów pomnożone przez 8 agentów, czyli 80 oddzielnych integracji. Zamiast tego, jeśli wszystko kierujemy przez hub, potrzebujemy tylko 10 spoke’ów plus 8 połączeń z agentami — łącznie 18 ogniw.
Każde bezpośrednie połączenie typu punkt-do-punktu to miejsce, gdzie dane uwierzytelniające są umieszczane w sposób sztywny, rejestracja działań zostaje zaniedbana, a zachowanie systemu cicho odbiega od reszty. Gdy pomnożymy to przez 80 połączeń, otrzymujemy 80 miejsc, do których audytor nie może w pełni zajrzeć. Agenci tylko pogarszają sytuację, a nie poprawiają ją, ponieważ każdy nowy agent zwykle chce mieć dostęp do wszystkiego.
Centralizacja poprzez hub daje kontrolę nad czterema elementami, które mają ogromne znaczenie:
1. Brokering autoryzacji — centrum przechowuje rzeczywiste dane logowania do Salesforce, podczas gdy agenci posiadają jedynie ograniczony i możliwy do cofnięcia token centrum. Cofnięcie jednego tokenu oznacza kontrolę nad jednym agentem, nic więcej. 2. Tłumaczenie schematu — słowo „klient” może oznaczać trzy różne rzeczy w zależności od tego, czy mamy do czynienia z SAP, CRM, czy biurem obsługi klienta. Centrum rozwiązuje ten problem raz, zamiast zmuszać osiem oddzielnych baz kodów agentów do robienia tego samodzielnie. 3. Niezawodność — ograniczenia szybkości i mechanizmy ochronne w centrum zapobiegają temu, by jeden niestabilny element spowodował serię ponownych prób w całym zespole agentów. 4. Jedyny punkt kontrolny audytu — jeden spójny format logów, jedno miejsce, gdzie można odpowiedzieć na pytanie: „Który agent edytował który rekord, kiedy i w jakim zakresie?”
Kolejną zaletą jest to, że serwery narzędzi w stylu MCP umożliwiają przekształcenie poszczególnych komponentów w standardowe, łatwo łączące się elementy zamiast kodu integracyjnego używanego tylko raz.
Jak to wygląda w Aurora: uruchomienie ServiceNow jako systemu nr 21 oznacza stworzenie jednego takiego komponentu. Od następnego dnia każdy agent może go używać według tego samego modelu autoryzacji, tych samych ograniczeń szybkości oraz tej samej ścieżki audytowej co pozostałe 20 systemów. Przy podejściu punkt-do-punktu wymagałoby to ośmiu oddzielnych projektów integracyjnych oraz ośmiu osobnych przekazów danych uwierzytelniających.
Bез tego podejścia: każdy agent posiada własną kopię hasła do Salesforce. Nikt nie może ustalić, który agent edytował dany rekord klienta. Dodanie nowego narzędzia wymaga całego kwartału pracy inżynierów.
Wniosek: hub pełni wobec narzędzi rolę, jaką przełożony pełni wobec agentów — stanowi jedyny, w pełni wyposażony punkt wejścia.
Kolumna 6 — Architektura danych: Dlaczego potrzebne są odrębne poziomy
Pytanie: jak należy zorganizować dane, aby można było odtwarzać odpowiedzi, usuwać rekordy na żądanie i utrzymać kontrolę nad całym procesem?
Odpowiedzią są pięć poziomów, ułożonych w formie procesu:
T0 — Systemy źródłowe. Są to systemy przechowywania danych. Nie są twoją własnością i zmieniają się według własnego harmonogramu, bez uprzedzenia. T1 — Surowa strefa przechowywania. Jednorazowe kopie wszystkich danych w momencie ich przyjęcia. Jest to punkt odniesienia dla wszelkich odbudów; nie jest edytowana ani usuwana, chyba że zgodnie z wyraźną polityką przechowywania. T2 — Dane weryfikowane. Wyczyśczone, usunięte z duplikatów, podzielone na fragmenty, oznaczone jako dane osobowe oraz wzbogacone identyfikatorami ścieżki pochodzenia. T3 — Warstwa serwisowa. Indeksy wektorowe, grafy wiedzy, cache semantyczne — wszystko to artefakty możliwe do odbudowy, które można wygenerować na nowo z T2 w razie potrzeby. T4 — Dane generowane przez agenta. Logi rozmów, „pamięci”, ślady oraz wygenerowane wyniki. Ten poziom umożliwia jedynie dodawanie nowych danych, rzadko jest planowany z wyprzedzeniem i często zawiera najbardziej wrażliwe materiały w całym systemie.
Dlaczego akurat pięć poziomów?
Jeśli przypomina to znane architektury medalionowe — brąz, srebro, złoto — to jest celowe; poziomy T1 do T3 to dokładnie ten dobrze ustalony wzorzec. Kontekst agentów dodaje dwa poziomy na końcach: wyraźną granicę na stronie źródłowej (T0, ponieważ kontrakty integracyjne muszą być dokładnie określone) oraz poziom dla wyników agenta (T4, ponieważ to, co wytwarzają agenci, to również dane, które wymagają własnych zasad przechowywania, ochrony prywatności i audytu).
Strukturyzowanie danych w poziomy zamienia dwa inaczej trudne problemy w rutynową pracę:
1. Reprodukowalność. Zamiast by „zmieniliśmy strategię dzielenia na fragmenty i teraz odpowiedzi są inne” przerodziło się w kryzys, wystarczy jedną noc odbudować T3 na podstawie T2. Jeśli model ulegnie uszkodzeniu, regeneruje się T2 na podstawie T1. Nigdy nie trzeba ponownie przeszukiwać oryginalnych systemów źródłowych. 2. Usuwanie. Gdy klient skorzysta ze swojego prawa do usunięcia danych zgodnie z GDPR, wyraźna ścieżka przekazu oznacza, że żądanie usunięcia jest deterministycznie przekazywane przez T1, T2, T3 i T4 na podstawie identyfikatora — bez konieczności ręcznego szukania.
Zasada leżąca u podstaw tego wszystkiego: indeks wektorowy to pamięć cache, a nie źródło prawdy.
Jak to wygląda w Aurora: zespół QA odkrył, że logika dzielenia na fragmenty potajemnie usuwała wiersze z tabel. Aurora przy użyciu poprawionego narzędzia do dzielenia na fragmenty przenosi dwie miliony dokumentów z T2 w ciągu nocy, bez konieczności ponownego przeszukiwania żadnego systemu źródłowego i bez konieczności paniki z powodu braku historii. Miesiąc później zespół może odtworzyć i porównać, w jaki sposób na dane pytanie odpowiadano przed i po wprowadzeniu poprawki.
Bez hierarchii poziomów: magazyn wektorowy staje się jedyną istniejącą kopią danych. Usuwanie elementów w systemie źródłowym nigdy nie przenosi się dalej. Pytanie takie jak „co asystent powiedział temu klientowi w marcu?” po prostu nie może zostać udzielone odpowiedzi.
Wniosek: projektuj architekturę danych w oparciu o konieczność odbudowy, której ostatecznie będziesz potrzebować, oraz usuwania, którego jesteś prawnie zobowiązany do przeprowadzenia.
Kolumna 7 — Projektowanie oparte na agentach: Dlaczego nadzorca z podagentami jest lepszy od monolitu
Pytanie brzmi: jak powinno się zorganizować „społeczeństwo” agentów składających się na twój system?
W praktyce sprawdziłym się wzorem jest model orkiestrator-pracownik: jeden nadzorca określa ogólny cel, a zbiór podagentów zajmuje się poszczególnymi, wąsko specjalizowanymi zadaniami.
Dlaczego rozdzielenie obowiązków jest lepsze niż tworzenie jednego ogromnego agenta z pięćdziesięcioma dodanymi narzędziami?
1. Kontekst szybko traci na znaczeniu. Gdy jeden agent musi obsługiwać pięćdziesiąt narzędzi oraz cel bez określonego kresu, jego wydajność spada w sposób mierzalny – błędne wybory narzędzi, zapomniane ograniczenia, utrata wątku zadania. Specjalista posiadający pięć narzędzi i wąski zakres zadań jest znacznie bardziej niezawodny. 2. Można to faktycznie przetestować. Nie istnieje sensowny sposób na testowanie jednostkowe rozbudowanego mega-promptu. Można jednak stworzyć dedykowany zestaw testów dla każdego podagenta – na przykład 200 przypadków testowych dla badacza i 50 dla pisarza. To sprawia, że testy regresji agentów stają się rzeczywiste i powtarzalne. 3. Masz jeden punkt kontrolny. Nadzorca staje się miejscem, w którym wprowadzasz ograniczenia budżetowe (maksymalnie 12 kroków lub 0,40 euro za zadanie), zarządzasz próbami ponownymi, uruchamiasz interwencję człowieka oraz zabezpieczasz każdą przekazanie zadania odpowiednimi regułami. 4. Praca odbywa się równolegle, a elementy są wymienne.
Podagenty mogą działać jednocześnie, a każdy z nich może zostać zastąpiony – silniejszym LLM, tańszym modelu lub krokiem wyszukiwania w pełni deterministycznym – bez zakłócania pracy reszty systemu.
Warto podkreślić, że „podagent” nie oznacza „LLM na najniższym poziomie”. W konfiguracji Aurora podagent obliczający koszty w ogóle nie zawiera LLM – jest to kod deterministyczny przykryty interfejsem w stylu agenta. To zapowiada element Pillar 8.
Aurora w praktyce: proces pomocy przy udzielaniu pożyczek dzieli się na rolę Badacza (który pobiera dokumenty polisy), Sprawdzającego (który weryfikuje te dokumenty), Kalkulatora (który oblicza możliwość spłaty za pomocą prostego kodu) oraz Autora (który sporządza list skierowany do klienta). Każda z tych funkcji jest oceniana, wersjonowana i zarządzana niezależnie. Jeśli po zmianie modelu spadną wyniki dotyczące tonu wiadomości napisanych przez Autora, naprawia się konkretnego specjalistę, zamiast próbować uporządkować cały monolit.
Jeśli pominiesz ten element: ostatecznie dostarczysz megagenta składającego się z siedemdziesięciu narzędzi, który od czasu do czasu dwukrotnie wywołuje API zwrotów pieniędzy z powodów, których nikt nie potrafi określić — a wszyscy boją się go edytować.
Wniosek: dzielenie pracy nie dotyczy tylko efektywności. W systemach opartych na agentach jest to właśnie źródło niezawodności.
Pilarek 8 — Determinizm kontra rozumowanie: decyzja najważniejsza
Pytanie: dokładnie gdzie w systemie pozwalamy, by decyzje podejmowane przez sztuczną inteligencję probabilistyczną miały pierwszeństwo, a gdzie zachowanie jest określane wyłącznie przez kod i zasady?
To jest kluczowy filar – wszystkie pozostałe istnieją po to, by wspierać lub egzekwować odpowiedź, którą tu podasz.
Zasada kierująca jest prosta:
LLM proponują. Systemy deterministyczne decydują.
Wykorzystuj LLM do zadań, w których doskonale radzi sobie: klasyfikacji, wydobywania informacji, tworzenia projektów, planowania. Wykorzystuj kod deterministyczny do zadań wymaganych przez regulacje i dobrą inżynierię: weryfikacji, przekazywania pieniędzy, zmiany stanu, egzekwowania zgodności.
W praktyce oznacza to traktowanie procesów pracy jako maszyn stanowych, w których LLM ma prawo głosu tylko w określonych, wyliczonych punktach decyzyjnych, a zwykły kod zajmuje się wszystkim innym.
Dlaczego to jest uznawane za najważniejszy wybór projektowy? Ponieważ wpływa na wszystko, co następuje później:
1. Niezawodność — ścieżki związane z pieniędzmi nie pozwalają na nieprzewidziane zachowania.
2. Możliwość audytu — ponieważ rozgałęzienia decyzji są wyliczalne, można wymienić każdy punkt, w którym podjęto decyzję.
3. Kontrola kosztów — unika się wydawania tokenów na zadania, które prosta instrukcja if już obsługuje bezkosztowo.
4. Spójność architektury — to w nadzorcy z Filaru 7 wprowadza się tę granicę, w hubie z Filaru 5 egzekwuje się ją na poziomie narzędzi, strefy z Filaru 4 zawierają wszelkie błędy, a magazyn dowodów z Filaru 9 potwierdza faktycznie, co się wydarzyło.
Aurora w praktyce — proces zwrotu pieniędzy:
- LLM w strefie rozumowania: czyta e-mail klienta i wyodrębnia ustrukturyzowane pola —
kwota: €145,przyczyna: uszkodzone towary,nastroje: sfrustrowany. Ten krok ma charakter probabilistyczny, co jest do przyjęcia, ponieważ służy jedynie wypełnianiu formularza. - Deterministyczny silnik decyzyjny: kwoty do €200 są automatycznie zatwierdzane; kwoty od €200 do €1 000 podlegają weryfikacji opartej na regułach; wszystko powyżej €1 000 wymaga zatwierdzenia przez człowieka. LLM nie ma uprawnień do przenoszenia pieniędzy — może jedynie zaproponować wartość, a decyzję o dalszym losie podejmuje sam kod.
Oba skrajne przypadki są niebezpieczne, dlatego konieczne jest przyjęcie środniej drogi:
Pozwolenie modelowi LLM na decydowanie o wszystkim („po prostu niech agent się tym zajmie”) prowadzi do sytuacji, gdy otrzymujemy e-mail z wpisany promptem, który zatwierdza zwrot 50 000 euro. Pozwolenie regułom na decydowanie o wszystkim oznacza system, który nie potrafi nawet przetworzyć zwykłego e-maila – co w praktyce oznacza powrót do czasów z 1995 roku.
Wniosek: pełna autonomia modeli LLM to tylko trik demonstracyjny; pełna sztywność oparta na regułach należy już do przeszłości. Systemy produkcyjne wymagają starannie opracowanej, udokumentowanej mapy określającej dokładnie, w których przypadkach obowiązuje dany tryb – a prawidłowe stworzenie tej mapy jest najważniejszą decyzją przy projektowaniu całego systemu.
Pilarek 9 — Powiązanie z dowodami / Citowanie: Dlaczego to jest odporne na audyt
Pytanie: Jak sprawić, by każdy wynik był odporny na krytykę – nawet po miesiącach lub latach, wobec audytora, który aktywnie szuka słabych punktów?
Każde twierdzenie faktograficzne musi być powiązane ze swoim źródłem dowodowym, a cała ścieżka decyzyjna musi pozostać niezmieniona po zapisaniu:
Dlaczego to sprawdza się podczas audytu? Ponieważ zapewnia to jednocześnie trzy gwarancje:
1. Blokada halucynacji. Jeśli nie ma cytatu, nie ma publikacji. Gdy etap generowania odpowiedzi nie może dołączyć ważnego źródła, wynik zostaje oznaczony lub zablokowany. To przekształca zasadę „po prostu ufać modelowi” w egzekwowalną, mechaniczną zasadę.
2. Pełna możliwość odtworzenia procesu. Jeśli ktoś zapyta „dlaczego system zareagował w ten sposób 3 marca?”, możesz odtworzyć dokładną sekwencję – pierwotne pytanie, pobrane fragmenty, wersję promptu, wersję modelu, wygenerowaną odpowiedź oraz jej źródła. Zamiast mówić „uważamy, że”, przedstawiasz rzeczywisty zapis.
3. Jasność przyczyny podstawowej. Gdy wynik okazuje się błędny, możesz natychmiast określić rodzaj awarii: czy chodziło o błąd w wyszukiwaniu (pobrano niewłaściwe dowody), czy o błąd w rozumowaniu (pobrano właściwe dowody, ale zostały błędnie zinterpretowane)? Wymagają one zupełnie różnych rozwiązań, a bez wiążących dowodów nie da się ich odróżnić.
Aurora w praktyce: Asystent odpowiada na pytanie dotyczące warunków kary, powołując się na credit_policy_v12.pdf, strona 14, sha256:9f2c…. Później, gdy zostanie wydana wersja 13 polityki, ta wcześniejsza odpowiedź nadal odzwierciedla dokładnie to, co było prawdziwe w momencie jej udzielenia, ponieważ przytoczone dowody są związane haszem, a nie pobierane dynamicznie. Przeglądający zgodność może ją zatwierdzić, ponieważ cały łańcuch jest możliwy do odtworzenia, wykazuje oznaki ingerencji i ma poprawne znaczniki czasowe.
Uniknij tego, a: twoją jedyną obroną podczas incydentu lub audytu stanie się „model tak powiedział”. Tracisz możliwość odróżnienia problemu jakości danych od błędu w rozumowaniu. Organizacje regulacyjne określą taki system jako „czarną skrzynkę” — a czarne skrzynki są wyłączane.
Wniosek: jeśli system nie może na to powołać się, nie zostaje opublikowany.
Jak połączone są Dziewięć filarów
Te dziewięć elementów nie stanowi listy oddzielnych kwestii — tworzą spójną strukturę z jądrem:
Gdy usuniemy choć jeden filar, reszta zaczyna się rozpadać. Usunięcie warstwy typu „środek i promienie” (5) sprawia, że determinizm (8) nie może być już egzekwowany na poziomie wywoływania narzędzi. Usunięcie hierarchii danych (6) oznacza, że wiązanie dowodów (9) nie ma już nic wiarygodnego do odniesienia. Usunięcie dokumentacji C4 (3) pozbawia nas możliwości wyjaśnienia pozostałej architektury podczas audytu. Działają one tylko jako zbiór — albo wszystkie dziewięć jest zachowane, albo całość się załamuje.
Co przyniesie ta seria
Każdy kolejny odcinek będzie kompleksowym opracowaniem: zasadą przewodnią, towarzyszącym diagramem, przykładem z scenariusza banku Aurora, konkretnymi wyborami technologicznymi, powszechnymi antypatronami, których należy unikać, oraz praktyczną listą kontrolną budowy.
Ostatnia myśl
Do 2026 roku dostęp do sprawdzonego modelu nie będzie już czynnikiem wyróżniającym — klucz API może uzyskać każdy.
To architektura naprawdę odróżnia systemy, które przetrwają. Zespoły, którym uda się wdrożyć systemy agentowe w regulowane, wysokorizykowe środowiska, to te, które zrozumiały prawdziwą naturę zadania: budowę deterministycznego systemu korporacyjnego, w którym zaimplementowany jest silnik rozumowania probabilistycznego.
Dziewięć filarów. Dziewięć decyzji. Trzeba je wszystkie podjąć prawidłowo, jednocześnie.
Następnie — Część 1: Architektura logiczna, gdzie sześciowarstwowa struktura jest budowana warstwa po warstwie, kontrakty pomiędzy każdą parą warstw są definiowane w sposób wyraźny, a antypatrony, które zamieniają bazy kodu agentów w nieudostępnialne bałagany, są szczegółowo analizowane.
Pozycje pokrewne
- Agentic AI wyjaśnione: od modeli językowych do autonomicznych agentów — Strukturalny przewodnik po tym, jak modele językowe ewoluują w systemy agencyjne za pomocą narzędzi, pamięci, planowania, architektur wieloagentowych oraz integracji MCP.
- RAG wyjaśnione: jak systemy AI zdobywają nową wiedzę na zamówienie — Dowiedz się, jak działa Retrieval-Augmented Generation, od dzielenia tekstu na fragmenty i tworzenia embeddingów po wyszukiwanie wektorowe, dzięki czemu modele AI mogą odpowiadać na pytania bez ponownego szkolenia.