yuqei/ai-exchange

Fork 0

Files

T

Codex d7a4330d30 Add ICT book mainline governance docs

2026-05-21 08:27:12 +08:00

20 KiB

Raw Permalink Blame History

AI ICT 实盘交易分析系统开发计划 v1

1. 文档目标

本文档用于替代旧的分散方案文档，把项目重新收束到一个目标：

尽快完成实盘交易分析主线，让系统从“规则事件识别与回测工具”升级为“书本驱动的半自动实盘交易分析与执行辅助系统”。

当前只聚焦实盘交易分析主线，暂不展开 Training Case Engine、法务内容资产或通用协作流程文档。

根依据：

docs/ICT交易全书_出版终校版.md
docs/AI_ICT_硬性主线约束_必须遵循ICT交易全书_2026-05-21_v1.md

硬性要求：

本计划以及后续任何实盘交易分析开发，必须严格遵循《ICT交易全书》的主线。
若旧需求、旧 backlog、自动化阶段或临时需求与书本主线冲突，以《ICT交易全书》主线为准。
不能映射到 Range / Draw / Location -> Liquidity / Sweep / Path -> Displacement / MSS / FVG / Retest / Session -> backtest -> plan -> intraday focus/no-trade -> journal feedback 的能力，不得进入交易员主界面。

开发原则：

书本是理论与流程源头。
规则引擎负责结构化真值。
AI 智能体负责叙事、解释、监督、计划生成与复盘总结。
风控、下单、仓位、熔断必须由硬规则控制，不能交给 LLM 自由决定。
先做半自动实盘辅助，再考虑极小风险 live adapter；不直接进入全自动实盘。

2. 核心判断

现有系统已经具备良好的底层能力：

行情接入
session / swing / range / liquidity
sweep / displacement / MSS / FVG
bias / signal
backtest / quality gate
paper / semi-auto execution 雏形

但它目前更像：

规则事件识别器 + 信号生成器 + 回测闸门

离书中要求的实盘执行系统还缺一层：

盘前叙事 -> 盘中监控 -> 确认链授权 -> 风险闸门 -> 半自动执行 -> 仓位管理 -> 盘后复盘

因此，后续不应继续优先堆更多零散 ICT 术语识别器，而应优先把书中的执行顺序固化为系统状态机。

3. 书本抽象出的实盘主流程

从《ICT交易全书》抽象出的可执行顺序如下：

Narrative
-> Draw on Liquidity
-> Bias
-> Dealing Range / Location
-> Time Window
-> Setup Type
-> Confirmation Chain
-> Trade Plan
-> Risk Gate
-> Execution
-> Position Management
-> Journal / Review

对应系统语言：

Narrative：当前市场正在讲什么故事。
Draw：价格更可能优先处理哪一侧流动性或失衡。
Bias：当前只允许偏多、偏空、中性还是观察。
Location：当前是否处在有风险效率的位置。
Time Window：当前时段是否授权执行。
Setup Type：当前机会是否属于模型内机会。
Confirmation Chain：是否完成 sweep / displacement / MSS / FVG / retest 等闭环。
Trade Plan：入场、止损、目标、失效、过期、管理动作。
Risk Gate：账户、时段、新闻、质量门槛、持仓限制。
Execution：paper 或 semi-auto；后续才接 live adapter。
Position Management：TP1、TP2、保本、部分止盈、失效退出。
Journal：区分模型失效和执行违规，反哺下一轮计划。

4. 新系统定位

系统不是“AI 自动喊单器”，而是：

AI-assisted ICT Trading Operations System

中文定位：

AI 辅助 ICT 实盘交易分析与半自动执行系统

核心能力：

自动整理盘前结构化交易计划。
自动监控盘中是否出现模型内机会。
自动生成交易计划票据，而不是直接喊买卖。
用硬规则判断是否允许执行。
半自动执行时必须人工确认。
自动追踪订单、仓位、止盈止损和失效条件。
自动生成盘后复盘和下一轮改进项。

5. 总体架构

建议采用三层架构。

5.1 Layer A：Market Truth Layer

负责事实层，不做主观建议。

输入：

OKX candles
当前价
sessions
market calendar
economic calendar
account state
positions
orders

输出：

market state
session state
freshness state
data quality state
account risk state
open position state

要求：

完全结构化。
不依赖 LLM。
可回测、可审计、可复现。

5.2 Layer B：Rule Intelligence Layer

