Model dojrzałości agentów: nadzór przez człowieka, inżynieria narzędziowa, orkiestracja.
Pięć poziomów dojrzałości agentów sprawdzonych w warunkach produkcyjnych: nadzór przez człowieka, inżynieria narzędziowa, orkiestracja wielu agentów oraz problemy, które wciąż pozostają nierozwiązane.
Źródła: Agentic Architectures — Article 15: The Maturity Model Revisited
Model dojrzałości agentów jest łatwy do narysowania, ale trudny w praktyce. Na papierze wygląda schludnie: to drabina zaczynająca się od prostych narzędzi do wywoływania funkcji i kończąca się samodoskonalącymi się systemami produkcyjnymi. Frameworki zawsze wyglądają uporządkowanie, zanim ktoś spróbuje uruchomić je pod obciążeniem. Gdy za nimi znajduje się rzeczywisty kod, ten sam model wygląda inaczej. Nie był błędny, ale znać coś teoretycznie a znać to w warunkach produkcyjnych to różne rodzaje wiedzy. Mapa nie może powiedzieć ci, jak wygląda droga o trzeciej nad ranem, gdy wyłącznik bezpieczeństwa nie chce się zamknąć, a osobą odpowiedzialną za reakcję jesteś ty.
To spojrzenie wstecz na ten model po tym, jak zbudowano warstwy, które się pod nim znajdują: jak poziomy odpowiadają pracom inżynieryjnym, które przekonania nie przetrwały kontaktu z produkcją, jak wygląda architektura referencyjna składająca się z warstw oraz co pozostaje nierozwiązane. Kod jest tutaj zminimalizowany. Celem jest cofnięcie się o krok i zobaczenie całej struktury.
Pięć poziomów, z których każdy opiera się na poprzednim
Model dojrzałości opisuje pięć poziomów możliwości agenta. Każdy poziom to nie tylko silniejsza wersja poprzedniego, ale także zależy od wszystkiego, co znajduje się poniżej. Nie można pominąć żadnego kroku. Agent nie może być niezawodnie autonomiczny bez infrastruktury do oceny, a także nie może się sam poprawiać bez pamięci. Poziomy wzajemnie się uzupełniają.
Oto, jak tematy inżynieryjne odpowiadają tym poziomom:
+---------+---------------------+------------------------------------------+
| Level | Capability | Articles That Build It |
+---------+---------------------+------------------------------------------+
| Level 1 | Reactive | Article 4: Protocols (MCP, A2A) |
| | Responds to inputs, | Basic tool use, standard interfaces |
| | calls tools | |
+---------+---------------------+------------------------------------------+
| Level 2 | Assisted | Article 5: Harness Engineering |
| | Shaped behavior, | Article 13: Human-in-the-Loop |
| | human oversight | |
+---------+---------------------+------------------------------------------+
| Level 3 | Supervised | Article 6: Multi-Agent Orchestration |
| | Coordinated, | Article 8: Evaluation Pipelines |
| | evaluated, secured | Article 9: Security and Red-Teaming |
+---------+---------------------+------------------------------------------+
| Level 4 | Autonomous | Article 7: Memory Architectures |
| | Operates | Article 10: Cost Optimization |
| | independently at | Article 11: Deployment Patterns |
| | scale | Article 14: Goal-Directed Loops |
+---------+---------------------+------------------------------------------+
| Level 5 | Self-Improving | Articles 7 + 8 combined |
| | Learns from its own | Article 12: The frontier (not yet here) |
| | operation | |
+---------+---------------------+------------------------------------------+
Kształt ma większe znaczenie niż mapowanie. Poziom 5, samodoskonalenie, nie posiada dedykowanego komponentu, ponieważ nie jest to coś, co można bezpośrednio stworzyć. Pojawia się wtedy, gdy pamięć i ocena współpracują ze sobą, a nawet wtedy ta dziedzina nie jest jeszcze w pełni rozwinięta. Górna część modelu pozostaje częściowo aspiracyjna. Samodoskonalenie można dziś tylko przybliżyć, ale nie osiągnąć w pełni.
To nie było oczywiste, gdy model został po raz pierwszy naszkicowany. Poziom 5 wyglądał jak cel, do którego można dotrzeć poprzez połączenie odpowiednich elementów. W praktyce zachowuje się bardziej jak horyzont, który oddala się w miarę jego zbliżania się.
Przekonania skorygowane przez produkcję, od ludzi w procesie do orkiestracji
To jest to, czego dokument ramowy nigdy nie może uchwycić, ponieważ wynika ono wyłącznie z procesu budowania. Kilka wstępnych założeń okazało się błędnych lub przynajmniej niekompletnych.
Pamięć była poważnie niedoceniana. W pierwszym szkicu pamięć była przedstawiona jako pojedynczy element, cecha sprawiająca, że agenci działają w sposób bardziej spójny. Pokazanie, jak ją budować, ujawniło, że pamięć stanowi infrastrukturę, obejmującą wszystko, co to słowo oznacza: projektowanie schematów, jakość odzyskiwania danych, zasady degradacji oraz izolację użytkowników. Nastąpiła kolejna, nieprzyjemna lekcja – nawet infrastruktura, którą potrafimy zbudować, nie jest dokładnie odpowiednią abstrakcją. Zespoły adaptują bazy danych zaprojektowane do innych zadań, ponieważ nie istnieją specjalnie stworzone rozwiązania. Pamięć była tematem najbardziej niedocenianym w oryginalnym modelu.
Celem jest przewidywalność, a autonomia ma drugorzędne znaczenie. To jest najgłębsza zmiana. Na początku postęp mierzono tym, ile może zrobić agent bez udziału człowieka, więc każdy dodatkowy element niezależności wydawał się oznaką rozwoju. Jednak agent, który działa samodzielnie, ale w sposób nieprzewidywalny, szybciej wyrządza szkodę. Okazało się, że niezawodność pod nadzorem ma większe znaczenie niż sama niezależność we wszystkich poważnych zastosowaniach. Jeden z ilustracyjnych przypadków niepowodzenia dotyczył agenta, który samodzielnie stworzył dziesiątki duplikatów zleceń. Systemy produkcyjne potrzebują odpowiedniej ilości autonomii: ograniczonej, podlegającej audytowi i przewidywalnej, przy czym to ludzie podejmują decyzje, których koszt wymaga ludzkiej uwagi. Jeden z czytelników twierdził kiedyś, że orkiestracja powinna dążyć do przewidywalności, a nie do autonomii, i długo nie chcieliśmy przyznać mu racji.
Bezpieczeństwo jest cechą każdej warstwy. Pierwotny plan traktował bezpieczeństwo jako temat na końcu, coś, co dodawano dopiero wtedy, gdy system zaczął funkcjonować. Iniekcja poleceń poprawia tę sytuację. Jej cele znajdują się gdzie indziej: w miejscu wywoływania narzędzi, w ścieżce zapisywania danych, w sposobie modyfikacji celów oraz w ruchu pomiędzy agentami. Każdy komponent ma wymiar bezpieczeństwa. Autoryzacja na granicy narzędzi, izolacja w pamięci oraz kontrole modyfikacji celów to wszystko elementy bezpieczeństwa, rozproszone w całym systemie, a nie skupione w jednym miejscu.
Pętla ma wyższy priorytet niż prompt. Ta lekcja znalazła się na końcu, a powinna była być pierwsza – wtedy byłaby bardziej przydatna. Duża część wysiłków w tej dziedzinie skupia się na projektowaniu promptów oraz poszukiwaniu idealnych sformułowań. Jednak agent to nie prompt – to pętla, która realizuje cel poprzez wiele kroków, a doskonały prompt wewnątrz uszkodzonej pętli daje nam elokwentnego agenta, który nigdy nie dociera do celu. Gdy zaczniemy myśleć w kategoriach pętli, wiele problemów, które wydawały się ograniczeniami modelu, okazuje się błędami w projektowaniu pętli.
Człowiek w procesie nie jest wadą, którą można usunąć poprzez inżynierię. Kuszące jest założenie, że udział człowieka to tymczasowe rozwiązanie, które należy usunąć w miarę rozwoju technologii. Najlepsze systemy agentów produkcyjnych to nie te najbardziej autonomiczne. One umieszczają ludzką ocenę dokładnie tam, gdzie jest potrzebna, i nigdzie indziej. Nadzór człowieka to nie etap, z którego się kończy. To celowe, trwałe element każdego systemu, którego błędy niosą rzeczywiste konsekwencje.
Całość w jednym obrazku
Jeśli połączyć wszystko powyżej, dojrzały system agentów wygląda w ten sposób:
+==========================================================================+
| HUMAN OVERSIGHT LAYER |
| Approval gates, escalation, audit trail (Article 13) |
+==========================================================================+
| | |
+==========================================================================+
| GOAL & LOOP LAYER |
| ReAct / Plan-Execute / Reflexion, goal revision (Article 14) |
+==========================================================================+
| | |
+==========================================================================+
| ORCHESTRATION LAYER |
| Supervisor-worker, pipeline, fan-out, debate (Article 6) |
+==========================================================================+
| | |
+==========================================================================+
| HARNESS LAYER |
| Self-verification, loop detection, reasoning routing (Article 5) |
+==========================================================================+
| | |
+--------------------------------------------------------------------------+
| MODEL LAYER |
| AWS Bedrock: Claude 3.7 / 3.5 / Haiku |
+--------------------------------------------------------------------------+
CROSS-CUTTING CONCERNS (touch every layer above):
+----------------+ +----------------+ +----------------+ +----------------+
| MEMORY | | EVALUATION | | SECURITY | | COST |
| Article 7 | | Article 8 | | Article 9 | | Article 10 |
| episodic, | | offline+online | | injection def, | | model routing, |
| semantic, | | LLM judge, | | guardrails, | | caching, |
| procedural | | regression | | red-teaming | | batch, budget |
+----------------+ +----------------+ +----------------+ +----------------+
+--------------------------------------------------------------------------+
| DEPLOYMENT LAYER (Article 11) |
| Blue-green, canary, state migration, model pinning, IaC |
+--------------------------------------------------------------------------+
Warstwy pionowe tworzą ścieżkę żądania. Zadanie trafia do systemu dzięki nadzorowi człowieka, kształtuje się pod wpływem celów i pętli, jest koordynowane pomiędzy różnymi elementami systemu, udoskonalane za pomocą odpowiednich narzędzi i w końcu wykonywane wobec modelu. Kwestie dotyczące całego układu wpływają na każdą warstwę. Pamięć dostarcza zarówno elementy niezbędne do funkcjonowania pętli, jak i narzędzia do ich udoskonalania. Bezpieczeństwo chroni granice narzędzi oraz proces korekty celów. Koszt determinuje sposób przekierowywania zapytań do modelu na każdym etapie. Implementacja obejmuje wszystkie te elementy razem.
Perspektywa poziom po poziomie ukrywa fakt, jak ściśle połączone są ze sobą te elementy. Zmiana w jednym elementie wpływa na pozostałe. Nie można optymalizować kosztów bez zrozumienia mechanizmów pętli, ponieważ drogie wykonywanie zadań często wynika z pętli, która nie kończy się. Praca nad bezpieczeństwem również wymaga świadomości funkcjonowania pamięci, ponieważ uszkodzony wpis może nadal powodować problemy długo po swoim utworzeniu. Traktuj warstwy jako jedną spójną całość, a nie jako zbiór oddzielnych modułów.
To, czego nikt jeszcze nie rozwiązał
To może być najprzydatniejszy rozdział, ponieważ wszystko powyżej opisuje to, co można zbudować, a tutaj opisano to, czego na razie nie da się zrobić. Szczery obraz granic jest cenniejszy niż idealnie dopracowany.
Pamięć typu „agent-native” nie istnieje. Obecne systemy pamięciowe są tworzone na bazie baz danych i magazynów wektorowych, zaprojektowanych do innych celów. Prawdziwy system typu „agent-native”, który śledzi czas, wyszukuje informacje poprzez powiązania, celowo zapomina i pozwala agentowi decydować, co zapisać, według niektórych ocen jest jeszcze kilka lat w tyle. To, co istnieje, funkcjonuje, ale to nie jest to, czego potrzebujemy.
Agenci nie mogą pewnie określić, kiedy ich wiedza jest przydatna. To jest głębsza forma problemu przestarzałej pamięci. Agent może odzyskać odpowiednią procedurę i z pewnością zastosować ją w przypadku, w którym nie pasuje, ponieważ trudno jest określić, w którym momencie dana wiedza przestaje być aktualna, a jeszcze trudniej to sprawdzić po jej odzyskaniu. Procedura, która działa w jednym obszarze jurysdykcji, może zostać błędnie zastosowana w innym, a ani agent, ani często użytkownik tego nie zauważają. To fundamentalna ograniczenie, a nie tylko brak w rozwiązaniach inżynieryjnych.
Samodzielna ocena jest niewiarygodna. Zarówno logika eskalacji, jak i ocena pewności sięgają się możliwości dokładnego oceniania przez agenta własnej pewności. Czasami mu się to udaje, a czasami myli się, wydając się pewnym – co stanowi najbardziej szkodliwy przypadek, ponieważ unieważnia wszelkie zabezpieczenia oparte na rozpoznawaniu przez agenta swoich ograniczeń. Do tej pory nie ma niezawodnego rozwiązania dla skalibrowanej samodzielnej oceny.
narzędzia nie przenoszą się między modelami. Każde narzędzie jest dostosowane do zachowania konkretnego modelu. Zmiana modelu wymaga ponownego dostosowania promptów, progów wykrywania pętli oraz kryteriów weryfikacji. W zasadzie nie musi tak być, ale nikt nie stworzył abstrakcji narzędzi, która przetrwałaby zamianę modelu bez konieczności dostosowań. Aktualizacja modelu pozostaje projektem, a nie zmianą konfiguracji.
Nie istnieje prawdziwe ciągłe uczenie się. Pamięć proceduralna tylko naśladuje proces uczenia się: skuteczne metody są przechowywane i ponownie wykorzystywane. Jednak wagi się nie zmieniają, a agent nie rozwija nowych umiejętności dzięki doświadczeniu. Tworzy on bibliotekę wcześniejszych rozwiązań i czerpie z niej. Agent, który naprawdę poprawia swoje umiejętności w określonej klasie zadań dzięki doświadczeniu, to coś, czego systemy produkcyjne nie są w stanie osiągnąć obecnie.
Koszt jest nieprzewidywalny w warunkach skrajnych. Istnieją narzędzia do zarządzania kosztami i działają one skutecznie, ale końcowa część rozkładu jest trudna do przewidzenia. Niewielka liczba wykonań, te, które wpadają w patologiczne pętle lub nietypowe przypadki graniczne, nadal zużywa niewspółmiernie wiele zasobów w sposób trudny do przewidzenia. Można ograniczyć te wydatki, choć nie zawsze można je przewidzieć.
Żadne z tych powodów nie jest uzasadnieniem do wstrzymywania się. To są krawędzie obecnego „mapy”, a znajomość ich położenia to to, co odróżnia inżynierię od marzeń bez podstaw.
Od czego zacząć: najpierw inżynieria, potem orkiestracja agentów
Jeśli budujesz system agentów, nie traktuj tematów jako kolejności budowy. Są one grupowane według koncepcji, a nie według sekwencji realizacji. Jeśli będziesz budować w takiej kolejności, stworzysz „pamięć” zanim będziesz miał narzędzie do jej wykorzystania, a ocenę zanim będzie cokolwiek do oceny.
Zacznij od poziomu dojrzałości swojego systemu.
- Prosty agent wykonujący proste zadania, który jest niewiarygodny, powinien najpierw opracować mechanizmy zapewniające niezawodność, ponieważ to właśnie tam leżą większość problemów z niezawodnością.
- Solidny, pojedynczy agent, który osiągnął już swój limit możliwości, jest gotowy do orkiestracji wielu agentów.
- System przeznaczony do produkcji wymaga oceny, zabezpieczeń oraz procesu wdrożenia – żadna z tych czynności nie jest opcjonalna, a rozsądnie jest je realizować mniej więcej w takiej kolejności.
- Pamięć komputerowa okazuje się przydatna, gdy masz już działającego, przetestowanego i zabezpieczonego agenta, a widzisz, że ta sama praca jest powtarzana przy kolejnych uruchomieniach. Dodawanie jej wcześniej jest przedwczesne.
- Optymalizacja kosztów staje się pilna, gdy zużycie przechodzi z poziomu testowego na poziom produkcyjny, chociaż powinna kształtować projekt od samego początku.
- Pętle ukierunkowane na cel oraz wzorce z udziałem człowieka występują we wszystkich aspektach. Spotkasz je na każdym etapie, więc warto dowiedzieć się o nich wcześnie, nawet jeśli będziesz je wdrażać stopniowo.
Narzędzia są wymiennicze, ale pomysły nie
Przykłady przedstawione w tym omówieniu zostały stworzone na bazie AWS Bedrock, LangGraph i LangChain. Były to praktyczne wybory, podyktowane faktem, że stanowią one stack używany w produkcji, ale nie są jedynymi możliwymi rozwiązaniami. Większość istotnych elementów nie jest z nimi powiązana. Autoryzacja powinna znajdować się na granicy narzędzia w każdym chmurze. W każdym frameworku ważniejszy jest cykl niż prompt. Poziomy pamięci, wzorce koordynacji między wieloma agentami, kategorie ataków oraz matryca odwracalności w odniesieniu do kosztów nadzoru przez człowieka mogą być przeniesione na inne stacki.
To także powód, dla którego warto mieć lokalną alternatywę z Ollamą i Dockerem. Umożliwia ona uruchamianie tych wzorców bez konieczności płacenia rachunków chmurowych i pokazuje, że koncepcje te można oddzielić od ich implementacji. Jeśli architektura pamięci działa z lokalnym modelem oraz lokalnym magazynem wektorowym, to projekt od początku nie był inspirowany Bedrockiem. To, co zostało uchwycione, to podstawowy problem, który wygląda podobnie na każdej platformie. To samo dotyczy wzorców orkiestracji – zamiana LangGraph na inny framework zmienia tylko składnię pętli, ale nie sposoby radzenia sobie z awariami, z którymi musi się ona zmierzyć. Podobnie jest z narzędziami oceny, które mogą być używane z dowolnym modelem znajdującym się za nimi.
Co ujawniło spisanie tego tekstu
Jasne i uporządkowane wyjaśnianie tematu komuś, kto nie był obecny podczas jego poznawania, ujawnia luki we własnym rozumieniu. Wiele tematów wydaje się już opanowane, dopóki nie spróbujemy ich zapisać.
Prawdziwy stan tej dziedziny to jednocześnie jej ekscytujący i niedojrzały charakter. Dziś możliwe są rzeczy, których nie dało się zrobić dwa lata temu, a łatwo oszukać samego siebie, ponieważ płynna prezentacja wydaje się bardziej skuteczna, niż w rzeczywistości jest. Różnica pomiędzy agentem, który dobrze funkcjonuje podczas demonstracji, a tym, który stabilnie działa w produkcji, jest ogromna, a większość trudności inżynieryjnych leży właśnie w tej przestrzeni.
Jeśli istnieje jedno przesłanie, które warto przekazać na początek, to takie, że interesująca praca nie polega na czynieniu agentów potężniejszymi. Modele są już potężne i stale się udoskonalają zgodnie z harmonogramem, którego nie kontrolujemy. Prawdziwym wyzwaniem jest uczynienie tych potężnych modeli niezawodnymi, przewidywalnymi, bezpiecznymi oraz wystarczająco dostępnymi, by można było im powierzać rzeczywiste decyzje. To inżynieria, a nie magia: mechanizmy, pętle, pamięć, ocena oraz cała ta niespektakularna infrastruktura, która przekształca zdolny model w coś, na czym można polegać.
Inteligencja pochodzi od modelu. Architekturę musisz zbudować sam.
Literatura pokrewna
- Notatki praktyczne: Architektury agentowe, Artykuł 12: Czy jesteśmy gotowi na: Szczegółowy przewodnik po Notatkach praktycznych: Architektury agentowe, Artykuł 12: Czy jesteśmy gotowi na – umowy, sprawdzania oraz gotowe elementy kodu dla zespołów wdrażających ten wzorzec.
- Ludzka interwencja w działaniu agentów AI: Brama zatwierdzenia, eskalacja, ślady audytu: W sytuacjach, gdy agent wymaga zatwierdzenia człowieka, przedstawiono cztery wzorce (bramy, eskalacja, wspólne edycje, próbkowanie), możliwość pauzowania i wznowienia działania za pomocą LangGraph, limity czasowe, logi audytu oraz typowe pułapki.