ai-exchange/docs/archive/AI_ICT_盯盘告警架构图_v1.md

AI ICT 盯盘告警架构图 v1

1. 文档目标

本文档保存基于当前代码库梳理出的“AI 盯盘 + 主动告警”总体架构图，作为后续实现技术设计、任务拆分和模块落地的基准版本。

结论：

• 当前仓库已经具备结构化主引擎骨架
• 后续重点不是重做策略核心，而是在现有 runtime / candidate / decision packet 之上增加视觉复核与外发告警
• 最优路径是“结构化主判断 + 视觉增强 + 主动通知 + 人工反馈回流”

2. 当前代码库中的现有基础

已存在的关键能力：

• 运行时调度：src/services/runtime/trading_runtime_service.py
• 市场状态监控：src/services/market_state/market_state_service.py
• 候选机会生成：src/services/trade_plan_candidates/setup_watcher_service.py
• 候选确认链：src/services/trade_plan_candidates/confirmation_service.py
• 决策包生成：src/services/decision/decision_packet_service.py
• 告警落库：src/repositories/decision_packet_repository.py
• API 暴露：src/api/server.py
• 交易工作台页面：src/web/

这些能力已经构成了盯盘系统的主骨架。

3. 分层架构

建议整体拆成六层：

1. 市场数据与运行时层
2. 结构化机会识别层
3. 决策与风险闸门层
4. 视觉观察层
5. 告警编排与消息分发层
6. 人工确认与反馈学习层

3.1 市场数据与运行时层

职责：

• 维护调度循环
• 获取最新市场状态
• 检查 freshness / stream / gap / news / session
• 维护 degraded mode

代码映射：

• src/services/runtime/trading_runtime_service.py
• src/services/market_state/market_state_service.py

3.2 结构化机会识别层

职责：

• 绑定 active trading plan
• 识别 sweep / MSS / FVG / target plan
• 生成 trade plan candidate
• 明确缺失确认条件与阻断原因

代码映射：

• src/api/trading_runtime.py
• src/services/trade_plan_candidates/setup_watcher_service.py
• src/services/trade_plan_candidates/confirmation_service.py

3.3 决策与风险闸门层

职责：

• 将 plan / candidate / signal / ticket / risk 汇总为统一 decision packet
• 生成 actionable / blocked / monitoring 等业务结论
• 形成可落库、可审计的 alert candidate

代码映射：

• src/services/decision/decision_packet_service.py
• src/services/execution/
• src/repositories/decision_packet_repository.py

3.4 视觉观察层

职责：

• 打开图表或工作台页面
• 截图采样
• 对高价值时刻做视觉复核
• 输出 visual_confirm / caution / mismatch / unavailable

这层应当只做增强，不替代结构化主判断。

3.5 告警编排与消息分发层

职责：

• 从 decision alerts 队列读取 queued 事件
• 套用消息模板
• 分发到 Telegram / 企业微信 / Webhook / 邮件等通道
• 写回发送状态、失败原因、发送时间

3.6 人工确认与反馈学习层

职责：

• 支持人工查看告警、截图、理由
• 支持添加 operator note
• 将“有用 / 太早 / 太晚 / 误报”等反馈回流到后续优化

4. 关键原则

1. 结构化层是主引擎
2. 视觉层只做高价值时刻增强
3. 风控和市场真值层优先级高于视觉层
4. 所有提醒必须结构化，可审计、可回放
5. 系统优先支持“提醒人”，不是直接自动实盘下单
6. 原型验证与正式产品要分开：研发期可以借助 computer use / 截图工具验证思路，但正式落地必须依赖系统内建的浏览器自动化、截图和告警闭环
7. 告警必须带结论和理由，不能只发截图

5. 额外吸收的实施边界

结合 AI_ICT_盯盘告警技术设计稿_v1.md，补充以下边界：

• 视觉层除了看图表，也适合看新闻日历页、公告页、工作台状态页
• 视觉层适合处理“候选接近可执行”“系统异常巡检”“session 切换复核”三类高价值场景
• 不做 24 小时全量高频截图；只在事件触发时启动
• 视觉结论必须结构化回写，不能只留图片文件
• 研发验证阶段可先用现有人工页面或 browser 工具验证 ROI，确认有价值后再产品化

5. 总体时序

标准流程：

TradingRuntimeScheduler.run_cycle()
    ↓
更新 market_state
    ↓
检查 freshness / stream / gap / news / session
    ↓
生成 / 更新 active trading plan
    ↓
SetupWatcherService.build_candidate()
    ↓
DecisionPacketService.build_persist_and_alert()
    ↓
alert 写入 decision_alerts
    ↓
Alert Dispatcher 读取 queued alerts
    ↓
发送消息给用户

高价值机会的增强流程：

Decision packet 进入 actionable 状态
    ↓
触发 Visual Watch Service
    ↓
打开 chart / workbench
    ↓
截图 + 视觉总结
    ↓
把 visual summary 追加到 alert payload
    ↓
发送高优先级提醒

6. 最终架构图（文字版）

[Market Data / OKX / Sessions / News / Stream]
                ↓
      [MarketStateService]
   freshness / stream / gap / news / session
                ↓
      [TradingRuntimeScheduler]
     plan / watch / decision / broker / reconcile
                ↓
       [SetupWatcherService]
 active plan + sweep + MSS + FVG + target plan
                ↓
      [ConfirmationService]
   osok/range + sweep + MSS + FVG retrace
                ↓
      [DecisionPacketService]
 status / action / risk / explanation / alerts
                ↓
      [Decision Alert Queue DB]
                ↓
     ┌───────────────┴───────────────┐
     ↓                               ↓
[Alert Dispatcher]             [Visual Watch Service]
send TG/WeCom/Webhook          screenshot / chart review
     ↓                               ↓
     └───────────────┬───────────────┘
                     ↓
            [Final Human Alert]
   actionable / blocked / caution / system degraded
                     ↓
        [Operator Notes / Review / Journal]
                     ↓
            [Feedback-driven tuning]

7. 架构落地建议

建议按以下顺序推进：

阶段 1

先打通结构化盯盘与消息通知：

• runtime 周期运行
• candidate / decision packet 持续生成
• alert dispatcher 真实发消息

阶段 2

在高优先级时刻追加截图证据：

• candidate actionable
• ticket ready
• runtime degraded

阶段 3

增加视觉复核：

• visual confirm
• visual caution
• visual mismatch

阶段 4

增加人工反馈回流：

• operator notes
• alert usefulness 标签
• 后续统计和调优

8. 文档用途

本文件用于：

• 保存总体结构图
• 给后续技术设计稿提供总纲
• 为模块拆分、接口定义、数据库扩展提供边界约束