Всередині багатоагентної системи: примітки щодо архітектури для розробників криптовалют

Уявіть криптовалютну компанію, яка продає свої послуги бізнесам та потребує програмного забезпечення, яке стежить за протоколами DeFi, оцінює ліквідність, аналізує ризики смарт-контрактів, відновлює баланс казни, позначає незвичайні транзакції та навіть виконує операції згідно з заздалегідь встановленими правилами. Один ШІ-агент, якому доручено виконувати всі ці завдання, швидко опиняється під надмірним тиском. Йому доводиться читати дані ринку, запитувати інфраструктуру блокчейну, оцінювати ризики, викликати API, приймати рішення щодо заробітку та підписувати транзакції — усе це в межах одного циклу міркувань. Тестування, масштабування та забезпечення безпеки такої системи дуже швидко стають складними завданнями.

Звичайна відповідь — розділити роботу між спеціалізованими агентами та додати верхній шар оркестрації. Це більше, ніж просто кілька мовних моделей, які спілкуються між собою. Це програмна архітектура, у якій міркування моделі, логіка додатку, дані, інструменти, дозволи та процес виконання навмисно тримаються окремо. Далі буде розглянуто, як ці елементи взаємодіють та що слід враховувати розробникам продакшн-систем у цій галузі.

Що вважається багатоагентною системою

Кілька спеціалізованих агентів, які співпрацюють над завданням, більшим за те, що може обробити кожен з них окремо: ось так визначається цей тип системи. Корисна формула для одного агента:

Агент = модель ШІ + інструкції + контекст + інструменти + стан + цикл виконання

Для групи можна додати ще один шар:

Агенти + оркестрація + спільний стан + комунікація + політики

Платформа для управління казною може використовувати такий склад елементів:

1. Агент з досліджень, який збирає дані про протокол та ринок.
2. Агент з оцінки ризиків, який аналізує ризики, пов’язані з контрактами, ліквідністю та протоколом.
3. Агент з управління портфелем, який порівнює можливості та розраховує розподіл коштів.
4. Агент з дотримання правил, який застосовує бізнес-правила компанії.
5. Агент з виконання операцій, який підготовлює та подає заявки на транзакції.
6. Агент з моніторингу, який перевіряє на ланцюзі те, що насправді сталося.

Візьмемо таку інструкцію: вкласти 50 000 USDC у найбезпечніший варіант з дохідністю, який пропонується, за умови, що протокол відповідає політиці управління ризиками та витрати на виконання залишаються нижче 0,5%. Це вимагає кількох різних навичок, тому система перетворює цей процес на послідовну схему дій:

```text
User Request
     ↓
Orchestrator
     ↓
Research Agent
     ↓
Risk Agent
     ↓
Portfolio Agent
     ↓
Policy Check
     ↓
Execution Agent
     ↓
Blockchain
     ↓
Verification
```

Кожен агент вирішує невелику проблему, і жоден з них не повинен вирішувати весь процес роботи.

Шари системи виробництва

Сім елементів зустрічаються знову та знову: середовище виконання агента, оркестратор, спільний стан, шар інструментів, шар політик та безпеки, інфраструктура виконання та можливості моніторингу. Кожен з них відповідає на окреме інженерне питання.

Середовище виконання агента

Середовище виконання запускає один агент. У умовах виробництва агент — це більше, ніж просто вхідний запит та вихідна відповідь. Він функціонує як цикл:

  ```text
Input
 ↓
Build Context
 ↓
Ask Model to Reason
 ↓
Choose Action
 ↓
Call Tool / Agent / Return Result
 ↓
Receive Result
 ↓
Update Context
 ↓
Reason Again
```

Уявімо, що від агента з досліджень просили порівняти протоколи позикування в DeFi. Він би отримав список протоколів, збирав би їхній поточний TVL, дізнавався б ставки за позики, порівнював би ліквідність, обирав би найкращі варіанти та передавав їх агенту з управління ризиками. Модель надає обґрунтування, тоді як програмне забезпечення, що її оточує, контролює те, що насправді виконується. Цей розмежування має значення, адже модель не повинна виконувати завдання, які краще виконує звичайне програмне забезпечення. Для множення суми $50,000 на 8.2% не потрібен LLM, оскільки звичайна функція працює швидше, дешевше та завжди дає однаковий результат.

Оркестратор

Оркестратор — це центр керування. Він вирішує, який агент буде працювати, що йому слід сказати, що буде виконуватися далі, які завдання можна виконувати паралельно, коли робота завершиться та що робити, якщо агент зазнає невдачі. Існує два основні стили роботи оркестратора.

