量化交易系统总体架构与一统演进蓝图 (Assessment & Unification Plan) 文档创建: 2026-04-05 涉及核心项目: ATMS、QMT (qmt_system)、Wavemonitor、tradingagents-cn 核心战略: 依托小步快跑迭代，正式开启多项目 Monorepo 合体进程 一、 系统全貌与原产物核心定位 在进行统一规划前，对前期分别验证独立技术的成果及其在全局大系统中的定位梳理如下： 1.1 ATMS: 战术监控与AI宏观决策 历史定位: 定时巡检、多维共振监控、结合大语言模型盘中辅助决策的独立系统。 技术沉淀: 高频巡检调度: main.py 定时机制与健壮的自我降级防护。 AI 赋能辩论 (debate/): 探索出利用实时技术信号与持仓成本数据灌入 Prompt、限定 2 轮带记忆裁决的无幻觉 LLM Agent 应用机制。 消息枢纽: 基于 OpenClaw 的 atms666-stock 飞书自动化卡片推送链路。 1.2 WaveMonitor: 极速算子基座 历史定位: 探索大批量实时股票状态机计算的最优解。 技术沉淀: vector_engine.py (V7.1 Titan): 抛弃逐条 K 线的 if-else 判断，完全依靠 Pandas 执行纯向量化并行运算。内置双确认红绿波、状态粘性 FFill、超级防守趋势与动态吊灯止损。是所有旧版运算库（如 TA-Lib）的绝对上位替代品。 1.3 QMT System: 交易执行与底层基建 历史定位: 打通真实市场交易与跨平台研发（Mac vs Windows）隔离的底座环境。 技术沉淀: 多端执行抽象 (executor): 基于 ExecutorBase 包含实盘 QMT 和基于滑点延迟可配置的模拟执行器 SimulatedExecutor。 多源数据网关 (stock-qdata): 优雅抹平 xtdata / akshare / csv 获取方式异构差异的数据提取中间件。 二、 当前演变断层与技术债务 在独立发展验证后，向整合系统转化存在以下架构冲突，需要在重构计划中逐个拔除： ...

QMT 高阶架构图 下图为 QMT 项目的高阶架构视图（Mermaid）： %%{init: {"theme":"neutral"}}%% flowchart LR %% Data Sources subgraph DataSources [外部数据源] XT[QMT xtdata] AK[AKShare / CSV] API[第三方 API] end %% Ingestion Layer subgraph Ingest [数据接入层] StockQ[stock-qdata (统一数据网关)] DataFeed[DataFeed (qss/core/data_feed)] end %% Core Platform subgraph Core [核心平台] Event[EventBus (异步事件总线)] Strategy[策略引擎 (策略生命周期、回放)] Executor[执行器 (Simulated / Real / Remote)] Monitor[wavemonitor (信号监控)] end %% Storage & Observability subgraph Storage [存储与观测] DB[SQLite / Parquet] Metrics[Prometheus / Grafana] Logs[集中日志] end %% Config & Ops subgraph Ops [配置与运维] Config[quant_config (配置中心/YAML)] CI[CI/CD] Notif[Feishu Webhook (告警/通知)] end %% Flows XT -->|kline/tick| StockQ AK -->|kline/csv| StockQ API -->|quotes| StockQ StockQ -->|normalized data| DataFeed DataFeed -->|DataResult| Event Event -->|tick/bar| Strategy Strategy -->|order req| Executor Executor -->|order/trade events| Event DataFeed -->|persist| DB Strategy -->|results| DB Executor -->|fills| DB Event -->|alerts| Monitor Monitor -->|alerts| Notif Executor -->|trade alerts| Notif Config --> Strategy Config --> Executor CI -->|tests/build| Repo[(code repo)] Metrics -->|dashboards| Ops Logs -->|search| Ops style DataSources fill:#f8f9fa,stroke:#333,stroke-width:1px style Ingest fill:#eef6ff,stroke:#3b82f6 style Core fill:#fff7ed,stroke:#f59e0b style Storage fill:#f0fdf4,stroke:#10b981 style Ops fill:#f3f4f6,stroke:#6b7280 classDef smallText font-size:12px; class StockQ,DataFeed,Event,Strategy,Executor,DB,Config smallText; 保存路径： docs/ARCHITECTURE_HIGH_LEVEL_DIAGRAM.md ...

