TradingAgents-AShare: a 14-agent A-share research pipeline you host yourself

The problem is orchestration, not prediction

A single LLM asked to analyse 600519.SH produces one confident paragraph. The interesting failure is that you cannot see which claim it leaned on. TradingAgents-AShare attacks that by splitting the work across named roles and recording the disagreement between them. The README describes a pipeline that starts with six analyst agents working in parallel: fundamentals, sentiment, news, technicals, macro, and main-force capital flow. Their outputs feed two researcher agents, one long and one short, who argue over claims rather than prose, after which a research director issues a ruling. A trader converts that ruling into an executable plan, three risk agents (aggressive, neutral, conservative) debate it, and a portfolio manager makes the final call. The README says the full flow contains 14 agents and that the diagram shows only the core nodes. The audience is a Chinese-market retail or semi-professional investor who already has an LLM API key and is willing to run a container. It is not a screener, not a backtester, and it does not place orders.

Where the data actually comes from is the gap

The README is precise about agent roles and vague about inputs. It says the analyst team performs extraction and initial assessment on market data, and the feature list mentions real-time prices, the day's range, and position P&L on the tracking board. What it never states is which vendor or endpoint supplies A-share quotes, fundamentals, news, or capital-flow data, whether that source needs its own key, or what happens when it returns nothing. For a system whose entire value rests on the quality of its inputs, that is the largest documentation hole. A reader can infer that the data layer exists because the frontend shows live prices, but cannot verify its coverage, its latency, or its behaviour on a suspended stock. If you are evaluating this project, that is the first question to answer from the source tree, not the last.

Docker Compose is the intended path, and it is short

The README recommends Docker and gives two routes. The Compose route clones the repository, exports a secret, and brings the stack up: run `export TA_APP_SECRET_KEY=$(openssl rand -base64 32)` then `docker compose up -d`. The image starts the API service and the scheduled-task dispatcher in the same container, so scheduled analysis works without Redis. If you want the API, the scheduler and Redis in separate containers, the repository ships `docker-compose.split.yml` and points at `guide/deployment.md`. The plain `docker run` route pulls `ghcr.io/kylinmountain/tradingagents-ashare:latest`, mounts `$(pwd)/data` at `/app/data`, and passes `DATABASE_URL="sqlite:///./data/tradingagents.db"` plus the secret. The README is explicit that without the volume mount, historical reports, user configuration and tokens are lost when the container is deleted. Two configuration details matter more than they look. First, `TA_APP_SECRET_KEY` encrypts stored LLM API keys and signs login JWTs; the README says an unset value falls back to a built-in default suitable only for local development, and that once set it must not change. Second, LLM providers are configured in the browser settings page, not through environment variables, and the README notes that saving triggers a model warmup and that the settings page can send a literal "你好" to inspect the raw model response.

Source install and the REST surface

The source path needs Python 3.10+, uv, Node.js 18+ and npm. Backend setup is `uv sync`; frontend is `cd frontend && npm install && npm run build`. Copy `.env.example` to `.env`, then start with `uv run python -m uvicorn api.main:app --port 8000`. For frontend work, writing `VITE_API_URL=http://localhost:8000` into `frontend/.env` and running `npm run dev` serves on port 5173 against the backend on 8000. The HTTP surface is job-based rather than synchronous: `POST /v1/analyze` returns a `job_id`, `GET /v1/jobs/{job_id}` reports status, and `GET /v1/jobs/{job_id}/result` returns the payload. Around that sit `GET /v1/reports`, `POST /v1/reports/latest-by-symbols`, portfolio import endpoints under `/v1/portfolio/imports`, `GET /v1/dashboard/tracking-board`, batch scheduler operations at `PATCH /v1/scheduled/batch` and its delete and trigger siblings, and `POST /v1/config/warmup`. Authentication is a bearer token generated in the settings page, passed as `Authorization: Bearer <TOKEN>`. The README's own example posts a natural-language string as the symbol field: `{"symbol": "分析一下600519.SH短期趋势", "trade_date": "2026-03-28"}`. That is worth noting. The field is named `symbol` but accepts an instruction, and the README does not document what the parser does with an ambiguous sentence or a symbol it does not recognise.

The licence is split, and that decides most adoption questions

