QuantMind: an AI-native quant research desk wired to Chinese broker terminals

What QuantMind bundles around Qlib, RD-Agent and TradingAgents

The pitch is a full research-to-execution loop, and the README states it as one line of text that reads like a flow diagram: data layer, factor mining, model training, batch inference, portfolio backtest, live trading through QMT or Tongdaxin, then production monitoring. Most open quant projects stop somewhere in the middle of that list.

The tree shows the assembly rather than hiding it. `rd-agent/` and `alphaagent/` sit beside `backend/`, `TradingAgents-astock/` holds an A-share adaptation of a multi-agent research framework, and `qmt-bridge-kit.zip` plus `bridge/` cover the broker side. There is also `prompts/`, `skills/`, `skills-lock.json`, `AGENTS.md` and `CLAUDE.md`, which tells you the project is meant to be worked on by AI coding agents as much as by humans. `strategy_templates/` and `user_strategies/` are separate, so shipped examples and your own code do not mix.

It covers A-shares, Hong Kong, US equities, futures and crypto from one install. The data claims lean on a QuantDB hub with 300 plus precomputed L1 and L2 microstructure features, stored as Parquet and queried through DuckDB, which is why the model zoo can use granular features without you building a feature store first.

The honest comparison is with running Qlib yourself. Qlib is a research library you script; QuantMind keeps it as the backtest engine but adds the web console, the data sync, the model trainer, the signal center and the broker bridge around it. If your plan is a notebook and one backtest, QuantMind is a large amount of infrastructure to adopt. If your plan is a desk where several people share signals and someone has to place orders, that infrastructure is the point.

Deployment is one piped shell script and three ports

The primary install path is a remote script piped into a shell with root, hosted on Gitee rather than GitHub:

curl -fsSL https://gitee.com/qusong0627/QuantMind/raw/master/deploy/full-deploy.sh | sudo bash
curl -fsSL https://gitee.com/qusong0627/QuantMind/raw/master/deploy/deploy.sh | sudo bash
sudo bash deploy/update.sh

The first command is the full deploy, which pulls prebuilt images plus business data, pretrained models, Qlib data and a PostgreSQL initialization backup, verifies and restores them. The second is the lighter source deploy without data. The third updates an existing install without clearing the database or model assets, which is the line to care about for day two.

Ubuntu 22.04 or 24.04 is the stated target. After deploy, the console listens on port 3000, the API gateway on port 8000, and Swagger documentation at the `/docs` path on the gateway. Everything else lives in `docs/部署指南.md`, which the README defers to for `.env` setup, AutoDL GPU training nodes, data directories and troubleshooting.

Running it under root from a piped download is worth naming as a tradeoff. It is the fastest route to a working stack and it is how Chinese self-hosted projects conventionally ship, but it means the install trusts a script hosted on a third-party git service that can change after you pin it. Clone the repository, read `deploy/full-deploy.sh`, and run it yourself if that matters to you.

Postgres, Redis with noeviction, and a CPU-first torch wheel

`docker-compose.yml` is where the operational thinking shows. Three services: `postgres:15-alpine` named `quantmind-db` with a `pg_isready` healthcheck and its port bound to `127.0.0.1` only, `redis:7-alpine` with appendonly on and 512mb maxmemory, and the core `quantmind` service built from `docker/Dockerfile.oss` as a single image that runs every backend service inside one container.

Redis carries a comment that explains itself: the same instance handles the Celery broker and result backend, and `allkeys-lru` would silently evict queued messages under memory pressure, showing up as scheduled jobs that never ran. So the compose command pins `--maxmemory-policy noeviction`. That is the kind of detail that tells you someone hit the bug.

The build arguments are also revealing. `TORCH_DEVICE` defaults to `skip` with `TORCH_CPU_INDEX_URL` pointing at the PyTorch CPU wheel index, which means a default build ships without CUDA support and you add GPU capability deliberately. `QM_REQ_SHA` lets you pin the requirements revision, and `APT_MIRROR` defaults to a Tsinghua mirror, again a China-speed default.

Both Postgres and Redis are published to loopback only. That is the right default, and it also means if you intend to reach them from another host you have to change the compose file rather than just open a firewall.

Market data arrives by API key or a 56 GB offline archive

Nothing works without history. Two documented paths, and the full deploy bundles the basics so you can skip this.

The online path binds a QuantDB API key in the web console under the personal center and data platform page, after which incremental sync is one command:

docker exec quantmind python backend/scripts/quantdb_daily_sync.py

The offline path is an archive of roughly 56 GB across about 130,000 files containing A-share history, QuantDB factors and precomputed L1 and L2 factors, distributed through Baidu Netdisk. It has to be extracted to a fixed path, because the container mounts `./data` as `/data` and reads from there:

cd /opt/quantmind/data/quantdb
7z x -y /path/to/quant_data.7z

`docs/QuantDB_数据包解压指南.md` covers the extraction in detail, and `.env.example` plus the deploy guide handle the directory wiring. If you are outside China, both routes have friction worth checking before you commit: one depends on a third-party data service and its key policy, the other on a consumer file-sharing service for 56 GB.

