Недавно ко мне обратился знакомый — торгует криптой на любительском уровне — и попросил “написать торгового робота”. Тут важно остановиться на терминологии. В разговоре всё это называют роботами, но на практике чаще нужен торговый советник
Советник анализирует рынок и выдаёт рекомендации: где входить, где ставить стоп, где лучше вообще ничего не делать.
Робот делает следующий шаг за вас — и сам открывает/закрывает позиции.
И вот почему “давай сразу робота” — обычно плохая идея. Пока алгоритм не отлажен, риск потери денег максимальный: ошибка в анализе, баг в логике, неверная обработка свечи/ордера — и робот спокойно сделает ровно то, что вы бы не сделали руками.
Поэтому разумная стратегия почти всегда одна: сначала советник (анализ + сигналы), потом — автоматизация исполнения, и то если есть статистика и контроль рисков.
О чём статья: архитектура торгового советника
В этой статье — без “сигналов на миллион” и без обещаний доходности — только теория: из чего вообще собирается торговый советник, как выглядит его архитектура и почему в ней важны границы ответственности.
Внутрь алгоритмов анализа мы глубоко не уходим — задача статьи другая: показать, какие компоненты обычно есть у советника и как они стыкуются между собой.
Для “мозга”, который интерпретирует данные и формулирует выводы, сегодня часто выбирают готовые LLM-сервисы: ChatGPT, Gemini, Grok. При желании их можно дообучать или заменить своей моделью, но для архитектуры это вторично.
Нюанс остаётся тем же: нейросеть не читает ваши мысли. Ей нужен промпт — внятный, формализованный и повторяемый.
Промпт — это текстовая инструкция (и контекст), которую вы передаёте модели: что за данные перед вами, что именно нужно сделать и в каком формате вернуть ответ.
И ещё нужны данные, с которыми мы будем работать.
Здесь дальше главный вопрос: что именно класть в промпт (свечи, индикаторы, стакан, сделки, контекст риска) и в каком виде.
Данные и API
Про промпт поговорим позже, а сейчас — о данных.
Начальный уровень выглядит просто:
- Получить данные о курсах (котировки).
- Скомпоновать их с контекстом запроса.
- Передать это в промпт нейросети — через тот самый API.
Почти все биржи дают доступ к котировкам программно. И да — тоже через API.
Давайте на минуту отвлечёмся и уясним, что мы вообще называем API, раз слово уже встречается несколько раз и дальше будет встречаться постоянно.
API (Application Programming Interface) — это интерфейс взаимодействия между программами.
На практике это “правила игры”:
- какие запросы можно сделать (например: получить свечи, получить ордербук);
- в каком формате передавать данные (часто JSON);
- как выглядит ответ (структура полей, ошибки, лимиты, авторизация).
Проще говоря: API позволяет вам пользоваться возможностями биржи (или нейросети) как набором функций, не влезая внутрь реализации.
Пользовательский слой: как показывать результат
Итак, на этом этапе у нас уже есть два базовых компонента:
- данные (мы берём их с биржи);
- аналитик (нейросеть, которой мы скармливаем данные и получаем вывод/сигнал).
Но приложение, которое само в себе получает данные и само их анализирует, бесполезно до тех пор, пока результат не увидит человек.
Значит нужен третий компонент — интерфейс.
Самый простой и универсальный вариант — веб-интерфейс: график, последние сигналы, объяснение “почему так”, настройки риска.
Как опция — уведомления в мессенджеры (например, Telegram): краткий сигнал + ссылка на подробности в вебе.
Контекст поверх цены: новости
Для базовой версии этого достаточно, но если хочется глубже — можно добавить ещё один слой контекста: новости.
Идея простая: мы собираем релевантные новостные статьи и добавляем их в промпт. Обычно — не “сырьём”, а в виде коротких саммари (чтобы не забивать контекст и не улетать в токены).
Это не обязательная часть архитектуры, но в некоторых режимах она заметно повышает качество советов: модель начинает учитывать причины движения, а не только форму графика.
Как увязать всё вместе
Окей, модули понятны. Вопрос теперь практический: как это собрать в единое приложение.
На практике почти всегда получается два режима.
Анализ по запросу
Пользователь нажал кнопку (или дёрнул endpoint) → мы подтянули свежие котировки → собрали промпт → получили ответ модели → показали сигнал.
- Плюсы: экономно по токенам/ресурсам, проще отлаживать.
- Минусы: вы гарантированно пропускаете часть событий между запросами — вместе с ними пропускаются и точки входа.
Регулярный анализ по расписанию
Пользователь задаёт периодичность (например, раз в 5 минут/час/день) → система сама гоняет конвейер и пушит результат.
- Плюсы: сигналы приходят регулярно, можно держать “пульс рынка”, легче собирать статистику.
- Минусы: дороже (токены/инфраструктура), нужны лимиты и защита от “самострела” (rate limit, ретраи, дедупликация сигналов), плюс обязательны мониторинг и логирование — иначе вы не поймёте, почему в 03:17 всё внезапно замолчало.
В любом из режимов набор базовых компонентов одинаковый:
- web-сервер (интерфейс и API для пользователя);
- модуль биржевых данных (котировки, свечи, при необходимости — стакан/сделки);
- модуль LLM (сбор промпта → вызов модели → парсинг ответа);
- хранилище (настройки пользователя, история сигналов, кэш котировок, результаты анализа).
И нужен один “клей”, который всё это связывает: сущность уровня приложения — назовём её core/service — которая управляет зависимостями, жизненным циклом и сценариями (по запросу или по расписанию).
На перспективу почти всегда выгодно заложить плагинный подход:
- плагины для источников котировок (добавили новую биржу — не переписываем остальное);
- плагины для LLM-провайдеров (появилась новая модель/поменялись тарифы — меняем адаптер, а не архитектуру).
Примечание: здесь планируется схема архитектуры (диаграмма) — в этой версии HTML она намеренно не вставлена.
Дальше можно уже приземляться на реализацию: какие интерфейсы у модулей, какие структуры данных, и где проходит граница между “советником” и “торговым роботом”.
По материалам itprolab.dev
Читайте также
EthBackNode: зачем вашему приложению “прокладка” между ним и Ethereum-нодой
Если вы когда-либо пробовали написать крипто-кошелёк, платёжный шлюз или просто “бэкенд, который умеет отправлять и принимать ETH”, то довольно быстро выясняется неприятная вещь: Ethereum-нода — это не ваш бэкенд
Сканер блоков (Blockchain explorer) своими руками: немного теории
В прошлой статье мы рассмотрели причины, по которым нам может понадобится свой blockexplorer. Замечу, что список этот далеко не полный, но будем считать, что мы определились - нам нужен свой источник данных о транзакциях и их связях с адресами.