ai-trading · AI 工具图鉴

📌 核心价值：把本地行情、财务数据、可视化与 Agent 分析放进同一套可审计工作台。

本文仅作技术交流，不构成投资建议。股市有风险，投资需谨慎。

ai-trading 官方工作台

🚀 什么是 ai-trading？

ai-trading 是一个面向本地研究场景的开源量化分析系统。它不是单一指标脚本，而是一套从数据导入、结构化存储、策略计算、图表交互到 Agent 辅助分析的完整 Web 工作台。项目采用 Python 3.12、FastAPI、Vue 3、MySQL 8.0 与 pytdx，浏览器即可访问，不依赖复杂的前端构建链。

项目最值得关注的并不是某个具体策略，而是它把原本分散的工程环节统一起来：本地数据文件进入导入脚本，写入结构化数据库；FastAPI 以模块化路由暴露服务；Vue 3 前端负责交互与可视化；AI 辩论与专家系统作为分析模块接入，而不是绕过数据直接给结论。

核心定位：本地优先、数据可追溯、模块可替换的 AI 量化技术框架。

✨ 五层技术架构

ai-trading 五层技术架构

系统可以拆成五层：

用户层：桌面和移动浏览器通过统一地址访问。
前端层：Vue 3 以 CDN 方式加载，配合 Lightweight Charts 展示交互图形。
服务层：FastAPI 注册 screening、backtest、profile、debate、vcp、expert 与 data management 等路由。
数据层：MySQL 保存行情、财务、板块映射与基础资料，策略引擎保持纯计算逻辑。
导入层：pytdx 与四个独立导入脚本负责把本地数据转成可查询的数据表。

官方系统架构图

这一设计的关键是边界清晰。API 路由必须先于 SPA catch-all 注册，否则前端兜底路由会截获接口请求。策略计算也没有直接暴露 HTTP，而是由 Router 调用，使业务逻辑与传输层解耦，后续更容易增加测试或替换数据源。

🛠️ 快速上手：先跑通数据与服务

环境要求

Python 3.12
MySQL 8.0
本地通达信数据源

# 1. 克隆仓库
git clone https://github.com/zhitucoder/ai-trading
cd ai-trading

# 2. 创建环境并安装核心依赖
conda create -n aitrading python=3.12
conda activate aitrading
pip install fastapi uvicorn pymysql pytdx

# 3. 创建数据库
mysql -u root -p -e "CREATE DATABASE IF NOT EXISTS ai_trading"

随后在 src/app/database.py 中配置数据库连接，并按数据类型运行导入脚本：

python src/import_kline.py
python src/import_financial.py
python src/import_sectors.py
python src/import_shares.py

完成数据准备后启动服务：

uvicorn src.app.main:app --host 0.0.0.0 --port 9000

浏览器打开 http://localhost:9000，即可进入工作台。

注意：先验证数据完整性，再启用上层分析模块。任何 Agent 结论都应能回溯到结构化数据与计算过程。

💡 三个值得拆解的工程场景

场景一：交互式数据工作台

官方工作台演示

功能说明：前端把筛选条件、图形展示和 API 调用放进同一界面，适合观察不同数据维度之间的关系。Vue 3 无构建工具的方案降低了部署门槛，也让后端工程师可以直接修改页面逻辑。

输入要求：已完成导入的本地行情、财务与板块数据。

输出效果：结构化列表、K 线图、指标视图和分析结果面板。

适用场景：本地研究、数据质量核验、接口联调和教学演示。

场景二：模块化 API 与策略引擎

官方功能演示

功能说明：系统把筛选、回测、画像、辩论、VCP、专家查询和数据管理拆成独立路由。策略逻辑位于 src/app/strategies/，Router 负责参数接收与结果返回，便于替换算法而不改变前端协议。

输入要求：明确的数据表结构、可验证的计算参数与稳定的接口契约。

输出效果：统一 JSON API，可被 Web 前端、脚本或其他 Agent 调用。

适用场景：二次开发、内部研究平台、教学实验与模块化测试。

场景三：AI 辅助分析与专家系统

官方 AI 分析模块演示

功能说明：AI 辩论模块以多角色观点碰撞辅助分析，专家系统面向财报、技术面和行业信息进行知识查询。它们位于数据层与 API 之上，正确用法是提供决策支持，而不是替代数据验证。

输入要求：结构化数据、明确问题、可追溯的上下文与边界条件。

输出效果：多视角分析文本、专家查询结果与结构化辅助信息。

适用场景：研究假设检查、报告初稿组织、跨维度问题梳理。

📊 与其他技术路线怎么选？

三类量化分析工具技术路线对比

ai-trading 的优势是系统边界完整：既有数据导入，也有数据库、API、前端和 AI 模块。代价是需要维护 MySQL 与本地数据目录，初次部署比单文件脚本更复杂。对于只想验证一个计算函数的开发者，轻量脚本更直接；对于需要大规模协作、权限治理与多环境部署的团队，成熟研究平台更合适。

选择标准不是功能数量，而是数据是否可追溯、模块是否可替换、结果是否可复现。

⚙️ 二次开发的四个优先级

先做数据校验：对导入行数、字段范围、日期连续性和重复记录建立自动检查。
再做接口契约：为每个 API 定义输入模型、输出模型和错误码，避免前后端隐式耦合。
补齐测试层：策略函数适合单元测试，Router 适合集成测试，导入脚本需要小样本回归测试。
最后接入 Agent：为提示词、工具调用、数据引用和失败回退保留日志，确保分析过程可审计。

项目 README 特别指出，部分财务比率字段存在偏移问题，需要回到利润表和资产负债表按公式重新计算。这个细节体现了量化工程中的核心原则：数据质量优先于模型复杂度。

💰 开源与使用成本

项目 README 声明采用 MIT License。软件本身开源，但实际运行仍需考虑 MySQL 存储、本地数据维护、服务器资源以及外部模型接口成本。若只在单机内网使用，可把部署重点放在数据备份、访问控制与日志留存；若准备多人协作，则还需要补充鉴权、权限分级和安全审计。

🎯 总结

ai-trading 展示了一条务实的 AI 量化工程路线：先建立本地数据底座，再用 FastAPI 和 Vue 3 形成可操作工作台，最后把 AI 辩论和专家查询作为上层能力接入。它适合希望理解完整技术链、重视数据可控性和二次开发空间的研究者。

推荐指数： 4.5 / 5

适合人群： Python 开发者、量化工程学习者、数据分析研究者、小型技术团队。

立即体验： GitHub 仓库

数据截至 2026-07-26，最新信息请以官方仓库为准。

配套媒体