Enjoy your life! Let's Claude!

About

Wed, 15 Apr 2026 00:00:00 +0000

About Me

Hi, I’m James. I’m a software engineer passionate about building great products and sharing knowledge with the community.

Skills

Software Development
Web Applications
Open Source

Contact

Feel free to reach out via email or connect on social media.

Hello World

Wed, 15 Apr 2026 00:00:00 +0000

Welcome to my blog! This is my first post using Hugo and PaperMod theme.

Stay tuned for more content coming soon.

Mon, 01 Jan 0001 00:00:00 +0000

DevLog #008: QMT Monorepo 统一演进蓝图 — 四段式架构合体

日期: 2026-04-05 状态: 规划中 Tags: architecture, monorepo, system-unification

背景

涉及核心项目：ATMS、QMT (qmt_system)、Wavemonitor、tradingagents-cn

核心战略：依托小步快跑迭代，正式开启多项目 Monorepo 合体进程

原产物核心定位

ATMS: 战术监控与AI宏观决策

历史定位: 定时巡检、多维共振监控、结合大语言模型盘中辅助决策的独立系统。

技术沉淀:

高频巡检调度: main.py 定时机制与健壮的自我降级防护
AI 赋能辩论 (debate/): 利用实时技术信号与持仓成本数据灌入 Prompt、限定 2 轮带记忆裁决的无幻觉 LLM Agent 应用机制
消息枢纽: 基于 OpenClaw 的飞书自动化卡片推送链路

WaveMonitor: 极速算子基座

历史定位: 探索大批量实时股票状态机计算的最优解。

技术沉淀:

vector_engine.py (V7.1 Titan): 抛弃逐条 K 线的 if-else 判断，完全依靠 Pandas 执行纯向量化并行运算
内置双确认红绿波、状态粘性 FFill、超级防守趋势与动态吊灯止损
是所有旧版运算库（如 TA-Lib）的绝对上位替代

QMT System: 交易执行与底层基建

历史定位: 打通真实市场交易与跨平台研发（Mac vs Windows）隔离的底座环境。

Mon, 01 Jan 0001 00:00:00 +0000

DevLog #010: Antigravity 文档评审 — Phase 3 完成确认 + Phase 4 改进建议

日期: 2026-04-06 状态: 评审完成 Tags: phase3, phase4, its, debate-engine, architecture-review

Phase 3: QSS 实盘策略 — 全部已完成 ✅

文档任务	实际状态	Commit
实现 Titan Resonance Strategy	`qss/strategy/resonance_strategy.py` 222行，三维共振（价值30+趋势40+择时30 - 波动率惩罚）	`0865571`
策略防护状态机扩容	`qss/core/signal.py` 已有 `stop_loss_price` + `metadata` 字段	`0865571`
Chandelier Exit 吊灯止损	`qss/risk/stop_loss.py` 143行，ATR 动态乘数 + 超级趋势检测 + 硬止损 max(吊灯线, 成本*0.92)	`0865571`
测试覆盖	`tests/test_phase3_strategies.py` 429行，22个测试	`0865571`

结论: Phase 3 已在 commit 0865571 中全部完成。文档应标记为 DONE。

Mon, 01 Jan 0001 00:00:00 +0000

DevLog #006: 辩论引擎记忆系统设计 — SQLite + FTS5 三阶段演进

日期: 2026-04-06 状态: 实施中 Tags: its, debate-engine, memory-system, sqlite, fts5

现状分析

当前记忆机制的缺陷

辩论引擎 (its/debate/engine.py) 的"记忆"仅是进程内的 round-to-round dict:

previous_round = {
 "bull": bull_output, # 本轮多头输出
 "bear": bear_output, # 本轮空头输出
 "arbiter": arbiter_output, # 本轮裁判输出
}

三大问题：

进程重启后记忆消失
同一股票不同时间辩论，无法参考历史判断
没有事后复盘（辩论决策 vs 实际走势）

业界方案对比

