mystocks_spec vs MPW-hermes vs daily-stock 定位对比

用户量化生态中存在三个容易混淆的系统：mystocks_spec（业务终端）、MPW-hermes（策略编排/回测）、daily-stock（每日工作流 skill）。它们分工明确但边界容易踩坑，本文给出清晰的对比与协同关系。

一、三系统一句话定位

二、核心维度对比

三、职责边界

mystocks_spec 负责

• 行情展示、技术分析 UI、策略管理界面、风控监控、投资组合、交易辅助、系统管理
• ArtDeco 金融终端视觉体验
• 业务数据的本地持久化（PostgreSQL 业务表、TDengine 时序缓存）
• 对前端用户的 API 契约（OpenAPI 单一事实来源）

MPW-hermes 负责

• 跨项目编排：Pipeline / Cascade / Parallel 三种模式
• 单项目 worktree 并行 + 写审分离（Codex 写 + Claude Code 审）
• function-tree 主线治理（FT 节点深度 ≤ 2 硬约束）
• A 股策略回测引擎（T+1 拦截 + 成本模型 + 涨跌停）
• 因子 Alpha 策略 + 因子注册（对接 factor-pool）
• Optuna 参数优化 + 过拟合防护 + Walk-Forward 滚动验证
• QuantDinger 作为执行域成员（非平级 HEAD）

daily-stock 负责

• 扫描 Obsidian Vault 持仓目录，合并多账户去重
• 更新 mystocks/index.md（行业分布 + 概念分布 + 技术指标）
• 按持仓股拉取东方财富新闻
• 用 mystock-analysis skill 逐只技术分析 + 飞书推送
• MySQL 备份（account_overview / holdings / news / analysis_reports 四表）
• 触发盘中监控（market-monitor skill）

四、数据流与协同关系

                    OpenStock (NAS:8040, 数据提供者)
                       ↑          ↑
          HTTP REST    │          │  HTTP REST
                       │          │
    ┌──────────────────┘          └──────────────────┐
    │                                                 │
    ▼                                                 ▼
┌────────────────┐                          ┌──────────────────┐
│ mystocks_spec  │                          │   MPW-hermes     │
│ (业务终端)     │                          │ (策略编排/回测)  │
│                │                          │                  │
│ TDengine 缓存  │                          │ factor-pool 接入 │
│ PostgreSQL业务 │                          │ QuantDinger 执行 │
└────────────────┘                          └──────────────────┘
    ▲                                                 ▲
    │ 读 MySQL holdings                               │ 策略导入
    │                                                 │
    │     ┌──────────────────────────────┐            │
    │     │     daily-stock skill        │            │
    │     │  (每日工作流自动化)          │            │
    │     │                              │            │
    │     │  持仓 → 新闻 → 分析 → 飞书  │            │
    │     │  → MySQL 备份 → 盘中监控    │            │
    │     └──────────────────────────────┘            │
    │                                                 │
    │  写 MySQL hermes.holdings                       │
    │  (daily-stock 产出的持仓数据)                   │
    │                                                 │
    └───────────── 共享 MySQL hermes 库 ─────────────┘

关键协同点： - daily-stock 写 MySQL holdings → mystocks_spec 可读（理论上的协同，实际各自独立运行） - mystocks_spec 与 MPW-hermes 共享 OpenStock → 都是消费者，互不干扰 - trade-audit skill 读券商导出文件 → 独立于三者，做交易复盘审计

五、功能重叠与边界澄清

5.1 技术分析

• mystocks_spec：内建技术分析 UI（domain-02，90% 完成），用户点击交互
• MPW-hermes：回测引擎内的技术指标计算，批量程序化
• daily-stock：调用 mystock-analysis skill，输出 MD 报告 + 飞书摘要

边界：mystocks_spec 是"交互式"，MPW-hermes 是"批量回测式"，daily-stock 是"定时报告式"。

5.2 策略管理

• mystocks_spec：策略 UI 展示与参数配置（domain-03，85% 完成）
• MPW-hermes：策略研发、适配、回测、优化（PluginRegistry 8 插件）
• daily-stock：不涉及策略管理