QMT 系统代码架构分析 日期: 2026-04-06 分析范围: qss/, sps/, tss/, qdata/, its/, config/, scripts/, tests/ 统计口径: 已排除 .git/, .venv/, __pycache__/, .pytest_cache/, tss/output/ 等生成内容 命名说明: 对外交付物中使用 QTS 作为交易执行主系统简称；当前代码目录与 import 路径仍保持为 qss/ 1. 核心模块缩写与全称 缩写 英文全称 中文全称 当前职责 QTS Quantitative Trading System 量化交易系统 在线策略执行、风控、事件总线、执行器、API SPS Strategy Push System 策略监控推送系统 盘中监控、状态观察、消息推送 TSS Trading Strategy Search 交易策略搜索系统 策略研究、批量回测、策略比较 ITS Investment Target Selection 投资标的选择系统 个股筛选、辩论评审、金股池与记忆沉淀 说明: ITS 在当前代码里同时承载“投资决策评审 / 标的筛选”语义。本文统一采用 Investment Target Selection 这一主命名，并保留其“评审式筛选”定位。 2. 子系统原始定位与边界 这一节补回原有文档中的“角色定位”，避免只看技术实现而忽略业务边界。 ...

QMT Detailed Runtime Flow 时间: 2026-04-07 目的: 画清楚 ITS / QTS / SPS / TSS / qdata / scheduler 的详细运行流程 说明: 本文分为两部分 当前代码真实运行流程 推荐演进后的分层池消费流程 1. 当前代码真实运行流程 1.1 运行说明 当前仓库里，最稳定、最清晰的主流程是: 夜间由 scheduler.py 拉起 nightly_screener.py nightly_screener.py 从种子池读取股票列表 ITS 用技术过滤 + AI 辩论筛出可关注标的 结果写入 config/golden_pool.yaml 次日 scheduler.py 拉起 qss/main.py QTS 加载配置、数据源、执行器、风控和策略后进入交易时段运行 SPS 当前是相对独立的盘中监控链路，更多消费自己的 watchlist，而不是统一消费 ITS 分层池 1.2 详细运行流程图 flowchart TD subgraph Time0["夜间研究与洗池"] A1["scheduler.py<br/>01:00 定时触发"] --> A2["job_run_nightly_screener()"] A2 --> A3["scripts/jobs/nightly_screener.py"] A3 --> A4["读取 config/pools/zxg_a_share_pool.csv<br/>种子股票池"] A3 --> A5["ConfigManager.load()<br/>日志 / 配置初始化"] A3 --> A6["DataFeed(settings)<br/>经 qdata / xtdata / CSV 获取日线"] A3 --> A7["AIClient<br/>LLM 客户端"] A4 --> A8["遍历股票"] A6 --> A8 A7 --> A8 A8 --> A9["ITS.StockScreener.screen_symbol()"] A9 --> A10["IndicatorEngine<br/>趋势过滤 / 择时过滤"] A10 --> A11{"技术过滤通过?"} A11 -- 否 --> A12["skip_reason<br/>淘汰"] A11 -- 是 --> A13["DebateContextBuilder<br/>组装技术/价格/持仓上下文"] A13 --> A14["DebateEngine.run_debate()"] A14 --> A15["debate_to_signal()<br/>生成 BUY / HOLD / SELL 等信号"] A15 --> A16{"action in BUY/STRONG_BUY?"} A16 -- 否 --> A17["不入池"] A16 -- 是 --> A18["写入 golden_symbols[]<br/>symbol / name / confidence / risk / logic"] A18 --> A19["save_golden_pool()"] A19 --> A20["config/golden_pool.yaml"] end subgraph Time1["盘前调度"] B1["scheduler.py<br/>09:25 定时触发"] --> B2["job_start_qss_engine()"] B2 --> B3["subprocess 启动 qss/main.py"] end subgraph Time2["QTS 交易主链路"] C1["qss/main.py"] --> C2["ConfigManager.load()"] C2 --> C3["DataFeed(settings)<br/>可接 qdata / xtdata"] C2 --> C4["create_executor()<br/>QMTExecutor 或 SimulatedExecutor"] C4 --> C5["ExecutorPortfolioAdapter"] C5 --> C6["RiskManager"] C4 --> C7["SignalProcessor.start()"] C2 --> C8["create_strategy()<br/>按 settings.strategies 装载策略"] C8 --> C9["strategy.start()"] C2 --> C10["NotificationBridge.start()"] C2 --> C11["FastAPI init_state / uvicorn"] C1 --> C12["进入阻塞运行 while True"] C3 --> C8 C6 --> C7 C8 --> C7 C7 --> C13["风控检查 / 订单路由 / 执行"] C13 --> C14["QMT 实盘下单 或 模拟执行"] end subgraph Time3["SPS 独立盘中监控链路"] D1["sps/wave_monitor.py"] --> D2["读取 .watchlist_a.json"] D1 --> D3["QuoteFetcher<br/>QMT xtdata 或 Sina"] D1 --> D4["HistoryDataManager"] D3 --> D5["实时行情"] D4 --> D6["历史K线"] D5 --> D7["WaveComputeEngine<br/>V7.1 Titan 向量计算"] D6 --> D7 D7 --> D8["状态机 / 变化检测 / 告警格式化"] D8 --> D9["控制台 / 持久化 / 推送"] end subgraph Time4["TSS 研究与回测链路"] E1["TSS runner / backtest"] --> E2["更宽研究池 / 自定义 universe"] E2 --> E3["qdata / CSV / yfinance / vn.py"] E3 --> E4["回测结果 / 对比报告"] end A20 -. 次日作为候选输入 .-> C8 A20 -. 当前也可供其他模块读取 .-> D2 C3 -->|"统一数据入口"| E3 2. 当前流程的关键结论 当前最明确的“日切换”主线是 scheduler -> nightly_screener -> golden_pool.yaml -> qss/main.py ITS 已经承担了夜间评审和洗池职责 QTS 是唯一真正承担执行闭环的系统 SPS 目前更像并行监控服务，还没有完全切到统一的 ITS 输出契约 TSS 保留更宽研究池是合理的，不必被 ITS 完全约束 3. 推荐演进后的详细运行流程 3.1 演进目标 你前面提的方向我认可，推荐把 ITS 定义为“分层池生产者”，而不是“强耦合驱动所有下游”的控制中心。 ...