方案	来源	存储	检索方式
ChromaDB 向量记忆	TradingAgents-CN	ChromaDB	Embedding 相似度
QMD 混合搜索	OpenClaw/Tobi Lütke	SQLite + FTS5 + sqlite-vec	BM25 + 向量 + LLM 重排
本方案	QMT	SQLite + FTS5	BM25 全文搜索（可升级向量）

为什么不直接用 QMD / ChromaDB

QMD 是 Node.js 工具，跨语言调用引入不必要的复杂度
ChromaDB 是独立数据库服务，对当前项目规模（单机交易）过重
SQLite 零部署、Python 内置、性能足够（单机万级记录）

三阶段演进方案

Phase 1 (P0) Phase 2 (P1) Phase 3 (P2)
────────────────────────────────────────────────────────────
SQLite 辩论历史存储 → 反思机制 (Reflection) → 语义检索升级
↓ ↓ ↓
持久化 + 查询 事后评估 vs 实际走势 特征向量相似度

Phase 1: SQLite 辩论历史存储

目标: 辩论结果持久化，支持按股票/日期查询历史。

Mon, 01 Jan 0001 00:00:00 +0000

DevLog #007: DfX 架构设计原则 — QMT 大一统系统工程纪律

日期: 2026-04-06 状态: 架构共识 Tags: architecture, design-principles, engineering-discipline

背景

随着 ATMS、WaveMonitor、TradingAgents 等实验性工程合体为大一统量化基建，代码体积正在膨胀。

为了抵御熵增，我们确立以下 Design for X 的系统级工程纪律。

一、Design for Maintainability — 以"减法"为核心

痛点：量化项目很容易留下大量"废弃的因子、没用的回测废稿、不再调用的模块"。

激进删除原则

只要是被 V7.1 Titan 或新版 qss 证明已超越的旧概念（如老版的 TA-Lib 逐行遍历、老版的提示词生成器），一旦替换，连注释都不要留，直接物理删除文件。

理由：在 Git 时代，代码库不应该做垃圾场。精简的代码库是对接替者（包括未来维护的 AI）最大的仁慈。

面向 Protocol 的解耦

设计准则：杜绝"意大利面条式"的深层类继承。

例如任何只需要历史行情的数据，只约束其入参必须符合 typing.Protocol：

class BarProvider(Protocol):
 @property
 def open(self) -> pd.Series: ...
 @property
 def high(self) -> pd.Series: ...
 @property
 def low(self) -> pd.Series: ...
 @property
 def close(self) -> pd.Series: ...

而不是强迫它继承一个巨大的 BaseDataFeed 基类。

★ Insight ───────────────────────────────────── Protocol vs 继承：继承是"我是谁"，Protocol 是"我能做什么"。用 Protocol 解耦的好处是：你只需要关心数据提供者有没有你需要的方法，而不是关心它在类继承树中的位置。 ──────────────────────────────────────────────────

Mon, 01 Jan 0001 00:00:00 +0000

DevLog #009: SPS ATR 缓冲修复 — 均线滞后性的边界弹性设计

日期: 2026-04-08 状态: 已修复 Tags: sps, vector-engine, atr, trend-detection

问题描述

现象: market_radar.py 和 vector_engine.py 使用硬 MA 阈值判断趋势。大涨后价格仍略低于 MA20/MA60 时，系统错误判定为 BEAR/GREEN_WAVE。

用户痛点: 均线是滞后指标，一天的大涨不足以让 MA 穿越，但用户体感"明显不是空头"。

修复方案

market_radar.py 修复

加 ATR(14) × 0.5 缓冲，价格贴线时 BEAR → CHOPPY

# 修复前
if price < ma20: BEAR

# 修复后
if price < ma20 - atr * 0.5: BEAR
else: CHOPPY # 贴线区域不轻易下定论

vector_engine.py 修复

加 ATR × 0.15 缓冲，MA5 略低于 MA21 但在缓冲区内时标 GRAY_ZONE 而非 GREEN_WAVE

Mon, 01 Jan 0001 00:00:00 +0000

DevLog #011: SPS OpenClaw Skill 部署架构 — 本地引用 vs HTTP API

日期: 2026-04-08 状态: 已建立 Tags: sps, openclaw, skill, deployment

当前模式: 本地引用

