TradingAgents-CN: a Chinese-language multi-agent stock analysis platform with a split licence

The problem is not the agents, it is the plumbing around them

The upstream TradingAgents framework from Tauric Research is a research artifact. TradingAgents-CN takes that multi-agent trading idea and builds the surrounding product for Chinese users: a learning centre, A-share, Hong Kong and US market coverage, Chinese-language documentation, and a web interface. The README frames the platform as a study and research tool that does not issue live trading instructions and does not constitute investment advice. That positioning matters, because it tells you who the intended user is. This is not a library you import into a trading system. It is an application you deploy, configure with model providers and data sources, and use to generate analysis reports. The target reader is someone who wants to study how a multi-agent LLM pipeline behaves on Chinese equities, or a developer who wants a working reference implementation of that pipeline with a real front end attached. If you already have a research stack and only want the agent orchestration, the upstream project is the smaller dependency.

FastAPI, Vue 3 and a two-database split replace the original Streamlit app

The v1.1.0 release notes describe a migration from Streamlit to FastAPI plus Uvicorn on the back end and Vue 3 with Vite and Element Plus on the front end, with MongoDB and Redis behind them. The README claims a tenfold performance improvement from the database change. That number comes from the project's own release notes, not from any independent measurement, and no method is given for it, so treat it as a vendor claim. What is verifiable from the layout is the shape of the system. There is a RESTful API plus WebSocket layer, and the notification system is described as SSE plus WebSocket dual-channel, used to push analysis progress and system status. A batch analysis feature runs multiple tickers at once. A cache layer is described as multi-level across MongoDB, Redis and files. On the data side, the README names Tushare, AkShare and BaoStock as sources behind a unified data source manager, and a market analyst plus a fundamentals analyst consume that data. The v1.1.0 notes list fixes for technical indicator calculation and for PE and PB values in the fundamentals path, plus a fix for an infinite loop some users hit during analysis. Those entries are worth reading as evidence that the data layer, not the LLM layer, is where the hard bugs live in a project like this.

Model providers are configured, not hardcoded, with one exception

The feature list includes native OpenAI support, Google AI integration, custom endpoint configuration and multi-provider support, with model selection persisted between sessions. v1.1.0 adds a VolcEngine Ark provider, and the release notes mention hardcoded configuration for the programming-tier model plus password compatibility handling. A reasoning_effort field is threaded through the chain and the data model gained reasoning_effort and test_model fields, with timeout protection added for reasoning models. The upstream absorption notes list an llm_clients abstraction layer, a shared model catalogue with lightweight validation, and canonical provider key normalisation, along with unified default URLs and environment variable mappings per provider. That is a sensible design: providers are described in a catalogue and addressed by a canonical key, so adding one does not mean editing the orchestration graph. The caveat is the hardcoded Ark programming model. Any time a provider needs a special case in code rather than in configuration, that provider will drift as the model lineup changes, and the user cannot fix it without a patch. If you plan to run a provider that is not in the catalogue, budget for reading the provider initialisation path in trading_graph.py before you assume it will work.

Getting it running means Docker Compose or a local install, then a data sync

The README offers two deployment paths. The Docker route is described as suitable for production and cross-platform, with a full Docker Compose configuration and a stated five-minute start. The local code route is aimed at developers and customisation and is described as harder. Docker images are built for amd64 and arm64 through GitHub Actions, covering Apple Silicon, Raspberry Pi and AWS Graviton. A start_dev.ps1 script is provided in v1.1.0 to launch development environments for v1.0, v2.0, v2.1 and v3.0. On the database side, v1.1.0 fixed MongoDB connection string construction so the string is built automatically, and fixed a Tushare permission error when writing tk.csv. There is a documented database version isolation and provider normalisation scheme with migration scripts. The one step the README marks as mandatory is the data sync: it states plainly that stock data must be synchronised before analysis, otherwise the analysis results will contain data errors. That is not a footnote. In a system where several analysts read from a shared data layer, a stale or partially synced store produces confident-looking output built on the wrong numbers, and the v1.1.0 fix list suggests that has already happened to users. The linked installation guides are hosted on WeChat articles and Bilibili videos rather than in-repo markdown, which makes them harder to diff or search when a step fails.

The licence is split, and the interesting directories are the closed ones