QMT 系统管理层摘要 日期: 2026-04-07 适用对象: 老板、新同事、非核心开发成员 命名说明: 对外简称采用 QTS；当前代码目录仍为 qss/ 1. 一句话总结 QMT 不是单一策略程序，而是一套围绕量化交易建立的工作平台。它已经形成了“数据底座 + 标的筛选 + 策略研究 + 交易执行 + 监控推送”的完整闭环雏形。 2. 四个核心子系统分别做什么 QTS QTS (Quantitative Trading System) 是交易执行主系统。 它负责把策略信号真正落到交易闭环，包括: 策略在线运行 风控校验 委托执行 持仓/资产状态管理 API 与运行态对外暴露 简单说，QTS 负责“做”。 SPS SPS (Strategy Push System) 是监控推送系统。 它负责盘中状态观察、信号变化提醒和消息推送，重点是“监控”和“告警”，不是交易执行。 简单说，SPS 负责“看”，而且是 只推不交易。 TSS TSS (Trading Strategy Search) 是策略研究与回测系统。 它负责策略搜索、历史回测、参数比较和策略验证，输出的是研究结论，而不是实盘执行动作。 简单说，TSS 负责“试”。 ITS ITS (Investment Target Selection) 是投资标的筛选与评审系统。 它负责从全市场中筛选候选标的，并通过多维评审给出优先级和结论。它输出的是候选池和评审报告，而不是直接下单。 简单说，ITS 负责“挑”。 3. 整体关系如何理解 可以用一句话概括这套体系: ...