边界：mystocks_spec 展示策略，MPW-hermes 研发策略。用户在 MPW-hermes 回测验证 → 通过的因子/策略 → 可在 mystocks_spec UI 中配置监控。

5.3 持仓与交易

• mystocks_spec：投资组合与交易辅助 UI（domain-05，70%，开发中）
• MPW-hermes：Paper Trading 模拟（10 只标的执行适配，成交率 98%）
• daily-stock：持仓数据汇总与 MySQL 备份（只读分析，不下单）

边界：实盘交易执行归 QuantDinger（执行域成员），mystocks_spec 提供辅助 UI，MPW-hermes 做回测验证，daily-stock 做数据汇总。

六、技术栈对比

七、演进路线对比

mystocks_spec

• 当前：B4.014 OpenStock routes 迁移（Phase 1 六批分域）
• 中期：完成 OpenStock 消费者边界收口（Phase 2/3，退役 ~8,600 LOC akshare 代码）
• 长期：投资组合与交易域完善（domain-05 至 ✅）

MPW-hermes

• 当前：12/12 Phase 完成，312 tests 全绿，三步实战验证完成
• 中期：导入 Obsidian vault 策略文件逐个测试；factor-pool draft→verified 推进
• 长期：Hermes cron 每日自动跑因子选股 + 信号生成；QuantDinger 实盘对接

daily-stock

• 当前：稳定运行，工作日 09:00 cron 自动执行
• 持续优化：冷却期机制（3 小时）、多账户合并去重、V5 风控规则拦截
• 与 trade-audit 解耦：审计功能独立子目录，不混入 daily-stock scripts

八、用户架构原则在三者中的体现

用户长期坚持的原则在三个系统中有不同体现：

九、何时不该混淆

常见误用警示：

1. ❌ 用 MPW-hermes 做日常持仓监控 → 应该用 daily-stock + mystocks_spec
2. ❌ 用 mystocks_spec 做策略批量回测 → 应该用 MPW-hermes（它的回测引擎经过 312 tests 验证）
3. ❌ 在 daily-stock 里混入交易审计 → 用户明确要求 trade-audit 完全独立
4. ❌ 让 mystocks_spec 直接 import akshare → 违反 OpenStock 消费者边界 SOT
5. ❌ 让 MPW-hermes 自建数据抓取层 → 违反"REST 直连优先，不自己实现数据抓取层"
6. ❌ 把 daily-stock 的脚本当作 mystocks_spec 的数据源 → 两者独立，daily-stock 只写 MySQL/Obsidian，不向 mystocks_spec 提供数据

十、科学组织的建议

基于三者定位，推荐的协作模式：

1. 策略研发阶段（MPW-hermes 主导） - 在 MPW-hermes 用 function-tree 治理研发策略 - 接入 factor-pool 真实因子，跑 Optuna 优化 + Walk-Forward 验证 - 通过的策略导出为可复用产出物（.h5 因子文件）

2. 策略部署阶段（mystocks_spec 主导） - 在 mystocks_spec UI 配置已验证的策略参数 - 监控运行状态（domain-04 风险管理 + domain-06 监控告警） - 用户通过 Web 终端做日常决策

3. 日常运营阶段（daily-stock 主导） - 工作日 09:00 自动汇总持仓 + 拉取新闻 + 技术分析 - 飞书推送摘要，用户在手机即可查看 - 盘中 market-monitor 每分钟刷新（30 分钟 cron 扫描风控）

4. 复盘阶段（trade-audit 主导，独立于三者） - 工作日 18:30 自动复盘审计 - 读券商导出文件，FIFO 配对 + V5 风控规则检查 - 输出审计报告到 Obsidian + 飞书

四个阶段、四个系统，各司其职，通过 OpenStock（数据）、MySQL（持仓）、Obsidian（报告）三个共享层串联。

相关页面：mystocks-spec-项目全景、openstock-消费者边界与数据源迁移、mystocks-spec-治理体系、A股策略体系全景：从分形到动量到趋势跟随。