Разработка мультиагентной торговой системы

Разработка мультиагентной торговой системы

Мультиагентные торговые системы — это архитектурный подход, при котором вместо одного монолитного бота работает сеть независимых агентов, каждый из которых отвечает за конкретную задачу. Такой подход сложнее в реализации, но даёт качественно иной уровень гибкости, масштабируемости и устойчивости к сбоям.

Почему мультиагентность, а не монолит

Монолитный торговый бот со временем превращается в клубок зависимостей. Добавить новый инструмент или стратегию — значит переписывать 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 для критических путей валидации.

Жизненный цикл торгового решения

Рассмотрим путь от рыночного события до исполненного ордера:

1. Market Data Agent получает tick по BTC/USDT с Binance WebSocket
2. Событие публикуется в Redis Stream с нормализованным форматом {exchange, symbol, price, volume, timestamp}
3. Signal Agent потребляет поток, обновляет rolling-window индикаторов (EMA, RSI, ATR)
4. При срабатывании условия стратегии публикует сигнал {direction: LONG, size: 0.1, confidence: 0.78}
5. Risk Agent проверяет: не превышен ли дневной лимит потерь, не коррелирует ли позиция с уже открытыми
6. Execution Agent получает одобренный ордер, выставляет limit order на бирже
7. Portfolio Agent обновляет состояние через WebSocket-подтверждения от биржи

Весь путь — порядка 50–150ms при правильной реализации.

Управление состоянием и отказоустойчивость

Каждый агент должен быть stateless или иметь воспроизводимое состояние. Если Execution Agent упал и перезапустился, он должен уметь восстановить актуальное состояние ордеров через REST API биржи, не дожидаясь следующего WebSocket-события.

Паттерн event sourcing здесь особенно ценен: вместо хранения текущего состояния хранится лог всех событий. Состояние — лишь материализованное представление этого лога. Это даёт бесплатный аудит-трейл и возможность "откатиться" к любому моменту времени.

Circuit breaker на каждом агенте защищает от каскадных отказов. Если биржевой API начинает отвечать с задержками или ошибками, Execution Agent переходит в degraded mode: прекращает открывать новые позиции, но продолжает мониторить открытые.

Технологический стек

Масштабирование и деплой

Горизонтальное масштабирование агентов — одно из ключевых преимуществ архитектуры. Signal Agent для разных инструментов можно запустить в нескольких инстансах, распределив инструменты через партиционирование Kafka-топиков. Execution Agent масштабируется по количеству целевых бирж.

Kubernetes с HPA (Horizontal Pod Autoscaler) автоматически масштабирует инстансы агентов по метрикам latency и queue depth. Это особенно важно в периоды высокой волатильности, когда поток рыночных событий резко возрастает.

Тестирование

Unit-тесты для бизнес-логики каждого агента. Integration-тесты — на уровне взаимодействия агентов через шину. И обязательно — chaos testing: намеренное убийство агентов в production-like окружении, чтобы убедиться, что система корректно восстанавливается. Инструменты типа Chaos Monkey или Toxiproxy для симуляции сетевых проблем между агентами — стандартная часть процесса.

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