QMT 高层架构图 日期: 2026-04-06 说明: 本文档基于当前代码结构绘制，不沿用旧命名。 命名说明: 对外简称采用 QTS；当前代码目录与 import 路径仍为 qss/ 1. 模块缩写与全称 缩写 英文全称 中文全称 QTS Quantitative Trading System 量化交易系统 SPS Strategy Push System 策略监控推送系统 TSS Trading Strategy Search 交易策略搜索系统 ITS Investment Target Selection 投资标的选择系统 2. 原始定位补充 QTS: 交易执行主系统，负责真正的策略执行、风控与交易闭环 SPS: 监控推送系统，负责低频监控和消息推送，只推不交易 TSS: 策略搜索与回测系统，负责研究、验证和比较 ITS: 投资标的筛选与评审系统，负责候选股筛选与评审，看和评，不直接做 3. 系统上下文图 flowchart LR User[交易员 / 研究员 / 调度脚本] --> QMT[QMT Quant Workspace] Market[QMT xtdata / AKShare / CSV / Sina / News] --> QMT QMT --> Notify[Feishu / Dashboard / 报表] QMT --> Broker[QMT 交易终端 / 模拟执行] 4. 当前代码高层架构图 flowchart TB subgraph Config[统一配置层] CFG1[config/base.yaml] CFG2[accounts / pools / strategies] CFG3[loader.py] end subgraph Data[数据与存储层] QD[qdata.service.DataService] ADP[QMTAdapter / AKShareAdapter / CSVAdapter] ASYNC[AsyncDataService] BAR[BarStore SQLite] end subgraph Trading[交易执行层] DF[DataFeed] QTS[QTS\nQuantitative Trading System\n量化交易系统] BUS[EventBus] PROC[SignalProcessor] RISK[RiskManager] EXE[QMTExecutor / SimulatedExecutor / RemoteExecutor] API[FastAPI + Dashboard] NOTI[NotificationBridge] end subgraph Monitor[盘中监控层] SPS[SPS\nStrategy Push System\n策略监控推送系统] WM[wave_monitor] QF[QuoteFetcher] VE[vector_engine] HDB[HistoryDataManager] end subgraph Research[策略研究层] TSS[TSS\nTrading Strategy Search\n交易策略搜索系统] DL[data_loader] VBT[vnpy_backtest_runner] COMP[comparison / report scripts] end subgraph Intelligence[智能分析层] ITS[ITS\nInvestment Target Selection\n投资标的选择系统] DCB[DebateContextBuilder] DEB[DebateEngine] AIC[AIClient] MEM[DebateMemoryStore] GP[GoldenPoolManager] NEWS[news + sentiment] end subgraph Ops[编排运维层] SCH[scheduler.py] NIGHT[nightly_screener.py] end CFG1 --> QD CFG2 --> QD CFG3 --> QD CFG3 --> Trading CFG3 --> Research ADP --> QD --> BAR QD --> ASYNC QD --> DF QD --> SPS QD --> TSS QD --> ITS DF --> QTS QTS --> BUS --> PROC --> RISK --> EXE BUS --> NOTI BUS --> API QF --> WM VE --> WM HDB --> WM SPS --> WM TSS --> DL DL --> VBT COMP --> VBT ITS --> DCB DCB --> DEB --> AIC DEB --> MEM DEB --> GP NEWS --> DCB GP -. 候选池 / 事件 .-> QTS SCH --> NIGHT SCH --> QTS NIGHT --> ITS 5. 推荐部署图 flowchart LR subgraph StrategySide[策略与研究侧 Mac / Linux] TSS[TSS\nTrading Strategy Search] SPS[SPS\nStrategy Push System] ITS[ITS\nInvestment Target Selection] QTSL[QTS Logic\nQuantitative Trading System] QDATA[qdata] end subgraph ExecSide[执行侧 Windows + QMT] REMOTE[RemoteExecutorServer] QMTX[xtdata / xttrader / QMTExecutor] TERMINAL[QMT Client] end TSS --> QDATA SPS --> QDATA ITS --> QDATA QTSL --> QDATA QTSL -->|JSON-RPC/TCP| REMOTE --> QMTX --> TERMINAL 6. 阅读说明 qdata 是全系统共享底座 QTS 是最核心的在线执行域，也是唯一承担交易执行闭环的主系统 SPS 与 TSS 分别承担监控和研究职责，其中 SPS 只推不交易 ITS 负责智能分析、候选池沉淀和评审结论输出 scripts 负责日常编排，不直接承载业务逻辑