The repository's licence is reported as NOASSERTION, and the README explains why. The project is a derivative of TauricResearch/TradingAgents, which is Apache 2.0. The new modules, `api/` and `frontend/`, and what the README calls deep modifications to the core logic, are released under PolyForm Noncommercial 1.0.0. That is a non-commercial licence. Anyone planning to run this inside a fund, a brokerage, or a paid signal service is in territory the README explicitly reserves, and the README points to the root LICENSE file for the boundary between the two. I am not giving legal advice, and the README does not spell out which files fall on which side beyond the two directories. Treat the split as the single most consequential fact about this project after the data-source question. It also interacts with the affiliate links in the README, which promote a third-party API relay service; the project is monetising distribution while licensing the code non-commercially, which is a legitimate but unusual arrangement.

Limitations the README admits, and one it does not

The stated limitations are honest. The system is for study and demonstration and is not investment advice, and the README says any output reflects an algorithmic debate rather than real P&L. Scheduled analysis reuses position context and disables itself after repeated failures, which means a silently broken data source can quietly stop your schedule rather than alert you. The default secret key is unsafe outside local development. The unstated limitation is verification. Nothing in the material describes a ground-truth comparison, a backtest, or a measured accuracy figure for the debate output. The decision card shows direction, confidence, a target price and a stop price, but the README never says how confidence is computed or whether the target price comes from the model or from a deterministic rule. If you need a system whose outputs you can audit numerically, this is the wrong tool. It is also the wrong tool if your universe is not A-shares: the six analyst dimensions and the capital-flow agent are framed around the Chinese market, and nothing in the README suggests they generalise.

How it differs from calling an LLM directly, and from the upstream project

The obvious alternative is a single prompt to Claude or GPT with a few price screenshots, and the difference is structural rather than qualitative. A single call gives you one voice and no record of what it rejected. This project gives you a persisted report per symbol and date, retrievable through `GET /v1/reports`, plus a debate drawer that streams each agent's argument token by token, grouped by round, with the ruling rendered as a separate card. Whether that extra structure produces better calls is unproven here, but it does produce an artefact you can re-read. The second alternative is upstream TauricResearch/TradingAgents itself. The README credits it as the source of the core architecture and part of the base logic. The difference is the wrapper: this fork adds the FastAPI service, the Vue frontend, the SQLite schema, the scheduler, position import, the tracking board, and the OpenClaw skill `tradingagents-analysis`. If you want the agent graph without a web application, the upstream repository is Apache 2.0 throughout and avoids the non-commercial question entirely. If you want a running product rather than a library, this is the shorter path, at the cost of the licence split.

Maintenance cost and what to check on upgrade

The release cadence visible in the material is uneven: v0.8.0-rc10 in April 2026, v0.8.0 in May, v0.8.1 in July, and the last push in September 2026. That is a project still moving, which means the Docker image tag `latest` is not a stable pin. For a self-hosted deployment, pin a version tag rather than tracking `latest`, and keep the `data` volume on a path you back up, because the SQLite file holds reports, users, and encrypted API keys. The README references `guide/deployment.md` for upgrade and migration topology from older images, so read that before pulling. Model cost is the other recurring expense and it is not a fixed number: 14 agents, each producing streamed output, run per analysis, and the README's own affiliate copy quotes a relay multiplier of `0.06` without stating what it multiplies. Budget by measuring your own token usage per run, since the material gives no figure. On the licence side, the non-commercial restriction on `api/` and `frontend/` does not expire and does not depend on how you deploy, so a commercial user cannot escape it by self-hosting.

Editorial conclusion

Adopt it if you want a self-hosted A-share research pipeline and you are comfortable reading Python to learn how the agents are wired, because the README describes features but not the internals. Do not adopt it for anything commercial without reading LICENSE first: the new api/ and frontend/ modules are PolyForm Noncommercial 1.0.0, not Apache 2.0. Verify three things before trusting an output: which model provider you pointed it at, whether TA_APP_SECRET_KEY was set before first boot (it cannot be changed later), and whether the data volume is actually mounted, since an unmounted /app/data loses reports and tokens when the container is removed.

Official sources

1. Issues
2. KylinMountain/TradingAgents-AShare on GitHub
3. Project website
4. README
5. Releases