Розробка багатоагентної торговельної системи
Багатоагентні торговельні системи — це архітектурний підхід, при якому замість одного монолітного бота працює мережа незалежних агентів, кожен з яких відповідає за конкретне завдання. Такий підхід складніший у реалізації, але дає якісно інший рівень гнучкості, масштабованості та відмовостійкості.
Чому багатоагентність, а не моноліт
Монолітний торговельний бот з часом перетворюється на клубок залежностей. Додати новий інструмент або стратегію — означає переписати core-логіку і ризикувати регресією всього іншого. Багатоагентна архітектура вирішує це через принцип однієї відповідальності: кожен агент робить одне, робить це добре і спілкується з іншими через чіткий протокол.
У типовій системі агенти ділються за ролями:
- Market Data Agent — підписується на потоки даних (WebSocket з Binance, Bybit, OKX), нормалізує формат і публікує події в шину
- Signal Agent — отримує нормалізовані дані, запускає стратегії і генерує торговельні сигнали
- Risk Agent — валідує кожен сигнал: перевіряє ліміти позицій, drawdown, кореляцію з відкритими позиціями
- Execution Agent — отримує схвалені ордери, управляє їх життєвим циклом на біржі
- Portfolio Agent — агрегує стан усіх позицій, розраховує P&L у реальному часі
Комунікаційна шина
Зв'язок між агентами — критичне архітектурне рішення. Існує кілька підходів:
Message Queue (RabbitMQ, Redis Streams, Kafka) — найбільш поширений вибір. Агенти публікують події і підписуються на топіки. Kafka особливо хорош, якщо потрібна воспроізводимість: ви можете "переграти" історичний потік подій для отладки або бектестингу прямо на production-інфраструктурі.
gRPC — підходить для синхронних викликів з жорсткими вимогами до latency, наприклад, коли Risk Agent повинен дати відповідь "approve/reject" за мілісекунди.
Shared State через Redis — простий варіант для невеликих систем, але створює приховані залежності і ускладнює горизонтальне масштабування.
Ми рекомендуємо гібридний підхід: асинхронна шина для потоків даних і сигналів, синхронний gRPC для критичних шляхів валідації.
Життєвий цикл торговельного рішення
Розглянемо шлях від ринкової події до виконаного ордера:
- Market Data Agent отримує tick по
BTC/USDTз Binance WebSocket - Подія публікується в Redis Stream з нормалізованим форматом
{exchange, symbol, price, volume, timestamp} - Signal Agent споживає потік, оновлює rolling-window індикаторів (EMA, RSI, ATR)
- При спрацюванні умови стратегії публікує сигнал
{direction: LONG, size: 0.1, confidence: 0.78} - Risk Agent перевіряє: не перевищений ліміт щоденних втрат, позиція не корелює з уже відкритими
- Execution Agent отримує схвалений ордер, виставляє limit order на біржі
- Portfolio Agent оновлює стан через WebSocket-підтвердження від біржі
Весь шлях — близько 50–150ms при правильній реалізації.
Управління станом і відмовостійкість
Кожен агент повинен бути stateless або мати воспроізводимий стан. Якщо Execution Agent впав і перезапустився, він повинен вміти відновити актуальний стан ордерів через REST API біржі, не чекаючи наступної WebSocket-події.
Паттерн event sourcing тут особливо цінний: замість зберігання поточного стану зберігається лог усіх подій. Стан — лише матеріалізоване представлення цього логу. Це дає безплатний аудит-трейл і можливість "відкатитись" до будь-якого моменту часу.
Circuit breaker на кожному агенті захищає від каскадних відмов. Якщо біржевий API починає відповідати з затримками або помилками, Execution Agent переходить у degraded mode: припиняє відкривати нові позиції, але продовжує моніторити відкриті.
Технологічний стек
| Компонент | Рекомендоване рішення |
|---|---|
| Агенти | Python (asyncio) або Go |
| Message Bus | Kafka або Redis Streams |
| State Storage | Redis + PostgreSQL (TimescaleDB) |
| Оркестрація | Kubernetes + Helm |
| Моніторинг | Prometheus + Grafana |
| Трейсинг | OpenTelemetry + Jaeger |
Масштабування і розгортання
Горизонтальне масштабування агентів — одна з ключових переваг архітектури. Signal Agent для різних інструментів можна запустити в кількох інстансах, розподіливши інструменти через партиціонування Kafka-топіків. Execution Agent масштабується за кількістю цільових бірж.
Kubernetes з HPA (Horizontal Pod Autoscaler) автоматично масштабує інстанси агентів за метриками latency і queue depth. Це особливо важливо в періоди високої волатильності, коли потік ринкових подій різко зростає.
Тестування
Unit-тести для бізнес-логіки кожного агента. Integration-тести — на рівні взаємодії агентів через шину. І обов'язково — chaos testing: навмисне вбивство агентів у production-like окруженні, щоб впевнитися, що система коректно відновлюється. Інструменти типу Chaos Monkey або Toxiproxy для симуляції мережевих проблем між агентами — стандартна частина процесу.
Результат — торговельна система, яку можна розширювати без страху зламати те, що працює, яка переживає збої окремих компонентів і яку можна отладжувати через воспроізведення реальних подій.