ai-exchange/docs/archive/AI_ICT_下一阶段开发计划_v1.md

AI ICT 下一阶段开发计划 v1

1. 目标

本文档基于以下三类信息制定：

• docs/ 下已有方案文档
• 当前代码实际实现情况
• 当前 SESSION.md 记录的阶段进度与剩余问题

目标是明确：

1. 当前方案哪些部分已经完成
2. 哪些方案合理但应延期
3. 下一阶段真正应该做什么
4. 以什么顺序推进最符合当前仓库现实

---

2. 当前状态总结

2.1 主方案完成度判断

从 docs/AI_ICT_实盘辅助决策系统开发方案_v2.md 看，原主线核心阶段已经基本落地：

• 实时市场真值层：已落地主骨架
• 真实账户与订单只读同步：已落地
• 盘中持续调度与运行监督：已落地
• 决策包与主动提醒：已落地到 workbench / queue 层
• 真实交易映射与盘后闭环：已落地
• 辅助可信度与模型白名单：已落地
• 操作体验与运营工具：已落地
• live adapter readiness prep：已落地
• launch readiness：已新增并可输出 blockers/warnings

从代码上看，这些结论有直接映射：

• runtime：src/services/runtime/trading_runtime_service.py
• decision packet：src/services/decision/decision_packet_service.py
• session/operator/review：src/services/operator/operator_workspace_service.py
• launch readiness：src/services/readiness/launch_readiness_service.py
• API 聚合入口：src/api/server.py

2.2 当前真正未完成的部分

虽然主线骨架已经出来，但仍有三个非常现实的未完成点：

A. 告警还停留在“落库 + workbench 可见”

DecisionPacketService.build_persist_and_alert() 当前只把 alert 写入 decision_alerts，默认 channel 仍是 workbench，没有真正外发到 Telegram / webhook 等外部通道。

对应代码：

• src/services/decision/decision_packet_service.py:110
• src/services/decision/decision_packet_service.py:121

B. launch readiness 还存在明确 blocker / warning

LaunchReadinessService 当前仍然暴露剩余问题：

• trust_model_available
• real_trade_sample_verified
• real_live_path_ready
• live submit strategy 仍需明确

对应代码：

• src/services/readiness/launch_readiness_service.py:60
• src/services/readiness/launch_readiness_service.py:111
• src/services/readiness/launch_readiness_service.py:150

C. 视觉盯盘增强仍是方案态，不是代码态

当前代码中：

• 没有 visual_watch 服务目录
• 没有截图存储模型
• 没有 visual review API
• 没有 alert delivery 机制

说明视觉盯盘方案仍处在设计阶段。

---

3. 对现有方案合理性的判断

3.1 原主线方案是否合理

结论：合理，而且大部分方向已经被代码验证是正确的。

尤其这条主线是正确的：

实时真值 -> 持续调度 -> 决策包 -> 提醒 -> 真实账户映射 -> 研究闭环

从当前代码看，主架构已经成型，因此主方案不需要推翻，只需要进入“收尾硬化 + 缺口补齐”阶段。

3.2 视觉盯盘与主动告警增强方案是否合理

结论：方向合理，但不适合现在整体重投入。

合理点：

• 结构化主引擎 + 视觉增强的分层是对的
• 事件触发式截图比全量高频截图更合理
• 视觉层不仅能看图表，也能看工作台/新闻页/公告页
• 视觉结论结构化回写是正确设计

不适合当前立即全面落地的原因：

• 上游主交易系统还处于 launch-readiness 收尾阶段
• 外发消息闭环还没完成
• launch blockers 还未完全收敛
• 视觉层依赖主判断层稳定，否则容易放大噪声

因此：

视觉方案应保留，但应作为下一阶段中的后置子线，而不是当前主线。

---

4. 当前最合理的下一阶段定位

我认为下一阶段不应该命名为“视觉盯盘阶段”，而应该命名为：

Assisted Trading V1 收尾硬化 + 最小外发告警闭环阶段

目标分两部分：

第一优先级：收敛当前 launch readiness 剩余缺口

第二优先级：把已落库 alert 变成真正外发的最小闭环

也就是说，下一阶段重点不是大规模新功能扩张，而是：

• 收尾
• 硬化
• 最小通知闭环
• 为后续视觉增强打基础

---

5. 下一阶段开发计划

Phase N1：Launch Readiness 收尾与可信度闭环

当前结果

本地环境下已完成这一阶段的关键收尾：

• 使用显式 DATABASE_URL、代理和 OKX 只读凭据完成本地 launch readiness 验证
• scripts/run_launch_readiness.py 已返回 Assisted trading ready: True
• scripts/run_trading_runtime.py 已返回 current_blockers = []
• broker_state_ok、market_stream_connected、market_data_gap_clear、news_provider_cached 均已在本地单次流程中恢复
• real_live_ready 仍保持 false，边界未被放宽

目标

让系统尽可能接近“可用于 assisted trading 软上线”的状态。

阶段结论

N1 的本地主目标已经达成。后续如果不出现环境回退，主线应切换到 N2 最小主动消息告警闭环。

