Wewnątrz systemu wielu agentów: notatki architektoniczne dla twórców kryptowalut
System wielu agentów do kryptowalut B2B, warstwa po warstwie: style orkiestracji, wspólny stan, ograniczenia narzędzi, zasady bezpieczeństwa, idempotencja oraz brak sztucznej inteligencji w żadnym etapie podpisywania.
Źródła: Inside the Architecture of a Multi-Agent System: A Technical Guide for B2B Crypto Builders
Załóżmy firmę zajmującą się kryptowalutami, która sprzedaje usługi firmom i potrzebuje oprogramowania, które monitoruje protokoły DeFi, ocenia płynność, analizuje ryzyko związane z inteligentnymi kontraktami, przywraca równowagę w rezerwie finansowej, zaznacza nietypowe transakcje, a nawet dokonuje transakcji zgodnie z z góry ustalonymi zasadami. Jeden agent AI, który ma do obsługi to wszystko, szybko odczuwa przeciążenie. Musi czytać dane rynkowe, wysyłać zapytania do infrastruktury łańcucha bloków, oceniać ryzyko, korzystać z API, podejmować decyzje finansowe i podpisywać transakcje – wszystko to w ramach jednego cyklu rozumowania. Testowanie, skalowanie i zabezpieczanie takiego systemu szybko staje się skomplikowane.
Zwykłą odpowiedzią jest podział pracy między specjalistycznymi agentami oraz dodanie warstwy orkiestracji na górze. To coś więcej niż tylko kilka modeli językowych rozmawiających ze sobą. Jest to architektura oprogramowania, w której rozumowanie modeli, logika aplikacji, dane, narzędzia, uprawnienia oraz proces wykonywania są celowo oddzielone. W dalszej części omówiono, jak te elementy się łączą oraz co powinni wziąć pod uwagę twórcy systemów produkcyjnych w tym obszarze.
Co stanowi system wieloagentowy
Kilka specjalistycznych agentów współpracujących przy zadaniu większym, niż jakikolwiek z nich mógłby samodzielnie sprostać – taka jest definicja. Praktyczna formuła dla pojedynczego agenta:
Agent = model AI + instrukcje + kontekst + narzędzia + stan + pętla wykonywania
Dla grupy dodaje się drugą warstwę:
Agenci + orkiestracja + wspólny stan + komunikacja + zasady
Platforma skarbowa może składać się z następujących komponentów:
- Agenta badawczego, który zbiera dane protokołu i rynkowe.
- Agenta ds. ryzyka, który ocenia zagrożenia związane z kontraktami, płynnością i protokołem.
- Agenta portfelowego, który porównuje możliwości i oblicza alokacje.
- Agenta ds. zgodności, który stosuje zasady biznesowe firmy.
- Agenta wykonawczego, który przygotowuje i wysyła transakcje.
- Agenta monitorującego, który potwierdza na łańcuchu, co faktycznie się wydarzyło.
Weźmy takie polecenie: zainwestuj 50 000 USD w najbezpieczniejsze oferowane stopy zwrotu, pod warunkiem, że protokół spełnia zasady zarządzania ryzykiem, a koszty wykonania pozostają poniżej 0,5%. Wymaga to kilku różnych umiejętności, dlatego system przekształca to w sekwencję kroków:
```text
User Request
↓
Orchestrator
↓
Research Agent
↓
Risk Agent
↓
Portfolio Agent
↓
Policy Check
↓
Execution Agent
↓
Blockchain
↓
Verification
```
Każdy agent zajmuje się małym problemem, a żaden nie musi rozwiązywać całego procesu pracy.
Szczegóły systemu produkcyjnego
Siedem elementów pojawia się wielokrotnie: środowisko działania agenta, orkiestrator, wspólny stan, warstwa narzędzi, warstwa polityk i bezpieczeństwa, infrastruktura wykonywania oraz możliwości obserwacji. Każdy z nich odpowiada na odrębną kwestię inżynieryjną.
Środowisko działania agenta
Środowisko to uruchamia jeden agent. W warunkach produkcyjnych agent to coś więcej niż prośba wprowadzona i odpowiedź otrzymana. Działa jak pętla:
```text
Input
↓
Build Context
↓
Ask Model to Reason
↓
Choose Action
↓
Call Tool / Agent / Return Result
↓
Receive Result
↓
Update Context
↓
Reason Again
```
Załóżmy, że od agenta badawczego wymaga się porównania protokołów pożyczkowych w DeFi. Pobierze on listę protokołów, uzyska ich aktualną wartość TVL, sprawdzi stawki pożyczkowe, porówna płynność, wybierze najbardziej odpowiednie opcje i przekaże je agentowi ds. ryzyka. Model dostarcza uzasadnienie, natomiast aplikacja wokół niego kontroluje to, co faktycznie zostanie wykonane. Ta granica jest ważna, ponieważ model nie powinien wykonywać zadań, które zwykły oprogramowanie wykonuje lepiej. Mnożenie 50 000 dolarów przez 8,2% nie wymaga użycia LLM, ponieważ zwykła funkcja jest szybsza, tańsza i zawsze daje ten sam wynik.
Orkiestrator
Orkiestrator to centrum sterowania. Decyduje, który agent ma działać, co ma mu zostać powiedziane, co ma zostać wykonane dalej, które zadania mogą być realizowane równolegle, kiedy praca zostanie zakończona oraz co robić, gdy agent zawiedzie. Istnieją dwa podstawowe style.
Orkiestracja oparta na modelach. Model nadzorczy wybiera specjalistę, którego potrzebuje.
```text
Supervisor Agent
│
┌─────┼─────┐
▼ ▼ ▼
Research Risk Analytics
```
Kierownik może uznać, że najpierw potrzebne są dane protokołowe, więc wzywa agenta badawczego, a gdy otrzyma wynik, decyduje, że potrzebna jest ocena bezpieczeństwa, i wzywa agenta ds. ryzyka. To jest elastyczne, chociaż routowanie może stać się nieprzewidywalne, dodatkowe wywołania modeli się gromadzą, a wraz z nimi koszty.
Orkiestracja oparta na kodzie. Aplikacja określa kolejność działań.
```text
Research
↓
Risk Analysis
↓
Policy Check
↓
Simulation
↓
Approval
↓
Execution
```
Ta wersja jest łatwiejsza do testowania i kontrolowania.
Mieszanie obu podejść. W przypadku produktów finansowych typu B2B najskuteczniejsze rozwiązania często łączą oba podejścia. Model podejmuje decyzje, a kod stosuje zasady. Model może stwierdzić, że protokół A oferuje najlepszą stopę zwrotu dostosowaną do ryzyka, podczas gdy aplikacja nalega na dodatkową zatwierdzenie dla kwot przekraczających 50 000 dolarów. Sztuczna inteligencja doradza, a oprogramowanie egzekwuje.
Wspólny stan
Agenty muszą widzieć wyniki wcześniejszych kroków. Przekazywanie całej rozmowy każdemu z nich marnuje zasoby, dlatego system przechowuje zamiast tego uporządkowany zapis procesu pracy.
Dla żądania dotyczącego USDC taki zapis zawierałby aktywo (USDC), kwotę (50000), łańcuch (Ethereum), listę kandydujących protokołów (Aave i Morpho) oraz trzy pola stanu (ryzyko, polityka i realizacja), które początkowo mają wartości pending, pending i not started.
Agent badawczy wypełnia pola takie jak protokoły kandydatów, wyniki oraz dane rynkowe. Agent ds. ryzyka dodaje ocenę oraz swoje ustalenia dotyczące bezpieczeństwa. Agent wykonawczy widzi tylko to, co jest potrzebne do wykonywania jego zadań. Struktura jest uporządkowana:
```text
Shared State
│
┌──────────┼──────────┐
▼ ▼ ▼
Research Risk Execution
Agent Agent Agent
└──────────┼──────────┘
▼
Updated State
```
Dzielenie się danymi ułatwia również znacznie przerwanie, wznowienie, audytowanie i naprawianie błędów w procesie pracy.
Komunikacja: przekazywanie zadań i agenci jako narzędzia
Agenci współpracują na dwa przydatne sposoby. Podczas przekazywania zadań kontrola przechodzi od jednego agenta do następnego.
```text
Research Agent
↓
Risk Agent
↓
Portfolio Agent
```
Przekazywanie obowiązków jest odpowiednie w sytuacjach, gdy zmienia się odpowiedzialność: po zakończeniu badań rynkowych to agent zajmujący się ryzykiem odpowiada za ocenę kandydatów. Gdy agent jest używany jako narzędzie, jeden agent wzywa drugiego i utrzymuje kontrolę.
```text
Supervisor
/ | \
Research Risk Analytics
```
Kierownik może poprosić specjalistę od ryzyka o przetestowanie protokołu pod kątem kryteriów firmy, uzyskanie uporządkowanej odpowiedzi i kontynuowanie pracy. Jest to przydatne, gdy jeden centralny specjalista musi połączyć kilka opinii ekspertów.
Szczegóły narzędzi
Specjalista nie może samodzielnie modyfikować łańcucha bloków ani bazy danych. Narzędzia stanowią połączenie pomiędzy nimi. Specjalista od kryptowalut może mieć dostęp do interfejsów RPC dla łańcuchów bloków, API z danymi rynkowymi, agregatorów DEX, narzędzi do tworzenia indeksów, baz danych dotyczących ryzyka, infrastruktury portfeli oraz wewnętrznych systemów finansowych, dostępnych poprzez funkcje takie jak get_balance(), read_contract(), estimate_gas(), simulate_transaction() i submit_transaction().
Przysługuj każdemu agentowi tylko tyle uprawnień, ile jest konieczne do wykonywania jego funkcji. Agent badawczy może potrzebować jedynie funkcji read_market_data() i read_protocol_data(). Agent wykonawczy może mieć dostęp do funkcji simulate_transaction() i submit_transaction(). Nie ma żadnego uzasadnienia, by przyznawać każdemu agentowi prawa do zarządzania portfelem lub transakcjami, a wąskie uprawnienia ograniczają szkody w przypadku nieprawidłowego zachowania lub kompromitacji jednego z agentów.
Granica pomiędzy sztuczną inteligencją a łańcuchem bloków
To może być najważniejszy aspekt projektowy produktów kryptograficznych. Wyniki modeli są probabilistyczne, podczas gdy wykonywanie operacji na łańcuchu bloków jest deterministyczne i często nie da się go cofnąć. Dlatego żaden agent nie powinien bezpośrednio kontrolować końcowej transakcji. Bezpieczniejsza ścieżka wygląda następująco:
```text
Agent Decision
↓
Schema Validation
↓
Policy Check
↓
Risk Check
↓
Transaction Simulation
↓
Authorization
↓
Signing
↓
Blockchain
```
Załóżmy, że agent postanawia zamienić 50 000 USD w USDC na ETH. Warstwa wykonawcza powinna niezależnie sprawdzić, czy USDC jest zatwierdzonym aktywem, a ETH zatwierdzonym miejscem przelewu, czy kwota mieści się w limicie użytkownika, czy rozchylenie cenowe jest akceptowalne, czy adresat jest prawidłowy, czy transakcja działa poprawnie, oraz czy użytkownik musi ją zatwierdzić. Agent proponuje działanie, a warstwa deterministyczna decyduje, czy może ono dojść do skutku. Systemy finansowe opierają się na takim podziale obowiązków.
Zasady bezpieczeństwa i radzenie sobie z awariami
Każdą decyzję sztucznej inteligencji należy otoczyć deterministycznymi ograniczeniami. Konfiguracja może określać: maksymalną kwotę transakcji na poziomie 50 000 dolarów, maksymalne rozchylenie cenowe na 0,5%, minimalną płynność na poziomie 5 milionów dolarów, a dozwolone łańcuchy blockchain – Ethereum, Arbitrum i Base. Model sztucznej inteligencji nie może obejść tych ograniczeń poprzez zmianę sformułowania odpowiedzi.
Pamiętaj również, że poprawna struktura nie jest dowodem na poprawną treść. Wynik taki jak {"risk_score": 0.04} może być doskonale sformatowany, a mimo to opierać się na całkowicie błędnym rozumowaniu. System produkcyjny powinien sprawdzać format, zasady biznesowe, aktualność danych, wiarygodność źródeł oraz wyniki końcowych wywołań narzędzi:
```text
Agent Output
↓
Schema Validation
↓
Business Validation
↓
Data Validation
↓
Tool Execution
↓
Result Verification
```
Idempotencja. Rozważmy sytuację, gdy przesłanie danych się timeoutuje. Agent może uznać, że transakcja nie powiodła się, i spróbować ponownie, choć pierwsza próba mogła się udać, co doprowadziłoby do powtórzenia tej samej operacji finansowej. Usługa wykonawcza powinna przypisać każdej prośbie unikalny identyfikator, na przykład exec_829192, i powiązać go z powstałą transakcją. Gdy ta sama prośba pojawi się ponownie, usługa zwraca już istniejący wynik i nie wysyła nic nowego. W procesach finansowych ta właściwość nie jest opcjonalna.
Obserwowalność
Zwykłe logi nie wystarczają w systemach agentowych, ponieważ inżynierowie potrzebują pełnej ścieżki decyzyjnej. Dla każdego kroku należy odnotować, który agent go wykonał, jakiego modelu użył, jakie narzędzia i z jakimi parametrami wywołał, co wróciło, które zasadnicze reguły zostały uruchomione, ile czasu zajęło każdy krok oraz która transakcja ostatecznie została wysłana. Gdy transakcja zawodzi, należy móc określić, kto podjął decyzję, na podstawie jakich danych, która zasada ją zatwierdziła, w jaki sposób została utworzona transakcja oraz co faktycznie wydarzyło się w łańcuchu bloków. Bez takiego poziomu przejrzystości uruchamianie tych systemów w produkcji staje się domysłem.
Oprócz tego, w wersji produkcyjnej konieczne jest dodanie mechanizmów kontroli tożsamości i dostępu, bezpiecznego przechowywania kluczy, magazynu stanu, ograniczeń przepustowości, monitoringu, testów oceniających oraz śledzenia działań. Wersje demonstracyjne nigdy ich nie pokazują, a jednak one decydują o tym, czy rozwiązanie będzie skuteczne w skali przedsiębiorstwa.
Systemy rozproszone z LLM w środku
Najlepszym sposobem na zrozumienie tego wyzwania jest przestanie traktowania systemu wielu agentów jako zbiór chatbotów. Jest to system rozproszony, w którym niektóre decyzje są podejmowane probabilistycznie przez model, więc nadal obowiązują wszystkie klasyczne kwestie: zarządzanie stanem, autoryzacja, uprawnienia, współbieżność, ponawianie prób, idempotencja, przywracanie po awariach, walidacja danych oraz możliwość obserwacji.
Model stanowi warstwę rozumowania, a architektura – warstwę kontrolną. Gdy w grę wchodzą rzeczywiste aktywa i nieodwracalne transakcje, ta różnica ma ogromne znaczenie. Dobrze zaprojektowany system nie dąży do nieograniczonej autonomii – dąży do kontrolowanej autonomii: agenty mogą swobodnie rozumować, współpracować i dostosowywać się, podczas gdy deterministyczne oprogramowanie odpowiada za uprawnienia, limity finansowe, walidację i wykonywanie zadań.
Główny wniosek
Wartość nie leży w posiadaniu kilku modeli, ale w dzieleniu złożonych procesów pracy na mniejsze, specjalistyczne jednostki, które można kontrolować. W przypadku kryptowalut typu B2B zasada ta można sformułować prosto:
- Rozumowanie należy do agentów.
- Pobieranie danych i wykonywanie operacji należy do narzędzi.
- Koordynacja należy do orkiestratora.
- Zasady biznesowe są egzekwowane za pomocą polityk.
- Transakcje przechodzą przez warstwę wykonawczą, która je kontroluje.
- Ostateczne rozliczenie odbywa się bezpośrednio na łańcuchu bloków.
Gdy te obowiązki są oddzielone, system jest łatwiejszy do skalowania, testowania, zabezpieczania i audytowania. Celem nie jest sprawienie, by sztuczna inteligencja wyglądała na inteligentną, lecz aby złożone procesy oparte na AI były wystarczająco niezawodne do użycia w produkcji.
Podobne materiały
- Jak subagenty i systemy wielu agentów dzielą prace oraz koszty tokenów — Proste wyjaśnienie różnic między subagentami a systemami wielu agentów, projektu orkiestrator-pracownik, czterech topologii, kosztów tokenów oraz sytuacji, gdy jeden agent jest lepszym wyborem.
- Projektowanie narzędzia do wyszukiwania zadań dla systemów wielu agentów: pipeline, HyDE i możliwości obserwacji — Dziewięciostopniowy pipeline LangGraph służący do dopasowywania CV do ofert pracy, wraz z osiemią opcjami projektowymi dotyczącymi HyDE, routingu modeli, ograniczeń szybkości i śledzenia procesów.