Оркестрація, заснована на моделях. Керівна модель обирає необхідного спеціаліста.

           ```text
        Supervisor Agent
              │
        ┌─────┼─────┐
        ▼     ▼     ▼
   Research  Risk  Analytics
```

Керівник може вирішити, що спочатку потрібні дані протоколу, тож він викликає агента досліджень, а коли надходить результат, вирішує, що потрібна оцінка безпеки, і викликає агента ризиків. Це гнучко, проте маршрутизація може стати непередбачуваною, кількість додаткових викликів моделей зростає, а разом з ними — і витрати.

Оркестрація, керована кодом. Додаток визначає послідовність дій.

```text
Research
   ↓
Risk Analysis
   ↓
Policy Check
   ↓
Simulation
   ↓
Approval
   ↓
Execution
```

Ця версія простіша у тестуванні та керуванні.

Поєднання обох підходів. Для B2B фінансових продуктів найефективніша конфігурація часто поєднує їх. Нехай модель робить висновки, а код застосовує правила. Модель може дійти висновку, що протокол A забезпечує найкращу дохідність з урахуванням ризиків, тоді як додаток наполягає на тому, що будь-яка сума понад 50 000 доларів потребує додаткового схвалення. Штучний інтелект рекомендує, а програмне забезпечення забезпечує виконання.

Спільний стан

Агентам потрібно бачити результати попередніх кроків. Надсилання всієї розмови кожному з них марнує зусилля, тому система замість цього зберігає структурований запис про хід роботи.

Для запиту на USDC у цьому записі будуть вказані актив (USDC), сума (50000), мережа (Ethereum), список потенційних протоколів (Aave та Morpho) та три поля статусу (ризик, політика та виконання), які спочатку мають значення «очікується», «очікується» та «не розпочато».

Агент досліджень заповнює такі поля, як протоколи кандидатів, результати продуктивності та дані ринку. Агент ризиків додає оцінку та свої висновки щодо безпеки. Агент виконання бачить лише те, що потрібно для виконання його завдань. Структура є охайною:

               ```text
                Shared State
                    │
         ┌──────────┼──────────┐
         ▼          ▼          ▼
    Research      Risk     Execution
     Agent        Agent     Agent
        └──────────┼──────────┘
                   ▼
             Updated State
```

Спільний запис також значно спрощує призупинення, відновлення, аудит та виправлення проблем у робочому процесі.

Комунікація: передача обов’язків та агенти як інструменти

Агенти співпрацюють двома корисними способами. Під час передачі обов’язків керування переходить від одного агента до іншого.

```text
Research Agent
↓
Risk Agent
↓
Portfolio Agent
```

Передача обов’язків підходить у моменти, коли змінюється відповідальність: після завершення дослідження ринку агент, відповідальний за ризики, бере на себе оцінку кандидатів. Коли агента використовують як інструмент, один агент викликає іншого та зберігає контроль.

     ```text
      Supervisor
      /    |   \
 Research Risk Analytics
```

Керівник може попросити спеціаліста з ризиків перевірити протокол згідно з критеріями компанії, отримати структуровану відповідь та продовжити роботу. Це допомагає, коли одному центральному спеціалісту потрібно об’єднати кілька фахових думок.

Рівень інструментів

Спеціаліст не може самостійно працювати з блокчейном чи базою даних. Інструменти є засобом зв’язку. Крипто-спеціалісту можуть надати RPC-інтерфейси блокчейну, API з ринковими даними, агрегатори DEX, індексатори, бази даних ризиків, інфраструктуру гаманців та внутрішні системи казначейства, які доступні через такі функції, як get_balance(), read_contract(), estimate_gas(), simulate_transaction() та submit_transaction().

Надайте кожному агенту мінімальні права доступу, необхідні для виконання його функцій. Дослідницькому агенту може знадобитися лише read_market_data() та read_protocol_data(). Агенту, відповідальному за виконання, можуть бути надані simulate_transaction() та submit_transaction(). Немає жодних підстав надавати кожному агенту права на керування гаманцем чи транзакціями, а обмежені дозволи зменшують ризики у разі неналежної поведінки або компрометації.

Межа між ШІ та блокчейном

Це, можливо, найважливіший аспект проектування криптовалютних продуктів. Результати роботи моделі є ймовірнісними, тоді як виконання операцій у блокчейні є детермінованим та часто не піддається скасуванню. Тому жоден агент не повинен безпосередньо керувати остаточною транзакцією. Безпечніший підхід виглядає так:

```text
Agent Decision
     ↓
Schema Validation
     ↓
Policy Check
     ↓
Risk Check
     ↓
Transaction Simulation
     ↓
Authorization
     ↓
  Signing
     ↓
Blockchain
```