~/.agents/skills/sps/
├── SKILL.md ← 能力声明
├── scripts/run_sps.py ← 入口路由器
├── config/*.yaml ← 只读拷贝
├── data/.watchlist_a.json ← 只读拷贝
└── .qmt_root ← 指向 /Users/james/code/qmt/qmt
↑ 运行时动态 import sps/ 下全部代码

关键设计

不是独立部署。run_sps.py 通过 .qmt_root 找到项目根，把 sps/ 加入 sys.path，直接 import 原始模块。

改了代码自动生效，只有 config/watchlist 变了才需重跑 sync_sps_skill.sh。

依赖链

run_sps.py (入口)
├── wave_monitor.py ← db_manager, data_adapter, vector_engine
├── market_radar.py ← baostock
├── backtest.py ← db_manager, vector_engine, strategy_b
└── hk_us_monitor.py
vector_engine.py ← strategy_b
db_manager.py ← data_adapter
data_adapter.py ← qdata / xtquant / akshare (QMT数据源)

未来计划: 统一 HTTP API 部署

Why: 当前 data_adapter.py 硬依赖 QMT 客户端（qdata/xtquant），打包到别的机器上数据源就断了。

Mon, 01 Jan 0001 00:00:00 +0000

DevLog #005: QMT Gateway 鲁棒性修复清单 — P0-P2 分级扫雷

日期: 2026-04-09 状态: 修复中 Tags: qmt-gateway, robustness, grpc, thread-safety

背景

目标：把 QMT Gateway 做到**“可长期稳定支撑批回测 + 准实盘（正在测）+ 实盘执行”**的工程质量。

本文偏工程健壮性（正确性、隔离性、可观测性、可恢复性），不讨论策略收益逻辑。

涉及模块：

qmt_gateway/*（网关本体）
qdata/qdata/adapters/qmt_remote_adapter.py（客户端适配器）
qss/*（交易执行器 / 远端执行服务）

P0: Must Fix Today

这些问题不修会导致：数据错乱、订阅串流、卡死/随机失败、交易服务不可用。

P0-1: 实时订阅的消息隔离与正确性

症状：多个订阅者同时订阅时会串流/抢消息；订阅 A 可能收到订阅 B 的 tick；或漏推。

位置：

qmt_gateway/services/data_service.py（SubscribeQuote 直接消费一个全局流并 yield）
qmt_gateway/bridge/xtdata_bridge.py（单个 _tick_queue + tick_stream()）

修复方向：把 tick 分发改成 fan-out/pub-sub（每个订阅者独立队列），并按 request.symbols 做过滤。

P0-2: `asyncio.Queue` 跨线程使用（线程安全问题）

症状：tick 回调可能在 xtdata 线程里触发，但 asyncio.Queue.put_nowait() 不是线程安全；会出现随机异常、丢消息、甚至卡死。

位置：qmt_gateway/bridge/xtdata_bridge.py（on_data() -> _tick_queue.put_nowait()）

Mon, 01 Jan 0001 00:00:00 +0000

DevLog #002: TSS 策略自进化 — “正在测” 机制深度讨论

日期: 2026-04-09 状态: 讨论稿 Tags: tss, strategy-evolution, 正在测, 评价体系

核心问题

TSS 是否具备"自我迭代能力"？如果可以，应该如何设计？

讨论结论

TSS 可以具备一种有限但很有价值的"自我迭代能力"，但它不是"自己变聪明"，而是：

每天持续生成候选策略或候选变体
用最新行情做"正在测"的在线观察
把观察结果写入记忆
定期根据记忆淘汰、降权、晋升、重组策略

★ Insight ───────────────────────────────────── “正在测"不是回测替代品，而是回测之后的下一层。回测回答"如果过去这样做，结果会怎样” “正在测"回答"如果从今天开始持续跟踪，这个策略在当前市场状态下是不是还活着” ──────────────────────────────────────────────────

“正在测” 的本质

它更像：

影子组合
模拟联赛
在线观察期

策略生命周期：

历史回测：先证明它过去不是纯噪声
滚动验证：再看它在不同年份和市场阶段是否稳定
正在测：让它用最新市场数据持续接受现实检验
晋升或淘汰：根据在线表现决定是否进入正式策略池

策略池四层设计

┌─────────────────────────────────────────────────────────────┐
│ 候选池 │
│ - 只做离线回测与稳健性筛选 │
├─────────────────────────────────────────────────────────────┤
│ 观察池（正在测） │
│ - 每天跟随最新行情更新表现 │
│ - 不直接决定正式组合 │
│ - 重点观察是否延续历史优势 │
├─────────────────────────────────────────────────────────────┤
│ 生产池 │
│ - 已通过历史和在线双重验证 │
│ - 可作为正式优选策略候选 │
├─────────────────────────────────────────────────────────────┤
│ 冻结池 │
│ - 曾经有效但近期失效 │
│ - 暂不删除，保留历史记忆 │
│ - 等待未来市场状态重新匹配 │
└─────────────────────────────────────────────────────────────┘

★ Insight ───────────────────────────────────── 大多数策略不是"永远死"，而是"阶段失效"。冻结池的设计让系统保留了"等待市场状态重新匹配"的可能性。 ──────────────────────────────────────────────────

Mon, 01 Jan 0001 00:00:00 +0000

DevLog #003: no_signal_func 问题分析 — 741个策略中90个无法提取信号函数

日期: 2026-04-12 状态: 分析完成 Tags: strategy-factory, issue-analysis, signal-extraction, 平台兼容性

概述

对 out/ 目录下所有 741 个策略 JSON 进行分析，发现 90 个策略（12.1%）的 pure_alpha_function 字段为 null，无法参与回测。

总体统计

类别	数量	占比	处理建议
A类（可直接修复）	~5 个	0.7%	通过 LLM 直接生成
B类（可重新生成）	~58 个	7.8%	模拟 API 或替代数据
C类（不可修复）	~27 个	3.6%	标记排除，不计入失败率
总可修复率	~70%	—	修复后预估通过率 4.0% → 12.5%

A类：可直接修复（5个）

判定条件：

pure_alpha_function 为 null
logic_extraction.entry_signals 有实质性内容
quality_assessment.completeness 为 medium 或 high
策略描述清晰

典型案例：

Mon, 01 Jan 0001 00:00:00 +0000

DevLog #004: SAF 架构看护体系 — 需求-特性-测试三角闭环

日期: 2026-04-13 状态: 已建立 Tags: architecture, quality-assurance, requirements, testing

背景

随着 SAF 平台规模扩大，如何确保架构完整性不被侵蚀成为重要问题。我们建立了"架构看护体系"，通过三个核心文档形成闭环。

三大核心文档

文档	用途	格式
`FEATURE_TREE.md`	SAF 完整特性树	特性 → 子特性 → 孙子特性
`SYSTEM_REQUIREMENTS.md`	系统需求规格	REQ-ID 格式
`TEST_DESIGN.md`	系统级测试设计	基于需求规格

闭环流程

┌──────────────────────────────────────────────────────────────┐
│ │
│ 需求规格 (SYSTEM_REQUIREMENTS.md) │
│ │ │
│ ▼ │
│ 特性树 (FEATURE_TREE.md) │
│ │ │
│ ▼ │
│ 测试用例 (TEST_DESIGN.md) │
│ │ │
│ ▼ │
│ ┌─────────────────┐ │
│ │ 通过 = 功能正确 │ │
│ └─────────────────┘ │
│ │
└──────────────────────────────────────────────────────────────┘

看护机制

CI/CD Pipeline:
├── pytest (单元测试)
├── pytest --cov (覆盖率检查)
└── 全部通过 → 部署

验证命令

# 运行 SAF 所有测试
cd SAF && pytest tests/ -v --cov=saf --cov-report=term-missing

# 测试通过 = 系统功能良好

看护目标

通过以上机制，确保：

Mon, 01 Jan 0001 00:00:00 +0000

DevLog #001: 回测引擎选型辩论 — Qlib vs VectorBT vs 自研

日期: 2026-04-14 状态: 已定稿 Tags: architecture, backtest-engine, qlib, duckdb

背景

在 SAF 平台开发过程中，我们面临一个关键架构决策：回测引擎层应该如何演进？

已有的组件：

TimeSeriesExecutionEngine — 时序执行框架
PanelExecutionEngine — 截面执行框架
VnPyAdapterEngine — vn.py CTA 适配器
BarStore (SQLite) — K 线持久化
legacy/evaluate/engine.py — 历史包袱

候选引入：

Qlib — 截面评价 + IC/IR + 参数扫描
VectorBT — 参数扫描
DuckDB — 多数据源 ETL Hub

讨论焦点

1. VectorBT 的去留

初始提案：用 VectorBT 做参数扫描，替代手写参数枚举。

辩论过程：

支持引入方：VectorBT 的参数扫描 API 很成熟，可以节省大量开发时间
反对引入方：Qlib 已经覆盖了参数扫描能力，引入 VectorBT 会增加额外依赖

最终结论：不引入 VectorBT，理由是 Qlib 已覆盖其核心能力。

Mon, 01 Jan 0001 00:00:00 +0000

QMT AI Harness 工程与扩展防线设计

文件性质: 架构决策增补草案 (针对 Blueprint 致命缺陷的修复) 重点目标: 彻底消除大模型在金融交易中的“看图作文”幻觉，并加固周边基建的容错能力。

专项一：AI Harness 维度隔离工程设计 (解决缺陷3)

为了防止 AI 因为迎合设定的“多空人设”而产生数据幻觉，我们需要在底层设计一套**特征路由与盲区隔离（Harness）**机制。

1. 核心设计思想：剥夺全知全能的视角

过去我们将包含 OHLC/技术指标/财务面/新闻 的整个巨大 JSON 广播给所有特工。在全新的 Harness 设计下，系统只通过“守门人 (ContextRouter)”对数据进行脱敏切分后再下发。

2. 维度特工阵列 (Dimensional Agents)

A. 技术派特工 (Technical Agent)

看到的数据: 纯 K 线形态、MA60 均线、MACD/BOLL 极值点、价格相对强度。
被屏蔽的数据: 估值 PE、公司名字、新闻利好。
任务: 纯粹从图形和博弈阻力位出发，哪怕公司马上退市，只要底背离了也必须说看多。

B. 价值派特工 (Fundamental Agent)

看到的数据: 历史 5 年 PE/PB 绝对分位值、ROE 变化、当前行业平均市盈率。
被屏蔽的数据: K 线形态走势、短线暴涨暴跌的惊悚新闻。
任务: 冷血计算护城河与折价率。只要低于 30% 分位即给出买点，哪怕天天跌板。

C. 资金/情绪面特工 (Sentiment Agent)

看到的数据: volume_shadow (量影)、大单净流入、外部飞书资讯情绪。
任务: 捕猎当前市场主力的动向和筹码集中度。

3. Harness 融合器 (The Arbitrator)

三位盲人摸象的特工将产生极为结构化的短 JSON 报告（包含 Stance: INT 与 Confidence: 0.0-1.0）。Harness 的最终融合节点（Arbiter）将不再听他们吵架，而是基于他们不可调和的矛盾点做出终裁。例如 Arbiter 的逻辑推演会变成：“该股技术面触发死叉（Technical输出空），但价值层因为暴跌进入极度低估区（Fundamental输出多），综合考虑这属于黄金坑，给出建仓信号。”——这才是真正的投研。

Mon, 01 Jan 0001 00:00:00 +0000

量化交易系统总体架构与一统演进蓝图 (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 获取方式异构差异的数据提取中间件。

二、当前演变断层与技术债务

在独立发展验证后，向整合系统转化存在以下架构冲突，需要在重构计划中逐个拔除：

Mon, 01 Jan 0001 00:00:00 +0000

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

Mon, 01 Jan 0001 00:00:00 +0000

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. 子系统原始定位与边界

这一节补回原有文档中的“角色定位”，避免只看技术实现而忽略业务边界。

Mon, 01 Jan 0001 00:00:00 +0000

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 定义为“分层池生产者”，而不是“强耦合驱动所有下游”的控制中心。

Mon, 01 Jan 0001 00:00:00 +0000

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. 整体关系如何理解

可以用一句话概括这套体系:

Mon, 01 Jan 0001 00:00:00 +0000

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 负责日常编排，不直接承载业务逻辑

Mon, 01 Jan 0001 00:00:00 +0000

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
对外介绍口径
模块说明
管理层摘要

中风险部分

以下内容改动后，需要回归验证:

日志文案
调度脚本中的显示文本
文档里的目录说明
测试里的描述文字

高风险部分

以下内容一旦修改，会直接影响代码运行与导入路径:

Mon, 01 Jan 0001 00:00:00 +0000

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 来完成跨目录导入。这说明仓库虽已开始形成模块边界，但尚未完全进入“稳定包 + 明确入口”的状态。

Mon, 01 Jan 0001 00:00:00 +0000

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 包，零抽象开销。

Mon, 01 Jan 0001 00:00:00 +0000

SAF 重构迁移方案

日期: 2026-04-13 目标: 将 SAF 提升到与 StrategeFactoryFlow/TSS 并列层次，废弃两者中与 SAF 重叠的部分范围: StrategeFactoryFlow, TSS, SAF 三个项目的回测/数据/评估层

1. 当前架构状态

1.1 三个项目现状

qmt/
├── SAF/ # 新共享内核（重构骨架）
│ ├── src/saf/
│ │ ├── capability/ # ✅ 策略能力检测
│ │ ├── data/ # ⚠️ 框架完成，实现缺失
│ │ ├── engine/ # ⚠️ 框架完成，时序实现待补全
│ │ ├── evaluation/ # ⚠️ 框架完成，评分实现缺失
│ │ ├── models/ # ✅ 强类型对象模型
│ │ ├── orchestrator/ # ✅ 编排层框架
│ │ ├── storage/ # ✅ 接口定义
│ │ └── strategy/ # ✅ 策略解析器
│ └── tests/
│
├── StrategeFactoryFlow/ # 策略工厂（待迁移/废弃）
│ ├── evaluate/
│ │ ├── engine.py # ❌ 与 SAF engine 重复 → 废弃
│ │ ├── fast_screen_policy.py # ✅ 保留（SAF 暂无对应）
│ │ └── scorer.py # ⚠️ 与 SAF evaluation 重复 → 迁移/废弃
│ ├── run_evaluate.py # ✅ 保留（批量编排）
│ └── pipeline/ # ⚠️ 部分迁移
│
└── tss/ # 策略运营（待迁移/废弃）
├── data_loader.py # ❌ 与 SAF data 重复 → 废弃
├── run_*_comparison.py # ⚠️ 保留（多策略对比）
├── vnpy_backtest_runner.py # ⚠️ SAF vnpy_adapter 替代
└── ...

1.2 SAF 能力 vs 现有实现 (2026-04-13 更新)

模块	SAF 现状	StrategeFactoryFlow	TSS	结论
策略拓扑检测	✅ 完整	✅ 完整	❌ 无	SAF 优，废弃 SFF
FailureCode	✅ 完整	❌ 散落字符串	❌ 无	SAF 优，废弃 SFF
对象模型	✅ 完整	❌ pd.DataFrame	❌ 无	SAF 优
时序回测引擎	✅ 完整	✅ 完整	⚠️ 简单实现	SAF 已可替代 SFF
截面回测引擎	✅ 完整	✅ 完整	❌ 无	SAF 已可替代 SFF
配对回测引擎	⚠️ 骨架定义	❌ 无	❌ 无	SAF 框架已定义，实现待补
vnpy 适配器	⚠️ 骨架定义	❌ 无	✅ 完整	迁移到 SAF vnpy_adapter
数据加载	⚠️ 协议定义	❌ 直接用 DataService	✅ 完整	迁移 data_loader 到 SAF
评分系统	⚠️ 简化版	✅ 6维评分	❌ 无	迁移 6维到 SAF evaluation
编排/批量	✅ 框架完整	✅ 完整	⚠️ 脚本	SAF orchestrator 已可替代
快筛重试	❌ 无	✅ 完整	❌ 无	SFF 保留或迁移到 SAF

2. 迁移原则

2.1 三不原则

不删除代码：所有待废弃代码移入 legacy/ 目录，保留历史
不中断开发：迁移期间现有流水线照常运行
不破坏接口：SAF 接口先稳定再对接

2.2 迁移顺序

Phase 1: 稳固 SAF 内核（共享层先完成）
Phase 2: 废弃 StrategeFactoryFlow 中对应模块
Phase 3: 废弃 TSS 中对应模块
Phase 4: 清理 legacy/ 目录

3. 完整迁移方案

3.1 Phase 1: 稳固 SAF 内核 ✅ 已完成 (2026-04-13)

目标: 补全 SAF 中缺失的关键实现，使其能够承接废弃模块

Enjoy your life! Let's Claude!

About

About Me

Skills

Contact

Hello World

DevLog #008: QMT Monorepo 统一演进蓝图 — 四段式架构合体

背景

原产物核心定位

ATMS: 战术监控与AI宏观决策

WaveMonitor: 极速算子基座

QMT System: 交易执行与底层基建

DevLog #010: Antigravity 文档评审 — Phase 3 完成确认 + Phase 4 改进建议

Phase 3: QSS 实盘策略 — 全部已完成 ✅

DevLog #006: 辩论引擎记忆系统设计 — SQLite + FTS5 三阶段演进

现状分析

当前记忆机制的缺陷

业界方案对比

为什么不直接用 QMD / ChromaDB

三阶段演进方案

Phase 1: SQLite 辩论历史存储

DevLog #007: DfX 架构设计原则 — QMT 大一统系统工程纪律

背景

一、Design for Maintainability — 以"减法"为核心

激进删除原则

面向 Protocol 的解耦

DevLog #009: SPS ATR 缓冲修复 — 均线滞后性的边界弹性设计

问题描述

修复方案

market_radar.py 修复

vector_engine.py 修复

DevLog #011: SPS OpenClaw Skill 部署架构 — 本地引用 vs HTTP API

当前模式: 本地引用

关键设计

依赖链

未来计划: 统一 HTTP API 部署

DevLog #005: QMT Gateway 鲁棒性修复清单 — P0-P2 分级扫雷

背景

P0: Must Fix Today

P0-1: 实时订阅的消息隔离与正确性

P0-2: asyncio.Queue 跨线程使用（线程安全问题）

DevLog #002: TSS 策略自进化 — “正在测” 机制深度讨论

核心问题

讨论结论

“正在测” 的本质

策略池四层设计

DevLog #003: no_signal_func 问题分析 — 741个策略中90个无法提取信号函数

概述

总体统计

A类：可直接修复（5个）

DevLog #004: SAF 架构看护体系 — 需求-特性-测试三角闭环

背景

三大核心文档

闭环流程

看护机制

验证命令

看护目标

DevLog #001: 回测引擎选型辩论 — Qlib vs VectorBT vs 自研

背景

讨论焦点

1. VectorBT 的去留

QMT AI Harness 工程与扩展防线设计

专项一：AI Harness 维度隔离工程设计 (解决缺陷3)

1. 核心设计思想：剥夺全知全能的视角

2. 维度特工阵列 (Dimensional Agents)

A. 技术派特工 (Technical Agent)

B. 价值派特工 (Fundamental Agent)

C. 资金/情绪面特工 (Sentiment Agent)

3. Harness 融合器 (The Arbitrator)

量化交易系统总体架构与一统演进蓝图 (Assessment & Unification Plan)

一、 系统全貌与原产物核心定位

1.1 ATMS: 战术监控与AI宏观决策

1.2 WaveMonitor: 极速算子基座

1.3 QMT System: 交易执行与底层基建

二、 当前演变断层与技术债务

QMT 高阶架构图

QMT 系统代码架构分析

1. 核心模块缩写与全称

2. 子系统原始定位与边界

QMT Detailed Runtime Flow

P0-2: `asyncio.Queue` 跨线程使用（线程安全问题）

一、系统全貌与原产物核心定位

二、当前演变断层与技术债务

2. `sys.path` 注入与隐式导入较多，包边界未完全硬化