Создание максимально стабильной автоматизированной торговой системы: от бэктеста до реального бота
- Разбор охватывает цепочку: бэктест стратегии → подбор параметров → запуск бота в реальном времени на бирже BingX.
- Указано, что система находится в тесте около 2 недель; текущий результат — +5% к капиталу бота, при этом возможна и потеря капитала.
- Данные для расчётов берутся с Binance (заявлено: бесплатно и без API-ключей), исполнение сделок — на BingX (Perpetual Futures; заявлены низкие комиссии).
- Стратегия использует набор индикаторов (Ichimoku, CCI, ADX, RSI, NATR, BBW, MA) и торгует на 1-часовом таймфрейме; пример пары — SOLUSDT.
- Управление позицией описано через TP/SL, перенос стопа в безубыток и риск 1% капитала на сделку с динамическим расчётом объёма.
- Система разделена на три скрипта: main.py (бэктест/оптимизация), bingx_client.py (клиент API), realtime.py (бот в реальном времени); в бэктесте учтены комиссии и используется multiprocessing.
Почему это важно: Схема из текста демонстрирует, как в одном проекте связаны исследование на исторических данных и эксплуатация в реальном времени. Это помогает обсуждать воспроизводимость результатов и то, где именно появляются комиссии, задержки и ограничения API. Отдельно подчёркнут свечной подход к симуляции, который приближает бэктест к логике работы бота на потоке данных.
На что обратить внимание: В описании прямо говорится о регулярной подгонке параметров и периодической замене монеток, поэтому эффект может зависеть от выбранного периода и набора инструментов. Тестовый срок указан как около двух недель, из-за чего устойчивость результатов на других отрезках остаётся открытым вопросом. В кодовых фрагментах встречаются упрощения и заглушки (например, fallback по балансу), а часть фильтров включается флагами, что влияет на интерпретацию итогов. В качестве будущих улучшений в тексте упоминаются мониторинг через Telegram-бота для алертов и развитие walk-forward бэктеста.
Коротко
- Показан приём постраничной загрузки свечей (до 5000) для обхода лимитов API, что удобно в бэктестах, где история забирается партиями.
- В логике симуляции есть флаги allow_long/allow_short и их сброс по условиям облака Ichimoku; это влияет на частоту входов и повторяемость сигналов.
- Клиент BingX демонстрирует типовой паттерн HMAC-подписи запросов и открытие рыночного ордера с прикреплёнными SL/TP в одном вызове API.
- Реалтайм-часть поддерживает скользящее окно (tail 700) и пересчитывает индикаторы на закрытии свечи; в таких схемах обычно важны логи и обработка ошибок.
- Автор пишет о постоянной подстройке параметров и замене монеток; на практике это часто поднимает вопрос устойчивости и проверки на других периодах, чтобы не переобучиться.
FAQ
Зачем это важно: что показывает разбор цикла «бэктест → оптимизация → запуск реалтайм-бота», и почему автор отдельно акцентирует приближение к реальной торговле?
Текст на одном примере показывает, как связать проверку стратегии на исторических данных с запуском бота в реальном времени и где учитываются комиссии и логика выхода. Автор подчёркивает пошаговую симуляцию по свечам как более близкую к поведению в реальной торговле.
Почему в примере используются две площадки — Binance для данных и BingX для исполнения ордеров, и какие аргументы автор приводит для такого разделения?
Binance используется как источник свечей: в тексте сказано, что данные бесплатные и не требуют API-ключей. BingX выбран для торговли Perpetual Futures и из-за заявленных низких комиссий.
Как в статье устроены входы/выходы и контроль риска: какие уровни TP/SL, безубыток и расчёт размера позиции описаны на уровне правил стратегии?
Входы построены на пересечении CCI (+98 для long и −98 для short) с фильтрами других индикаторов и условиями относительно облака Ichimoku. Выходы описаны через TP/SL, перенос стопа в безубыток при достижении триггера и риск 1% капитала на сделку с динамическим расчётом объёма.
Из каких модулей состоит система и что делает каждый: какие задачи отнесены к main.py, bingx_client.py и realtime.py в описании проекта?
main.py отвечает за бэктест и оптимизацию параметров на истории, включая перебор конфигураций и построение equity curve. bingx_client.py оборачивает API BingX (подпись, ордера, SL/TP), а realtime.py получает свечи через WebSocket Binance и открывает/закрывает сделки на BingX.
Читайте также
Как тимлид заменил десятки вкладок на файловую систему и Claude Code- Динамический ресайзинг изображений (Image Previewer)
- Как написать юзербота для MAX: Green-API, автоматизация рутины и примеры кода
- От хаоса к системе: как выстроить процесс Discovery (часть 1)
- LLM-агент для поиска свободных доменов: автоматизация подбора
- Постраничная загрузка свечей для обхода лимита API: Если API отдаёт свечи порциями (в примере лимит 1000), историю можно добирать постранично, двигая endTime назад и накапливая данные до нужного лимита (в тексте — до 5000). Такой подход помогает стабильно получать фиксированный объём истории для бэктеста и снижает риск «обрезанных» выборок из-за ограничений API.
[Инструменты: загрузка данных и API]
Зарегистрированные пользователи видят только два тезиса.
Зарегистрироваться
Автор описывает полный цикл создания торговой системы на Python: от бэктеста и оптимизации до запуска реалтайм-бота, который берёт данные с Binance и торгует на BingX. В тексте подчёркивается, что система тестируется около 2 недель и показывает +5% к капиталу, но риск потери сохраняется.