负责 ICT 结构识别。

已有模块继续保留：

session
swing
dealing range
liquidity pool
sweep
displacement
MSS
FVG
bias
signal
backtest

需要升级：

bias 从 latest_mss 升级为 Narrative -> Draw -> Bias
signal 从单一 SWEEP_MSS_FVG 升级为 TradePlanCandidate
target 从固定百分比升级为 IRL / ERL / liquidity / ADR / STD
invalidation 从简单标签升级为结构化退出条件

5.3 Layer C：AI Agent Layer

负责解释、计划、监督和复盘。

LLM 可以参与：

盘前叙事摘要
setup 解释
交易计划自然语言说明
风险提示
复盘归因
周度报告

LLM 不允许参与：

绕过风控
直接下单
修改风险上限
自行扩大仓位
在无结构证据时生成交易建议

6. 智能体划分

6.1 Market Truth Agent

职责：

检查行情新鲜度。
检查 candle 连续性。
维护当前 session。
识别新闻窗口和开盘波动窗口。
读取账户与持仓状态。

输出：

{
  "market_data_fresh": true,
  "session_code": "NY_AM",
  "news_window_state": "clear",
  "opening_volatility_state": "normal",
  "account_risk_state": "normal"
}

第一阶段必须落地为纯规则模块。

6.2 Narrative Agent

职责：

盘前生成 Narrative。
定义主 Draw、次 Draw。
生成 Bias。
写明失效条件。
生成当天不可做环境。

输出：

{
  "narrative_code": "bullish_after_sell_side_sweep",
  "primary_draw": {
    "side": "buy_side",
    "target_type": "external_liquidity",
    "target_id": 123
  },
  "secondary_draw": {
    "side": "sell_side",
    "target_type": "internal_liquidity",
    "target_id": 88
  },
  "bias": "bullish",
  "execution_intensity": "medium",
  "invalidation": [
    "price_reclaims_old_control",
    "mss_invalidated",
    "news_window_active"
  ]
}

LLM 可用于解释，但结构化字段必须由规则和证据填充。

6.3 Setup Watcher Agent

职责：

盘中监控是否出现模型内机会。
不做全天随机扫描，只监控计划内方向和时段。
当前第一模型锁定为：

Daily Range / OSOK
+ Sweep
+ MSS
+ FVG retrace
+ IRL / ERL target

输出：

{
  "candidate_type": "OSOK_SWEEP_MSS_FVG",
  "status": "candidate",
  "side": "buy",
  "evidence": {
    "sweep_id": 1,
    "mss_id": 2,
    "fvg_id": 3,
    "liquidity_target_id": 4
  }
}

6.4 Confirmation Agent

职责：

判断确认链是否闭合。
确认流动性处理是否已经发生。
确认 displacement 是否有效。
确认 MSS 是否 accepted。
确认 FVG 是否仍可执行。
确认当前时段是否允许执行。

输出：

{
  "confirmation_state": "confirmed",
  "missing_requirements": [],
  "quality_score": 4,
  "quality_reasons": [
    "sweep_confirmed",
    "mss_accepted",
    "fvg_open",
    "allowed_session"
  ]
}

硬规则：

缺 confirmation 不允许进入标准风险执行。
低质量机会只能观察，不能创建 semi-auto 执行票。

6.5 Trade Plan Agent

职责：

生成标准交易计划票据。
把 setup 转成可执行计划。

计划字段：

symbol
side
model_code
session_code
entry_zone
stop_loss
tp1
tp2
invalidation
expiry
risk_pct
management_rules

目标规则：

TP1 优先来自 IRL。
TP2 优先来自 ERL。
不再使用固定百分比作为默认 TP。
若 IRL / ERL 不明确，则交易计划不成立。

6.6 Risk Governor

职责：

最终执行闸门。
必须是纯规则系统。

检查项：

行情是否新鲜。
回测质量门槛是否允许该模型执行。
是否处于允许 session。
是否处于新闻禁运或开盘高噪音窗口。
是否存在 stop。
RR 是否达标。
单笔风险是否在上限内。
日亏损是否触发熔断。
连亏是否触发熔断。
是否已有持仓。
是否同向暴露过高。
是否超出每日最大交易次数。

输出：

{
  "allowed": false,
  "decision": "reject",
  "reasons": [
    "news_window_active",
    "quality_gate_not_passed"
  ]
}

6.7 Execution Agent

阶段一只做：

paper
semi_auto