剩余关注项

• decision_support_ready
• real_trade_loop_ready
• real_live_ready = false 的边界维护

任务

（以下条目保留为后续环境回归或继续硬化时参考）

任务

N1-1 收敛 launch readiness warning/blocker

重点围绕：

• trust_model_available
• real_trade_sample_verified
• live_submit_strategy_defined
• real_live_path_ready

其中：

• real_live_path_ready 可以继续保持 false，但必须是清晰边界，不是模糊状态
• live_submit_strategy_defined 需要变成明确配置与明确文档
• trust_model_available 需要决定：
  • 是补更多样本
  • 还是放宽 assisted-trading readiness 对 trust 的门槛
• real_trade_sample_verified 需要明确是：
  • 等真实成交样本
  • 还是用受控演练替代

N1-2 强化 launch readiness 页面与输出解释

• 让 /trading/launch-readiness 的 blocker / warning 更可操作
• next_actions 输出更具体
• workbench 中清楚区分：
  • assisted trading ready
  • real live ready

验收

• /trading/launch-readiness 的输出可直接指导人工下一步动作
• 现有 blocker 与 warning 被压缩到最少
• 边界清晰，不再出现“看起来 ready 但其实不能用”的模糊状态

---

Phase N2：最小主动消息告警闭环

目标

把当前仅落库的 decision_alerts 变成真正可外发的提醒系统。

为什么这是下一阶段应该做的

因为当前代码里已经有：

• alert 生成
• alert 落库
• runtime 里持续生成 decision packet
• workbench 已能看到 recent alerts

缺的只是最后一公里：

decision_alerts -> dispatcher -> external channel -> delivery record

任务

N2-1 增加 alert_deliveries

• 新增迁移表
• 增加 AlertDeliveryRepository

N2-2 增加 notifier 基础设施

优先只支持一个通道：

• Telegram 或 Webhook

不要一开始做多通道。

N2-3 增加 AlertDispatcherService

• 扫描 queued alerts
• 发送成功回写 delivered
• 失败写入 failed
• 已发送不重复发送

N2-4 API / 脚本 / runtime 接入

• POST /trading/alerts/dispatch
• GET /trading/alerts/{id}/deliveries
• scripts/run_alert_dispatcher.py
• runtime 增加 alert_dispatch task

范围约束

当前阶段优先支持：

• candidate_actionable
• ticket_ready
• runtime_degraded（若当前 alert 模型还未包含，则补最小支持）

本轮实现与验证中，candidate_blocked 也已接入 webhook 路由，用于验证 blocked 类消息的真实外发链路。 这证明外发机制已打通，但也同时暴露出下一阶段必须处理的噪声与 backlog 压力问题。

当前结果

N2 最小闭环已经完成：

• alert_deliveries 已新增并成功落库
• AlertDispatcherService 已接入 API / CLI / runtime
• POST /trading/alerts/dispatch 与 GET /trading/alerts/{alert_id}/deliveries 已可用
• scripts/run_alert_dispatcher.py 已可单次运行
• runtime 已包含 alert_dispatch task
• 本地 webhook capture 已完成真实端到端演练
• alert_deliveries 中已出现 channel=webhook、status=delivered 的真实记录

阶段结论

主线应从 N2 切换到 N3。当前主要问题已经不是“能不能发出去”，而是：

• backlog 很大时 dispatch 是否稳定
• blocked 类消息是否会造成噪声洪水
• 在远端 PostgreSQL 不稳定时如何避免整批 dispatch 中断

验收

• alert 可以从 queued 变成 delivered / failed / skipped
• runtime 能自动 dispatch
• 外部通道能收到最小文本提醒
• 已确认在大批量 backlog drain 时仍可能触发 PostgreSQL connection timeout；该问题转入 N3 处理

---

Phase N3：告警质量与 runtime 硬化

目标

在已验证 webhook 外发成功的基础上，解决噪声、重复发送、backlog 处理与数据库不稳定时的稳态运行问题。

关键问题

• 重复 blocked alert 会快速堆积 queue
• 大 limit backlog dispatch 会在状态回写过程中触发 PostgreSQL connection timeout
• 当前 dispatcher 适合最小闭环验证，但还不适合直接长时间清空大 backlog

建议任务

• 增加重复抑制与发送节流
• 将大 backlog drain 改为更保守的批次策略
• 明确哪些 blocked / observe 类 alert 仅保留 workbench 展示
• 在 runtime 中降低 alert dispatch 对数据库瞬时压力

当前新增结果

N3 第一轮硬化已完成：

• 增加单条 alert resend cooldown
• 增加跨 alert 记录的等价消息 cooldown / dedupe
• 将 dispatcher 单次处理量收敛到配置上限
• runtime alert_dispatch 任务已跟随配置上限运行
• 收紧 blocked 外发边界：
  • wait_for_confirmations 保持 workbench-only
  • do_not_execute 可进入 webhook 路径