QSS 到 QTS 重命名迁移方案 日期: 2026-04-07 当前结论: 推荐先做对外命名切换，再做代码层重命名 当前状态: 对外交付物已切换为 QTS，代码目录与 import 路径仍为 qss/ 1. 为什么考虑从 QSS 改为 QTS 当前对外简称最初是 QSS，但从语义上看，交易执行主系统更容易被理解为: QTS = Quantitative Trading System 相比之下，QSS 更容易让人联想到 Strategy System，而不是“交易执行主系统”。 因此，从品牌和沟通角度，QTS 的确更直观。 2. 当前现状 本次快速评估显示，仓库中与 QSS / qss/ / qss. 相关的引用约 178 处。 这些引用分布在: 文档 PPT 生成脚本 Python import 调度脚本 测试代码 架构图与说明文本 这意味着，QSS -> QTS 不是一个“只改几行字”的动作。 3. 风险评估 低风险部分 以下内容可以先改，不会影响系统运行: 架构文档 汇报 PPT 对外介绍口径 模块说明 管理层摘要 中风险部分 以下内容改动后，需要回归验证: 日志文案 调度脚本中的显示文本 文档里的目录说明 测试里的描述文字 高风险部分 以下内容一旦修改，会直接影响代码运行与导入路径: ...

QMT Architecture Risk Details 基于当前代码仓库现状整理，聚焦此前架构文档里提到的前三类风险。 时间: 2026-04-07 范围: qmt/ 当前主仓代码、历史文档与运行脚本 1. 文档命名与实际目录漂移 1.1 现象 仓库已经明显从历史命名体系迁移到新的模块化命名体系，但大量旧文档仍使用老名字，导致“文档里的系统”和“代码里的系统”不是同一套口径。 当前对外推荐口径: 当前口径 代码目录 历史口径 QTS qss/ qmt_system/ SPS sps/ wavemonitor/ TSS tss/ search_essential/ qdata qdata/ stock-qdata/ config config/ quant_config/ 1.2 具体问题 根级架构文档仍以旧目录为主，容易让阅读者误以为仓库目录尚未迁移。 子系统文档中混用了“旧目录名”和“新简称”，导致同一个模块在不同材料里有两到三个名字。 一些蓝图文档已经开始做新旧映射，但没有成为统一事实来源，阅读时仍需要人工脑补转换。 历史输出物中仍保留“qmt_system/skills/wavemonitor/”这类已经不符合当前结构的表述。 1.3 代码与文档证据 ARCHITECTURE.md 仍写 qmt_system / wavemonitor / stock-qdata / search_essential / quant_config ARCHITECTURE.md 之后的大段目录树仍基于旧结构 Architecture.md 仍以 qmt_system / search_essential / wavemonitor / stock-qdata 为主名 Architecture.md 仍把 search_essential / wavemonitor / qmt_system 当作主要模块名 ARCHITECTURE_HIGH_LEVEL_DIAGRAM.md 图中仍使用 stock-qdata / wavemonitor / quant_config integration-blueprint.md 已开始建立 旧目录 -> 新简称 映射，但这份映射尚未完全反向同步到其他文档 1.4 架构层影响 沟通成本上升: 老成员说旧名，新成员看新目录，讨论容易错位 汇报口径不稳定: 对外材料、PPT、代码目录三套话语并存 重命名评估容易失真: 无法快速分辨“文档已迁移”还是“代码已迁移” 影响自动化治理: 后续如果做目录扫描、依赖图、ADR 归档，命名不统一会让结果失真 1.5 建议 指定一份主口径文档，推荐继续以 QMT_CODE_ARCHITECTURE_20260406.md 作为对外事实来源 在旧文档顶部统一加“历史文档 / 已迁移命名对照”提示，而不是默默保留旧名 对外统一使用 QTS / SPS / TSS / ITS / qdata 对内在过渡期保留说明: QTS 对应当前代码目录 qss/ 2. sys.path 注入与隐式导入较多，包边界未完全硬化 2.1 现象 当前多个核心模块和运行脚本仍通过手工修改 sys.path 来完成跨目录导入。这说明仓库虽已开始形成模块边界，但尚未完全进入“稳定包 + 明确入口”的状态。 ...