Уявіть собі, що агент вирішує обміняти 50 000 USDC на ETH. Шар виконання має незалежно перевірити, чи є USDC схваленим активом, а ETH — схваленим напрямком обміну, чи не перевищує сума ліміт користувача, чи є допустимим рівень зміщення ціни, чи правильний адресат, чи безпроблемно симулюється транзакція, та чи потрібно підписати її користувачем. Агент пропонує дію, а детерміністичний шар вирішує, чи може вона бути здійснена. Фінансові системи ґрунтуються саме на такому розділенні обов’язків.

Обмеження та обробка збоїв

Навколо кожного рішення ШІ необхідно встановити детерміністичні обмеження. У конфігурації може бути зазначено: максимальна сума транзакції — 50 000 доларів, максимальне зміщення ціни — 0,5%, мінімальна ліквідність — 5 мільйонів доларів, дозволені мережі — Ethereum, Arbitrum та Base. Модель не може обійти ці значення, змінивши формулювання відповіді.

Пам’ятайте також, що наявність правильної структури не є доказом коректного змісту. Результат у форматі {"risk_score": 0.04} може бути ідеально сформованим, проте ґрунтуватися на абсолютно хибних міркуваннях. Система обробки даних повинна перевіряти формат, бізнес-правила, актуальність даних, надійність джерел та результати фінальних викликів інструментів:

```text
Agent Output
     ↓
Schema Validation
     ↓
Business Validation
    ↓
Data Validation
    ↓
Tool Execution
    ↓
Result Verification
```

Ідемпотентність. Розглянемо ситуацію, коли подання запиту закінчується через тайм-аут. Агент може вирішити, що транзакція зазнала невдачі, і спробувати ще раз, проте перша спроба могла вже відбутися, що призведе до дублювання фінансової операції. Сервіс виконання має надавати кожному запиту унікальний ідентифікатор, наприклад exec_829192, та прив’язувати його до відповідної транзакції. Якщо такий самий запит надійде знову, сервіс повертає вже наявний результат та не надсилає нічого нового. У фінансових робочих процесах ця властивість є обов’язковою.

Спостережуваність

Звичайні журнали недостатні для систем агентів, оскільки інженерам потрібен повний шлях прийняття рішень. Для кожного кроку необхідно фіксувати, який агент його виконував, яку модель він використовував, які інструменти та з якими параметрами він запускав, що повернулося, які правила були активовані, скільки часу зайняв кожен крок та яка транзакція врешті-решт була відправлена. Коли транзакція зазнає невдачі, потрібно мати можливість сказати, хто прийняв рішення, на основі яких даних, яке правило її схвалило, як була створена транзакція та що насправді відбулося в мережі. Без такого рівня прозорості робота цих систем у продакшені перетворюється на здогадки.

Окрім основної частини, у продакшен-розгортанні необхідно додати контроль ідентичності та доступу, зберігання ключів, місце для зберігання стану системи, механізми обмеження навантаження, моніторинг, тестування та історію аудиту. Демо-версії ніколи не демонструють цього, проте саме це визначає, чи може система працювати у масштабах корпорації.

Розподілені системи з LLM всередині

Найясніший спосіб побачити цю проблему — це припинити розглядати багатоагентну систему як набір чат-ботів. Це розподілена система, де деякі рішення приймаються моделлю імовірнісним чином, тому всі класичні проблеми залишаються актуальними: керування станом, автентифікація, авторизація, конкурентність, повторні спроби, ідемпотентність, відновлення після збоїв, перевірка даних та можливість спостереження.

Модель є шаром міркувань, а архітектура — шаром керування. Коли на кону стоять реальні активи та незворотні транзакції, ця різниця має величезне значення. Добре створена система не прагне необмеженої автономії; вона прагне контрольованої автономії: агенти можуть вільно міркувати, співпрацювати та адаптуватися, тоді як детерміністичне програмне забезпечення відповідає за дозволи, фінансові обмеження, перевірку та виконання.

Висновок

Справа не в наявності кількох моделей. Суть полягає у розбитті складних робочих процесів на менші, спеціалізовані одиниці, які можна керувати. Для B2B-криптовалют цей принцип можна сформулювати просто:

• Міркування належать агентам.
• Отримання даних та виконання операцій — інструментам.
• Координація — оркестратору.
• Бізнес-правила забезпечуються політиками.
• Транзакції проходять через шар виконання, який їх контролює.
• Остаточне врегулювання відбувається безпосередньо на блокчейні.

Як тільки ці обов’язки стають окремими, систему легше масштабувати, тестувати, захищати та аудитувати. Мета не в тому, щоб AI виглядала розумною. Мета — зробити складні робочі процеси, що керуються AI, достатньо надійними для використання в промислових умовах.