semi_auto 必须：

生成执行票。
等待人工确认。
记录确认人、确认时间、确认版本。
下单前再次跑 Risk Governor。

后续 live adapter 必须支持：

bracket order / OCO
partial take profit
stop move
cancel all
kill switch
order reconciliation
exchange error handling

6.8 Journal Agent

职责：

盘后自动生成复盘。
区分模型问题和执行问题。
统计框架内执行率。
统计模型外交易率。
统计风险违规次数。

输出：

{
  "trade_id": 1,
  "model_compliance": true,
  "risk_compliance": true,
  "execution_error": false,
  "model_failure": false,
  "review_tags": [
    "valid_model",
    "tp1_hit",
    "managed_by_plan"
  ],
  "next_actions": [
    "keep_same_model",
    "review_fvg_fill_behavior"
  ]
}

7. 数据模型新增与调整

7.1 新增 `market_states`

用途：

记录当前市场事实快照。

核心字段：

instrument_id
snapshot_ts
session_code
data_freshness
candle_age_seconds
news_window_state
opening_volatility_state
account_state jsonb
position_state jsonb
meta jsonb

7.2 新增 `trading_plans`

用途：

保存盘前计划。

核心字段：

instrument_id
plan_date
plan_type
narrative_code
primary_draw jsonb
secondary_draw jsonb
bias
execution_intensity
allowed_sessions jsonb
invalidations jsonb
no_trade_conditions jsonb
status
ai_summary
evidence jsonb
created_at

7.3 新增 `trade_plan_candidates`

用途：

保存盘中机会候选。

核心字段：

trading_plan_id
instrument_id
model_code
side
session_code
candidate_state
confirmation_state
quality_score
entry_low
entry_high
stop_loss
tp1
tp2
rr_tp1
rr_tp2
expiry_ts
invalidations jsonb
management_rules jsonb
evidence jsonb
ai_explanation

7.4 调整 `trade_signals`

方向：

trade_signals 不再作为“泛信号候选”，而是作为已经通过计划和确认链的执行候选。
新字段或 meta 必须包含：
- trading_plan_id
- candidate_id
- primary_draw
- target_plan
- risk_governor_decision
- confirmation_quality

7.5 调整 `trade_executions`

方向：

从模拟执行记录升级为订单生命周期记录。

新增语义：

execution_ticket_id
confirmation_required
confirmed_by
confirmed_at
broker_order_ids
bracket_state
fill_state
position_state
close_reason
reconciliation_state

7.6 新增 `trading_journal_entries`

用途：

保存盘后复盘。

核心字段：

trade_signal_id
execution_id
plan_id
model_code
compliance_state
model_failure
execution_violation
risk_violation
review_tags jsonb
metrics jsonb
ai_review
next_actions jsonb

8. API 设计

8.1 盘前计划

POST /trading/plans/generate
GET  /trading/plans/latest
GET  /trading/plans/{id}
POST /trading/plans/{id}/activate
POST /trading/plans/{id}/cancel

8.2 盘中监控

GET  /trading/market-state
POST /trading/watch/run
GET  /trading/candidates
GET  /trading/candidates/{id}
POST /trading/candidates/{id}/confirm-check

8.3 交易计划票

POST /trading/candidates/{id}/build-ticket
GET  /trading/tickets
GET  /trading/tickets/{id}
POST /trading/tickets/{id}/risk-check

8.4 执行

POST /trading/tickets/{id}/paper-execute
POST /trading/tickets/{id}/semi-auto-submit
POST /trading/tickets/{id}/confirm
POST /trading/executions/{id}/cancel
POST /trading/executions/{id}/sync

8.5 复盘

POST /trading/journal/generate
GET  /trading/journal
GET  /trading/journal/summary
GET  /trading/research/weekly-review

9. 前端工作台

当前前端不应做成普通 dashboard，而应做成实盘工作台。

9.1 顶部状态条

展示：

symbol
session
data freshness
news state
account risk state
open position
kill switch

9.2 盘前计划区

展示：

Narrative
primary Draw
secondary Draw
Bias
allowed sessions
no-trade conditions
invalidation

9.3 盘中候选区

展示：

setup candidate
confirmation chain
quality score
missing requirements
evidence links

9.4 执行票区

展示：

side
entry zone
stop
TP1 / TP2
RR
risk amount
expiry
management rules
risk governor result

9.5 仓位管理区

展示：