The README describes a hybrid licence. Files outside app/ and frontend/ are Apache 2.0. The app/ directory, described as the FastAPI back end, and the frontend/ directory, described as the Vue front end, are proprietary and require commercial authorisation. The repository's licence field reports NOASSERTION, which is consistent with a licence that is not a single recognised identifier. Personal use of v1.1.0 is described as fully open. Commercial use requires authorisation via the contact email in the README. The version roadmap is the part that needs care: v1.1.0 is open, v2.0 is described as complete and stable but will only be open-sourced after v3.0 ships, and v3.0 is in closed beta with an application process. The project also states that no organisation or individual has been granted commercial authorisation, and that a third-party site is using the code without permission. Two practical consequences follow. First, if you clone the repository expecting a permissively licensed web application, you will find the API and UI directories outside the open grant. Second, if you evaluate v3.0 features such as the AI workflow designer, replay research, position research or the Skill system, you are evaluating closed code, and the open-source schedule for v2.0 is tied to a future v3.0 release. None of this is a legal opinion; read COPYRIGHT.md and LICENSE yourself, and get your own advice if you intend to ship anything.

The contribution economy is unusual and worth understanding before you file a PR

The README states that merged pull requests earn Pro licence time: one merged PR gives three months, three merged PRs give one year, and core contributors get a permanent licence plus revenue share. That is an explicit trade of code for access to the closed tiers, and it tells you where the project expects effort to come from. It also tells you something about the maintenance model. The upstream sync document describes manual, selective absorption of upstream changes rather than a straight merge, and lists the specific upstream capabilities already pulled into v1.1.0: the llm_clients abstraction, the shared model catalogue, provider canonical key normalisation, the main provider initialisation path in trading_graph.py, the qwen fresh LLM rebuild in fundamentals_analyst.py, layer parameter passing, factory alias compatibility, risk control reference fixes, and the MongoDB default database name and version isolation naming. Manual absorption means upstream fixes do not arrive automatically, and each one is a deliberate decision by the maintainers. If you depend on a specific upstream behaviour, check the manual upstream absorption checklist before assuming it is present. There are no retrieved releases in the repository metadata, so version tracking runs through the VERSION file and the docs/releases directory rather than through tagged releases.

Where it is the wrong tool, and what to use instead

The clearest wrong-tool case is anyone who wants the multi-agent orchestration itself as a library. The upstream Tauric Research TradingAgents repository is the smaller thing: it is the framework this project localises and extends, and it does not carry the FastAPI back end, the Vue front end, the MongoDB and Redis requirement, or the split licence over app/ and frontend/. If your goal is to study or modify the agent graph, the upstream code is the direct path, and the CN project's own README credits it as the source. The second wrong-tool case is a team that needs a permissively licensed application to embed in a product. The Apache 2.0 grant here stops at the API and UI directories, so the parts you would most want to reuse are the parts that need authorisation. A third case is a user who wants signals rather than a study environment. The README states the platform does not provide live trading instructions and is positioned for learning and research, and the simulated trading feature is described as a virtual environment for validating strategy ideas. If you need execution, this is not it, and no amount of configuration changes that. Between the CN project and upstream, the real difference is scope: upstream is the framework, this is the framework plus a Chinese-language application, data source integrations, a report export path covering Markdown, Word and PDF, and a versioned licence model.

What to verify before you commit a weekend to it

Start with the licence files, not the feature list. Read COPYRIGHT.md and LICENSE side by side and confirm which directories fall under which grant, then decide whether your intended use is personal or commercial. Next, confirm which version you are actually installing, because v1.1.0, v2.0 and v3.0 have different availability and the open-source schedule for v2.0 depends on v3.0 shipping. Then check the data sync path for the sources you care about, since the README makes synced data a precondition for correct analysis and names Tushare, AkShare and BaoStock as the supported sources. If you run Docker, the multi-architecture images cover amd64 and arm64. If you run locally, start_dev.ps1 covers the version matrix on Windows, and the database version isolation document covers the migration and provider normalisation steps. Finally, pick your model provider deliberately: the catalogue-based path is the supported one, and the Ark programming model is the documented exception where configuration gives way to hardcoded values. The project is a usable Chinese-language research environment with real data-source integrations and a real front end. Its constraints are licensing and data freshness, and both are visible in the repository before you run anything.

Editorial conclusion

Adopt it if you want a Chinese-language multi-agent research environment with A-share, Hong Kong and US market coverage and you can live with the licence split: app/ and frontend/ are proprietary and commercial use needs authorisation from hsliup@163.com. Do not adopt it if you need a permissively licensed codebase you can ship in a product, or if you expect the agent prompts themselves to be the interesting part. Before installing, read COPYRIGHT.md and LICENSE together, confirm which version you are actually pulling (v1.1.0 is open, v2.0 and v3.0 are not), and plan the data sync step, because the README states that analysis on unsynced data returns wrong results.

Official sources

1. hsliuping/TradingAgents-CN on GitHub
2. Issues
3. README