SAF Architecture Review 策略自动化工厂 — 架构深度评审（修订版） 更新时间: 2026-04-14 评审范围: SAF / Strategy Factory / 各子系统联动 1. 定位与愿景 QMT 工作区 │ ├── qdata/ 统一数据层 ├── qss/ 量化策略系统 ├── its/ 舆情/情绪分析 ├── sps/ 盘中信号监控 ├── tss/ 策略研发回测 │ └── SAF/ 策略自动化工厂 ├── core/saf/ saf Python 包（核心引擎） └── strategy_factory/ 策略工厂（批量评估） 2. 实际架构：双轨并行 strategy_factory/ │ ├── run_evaluate.py ← 批量评估入口（当前生产路径） │ │ │ ├─ legacy/evaluate/engine.py CrossSectionalBacktester ← 实际运行的回测引擎 │ ├─ legacy/evaluate/scorer.py 6D 评分 + 场景切片 │ └─ evaluate/fast_screen_policy.py 快筛策略 │ ├── run_pipeline.py ← 策略数据提纯入口（LLM 清洗 raw→JSON） │ └── pipeline/runner.py │ ├── evaluate/ │ ├── engine_adapter.py ⚠️ 存在但未接入 — SAF 引擎适配器 │ └── fast_screen.py │ └── backtest_*.py ← 专项回测工具（独立使用） ├── backtest_regime.py Regime 三策略对比 (374L) ✅ ├── backtest_regime_aware.py Regime-Aware 回测 (499L) ✅ ├── backtest_skills_v71.py Skills V7.1 回测 (342L) ✅ ├── backtest_sps.py SPS 回测 (360L) ✅ ├── backtest_sps_v2.py SPS V2 回测 (325L) ✅ ├── backtest_v7_vs_v8.py V7 vs V8 对比 (289L) ✅ └── test_tdx_api.py TDX API 测试 (297L) 3. 双轨详解 3.1 Legacy 轨（✅ 当前生产路径） run_evaluate.py │ ├─ CrossSectionalBacktester (legacy/evaluate/engine.py) │ ├─ load_data_yfinance() ✅ Mac 主路径 │ ├─ load_data_csv() ✅ CSV fallback │ ├─ load_data_gateway() ✅ QMT gateway │ ├─ _normalize_ohlcv() ✅ 列名统一 │ └─ signal_func(df) → equity ✅ 截面回测 │ ├─ fast_screen_policy.py │ ├─ infer_profile() ✅ 策略画像推断 │ ├─ should_retry_rejected() ✅ 重试策略 │ └─ classify_*() ✅ 分类逻辑 │ └─ legacy/evaluate/scorer.py ├─ score_strategy() ✅ 6D 评分 ├─ score_scenario_slices() ✅ 场景切片评分 └─ generate_report() ✅ JSON/MD 输出 特点: 直接操作 pandas DataFrame，不依赖 saf.data 包，零抽象开销。 ...