• 小批量真实 dispatch 验证当前返回 attempted = 0，说明当前 pending backlog 已清空
• 新增 restricted decision support 产品层：
  • trust 输出新增 restricted_decision_support_list
  • readiness 输出新增 restricted_decision_support_ready
  • blacklist 但 analysis-only 的模型现在可进入“受限辅助决策”语义层，但不会进入执行层
• 在显式环境注入（数据库 + 代理 + OKX 只读凭据）下已验证：
  • analysis_only_ready = true
  • decision_support_ready = true
  • restricted_decision_support_ready = true
  • execution_assist_ready = false
• 当前又进一步完成了产品语义收口：
  • readiness 输出新增并验证 product_operating_mode / product_capabilities / product_boundary_notes
  • decision packet 输出已从错误的 observe_only + trust_model_policy_missing 修正为真实的 restricted_decision_support
  • trust policy 映射已支持模型家族级别的模糊匹配
• 当前最终验证边界已确认：
  • analysis_only_ready = true
  • restricted_decision_support_ready = true
  • decision_support_ready = false
  • execution_assist_ready = false
  • 其中 execution_assist_ready = false 当前是产品边界，不是待修复 bug

当前结论

N3 的“噪声与批量压力第一轮治理”已经落地。并且本轮已经补上 runtime severity 分层：

• runtime status 已拆分为 current_blockers、current_warnings、current_noisy_incidents
• runtime incidents 已带 severity
• runtime summary 已新增 runtime_health
• 派生性的 watch skip 信号已从 warning 下沉到 noisy incident

下一步更适合进入：

• queue hygiene 和文档去重收尾
• 再决定是否继续扩大外发范围
• 如有需要，再把 noisy incidents 单独接入更轻量的展示或路由策略

阶段验收

• backlog drain 在数据库偶发抖动下仍可稳定推进
• 重复 blocked alert 不再持续轰炸外部通道
• runtime 中 alert_dispatch 任务保持可观测且低噪声
• assisted_trading_ready = true 与 real_live_ready = false 边界保持不变

---

Phase N3：运行时与告警质量硬化

目标

在外发闭环接通后，先治理噪声和稳定性，再谈视觉增强。

任务

N3-1 告警节流与去重

• 同一 candidate/action/status 不重复刷
• 相同 reason code 最小间隔控制

N3-2 runtime blockers 分级

目前 runtime blocker 很容易和“系统不可用”混在一起。下一步建议分：

• blocker
• warning
• noisy incident

N3-3 决策包文案与字段硬化

当前 DecisionPacketService 已可用，但还可以继续强化：

• why_allowed
• why_blocked
• risk_result
• entry/targets/invalidation 的最终展示一致性

验收

• 告警数量可控
• 同一机会不会过度重复提醒
• runtime 状态更接近真实值班视角

---

Phase N4：视觉盯盘增强预埋，不全面展开

目标

只做基础预埋，不做完整视觉主线实现。

任务

N4-1 保留视觉设计文档与触发模型

• 保留 trigger_type 设计
• 保留 visual_watch_runs / visual_snapshots / visual_reviews 数据模型设计

N4-2 只做接口预留，不重投入实现

如果要动代码，也只做：

• visual review payload 预留字段
• runtime task 扩展点预留

不要现在就做：

• 全套 screenshot pipeline
• browser automation service
• visual workbench panels

原因

当前阶段应先保证：

• 上游主判断稳定
• 外发消息真实可用
• readiness 缺口收敛

之后再做视觉增强，收益更高、返工更少。

---

6. 当前不建议作为主线推进的事项

以下事项目前不建议作为下一阶段主线：

6.1 不建议现在全面启动视觉盯盘实现

原因：

• 主系统还在收尾
• 外发闭环尚未完成
• launch blockers 还未清空
• 容易放大噪声

6.2 不建议现在扩大策略识别器范围

原因：

• 当前瓶颈不在“少一个 ICT 识别器”
• 瓶颈在可运行性、可信度、通知闭环、soft rollout readiness

6.3 不建议现在推进真实自动下单

原因：

• 当前边界明确要求不要默认开启
• assisted trading ready 与 real live ready 必须分离

---

7. 推荐执行顺序

下一阶段推荐按下面顺序推进：

1. N1 Launch Readiness 收尾
2. N2 最小主动消息告警闭环
3. N3 告警质量与 runtime 硬化
4. N4 视觉盯盘增强预埋

换句话说：

先把“能不能上线辅助使用”讲清楚
再把“提醒能不能真正发出来”打通
再治理噪声和稳定性
最后再为视觉增强铺路

---

8. 最终结论

结论一

AI_ICT_实盘辅助决策系统开发方案_v2.md 的主方向是合理的，而且当前代码已经证明主骨架基本成立。

结论二

视觉盯盘方案也是合理的，但对当前项目阶段来说，应该后置，不应抢主线。

结论三

当前最合适的下一阶段，不是做大而全的新能力，而是：

Launch Readiness 收尾 + 最小外发告警闭环 + 运行时/告警硬化

这是最符合当前代码现实、最少返工、最容易尽快进入 assisted-trading soft rollout 的路线。