current position
fill state
TP progress
stop state
invalidation alerts
cancel / close / sync actions

9.6 盘后复盘区

展示：

model compliance
risk compliance
execution violations
model failure vs execution failure
next actions

10. 实施阶段

Phase 0：文档收束与旧方案冻结

目标：

删除旧的分散 docs。
保留书稿和本计划。
后续所有实盘主线开发引用本计划。

交付：

docs/ICT交易全书_出版终校版.md
docs/AI_ICT_实盘交易分析系统开发计划_v1.md

验收：

docs 下不再混放旧方案。

Phase 1：Trading Plan 核心结构

目标：

让系统先会写“盘前计划”，而不是直接生成信号。

任务：

新增 trading_plans migration / model / repository。
新增 TradingPlanService。
把现有 range / liquidity / MSS / FVG / session 汇总成计划输入。
生成结构化 plan：
- Narrative
- primary Draw
- secondary Draw
- Bias
- allowed sessions
- invalidations
- no-trade conditions
新增计划单元测试。

验收：

能生成当天 BTC / ETH 的结构化交易计划。
计划中必须有 Draw 和 Invalidation。
缺 Draw 或 Invalidation 时，计划不得进入 active。

Phase 2：Market State 与 Risk Governor

目标：

建立实盘执行前的事实和风险闸门。

任务：

新增 MarketStateService。
新增行情 freshness 检查。
新增 session state。
新增 news window / opening volatility 占位接口。
新增 RiskGovernorService。
把现有 AccountRiskState 扩展为完整 RiskContext。
为每个拒绝原因建立稳定 code。

验收：

风险闸门能独立运行。
数据陈旧时拒绝执行。
新闻窗口 active 时拒绝新开仓。
低质量 backtest gate 时拒绝 semi-auto。

Phase 3：Trade Plan Candidate

目标：

把 setup 从“信号”升级为“交易计划候选”。

任务：

新增 trade_plan_candidates。
新增 SetupWatcherService。
新增 ConfirmationService。
第一模型锁定：
- OSOK / Daily Range
- Sweep
- MSS
- FVG retrace
候选必须绑定 active trading plan。
候选必须绑定 confirmation state。

验收：

没有 active plan 不生成 candidate。
缺 sweep / MSS / FVG 不生成 executable candidate。
候选可以说明缺少哪些确认条件。

Phase 4：目标与退出重构

目标：

TP1 / TP2 从固定百分比改为书本式 IRL / ERL。

任务：

新增 TargetSelectionService。
从 liquidity pools / dealing ranges / session pivots / ADR / STD 中选择目标。
TP1 优先内部目标。
TP2 优先外部目标。
增加 management_rules：
- TP1 partial
- move stop
- invalidate on reclaim
- expire by session

验收：

交易计划没有结构目标时不得执行。
TP1 / TP2 必须能追溯来源。
退出规则必须进入 backtest 和 execution meta。

Phase 5：Backtest 升级为 Plan Replay

目标：

回测不再只测 signal，而是测完整 trading plan candidate。

任务：

支持 trading_plan_id 维度。
支持 plan active 后逐根 replay。
记录 candidate 何时出现、何时确认、何时入场、何时失效。
统计：
- plan win rate
- candidate confirmation rate
- executed expectancy
- model compliance
- session performance
- draw target hit rate

验收：

回测能证明某个模型是否值得进入 semi-auto。
quality gate 基于 executed sample，而不是泛信号数量。
输出可解释失败原因。

Phase 6：Semi-auto Execution Ticket

目标：

形成安全的人工确认执行票。

任务：

新增 execution ticket。
ticket 生成前跑 Risk Governor。
ticket 确认前再次跑 Risk Governor。
半自动确认记录：
- confirmed_by
- confirmed_at
- ticket_snapshot
支持 paper execute。
支持 semi-auto pending。

验收：

未确认不得进入 semi-auto pending。
风险检查失败不得创建 execution。
execution ticket 可完整复盘。

Phase 7：Live Adapter 预备层

目标：

为未来真实交易所执行建立接口，但不默认开启。

任务：

定义 BrokerAdapter 接口。
定义 OKX order adapter 占位。
支持 bracket / OCO 语义。
支持 order reconciliation。
支持 cancel all。
支持 kill switch。
默认 LIVE_TRADING_ENABLED=0。

验收：

live adapter 不会被误触发。
无显式环境变量和人工确认不能下真实单。
所有 live 操作有审计记录。