Alongside price history the README lists 24 hour RSS monitoring that matches event entities and scores sentiment as positive or negative. That is the kind of feature that sounds decisive in a demo and needs a real evaluation before you let it near a position.

Thirteen trainers with Optuna tuning and GPU offload to AutoDL

The model workbench covers LightGBM, XGBoost, CatBoost, GRU, LSTM, ALSTM, Transformer, TabNet, TCN and NativeTFT, with Optuna for hyperparameter search and stacking for ensembles. Beyond fitting models, it runs cross-sectional scoring across the whole market each day, keeps daily Rank IC and ICIR written back automatically, exposes SHAP feature importance, and raises data drift alerts. That last group is the difference between a demo and something you would leave running.

Compute is schedulable. Local CPU, local GPU, or a push to an AutoDL remote GPU cluster, which matters because the tree model path is cheap and the sequence models are not. The deploy guide covers AutoDL nodes as part of the environment setup.

Factor discovery is the LLM-driven piece, built on RD-Agent's AutoAlpha 2.0: you state a hypothesis in natural language, the pipeline synthesizes factor expressions, backtests them genetically, and promotes survivors into the store. TradingAgents-astock/ adds a multi-agent research layer for the qualitative side of the same question.

One caveat from the dependency list itself. `requirements.txt` carries an inline note next to `tigeropen` explaining that PyPI tops out at 3.7.1 and that a `>=7.0.0` pin had previously broken image builds. That is a small thing to read and a useful signal about the pinning discipline elsewhere in a file with 40 plus pinned and ranged packages.

Execution paths to MiniQMT and the Tongdaxin desktop link

Two ways reach a broker, and they serve different users.

The first is native MiniQMT through `xtquant`, with a separate Windows QMT agent desktop client and an encrypted WebSocket bridge for two-way traffic. The documented capabilities are synchronous and asynchronous order placement, protected limit orders, an anti-starvation cancel queue, account and position sync to the database, asynchronous fill callbacks from the counter, and a reconnect watchdog. This is the path with real money behind it, and it is the one to read twice before enabling.

The second is Tongdaxin integration for users already living in that terminal: cross-sectional stock picks pushed into a custom sector block, intraday warning radar popups, and double-click order entry with separate simulated and live modes. Local simulation adds T+1 matching, full order and position lifecycle, price limit and suspension filters, and a preflight check before the open.

For overseas brokers the requirements list names Tiger, Futu and IB via `tigeropen`, `futu-api` and `ib_async`. Note that the Tongdaxin path needs a Windows machine, since QMT ships as a Windows desktop client.

The honest limitation is that none of this is paper-only by default. The simulated mode exists and the preflight check exists, but the bridge is a general-purpose order path with no documented permission model, so the practical control is which endpoint the desktop client is pointed at and whether you flip it to live.

What AGPL-3.0 and a desktop-only 1.0.0 release commit you to

The licence is worth settling first. Repository metadata reports AGPL-3.0, the README badge says AGPL v3, and the `pyproject.toml` classifier says GNU Affero General Public License v3, with a `LICENSE` file in the tree. All four agree. The project description, however, advertises free commercial use with no further qualification. Those two things are not the same statement, because AGPL's defining obligation is source disclosure to users of a modified version offered over a network, which is exactly the shape of a hosted research platform. This is not legal advice; it is the reason to read the licence text before putting this behind a login page for other people.

The single release, version 1.0.0 published on 2026-05-07 as a desktop installer, is also narrower than the number suggests. Its own notes say the package is a frontend desktop client only, with no backend, and that you must already be running the server-side yourself before the client can connect to an IP and port you enter at first launch. The release description additionally reads as an unpublished draft, phrased as instructions to the publisher and still carrying unfilled placeholders for the issue tracker and community links. So 1.0.0 is a shell around a deployment you perform separately, not a turnkey build.

On cadence, the last push was on 2026-09-20, the repository is not archived, and the default branch is `master`. For anyone evaluating, the useful next step is narrow: run the full deploy on a spare Ubuntu host, log in, and confirm a factor sync and one Qlib backtest complete before wiring up any broker account. The last push date is the number to watch if you depend on it later, since there is no changelog beyond that single release note.

Editorial conclusion

QuantMind is unusual in how much of the quant stack it puts behind a login page: factor mining, Optuna tuning, cross-sectional scoring, event-driven backtesting and broker execution in one console, with the Qlib, RD-Agent and TradingAgents code visible as directories you can read. Two things decide whether it fits. First is the AGPL-3.0 licence, which the repository metadata, the README badge and the pyproject classifier all agree on, while the project description advertises free commercial use without qualification; for a hosted service that obligation is worth reading before you deploy. Second is data: the online path wants a QuantDB API key, and the offline path is a 56 GB, 130,000 file archive that must land in /opt/quantmind/data/quantdb. The last push was on 2026-09-20. Start with the full deploy script, confirm the Postgres and Redis services come up healthy, and only then point it at a broker account, because the QMT bridge is the component with real money behind it.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. qusong0627/QuantMind on GitHub
4. README
5. Releases