Productize decision assistant archive and context cockpit batch
This commit is contained in:
Codex
@@ -0,0 +1,133 @@
|
||||
# AI_ICT + TradingAgents P0-P6 合理性审查与优化结论 v1
|
||||
|
||||
## 1. 审查目标
|
||||
|
||||
本文件用于在正式进入自动化流程开发阶段前，对 `Research Council P0-P6` 进行一次阶段合理性审查。
|
||||
|
||||
审查问题：
|
||||
|
||||
1. P0-P6 的阶段划分是否合理
|
||||
2. 是否存在阶段过度扩张或重复建设
|
||||
3. 自动晋级 / 退出条件是否可执行
|
||||
4. 是否存在越过 execution gate / live readiness / trust bucket 的风险
|
||||
5. 是否可以停止继续写阶段文档，进入自动化执行层开发
|
||||
|
||||
---
|
||||
|
||||
## 2. 总体结论
|
||||
|
||||
结论：
|
||||
|
||||
> P0-P6 作为 `AI_ICT + TradingAgents` 融合主线的自动化阶段是合理的，可以保留；但 P6 必须被定义为当前研究委员会链路的终端治理入口，不应继续自动扩展 P7。
|
||||
|
||||
补充裁定：用户明确要求“从 P7 开始设计自动化”时，P7 只能作为自动化执行层阶段使用，不得解释为 `Research Council P7`。
|
||||
|
||||
本次审查后的执行原则：
|
||||
|
||||
```text
|
||||
P0-P6 阶段冻结
|
||||
-> 默认运行 P6 governance tick
|
||||
-> no_op_healthy 则停止
|
||||
-> cycle_required 才补跑 optimization cycle
|
||||
-> bounded_slice_required 才打开最小实现切片
|
||||
-> 不再因为“继续”自动创造新阶段
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. 分阶段合理性判断
|
||||
|
||||
| 阶段 | 判断 | 保留理由 | 优化要求 |
|
||||
| --- | --- | --- | --- |
|
||||
| P0 | 合理 | 影子接入是最低风险融合方式 | 必须保持只读，不影响主链 |
|
||||
| P1 | 合理 | 让 council 进入 decision packet / runtime 解释层 | 只增强解释和 operator 可见性，不改执行门 |
|
||||
| P2 | 合理 | lesson / eval / arena 是持续改进的基础 | 只能用于研究评估和 bounded follow-up |
|
||||
| P3 | 合理 | 把 P2 长期运行态固化为可持久化 cycle | cycle 输出只能进入 operator follow-up |
|
||||
| P4 | 合理 | 把 cycle 转为治理判断，避免盲目继续开发 | `needs_attention` 不能被解释成交易信号 |
|
||||
| P5 | 合理但特殊 | P5 是由 P4 指出的具体 replay evidence 缺口触发 | 未来类似缺口应作为 P6 bounded slice，不再固定扩阶段 |
|
||||
| P6 | 合理且应作为终端入口 | governance tick 解决“继续时该做什么”的自动判断问题 | P6 后默认停止扩阶段，转入自动化执行层开发 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 必须优化的流程点
|
||||
|
||||
### 4.1 P6 之后不再自动扩阶段
|
||||
|
||||
之前 P0-P5 的模式容易让“继续”自然变成 P7、P8。
|
||||
|
||||
优化后：
|
||||
|
||||
- P6 是当前 Research Council 融合主线的终端治理入口
|
||||
- P6 返回 `no_op_healthy` 时，自动化流程必须停止开新切片
|
||||
- 只有 P6 返回 `cycle_required` 或 `bounded_slice_required`，才允许继续执行
|
||||
- analysis/decision monitor 已达到稳定质量窗口时，可进入自动化执行层 P7，用于成熟度摘要与下一 bounded slice 路由
|
||||
|
||||
### 4.2 P4 到 P5 必须是条件跳转
|
||||
|
||||
P5 不应被理解为所有情况下 P4 后的固定阶段。
|
||||
|
||||
只有当 P4 review 返回：
|
||||
|
||||
```text
|
||||
recommended_actions includes add_replay_fixture_with_confirmed_swings
|
||||
```
|
||||
|
||||
才进入 P5。
|
||||
|
||||
如果 P4 已经 healthy，应直接进入 P6 governance tick。
|
||||
|
||||
### 4.3 P5 以后同类缺口不再扩新阶段
|
||||
|
||||
P5 是一次已经发生的具体缺口闭环，不应形成“每个缺口一个永久阶段”的模式。
|
||||
|
||||
以后如果 P6 tick 返回 `bounded_slice_required`：
|
||||
|
||||
- 在当前自动化执行层内打开最小 bounded slice
|
||||
- 完成后回到 P6 tick
|
||||
- 不新增 Research Council P7/P8 文档，除非用户明确要求重新规划产品阶段
|
||||
|
||||
### 4.4 状态机必须统一
|
||||
|
||||
P6 后默认自动化状态机：
|
||||
|
||||
| Tick status | 自动动作 | 是否写代码 |
|
||||
| --- | --- | --- |
|
||||
| `no_op_healthy` | 停止，记录健康 | 否 |
|
||||
| `cycle_required` | 按策略补跑 optimization cycle | 仅当明确授权 |
|
||||
| `bounded_slice_required` | 打开最小实现切片 | 是 |
|
||||
| `cycle_run` | 写回 cycle / review 结果 | 否，除非新 review 要求 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 正式进入自动化流程开发阶段的条件
|
||||
|
||||
满足以下条件后，可以进入自动化流程开发阶段：
|
||||
|
||||
1. `SESSION.md` 状态已写为 `automation_flow_p0_p6_review_closed`
|
||||
2. `TASKS.md` 已明确下一步是自动化执行层开发
|
||||
3. P6 governance tick 可作为默认入口
|
||||
4. latest tick 为 `no_op_healthy`
|
||||
5. P0-P6 文档不再继续扩阶段
|
||||
6. `npm run lint` 或至少文档一致性相关测试通过
|
||||
|
||||
---
|
||||
|
||||
## 6. 审查结论
|
||||
|
||||
P0-P6 不需要重写。
|
||||
|
||||
需要并已纳入流程的优化是：
|
||||
|
||||
1. 增加 P0-P6 审查结论文档
|
||||
2. 明确 P6 为终端治理入口
|
||||
3. 明确 P4->P5 是条件跳转
|
||||
4. 明确 P6 后不自动扩 P7
|
||||
5. 明确下一步进入自动化执行层开发，而不是继续写阶段清单
|
||||
|
||||
最终判定：
|
||||
|
||||
```text
|
||||
P0-P6 合理
|
||||
P0-P6 阶段冻结
|
||||
可以进入自动化流程开发阶段
|
||||
```
|
||||
@@ -0,0 +1,295 @@
|
||||
# AI_ICT + TradingAgents P0 自动任务清单 v1
|
||||
|
||||
## 1. 文档目标
|
||||
|
||||
本清单用于驱动 `Research Council P0` 的自动推进。
|
||||
|
||||
P0 定位：
|
||||
|
||||
> 影子接入，不影响现有决策，只读消费 AI_ICT 事实，结果先进入 `review packet`。
|
||||
|
||||
本清单是执行单，不是设计稿。
|
||||
|
||||
---
|
||||
|
||||
## 2. 启动条件
|
||||
|
||||
只有满足以下条件，自动化流程才应切入本清单：
|
||||
|
||||
1. 当前 AI_ICT 主骨架无新增主链 blocker
|
||||
2. 当前阶段已被标记为 `Research Council P0`
|
||||
3. 已读取：
|
||||
- `AI_ICT_TradingAgents融合实施方案_最终版.md`
|
||||
- `AI_ICT_全自动开发执行流程_v1.md`
|
||||
- `AI_ICT_research_council脚手架与数据表草案_v1.md`
|
||||
|
||||
---
|
||||
|
||||
## 3. 默认执行顺序
|
||||
|
||||
## P0-1 脚手架与导出入口
|
||||
|
||||
### 目标
|
||||
|
||||
创建 `src/services/research_council/` 基础目录和统一导出入口。
|
||||
|
||||
### 主要文件
|
||||
|
||||
- `src/services/research_council/__init__.py`
|
||||
- `src/services/research_council/council_schema.py`
|
||||
- `src/services/research_council/council_output_formatter.py`
|
||||
|
||||
### 完成标志
|
||||
|
||||
- 目录结构存在
|
||||
- 包可被 import
|
||||
- 不影响现有主链
|
||||
|
||||
### 默认验证
|
||||
|
||||
- focused import smoke
|
||||
- 新增 unit test: `tests/unit/test_research_council_imports.py`
|
||||
|
||||
---
|
||||
|
||||
## P0-2 context builder
|
||||
|
||||
### 目标
|
||||
|
||||
完成 `council_context_builder`，只读拼装 AI_ICT 已有事实。
|
||||
|
||||
### 主要文件
|
||||
|
||||
- `src/services/research_council/council_context_builder.py`
|
||||
- `src/services/decision/decision_packet_service.py`
|
||||
- `src/services/operator/operator_workspace_service.py`
|
||||
|
||||
### 输入源要求
|
||||
|
||||
- `market_state`
|
||||
- `latest_trading_plan`
|
||||
- `latest_candidate`
|
||||
- `latest_signal`
|
||||
- `risk_result`
|
||||
- `trust_policy`
|
||||
- `recent_alerts`
|
||||
- `recent_journal_entries`
|
||||
- `weekly_review_summary`
|
||||
|
||||
### 完成标志
|
||||
|
||||
- builder 只消费现有服务输出
|
||||
- 不创建第二套事实层
|
||||
|
||||
### 默认验证
|
||||
|
||||
- focused unit test: `tests/unit/test_research_council_context_builder.py`
|
||||
|
||||
---
|
||||
|
||||
## P0-3 结构化输出契约
|
||||
|
||||
### 目标
|
||||
|
||||
定义 P0 可用的最小 `CouncilDecision` 结构与 formatter。
|
||||
|
||||
### 主要文件
|
||||
|
||||
- `src/services/research_council/council_schema.py`
|
||||
- `src/services/research_council/council_output_formatter.py`
|
||||
|
||||
### P0 必含字段
|
||||
|
||||
- `research_summary`
|
||||
- `operator_summary`
|
||||
- `bull_case`
|
||||
- `bear_case`
|
||||
- `net_assessment`
|
||||
- `committee_confidence`
|
||||
- `source_snapshot_meta`
|
||||
|
||||
### 完成标志
|
||||
|
||||
- formatter 输出稳定
|
||||
- review packet 可直接消费
|
||||
|
||||
### 默认验证
|
||||
|
||||
- focused unit test: `tests/unit/test_research_council_schema.py`
|
||||
|
||||
---
|
||||
|
||||
## P0-4 structure / risk analysts
|
||||
|
||||
### 目标
|
||||
|
||||
先接入最必要的两个 analyst：
|
||||
|
||||
- `structure_analyst`
|
||||
- `risk_analyst`
|
||||
|
||||
### 主要文件
|
||||
|
||||
- `src/services/research_council/agents/structure_analyst.py`
|
||||
- `src/services/research_council/agents/risk_analyst.py`
|
||||
- `src/services/research_council/tradingagents_adapter.py`
|
||||
|
||||
### 完成标志
|
||||
|
||||
- analyst 只基于 context builder 输入工作
|
||||
- 不直接调用外部股票研究数据源
|
||||
|
||||
### 默认验证
|
||||
|
||||
- focused unit test: `tests/unit/test_research_council_analysts.py`
|
||||
|
||||
---
|
||||
|
||||
## P0-5 bull / bear / manager
|
||||
|
||||
### 目标
|
||||
|
||||
接入最小对抗论证链路：
|
||||
|
||||
- `bull_researcher`
|
||||
- `bear_researcher`
|
||||
- `research_manager`
|
||||
|
||||
### 主要文件
|
||||
|
||||
- `src/services/research_council/agents/bull_researcher.py`
|
||||
- `src/services/research_council/agents/bear_researcher.py`
|
||||
- `src/services/research_council/agents/research_manager.py`
|
||||
- `src/services/research_council/debate_service.py`
|
||||
- `src/services/research_council/council_orchestrator.py`
|
||||
|
||||
### 完成标志
|
||||
|
||||
- 能生成正反论据和最终摘要
|
||||
- 结论只作为解释层，不改写主裁决
|
||||
|
||||
### 默认验证
|
||||
|
||||
- focused unit test: `tests/unit/test_research_council_orchestrator.py`
|
||||
|
||||
---
|
||||
|
||||
## P0-6 持久化主表与链接表
|
||||
|
||||
### 目标
|
||||
|
||||
落最小持久化，不一开始就把全部历史回流做满。
|
||||
|
||||
### 建议先做的表
|
||||
|
||||
- `research_council_runs`
|
||||
- `research_council_messages`
|
||||
- `research_council_links`
|
||||
|
||||
### 主要文件
|
||||
|
||||
- `migrations/036_create_research_council_runs.sql`
|
||||
- `migrations/037_create_research_council_messages.sql`
|
||||
- `migrations/038_create_research_council_links.sql`
|
||||
- 对应 repository 文件
|
||||
|
||||
### 完成标志
|
||||
|
||||
- 一次 council run 可持久化
|
||||
- 能和 `decision_packet_id / candidate_id / signal_id` 关联
|
||||
|
||||
### 默认验证
|
||||
|
||||
- migration static checks
|
||||
- focused repository tests
|
||||
|
||||
---
|
||||
|
||||
## P0-7 手动 API / script 入口
|
||||
|
||||
### 目标
|
||||
|
||||
提供手动触发入口，先不进入 runtime 自动任务。
|
||||
|
||||
### 建议新增
|
||||
|
||||
- `scripts/run_research_council.py`
|
||||
- `GET /trading/research-council/latest`
|
||||
- `GET /trading/research-council/runs`
|
||||
- `POST /trading/research-council/run`
|
||||
|
||||
### 主要文件
|
||||
|
||||
- `scripts/run_research_council.py`
|
||||
- `src/api/server.py`
|
||||
|
||||
### 完成标志
|
||||
|
||||
- 手动 API / script 稳定可跑
|
||||
- 没有 council 时系统主行为不变
|
||||
|
||||
### 默认验证
|
||||
|
||||
- focused API unit test
|
||||
- script smoke
|
||||
|
||||
---
|
||||
|
||||
## P0-8 review packet 只读展示
|
||||
|
||||
### 目标
|
||||
|
||||
把 council 摘要先接入 `review packet`，不进 `decision packet`。
|
||||
|
||||
### 主要文件
|
||||
|
||||
- `src/services/operator/operator_workspace_service.py`
|
||||
- `scripts/run_review_packet.py`
|
||||
- `src/web/app.js`
|
||||
|
||||
### 完成标志
|
||||
|
||||
- `review packet` 能显示 council 摘要
|
||||
- council 缺席时不回归
|
||||
|
||||
### 默认验证
|
||||
|
||||
- focused review packet unit test
|
||||
- API smoke: `/trading/review-packet`
|
||||
- browser smoke
|
||||
|
||||
---
|
||||
|
||||
## 4. P0 阶段出口判断
|
||||
|
||||
P0 做完后必须回到晋级门，不是直接进入 P1。
|
||||
|
||||
只有以下全部成立，才允许自动切到 P1：
|
||||
|
||||
1. 手动 API / script 稳定
|
||||
2. council 缺席时主系统不回归
|
||||
3. council 存在时 `review packet` 展示正常
|
||||
4. council 失败时 runtime 可自动降级
|
||||
5. 连续 smoke 无新增主链 blocker
|
||||
|
||||
否则状态应写为：
|
||||
|
||||
- `P0 部分完成`
|
||||
- `P0 待收尾`
|
||||
- `P0 环境阻塞`
|
||||
|
||||
---
|
||||
|
||||
## 5. P0 默认验证串
|
||||
|
||||
建议默认验证顺序：
|
||||
|
||||
1. focused unit tests
|
||||
2. `tests/unit`
|
||||
3. `scripts/run_offline_checks.py`
|
||||
4. `scripts/run_research_council.py`
|
||||
5. `scripts/run_review_packet.py`
|
||||
6. API smoke
|
||||
7. browser smoke
|
||||
|
||||
如果改动未进入 runtime 主链，可不强制远端 deploy，但必须在状态中说明。
|
||||
@@ -0,0 +1,252 @@
|
||||
# AI_ICT + TradingAgents P1 自动任务清单 v1
|
||||
|
||||
## 1. 文档目标
|
||||
|
||||
本清单用于驱动 `Research Council P1` 的自动推进。
|
||||
|
||||
P1 定位：
|
||||
|
||||
> 受控进入 `decision_packet` 与 `runtime`，增强 operator / workbench 的解释质量，但不替代风控和 trust。
|
||||
|
||||
---
|
||||
|
||||
## 2. 启动条件
|
||||
|
||||
只有满足以下条件，自动化流程才应切入本清单：
|
||||
|
||||
1. `P0` 晋级门已通过
|
||||
2. 当前阶段已被标记为 `Research Council P1`
|
||||
3. P0 相关回归已清零
|
||||
|
||||
---
|
||||
|
||||
## 3. 默认执行顺序
|
||||
|
||||
## P1-1 runtime 任务接入
|
||||
|
||||
### 目标
|
||||
|
||||
把 `research_council` 作为受控任务接入 runtime。
|
||||
|
||||
### 主要文件
|
||||
|
||||
- `src/services/runtime/trading_runtime_service.py`
|
||||
- `src/services/research_council/council_orchestrator.py`
|
||||
|
||||
### 完成标志
|
||||
|
||||
- 任务顺序固定在 `watch -> research_council -> decision_packet`
|
||||
- 失败自动降级，不阻塞主链
|
||||
|
||||
### 默认验证
|
||||
|
||||
- `tests/unit/test_trading_runtime_service.py`
|
||||
- 新增: `tests/unit/test_research_council_runtime_integration.py`
|
||||
|
||||
---
|
||||
|
||||
## P1-2 decision packet 字段扩展
|
||||
|
||||
### 目标
|
||||
|
||||
把 council 解释字段正式接入 `DecisionPacket`。
|
||||
|
||||
### 主要文件
|
||||
|
||||
- `src/services/decision/decision_packet_service.py`
|
||||
|
||||
### 目标字段
|
||||
|
||||
- `research_summary`
|
||||
- `committee_confidence`
|
||||
- `agreement_points`
|
||||
- `disagreement_points`
|
||||
- `follow_up_checks`
|
||||
- `recommended_watch_items`
|
||||
- `operator_questions`
|
||||
|
||||
### 完成标志
|
||||
|
||||
- packet 主裁决仍由原逻辑决定
|
||||
- council 只增强解释
|
||||
|
||||
### 默认验证
|
||||
|
||||
- `tests/unit/test_decision_packet_service.py`
|
||||
- 新增: `tests/unit/test_research_council_decision_packet_fields.py`
|
||||
|
||||
---
|
||||
|
||||
## P1-3 news_event_analyst
|
||||
|
||||
### 目标
|
||||
|
||||
增加环境解释层。
|
||||
|
||||
### 主要文件
|
||||
|
||||
- `src/services/research_council/agents/news_event_analyst.py`
|
||||
- `src/services/market_state/news_event_provider.py`
|
||||
|
||||
### 完成标志
|
||||
|
||||
- 只解释 AI_ICT 已有 news/event 结果
|
||||
- 不自行建立第二套事实源
|
||||
|
||||
### 默认验证
|
||||
|
||||
- focused unit test
|
||||
|
||||
---
|
||||
|
||||
## P1-4 visual_analyst
|
||||
|
||||
### 目标
|
||||
|
||||
吸收 visual review 结果，增强解释与 follow-up checks。
|
||||
|
||||
### 主要文件
|
||||
|
||||
- `src/services/research_council/agents/visual_analyst.py`
|
||||
- `src/services/visual_watch/visual_watch_service.py`
|
||||
|
||||
### 完成标志
|
||||
|
||||
- visual 结果只作为补充确认和风险提示
|
||||
- 不单独作为执行许可来源
|
||||
|
||||
### 默认验证
|
||||
|
||||
- focused unit test
|
||||
|
||||
---
|
||||
|
||||
## P1-5 disagreement / follow-up checks
|
||||
|
||||
### 目标
|
||||
|
||||
把分歧点和补充检查项结构化输出。
|
||||
|
||||
### 主要文件
|
||||
|
||||
- `src/services/research_council/debate_service.py`
|
||||
- `src/services/research_council/council_schema.py`
|
||||
|
||||
### 完成标志
|
||||
|
||||
- bull / bear / manager 输出可汇总成统一分歧结构
|
||||
|
||||
### 默认验证
|
||||
|
||||
- orchestrator / formatter focused tests
|
||||
|
||||
---
|
||||
|
||||
## P1-6 visual watch 建议联动
|
||||
|
||||
### 目标
|
||||
|
||||
让 council 输出建议的 watch 项，但不越过执行边界。
|
||||
|
||||
### 主要文件
|
||||
|
||||
- `src/services/visual_watch/visual_trigger_policy_service.py`
|
||||
- `src/services/decision/decision_packet_service.py`
|
||||
|
||||
### 完成标志
|
||||
|
||||
- `recommended_watch_items` 可进入 visual watch
|
||||
- 不改变 `execution_allowed`
|
||||
|
||||
### 默认验证
|
||||
|
||||
- visual watch focused tests
|
||||
|
||||
---
|
||||
|
||||
## P1-7 workbench 展示增强
|
||||
|
||||
### 目标
|
||||
|
||||
把 council 解释层真正呈现在 operator workbench 上。
|
||||
|
||||
### 主要文件
|
||||
|
||||
- `src/web/app.js`
|
||||
- `src/web/index.html`
|
||||
|
||||
### 展示目标
|
||||
|
||||
- 支持理由
|
||||
- 反对理由
|
||||
- 分歧点
|
||||
- follow-up checks
|
||||
- committee confidence
|
||||
|
||||
### 完成标志
|
||||
|
||||
- operator 能直接读到增强解释
|
||||
- 不引入第二套页面
|
||||
|
||||
### 默认验证
|
||||
|
||||
- `npm run lint`
|
||||
- `npm run build`
|
||||
- `npm run visual:snapshots`
|
||||
- browser smoke
|
||||
|
||||
---
|
||||
|
||||
## P1-8 checkpoint / resume
|
||||
|
||||
### 目标
|
||||
|
||||
给 council 长链路增加恢复能力。
|
||||
|
||||
### 主要文件
|
||||
|
||||
- `src/services/research_council/council_checkpoint_service.py`
|
||||
- 相关 migration / repository
|
||||
|
||||
### 完成标志
|
||||
|
||||
- council 运行中断后可恢复
|
||||
- 不影响主链稳定性
|
||||
|
||||
### 默认验证
|
||||
|
||||
- focused unit test
|
||||
- script smoke
|
||||
|
||||
---
|
||||
|
||||
## 4. P1 阶段出口判断
|
||||
|
||||
只有以下全部成立，才允许自动切入 P2：
|
||||
|
||||
1. `decision_packet` 已稳定吸收 council 字段
|
||||
2. runtime 已受控接入 council 任务
|
||||
3. workbench 已稳定展示支持 / 反对 / 分歧 / follow-up checks
|
||||
4. visual watch 已能消费 council 建议
|
||||
5. 未造成执行边界回归
|
||||
|
||||
否则状态应写为：
|
||||
|
||||
- `P1 部分完成`
|
||||
- `P1 待收尾`
|
||||
- `P1 环境阻塞`
|
||||
|
||||
---
|
||||
|
||||
## 5. P1 默认验证串
|
||||
|
||||
建议默认验证顺序：
|
||||
|
||||
1. focused unit tests
|
||||
2. `tests/unit`
|
||||
3. `scripts/run_offline_checks.py`
|
||||
4. `scripts/run_research_council.py`
|
||||
5. `scripts/run_decision_packet.py`
|
||||
6. `scripts/run_trading_runtime.py`
|
||||
7. browser smoke
|
||||
8. 必要时远端 deploy + smoke
|
||||
@@ -0,0 +1,179 @@
|
||||
# AI_ICT + TradingAgents P2 自动任务清单 v1
|
||||
|
||||
## 1. 文档目标
|
||||
|
||||
本清单用于驱动 `Research Council P2` 的自动推进。
|
||||
|
||||
P2 定位：
|
||||
|
||||
> 经验回流、评估闭环、研究竞技场，并进入长期运行与优化模式。
|
||||
|
||||
---
|
||||
|
||||
## 2. 启动条件
|
||||
|
||||
只有满足以下条件，自动化流程才应切入本清单：
|
||||
|
||||
1. `P1` 晋级门已通过
|
||||
2. 当前阶段已被标记为 `Research Council P2`
|
||||
3. P1 展示层和 runtime 接入已稳定
|
||||
|
||||
---
|
||||
|
||||
## 3. 默认执行顺序
|
||||
|
||||
## P2-1 lessons schema 与持久化
|
||||
|
||||
### 目标
|
||||
|
||||
建立 lesson store。
|
||||
|
||||
### 主要文件
|
||||
|
||||
- `migrations/039_create_research_council_lessons.sql`
|
||||
- `src/services/research_council/council_memory_service.py`
|
||||
|
||||
### 完成标志
|
||||
|
||||
- 可持久化 lesson
|
||||
- 可按 symbol / session / setup_type 检索
|
||||
|
||||
---
|
||||
|
||||
## P2-2 backfill lessons
|
||||
|
||||
### 目标
|
||||
|
||||
把现有 `journal / weekly review / replay / trust` 回填成可用经验。
|
||||
|
||||
### 主要文件
|
||||
|
||||
- `scripts/run_research_council_backfill_lessons.py`
|
||||
- `src/services/journal/*`
|
||||
- `src/services/trust/*`
|
||||
|
||||
### 完成标志
|
||||
|
||||
- 历史记录可转成结构化 lesson
|
||||
- backfill 可重复执行
|
||||
|
||||
---
|
||||
|
||||
## P2-3 similarity / memory retrieval
|
||||
|
||||
### 目标
|
||||
|
||||
让 council 在分析时能够读取相近历史经验。
|
||||
|
||||
### 主要文件
|
||||
|
||||
- `src/services/research_council/council_memory_service.py`
|
||||
- `src/services/research_council/council_context_builder.py`
|
||||
|
||||
### 完成标志
|
||||
|
||||
- context builder 可注入 compact lessons
|
||||
- 不挤占主事实层
|
||||
|
||||
---
|
||||
|
||||
## P2-4 checkpoint / resume 稳定化
|
||||
|
||||
### 目标
|
||||
|
||||
把 council checkpoint 从“存在”推进到“长期稳定可用”。
|
||||
|
||||
### 主要文件
|
||||
|
||||
- `src/services/research_council/council_checkpoint_service.py`
|
||||
- `scripts/run_research_council_replay.py`
|
||||
|
||||
### 完成标志
|
||||
|
||||
- 中断恢复稳定
|
||||
- replay 可用于调试与评估
|
||||
|
||||
---
|
||||
|
||||
## P2-5 评估脚本
|
||||
|
||||
### 目标
|
||||
|
||||
建立 council 与非 council 的效果比较。
|
||||
|
||||
### 建议输出维度
|
||||
|
||||
- operator 决策质量 proxy
|
||||
- follow-up checks 命中率
|
||||
- disagreement 提示有效性
|
||||
- session / setup 适配性
|
||||
|
||||
### 主要文件
|
||||
|
||||
- `scripts/run_research_council_eval.py`
|
||||
- `src/services/research_council/` 评估辅助模块
|
||||
|
||||
### 完成标志
|
||||
|
||||
- 能周期性生成比较结果
|
||||
|
||||
---
|
||||
|
||||
## P2-6 内部研究竞技场
|
||||
|
||||
### 目标
|
||||
|
||||
建立内部 council 组合 / setup / model 对比框架。
|
||||
|
||||
### 范围限制
|
||||
|
||||
只用于内部：
|
||||
|
||||
- model 赛马
|
||||
- setup 对比
|
||||
- council 组合实验
|
||||
|
||||
不用于：
|
||||
|
||||
- 外部平台化
|
||||
- follower/copy trade
|
||||
- rewards
|
||||
|
||||
### 完成标志
|
||||
|
||||
- 可服务长期迭代
|
||||
|
||||
---
|
||||
|
||||
## 4. P2 阶段出口判断
|
||||
|
||||
P2 不是“做完就停”，而是进入长期运行态。
|
||||
|
||||
只有以下条件成立，才应把状态写为 `P2 进入长期运行态`：
|
||||
|
||||
1. lesson backfill 稳定
|
||||
2. checkpoint / resume 稳定
|
||||
3. 评估脚本稳定
|
||||
4. 内部竞技场可支撑后续迭代
|
||||
|
||||
进入长期运行态后的默认动作：
|
||||
|
||||
```text
|
||||
持续评估
|
||||
-> 识别 council 薄弱点
|
||||
-> 回到 P2 内部优化
|
||||
-> 必要时回流修正 P1 展示层或 P0 契约层
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. P2 默认验证串
|
||||
|
||||
建议默认验证顺序：
|
||||
|
||||
1. focused unit tests
|
||||
2. `tests/unit`
|
||||
3. `scripts/run_research_council_backfill_lessons.py`
|
||||
4. `scripts/run_research_council_replay.py`
|
||||
5. `scripts/run_research_council_eval.py`
|
||||
6. 必要时 review packet / workbench smoke
|
||||
@@ -0,0 +1,161 @@
|
||||
# AI_ICT + TradingAgents P3 自动任务清单 v1
|
||||
|
||||
## 1. 文档目标
|
||||
|
||||
本清单用于驱动 `Research Council P3` 的自动化闭环。
|
||||
|
||||
P3 定位：
|
||||
|
||||
> 把 P2 的 `lessons -> replay -> eval -> arena` 长期运行能力，固化成可重复执行、可持久化、可查询、可回写状态的优化循环。
|
||||
|
||||
P3 不是新的执行权限阶段，也不是放开真实自动下单。它只负责让研究委员会进入稳定的长期优化模式。
|
||||
|
||||
---
|
||||
|
||||
## 2. 启动条件
|
||||
|
||||
只有满足以下条件，自动化流程才应进入 P3：
|
||||
|
||||
1. `Research Council P2` 已进入长期运行态
|
||||
2. lesson backfill 可重复执行
|
||||
3. replay / eval / arena 工具均能独立跑通
|
||||
4. runtime / decision packet / workbench 边界未被研究层越权
|
||||
5. 远端 deploy / smoke 最近一次可通过，或环境阻塞已被明确记录
|
||||
|
||||
---
|
||||
|
||||
## 3. 默认执行顺序
|
||||
|
||||
### P3-1 optimization cycle schema 与 repository
|
||||
|
||||
目标：
|
||||
|
||||
建立优化循环的持久化记录。
|
||||
|
||||
主要文件：
|
||||
|
||||
- `migrations/041_create_research_council_optimization_cycles.sql`
|
||||
- `src/repositories/research_council_optimization_repository.py`
|
||||
|
||||
完成标志：
|
||||
|
||||
- 每轮优化循环有唯一 `cycle_key`
|
||||
- 可记录 lesson / replay / eval / arena summary
|
||||
- 可查询 latest / recent cycles
|
||||
|
||||
---
|
||||
|
||||
### P3-2 CouncilOptimizationService
|
||||
|
||||
目标：
|
||||
|
||||
把 P2 的分散工具串成一个稳定的优化循环：
|
||||
|
||||
```text
|
||||
backfill lessons
|
||||
-> build fresh council run
|
||||
-> replay summary
|
||||
-> eval summary
|
||||
-> arena summary
|
||||
-> choose next bounded actions
|
||||
-> persist optimization cycle
|
||||
```
|
||||
|
||||
主要文件：
|
||||
|
||||
- `src/services/research_council/council_optimization_service.py`
|
||||
- `src/services/research_council/__init__.py`
|
||||
|
||||
完成标志：
|
||||
|
||||
- 一次调用能完成完整 cycle
|
||||
- 失败不改变 execution gate / live readiness / risk governor
|
||||
- 输出只作为 operator follow-up 与下一轮优化建议
|
||||
|
||||
---
|
||||
|
||||
### P3-3 CLI / API 入口
|
||||
|
||||
目标：
|
||||
|
||||
提供可自动化触发与可查询的入口。
|
||||
|
||||
主要文件：
|
||||
|
||||
- `scripts/run_research_council_optimization_loop.py`
|
||||
- `scripts/deploy_with_password.py`
|
||||
- `src/api/research_council.py`
|
||||
- `src/api/server.py`
|
||||
|
||||
建议接口：
|
||||
|
||||
- `POST /trading/research-council/optimization-cycle`
|
||||
- `GET /trading/research-council/optimization-cycle/latest`
|
||||
- `GET /trading/research-council/optimization-cycles`
|
||||
|
||||
完成标志：
|
||||
|
||||
- CLI 能输出 JSON
|
||||
- API 能手动触发一轮 cycle
|
||||
- latest / recent 查询可用于 smoke 和状态面板
|
||||
- password-based remote deploy / smoke 不再依赖本机 `expect`
|
||||
|
||||
---
|
||||
|
||||
### P3-4 状态锚点与自动化回写
|
||||
|
||||
目标：
|
||||
|
||||
让 P3 完成后不是停住，而是进入长期优化运行态。
|
||||
|
||||
主要文件：
|
||||
|
||||
- `SESSION.md`
|
||||
- `TASKS.md`
|
||||
- `docs/AI_ICT_全自动开发执行流程_v1.md`
|
||||
|
||||
完成标志：
|
||||
|
||||
- `SESSION.md` 写明当前进入 `Research Council P3 long-running optimization loop`
|
||||
- `TASKS.md` 记录 P3 已形成闭环
|
||||
- 下一步明确为周期性运行 optimization cycle，而不是进入执行权限扩张
|
||||
|
||||
---
|
||||
|
||||
## 4. 阶段出口
|
||||
|
||||
只有同时满足以下条件，P3 才可视为完成闭环：
|
||||
|
||||
1. optimization cycle 表和 repository 已落地
|
||||
2. `CouncilOptimizationService.run_cycle(...)` 可稳定执行
|
||||
3. CLI / API 均可触发或查询 cycle
|
||||
4. focused unit tests 通过
|
||||
5. migration static checks 通过
|
||||
6. 本地质量门通过
|
||||
7. 必要时完成 deploy / smoke，或明确记录外部环境阻塞
|
||||
|
||||
完成后状态应写为：
|
||||
|
||||
```text
|
||||
state: research_council_p3_optimization_loop_closed
|
||||
current_phase: Research Council P3 Long-Running Optimization Loop
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. 边界守卫
|
||||
|
||||
P3 不允许做以下事情：
|
||||
|
||||
1. 不允许改变 `execution_allowed`
|
||||
2. 不允许改变 `real_live_ready`
|
||||
3. 不允许让 arena 结果直接替换默认模型
|
||||
4. 不允许让 eval 结果自动升级 trust bucket
|
||||
5. 不允许引入 copy trading / follower economy / rewards
|
||||
|
||||
P3 的输出只允许进入：
|
||||
|
||||
- operator follow-up
|
||||
- 下一轮 research council 优化建议
|
||||
- eval / arena 对比报告
|
||||
- 长期运行状态锚点
|
||||
@@ -0,0 +1,145 @@
|
||||
# AI_ICT + TradingAgents P4 自动任务清单 v1
|
||||
|
||||
## 1. 文档目标
|
||||
|
||||
本清单用于驱动 `Research Council P4` 的自动化闭环。
|
||||
|
||||
P4 定位：
|
||||
|
||||
> 把 P3 的 optimization cycle 结果转成 operator 可读的治理判断：是否 stale、是否需要更多样本、是否出现退化、是否可以开启 bounded optimization slice。
|
||||
|
||||
P4 不负责自动修改模型、信任分层、执行权限或真实交易边界。
|
||||
|
||||
---
|
||||
|
||||
## 2. 启动条件
|
||||
|
||||
只有满足以下条件，自动化流程才应进入 P4：
|
||||
|
||||
1. `Research Council P3` 已完成 optimization-loop 闭环
|
||||
2. `research_council_optimization_cycles` 已有可查询记录
|
||||
3. P3 latest / recent API 可用
|
||||
4. 远端 deploy / smoke 路径可用，或已明确环境阻塞
|
||||
|
||||
---
|
||||
|
||||
## 3. 默认执行顺序
|
||||
|
||||
### P4-1 optimization review service
|
||||
|
||||
目标：
|
||||
|
||||
读取最近若干轮 optimization cycle，生成治理判断。
|
||||
|
||||
主要文件：
|
||||
|
||||
- `src/services/research_council/council_optimization_review_service.py`
|
||||
|
||||
完成标志：
|
||||
|
||||
- 可判断 `missing / stale / needs_more_samples / needs_attention / healthy`
|
||||
- 可计算 latest metrics 与相邻 cycle delta
|
||||
- 可输出 operator summary 与 bounded recommended actions
|
||||
|
||||
---
|
||||
|
||||
### P4-2 CLI 入口
|
||||
|
||||
目标：
|
||||
|
||||
提供自动化可运行的 review smoke 入口。
|
||||
|
||||
主要文件：
|
||||
|
||||
- `scripts/run_research_council_optimization_review.py`
|
||||
|
||||
完成标志：
|
||||
|
||||
- 支持 JSON 输出
|
||||
- 无 cycle 时返回明确 `missing`
|
||||
- 有 cycle 时返回 review payload
|
||||
|
||||
---
|
||||
|
||||
### P4-3 API 与 review packet 可见性
|
||||
|
||||
目标：
|
||||
|
||||
让 operator/workbench 可以看到 P4 治理结果。
|
||||
|
||||
主要文件：
|
||||
|
||||
- `src/api/research_council.py`
|
||||
- `src/api/server.py`
|
||||
- `src/services/operator/operator_workspace_service.py`
|
||||
- `src/web/app.js`
|
||||
|
||||
建议接口：
|
||||
|
||||
- `GET /trading/research-council/optimization-review`
|
||||
|
||||
完成标志：
|
||||
|
||||
- API 能返回 optimization review
|
||||
- review packet 包含 `research_council_optimization_review`
|
||||
- workbench operator console 显示 optimization health / summary / next actions
|
||||
|
||||
---
|
||||
|
||||
### P4-4 状态锚点与远端验证
|
||||
|
||||
目标：
|
||||
|
||||
完成本地与远端闭环。
|
||||
|
||||
主要文件：
|
||||
|
||||
- `SESSION.md`
|
||||
- `TASKS.md`
|
||||
|
||||
完成标志：
|
||||
|
||||
- focused tests 通过
|
||||
- `npm run lint / build / visual:snapshots` 通过
|
||||
- 数据库注入脚本 smoke 通过
|
||||
- 本地 API smoke 通过
|
||||
- 远端 deploy / smoke 通过
|
||||
- 状态写为 `research_council_p4_optimization_review_closed`
|
||||
|
||||
---
|
||||
|
||||
## 4. 阶段出口
|
||||
|
||||
只有同时满足以下条件，P4 才可视为完成闭环：
|
||||
|
||||
1. optimization review service 已落地
|
||||
2. CLI / API / review packet / workbench 均可消费 review
|
||||
3. review 能明确区分 stale、样本不足、需要关注、健康
|
||||
4. review 只输出 operator follow-up，不自动改变模型或执行权限
|
||||
5. 本地和远端验证完成，或外部环境阻塞被明确记录
|
||||
|
||||
完成后状态应写为：
|
||||
|
||||
```text
|
||||
state: research_council_p4_optimization_review_closed
|
||||
current_phase: Research Council P4 Optimization Review Governance
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. 边界守卫
|
||||
|
||||
P4 不允许做以下事情：
|
||||
|
||||
1. 不允许自动切换默认模型
|
||||
2. 不允许自动升级或降级 trust bucket
|
||||
3. 不允许改变 `execution_allowed`
|
||||
4. 不允许改变 `real_live_ready`
|
||||
5. 不允许把 `needs_attention` 直接解释成可交易信号
|
||||
|
||||
P4 的输出只允许进入：
|
||||
|
||||
- operator summary
|
||||
- review packet
|
||||
- workbench optimization health
|
||||
- 下一轮 bounded optimization slice 建议
|
||||
@@ -0,0 +1,140 @@
|
||||
# AI_ICT + TradingAgents P5 自动任务清单 v1
|
||||
|
||||
## 1. 文档目标
|
||||
|
||||
本清单用于驱动 `Research Council P5` 的自动化闭环。
|
||||
|
||||
P5 定位：
|
||||
|
||||
> 把 P4 review 输出的 `add_replay_fixture_with_confirmed_swings` 从 operator 建议变成可重复执行、可部署、可审计的 replay 证据链。
|
||||
|
||||
P5 不负责改变交易执行权限、模型信任分层、真实交易就绪状态或 operator confirmation protocol。
|
||||
|
||||
---
|
||||
|
||||
## 2. 启动条件
|
||||
|
||||
只有满足以下条件，自动化流程才应进入 P5：
|
||||
|
||||
1. `Research Council P4` 已完成 optimization review governance 闭环
|
||||
2. P4 review 返回 `health_state=needs_attention`
|
||||
3. P4 review 的 `recommended_actions` 包含 `add_replay_fixture_with_confirmed_swings`
|
||||
4. optimization loop / review CLI 与 API 路径可运行
|
||||
|
||||
---
|
||||
|
||||
## 3. 默认执行顺序
|
||||
|
||||
### P5-1 confirmed swing replay fixture
|
||||
|
||||
目标：
|
||||
提供一份可部署的 replay 数据，默认 `left_bars=2/right_bars=2` 下能确认 swing high 与 swing low。
|
||||
|
||||
主要文件：
|
||||
|
||||
- `data/replay/research_council_confirmed_swings_v1.jsonl`
|
||||
|
||||
完成标志：
|
||||
|
||||
- replay 文件通过 candle integrity gate
|
||||
- `run_replay_file.py` 在 `REPLAY_MIN_CANDLES=9`、`REPLAY_MIN_SWINGS=2`、`REPLAY_MAX_GAP_MINUTES=1` 下通过
|
||||
- 默认窗口可检测到 2 个 confirmed swings
|
||||
|
||||
---
|
||||
|
||||
### P5-2 optimization replay summary evidence
|
||||
|
||||
目标：
|
||||
让 optimization cycle 的 `replay_summary` 不只输出计数，还能输出可审计的 swing 细节。
|
||||
|
||||
主要文件：
|
||||
|
||||
- `src/services/research_council/council_optimization_service.py`
|
||||
|
||||
完成标志：
|
||||
|
||||
- `replay_summary.confirmed_swing_count >= 2`
|
||||
- `replay_summary.swing_counts` 包含 `swing_high` 与 `swing_low`
|
||||
- `replay_summary.confirmed_swings` 包含 `source_index`、`confirmed_at_index`、`left_bars`、`right_bars`
|
||||
- `choose_next_actions` 不再输出 `add_replay_fixture_with_confirmed_swings`
|
||||
|
||||
---
|
||||
|
||||
### P5-3 optimization loop and review rerun
|
||||
|
||||
目标：
|
||||
用 P5 replay fixture 跑出新一轮 optimization cycle，并让 P4 review 看到缺口已关闭。
|
||||
|
||||
默认命令：
|
||||
|
||||
```bash
|
||||
DATABASE_URL='<configured database url>' \
|
||||
RESEARCH_COUNCIL_OUTPUT_JSON=1 \
|
||||
RESEARCH_COUNCIL_OPTIMIZATION_CYCLE_KEY='research_council_opt:p5_confirmed_swings_20260511' \
|
||||
RESEARCH_COUNCIL_REPLAY_FILE='D:/ai-exchange/data/replay/research_council_confirmed_swings_v1.jsonl' \
|
||||
D:/ai-exchange/.venv/Scripts/python.exe D:/ai-exchange/scripts/run_research_council_optimization_loop.py
|
||||
```
|
||||
|
||||
完成标志：
|
||||
|
||||
- latest cycle 的 `replay_summary.confirmed_swing_gate_passed=true`
|
||||
- latest cycle 的 `next_actions` 不包含 `add_replay_fixture_with_confirmed_swings`
|
||||
- `run_research_council_optimization_review.py` 返回 `health_state=healthy` 或只剩样本量相关状态
|
||||
|
||||
---
|
||||
|
||||
### P5-4 deploy and remote smoke
|
||||
|
||||
目标：
|
||||
确保远端系统也拥有同一份 replay 证据，并且远端 API 能跑出/读取 P5 cycle。
|
||||
|
||||
主要文件：
|
||||
|
||||
- `Dockerfile`
|
||||
- `scripts/deploy_with_password.py`
|
||||
|
||||
完成标志：
|
||||
|
||||
- Docker 镜像包含 `/app/data/replay/research_council_confirmed_swings_v1.jsonl`
|
||||
- 远端 deploy / smoke 通过
|
||||
- 远端 `POST /trading/research-council/optimization-cycle` 可使用 P5 replay 文件
|
||||
- 远端 `GET /trading/research-council/optimization-review` 返回不再包含 `add_replay_fixture_with_confirmed_swings`
|
||||
|
||||
---
|
||||
|
||||
## 4. 阶段出口
|
||||
|
||||
只有同时满足以下条件，P5 才可视为完成闭环：
|
||||
|
||||
1. confirmed swing replay fixture 已落地并通过质量门
|
||||
2. optimization replay summary 已包含 swing evidence
|
||||
3. 新 cycle 已消除 `add_replay_fixture_with_confirmed_swings`
|
||||
4. review / review packet / workbench 可读取 P5 后的状态
|
||||
5. 本地与远端验证完成，或外部环境阻塞被明确记录
|
||||
|
||||
完成后状态应写为：
|
||||
|
||||
```text
|
||||
state: research_council_p5_confirmed_swing_replay_closed
|
||||
current_phase: Research Council P5 Confirmed Swing Replay Evidence
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. 边界守卫
|
||||
|
||||
P5 不允许做以下事情：
|
||||
|
||||
1. 不允许把 replay fixture 结果解释为真实可交易信号
|
||||
2. 不允许修改 `execution_allowed`
|
||||
3. 不允许修改 `real_live_ready`
|
||||
4. 不允许自动升级或降级 trust bucket
|
||||
5. 不允许绕过 operator confirmation protocol
|
||||
|
||||
P5 的输出只允许进入：
|
||||
|
||||
- replay evidence
|
||||
- optimization cycle payload
|
||||
- optimization review
|
||||
- review packet / workbench
|
||||
- 下一轮 bounded optimization 建议
|
||||
@@ -0,0 +1,137 @@
|
||||
# AI_ICT + TradingAgents P6 自动任务清单 v1
|
||||
|
||||
## 1. 文档目标
|
||||
|
||||
本清单用于驱动 `Research Council P6` 的自动化闭环。
|
||||
|
||||
P6 定位：
|
||||
|
||||
> 在 P5 已恢复 healthy review 后，提供一个可调度的 governance tick，让自动化流程能判断当前应 no-op、补跑 optimization cycle，还是打开 bounded slice。
|
||||
|
||||
P6 不新增交易能力，不改变 execution gate、live readiness、risk governor、trust bucket 或 operator confirmation protocol。
|
||||
|
||||
---
|
||||
|
||||
## 2. 启动条件
|
||||
|
||||
只有满足以下条件，自动化流程才应进入 P6：
|
||||
|
||||
1. `Research Council P5` 已完成 confirmed-swing replay evidence 闭环
|
||||
2. latest optimization review 为 `healthy`
|
||||
3. `recommended_actions` 为 `continue_periodic_optimization_cycle`
|
||||
4. `can_open_bounded_slice=false`
|
||||
|
||||
---
|
||||
|
||||
## 3. 默认执行顺序
|
||||
|
||||
### P6-1 governance tick service
|
||||
|
||||
目标：
|
||||
把 optimization review 的状态转成自动化可消费的 tick status。
|
||||
|
||||
主要文件：
|
||||
|
||||
- `src/services/research_council/council_governance_tick_service.py`
|
||||
|
||||
完成标志：
|
||||
|
||||
- `healthy` -> `no_op_healthy`
|
||||
- `stale/missing` -> `cycle_required`
|
||||
- `needs_attention` -> `bounded_slice_required`
|
||||
- 只有显式开启 `auto_run_stale_cycle` 或 `force_cycle` 才补跑 optimization cycle
|
||||
|
||||
---
|
||||
|
||||
### P6-2 CLI 入口
|
||||
|
||||
目标：
|
||||
提供可被计划任务、远端 cron 或人工 smoke 调用的入口。
|
||||
|
||||
主要文件：
|
||||
|
||||
- `scripts/run_research_council_governance_tick.py`
|
||||
|
||||
完成标志：
|
||||
|
||||
- 支持 JSON 输出
|
||||
- 支持 review 参数
|
||||
- 支持受控 cycle 参数
|
||||
- 默认 healthy 时只输出 no-op，不写交易状态
|
||||
|
||||
---
|
||||
|
||||
### P6-3 API 入口
|
||||
|
||||
目标：
|
||||
让远端服务可通过 HTTP 执行 governance tick。
|
||||
|
||||
主要文件：
|
||||
|
||||
- `src/api/research_council.py`
|
||||
- `src/api/server.py`
|
||||
|
||||
接口：
|
||||
|
||||
- `POST /trading/research-council/governance-tick`
|
||||
|
||||
完成标志：
|
||||
|
||||
- healthy tick 返回 `status=no_op_healthy`
|
||||
- tick 输出 `safe_to_auto_continue`
|
||||
- tick 输出 `requires_cycle_run`
|
||||
- tick 输出 `requires_bounded_slice`
|
||||
|
||||
---
|
||||
|
||||
### P6-4 状态锚点与远端验证
|
||||
|
||||
目标：
|
||||
完成本地与远端闭环。
|
||||
|
||||
完成标志：
|
||||
|
||||
- focused tests 通过
|
||||
- `npm run lint / build / visual:snapshots` 通过
|
||||
- 本地 CLI smoke 通过
|
||||
- 本地 API smoke 通过
|
||||
- 远端 deploy / smoke 通过
|
||||
- 远端 governance tick 返回 `no_op_healthy`
|
||||
|
||||
---
|
||||
|
||||
## 4. 阶段出口
|
||||
|
||||
只有同时满足以下条件，P6 才可视为完成闭环：
|
||||
|
||||
1. governance tick 能稳定读取 optimization review
|
||||
2. healthy 状态不会触发无意义写操作
|
||||
3. needs_attention 状态只返回 bounded action，不自动越权修复
|
||||
4. stale/missing 状态只有显式授权才补跑 cycle
|
||||
5. 本地与远端验证完成，或外部环境阻塞被明确记录
|
||||
|
||||
完成后状态应写为：
|
||||
|
||||
```text
|
||||
state: research_council_p6_governance_tick_closed
|
||||
current_phase: Research Council P6 Governance Tick
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. 边界守卫
|
||||
|
||||
P6 不允许做以下事情：
|
||||
|
||||
1. 不允许把 governance tick 结果解释为真实可交易信号
|
||||
2. 不允许修改 `execution_allowed`
|
||||
3. 不允许修改 `real_live_ready`
|
||||
4. 不允许自动升级或降级 trust bucket
|
||||
5. 不允许绕过 operator confirmation protocol
|
||||
|
||||
P6 的输出只允许进入：
|
||||
|
||||
- automation status
|
||||
- operator summary
|
||||
- optimization governance logs
|
||||
- 下一轮 bounded optimization 建议
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,244 @@
|
||||
# AI ICT repair bridge protocol v1
|
||||
|
||||
## 1. 目标
|
||||
|
||||
本文档定义 `scripts/run_monitoring_alert_rollout.py` 中 `repair-bridge` 模式与外部修复代理之间的 JSON 输入输出协议。
|
||||
|
||||
目标：
|
||||
|
||||
- 让自动化 orchestrator 能把当前失败阶段的上下文结构化发送给外部修复代理
|
||||
- 让外部修复代理用稳定 JSON 返回修复结果
|
||||
- 让 orchestrator 根据返回值决定是否自动复验、是否允许阶段推进
|
||||
|
||||
---
|
||||
|
||||
## 2. 协议版本
|
||||
|
||||
当前协议版本：
|
||||
|
||||
```text
|
||||
repair-bridge/v1
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. stdin JSON 输入协议
|
||||
|
||||
外部修复代理从 stdin 读取 JSON。
|
||||
|
||||
### 必填字段
|
||||
|
||||
- `protocol_version`
|
||||
- `mode`
|
||||
- `phase`
|
||||
- `phase_title`
|
||||
- `failure_class`
|
||||
- `recommended_focus`
|
||||
- `phase_patch_targets`
|
||||
- `validation_entrypoint`
|
||||
- `repair_prompt_context`
|
||||
|
||||
### 示例
|
||||
|
||||
```json
|
||||
{
|
||||
"protocol_version": "repair-bridge/v1",
|
||||
"mode": "repair_loop",
|
||||
"phase": "N2",
|
||||
"phase_title": "最小主动消息告警闭环",
|
||||
"failure_class": "alert_dispatch_gap",
|
||||
"recommended_focus": "alert_delivery_and_dispatch",
|
||||
"phase_patch_targets": [
|
||||
"src/services/alerts/alert_dispatcher_service.py",
|
||||
"src/services/runtime/trading_runtime_service.py"
|
||||
],
|
||||
"validation_entrypoint": ".venv/bin/python scripts/run_alert_dispatcher.py",
|
||||
"repair_prompt_context": {
|
||||
"prompt_text": "...",
|
||||
"phase_tasks": ["..."],
|
||||
"phase_files": ["..."],
|
||||
"suggested_files": ["..."],
|
||||
"suggested_commands": ["..."]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. stdout JSON 输出协议
|
||||
|
||||
外部修复代理必须向 stdout 输出一段 JSON。
|
||||
|
||||
### 必填字段
|
||||
|
||||
- `status`
|
||||
- `summary`
|
||||
- `changed_files`
|
||||
|
||||
### 可选字段
|
||||
|
||||
- `protocol_version`
|
||||
- `notes`
|
||||
- `success_guess`
|
||||
- `tests_run`
|
||||
|
||||
### 字段说明
|
||||
|
||||
#### `status`
|
||||
建议值：
|
||||
|
||||
- `applied`
|
||||
- `success`
|
||||
- `fixed`
|
||||
- `blocked`
|
||||
- `noop`
|
||||
- `failed`
|
||||
|
||||
当前 orchestrator 认为下面这些值可以进入自动复验候选：
|
||||
|
||||
- `applied`
|
||||
- `success`
|
||||
- `fixed`
|
||||
|
||||
#### `summary`
|
||||
一句简短摘要，说明修复做了什么。
|
||||
|
||||
#### `changed_files`
|
||||
数组，列出本轮修复实际修改的文件路径。
|
||||
|
||||
#### `success_guess`
|
||||
布尔值。
|
||||
|
||||
- `true` 表示修复代理认为可以尝试复验
|
||||
- `false` 表示修复代理认为还不适合复验
|
||||
|
||||
#### `tests_run`
|
||||
数组，列出修复代理已经主动执行过的 focused tests / scripts。
|
||||
|
||||
orchestrator 会把它作为智能复验调度输入。
|
||||
|
||||
### 示例
|
||||
|
||||
```json
|
||||
{
|
||||
"protocol_version": "repair-bridge/v1",
|
||||
"status": "applied",
|
||||
"summary": "Implemented missing alert dispatcher module and updated runtime hook.",
|
||||
"changed_files": [
|
||||
"src/services/alerts/alert_dispatcher_service.py",
|
||||
"src/services/runtime/trading_runtime_service.py"
|
||||
],
|
||||
"notes": [
|
||||
"Focused on N2 alert delivery gap"
|
||||
],
|
||||
"success_guess": true,
|
||||
"tests_run": [
|
||||
".venv/bin/python scripts/run_alert_dispatcher.py"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. orchestrator 当前决策逻辑
|
||||
|
||||
## 5.1 自动复验条件
|
||||
|
||||
只有满足以下条件，脚本才会自动复验：
|
||||
|
||||
1. `MONITORING_ALERT_AUTO_RERUN_ENABLED=1`
|
||||
2. bridge output JSON 可解析
|
||||
3. bridge output schema 合法
|
||||
4. `status in {applied, success, fixed}`
|
||||
5. `success_guess != false`
|
||||
6. `changed_files` 非空
|
||||
|
||||
---
|
||||
|
||||
## 5.2 智能复验调度
|
||||
|
||||
当前策略：
|
||||
|
||||
### 优先级 1：如果有 `tests_run`
|
||||
直接优先执行 `tests_run` 中列出的命令，作为 focused rerun。
|
||||
|
||||
### 优先级 2：如果没有 `tests_run`
|
||||
根据 `changed_files` 做命令映射：
|
||||
|
||||
- 改动 `src/services/alerts/` 或 `src/api/alerts.py`
|
||||
- 运行 `scripts/run_alert_dispatcher.py`
|
||||
- 改动 `src/services/runtime/` 或 `src/api/trading_runtime.py`
|
||||
- 运行 `scripts/run_trading_runtime.py`
|
||||
- 改动 `src/services/readiness/` / `src/web/` / `src/config/settings.py`
|
||||
- 运行 `scripts/run_launch_readiness.py`
|
||||
- 改动 `src/services/decision/` / `src/services/operator/`
|
||||
- 运行 `scripts/run_review_packet.py`
|
||||
- 如果全部改动只在 `docs/`
|
||||
- 跳过 focused rerun，直接进入全阶段判断
|
||||
|
||||
之后仍会回到 `run-until-blocked` 做阶段级判断。
|
||||
|
||||
---
|
||||
|
||||
## 5.3 自动推进条件
|
||||
|
||||
修复后复验完成后，如果 rerun 结果状态为：
|
||||
|
||||
- `running`
|
||||
- `completed`
|
||||
|
||||
则当前阶段可视为已推进成功。
|
||||
|
||||
否则进入：
|
||||
|
||||
```text
|
||||
inspect_rerun_result
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. 推荐外部修复代理实现要求
|
||||
|
||||
建议外部 repair agent 至少做到：
|
||||
|
||||
1. 从 stdin 读取完整 JSON
|
||||
2. 解析 `phase_patch_targets` 和 `repair_prompt_context`
|
||||
3. 明确输出 `changed_files`
|
||||
4. 给出 `success_guess`
|
||||
5. 若已主动运行 focused checks，则把命令写入 `tests_run`
|
||||
6. 始终输出合法 JSON 到 stdout，不要混入额外日志
|
||||
|
||||
如果需要日志，建议输出到 stderr。
|
||||
|
||||
---
|
||||
|
||||
## 7. 当前脚本内相关模式
|
||||
|
||||
- `run-until-blocked`
|
||||
- `repair-loop`
|
||||
- `repair-bridge`
|
||||
|
||||
推荐顺序：
|
||||
|
||||
```text
|
||||
run-until-blocked
|
||||
-> repair-loop
|
||||
-> repair-bridge
|
||||
-> auto rerun
|
||||
-> phase advance / inspect_rerun_result
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8. 后续可扩展项
|
||||
|
||||
后续协议可以考虑补充：
|
||||
|
||||
- `applied_patches`
|
||||
- `skipped_files`
|
||||
- `risk_notes`
|
||||
- `confidence_score`
|
||||
- `requires_human_review`
|
||||
- `suggested_next_tests`
|
||||
|
||||
这些字段当前不是必需，但适合 `repair-bridge/v2`。
|
||||
@@ -0,0 +1,279 @@
|
||||
# AI_ICT research_council 脚手架与数据表草案 v1
|
||||
|
||||
## 1. 文档目标
|
||||
|
||||
本草案用于明确：
|
||||
|
||||
1. `research_council` 目录结构应如何搭建
|
||||
2. 每个模块的职责边界是什么
|
||||
3. 数据表与 migration 初稿应如何命名
|
||||
4. 如何避免和现有 AI_ICT 主链冲突
|
||||
|
||||
---
|
||||
|
||||
## 2. 目录脚手架建议
|
||||
|
||||
```text
|
||||
src/services/research_council/
|
||||
├── __init__.py
|
||||
├── council_context_builder.py
|
||||
├── council_orchestrator.py
|
||||
├── council_schema.py
|
||||
├── council_output_formatter.py
|
||||
├── council_mapper_service.py
|
||||
├── council_memory_service.py
|
||||
├── council_checkpoint_service.py
|
||||
├── tradingagents_adapter.py
|
||||
├── debate_service.py
|
||||
└── agents/
|
||||
├── structure_analyst.py
|
||||
├── risk_analyst.py
|
||||
├── news_event_analyst.py
|
||||
├── visual_analyst.py
|
||||
├── bull_researcher.py
|
||||
├── bear_researcher.py
|
||||
└── research_manager.py
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. 模块职责
|
||||
|
||||
## 3.1 `council_context_builder.py`
|
||||
|
||||
职责：
|
||||
|
||||
- 读取 AI_ICT 已有结构化事实
|
||||
- 生成 council 输入上下文
|
||||
|
||||
必须只读消费：
|
||||
|
||||
- `market_state`
|
||||
- `trading_plan`
|
||||
- `candidate`
|
||||
- `signal`
|
||||
- `risk_result`
|
||||
- `trust_policy`
|
||||
- `visual_review`
|
||||
- `operator_notes`
|
||||
- `journal / weekly review`
|
||||
|
||||
禁止：
|
||||
|
||||
- 自己重算 market truth
|
||||
- 自己生成平行 readiness / trust
|
||||
|
||||
## 3.2 `tradingagents_adapter.py`
|
||||
|
||||
职责：
|
||||
|
||||
- 适配 TradingAgents 的编排、结构化输出、checkpoint/memory 思路
|
||||
- 屏蔽掉不适用的股票数据入口
|
||||
|
||||
禁止：
|
||||
|
||||
- 直接暴露 `yfinance / alpha_vantage` 作为主事实源
|
||||
|
||||
## 3.3 `debate_service.py`
|
||||
|
||||
职责：
|
||||
|
||||
- 统一整理支持 / 反对理由
|
||||
- 生成分歧点与 follow-up checks
|
||||
|
||||
## 3.4 `council_mapper_service.py`
|
||||
|
||||
职责：
|
||||
|
||||
- 将 council 结果映射到：
|
||||
- `decision_packet`
|
||||
- `review_packet`
|
||||
- `workbench`
|
||||
- `visual_watch` 建议项
|
||||
|
||||
## 3.5 `council_memory_service.py`
|
||||
|
||||
职责：
|
||||
|
||||
- 读写 lesson store
|
||||
- 读取相似历史经验
|
||||
- 回填历史复盘数据
|
||||
|
||||
## 3.6 `council_checkpoint_service.py`
|
||||
|
||||
职责：
|
||||
|
||||
- 管理 council 运行中断恢复
|
||||
- 提供 replay / resume 支撑
|
||||
|
||||
---
|
||||
|
||||
## 4. 数据表草案
|
||||
|
||||
## 4.1 `research_council_runs`
|
||||
|
||||
建议 migration：
|
||||
|
||||
- `036_create_research_council_runs.sql`
|
||||
|
||||
建议字段：
|
||||
|
||||
- `id`
|
||||
- `instrument_id`
|
||||
- `trading_plan_id`
|
||||
- `candidate_id`
|
||||
- `signal_id`
|
||||
- `decision_packet_id`
|
||||
- `status`
|
||||
- `committee_confidence`
|
||||
- `summary_text`
|
||||
- `payload_json`
|
||||
- `created_ts`
|
||||
- `updated_ts`
|
||||
|
||||
用途：
|
||||
|
||||
- 记录一次 council 运行的总结果
|
||||
|
||||
## 4.2 `research_council_messages`
|
||||
|
||||
建议 migration：
|
||||
|
||||
- `037_create_research_council_messages.sql`
|
||||
|
||||
建议字段：
|
||||
|
||||
- `id`
|
||||
- `run_id`
|
||||
- `agent_role`
|
||||
- `message_type`
|
||||
- `payload_json`
|
||||
- `created_ts`
|
||||
|
||||
用途：
|
||||
|
||||
- 记录各角色输出
|
||||
|
||||
## 4.3 `research_council_links`
|
||||
|
||||
建议 migration：
|
||||
|
||||
- `038_create_research_council_links.sql`
|
||||
|
||||
建议字段：
|
||||
|
||||
- `id`
|
||||
- `run_id`
|
||||
- `trading_plan_id`
|
||||
- `candidate_id`
|
||||
- `signal_id`
|
||||
- `decision_packet_id`
|
||||
- `execution_ticket_id`
|
||||
- `created_ts`
|
||||
|
||||
用途：
|
||||
|
||||
- 连接 council run 与主链对象
|
||||
|
||||
## 4.4 `research_council_lessons`
|
||||
|
||||
建议 migration：
|
||||
|
||||
- `039_create_research_council_lessons.sql`
|
||||
|
||||
建议字段：
|
||||
|
||||
- `id`
|
||||
- `instrument_id`
|
||||
- `session_code`
|
||||
- `setup_type`
|
||||
- `lesson_type`
|
||||
- `importance_score`
|
||||
- `summary_text`
|
||||
- `source_type`
|
||||
- `source_ref`
|
||||
- `payload_json`
|
||||
- `created_ts`
|
||||
|
||||
用途：
|
||||
|
||||
- 持久化结构化经验
|
||||
|
||||
## 4.5 `research_council_checkpoints`
|
||||
|
||||
建议 migration：
|
||||
|
||||
- `040_create_research_council_checkpoints.sql`
|
||||
|
||||
建议字段：
|
||||
|
||||
- `id`
|
||||
- `run_id`
|
||||
- `step_name`
|
||||
- `checkpoint_payload`
|
||||
- `status`
|
||||
- `updated_ts`
|
||||
|
||||
用途：
|
||||
|
||||
- 管理中断恢复
|
||||
|
||||
---
|
||||
|
||||
## 5. repository 草案
|
||||
|
||||
建议新增：
|
||||
|
||||
- `src/repositories/research_council_run_repository.py`
|
||||
- `src/repositories/research_council_message_repository.py`
|
||||
- `src/repositories/research_council_link_repository.py`
|
||||
- `src/repositories/research_council_lesson_repository.py`
|
||||
- `src/repositories/research_council_checkpoint_repository.py`
|
||||
|
||||
---
|
||||
|
||||
## 6. 脚本草案
|
||||
|
||||
建议新增：
|
||||
|
||||
- `scripts/run_research_council.py`
|
||||
- `scripts/run_research_council_replay.py`
|
||||
- `scripts/run_research_council_backfill_lessons.py`
|
||||
- `scripts/run_research_council_eval.py`
|
||||
|
||||
---
|
||||
|
||||
## 7. 测试草案
|
||||
|
||||
建议新增：
|
||||
|
||||
- `tests/unit/test_research_council_imports.py`
|
||||
- `tests/unit/test_research_council_context_builder.py`
|
||||
- `tests/unit/test_research_council_schema.py`
|
||||
- `tests/unit/test_research_council_analysts.py`
|
||||
- `tests/unit/test_research_council_orchestrator.py`
|
||||
- `tests/unit/test_research_council_runtime_integration.py`
|
||||
- `tests/unit/test_research_council_decision_packet_fields.py`
|
||||
|
||||
---
|
||||
|
||||
## 8. 边界守卫
|
||||
|
||||
以下规则必须在脚手架阶段就固定：
|
||||
|
||||
1. council 不重写主事实层
|
||||
2. council 不重写 `risk_result`
|
||||
3. council 不重写 `execution_allowed`
|
||||
4. council 不替代 `DecisionPacketService` 主裁决
|
||||
5. council 不引入第二套 readiness / trust
|
||||
|
||||
---
|
||||
|
||||
## 9. 推荐落地顺序
|
||||
|
||||
1. 先落目录与 schema
|
||||
2. 再落 context builder
|
||||
3. 再落最小 analysts / orchestrator
|
||||
4. 再落 runs / messages / links 三张表
|
||||
5. 再落 lessons / checkpoints
|
||||
6. 最后接入 runtime / packet / workbench
|
||||
@@ -0,0 +1,521 @@
|
||||
# AI ICT 外部 repair agent 接入说明 v1
|
||||
|
||||
## 1. 文档目标
|
||||
|
||||
本文档用于说明：
|
||||
|
||||
> 如果你想编写一个外部 repair agent，并通过 `scripts/run_monitoring_alert_rollout.py` 的 `repair-bridge` 模式接入当前自动化流程，应该如何实现。
|
||||
|
||||
本文档面向：
|
||||
|
||||
- 你自己写的 Python 修复脚本
|
||||
- 其他 AI 代理包装器
|
||||
- Codex / Claude / 其他模型的桥接程序
|
||||
- 后续可能扩展出来的自动修复子进程
|
||||
|
||||
---
|
||||
|
||||
## 2. repair agent 的职责
|
||||
|
||||
外部 repair agent 的职责不是管理整个流程，而是专注完成这一步：
|
||||
|
||||
```text
|
||||
接收失败阶段上下文
|
||||
-> 分析应该修什么
|
||||
-> 修改代码
|
||||
-> 可选地执行少量 focused tests
|
||||
-> 返回结构化 JSON 结果
|
||||
```
|
||||
|
||||
也就是说：
|
||||
|
||||
- **主 orchestrator** 负责：阶段推进、状态管理、复验、phase advance
|
||||
- **外部 repair agent** 负责：拿到上下文之后，尽量完成本轮修复
|
||||
|
||||
---
|
||||
|
||||
## 3. 调用方式
|
||||
|
||||
当前主脚本通过环境变量指定外部 repair agent 命令，例如：
|
||||
|
||||
```bash
|
||||
MONITORING_ALERT_AUTO_REPAIR_ENABLED=1 \
|
||||
MONITORING_ALERT_REPAIR_BRIDGE_COMMAND="python your_repair_agent.py" \
|
||||
MONITORING_ALERT_ROLLOUT_MODE=repair-bridge \
|
||||
.venv/bin/python scripts/run_monitoring_alert_rollout.py
|
||||
```
|
||||
|
||||
主脚本会：
|
||||
|
||||
1. 生成 bridge input JSON
|
||||
2. 通过 **stdin** 传给 `your_repair_agent.py`
|
||||
3. 从 **stdout** 读取 repair result JSON
|
||||
4. 解析结果并决定是否自动复验
|
||||
|
||||
---
|
||||
|
||||
## 4. stdin 输入协议
|
||||
|
||||
repair agent 必须从 stdin 读取 JSON。
|
||||
|
||||
当前协议版本：
|
||||
|
||||
```text
|
||||
repair-bridge/v1
|
||||
```
|
||||
|
||||
### 必填字段
|
||||
|
||||
- `protocol_version`
|
||||
- `mode`
|
||||
- `phase`
|
||||
- `phase_title`
|
||||
- `failure_class`
|
||||
- `recommended_focus`
|
||||
- `phase_patch_targets`
|
||||
- `validation_entrypoint`
|
||||
- `repair_prompt_context`
|
||||
|
||||
### 示例
|
||||
|
||||
```json
|
||||
{
|
||||
"protocol_version": "repair-bridge/v1",
|
||||
"mode": "repair_loop",
|
||||
"phase": "N2",
|
||||
"phase_title": "最小主动消息告警闭环",
|
||||
"failure_class": "alert_dispatch_gap",
|
||||
"recommended_focus": "alert_delivery_and_dispatch",
|
||||
"phase_patch_targets": [
|
||||
"src/services/alerts/alert_dispatcher_service.py",
|
||||
"src/services/runtime/trading_runtime_service.py"
|
||||
],
|
||||
"validation_entrypoint": ".venv/bin/python scripts/run_alert_dispatcher.py",
|
||||
"repair_prompt_context": {
|
||||
"prompt_text": "...",
|
||||
"phase_tasks": ["..."],
|
||||
"phase_files": ["..."],
|
||||
"suggested_files": ["..."],
|
||||
"suggested_commands": ["..."]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5. 你应该如何使用输入字段
|
||||
|
||||
## 5.1 `phase`
|
||||
表示当前处在哪个开发阶段。
|
||||
|
||||
比如：
|
||||
|
||||
- `N1`
|
||||
- `N2`
|
||||
- `N3`
|
||||
- `N4`
|
||||
|
||||
你可以用它决定修复策略范围。
|
||||
|
||||
---
|
||||
|
||||
## 5.2 `failure_class`
|
||||
这是 orchestrator 归纳后的失败类型。
|
||||
|
||||
常见值：
|
||||
|
||||
- `missing_dependency_or_import`
|
||||
- `missing_file_or_artifact`
|
||||
- `validation_failure`
|
||||
- `missing_implementation`
|
||||
- `readiness_gap`
|
||||
- `alert_dispatch_gap`
|
||||
- `runtime_gap`
|
||||
- `decision_packet_gap`
|
||||
- `blocker:<something>`
|
||||
|
||||
用途：
|
||||
|
||||
- 帮你先快速判断本轮修复重点
|
||||
- 降低 repair agent 自己重新归类的成本
|
||||
|
||||
---
|
||||
|
||||
## 5.3 `recommended_focus`
|
||||
这是主脚本给 repair agent 的聚焦建议。
|
||||
|
||||
例如：
|
||||
|
||||
- `readiness_and_boundary_hardening`
|
||||
- `alert_delivery_and_dispatch`
|
||||
- `runtime_scheduler_and_status`
|
||||
- `decision_packet_and_operator_view`
|
||||
|
||||
建议：
|
||||
|
||||
- 优先服从这个 focus
|
||||
- 避免本轮修到无关模块
|
||||
|
||||
---
|
||||
|
||||
## 5.4 `phase_patch_targets`
|
||||
这是当前最值得优先看的文件列表。
|
||||
|
||||
建议：
|
||||
|
||||
- 先读这些文件
|
||||
- 只在必要时扩展到其它文件
|
||||
|
||||
这有助于控制修复范围。
|
||||
|
||||
---
|
||||
|
||||
## 5.5 `validation_entrypoint`
|
||||
这是本轮首个失败命令或者最重要的验证入口。
|
||||
|
||||
例如：
|
||||
|
||||
```text
|
||||
.venv/bin/python scripts/run_alert_dispatcher.py
|
||||
```
|
||||
|
||||
建议：
|
||||
|
||||
- 修完后优先自己尝试跑这个命令
|
||||
- 如果你已经跑了，把命令写到 `tests_run`
|
||||
|
||||
---
|
||||
|
||||
## 5.6 `repair_prompt_context`
|
||||
这里面通常包含最完整的上下文：
|
||||
|
||||
- `prompt_text`
|
||||
- `phase_tasks`
|
||||
- `phase_files`
|
||||
- `suggested_files`
|
||||
- `suggested_commands`
|
||||
- `reasoning`
|
||||
|
||||
如果你只想用一段“人类可读修复提示”，优先用：
|
||||
|
||||
```text
|
||||
repair_prompt_context.prompt_text
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. stdout 输出协议
|
||||
|
||||
repair agent 必须向 stdout 输出 **一段合法 JSON**。
|
||||
|
||||
### 当前必填字段
|
||||
|
||||
- `status`
|
||||
- `summary`
|
||||
- `changed_files`
|
||||
|
||||
### 可选字段
|
||||
|
||||
- `protocol_version`
|
||||
- `notes`
|
||||
- `success_guess`
|
||||
- `tests_run`
|
||||
|
||||
---
|
||||
|
||||
## 7. 每个输出字段该怎么写
|
||||
|
||||
## 7.1 `status`
|
||||
建议值：
|
||||
|
||||
- `applied`
|
||||
- `success`
|
||||
- `fixed`
|
||||
- `failed`
|
||||
- `blocked`
|
||||
- `noop`
|
||||
|
||||
当前 orchestrator 认为这些值可以进入自动复验候选：
|
||||
|
||||
- `applied`
|
||||
- `success`
|
||||
- `fixed`
|
||||
|
||||
如果你根本没改代码，不要写 `applied`。
|
||||
|
||||
---
|
||||
|
||||
## 7.2 `summary`
|
||||
一句简短总结。
|
||||
|
||||
好的写法：
|
||||
|
||||
- `Implemented missing alert dispatcher module and updated runtime hook.`
|
||||
- `Fixed readiness panel payload mismatch and aligned API fields.`
|
||||
|
||||
不好的写法：
|
||||
|
||||
- `done`
|
||||
- `fixed stuff`
|
||||
|
||||
---
|
||||
|
||||
## 7.3 `changed_files`
|
||||
必须是数组，列出本轮真正改动的文件路径。
|
||||
|
||||
例如：
|
||||
|
||||
```json
|
||||
"changed_files": [
|
||||
"src/services/alerts/alert_dispatcher_service.py",
|
||||
"src/services/runtime/trading_runtime_service.py"
|
||||
]
|
||||
```
|
||||
|
||||
非常重要：
|
||||
|
||||
- 如果你没改任何文件，不要伪造
|
||||
- 如果只改 docs，也应如实返回 docs 文件
|
||||
- 这个字段会影响 orchestrator 后续智能复验选择
|
||||
|
||||
---
|
||||
|
||||
## 7.4 `success_guess`
|
||||
布尔值。
|
||||
|
||||
建议：
|
||||
|
||||
- `true`：你认为这轮修复值得复验
|
||||
- `false`：你知道还没修完，不建议进入自动复验
|
||||
|
||||
如果你不确定，可以不写；但如果明确没修好，最好写 `false`。
|
||||
|
||||
---
|
||||
|
||||
## 7.5 `tests_run`
|
||||
建议写上本轮 repair agent 自己已经执行过的 focused commands。
|
||||
|
||||
例如：
|
||||
|
||||
```json
|
||||
"tests_run": [
|
||||
".venv/bin/python scripts/run_alert_dispatcher.py"
|
||||
]
|
||||
```
|
||||
|
||||
好处：
|
||||
|
||||
- orchestrator 会优先用这些命令做 focused rerun
|
||||
- 复验逻辑更精准
|
||||
|
||||
如果你没跑任何命令，可以不写。
|
||||
|
||||
---
|
||||
|
||||
## 7.6 `notes`
|
||||
可选。可以写本轮修复的一些额外说明。
|
||||
|
||||
例如：
|
||||
|
||||
```json
|
||||
"notes": [
|
||||
"Focused on N2 alert delivery gap",
|
||||
"Did not touch visual-watch code"
|
||||
]
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 8. 一个最小合法输出示例
|
||||
|
||||
```json
|
||||
{
|
||||
"protocol_version": "repair-bridge/v1",
|
||||
"status": "applied",
|
||||
"summary": "Implemented missing alert dispatcher module and updated runtime hook.",
|
||||
"changed_files": [
|
||||
"src/services/alerts/alert_dispatcher_service.py",
|
||||
"src/services/runtime/trading_runtime_service.py"
|
||||
],
|
||||
"success_guess": true,
|
||||
"tests_run": [
|
||||
".venv/bin/python scripts/run_alert_dispatcher.py"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 9. stdout 和 stderr 的规则
|
||||
|
||||
这是最重要的实践规则之一：
|
||||
|
||||
## stdout
|
||||
只能输出最终 JSON。
|
||||
|
||||
不要把这些内容输出到 stdout：
|
||||
|
||||
- 调试日志
|
||||
- print 进度
|
||||
- traceback
|
||||
- 人类说明文字
|
||||
|
||||
否则 orchestrator 会解析失败。
|
||||
|
||||
## stderr
|
||||
所有日志都应写到 stderr。
|
||||
|
||||
包括：
|
||||
|
||||
- 调试日志
|
||||
- 运行步骤
|
||||
- 中间状态
|
||||
- 额外说明
|
||||
|
||||
---
|
||||
|
||||
## 10. 最小 Python repair agent 示例
|
||||
|
||||
下面给一个最小骨架：
|
||||
|
||||
```python
|
||||
import json
|
||||
import sys
|
||||
from pathlib import Path
|
||||
|
||||
|
||||
def main():
|
||||
raw = sys.stdin.read()
|
||||
request = json.loads(raw)
|
||||
|
||||
phase = request.get("phase")
|
||||
patch_targets = request.get("phase_patch_targets") or []
|
||||
context = request.get("repair_prompt_context") or {}
|
||||
|
||||
print(f"[repair-agent] phase={phase}", file=sys.stderr)
|
||||
print(f"[repair-agent] patch_targets={patch_targets}", file=sys.stderr)
|
||||
|
||||
changed_files = []
|
||||
tests_run = []
|
||||
|
||||
# 这里写你自己的修复逻辑
|
||||
# 例如：读取 patch_targets，修改文件，运行一个 focused command
|
||||
|
||||
response = {
|
||||
"protocol_version": "repair-bridge/v1",
|
||||
"status": "applied",
|
||||
"summary": "Applied a placeholder repair.",
|
||||
"changed_files": changed_files,
|
||||
"success_guess": True,
|
||||
"tests_run": tests_run,
|
||||
}
|
||||
|
||||
sys.stdout.write(json.dumps(response, ensure_ascii=False))
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
main()
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 11. 推荐实现步骤
|
||||
|
||||
如果你要做一个真正可用的 repair agent，建议按这个顺序：
|
||||
|
||||
### Step 1
|
||||
先实现：
|
||||
- stdin 读 JSON
|
||||
- stdout 写 JSON
|
||||
- stderr 写日志
|
||||
|
||||
### Step 2
|
||||
只消费：
|
||||
- `phase`
|
||||
- `failure_class`
|
||||
- `phase_patch_targets`
|
||||
- `repair_prompt_context.prompt_text`
|
||||
|
||||
### Step 3
|
||||
修完后正确写：
|
||||
- `changed_files`
|
||||
- `success_guess`
|
||||
- `tests_run`
|
||||
|
||||
### Step 4
|
||||
再逐步加高级能力：
|
||||
- patch target 优先级
|
||||
- 局部测试
|
||||
- 风险边界保护
|
||||
- 多轮修复策略
|
||||
|
||||
---
|
||||
|
||||
## 12. 与 orchestrator 的交互建议
|
||||
|
||||
repair agent 最好遵守这些原则：
|
||||
|
||||
1. **范围尽量小**
|
||||
优先修当前 phase patch targets，不要顺手大改无关模块。
|
||||
|
||||
2. **日志进 stderr**
|
||||
保持 stdout 纯 JSON。
|
||||
|
||||
3. **changed_files 要真实**
|
||||
后续智能复验靠它决定。
|
||||
|
||||
4. **tests_run 要真实**
|
||||
不要写没执行过的命令。
|
||||
|
||||
5. **success_guess 要诚实**
|
||||
没修好就写 `false`，比误导自动复验更好。
|
||||
|
||||
---
|
||||
|
||||
## 13. 当前脚本会如何使用你的返回值
|
||||
|
||||
当前 orchestrator 会消费：
|
||||
|
||||
- `status`
|
||||
- `summary`
|
||||
- `changed_files`
|
||||
- `success_guess`
|
||||
- `tests_run`
|
||||
|
||||
用于决定：
|
||||
|
||||
1. 是否自动复验
|
||||
2. 跑哪些 focused rerun commands
|
||||
3. 是否推进 phase
|
||||
4. patch round 历史记录内容
|
||||
|
||||
---
|
||||
|
||||
## 14. 常见错误
|
||||
|
||||
### 错误 1：stdout 混入日志
|
||||
后果：JSON 解析失败。
|
||||
|
||||
### 错误 2：`changed_files` 不是数组
|
||||
后果：bridge output schema invalid。
|
||||
|
||||
### 错误 3：没改文件却返回 `applied`
|
||||
后果：会触发不必要复验，污染历史。
|
||||
|
||||
### 错误 4：已经知道没修好还写 `success_guess: true`
|
||||
后果：会误导自动复验逻辑。
|
||||
|
||||
### 错误 5：运行了 focused tests 却不写 `tests_run`
|
||||
后果：orchestrator 无法利用你的执行信息做更精准复验。
|
||||
|
||||
---
|
||||
|
||||
## 15. 总结
|
||||
|
||||
如果你要做兼容当前自动化流程的外部 repair agent，最重要的就是三句话：
|
||||
|
||||
1. **stdin 读 JSON**
|
||||
2. **stdout 只输出 JSON**
|
||||
3. **真实返回 changed_files / success_guess / tests_run**
|
||||
|
||||
做到这一点，就已经可以稳定接入当前的 `repair-bridge` 自动化链路。
|
||||
@@ -0,0 +1,120 @@
|
||||
# AI_ICT 实盘交易分析决策助手未完成需求清单 2026-05-14 v1
|
||||
|
||||
## 1. 对照锚点
|
||||
|
||||
本清单对照以下锚点整理：
|
||||
|
||||
1. `docs/AI_ICT_实盘交易分析决策助手下一阶段开发方案_v1.md`
|
||||
2. `SESSION.md`
|
||||
3. `TASKS.md`
|
||||
|
||||
本文件在 2026-05-14 这一轮已完成代码与文档重新对齐。原先列为“未完成”的 4 类产品化缺口，现已全部闭环实现。
|
||||
|
||||
## 2. 已完成对齐结论
|
||||
|
||||
### 2.1 workflow 产物归档产品化
|
||||
|
||||
已完成：
|
||||
|
||||
- 持久化真实 `Pre-Market / Intraday / Post-Trade` 摘要正文
|
||||
- workflow archive 独立查询能力
|
||||
- workflow archive 浏览与 latest-two compare 能力
|
||||
- workbench 中可直接查看 workflow archive 条目、正文摘要、phase brief compare
|
||||
|
||||
当前实现要点：
|
||||
|
||||
- `decision_assistant_workflow_history.payload` 现在保存 `phase_briefs / workflow_body / next_artifact_prompt`
|
||||
- 新增只读 API：
|
||||
- `GET /trading/workflow-archive`
|
||||
- `GET /trading/workflow-archive/compare`
|
||||
- cockpit `Workflow` 区已支持 archive browse / compare
|
||||
|
||||
### 2.2 个性化提醒完整产品化
|
||||
|
||||
已完成：
|
||||
|
||||
- 后端 profile 列表能力
|
||||
- profile 级别的 digest 偏好保存
|
||||
- importance template 阈值可编辑
|
||||
- profile label / history window / focus candidate 等配置持久化
|
||||
- workbench 内可切换 profile、调整阈值、编辑 template threshold
|
||||
|
||||
当前实现要点：
|
||||
|
||||
- `decision_assistant_preferences.payload` 现承载：
|
||||
- `profile_label`
|
||||
- `history_window_hours`
|
||||
- `importance_templates`
|
||||
- `focus_candidate_id / focus_session_code / focus_model_code`
|
||||
- 新增只读/写入 API：
|
||||
- `GET /trading/alerts/digest-preferences/profiles`
|
||||
- `GET / POST /trading/alerts/digest-preferences`
|
||||
|
||||
### 2.3 摘要历史检索与回看产品化
|
||||
|
||||
已完成：
|
||||
|
||||
- digest archive 独立查询 API
|
||||
- `history kind / digest mode / offset / limit` 查询过滤
|
||||
- digest archive compare 能力
|
||||
- cockpit 内可加载 digest archive、查看 summary body、查看 latest-two compare
|
||||
|
||||
当前实现要点：
|
||||
|
||||
- 新增只读 API：
|
||||
- `GET /trading/alerts/digest-history-archive`
|
||||
- `GET /trading/alerts/digest-history-archive/compare`
|
||||
- `decision_assistant_digest_history.payload` 现保存：
|
||||
- `summary_body`
|
||||
- `reminder_titles`
|
||||
- `high_value_titles`
|
||||
- `importance_template_counts`
|
||||
- `focus_candidate_id`
|
||||
|
||||
### 2.4 统一焦点连续工作区 end-to-end
|
||||
|
||||
已完成：
|
||||
|
||||
- focus 状态服务端持久化
|
||||
- watchlist 点击后写回服务端 focus
|
||||
- replay 学习 rollup 可跟随 focus candidate 的 `session_code / model_code`
|
||||
- notes 视角增加 focus candidate note 统计
|
||||
- digest / focus workspace / watchlist / replay 已共享同一 persisted focus
|
||||
|
||||
当前实现要点：
|
||||
|
||||
- 新增 API：
|
||||
- `GET /trading/assistant-focus`
|
||||
- `POST /trading/assistant-focus`
|
||||
- `focus_workspace_context` 现提供：
|
||||
- `focus_persistence_status`
|
||||
- `focus_profile_label`
|
||||
- `focus_history_window_hours`
|
||||
- `review_entrypoints` 现提供：
|
||||
- `focus_candidate_id`
|
||||
- `focus_note_count`
|
||||
- `focus_latest_note_ts`
|
||||
|
||||
## 3. 当前状态
|
||||
|
||||
截至本轮对齐完成后：
|
||||
|
||||
- 本文件原先列出的 4 类“未完成主需求”已经全部完成。
|
||||
- 当前没有仍需立即闭环的同级核心缺口。
|
||||
- 后续如继续迭代，应视为“增强项”，而不是“基础未完成项”。
|
||||
|
||||
## 4. 当前可继续增强但不再计入本清单未完成项
|
||||
|
||||
- archive compare 从 latest-two 扩展为任意双快照对比
|
||||
- digest profile 管理从 cockpit 内联控件升级为专门 settings surface
|
||||
- importance template 阈值编辑增加更细粒度的批量编辑与重置动作
|
||||
- workflow / digest archive 增加更细的时间窗口筛选与全文检索
|
||||
- focus workspace 增加更多 candidate-scoped evidence drill-down
|
||||
|
||||
## 5. 最终结论
|
||||
|
||||
这份《未完成需求清单》在 2026-05-14 本轮之后，已经从“待补清单”变成“对齐完成记录”：
|
||||
|
||||
- 文档曾经列出的缺口已全部有代码实现
|
||||
- 对应 API、持久化、workbench UI、focused validation 均已补齐
|
||||
- 后续若再新增功能，应新开增强清单，而不是继续沿用本文件描述“未完成”
|
||||
@@ -0,0 +1,480 @@
|
||||
# AI ICT 盯盘告警开发任务清单 v1
|
||||
|
||||
## 1. 文档目标
|
||||
|
||||
本文档把 `docs/AI_ICT_盯盘告警技术设计稿_v1.md` 进一步拆成可执行开发任务清单，并按 `P0 / P1 / P2` 排优先级。
|
||||
|
||||
设计原则：
|
||||
|
||||
- 先打通最短闭环，再叠加视觉增强
|
||||
- 优先做“真正能发消息”的能力
|
||||
- 不让视觉层抢主判断权
|
||||
- 自动化执行尽量持续推进，只有遇到重大 blocker 才停
|
||||
|
||||
---
|
||||
|
||||
## 2. 总体优先级
|
||||
|
||||
### P0：最小可用盯盘告警闭环
|
||||
目标：
|
||||
|
||||
> candidate / decision alert 已经落库的前提下，让系统真正把告警发出去，并可观测、可回执、可重试。
|
||||
|
||||
### P1：视觉证据与工作台增强
|
||||
目标：
|
||||
|
||||
> 给高优先级机会附加截图与视觉总结，并让 dashboard 能看到这些证据。
|
||||
|
||||
补充原则：
|
||||
|
||||
- 原型验证阶段可先用现有人工页面或 browser 工具验证触发 ROI
|
||||
- 正式产品实现不得依赖人工开着外部工具会话
|
||||
- 视觉层除了 chart，也应覆盖新闻日历页、公告异常页、workbench 页面
|
||||
- 所有视觉结论必须结构化回写，不能只留截图
|
||||
- 告警最终目标是让人 30 秒内完成判断
|
||||
|
||||
### P2：反馈回流与自动化运营增强
|
||||
目标：
|
||||
|
||||
> 让系统具备反馈标记、统计、调优与长期自动化运转能力。
|
||||
|
||||
---
|
||||
|
||||
## 3. P0 任务清单
|
||||
|
||||
## P0-1 数据库与仓储补齐
|
||||
|
||||
### 目标
|
||||
补齐告警真正发送所需的数据存储。
|
||||
|
||||
### 任务
|
||||
- 新增 `alert_deliveries` 表
|
||||
- 为告警发送结果建立 repository
|
||||
- 如需要，扩展 `decision_alerts` 查询字段
|
||||
|
||||
### 建议文件
|
||||
- `migrations/*_create_alert_deliveries.sql`
|
||||
- `src/repositories/alert_delivery_repository.py`
|
||||
|
||||
### 验收
|
||||
- 可写入一条 delivery 记录
|
||||
- 可按 `alert_id` 查询 delivery 历史
|
||||
|
||||
---
|
||||
|
||||
## P0-2 消息通道基础设施
|
||||
|
||||
### 目标
|
||||
先打通一个可靠通道，建议 Telegram 或 Webhook。
|
||||
|
||||
### 任务
|
||||
- 新增 `src/services/notifications/telegram_notifier.py`
|
||||
- 新增 `src/services/notifications/webhook_notifier.py`
|
||||
- 新增 `src/services/notifications/__init__.py`
|
||||
- 在 settings 中增加 bot token / chat id / webhook url
|
||||
|
||||
### 建议接口
|
||||
- `send_text(...)`
|
||||
- `send_photo(...)`
|
||||
- `send_json(...)`
|
||||
|
||||
### 验收
|
||||
- 用测试脚本能成功发出一条测试消息
|
||||
- 失败时能返回明确错误而不是静默吞掉
|
||||
|
||||
---
|
||||
|
||||
## P0-3 告警模板与分发策略
|
||||
|
||||
### 目标
|
||||
把落库 alert 转成真正适合人查看的消息。
|
||||
|
||||
### 任务
|
||||
- 新增 `src/services/alerts/message_template_service.py`
|
||||
- 新增 `src/services/alerts/channel_router_service.py`
|
||||
- 新增 `src/services/alerts/delivery_policy_service.py`
|
||||
- 定义三类模板：
|
||||
- actionable
|
||||
- blocked / watch
|
||||
- runtime degraded
|
||||
|
||||
### 建议输出
|
||||
- 标的
|
||||
- timeframe
|
||||
- 当前 action recommendation
|
||||
- why blocked / why allowed
|
||||
- entry / stop / targets（若存在）
|
||||
|
||||
### 验收
|
||||
- 能根据 alert type 正确输出不同文案
|
||||
- 冷却策略能避免重复刷屏
|
||||
|
||||
---
|
||||
|
||||
## P0-4 Alert Dispatcher 主闭环
|
||||
|
||||
### 目标
|
||||
打通：`decision_alerts -> dispatcher -> notifier -> deliveries`。
|
||||
|
||||
### 任务
|
||||
- 新增 `src/services/alerts/alert_dispatcher_service.py`
|
||||
- 实现：
|
||||
- `dispatch_pending(limit=50)`
|
||||
- `dispatch_alert(alert_id)`
|
||||
- 发送成功回写 `delivered`
|
||||
- 发送失败写入 `failed`
|
||||
- dashboard only 类型标记 `skipped`
|
||||
- 新增 `src/services/alerts/__init__.py`
|
||||
|
||||
### 依赖
|
||||
- P0-1
|
||||
- P0-2
|
||||
- P0-3
|
||||
|
||||
### 验收
|
||||
- queued alert 可以成功变成 delivered / failed / skipped
|
||||
- 重复执行 dispatcher 不会重复发送同一条已成功告警
|
||||
|
||||
---
|
||||
|
||||
## P0-5 API 与脚本接入
|
||||
|
||||
### 目标
|
||||
让本地和 runtime 都能手动或自动触发 dispatcher。
|
||||
|
||||
### 任务
|
||||
- 新增 `src/api/alerts.py`
|
||||
- 扩展 `src/api/server.py`
|
||||
- 新增脚本 `scripts/run_alert_dispatcher.py`
|
||||
- 增加接口：
|
||||
- `POST /trading/alerts/dispatch`
|
||||
- `GET /trading/alerts/{alert_id}/deliveries`
|
||||
|
||||
### 验收
|
||||
- 可通过脚本单次发送 pending alerts
|
||||
- 可通过 API 查看某条 alert 的 delivery 历史
|
||||
|
||||
---
|
||||
|
||||
## P0-6 runtime 接入自动分发
|
||||
|
||||
### 目标
|
||||
让运行时在不遇到重大 blocker 的情况下持续自动发送提醒。
|
||||
|
||||
### 任务
|
||||
- 扩展 `src/services/runtime/trading_runtime_service.py`
|
||||
- 新增 runtime task：`alert_dispatch`
|
||||
- 在 task details 中记录：
|
||||
- `alerts_dispatched`
|
||||
- `delivery_failures`
|
||||
- `last_dispatch_status`
|
||||
|
||||
### 验收
|
||||
- runtime run once 时能顺带执行一次 alert dispatch
|
||||
- `/trading/runtime-status` 可看到 alert dispatch task 状态
|
||||
|
||||
---
|
||||
|
||||
## P0-7 P0 验证与最小上线标准
|
||||
|
||||
### 验证项
|
||||
- `decision packet` 能持续落库 alert
|
||||
- dispatcher 能把 queued alerts 发到外部通道
|
||||
- delivery 结果可查
|
||||
- runtime 状态里能看到 dispatch task
|
||||
- workbench 仍然正常工作
|
||||
|
||||
### 建议命令
|
||||
- `.venv/bin/python scripts/run_alert_dispatcher.py`
|
||||
- `.venv/bin/python scripts/run_decision_packet.py`
|
||||
- `.venv/bin/python scripts/run_trading_runtime.py`
|
||||
- `.venv/bin/python scripts/run_offline_checks.py`
|
||||
|
||||
### P0 完成定义
|
||||
当以下闭环成立时，P0 完成：
|
||||
|
||||
```text
|
||||
candidate -> decision alert -> dispatcher -> 外部消息 -> delivery record
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 4. P1 任务清单
|
||||
|
||||
## P1-1 截图存储模型
|
||||
|
||||
### 目标
|
||||
为视觉增强准备持久化结构。
|
||||
|
||||
### 任务
|
||||
- 新增 `visual_watch_runs` 表
|
||||
- 新增 `visual_snapshots` 表
|
||||
- 新增 `visual_reviews` 表
|
||||
- 新增 `src/repositories/visual_snapshot_repository.py`
|
||||
- 将 `trigger_type`、`source_name`、`watch_run_id` 作为主关联字段贯穿视觉链路
|
||||
- 为后续统计预留 `candidate_actionable_watch / candidate_block_reason_review / market_anomaly_review / session_focus_watch` 等触发类型
|
||||
|
||||
### 验收
|
||||
- 可保存截图元数据
|
||||
- 可保存一次 visual review 结果
|
||||
|
||||
---
|
||||
|
||||
## P1-2 截图采集服务
|
||||
|
||||
### 目标
|
||||
对高价值时刻生成可回放截图。
|
||||
|
||||
### 任务
|
||||
- 新增 `src/services/visual_watch/snapshot_capture_service.py`
|
||||
- 新增 `src/services/visual_watch/chart_source_adapter.py`
|
||||
- 支持至少一个源：
|
||||
- local workbench 或 TradingView
|
||||
|
||||
### 验收
|
||||
- 对指定 symbol/timeframe 生成截图文件
|
||||
- 截图路径、时间、source 可持久化
|
||||
|
||||
---
|
||||
|
||||
## P1-3 视觉复核摘要
|
||||
|
||||
### 目标
|
||||
不是只留图，而是生成结构化视觉摘要。
|
||||
|
||||
### 任务
|
||||
- 新增 `src/services/visual_watch/vision_review_service.py`
|
||||
- 新增 `src/services/visual_watch/visual_watch_service.py`
|
||||
- 输出：
|
||||
- `visual_state`
|
||||
- `visual_confidence`
|
||||
- `visual_notes`
|
||||
- `ui_anomalies`
|
||||
|
||||
### 验收
|
||||
- 对指定 candidate 生成 visual review 记录
|
||||
- review 与 candidate / packet 有关联关系
|
||||
|
||||
---
|
||||
|
||||
## P1-4 视觉触发策略
|
||||
|
||||
### 目标
|
||||
只在高价值时刻启用视觉层。
|
||||
|
||||
### 任务
|
||||
- 新增 `src/services/visual_watch/visual_trigger_policy_service.py`
|
||||
- 触发条件首批支持：
|
||||
- `candidate.status == executable`
|
||||
- `action_recommendation in {build_execution_ticket, confirm_ticket}`
|
||||
- runtime degraded
|
||||
|
||||
### 验收
|
||||
- 普通 observe 状态不触发视觉层
|
||||
- 高优先级事件触发视觉层
|
||||
|
||||
---
|
||||
|
||||
## P1-5 告警与视觉结果融合
|
||||
|
||||
### 目标
|
||||
让消息里带视觉证据，而不是结构化信息孤立存在。
|
||||
|
||||
### 任务
|
||||
- 扩展 `message_template_service.py`
|
||||
- 告警支持附带：
|
||||
- screenshot path 或图片发送
|
||||
- visual summary
|
||||
- visual caution / mismatch 提示
|
||||
|
||||
### 验收
|
||||
- actionable alert 可带图或带视觉摘要
|
||||
- visual mismatch 能提升为更高优先级警告
|
||||
|
||||
---
|
||||
|
||||
## P1-6 API 与 Workbench 增强
|
||||
|
||||
### 目标
|
||||
让前端能看到视觉证据与发送结果。
|
||||
|
||||
### 任务
|
||||
- 新增 `src/api/visual_watch.py`
|
||||
- 扩展 `src/api/server.py`
|
||||
- 扩展 `src/web/app.js`
|
||||
- 扩展 `src/web/index.html`
|
||||
- 新增页面区块：
|
||||
- Recent Alerts
|
||||
- Delivery Status
|
||||
- Snapshot Gallery
|
||||
- Visual Review
|
||||
|
||||
### 验收
|
||||
- workbench 能显示最近 visual review
|
||||
- 能查看 alert delivery 历史
|
||||
|
||||
---
|
||||
|
||||
## P1-7 runtime 接入视觉层
|
||||
|
||||
### 目标
|
||||
把视觉复核纳入运行时自动化，但只在策略命中时触发。
|
||||
|
||||
### 任务
|
||||
- runtime 新增 `visual_watch` task
|
||||
- task details 记录：
|
||||
- `visual_reviews_created`
|
||||
- `last_visual_state`
|
||||
- `last_snapshot_source`
|
||||
|
||||
### 验收
|
||||
- runtime run once 时，在高优先级时刻自动产出 visual review
|
||||
|
||||
---
|
||||
|
||||
## 5. P2 任务清单
|
||||
|
||||
## P2-1 人工反馈回流
|
||||
|
||||
### 目标
|
||||
让告警与视觉增强可被持续调优。
|
||||
|
||||
### 任务
|
||||
- 新增 `alert_feedback` 表
|
||||
- 新增 `src/repositories/alert_feedback_repository.py`
|
||||
- 新增 `src/services/feedback/alert_feedback_service.py`
|
||||
- 新增 `src/api/feedback.py`
|
||||
|
||||
### 标签建议
|
||||
- `useful`
|
||||
- `too_early`
|
||||
- `too_late`
|
||||
- `false_positive`
|
||||
- `visual_helpful`
|
||||
- `visual_misleading`
|
||||
- `actionable`
|
||||
|
||||
### 验收
|
||||
- 可为 alert 添加反馈
|
||||
- 可查询 alert 的反馈记录
|
||||
- 2026-05-11 P8 实现已扩展到 visual review feedback：可为视觉复核添加 `visual_helpful` / `visual_misleading` / `actionable` 标签。
|
||||
- 2026-05-11 P8 实现已让 alert dispatch 在现有 workbench/webhook payload 中附带最新 visual evidence；额外图片通道属于后续增强，不作为 P8 阻塞。
|
||||
|
||||
---
|
||||
|
||||
## P2-2 统计与复盘面板
|
||||
|
||||
### 目标
|
||||
让系统不只是会发，还能衡量质量。
|
||||
|
||||
### 任务
|
||||
- 统计 delivery success rate
|
||||
- 统计 alert usefulness rate
|
||||
- 统计 visual helpfulness rate
|
||||
- 在 review packet 或 dashboard 增加简报视图
|
||||
|
||||
### 验收
|
||||
- 能看到最近一段时间的发送成功率与反馈标签分布
|
||||
- 2026-05-11 P9 实现已新增 `AlertQualitySummaryService`，聚合 recent alerts / deliveries / alert feedback / visual feedback / visual review states。
|
||||
- 2026-05-11 P9 实现已新增 `GET /trading/alerts/quality-summary`、`review_packet.alert_quality_summary` 和 dashboard `Alert Quality` 面板。
|
||||
- 2026-05-11 P9 本地闭环已验证：全量 `tests/unit` 通过，runtime smoke 无 blocker，本地 API/workbench smoke 可见质量摘要。
|
||||
|
||||
---
|
||||
|
||||
## P2-3 自动化运维增强
|
||||
|
||||
### 目标
|
||||
让这套能力适合长期 unattended 运行。
|
||||
|
||||
### 任务
|
||||
- 增强自动恢复与重试
|
||||
- 增加静默窗口 / 降噪策略
|
||||
- 增加 stuck task 检测
|
||||
- 增加 screenshot 存储清理策略
|
||||
|
||||
### 当前进展
|
||||
- 2026-05-12 P10 已完成 `screenshot` 存储清理闭环：新增 `VisualCaptureRetentionService`、`scripts/run_visual_capture_cleanup.py`、`POST /trading/visual-watch/cleanup-captures`、runtime `visual_capture_cleanup` 任务，以及 workbench 手动触发入口。
|
||||
- 2026-05-12 P10 本地闭环已验证：cleanup 脚本可删除过期临时文件，runtime smoke 无 blocker，本地 API/workbench smoke 可见 cleanup 路径。
|
||||
- 2026-05-12 P11 已完成 `stuck task` 检测闭环：新增 `RuntimeTaskWatchdogService`、`scripts/run_runtime_task_watchdog.py`、`GET /trading/runtime-watchdog`、`runtime_status.runtime_watchdog`，以及 runtime 面板 stalled-task 呈现。
|
||||
- 2026-05-12 P11 本地闭环已验证：watchdog 脚本返回 `stalled_task_count=0`，runtime/API/workbench smoke 可见 watchdog 路径与状态输出。
|
||||
- 2026-05-12 P12 已完成 `silent window / noise control` 基础闭环：新增 `AlertSilentWindowService`、`scripts/run_alert_silent_window_status.py`、`GET /trading/alerts/silent-window-status`，并将静默窗口状态接入 dispatcher、alert quality summary、runtime `alert_dispatch` 细节和 workbench 面板。
|
||||
- 2026-05-12 P12 本地闭环已验证：silent-window 脚本与 API 可返回 `active=true`，`quality-summary` 与 dashboard 可见静默窗口状态与 suppression 统计。
|
||||
- 2026-05-12 P13 已完成 `delivery failure retry` 闭环：failed alerts 现在可以通过 bounded retry attempts + retry backoff 自动重试，并在 dispatcher payload、delivery summary 与 runtime `alert_dispatch` 细节中暴露可观测计数。
|
||||
- 2026-05-12 P13 本地闭环已验证：focused retry/backoff 单测通过，dispatcher 脚本返回 retry counters，runtime smoke 无 blocker 且 alert_dispatch 详情带 retry 字段。
|
||||
- 2026-05-12 P14 已完成 `webhook transport retry` 闭环：单次 outbound webhook 发送现在可以在 `AlertDispatcherService` 内部做 bounded transport retries，并在 dispatcher payload、delivery summary 与 runtime `alert_dispatch` 细节中暴露 transport retry 计数。
|
||||
- 2026-05-12 P14 本地闭环已验证：focused transport retry 单测通过，`tests/unit` 全量通过；脚本级 smoke 因本地 PostgreSQL 未监听 `127.0.0.1:5432` 而未能在最后重跑，但代码路径已被全量单测覆盖。
|
||||
- 2026-05-12 已新增 `docs/AI_ICT_自动化执行层_P15-PXX闭环任务清单_v1.md`：P15-PXX 被收敛为有限队列，从 alert noise policy matrix 继续推进到 browser screenshot capture、visual ROI、media dispatch、multi-channel routing、operator digest、runtime incident journal、maintenance rollup、unattended harness、remote smoke 与 PXX closure gate。
|
||||
- 2026-05-12 P15 已完成 `alert noise policy matrix` 本地闭环：外部发送现在可按 alert type / severity / channel / duty mode / operator mode / silent window / cooldown 形成结构化策略结果，并在 dispatcher、delivery summary、runtime `alert_dispatch` 与 workbench `Alert Quality` 中暴露降噪计数。
|
||||
- 2026-05-12 P16 已完成 `browser screenshot capture adapter` 本地闭环：visual snapshot capture 现在在保留 HTML/JSON artifact 的同时，可通过本机 Edge/Chrome headless 生成 PNG screenshot，并把 browser capture status、HTML path、screenshot path 接入脚本、API 与 workbench Visual Reviews。
|
||||
- 2026-05-12 P17 已完成 `visual trigger ROI router` 本地闭环：视觉触发策略现在区分 `triggered` / `skipped`，普通 observe/monitoring 状态不触发视觉复核，actionable、blocked、market degraded、broker/reconciliation degraded 与 council watch item 会输出可审计 trigger type / reason codes，并在 runtime、alert quality summary、脚本和 workbench 中暴露 trigger/skip/ROI 计数。
|
||||
- 2026-05-12 P18 已完成 `visual evidence media dispatch` 本地闭环：visual review 现在会生成稳定 `media_evidence` block，外部文本通道不支持文件时降级为 `media_linked`，workbench 可消费本地截图路径时标记 `media_attached`，无视觉证据时标记 `media_unavailable`；dispatcher、delivery summary、runtime、脚本和 workbench 均可见媒体证据状态。
|
||||
- 2026-05-12 P19 已完成 `multi-channel alert routing` 本地闭环：channel router 现在输出 workbench/webhook/WeCom/Email capability 与 health summary，WeCom/Email 在凭据缺失或 adapter 未实现时会以 disabled adapter 形式返回 `credential_missing` / `adapter_not_implemented`，dispatcher、delivery summary、runtime、脚本和 workbench 均可见 per-channel 状态。
|
||||
- 2026-05-12 P20 已完成 `operator digest / review queue` 本地闭环：operator digest 会把高价值告警、被抑制 delivery、失败/重试 delivery、视觉 mismatch 与待反馈项聚合成 bounded review queue，并通过脚本、API 和 workbench `Alert Quality` 面板暴露。
|
||||
- 2026-05-12 P21 已完成 `runtime incident journal` 本地闭环：runtime/watchdog/blocker/noisy incident 现在可聚合写入 `runtime_incidents`，每条 incident 带 severity、source、reason、first/last seen 与 recommended action，并通过脚本、API、runtime status 和 workbench runtime panel 暴露。
|
||||
- 2026-05-12 P22 已完成 `maintenance / retention rollup` 本地闭环：maintenance summary 以只读方式聚合 visual capture retention dry-run、delivery/feedback、runtime watchdog 与 incident journal，输出 P23 harness 可复用的 checks/blockers/warnings/p23_assertions，不执行未纳入 retention policy 的业务数据删除。
|
||||
- 2026-05-12 P23 已完成 `end-to-end unattended harness` 本地闭环：`UnattendedHarnessService`、脚本与 API 会在 analysis/decision-only 模式下一次性验证 P15-P22 关键路径，输出单一 JSON blockers/warnings/passed-checks 报告，不使用外部通道、不要求真实成交。
|
||||
- 2026-05-12 P24 已完成 `remote smoke / ops closure` 闭环：当前 `HEAD` 已部署到远端，部署后 11 个 HTTP smoke endpoint 通过，`scripts/run_remote_ops_smoke.py` 对 P15-P23 关键远端能力返回 9 个 passed checks、无 warnings、无 blockers。
|
||||
- 2026-05-12 PXX 已完成 `automation execution closure gate` 闭环：P15-P24 已冻结，`SESSION.md` / `TASKS.md` / `docs` 已回写，后续默认进入长期 monitor + ops rollup，不再自动发明 P25/P26。
|
||||
|
||||
### 验收
|
||||
- 非重大错误不打断主循环
|
||||
- delivery 失败可重试
|
||||
- 存储不会无限膨胀
|
||||
|
||||
---
|
||||
|
||||
## P2-4 多通道与多场景扩展
|
||||
|
||||
### 目标
|
||||
从单通道提升为多场景编排。
|
||||
|
||||
### 任务
|
||||
- 增加 WeCom / Email
|
||||
- 区分系统健康告警与交易机会告警
|
||||
- 区分值班模式 / 静默模式
|
||||
|
||||
### 验收
|
||||
- 可按 alert type 路由到不同通道
|
||||
|
||||
---
|
||||
|
||||
## 6. 推荐实施顺序
|
||||
|
||||
按最小闭环优先，推荐顺序：
|
||||
|
||||
1. `P0-1` 数据库与仓储补齐
|
||||
2. `P0-2` 消息通道基础设施
|
||||
3. `P0-3` 告警模板与分发策略
|
||||
4. `P0-4` Alert Dispatcher 主闭环
|
||||
5. `P0-5` API 与脚本接入
|
||||
6. `P0-6` runtime 接入自动分发
|
||||
7. `P0-7` P0 验证
|
||||
8. `P1-1` ~ `P1-7` 视觉增强
|
||||
9. `P2-1` ~ `P2-4` 反馈与运营增强
|
||||
|
||||
---
|
||||
|
||||
## 7. 重大 blocker 定义
|
||||
|
||||
自动化执行脚本只有遇到以下情况才应暂停：
|
||||
|
||||
1. 缺失外部凭据
|
||||
2. 需要人工授权的外部通道配置
|
||||
3. 数据库迁移失败且无法安全回滚
|
||||
4. 浏览器/截图依赖缺失且无法自动安装
|
||||
5. 会导致真实交易风险的边界不明确
|
||||
|
||||
除此之外，应持续自动推进。
|
||||
|
||||
---
|
||||
|
||||
## 8. 最小可用版本定义
|
||||
|
||||
最小可用版本只要求完成 P0：
|
||||
|
||||
- alert 能真正发出
|
||||
- 有 delivery 记录
|
||||
- runtime 能持续分发
|
||||
- workbench 与 API 可观察
|
||||
|
||||
达到这一点后，这个系统就已经从“只会生成数据库内提醒”升级成“真正可用的盯盘主动通知系统”。
|
||||
@@ -0,0 +1,779 @@
|
||||
# AI ICT 盯盘告警技术设计稿 v1
|
||||
|
||||
## 1. 文档目标
|
||||
|
||||
本文档基于当前仓库目录，细化“AI 盯盘 + 主动告警”方案需要新增的模块、文件、接口、数据流和落地顺序。
|
||||
|
||||
目标不是推翻现有交易主链，而是在当前结构化交易运行时之上补齐：
|
||||
|
||||
- 外发消息告警
|
||||
- 视觉复核
|
||||
- 截图与证据留存
|
||||
- 告警回执与人工反馈
|
||||
|
||||
## 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`
|
||||
- `src/api/server.py`
|
||||
- `src/web/app.js`
|
||||
|
||||
当前系统已经具备：
|
||||
|
||||
- runtime 调度
|
||||
- market truth gate
|
||||
- active trading plan 生成
|
||||
- trade plan candidate 生成
|
||||
- decision packet 构建
|
||||
- decision alerts 落库
|
||||
- operator notes
|
||||
|
||||
缺口主要在“告警真正发出去”和“高价值时刻的视觉复核”。
|
||||
|
||||
## 3. 设计目标
|
||||
|
||||
### 3.1 本轮新增目标
|
||||
|
||||
1. 把 queued alerts 真正发到外部消息通道
|
||||
2. 给高优先级机会附加截图和视觉摘要
|
||||
3. 让 dashboard 可查看截图、告警发送结果、视觉结论
|
||||
4. 支持人工对告警进行反馈标记
|
||||
|
||||
### 3.2 明确不做
|
||||
|
||||
1. 不让视觉层替代 candidate 生成
|
||||
2. 不让视觉层绕过 risk governor
|
||||
3. 不让视觉层直接自动触发真实下单
|
||||
4. 不做全时全量高频截图
|
||||
|
||||
## 4. 建议新增目录与文件
|
||||
|
||||
以下按当前仓库结构给出建议。
|
||||
|
||||
---
|
||||
|
||||
## 4.1 services 层
|
||||
|
||||
### A. 新增 `src/services/alerts/`
|
||||
|
||||
用途：负责消息编排、分发、模板、重试和发送状态回写。
|
||||
|
||||
建议文件：
|
||||
|
||||
#### `src/services/alerts/__init__.py`
|
||||
导出告警服务。
|
||||
|
||||
#### `src/services/alerts/alert_dispatcher_service.py`
|
||||
核心职责：
|
||||
|
||||
- 拉取 `decision_alerts` 中 `status=queued` 的记录
|
||||
- 根据 channel policy 发送
|
||||
- 回写 `delivered / failed / skipped`
|
||||
- 支持冷却时间与重复抑制
|
||||
|
||||
建议类：
|
||||
|
||||
- `AlertDispatcherService`
|
||||
- `AlertDispatchResult`
|
||||
|
||||
建议方法：
|
||||
|
||||
- `dispatch_pending(limit: int = 50) -> dict`
|
||||
- `dispatch_alert(alert_id: int) -> dict`
|
||||
- `select_channel(alert: dict) -> str`
|
||||
- `should_skip(alert: dict) -> tuple[bool, str]`
|
||||
|
||||
#### `src/services/alerts/message_template_service.py`
|
||||
职责：把 decision packet / visual summary 组装成用户可读消息。
|
||||
|
||||
建议方法：
|
||||
|
||||
- `build_actionable_message(alert: dict, packet: dict, visual: dict | None) -> str`
|
||||
- `build_blocked_message(...) -> str`
|
||||
- `build_system_warning_message(...) -> str`
|
||||
|
||||
#### `src/services/alerts/channel_router_service.py`
|
||||
职责：根据 alert type / priority 决定发送到哪个通道。
|
||||
|
||||
例如：
|
||||
|
||||
- `candidate_actionable` -> Telegram + 企业微信
|
||||
- `candidate_blocked` -> dashboard only
|
||||
- `runtime_degraded` -> Telegram + dashboard
|
||||
|
||||
2026-05-12 P19 已落地：当前 channel router 保持现有 workbench/webhook 行为，同时输出结构化 `channel_route`、channel capability 与 channel health summary。WeCom / Email 已预留为 disabled adapter；凭据缺失时暴露 `credential_missing`，凭据存在但 adapter 未实现时暴露 `adapter_not_implemented`，不会把未配置通道伪装为成功发送。dispatcher、delivery summary、runtime 与 workbench 均可查看 per-channel 状态。
|
||||
|
||||
#### `src/services/alerts/operator_digest_service.py`
|
||||
职责：把 recent alerts、delivery history、visual reviews、alert/visual feedback 和 alert quality summary 聚合成 operator digest。
|
||||
|
||||
2026-05-12 P20 已落地：digest 输出 high-value alerts、suppressed deliveries、failed/retry deliveries、visual mismatches、pending feedback items、quality flags 与 bounded review queue。该服务只做复盘聚合与 operator 可观测性，不改变 execution allowed、real live readiness、risk governor、trust bucket 或 operator confirmation protocol。
|
||||
|
||||
#### `src/services/runtime/runtime_incident_journal_service.py`
|
||||
职责：把 runtime status、watchdog、blocker/warning/noisy incident 规范化为可持久化 incident journal。
|
||||
|
||||
2026-05-12 P21 已落地：`runtime_incidents` 使用 `incident_key` 做去重聚合，并保存 severity、source、reason、subject、first/last seen、occurrence_count、recommended_action 与 payload。`GET /trading/runtime-incidents`、`scripts/run_runtime_incident_journal.py`、`runtime_status.incident_summary` 与 workbench runtime panel 均可查看当前 incident summary；该层只做可观测性与恢复建议，不改变任何交易权限或 operator confirmation protocol。
|
||||
|
||||
#### `src/services/maintenance/maintenance_summary_service.py`
|
||||
职责：只读汇总 storage / delivery / feedback / runtime 维护健康状态，为无人值守 harness 提供断言输入。
|
||||
|
||||
2026-05-12 P22 已落地：maintenance summary 会 dry-run visual capture retention，读取 alert quality summary、runtime watchdog 与 runtime incident journal，输出 `checks`、`blockers`、`warnings`、`maintenance_actions` 与 `p23_assertions`。该 summary 不执行删除；自动清理动作只作为可用 action 暴露，未纳入 retention policy 的业务数据不会被删除。
|
||||
|
||||
#### `src/services/maintenance/unattended_harness_service.py`
|
||||
职责：把 P15-P22 的自动化执行层关键能力聚合成可一条命令运行的 unattended smoke harness。
|
||||
|
||||
2026-05-12 P23 已落地：unattended harness 以 analysis/decision-only 模式验证 policy suppression、dispatch retry contract、runtime watchdog、visual capture fallback、feedback rollup、visual media/channel rollup、operator digest、maintenance summary 与 runtime environment，并输出单一 JSON 报告。该 harness 不使用外部通道、不要求真实成交，环境不可用时以 environment blocker 暴露，不改变 execution allowed、real live readiness、risk governor、trust bucket 或 operator confirmation protocol。
|
||||
|
||||
#### `scripts/run_remote_ops_smoke.py`
|
||||
职责：提供 P24 远端部署后的统一 ops smoke 入口。
|
||||
|
||||
2026-05-12 P24 已落地：remote ops smoke 覆盖 health、runtime status、review packet、alert quality、operator digest、runtime incidents、maintenance summary、visual-watch cleanup dry-run 与 P23 unattended harness。该脚本只做远端可用性验证，visual-watch 步骤使用 dry-run，不触发外部通道、不要求真实成交，也不改变任何交易权限或 operator confirmation protocol。
|
||||
|
||||
#### `scripts/run_automation_execution_closure_gate.py`
|
||||
职责：验证 P15-P24 与 PXX finite-scope closure 是否已经完成，并冻结自动扩阶段的默认后续状态。
|
||||
|
||||
2026-05-12 PXX 已落地：closure gate 只读取 `SESSION.md`、`TASKS.md` 与 P15-PXX 任务清单，确认 P15-P24 已 closed、PXX 后默认状态已冻结、`new_phase_policy` 要求用户显式打开新阶段。该脚本只做状态校验，不改变任何执行权限、交易权限或 operator confirmation protocol。
|
||||
|
||||
#### `src/services/alerts/delivery_policy_service.py`
|
||||
职责：
|
||||
|
||||
- 冷却时间
|
||||
- 同一 alert_key 去重策略
|
||||
- 升级策略
|
||||
- 夜间静默策略（如需要）
|
||||
- alert noise policy matrix：按 alert type / severity / channel / duty mode / operator mode / silent window / cooldown 输出 `workbench_only`、`external_allowed`、`suppressed_noise_policy`、`suppressed_silent_window` 等结构化策略结果
|
||||
|
||||
2026-05-12 P15 已落地：`evaluate_alert_delivery_policy()` 会把 policy result 写入 dispatcher delivery payload，并在 alert quality summary、runtime `alert_dispatch` details 与 workbench `Alert Quality` 面板中暴露 policy counters。
|
||||
|
||||
---
|
||||
|
||||
### B. 新增 `src/services/notifications/`
|
||||
|
||||
用途：各具体消息通道适配器。
|
||||
|
||||
建议文件：
|
||||
|
||||
#### `src/services/notifications/__init__.py`
|
||||
|
||||
#### `src/services/notifications/telegram_notifier.py`
|
||||
建议类：`TelegramNotifier`
|
||||
|
||||
建议方法：
|
||||
|
||||
- `send_text(chat_id: str, text: str) -> dict`
|
||||
- `send_photo(chat_id: str, text: str, image_path: str) -> dict`
|
||||
|
||||
#### `src/services/notifications/wecom_notifier.py`
|
||||
建议类：`WecomNotifier`
|
||||
|
||||
#### `src/services/notifications/webhook_notifier.py`
|
||||
建议类：`WebhookNotifier`
|
||||
|
||||
#### `src/services/notifications/email_notifier.py`
|
||||
可选，优先级较低。
|
||||
|
||||
---
|
||||
|
||||
### C. 新增 `src/services/visual_watch/`
|
||||
|
||||
用途：高价值时刻截图、视觉复核、结果回写。
|
||||
|
||||
补充吸收点：
|
||||
|
||||
- 研发验证阶段允许先使用现有手工页面、browser/computer use、截图工具验证视觉触发 ROI
|
||||
- 正式产品阶段必须切换到系统内建浏览器自动化与截图闭环，不能依赖人工开着工具会话
|
||||
- 视觉数据源不只包含 chart，也应包含新闻日历页、交易所公告/异常页、本地 workbench 页面
|
||||
|
||||
建议文件：
|
||||
|
||||
#### `src/services/visual_watch/__init__.py`
|
||||
|
||||
#### `src/services/visual_watch/visual_watch_service.py`
|
||||
总控服务。
|
||||
|
||||
职责：
|
||||
|
||||
- 接收 symbol / timeframe / candidate / packet
|
||||
- 选择数据源
|
||||
- 触发截图
|
||||
- 调用视觉复核
|
||||
- 生成 visual summary
|
||||
- 写入数据库
|
||||
|
||||
建议类：
|
||||
|
||||
- `VisualWatchService`
|
||||
- `VisualWatchRequest`
|
||||
- `VisualWatchResult`
|
||||
|
||||
建议方法：
|
||||
|
||||
- `review_candidate(candidate_id: int) -> dict`
|
||||
- `review_decision_packet(packet_id: int) -> dict`
|
||||
- `review_runtime_incident(symbol: str, incident_code: str) -> dict`
|
||||
|
||||
#### `src/services/visual_watch/chart_source_adapter.py`
|
||||
职责：统一不同图表来源。
|
||||
|
||||
建议适配：
|
||||
|
||||
- TradingView
|
||||
- OKX Web
|
||||
- 本地 workbench
|
||||
|
||||
建议类：
|
||||
|
||||
- `ChartSourceAdapter`
|
||||
- `TradingViewChartAdapter`
|
||||
- `OkxChartAdapter`
|
||||
- `LocalWorkbenchAdapter`
|
||||
|
||||
建议方法：
|
||||
|
||||
- `build_chart_url(symbol: str, timeframe: str) -> str`
|
||||
- `build_capture_spec(...) -> dict`
|
||||
|
||||
#### `src/services/visual_watch/snapshot_capture_service.py`
|
||||
职责：截图执行层。
|
||||
|
||||
生产建议基于 Playwright；研发期可保留兼容抽象。
|
||||
|
||||
建议方法：
|
||||
|
||||
- `capture_page(url: str, viewport: dict, clip: dict | None = None) -> dict`
|
||||
- `capture_chart(symbol: str, timeframe: str, source: str) -> dict`
|
||||
|
||||
输出建议：
|
||||
|
||||
- `image_path`
|
||||
- `html_path`
|
||||
- `screenshot_path`
|
||||
- `captured_ts`
|
||||
- `source`
|
||||
- `browser_capture_status`
|
||||
- `meta`
|
||||
|
||||
2026-05-12 P16 已落地：当前实现优先使用本机 Edge/Chrome headless 截取 review-packet HTML 或指定 capture URL，成功时输出 PNG；浏览器不可用或截图失败时返回结构化 `browser_capture_status=unavailable`，并保留 HTML/JSON artifact 作为 advisory fallback。
|
||||
|
||||
#### `src/services/visual_watch/vision_review_service.py`
|
||||
职责：把截图和结构化上下文融合为视觉摘要。
|
||||
|
||||
建议方法：
|
||||
|
||||
- `review_snapshot(image_path: str, context: dict) -> dict`
|
||||
- `summarize_candidate_visual_state(...) -> dict`
|
||||
|
||||
输出字段建议：
|
||||
|
||||
- `visual_state`: `confirm | caution | mismatch | unavailable`
|
||||
- `visual_confidence`
|
||||
- `visual_notes`
|
||||
- `ui_anomalies`
|
||||
|
||||
#### `src/services/visual_watch/visual_trigger_policy_service.py`
|
||||
职责：控制何时启动视觉层。
|
||||
|
||||
建议规则：
|
||||
|
||||
- `action_recommendation in {build_execution_ticket, confirm_ticket}`
|
||||
- `candidate.status == executable`
|
||||
- `runtime incident` 高优先级
|
||||
- session 切换
|
||||
- candidate 临近 `entry zone`
|
||||
- candidate 从 blocked 进入接近 actionable
|
||||
- news window 激活后需要页面级复核
|
||||
- reconciliation 发现异常后需要人工式视觉巡检
|
||||
|
||||
建议触发类型枚举：
|
||||
|
||||
- `candidate_actionable_watch`
|
||||
- `candidate_block_reason_review`
|
||||
- `market_anomaly_review`
|
||||
- `session_focus_watch`
|
||||
- `news_window_review`
|
||||
- `reconciliation_review`
|
||||
|
||||
这些触发类型建议贯穿 visual watch run、snapshot、review、alert payload，便于后续统计 ROI。
|
||||
|
||||
2026-05-12 P17 已落地：`evaluate_visual_trigger_policy()` 现在输出 `triggered` / `skipped`、`trigger_types`、`primary_trigger_type`、`reason_codes`、`skip_reason` 与 ROI 友好的基础字段。普通 observe/monitoring 不再触发视觉复核，actionable、blocked、market degraded、broker/reconciliation degraded 与 council watch item 会创建 policy-backed visual watch request；runtime、alert quality summary、脚本与 workbench 均可查看 trigger/skip/ROI 统计。
|
||||
|
||||
#### `src/services/visual_watch/visual_media_evidence_service.py`
|
||||
职责：把视觉复核结果转换成 alert/workbench 均可消费的媒体证据块。
|
||||
|
||||
输出建议：
|
||||
|
||||
- `status`: `media_attached | media_linked | media_unavailable`
|
||||
- `items`: screenshot / html / metadata artifact 列表
|
||||
- `primary_item`: 首选截图或路径证据
|
||||
- `mime_type`
|
||||
- `browser_capture_status`
|
||||
- `fallback_reason`
|
||||
|
||||
2026-05-12 P18 已落地：workbench 通道可将本地截图路径作为 `media_attached` 消费；webhook 等文本通道在不支持文件上传时降级为 `media_linked`，并把路径、mime type、browser capture status 与 fallback reason 写入 delivery payload，不把媒体能力缺失误报为 dispatch 失败。
|
||||
|
||||
---
|
||||
|
||||
### D. 新增 `src/services/feedback/`
|
||||
|
||||
用途：人工对 alert / visual review 做反馈。
|
||||
|
||||
建议文件：
|
||||
|
||||
#### `src/services/feedback/__init__.py`
|
||||
|
||||
#### `src/services/feedback/alert_feedback_service.py`
|
||||
建议方法：
|
||||
|
||||
- `record_feedback(alert_id: int, label: str, note: str | None = None) -> dict`
|
||||
- `list_feedback(alert_id: int) -> list[dict]`
|
||||
|
||||
可选标签：
|
||||
|
||||
- `useful`
|
||||
- `too_early`
|
||||
- `too_late`
|
||||
- `false_positive`
|
||||
- `visual_helpful`
|
||||
- `visual_misleading`
|
||||
- `actionable`
|
||||
|
||||
---
|
||||
|
||||
## 4.2 repositories 层
|
||||
|
||||
### A. 新增 `src/repositories/alert_delivery_repository.py`
|
||||
|
||||
职责：
|
||||
|
||||
- 写入每次实际发送结果
|
||||
- 查询失败记录
|
||||
- 查询最近发送统计
|
||||
|
||||
建议方法：
|
||||
|
||||
- `insert_delivery(...) -> int`
|
||||
- `fetch_recent_deliveries(alert_id: int, limit: int = 20) -> list[dict]`
|
||||
- `fetch_failed_deliveries(limit: int = 100) -> list[dict]`
|
||||
|
||||
### B. 新增 `src/repositories/visual_snapshot_repository.py`
|
||||
|
||||
职责：
|
||||
|
||||
- 记录截图元数据
|
||||
- 记录 visual review 结果
|
||||
- 按 candidate / packet 查询最近截图
|
||||
|
||||
建议方法：
|
||||
|
||||
- `insert_snapshot(...) -> int`
|
||||
- `insert_visual_review(...) -> int`
|
||||
- `fetch_latest_snapshot_for_candidate(candidate_id: int) -> dict | None`
|
||||
- `fetch_reviews_for_packet(packet_id: int, limit: int = 10) -> list[dict]`
|
||||
|
||||
### C. 新增 `src/repositories/alert_feedback_repository.py`
|
||||
|
||||
职责：
|
||||
|
||||
- 保存人工反馈标签和备注
|
||||
|
||||
---
|
||||
|
||||
## 4.3 api 层
|
||||
|
||||
在 `src/api/` 下建议新增或扩展以下文件。
|
||||
|
||||
### A. 新增 `src/api/alerts.py`
|
||||
|
||||
职责：告警与发送结果查询。
|
||||
|
||||
建议函数：
|
||||
|
||||
- `get_recent_alerts(instrument_id: int, limit: int = 20) -> list[dict]`
|
||||
- `dispatch_pending_alerts(limit: int = 50) -> dict`
|
||||
- `get_alert_deliveries(alert_id: int, limit: int = 20) -> list[dict]`
|
||||
- `get_alert_quality_summary(instrument_id: int, limit: int = 50, visual_limit: int = 50) -> dict`
|
||||
|
||||
### B. 新增 `src/api/visual_watch.py`
|
||||
|
||||
职责：视觉触发和结果查询。
|
||||
|
||||
建议函数：
|
||||
|
||||
- `run_visual_candidate_review(candidate_id: int) -> dict`
|
||||
- `run_visual_packet_review(packet_id: int) -> dict`
|
||||
- `get_visual_reviews(candidate_id: int | None = None, packet_id: int | None = None, limit: int = 20) -> list[dict]`
|
||||
|
||||
### C. 新增 `src/api/feedback.py`
|
||||
|
||||
职责：人工反馈接口。
|
||||
|
||||
建议函数：
|
||||
|
||||
- `create_alert_feedback(alert_id: int, label: str, note: str | None = None) -> dict`
|
||||
- `get_alert_feedback(alert_id: int) -> list[dict]`
|
||||
|
||||
### D. 扩展 `src/api/trading_runtime.py`
|
||||
|
||||
建议新增：
|
||||
|
||||
- `run_trading_alert_dispatch() -> dict`
|
||||
- `run_visual_watch_for_candidate(candidate_id: int) -> dict`
|
||||
- `get_trading_visual_status(...) -> dict`
|
||||
|
||||
### E. 扩展 `src/api/server.py`
|
||||
|
||||
建议增加路由：
|
||||
|
||||
#### 告警
|
||||
- `GET /trading/alerts?instrument_id=1&limit=20`
|
||||
- `POST /trading/alerts/dispatch`
|
||||
- `GET /trading/alerts/{alert_id}/deliveries`
|
||||
- `GET /trading/alerts/quality-summary?instrument_id=1&limit=50&visual_limit=50`
|
||||
|
||||
#### 视觉复核
|
||||
- `POST /trading/candidates/{candidate_id}/visual-review`
|
||||
- `POST /trading/decision-packets/{packet_id}/visual-review`
|
||||
- `GET /trading/visual-reviews?candidate_id=...&limit=20`
|
||||
|
||||
#### 人工反馈
|
||||
- `POST /trading/alerts/{alert_id}/feedback`
|
||||
- `GET /trading/alerts/{alert_id}/feedback`
|
||||
|
||||
---
|
||||
|
||||
## 4.4 runtime 层
|
||||
|
||||
建议扩展：
|
||||
|
||||
### 文件：`src/services/runtime/trading_runtime_service.py`
|
||||
|
||||
现有 tasks：
|
||||
|
||||
- market_state
|
||||
- broker_sync
|
||||
- reconciliation
|
||||
- watch
|
||||
- decision_packet
|
||||
- plan
|
||||
|
||||
建议新增两个 task：
|
||||
|
||||
### A. `visual_watch`
|
||||
职责：
|
||||
|
||||
- 只在触发策略命中时执行
|
||||
- 对高价值事件生成截图和视觉摘要
|
||||
|
||||
### B. `alert_dispatch`
|
||||
职责：
|
||||
|
||||
- 定时扫描 queued alerts
|
||||
- 发送并回写结果
|
||||
|
||||
### 需要新增状态字段
|
||||
在 `RuntimeTaskState.details` 中补充：
|
||||
|
||||
- `alerts_dispatched`
|
||||
- `visual_reviews_created`
|
||||
- `failed_delivery_count`
|
||||
- `last_visual_state`
|
||||
|
||||
---
|
||||
|
||||
## 4.5 web 层
|
||||
|
||||
### A. 扩展 `src/web/app.js`
|
||||
|
||||
建议新增 UI 模块：
|
||||
|
||||
1. Recent Alerts 面板
|
||||
2. Alert Delivery 状态面板
|
||||
3. Visual Review 面板
|
||||
4. Snapshot Gallery
|
||||
5. Alert Feedback 面板
|
||||
|
||||
### B. 扩展 `src/web/index.html`
|
||||
|
||||
增加以下区域：
|
||||
|
||||
- 告警列表
|
||||
- 截图证据区
|
||||
- 视觉总结区
|
||||
- 反馈标记按钮
|
||||
|
||||
---
|
||||
|
||||
## 4.6 scripts 层
|
||||
|
||||
建议新增脚本：
|
||||
|
||||
### `scripts/run_alert_dispatcher.py`
|
||||
用途：单独运行告警发送流程。
|
||||
|
||||
### `scripts/run_visual_review.py`
|
||||
用途：对指定 candidate / packet 手动触发视觉复核。
|
||||
|
||||
### `scripts/run_monitoring_cycle.py`
|
||||
用途：做一轮“运行时 + 视觉 + 告警”的调试型总入口。
|
||||
|
||||
---
|
||||
|
||||
## 4.7 migrations 层
|
||||
|
||||
建议新增迁移，至少补三张表。
|
||||
|
||||
### A. `visual_snapshots`
|
||||
建议字段：
|
||||
|
||||
- `id`
|
||||
- `instrument_id`
|
||||
- `candidate_id`
|
||||
- `decision_packet_id`
|
||||
- `source`
|
||||
- `image_path`
|
||||
- `captured_ts`
|
||||
- `meta jsonb`
|
||||
|
||||
### B. `visual_watch_runs`
|
||||
建议字段：
|
||||
|
||||
- `id`
|
||||
- `instrument_id`
|
||||
- `trigger_type`
|
||||
- `source_name`
|
||||
- `status`
|
||||
- `started_ts`
|
||||
- `completed_ts`
|
||||
- `candidate_id`
|
||||
- `decision_packet_id`
|
||||
- `meta jsonb`
|
||||
|
||||
### C. `visual_reviews`
|
||||
建议字段：
|
||||
|
||||
- `id`
|
||||
- `watch_run_id`
|
||||
- `snapshot_id`
|
||||
- `instrument_id`
|
||||
- `candidate_id`
|
||||
- `decision_packet_id`
|
||||
- `visual_state`
|
||||
- `visual_confidence`
|
||||
- `visual_bias`
|
||||
- `visual_location`
|
||||
- `sweep_visible`
|
||||
- `mss_visible`
|
||||
- `fvg_visible`
|
||||
- `entry_zone_valid`
|
||||
- `invalidation_intact`
|
||||
- `summary`
|
||||
- `notes jsonb`
|
||||
- `anomalies jsonb`
|
||||
- `payload jsonb`
|
||||
- `created_ts`
|
||||
|
||||
### D. `alert_deliveries`
|
||||
建议字段：
|
||||
|
||||
- `id`
|
||||
- `alert_id`
|
||||
- `channel`
|
||||
- `status`
|
||||
- `attempted_ts`
|
||||
- `delivered_ts`
|
||||
- `external_message_id`
|
||||
- `error`
|
||||
- `payload jsonb`
|
||||
|
||||
### D. `alert_feedback`
|
||||
建议字段：
|
||||
|
||||
- `id`
|
||||
- `alert_id`
|
||||
- `label`
|
||||
- `note`
|
||||
- `created_by`
|
||||
- `created_ts`
|
||||
|
||||
---
|
||||
|
||||
## 5. 接口契约建议
|
||||
|
||||
## 5.1 visual review 输出契约
|
||||
|
||||
```json
|
||||
{
|
||||
"id": 101,
|
||||
"instrument_id": 1,
|
||||
"candidate_id": 88,
|
||||
"decision_packet_id": 55,
|
||||
"snapshot": {
|
||||
"image_path": "/data/visual/btc_1m_20260508_101500.png",
|
||||
"source": "tradingview",
|
||||
"captured_ts": "2026-05-08T10:15:00Z"
|
||||
},
|
||||
"visual_state": "confirm",
|
||||
"visual_confidence": 0.82,
|
||||
"summary": "结构与候选一致，回踩较干净，未见明显失效。",
|
||||
"notes": [
|
||||
"Sweep 后价格已回到区间内部",
|
||||
"MSS 后 pullback 较浅",
|
||||
"FVG 回踩仍在有效区"
|
||||
],
|
||||
"anomalies": [],
|
||||
"payload": {}
|
||||
}
|
||||
```
|
||||
|
||||
## 5.2 alert delivery 输出契约
|
||||
|
||||
```json
|
||||
{
|
||||
"alert_id": 301,
|
||||
"channel": "telegram",
|
||||
"status": "delivered",
|
||||
"attempted_ts": "2026-05-08T10:15:05Z",
|
||||
"delivered_ts": "2026-05-08T10:15:06Z",
|
||||
"external_message_id": "998877"
|
||||
}
|
||||
```
|
||||
|
||||
## 5.3 feedback 输出契约
|
||||
|
||||
```json
|
||||
{
|
||||
"alert_id": 301,
|
||||
"label": "useful",
|
||||
"note": "提醒时机合适，截图也有帮助",
|
||||
"created_by": "local_operator"
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 6. 触发策略建议
|
||||
|
||||
### 6.1 哪些事件触发视觉层
|
||||
|
||||
首批建议：
|
||||
|
||||
1. `candidate.status == executable`
|
||||
2. `action_recommendation in {build_execution_ticket, confirm_ticket}`
|
||||
3. `market_state` 进入 degraded
|
||||
4. `session` 切换到重点时段
|
||||
|
||||
### 6.2 哪些事件直接发消息
|
||||
|
||||
首批建议：
|
||||
|
||||
1. actionable candidate
|
||||
2. ticket ready
|
||||
3. runtime degraded
|
||||
4. visual mismatch（高风险提示）
|
||||
|
||||
### 6.3 哪些只写 dashboard 不推送
|
||||
|
||||
1. blocked candidate
|
||||
2. 低质量 observe 状态
|
||||
3. 重复告警冷却期间事件
|
||||
|
||||
---
|
||||
|
||||
## 7. 建议配置项
|
||||
|
||||
建议在 settings 中补充：
|
||||
|
||||
- `ALERTS_ENABLED`
|
||||
- `ALERT_DISPATCH_INTERVAL_SECONDS`
|
||||
- `ALERT_DEFAULT_CHANNEL`
|
||||
- `TELEGRAM_BOT_TOKEN`
|
||||
- `TELEGRAM_CHAT_ID`
|
||||
- `WECOM_WEBHOOK_URL`
|
||||
- `VISUAL_WATCH_ENABLED`
|
||||
- `VISUAL_WATCH_SOURCE`
|
||||
- `VISUAL_WATCH_VIEWPORT_WIDTH`
|
||||
- `VISUAL_WATCH_VIEWPORT_HEIGHT`
|
||||
- `VISUAL_WATCH_STORAGE_DIR`
|
||||
- `VISUAL_REVIEW_ON_ACTIONABLE_ONLY`
|
||||
- `VISUAL_CAPTURE_RETENTION_HOURS`
|
||||
- `VISUAL_CAPTURE_CLEANUP_INTERVAL_SECONDS`
|
||||
- `VISUAL_CAPTURE_CLEANUP_MAX_DELETE_FILES`
|
||||
- `RUNTIME_TASK_STALE_MULTIPLIER`
|
||||
- `RUNTIME_TASK_STUCK_MIN_SECONDS`
|
||||
- `ALERT_SILENT_WINDOW_ENABLED`
|
||||
- `ALERT_SILENT_WINDOW_START_HOUR`
|
||||
- `ALERT_SILENT_WINDOW_END_HOUR`
|
||||
- `ALERT_SILENT_WINDOW_TIMEZONE`
|
||||
- `ALERT_RETRY_FAILED_ENABLED`
|
||||
- `ALERT_RETRY_MAX_ATTEMPTS`
|
||||
- `ALERT_RETRY_BACKOFF_SECONDS`
|
||||
- `ALERT_WEBHOOK_TRANSPORT_RETRIES`
|
||||
- `ALERT_WEBHOOK_RETRY_BACKOFF_SECONDS`
|
||||
|
||||
---
|
||||
|
||||
## 8. 分阶段落地计划
|
||||
|
||||
### Phase 1：先打通消息外发
|
||||
|
||||
目标：
|
||||
|
||||
- 新增 alert dispatcher
|
||||
- 接入 Telegram 或 Webhook
|
||||
- 把现有 `decision_alerts` 真正发出去
|
||||
|
||||
### Phase 2：加入截图证据
|
||||
|
||||
目标：
|
||||
|
||||
- 对 actionable alert 生成截图
|
||||
- 告警附上 image_path 和视觉摘要占位
|
||||
|
||||
### Phase 3：加入视觉复核
|
||||
|
||||
目标：
|
||||
|
||||
- 生成 visual_state / confidence / notes
|
||||
- dashboard 展示 visual review
|
||||
|
||||
### Phase 4：加入反馈回流
|
||||
|
||||
目标：
|
||||
|
||||
- alert feedback 标记
|
||||
- delivery 成功率统计
|
||||
- visual helpfulness 统计
|
||||
- dashboard / review packet 质量简报
|
||||
|
||||
---
|
||||
|
||||
## 9. 风险与边界
|
||||
|
||||
1. 视觉层不能成为唯一真相源
|
||||
2. 截图成本和延迟必须受 trigger policy 控制
|
||||
3. 消息发送失败不能阻塞 runtime 主循环
|
||||
4. 所有视觉结论都必须带 candidate / packet 关联关系
|
||||
5. 实盘执行边界继续保持，盯盘增强不等于放开自动交易
|
||||
|
||||
---
|
||||
|
||||
## 10. 最小可用版本定义
|
||||
|
||||
最小可用版本建议只做：
|
||||
|
||||
- `AlertDispatcherService`
|
||||
- `TelegramNotifier`
|
||||
- `alert_deliveries` 表
|
||||
- `POST /trading/alerts/dispatch`
|
||||
- runtime 新增 `alert_dispatch` task
|
||||
|
||||
这样先让系统具备：
|
||||
|
||||
> 候选机会出现 -> 决策包生成 -> 告警落库 -> 实际发消息
|
||||
|
||||
之后再叠加视觉层，是最稳的推进路线。
|
||||
@@ -0,0 +1,249 @@
|
||||
# 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. 总体时序
|
||||
|
||||
标准流程：
|
||||
|
||||
```text
|
||||
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
|
||||
↓
|
||||
发送消息给用户
|
||||
```
|
||||
|
||||
高价值机会的增强流程：
|
||||
|
||||
```text
|
||||
Decision packet 进入 actionable 状态
|
||||
↓
|
||||
触发 Visual Watch Service
|
||||
↓
|
||||
打开 chart / workbench
|
||||
↓
|
||||
截图 + 视觉总结
|
||||
↓
|
||||
把 visual summary 追加到 alert payload
|
||||
↓
|
||||
发送高优先级提醒
|
||||
```
|
||||
|
||||
## 6. 最终架构图（文字版）
|
||||
|
||||
```text
|
||||
[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. 文档用途
|
||||
|
||||
本文件用于：
|
||||
|
||||
- 保存总体结构图
|
||||
- 给后续技术设计稿提供总纲
|
||||
- 为模块拆分、接口定义、数据库扩展提供边界约束
|
||||
@@ -0,0 +1,184 @@
|
||||
# AI_ICT 自动化执行层 P7 监控成熟度与晋级路由 v1
|
||||
|
||||
## 1. 文档目标
|
||||
|
||||
本文件用于打破 `continue_periodic_analysis_decision_monitoring` 的健康巡检循环。
|
||||
|
||||
P7 的定位是：
|
||||
|
||||
> 当分析/决策-only monitor 已经形成稳定窗口后，把“继续巡检”升级为“监控成熟度评估 + 下一 bounded automation slice 选择”。
|
||||
|
||||
P7 不是 `Research Council P7`。`Research Council P0-P6` 仍然冻结，P6 governance tick 仍然是研究委员会主线的终端治理入口。
|
||||
|
||||
---
|
||||
|
||||
## 2. 触发条件
|
||||
|
||||
只有同时满足以下条件，自动化才允许从 periodic monitor 进入 P7：
|
||||
|
||||
1. latest analysis decision monitor `passed=true`
|
||||
2. latest blockers 为空
|
||||
3. latest warnings 为空
|
||||
4. `analysis_decision_monitor_quality_gate.status=passed`
|
||||
5. `stable_monitoring_window=true`
|
||||
6. `consecutive_pass_count >= stable_sample_threshold`
|
||||
7. `decision_action=restricted_decision_support`
|
||||
8. `decision_operator_mode=observe_only`
|
||||
9. `real_trade_sample_gate_status=deferred_analysis_decision_only`
|
||||
10. `p6_governance_tick_status=no_op_healthy`
|
||||
|
||||
若任一条件不满足：
|
||||
|
||||
- monitor blocker 存在：进入 `repair_analysis_decision_monitor_blockers`
|
||||
- quality gate 未过但没有 blocker：继续 `continue_periodic_analysis_decision_monitoring`
|
||||
- 出现外部环境阻塞：记录阻塞并停止在最小可解释状态
|
||||
|
||||
---
|
||||
|
||||
## 3. P7 默认切片顺序
|
||||
|
||||
### P7-1 monitor maturity rollup
|
||||
|
||||
目标：把稳定窗口从“若干条 JSON 记录”提升为可读、可消费、可审计的成熟度摘要。
|
||||
|
||||
建议输出：
|
||||
|
||||
- `.claude/analysis_decision_monitor_maturity_rollup.json`
|
||||
- `SESSION.md` / `TASKS.md` 中的 P7 当前状态
|
||||
|
||||
摘要字段至少包含：
|
||||
|
||||
- local record count
|
||||
- local consecutive pass count
|
||||
- local quality gate status
|
||||
- latest observed broker/runtime/market/decision state
|
||||
- stable window conclusion
|
||||
- current allowed lane
|
||||
- prohibited lane
|
||||
- next bounded automation slice
|
||||
|
||||
---
|
||||
|
||||
### P7-2 local/remote drift check
|
||||
|
||||
目标：对比本地与远端 monitor 成熟度，避免本地健康但远端状态漂移。
|
||||
|
||||
检查项：
|
||||
|
||||
- 本地 quality gate
|
||||
- 远端容器 quality gate
|
||||
- 远端宿主机持久化 `.claude` quality gate
|
||||
- local/remote record count 差异
|
||||
- latest observed 关键字段差异
|
||||
|
||||
可接受状态：
|
||||
|
||||
- local 与 remote 均 `passed`
|
||||
- remote record count 不要求等于 local，但必须达到稳定窗口阈值
|
||||
- key guards 一致未变
|
||||
|
||||
若漂移不可解释，进入：
|
||||
|
||||
```text
|
||||
repair_analysis_decision_monitor_remote_drift
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### P7-3 alert and decision-support quality review
|
||||
|
||||
目标：判断当前 restricted decision-support 输出是否已经值得长期运行，而不是只判断 API 是否健康。
|
||||
|
||||
检查项：
|
||||
|
||||
- decision packet 是否持续存在
|
||||
- review packet 是否持续包含 trust score
|
||||
- review packet 是否持续包含 research summary
|
||||
- operator next actions 是否仍然处于 observe-only
|
||||
- alert 是否没有制造误导性“可交易”语义
|
||||
|
||||
若输出质量不足，进入最小 bounded slice：
|
||||
|
||||
```text
|
||||
improve_analysis_decision_support_quality
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### P7-4 bounded automation slice selector
|
||||
|
||||
目标：P7 不直接扩大系统能力，而是从成熟度评估中选择唯一的下一动作。
|
||||
|
||||
允许的下一动作只有：
|
||||
|
||||
| 条件 | next_slice |
|
||||
|---|---|
|
||||
| monitor 未稳定 | `continue_periodic_analysis_decision_monitoring` |
|
||||
| monitor blocker | `repair_analysis_decision_monitor_blockers` |
|
||||
| local/remote drift | `repair_analysis_decision_monitor_remote_drift` |
|
||||
| 输出质量不足 | `improve_analysis_decision_support_quality` |
|
||||
| 全部健康且无新问题 | `continue_periodic_analysis_decision_monitoring_with_maturity_rollup` |
|
||||
|
||||
P7 不允许一次打开多个改动方向。
|
||||
|
||||
---
|
||||
|
||||
### P7-5 state writeback
|
||||
|
||||
目标：让锚点文件反映“系统已从原地巡检升级到成熟度路由”。
|
||||
|
||||
必须回写：
|
||||
|
||||
- `SESSION.md`
|
||||
- `TASKS.md`
|
||||
- `.claude/automation_status.json`
|
||||
- `.claude/analysis_decision_monitor_maturity_rollup.json`
|
||||
|
||||
---
|
||||
|
||||
## 4. 边界守卫
|
||||
|
||||
P7 不允许做以下事情：
|
||||
|
||||
1. 不修改 `execution_allowed`
|
||||
2. 不修改 `real_live_ready`
|
||||
3. 不绕过 risk governor
|
||||
4. 不升级或降级 trust bucket
|
||||
5. 不绕过 operator confirmation protocol
|
||||
6. 不把 OKX fills 为 0 当作当前阶段 blocker
|
||||
7. 不创建 `Research Council P7`
|
||||
8. 不把 stable monitor 解释成实盘交易就绪
|
||||
|
||||
---
|
||||
|
||||
## 5. 阶段出口
|
||||
|
||||
P7 完成闭环后，状态应写为：
|
||||
|
||||
```text
|
||||
state: automation_execution_layer_p7_monitor_maturity_rollup_closed
|
||||
current_phase: Restricted Decision-Support Soft Rollout
|
||||
next_slice: <P7-4 selector result>
|
||||
```
|
||||
|
||||
如果 P7-4 选择的是：
|
||||
|
||||
```text
|
||||
continue_periodic_analysis_decision_monitoring_with_maturity_rollup
|
||||
```
|
||||
|
||||
则后续 periodic monitor 不再被视为“原地循环”，而是带有成熟度摘要的长期运行监控。
|
||||
|
||||
---
|
||||
|
||||
## 6. 验收标准
|
||||
|
||||
P7 可视为完成时，必须同时满足：
|
||||
|
||||
1. P7 文档存在
|
||||
2. `run_until_blocked.py` 能在 stable quality gate 后输出 P7 next slice
|
||||
3. P7 不创建 Research Council 新阶段
|
||||
4. P7 不改变任何交易权限或实盘就绪门
|
||||
5. focused unit tests 通过
|
||||
6. script static checks 通过
|
||||
7. `SESSION.md` / `TASKS.md` 已回写到 P7 当前入口
|
||||
@@ -0,0 +1,535 @@
|
||||
# AI ICT 自动化流程使用教程 v1
|
||||
|
||||
## 0. Current Default After P0-P6 Freeze
|
||||
|
||||
As of 2026-05-11, the default automation entrypoint for this project is:
|
||||
|
||||
```text
|
||||
scripts/run_until_blocked.py
|
||||
```
|
||||
|
||||
When `SESSION.md` / `TASKS.md` contain `automation_flow_p0_p6_review_closed`, this script does not use the older monitoring rollout phase queue. It first runs the Research Council P6 governance tick and applies the frozen P0-P6 policy:
|
||||
|
||||
- `no_op_healthy`: record health, stop Research Council phase expansion, and do not create P7.
|
||||
- `cycle_required`: run an optimization cycle only when the automation policy explicitly authorizes it.
|
||||
- `bounded_slice_required`: open only the smallest bounded implementation slice, then return to P6.
|
||||
|
||||
After the analysis/decision-only monitor reaches a stable quality window, the default loop no longer stays on `continue_periodic_analysis_decision_monitoring`. It advances to:
|
||||
|
||||
```text
|
||||
automation_execution_layer_p7_monitor_maturity_rollup
|
||||
```
|
||||
|
||||
This is automation execution-layer P7, not Research Council P7. It must keep the P0-P6 Research Council freeze, preserve observe-only semantics, and keep execution/live/risk/trust/operator confirmation gates unchanged.
|
||||
|
||||
The older `scripts/run_monitoring_alert_rollout.py` repair bridge remains historical/supporting tooling. It is not the default entrypoint for the current automation execution-layer flow.
|
||||
|
||||
The first execution-layer bootstrap slices are:
|
||||
|
||||
```text
|
||||
P0: P6 governance tick routing
|
||||
P1: anchor-driven smallest-slice selector
|
||||
P2: validation and quality-gate router
|
||||
P3: deploy/smoke router
|
||||
P4: state writeback renderer
|
||||
P7: monitor maturity rollup and bounded next-slice routing
|
||||
```
|
||||
|
||||
## 0.1 Default Kickoff Prompt
|
||||
|
||||
Going forward, the default operator kickoff prompt for this repository is:
|
||||
|
||||
```text
|
||||
启动 D:\ai-exchange 自动化流程。
|
||||
请先读取并以这些锚点为准：
|
||||
1. docs/AI_ICT_实盘交易分析决策助手下一阶段开发方案_v1.md
|
||||
2. SESSION.md
|
||||
3. TASKS.md
|
||||
全程按自动化闭环执行：读取锚点 -> 选择最小切片 -> 实现 -> focused validation -> 必要质量门 -> 必要时远端 deploy/smoke -> 回写 SESSION.md / TASKS.md。
|
||||
遇到真实外部阻塞再停下来说明，run-until-blocked。
|
||||
```
|
||||
|
||||
`docs/AI_ICT_全自动开发执行流程_v1.md` remains the protocol specification, but it is no longer required in the user-facing kickoff prompt.
|
||||
`docs/AI_ICT_TradingAgents_P0-P6合理性审查与优化结论_v1.md` remains as a historical governance-freeze reference and is not part of the default kickoff anchors anymore.
|
||||
|
||||
## 1. 文档目标
|
||||
|
||||
本文档用于说明当前项目内自动化编排工具的用途、使用方式、运行模式、repair bridge 协议、常见命令和实践建议，作为后续学习和日常使用手册。
|
||||
|
||||
当前这套工具仍然是 **`ai-exchange` 项目专用版本**。
|
||||
|
||||
不建议现在就抽成通用模板，因为它还需要继续通过实际项目推进来检验和修正。
|
||||
|
||||
---
|
||||
|
||||
## 2. 工具概览
|
||||
|
||||
当前主脚本：
|
||||
|
||||
```text
|
||||
scripts/run_monitoring_alert_rollout.py
|
||||
```
|
||||
|
||||
相关配套文档：
|
||||
|
||||
- `docs/archive/AI_ICT_下一阶段开发任务清单_v1.md`
|
||||
- `docs/AI_ICT_repair_bridge_protocol_v1.md`
|
||||
|
||||
这个脚本的目标不是直接替你完成所有业务开发，而是把当前项目的阶段推进流程固化为：
|
||||
|
||||
```text
|
||||
阶段执行
|
||||
-> 验证
|
||||
-> 发现失败
|
||||
-> 生成修复上下文
|
||||
-> 桥接外部修复代理
|
||||
-> 智能复验
|
||||
-> 推进下一阶段
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 3. 当前支持的阶段
|
||||
|
||||
当前脚本内置四个阶段：
|
||||
|
||||
- `N1` Launch Readiness 收尾
|
||||
- `N2` 最小主动消息告警闭环
|
||||
- `N3` 告警质量与 runtime 硬化
|
||||
- `N4` 视觉盯盘增强预埋
|
||||
|
||||
这些阶段定义在脚本的 `PHASES` 中，包括：
|
||||
|
||||
- `code`
|
||||
- `title`
|
||||
- `goal`
|
||||
- `tasks`
|
||||
- `files`
|
||||
- `validation_commands`
|
||||
- `deliverables`
|
||||
|
||||
---
|
||||
|
||||
## 4. 运行模式一览
|
||||
|
||||
通过环境变量控制：
|
||||
|
||||
```text
|
||||
MONITORING_ALERT_ROLLOUT_MODE
|
||||
```
|
||||
|
||||
当前支持：
|
||||
|
||||
- `plan`
|
||||
- `status`
|
||||
- `start`
|
||||
- `advance`
|
||||
- `block`
|
||||
- `complete`
|
||||
- `run-until-blocked`
|
||||
- `repair-loop`
|
||||
- `repair-bridge`
|
||||
|
||||
---
|
||||
|
||||
## 5. 最常用命令
|
||||
|
||||
## 5.1 查看计划
|
||||
|
||||
```bash
|
||||
.venv/bin/python scripts/run_monitoring_alert_rollout.py
|
||||
```
|
||||
|
||||
作用：
|
||||
|
||||
- 查看当前有哪些阶段
|
||||
- 查看自动化策略说明
|
||||
|
||||
---
|
||||
|
||||
## 5.2 初始化状态
|
||||
|
||||
```bash
|
||||
MONITORING_ALERT_ROLLOUT_MODE=start .venv/bin/python scripts/run_monitoring_alert_rollout.py
|
||||
```
|
||||
|
||||
作用：
|
||||
|
||||
- 初始化 `.claude/monitoring_alert_rollout_status.json`
|
||||
- 标记当前 phase 为首个阶段
|
||||
|
||||
---
|
||||
|
||||
## 5.3 查看状态
|
||||
|
||||
```bash
|
||||
MONITORING_ALERT_ROLLOUT_MODE=status .venv/bin/python scripts/run_monitoring_alert_rollout.py
|
||||
```
|
||||
|
||||
作用：
|
||||
|
||||
- 查看当前 phase
|
||||
- 已完成阶段
|
||||
- 上次运行结果
|
||||
- repair loop 状态
|
||||
|
||||
---
|
||||
|
||||
## 5.4 跑当前阶段直到卡住
|
||||
|
||||
```bash
|
||||
MONITORING_ALERT_ROLLOUT_MODE=run-until-blocked .venv/bin/python scripts/run_monitoring_alert_rollout.py
|
||||
```
|
||||
|
||||
作用：
|
||||
|
||||
- 执行当前阶段的验证命令
|
||||
- 自动判断：
|
||||
- `passed`
|
||||
- `needs_work`
|
||||
- `blocked`
|
||||
- 如果通过，会自动推进 phase
|
||||
|
||||
这是日常最核心的命令。
|
||||
|
||||
---
|
||||
|
||||
## 5.5 生成修复循环上下文
|
||||
|
||||
当 `run-until-blocked` 返回 `needs_work` 时：
|
||||
|
||||
```bash
|
||||
MONITORING_ALERT_ROLLOUT_MODE=repair-loop .venv/bin/python scripts/run_monitoring_alert_rollout.py
|
||||
```
|
||||
|
||||
作用：
|
||||
|
||||
- 从上次失败结果生成 repair loop payload
|
||||
- 生成：
|
||||
- `failure_class`
|
||||
- `recommended_focus`
|
||||
- `phase_patch_targets`
|
||||
- `repair_prompt_context`
|
||||
|
||||
---
|
||||
|
||||
## 5.6 桥接外部修复代理
|
||||
|
||||
```bash
|
||||
MONITORING_ALERT_AUTO_REPAIR_ENABLED=1 \
|
||||
MONITORING_ALERT_REPAIR_BRIDGE_COMMAND="python your_repair_agent.py" \
|
||||
MONITORING_ALERT_ROLLOUT_MODE=repair-bridge \
|
||||
.venv/bin/python scripts/run_monitoring_alert_rollout.py
|
||||
```
|
||||
|
||||
作用：
|
||||
|
||||
- 把 repair prompt/context 通过 JSON stdin 发给外部修复代理
|
||||
- 解析外部修复代理 stdout JSON
|
||||
- 决定是否自动复验
|
||||
|
||||
---
|
||||
|
||||
## 5.7 启用桥接后自动复验
|
||||
|
||||
```bash
|
||||
MONITORING_ALERT_AUTO_REPAIR_ENABLED=1 \
|
||||
MONITORING_ALERT_AUTO_RERUN_ENABLED=1 \
|
||||
MONITORING_ALERT_REPAIR_BRIDGE_COMMAND="python your_repair_agent.py" \
|
||||
MONITORING_ALERT_ROLLOUT_MODE=repair-bridge \
|
||||
.venv/bin/python scripts/run_monitoring_alert_rollout.py
|
||||
```
|
||||
|
||||
作用：
|
||||
|
||||
- 调 repair agent
|
||||
- 解析返回 JSON
|
||||
- 智能选择复验命令
|
||||
- 自动回跑 `run-until-blocked`
|
||||
- 自动判断是否 phase advance
|
||||
|
||||
---
|
||||
|
||||
## 5.8 JSON 输出模式
|
||||
|
||||
```bash
|
||||
MONITORING_ALERT_ROLLOUT_OUTPUT_JSON=1 \
|
||||
MONITORING_ALERT_ROLLOUT_MODE=status \
|
||||
.venv/bin/python scripts/run_monitoring_alert_rollout.py
|
||||
```
|
||||
|
||||
作用：
|
||||
|
||||
- 返回 machine-readable 输出
|
||||
- 适合给别的脚本、代理或 IDE 工具消费
|
||||
|
||||
---
|
||||
|
||||
## 6. 重要环境变量
|
||||
|
||||
## 6.1 基础模式
|
||||
|
||||
- `MONITORING_ALERT_ROLLOUT_MODE`
|
||||
- `MONITORING_ALERT_ROLLOUT_OUTPUT_JSON=1`
|
||||
|
||||
## 6.2 运行控制
|
||||
|
||||
- `MONITORING_ALERT_ROLLOUT_MAX_ROUNDS`
|
||||
- `MONITORING_ALERT_COMMAND_TIMEOUT_SECONDS`
|
||||
|
||||
## 6.3 repair bridge
|
||||
|
||||
- `MONITORING_ALERT_AUTO_REPAIR_ENABLED=1`
|
||||
- `MONITORING_ALERT_REPAIR_BRIDGE_COMMAND="..."`
|
||||
- `MONITORING_ALERT_AUTO_RERUN_ENABLED=1`
|
||||
|
||||
## 6.4 手动 blocker
|
||||
|
||||
- `MONITORING_ALERT_BLOCKER`
|
||||
- `MONITORING_ALERT_BLOCKER_NOTE`
|
||||
|
||||
---
|
||||
|
||||
## 7. 状态文件与锚点文件
|
||||
|
||||
## 7.1 状态文件
|
||||
|
||||
```text
|
||||
.claude/monitoring_alert_rollout_status.json
|
||||
```
|
||||
|
||||
记录内容包括：
|
||||
|
||||
- 当前 phase
|
||||
- 已完成 phase
|
||||
- last run
|
||||
- repair loop 状态
|
||||
- patch rounds
|
||||
- history
|
||||
|
||||
---
|
||||
|
||||
## 7.2 锚点文件
|
||||
|
||||
脚本还会维护：
|
||||
|
||||
- `SESSION.md`
|
||||
- `TASKS.md`
|
||||
|
||||
当前通过固定区块：
|
||||
|
||||
```text
|
||||
## Automation Status
|
||||
```
|
||||
|
||||
做结构化更新，而不是简单重复追加。
|
||||
|
||||
---
|
||||
|
||||
## 8. repair loop 的意义
|
||||
|
||||
当阶段验证失败时，脚本会生成两层信息：
|
||||
|
||||
### 8.1 next-step guidance
|
||||
给人类直接看：
|
||||
|
||||
- priority tasks
|
||||
- suggested files
|
||||
- suggested commands
|
||||
- reasoning
|
||||
|
||||
### 8.2 repair metadata
|
||||
给后续自动修复代理使用：
|
||||
|
||||
- `failure_class`
|
||||
- `recommended_focus`
|
||||
- `phase_patch_targets`
|
||||
- `phase_validation_entrypoint`
|
||||
- `repair_prompt_context`
|
||||
|
||||
---
|
||||
|
||||
## 9. repair-bridge JSON 协议
|
||||
|
||||
详见：
|
||||
|
||||
```text
|
||||
docs/AI_ICT_repair_bridge_protocol_v1.md
|
||||
```
|
||||
|
||||
### 9.1 stdin 输入
|
||||
脚本会给 repair agent 发一段 JSON，例如：
|
||||
|
||||
```json
|
||||
{
|
||||
"protocol_version": "repair-bridge/v1",
|
||||
"mode": "repair_loop",
|
||||
"phase": "N2",
|
||||
"phase_title": "最小主动消息告警闭环",
|
||||
"failure_class": "alert_dispatch_gap",
|
||||
"recommended_focus": "alert_delivery_and_dispatch",
|
||||
"phase_patch_targets": [
|
||||
"src/services/alerts/alert_dispatcher_service.py"
|
||||
],
|
||||
"validation_entrypoint": ".venv/bin/python scripts/run_alert_dispatcher.py",
|
||||
"repair_prompt_context": {
|
||||
"prompt_text": "..."
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 9.2 stdout 输出
|
||||
repair agent 应返回 JSON，例如：
|
||||
|
||||
```json
|
||||
{
|
||||
"protocol_version": "repair-bridge/v1",
|
||||
"status": "applied",
|
||||
"summary": "Implemented missing alert dispatcher module and updated runtime hook.",
|
||||
"changed_files": [
|
||||
"src/services/alerts/alert_dispatcher_service.py",
|
||||
"src/services/runtime/trading_runtime_service.py"
|
||||
],
|
||||
"notes": ["Focused on N2 alert delivery gap"],
|
||||
"success_guess": true,
|
||||
"tests_run": [
|
||||
".venv/bin/python scripts/run_alert_dispatcher.py"
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 10. 当前自动复验规则
|
||||
|
||||
repair agent 返回值会参与决策。
|
||||
|
||||
### 自动复验前提
|
||||
必须满足：
|
||||
|
||||
1. `MONITORING_ALERT_AUTO_RERUN_ENABLED=1`
|
||||
2. stdout JSON 可解析
|
||||
3. schema 合法
|
||||
4. `status in {applied, success, fixed}`
|
||||
5. `success_guess != false`
|
||||
6. `changed_files` 非空
|
||||
|
||||
---
|
||||
|
||||
## 11. 智能复验调度
|
||||
|
||||
脚本当前优先级：
|
||||
|
||||
### 优先级 1：有 `tests_run`
|
||||
如果 repair agent 已经给出 `tests_run`，优先执行这些命令。
|
||||
|
||||
### 优先级 2：没有 `tests_run`
|
||||
根据 `changed_files` 自动选 focused rerun：
|
||||
|
||||
- 改动 `src/services/alerts/` 或 `src/api/alerts.py`
|
||||
- 运行 `scripts/run_alert_dispatcher.py`
|
||||
- 改动 `src/services/runtime/` 或 `src/api/trading_runtime.py`
|
||||
- 运行 `scripts/run_trading_runtime.py`
|
||||
- 改动 `src/services/readiness/` / `src/web/` / `src/config/settings.py`
|
||||
- 运行 `scripts/run_launch_readiness.py`
|
||||
- 改动 `src/services/decision/` / `src/services/operator/`
|
||||
- 运行 `scripts/run_review_packet.py`
|
||||
- 如果改动全在 `docs/`
|
||||
- 跳过 focused rerun
|
||||
|
||||
然后再回到 `run-until-blocked` 做阶段判断。
|
||||
|
||||
---
|
||||
|
||||
## 12. patch round 历史
|
||||
|
||||
每次 repair bridge 现在都会记录 patch round，内容包括：
|
||||
|
||||
- 第几轮 repair
|
||||
- 本轮 `changed_files`
|
||||
- 本轮 `tests_run`
|
||||
- 本轮 `success_guess`
|
||||
- 本轮 `rerun_state`
|
||||
- 是否 `phase_advanced`
|
||||
|
||||
这些历史会写在状态文件的 `repair_loop.patch_rounds` 中。
|
||||
|
||||
---
|
||||
|
||||
## 13. 当前工具的实际定位
|
||||
|
||||
这套工具现在还不是完全通用的跨项目平台，它是：
|
||||
|
||||
> **为 `ai-exchange` 项目定制演化出来的自动化 orchestrator**
|
||||
|
||||
特点：
|
||||
|
||||
- 阶段定义写在脚本里
|
||||
- 验证命令写在脚本里
|
||||
- rerun 规则写在脚本里
|
||||
- 锚点文件是当前项目结构
|
||||
|
||||
所以目前最适合：
|
||||
|
||||
- 继续在本项目里使用
|
||||
- 一边推进，一边发现 bug 再修
|
||||
- 等经过更多实践验证后，再考虑抽通用模板
|
||||
|
||||
---
|
||||
|
||||
## 14. 实践建议
|
||||
|
||||
### 14.1 推荐日常顺序
|
||||
|
||||
```text
|
||||
1. run-until-blocked
|
||||
2. 如果 needs_work -> repair-loop
|
||||
3. 如果有 repair agent -> repair-bridge
|
||||
4. 自动复验
|
||||
5. 再看 status
|
||||
```
|
||||
|
||||
### 14.2 推荐先人工观察几轮
|
||||
虽然现在已经有自动修复桥接、自动复验，但仍建议：
|
||||
|
||||
- 先人工观察几轮
|
||||
- 看 repair agent 返回 JSON 是否稳定
|
||||
- 看 focused rerun 选择是否合理
|
||||
- 看 phase advance 是否符合预期
|
||||
|
||||
### 14.3 外部 repair agent 最好把调试日志写到 stderr
|
||||
这样 stdout 可以保持纯 JSON，更容易被脚本可靠解析。
|
||||
|
||||
---
|
||||
|
||||
## 15. 后续维护建议
|
||||
|
||||
如果后面发现 bug，优先检查：
|
||||
|
||||
1. `repair-bridge` stdout 是否是合法 JSON
|
||||
2. `changed_files` 是否真实反映改动
|
||||
3. `tests_run` 是否写成了脚本真实执行的命令
|
||||
4. 自动 focused rerun 是否选对了命令
|
||||
5. `SESSION.md / TASKS.md` 的 anchor block 是否被错误修改
|
||||
|
||||
---
|
||||
|
||||
## 16. 总结
|
||||
|
||||
这套工具当前已经具备：
|
||||
|
||||
- 阶段推进
|
||||
- 自动验证
|
||||
- run-until-blocked
|
||||
- repair loop
|
||||
- repair bridge
|
||||
- JSON 协议桥接
|
||||
- 智能复验
|
||||
- patch round 历史
|
||||
- 状态锚点写回
|
||||
|
||||
它已经足够作为：
|
||||
|
||||
> **当前项目内自动化流程的学习与实操工具**
|
||||
|
||||
后续先继续在本项目里实践，遇到 bug 再逐步修正，比现在就做通用模板更稳。
|
||||
Reference in New Issue
Block a user