Phase 8：Journal 与 Weekly Review

目标：

把实盘行为变成可迭代研究闭环。

任务：

新增 trading_journal_entries。
自动生成单笔复盘。
区分：
- model failure
- execution violation
- risk violation
- plan violation
生成周报：
- 框架内执行率
- 模型外交易率
- 风险违规次数
- high quality session
- low quality session
- 下周三条调整动作

验收：

每笔交易都有 journal。
每周能输出复盘 summary。
系统能指出下一轮应该改什么，而不是只展示盈亏。

11. 最小可实盘版本定义

MVP 不等于 live auto trading。

最小可实盘版本定义为：

能生成当天 active trading plan。
能监控 plan 内 candidate。
能给出 confirmation chain。
能生成 execution ticket。
Risk Governor 能拒绝不合格交易。
人工确认后能 paper / semi-auto 记录。
能按计划管理 TP1 / TP2 / invalidation。
能生成盘后 journal。

不包含：

全自动真实下单。
多策略自动切换。
LLM 自由生成交易方向。
高频 scalping。
未经验证的新模型上线。

12. 推荐立即执行顺序

第一轮建议只做以下 5 个文件/模块层：

trading_plans
market_states
risk_governor
trade_plan_candidates
execution_tickets

不要先做：

更多 ICT 术语识别器。
大型前端重写。
live 下单。
Training 产品增强。

13. 第一轮验收清单

第一轮完成时，必须能回答：

今天系统给出的 Narrative 是什么？
主 Draw 是哪个目标？
Bias 是什么？为什么？
当前是否允许交易？为什么？
如果出现机会，确认链缺什么？
如果确认链完整，entry / stop / TP1 / TP2 来自哪里？
风险闸门是否放行？如果拒绝，原因是什么？
这笔交易若执行，如何退出？
这笔交易若失败，是模型失败还是执行违规？

如果这 9 个问题不能结构化回答，系统还不具备实盘交易分析能力。

14. 当前结论

最重要的方向调整是：

从“事件识别优先”
切换到
“交易计划与执行授权优先”

现有代码底座可以保留，但主线要变成：

Trading Plan
-> Candidate Watch
-> Confirmation
-> Risk Governor
-> Execution Ticket
-> Position Management
-> Journal

这条线更贴近《ICT交易全书》的核心精神，也更接近真正可用的实盘交易分析系统。

20 KiB Raw Permalink Blame History Unescape Escape

AI ICT 实盘交易分析系统开发计划 v1

1. 文档目标

2. 核心判断

3. 书本抽象出的实盘主流程

4. 新系统定位

5. 总体架构

5.1 Layer A：Market Truth Layer

5.2 Layer B：Rule Intelligence Layer

5.3 Layer C：AI Agent Layer

6. 智能体划分

6.1 Market Truth Agent

6.2 Narrative Agent

6.3 Setup Watcher Agent

6.4 Confirmation Agent

6.5 Trade Plan Agent

6.6 Risk Governor

6.7 Execution Agent

6.8 Journal Agent

7. 数据模型新增与调整

7.1 新增 market_states

7.2 新增 trading_plans

7.3 新增 trade_plan_candidates

7.4 调整 trade_signals

7.5 调整 trade_executions

7.6 新增 trading_journal_entries

8. API 设计

8.1 盘前计划

8.2 盘中监控

8.3 交易计划票

8.4 执行

8.5 复盘

9. 前端工作台

9.1 顶部状态条

9.2 盘前计划区

9.3 盘中候选区

9.4 执行票区

9.5 仓位管理区

9.6 盘后复盘区

10. 实施阶段

Phase 0：文档收束与旧方案冻结

Phase 1：Trading Plan 核心结构

Phase 2：Market State 与 Risk Governor

Phase 3：Trade Plan Candidate

Phase 4：目标与退出重构

Phase 5：Backtest 升级为 Plan Replay

Phase 6：Semi-auto Execution Ticket

Phase 7：Live Adapter 预备层

Phase 8：Journal 与 Weekly Review

11. 最小可实盘版本定义

12. 推荐立即执行顺序

13. 第一轮验收清单

14. 当前结论

20 KiB

Raw Permalink Blame History

7.1 新增 `market_states`

7.2 新增 `trading_plans`

7.3 新增 `trade_plan_candidates`

7.4 调整 `trade_signals`

7.5 调整 `trade_executions`

7.6 新增 `trading_journal_entries`