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。 ...

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 辩论历史存储 目标: 辩论结果持久化，支持按股票/日期查询历史。 ...

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 解耦的好处是：你只需要关心数据提供者有没有你需要的方法， 而不是关心它在类继承树中的位置。 ────────────────────────────────────────────────── ...

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 ...

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），打包到别的机器上数据源就断了。 ...

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()） ...

DevLog #002: TSS 策略自进化 — “正在测” 机制深度讨论 日期: 2026-04-09 状态: 讨论稿 Tags: tss, strategy-evolution, 正在测, 评价体系 核心问题 TSS 是否具备"自我迭代能力"？如果可以，应该如何设计？ 讨论结论 TSS 可以具备一种有限但很有价值的"自我迭代能力"，但它不是"自己变聪明"，而是： 每天持续生成候选策略或候选变体 用最新行情做"正在测"的在线观察 把观察结果写入记忆 定期根据记忆淘汰、降权、晋升、重组策略 ★ Insight ───────────────────────────────────── “正在测"不是回测替代品，而是回测之后的下一层。 回测回答"如果过去这样做，结果会怎样” “正在测"回答"如果从今天开始持续跟踪，这个策略在当前市场状态下是不是还活着” ────────────────────────────────────────────────── “正在测” 的本质 它更像： 影子组合 模拟联赛 在线观察期 策略生命周期： 历史回测：先证明它过去不是纯噪声 滚动验证：再看它在不同年份和市场阶段是否稳定 正在测：让它用最新市场数据持续接受现实检验 晋升或淘汰：根据在线表现决定是否进入正式策略池 策略池四层设计 ┌─────────────────────────────────────────────────────────────┐ │ 候选池 │ │ - 只做离线回测与稳健性筛选 │ ├─────────────────────────────────────────────────────────────┤ │ 观察池（正在测） │ │ - 每天跟随最新行情更新表现 │ │ - 不直接决定正式组合 │ │ - 重点观察是否延续历史优势 │ ├─────────────────────────────────────────────────────────────┤ │ 生产池 │ │ - 已通过历史和在线双重验证 │ │ - 可作为正式优选策略候选 │ ├─────────────────────────────────────────────────────────────┤ │ 冻结池 │ │ - 曾经有效但近期失效 │ │ - 暂不删除，保留历史记忆 │ │ - 等待未来市场状态重新匹配 │ └─────────────────────────────────────────────────────────────┘ ★ Insight ───────────────────────────────────── 大多数策略不是"永远死"，而是"阶段失效"。 冻结池的设计让系统保留了"等待市场状态重新匹配"的可能性。 ────────────────────────────────────────────────── ...

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 策略描述清晰 典型案例： ...

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 # 测试通过 = 系统功能良好 看护目标 通过以上机制，确保： ...