docs: 文档治理2026-08-11——归档7份过时文档+57份研究过程文档,重写README,新增doc-audit核实报告

This commit is contained in:
xxm
2026-08-11 03:31:14 +08:00
parent d3990cc3b1
commit a5a0a46fe9
72 changed files with 267 additions and 18 deletions
+109
View File
@@ -0,0 +1,109 @@
# MoFin 系统架构
> 最后更新:2026-07-03
> 维护人:Sisyphus (小小莫) + Zhiwei (知微)
---
## 一、数据层
### 数据库
所有数据存储在 SQLite`/home/hmo/web-dashboard/data/mofin.db`
| 表 | 用途 | 写入方 |
|----|------|--------|
| `holdings` | 持仓列表 | price_monitor, import_holding_xls |
| `portfolio_summary` | 总资产/市值/仓位 | price_monitor, regenerate_all |
| `holding_strategies` | 策略/决策 | regenerate_all, server.py API |
| `watchlist_stocks` | 自选股 | price_monitor, regenerate_all |
| `cash_log` | 现金变更审计 | write_cash_log |
| `market_snapshots` | 大盘数据 | market_watch |
| `sector_snapshots` | 板块数据 | market_watch |
| `live_prices` | 实时价格快照 | price_monitor |
| `mtf_cache` | 多周期K线缓存 | multi_timeframe |
| `capital_flow_cache` | 资金流缓存 | capital_flow_collector |
| `price_events` | 价格触发事件 | price_monitor |
### 数据访问
- **读取**`mo_data.py``read_portfolio()` / `read_decisions()` / `read_watchlist()`
- **写入**`mofin_db.py``write_holdings_batch()` / `write_holding_strategy()` / `write_portfolio_summary()`
JSON 文件已全部移除(portfolio.json, decisions.json, watchlist.json 等)。
### 币种
| 品种 | 个股存储 | 汇总 |
|------|---------|------|
| 港股 | HKD (currency='HKD') | CNY (×汇率) |
| A股 | CNY (currency='CNY') | CNY |
`calc_total_assets()` 汇总时自动将港股 HKD 转 CNY。汇率由 `hk_rate.py` 实时获取。
---
## 二、核心模块
```
MoFin/
├── mo_models.py # 统一数据模型:calc_total_assets, is_hk_stock, to_cny
├── mo_data.py # 统一读取层:read_portfolio, read_decisions, read_watchlist
├── mofin_db.py # DB 层:建表 + 写函数 + 查询函数
├── mo_config.py # 配置单例
├── price_monitor.py # 价格更新(cron: */2 9-16 1-5
├── strategy_lifecycle.py # 策略生命周期(regenerate_all + quality gates
├── server.py # Flask Web API(端口 8899
├── market_watch.py # 大盘采集(cron: */30 9-15
├── market_screener.py # 全市场筛选(cron: */30 9-15
├── strategy_tree.py # 策略树/分支管理
├── strategy_evaluator.py # 策略评估
├── hk_rate.py # 港币汇率(API + 缓存)
├── multi_timeframe.py # 多周期K线分析
├── stock_profile.py # 个股画像
├── data_freshness.py # 数据新鲜度校验
├── system_audit.py # 系统审计
├── system_health_check.py# 系统健康检查
├── prompt_manager/ # LLM Prompt 管理
├── scripts/ # 工具/一次性脚本
└── docs/ # 文档
```
---
## 三、数据流
```
开盘 (9:00-16:00)
├── price_monitor (每2分钟)
│ ├── 东财/腾讯 API → 拉价格
│ ├── write_holdings_batch → holdings 表
│ └── write_portfolio_summary → portfolio_summary 表
├── market_watch (每30分钟)
│ └── write_market_snapshot → market_snapshots + sector_snapshots
├── market_screener (每30分钟)
│ └── 读 market_snapshots → 小果 LLM 筛选 → candidate_pool
└── stale_push_wlin (每30分钟)
└── 读持仓+决策 → 区间检测 → XMPP 推送
盘后
├── system_audit (17:30) → 全局审计报告
├── strategy_review (20:00) → 策略复盘
└── regenerate_all (手动/定时) → 全量策略重评
```
---
## 四、版本
| 版本 | 日期 | 关键变更 |
|------|------|---------|
| 5.0 | 2026-07-03 | JSON 彻底移除,纯 DB。币种修正(港股 HKD,汇总 CNY)。消除重复文件。 |
| 4.0 | 2026-07-01 | mo_data 统一读取层,cash_log 表 |
| 3.0 | 2026-06-30 | mo_models 统一数据模型,DSA 集成 |
| 2.0 | 2026-06-29 | 初始架构重构 |
+223
View File
@@ -0,0 +1,223 @@
# 莫荷系统架构文档 — 完整总览
> 最后更新:2026-06-11
> 维护人:莫荷(Hermes Agent
> 铁律:任何系统改动必须先读本文档,改完必须同步更新
---
## 一、系统总览
```
┌──────────────────────────────────────────────────────────────┐
│ Linux 192.168.1.246 │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 默认gateway │ │ 知微gateway │ │ 小果gateway │ │
│ │ :8642 │ │ :8643 │ │ :8645 │ │
│ │ 微信+XMPP │ │ position- │ │ xiaoguo │ │
│ │ mohe网关 │ │ analyst │ │ profile │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌─────────────────────────────────────────────────┐ │
│ │ state.db (SQLite) │ │
│ │ sessions / messages / FTS5 / compression_locks │ │
│ │ 消息存储:全量保存,永不删除 │ │
│ │ 上下文加载:最多200条,永不压缩 │ │
│ └─────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ xmpp_bot │ │ xmpp_ │ │ xmpp_ │ │
│ │ mohe │ │ zhiwei_bot │ │ xiaoguo_bot │ │
│ │ mohe@yoin │ │ zhiwei@yoin │ │ xiaoguo@ │ │
│ │ .fun │ │ .fun │ │ yoin.fun │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
│ └──────┬─────────┴────────┬───────┘ │
│ ▼ ▼ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │ ejabberd │ │ 内核组 │ │
│ │ Docker │ │ coregroup@ │ │
│ │ port 5222 │ │ conference │ │
│ └──────────────┘ │ .yoin.fun │ │
│ └──────────────┘ │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ 价格监控 │ │ cron调度器 │ │ Obsidian │ │
│ │ 1分钟·纯脚本 │ │ 14个jobs │ │ 知识库 │ │
│ └─────────────┘ └─────────────┘ │ :8890 │ │
│ └─────────────┘ │
└──────────────────────────────────────────────────────────────┘
│ │
▼ ▼
┌─────────────────┐ ┌─────────────────┐
│ Windows 192.168 │ │ Mac 192.168.1 │
│ .1.16 │ │ .122 │
│ 小小莫(wechat) │ │ 小果(oMLX) │
│ OpenCode :4096 │ │ Qwen3.6-27B │
│ 微信通道 :5801 │ │ :18003 │
└─────────────────┘ └─────────────────┘
```
## 二、Gateway 一览
| 端口 | 名称 | Profile | PID(当前) | 用途 |
|------|------|---------|-----------|------|
| 8642 | 默认gateway | 默认 | 1925504 | 微信小荷 + XMPP mohe |
| 8643 | 知微gateway | position-analyst | 1913506 | 知微分析 |
| 8645 | 小果gateway | xiaoguo | 1925602 | 小果Mac端 |
| 8646 | mohe gateway | mohe | 1620276 | mohe独立网关 |
每个gateway共用 `/home/hmo/hermes-agent/hermes_state.py` 里的 `get_messages_as_conversation()`**LIMIT 200硬截断**
## 三、XMPP Bot 架构
### 3.1 Bot 列表
| Bot | JID | 服务名 | 脚本路径 | 接入gateway |
|-----|-----|--------|---------|------------|
| 莫荷 | mohe@yoin.fun | xmpp-bot | /home/hmo/xmpp_bot.py | :8642 |
| 知微 | zhiwei@yoin.fun | xmpp-zhiwei | /home/hmo/xmpp_zhiwei_bot.py | :8643 |
| 小果 | xiaoguo@yoin.fun | xmpp-xiaoguo | /home/hmo/xmpp_xiaoguo_bot.py | :8645 |
### 3.2 连接管理(2026-06-11 修复)
**禁用** `auto_reconnect = True`(与手动重连环冲突,导致"Replaced by new connection"循环)
**禁用** `xep_0199` ping 保活(ejabberd不支持,导致ping超时→误判断线)
**重连机制**
- 主循环每15秒检查 `is_connected()`
- 断线后指数退避重连:1s → 2s → 4s → ... → 60s max
- 重连后自动重新加入 MUC(内核组 coregroup@conference.yoin.fun
**历史问题**
- 2026-06-08: bot断线后无法自动重连,session膨胀到3700条/26M tokens
- 2026-06-10: auto_reconnect导致10个重复连接
- 2026-06-11: 修复auto_reconnect冲突 + API key拼写错误
### 3.3 群聊规则
Bot只回复内核组中来自 `hmo``xxm` 的消息。私聊只回复 `hmo@yoin.fun`
## 四、Session 管理 —— 核心设计(2026-06-10 最终方案)
### 4.1 方案:硬截断200条 + 永不压缩
```python
# hermes_state.py → get_messages_as_conversation()
SELECT id, role, content, ...
FROM (
SELECT id, role, content, ...
FROM messages WHERE session_id = ?
AND active = 1
ORDER BY id DESC LIMIT 200 只取最近200条
) ORDER BY id ASC 按正序排回
```
### 4.2 Compression 配置(所有profile统一)
```yaml
compression:
enabled: false ← 永久关闭
threshold: 0.99
protect_last_n: 200
hygiene_hard_message_limit: 100000
```
### 4.3 效果
| 指标 | 之前 | 之后 |
|------|------|------|
| 每次请求token | 26M(全量加载) | ~22K200条) |
| 上下文窗口用量 | 2500% | 2.2% |
| 响应时间 | 10分钟+超时 | 10-20秒 |
| 内容丢失 | 压缩丢细节 | 永不丢失 |
| 旧消息可查 | 压缩后摘要 | 全量DB可搜 |
### 4.4 Session 列表(当前)
| Session ID | 消息数 | 用途 |
|-----------|--------|------|
| sisyphus | 9504 | 微信(旧session,已重建) |
| xmpp-mohe | 3705 | XMPP mohe(旧session |
| xmpp-mohe-v2 | ~200 | XMPP mohe(新sessionLIMIT 200 |
| xmpp-zhiwei | 2241 | 知微 |
| 20260610_090241_2235fb | ~900 | 当前CLI会话 |
## 五、Provider 链(2026-06-10 最终版)
| Agent | 默认 | Fallback 1 | Fallback 2 | Fallback 3 |
|-------|------|-----------|-----------|-----------|
| **我(CLI** | ocg-new | ocg-old | volcengine | - |
| **mohe gateway** | ocg-new | ocg-old | volcengine | - |
| **知微** | ocg-old | ocg-new | volcengine(cred池) | - |
| **小果** | volcengine | ocg-old | ocg-new | oMLX(本地Mac) |
**当前实际状态(2026-06-11):**
- ocg-new: ✅ 可用(当前会话走这个)
- ocg-old: ⚠️ 返回403但gateway cred pool缓存了有效key
- volcengine: ❌ 周配额已尽,6月15日周一恢复
## 六、SOUL.md 关键规则(2026-06-10 最终版)
位置:`/home/hmo/.hermes/profiles/default/SOUL.md`
### 沟通方式
- 对老爸:直接、不加修饰
- 反驳时:**必须带证据**(日志、数据、代码、截图)。不是为了显得聪明而反驳
- 听指令:用户明确说"闭嘴""停"时立即停止,不继续分析不解释
### 行动铁律 — 讲证据
1. 发现问题 → 2. 收集证据(至少两条独立证据) → 3. 验证假设 → 4. 只改对的 → 5. 改完验证
- 禁止猜根因、没有证据就动手、猜用户意图、多个改动同时做
### 授权边界
- ✅ 直接行动:读文件、查日志、搜知识库、分析数据、提建议
- ⚠️ 问清楚再做:改系统配置、重启服务、清数据、写文件
- ❌ 必须等批准:不可逆删除、修改API key、改provider链、清session
## 七、知识库(Obsidian
路径:`/home/hmo/Obsidian/`
HTTP API`:8890`(只读)
结构:
```
Obsidian/
├── raw/ — 原始资料(只追加只读)
├── knowledge/ — 加工笔记(tech/finance/ai/psychology/education/life
├── index.md — 全库索引
├── SCHEMA.md — 操作规则
└── log.md — 更新日志
```
## 八、MoFin 股票系统
详见 `EXPERT_SYSTEM_DESIGN.md`**`SELF_GROWTH_SYSTEM.md`**(自成长架构,2026-06-23新增),核心:
- 31个cron jobs(约22个交易日活跃)
- 四层循环架构:Sense → Respond → Adapt → Improve
- 价格监控每2分钟腾讯批量API + 分支评估
- XMPP中继推送报告
- 硬编码审计 + 分支剪枝 + 知识萃取等自成长机制
## 九、近期改动日志
### 2026-06-11
- LIMIT 200硬截断 + 关闭所有compression
- SOUL.md 最终版定稿
- XMPP bot重连逻辑修复(删除auto_reconnect + ping保活)
- API key typo修复(知微bot `hermess123``hermes123`
- 小果provider链:volc → ocg-old → ocg-new → oMLX
- 默认provider链:ocg-new → ocg-old → volcengine
### 2026-06-10
- 重建SOUL.md(讲证据+授权边界+责任闭环)
- 发现并清除orphaned compression flag
- 多个gateway反复重启,systemd服务冲突
- Windows wechat_agent API key不匹配
### 2026-06-09
- 知微SOUL新增对话识别规则
- position-analyst 启用压缩
- 价格监控全面改造(纯脚本+腾讯批量API)
+297
View File
@@ -0,0 +1,297 @@
# MoFin / TDX-Relay 协作文档
> 最后更新:2026-06-12
> 维护人:知微 + 小小莫(xxm)
> 铁律:任何 relay 相关改动必须先读本文档,改完必须同步更新
---
## 一、什么是 tdx-relay
tdx-relay 是小小莫(xxm)开发的 Windows 端通达信中继程序。
作用:通过 opentdx 协议直连招商证券 7727 扩展行情服务器,
为 MoFin 系统提供港股低延迟实时行情。
### 为什么需要它
原本 MoFin 的港股行情来源是腾讯 APIqt.gtimg.cn),
存在约 15 分钟延迟,对于盘中决策不够及时。
tdx-relay 将港股行情延迟从约 15 分钟降到接近实时(1~3 秒)。
---
## 二、系统架构
```
Windows 端(小小莫负责)
┌─────────────────────────────────────────┐
│ tdx-relay 项目 │
│ │
│ tdx_client.py │
│ └─ opentdx MacExtendedClient │
│ └─ 直连 招商证券 7727 扩展行情服务器 │
│ → 拉取 17 只港股实时行情 │
│ │
│ run_relay.py │
│ └─ 断线自动重连(5s/15s/30s 三次退避) │
│ └─ 推送 → POST /api/update/realtime │
│ │
│ start_tdx_relay.bat │
│ └─ 一键启动脚本 │
└───────────────┬─────────────────────────┘
│ HTTP POST (JSON)
Linux 端(知微负责)
┌─────────────────────────────────────────┐
│ MoFin 系统 (web-dashboard) │
│ │
│ server.py │
│ ├─ /api/update/realtime (POST) │
│ │ ← 接收 tdx-relay 推送的实时行情 │
│ │ → 更新 portfolio.json + watchlist │
│ │ → 写入 data_source = "tdx_relay" │
│ │ │
│ ├─ /api/relay/status (GET) │
│ │ ← 查询 relay 状态(在线/离线/时间) │
│ │ │
│ price_monitor.py │
│ └─ relay_active 检测 │
│ ├─ relay 在线 → 跳过港股腾讯API拉取 │
│ │ (保留 tdx-relay 的实时价不覆盖) │
│ └─ relay 掉线 → 回退腾讯 API 兜底 │
│ │
│ 数据文件 │
│ ├─ data/portfolio.json │
│ │ └─ 每只港股: data_source=txton/tdx │
│ ├─ data/watchlist.json │
│ └─ data/relay_state.json (新增) │
│ └─ online: true/false │
│ └─ last_ping: 时间戳 │
└─────────────────────────────────────────┘
```
## 三、职责边界
### 小小莫(xxm)— Windows 端
负责:
1. tdx_client.py 的开发维护
- 直连券商行情服务器的稳定性
- 港股代码列表的维护(当前 17 只)
- 行情数据的正确性验证
2. run_relay.py 的重连机制
- 断线自动恢复(3 次退避重连)
- relan 状态上报
3. 行情推送的稳定性
- 每 X 秒推送一次实时行情
- 推送失败的处理
4. Windows 端部署维护
- 开机自启动
- 日志管理
- 异常告警
不负责:
- MoFin API 的修改(但需要配合 server.py 新增端点)
- Linux 端 price_monitor 的回退逻辑
- 持仓分析和策略制定
### 知微(zhiwei)— Linux 端(MoFin
负责:
1. MoFin API 的 relay 兼容
- /api/update/realtime 端点(已实现)
- /api/relay/status 端点(待实现)
- relay_state 持久化(待实现)
2. price_monitor 的 relay 检测(待实现)
- relay 在线 → 跳过港股腾讯 API 拉取
- relay 掉线 → 回退腾讯 API 兜底
3. tdx-relay 接入后的数据一致性保障
- 腾讯 API 和 tdx-relay 的数据源标记区分
- 价格更新不互相覆盖
4. 行情来源对分析层的透明化
- 分析层(cron prompt)不需要关心行情来源
- 直接读 portfolio.json 即可
- 数据源标记在 data_source 字段中
不负责:
- Windows 端程序的开发和部署
- 通达信协议的细节
- 券商行情服务器的维护
### 共同维护
1. 港股代码列表 — 两边保持一致
2. 数据格式 — tdx-relay 推送的 JSON 格式与 MoFin 期望的格式
3. 接口联调 — 新端点上线后的验证
---
## 四、数据流详解
### 正常流程(relay 在线)
```
tdx-relay (Windows)
│ 每 X 秒推送 {stocks: [{code, price, change_pct, ...}]}
│ POST → http://192.168.1.246:8899/api/update/realtime
server.py 接收
├─ 更新 portfolio.json(港股 data_source = "tdx_relay"
├─ 更新 watchlist.json(港股 data_source = "tdx_relay"
└─ 更新 relay_state.jsononline=true, last_ping=now
price_monitor.py(每分钟运行)
├─ A股 → 腾讯 API(不变)
├─ 港股 → 检查 relay_state
│ ├─ relay 在线 → 跳过(保留 tdx-relay 的实时价)
│ └─ relay 离线(>60秒无推送)→ 回退腾讯 API
└─ 数据源标记 → 写入 portfolio/watchlist
```
### 异常流程(relay 离线)
```
tdx-relay 断线
│ 60秒内无推送
price_monitor.py 检测到 relay_state.online=false
│ 或 last_ping > 60秒前
├─ 港股 → 回退腾讯 API 拉取
├─ 写入时 data_source = "tencent"
└─ 记录日志 "relay offline, fallback to tencent"
tdx-relay 恢复
│ 推送到达 /api/update/realtime
server.py 接收更新
├─ 更新 relay_state.jsononline=true
└─ 正常接收行情
```
---
## 五、接口规范
### POST /api/update/realtime (已实现)
接收 tdx-relay 推送的实时行情。
请求格式:
```json
{
"stocks": [
{
"code": "00700",
"price": 467.20,
"change_pct": 3.09,
"high": 470.00,
"low": 460.00,
"open": 462.00,
"volume": 15000000
}
],
"source": "tdx_relay"
}
```
响应:
```json
{
"status": "ok",
"updated": 15,
"source": "tdx_relay",
"timestamp": "2026-06-12T14:30:00"
}
```
### GET /api/relay/status (待实现)
查询 tdx-relay 当前状态。
响应:
```json
{
"online": true,
"source": "tdx_relay",
"last_ping": "2026-06-12T14:29:55",
"age_seconds": 5,
"stocks_count": 15,
"fallback_active": false
}
```
---
## 六、当前实现状态
### 已完成(全部 ✅)
- server.py `/api/update/realtime` 端点 ✅
- server.py `/api/relay/status` GET 端点 ✅
- relay_state.json 持久化 ✅
- price_monitor.py relay_active 检测 ✅
- price_monitor 回退逻辑(relay 离线→腾讯 API 兜底)✅
- tdx-relay 心跳上报(每15秒推送)✅
- 断线自动重连(3次退避)✅
- 17只港股全量推送 ✅
- 数据层重构:JSON+SQLite 双写 + 消费者切 SQLite 优先 ✅
### 2026-06-20 数据层重构(小小莫完成)
**新增文件**
- `mofin_db.py` — 统一 SQLite 访问层(13张表 + 18个查询函数 + 4个写入函数)
- `migrate_all.py` — 一次性 JSON→SQLite 迁移脚本
- `mofin_query.py` — 通用查询工具
- `docs/DATABASE_ARCHITECTURE.md` — 完整架构文档
**修改文件**
- `market_watch.py` — JSON+SQLite 双写
- `multi_timeframe.py` — K线双写
- `price_monitor.py` — 价格事件双写
- `server.py` — SQLite 优先读取(/api/portfolio, /api/watchlist, /api/overview, /api/market
- `strategy_lifecycle.py` — SQLite 优先读取(stock_sector_map, market_context, holdings, watchlist
- `market_insight.py` — SQLite 优先读取
- `strategy_feedback.py` — SQLite 优先读取 price_events
- `system_health_check.py` — SQLite 优先读取 price_events
**设计原则**
- 所有消费者:SQLite 优先 → 失败回退 JSON,系统不中断
- 所有写入:JSON+SQLite 双写,SQLite 失败不影响 JSON 管道
- 迁移脚本幂等可重跑,JSON 文件不修改
---
## 七、港股代码列表(双方保持一致)
当前 17 只港股(来自 portfolio.json + watchlist.json):
| 代码 | 名称 | 持仓/自选 |
|------|------|----------|
| 00700 | 腾讯控股 | 持仓 |
| 00981 | 中芯国际 | 持仓 |
| 01211 | 比亚迪股份 | 持仓 |
| 09988 | 阿里巴巴 | 持仓 |
| 02202 | 万科企业 | 持仓 |
| 02388 | 中银香港 | 持仓 |
| 01478 | 丘钛科技 | 持仓 |
| 09868 | 小鹏集团 | 自选(已清仓) |
| 01088 | 中国神华 | 持仓 |
| 02359 | 药明康德 | 自选 |
| 01888 | 建滔积层板 | 自选 |
| 00968 | 信义光能 | 自选 |
| 01070 | TCL电子 | 自选 |
| 02318 | 中国平安 | 自选 |
| 02628 | 中国人寿 | 自选 |
| 06160 | 百济神州 | 自选(已清仓) |
| 06869 | 长飞光纤 | 自选 |
---
## 八、故障处理
| 现象 | 可能原因 | 处理方式 |
|------|---------|---------|
| relay 显示离线 | Windows 端掉线 | 检查 Windows 端运行状态,双击 start_tdx_relay.bat |
| relay 在线但数据不更新 | 推送异常 | 查 Windows 端日志,重启 tdx-relay |
| 港股价格异常 | 数据源错乱 | 检查 data_source 字段,确认 relay 是否覆盖了错误数据 |
| 港股价格用腾讯旧数据 | relay 离线超过 60s 自动回退 | 正常行为,relay 恢复后自动切回 |
+104
View File
@@ -0,0 +1,104 @@
## 2026-07-01 盘中自检:科创50跌3%HIGH信号分析
**事件:** 自愈执行器上报盘中宏观风险HIGH信号(科创50指数跌幅扩大至3%)
**原因分析:**
- 韩国政府计划设立智库利用芯片巨头超额利润的传闻引发半导体板块恐慌
- 三星电子一度跌超6%,SK海力士一度跌超5%,韩国KOSPI从+1.7%急跌至-4%
- 韩国产业通商资源部已紧急辟谣,KOSPI收窄至-0.87%
- 另一重因素:阳光电源崩跌近20%(光伏逆变器美国政策不确定性)
**市场状态(14:13):**
- 上证指数 +0.39%(大盘整体稳定)
- 科创50 -2.37%(已从-3%回升)
- 创业板指 -1.63%
**持仓影响:**
- 海博思创 -9.95%(距止损5.8%
- 长芯博创 -8.53%(距止损仅2.9%⚠️
- 中芯国际科创 -2.76%(距止损仅2.5%⚠️
- 中际旭创 -3.73%(距止损3.9%
- 均为高景气被动杀跌,按规则不动止损
**操作:** 已更新 macro_risk_state.json level从high降为medium,追加修正覆盖说明。无持仓操作建议。
**知识萃取:**
1. 韩国芯片巨头利税分配传闻是典型的「情绪性杀跌」——传闻已被辟谣,辟谣后指数快速回升。对A股科创板的影响主要通过半导体板块联动传导。
2. 科创50跌3%触发的HIGH信号本身是正确的——但需要结合消息面做上下文修正。这正是实时信号采集器(红绿灯)产生信号后需要LLM深度分析验证的原因。本次红绿灯正确捕捉到信号,LLM分析修正了级别。
3. 重仓科技股在情绪杀跌日不做止损调整——这是系统性应对规则的正确应用。长芯博创距止损仅2.9%也不应在恐慌日调宽,等1-2个交易日确认趋势。
## 2026-07-02 全球半导体冲击:韩国熔断+美股半导体暴跌4.4%
**事件:** 自愈执行器上报盘中宏观风险HIGH信号(韩国KOSPI-6%触发熔断+费城半导体-4.4%+日经-2%)
**原因分析:**
- Meta拟出租过剩算力(布局AI云业务)→ 市场解读为AI资本开支见顶 → 全球半导体板块抛售
- 费城半导体指数跌4.4%NVDA-3.2%/AMD-4.3%/ASML-4.1%/MRVL-7.7%
- 韩国KOSPI跌6%触发熔断(三星-7%/SK海力士-8%+ 日经225跌2%
- 微软6月跌20%/8个月市值蒸发1.3万亿
- **注意:这不是传闻,Meta已确认动向** — 与7月1日韩国芯片传闻有本质区别
**市场状态(09:30开盘):**
- 上证指数 -1.42%(有韧性,非全面崩溃)
- 科创50 -4.33%(半导体重仓指数暴跌)
- 创业板指 -2.94%
- 深证成指 -2.41%
**持仓影响(A股开盘):**
- 中际旭创(15.27%) 1160 -5.16% 距止损8%
- 中芯国际A(5.44%) 146.5 -5.17% 距止损7%
- 博创科技(3.2%) 241.3 -4.99% 距止损9%
- 法拉电子(2.3%) 172.6 -5.48% 距止损4%
- 海博思创(6.31%) 255 -3.0% 距止损8%
- 华恒生物(5.25%) 16.0 -2.26%
- 防御股验证:紫金矿业+2% 黄金ETF+1.86% 模塑科技+2.87%
**定性:** 全球半导体/AI叙事冲击(板块冲击B类,但严重程度接近系统性)
- 区别昨天:昨天是韩国传闻辟谣后快速修复,今天是真实事件(Meta确认)+ 韩国熔断
- A股上证仅-1.42%说明不是全面系统性下跌,资金在板块间轮动(半导体→黄金/资源)
**操作:**
- 已推送给Dad XMPP报告
- 高景气被动杀跌持仓不动止损
- 防御股保留
- 等待HK开市检查港股持仓
**知识萃取:**
1. **传闻 vs 真实事件的应对区别:** 7月1日是传闻(韩国芯片利润传闻,辟谣后快速修复),7月2日是真实事件(Meta确认出租算力+韩国熔断)。传闻日可预期修复,真实事件需3-5日观察趋势确认。两者触发相同的「不动止损」规则,但后续跟踪周期不同。
2. **韩国熔断的历史信号意义:** 韩国KOSPI触发熔断是极罕见事件(上一次在2020年3月新冠初期),熔断本身不代表长期趋势转折——2020年熔断后KOSPI在半年内涨超80%。熔断是流动性冲击的信号,不是基本面崩塌。
3. **科创板-4.33%开盘但上证仅-1.42%的结构性分化验证了三维分析框架的价值:** 不看单一指数结论。科创50暴跌但上证不崩、黄金上涨、宁德时代翻红——说明是科技板块轮动式下跌而非全面系统性风险。仅看科创50会误判为系统性。
## 2026-07-07 标准化操作建议流程(Dad强制要求)
**触发:** 腾讯盘中触止盈位,我直接给出「出半仓」建议。Dad 追问后才意识到港股每手100股不能拆半手,且系统策略信号是"持有"而不是卖出。
**根因:** 出操作建议前跳过了两个关键步骤:
1. 没有调 reassess_strategy() 获取系统策略判断(系统策略是持有,不是卖出)
2. 没有检查最小交易单位(港股每手=100股,100股=1手不能拆半)
**修改内容:**
1. 新建 `/home/hmo/.hermes/profiles/position-analyst/scripts/prepare_recommendation.py`
— 标准化前置流程脚本,调 reassess_strategy() + 检查交易约束 + 输出结构化 JSON
- 调用方式:`python3 prepare_recommendation.py {code} {price}`
- 输出:strategy(信号/止损/止盈) + trade_constraints(市场/最小手/可拆半手) + pnl(成本/盈亏%)
2. 更新盘前中监控 cron (62a2ba59f7ff) prompt — 加入三步标准化流程
3. 更新午后监控 cron (23adf24922b3) prompt — 加入三步标准化流程
**强制规则(以后所有推荐都走):**
三步流程:触发系统策略重评 → 检查交易约束 → 基于策略结果出推荐
禁止凭行情直接下结论。
## 2026-07-08 补建prepare_recommendation.py(实际文件缺失修复)
**发现问题:** 午后监控(13:35)运行时发现prepare_recommendation.py实际不存在——2026-07-07知识日志记录已"新建"但system_inventory.json引用的文件路径缺失。根因: 2026-07-07 session中仅记录了计划/写入意图但文件未实际落盘。
**修改内容:**
1. 实际创建 `/home/hmo/.hermes/profiles/position-analyst/scripts/prepare_recommendation.py`
- 调用per_stock_reassess.py获取策略信号(timing_signal/action_note/止损/止盈/RR)
- 自动识别市场(A股/港股/科创板)及最小交易单位(100/200)
- 对持仓股计算pnl(成本/盈亏金额/盈亏比例)
- 输出标准化JSON(strategy + trade_constraints + pnl)
- 已验证: 688981(科创板200股)→策略信号:买入但RR1.31<1.5降级+浮盈+22.57%
- 已验证: 01478(港股100股)→策略信号:弱势持有+浮亏-48.85%
2. 同时生成本日午后监控报告
+300
View File
@@ -0,0 +1,300 @@
# analyst-knowledge-log.md
## [2026-07-09 22:00] 全市场主力建仓扫描 + 五级过滤 + LLM九维分析
### 新增组件
| 组件 | 功能 | 调度 |
|------|------|------|
| `accumulation_scanner.py` | 全市场5207只A股量价异常扫描(每10分钟13秒) | `*/10 9-15` |
| `candidate_filter.py` | 五级过滤管道(S2量价/S3技术/S4资金/S5基本面) | `*/30 9-15` |
| `promote_candidates.py` | 自动提拔高分候选入自选 | `*/30 9-15` |
| `batch_reassess.py` | 批量LLM九维分析补全(逐只处理间隔15秒) | 一次性 |
### 系统架构变更
## [2026-07-10 11:42] 知微XMPP Bot离线自愈修复
### 发现
自愈执行器报告知微XMPP Bot离线。调查发现:
- Bot进程(PID 422464)被bash包装器手动启动,非systemd管理
- systemd xmpp-zhiwei.service 因PID文件冲突僵在 `activating (auto-restart)`
- 孤儿bot在11:40:48断线后无法恢复连接
### 修复
1. 杀死孤儿进程 `kill -TERM 422464`
2. 删除PID文件 `rm -f /home/hmo/.hermes/zhiwei_bot.pid /tmp/xmpp_zhiwei_bot.pid`
3. systemd自动重启,bot干净上线
4. 验证:presence available、加入coregroup、bridge正常
### 教训
bash包装器启动bot会绕开systemd管理,导致:
- systemd状态监测不准确(显示restarting而非running
- 孤儿进程断开后无法被systemd接管
- 已有 `xmpp-bot-infrastructure` skill 记录了孤儿进程陷阱,自愈系统可直接参考执行
自选统一:**
- 自选数据统一存储在 `holding_strategies(decision_type='自选策略')`
- `watchlist_stocks` 表已废弃(is_active=0
- `read_watchlist()` 改为从 `holding_strategies` 读取
**DB统一:**
- `~/.hermes/profiles/position-analyst/data/mofin.db` → 软链接 → `/home/hmo/MoFin/data/mofin.db`
**去小果化:**
- `xiaoguo_scanner` / `xiaoguo情感分析` / `xiaoguo信号消费` 全部停用
- 替代为 `accumulation_scanner.py`(纯数据驱动,0 LLM成本)
### 九维分析
`per_stock_reassess.py` 重评时自动调用LLM(gateway API)生成完整九维分析:
- 数据源全部随需随拉(腾讯API实时价/PE/市值 + DB大盘/基本面/消息)
- LLM输出信号+买入区间+止损止盈+仓位百分比
- 超时自动降级为代码生成
### 冷却期机制
- `per_stock_reassess`: `reassessed_at`追踪,交易时段1小时/非交易24小时
- `price_monitor` zone breach: `_can_push()` 同股同区间30分钟冷却
### 仓位规则
- 仅「买入」信号输出仓位建议
- 仓位公式:RR×大盘调整×品种调整,范围5%~20%
- 关注/观望/卖出信号仓位为空
### 数据清理
- DROP TABLE: stock_weekly, stock_monthly(无人读取的死表)
- DROP TABLE: portfolio_state(无人读写的僵尸表)
- holdings: 清除shares=0的5只持仓
- watchlist_stocks: 全部标记is_active=0(已迁移)
- **发现**: candidates表有15条历史候选数据但promoted=0的都被手动标记了dropped=1(超7天未更新)。自动推广管道从未实现。
- **修改**: 新建 `scripts/promote_candidates.py` — 扫描 candidates(promoted=0+dropped=0) → stock_quote验价 → write_holding_strategy → 标记promoted
- **新建cron**: 候选股自动推广-盘中(e415846d4fb6) | 0,30 9-15 * * 1-5 | no_agent | 静默模式
- **效果预期**: 新候选股在30分钟内自动进入自选+带策略,不再依赖LLM prompt
## [2026-07-09 10:40] 自愈执行器升级处理:KOSDAQ-4.1% HIGH信号
- **发现**: 自愈执行器上报盘中自检发现宏观风险HIGH(KOSDAQ-4.1% + 中信证券研报)
- **判断**: 系统无故障,已知市场条件延续。KOSDAQ-4.1%是昨日KOSPI暴跌的延续,非新事件。中信证券研报是采集器误报(正常行业研报)。
- **数据验证**: 中国各指数全面脱钩改善(上证-1.26%→+0.02%,恒生-0.51%→+1.69%,科创50+0.28%→+0.62%)。持仓止损距均>3%。
- **操作**: 标记已知状态,无需新推送。08:30 LLM深度分析已覆盖并修正。
- **涉及文件**: macro_risk_state.json(已由consumer更新为processed
## [2026-07-09 14:xx] 自愈执行器升级:信号堆积38条
- **发现**: 盘中自检触发「信号堆积: 38条未处理(需<30)」告警,自愈执行器无自动修复方案,升级到LLM处理
- **调查**: 38条为 xiaoguo 来源信号,属4h时效内积压。当前已完成消费(xiaoguo_signal_consumer每30分运行),积压自愈
- **监控盲区发现**: intraday_health_check.py 和 system_audit.py 均只监控 `source LIKE 'xiaoguo%'`,忽略 divergence_watch(80)、trend(46) 等来源的126条未处理信号
- **修复**: 两处均增加全量未处理查询,区分 xiaoguo 和其他来源分别报告
- **涉及文件**: scripts/intraday_health_check.py, scripts/system_audit.py, CHANGELOG.md
## [2026-07-09 14:xx] 自愈执行器升级:信号积压126条(divergence_watch/trend无consumer
- **发现**: 自愈执行器上报「其它来源信号积压: 126条未处理(divergence_watch/trend等无consumer)」
- **调查**: divergence_watch 80条全部未处理 — divergence_detector.py写入signal_news但已自写macro_divergence_state.jsonsignal_news仅归档副本。trend 46条未处理 — 废弃系统的死数据,summary为空
- **修复**: divergence_detector.py — INSERT时加processed=1(归档性质不需要consumer)。DB — 80条divergence_watch + 46条trend历史标记为processed。同步cron目录MD5一致
- **效果**: signal_news 1077条全量已处理,健康检查PASS,后续不会再次积压
- **涉及文件**: scripts/divergence_detector.py, data/mofin.db, CHANGELOG.md
## [2026-07-10 10:25] 自愈:知微XMPP Bot离线 — 孤儿进程阻塞systemd
- **发现**: 盘中自检报警「知微XMPP Bot离线」,TODO 83 created(无fix_action,升级到LLM处理)
- **调查**:
- systemd `xmpp-zhiwei.service` 陷入无限重启循环(重启计数器110+)
- 根因:外部bash wrapper脚本在10:04启动了一个孤儿bot进程(PID 252975),该进程占用了`/tmp/xmpp_zhiwei_bot.pid`和端口5805
- systemd每次尝试启动都因PID检查`xmpp_zhiwei_bot already running (PID 252975), exiting.`而退出
- 实际上PID 252975的bot是正常运行的(已加入群聊coregroup,HTTP桥5805正常响应),只是不受systemd管理。wrapper触发源不明(可能自愈系统之前的升级操作)
- **修复**:
1. `kill -TERM 252975` 杀掉孤儿进程
2. 清理旧PID文件 `/tmp/xmpp_zhiwei_bot.pid``/home/hmo/.hermes/zhiwei_bot.pid`
3. systemd 10秒RestartSec后自动启动新实例
4. TODO 83 标记为completed
- **验证**: systemd active(running) since 10:25:43bot加入群聊coregroup就绪,gateway health okHTTP桥5805正常
- **效果**: systemd恢复管控bot,重启循环归零
- **涉及文件**: /home/hmo/xmpp_zhiwei_bot.py (PID_FILE机制)
## [2026-07-13] XMPP Bot非阻塞修复 + 深套股规则重构 + 换股规划
### XMPP Bot修复
- **问题1**: bot调用gateway同步等600秒,阻塞事件循环 → XMPP心跳发不出 → 被踢下线 → 重试→turn堆积→更慢
- **修复**: 45s短超时 + "处理中"预回复 + 后台300s轮询 + 不再阻塞心跳
- **问题2**: 远程XMPP服务器(120.78.123.183:5222)网络不通,bot连不上
- **修复**: bot.connect(host='127.0.0.1', port=5222) 改连本地XMPP代理
- **问题3**: xep_0045 MUC插件未注册导致崩溃
- **修复**: __init__加 self.register_plugin('xep_0045')
- **涉及文件**: /home/hmo/xmpp_agent_core.py
### price_monitor通知噪音修复
- **问题**: _push_cooldown 是内存dictprice_monitor每2分钟新进程运行 → cooldown每次重置 → 同股同区间反复推送
- **修复**: cooldown持久化到 /home/hmo/.hermes/.price_push_cooldown.json
- **涉及文件**: scripts/price_monitor.py
### 深套股规则重构(Dad铁律确认)
- **删除**: `is_deep_loss` 对止损/止盈/买入区/质量检查的全部6处guard
- **删除**: `action_note="深套持有"` 强制覆盖
- **删除**: `position_advice="不补不割"` / `time_horizon="长期"`
- **保留**: `stock_category="深套"` 仅作标签
- **原则**: 一切根据客观判断,该加就加该割就割
- **涉及文件**: scripts/strategy_lifecycle.py
### 换股规划功能
- `python3 strategy_lifecycle.py swap-plan [--need 金额]`
- 五维评分: 亏损程度25% + 仓位20% + 技术趋势25% + 流动性15% + 前景15%
- 按评分排序输出可替换优先级,--need 参数自动计算卖几只够
- **涉及文件**: scripts/strategy_lifecycle.py
### 技术分析增强
- weekly/monthly趋势/MA/支撑阻力注入mtf_context
- 健康Tab写无读警告从3个归零(stock_weekly/monthly/watchlist_log加manual_readers
- 每日汇总只发一次(16:35 + sent标记防重复)
- cron_health_monitor新增数据实体完整性检查
- 涉及文件: scripts/technical_analysis.py, scripts/strategy_lifecycle.py, scripts/mofin_health.py, scripts/cron_to_xmpp.py, scripts/cron_health_monitor.py
## 2026-07-14 — 系统检查:Dad未收到任何消息的诊断
### 发现问题
1. **cron_to_xmpp.py Bug**: body提取`content.split("## Response")``parts[1]`取到的是skill内容中的 ## Response(第一个),而不是agent实际回复的 ## Response(最后一个)。导致开盘简报等LLM报告的正文取错,被误判为[SILENT]静默拦截。
2. **price_monitor.py SQLite写锁死锁**: 多个cron脚本(price_monitor + mofin_health等)同时BEGIN IMMEDIATE写 mofin.db,进程卡在D状态,WAL文件膨胀到2.7MB,后续全部超时。
3. **mofin_db.py版本不同步**: cron版本和MoFin版本有差异(cron版本多了保留full_analysis/reassessed_at的代码)。
### 修改了什么
- `cron_to_xmpp.py` — 改 `parts[1]``parts[-1]`(取最后一个Response节)
- `mofin_db.py` (MoFin目录) — 同步cron版本的reassessed_at列处理和full_analysis保留逻辑
- `price_monitor.py` — 添加debug时序追踪,临时kill D状态进程+WAL checkpoint
- `.silent_daily_count.json` — 纠正静默计数(-1因为开盘简报被误拦)
### 文件
- Modified: /home/hmo/.hermes/profiles/position-analyst/scripts/cron_to_xmpp.py
- Modified: /home/hmo/MoFin/scripts/mofin_db.py
- Modified: /home/hmo/.hermes/profiles/position-analyst/scripts/price_monitor.py
## 2026-07-14 — price_monitor DB写锁死锁根治(跟进修复)
### 发现问题
上次诊断只做了临时修复(kill D状态进程 + WAL checkpoint),Dad要求直接根治。
### 修改了什么(三副本同步)
- **price_monitor.py** (profile/scripts): 统一 BEGIN IMMEDIATE 包裹所有写操作,替代调用 write_holdings_batch/write_portfolio_summary/write_live_prices。5次重试+指数退避(1s→2s→4s→8s→16s)。重试耗尽后自动 emergency WAL checkpoint。try/except 确保 conn 始终释放。
- **MoFin/scripts/price_monitor.py** — 同步修复
- **MoFin/price_monitor.py** — 同步修复(保留其 cash_log 优先的现金读取逻辑)
- **CHANGELOG.md** — 新增2026-07-14条目
### 文件
- Modified: /home/hmo/.hermes/profiles/position-analyst/scripts/price_monitor.py
- Modified: /home/hmo/MoFin/scripts/price_monitor.py
- Modified: /home/hmo/MoFin/price_monitor.py
- Modified: /home/hmo/MoFin/CHANGELOG.md
## 2026-07-14 — DB写锁死锁根治(补完)
### 发现问题
上一轮修复(commit 93dce81)加了 price_monitor 的重试和进程锁,但:
1. mofin_db.py 的 get_conn() 没有在连接时自动清理 WAL,被 kill 的进程残留 WAL 仍会卡死后续连接
2. 其他并发写脚本(market_watch, mofin_health 等)没有重试保护
3. price_monitor 的 os.nice 缺失,高优先级抢占 DB 锁
### 修改了什么
- mofin_db.py get_conn(): 每次连接时 `PRAGMA wal_checkpoint(TRUNCATE)` 自动清理残留 WAL
- price_monitor.py run_once(): 加 `os.nice(10)` 降低优先级
- 其他并发脚本:通过 get_conn() 的 WAL checkpoint 间接保护 + busy_timeout=30s 兜底
### 效果预期
- 任何进程被 kill 后,下一个连接的脚本自动 checkpoint 清理 WAL,不会卡死
- price_monitor 进程锁防止同一脚本并发
- priority 降低减少恶性抢占
## 2026-07-14 10:55 — DB死锁根治:盘中脚本统一get_conn()
### 发现问题
price_monitor.py的`refresh_data_prices()`已有完善的重试机制(5次+指数退避+WAL checkpoint),但其他盘中高频脚本仍然使用raw `sqlite3.connect()`,绕过`get_conn()`的WAL模式+busy_timeout=30s设置。
### 修改了什么
- `mofin_health.py` — get_db_stats()改get_conn()
- `cron_health_monitor.py` — price_monitor新鲜度查询改get_conn()
- `intraday_health_check.py` — 3处sqlite3.connect全部改get_conn()
- `self_todo_executor.py` — sqlite3.connect改get_conn()
- `mofin_db.py` — get_conn()每次新建连接时WAL checkpoint
### 测试结果
并发压力测试:3x price_monitor + 3x mofin_health同时运行 → 6/6通过,WAL仅32bytes
### 文件
- Modified: /home/hmo/MoFin/mofin_db.py
- Modified: /home/hmo/MoFin/scripts/cron_health_monitor.py
- Modified: /home/hmo/MoFin/scripts/intraday_health_check.py
- Modified: /home/hmo/MoFin/scripts/mofin_health.py
- Modified: /home/hmo/MoFin/scripts/self_todo_executor.py
- Modified: /home/hmo/.hermes/profiles/position-analyst/scripts/ (同上5文件)
- Commit: 59e94d1, pushed to origin/master
## 2026-07-14 10:55 — 知微XMPP Bot断线不重连修复
### 发现问题
自愈执行器发现知微XMPP Bot离线。调查发现:
1. Bot进程(3643320)由gateway产生,但无任何TCP连接(断线后slixmpp不会自动重连,因为`auto_reconnect`默认关闭)
2. systemd的xmpp-zhiwei.service有2276次失败重启记录(PID文件冲突)
3. Bot进程(3643320)始于04:28presence=unavailable,但HTTP桥(5805)仍活着
### 根因
slixmpp ClientXMPP的`auto_reconnect`属性默认为False。断线(connection_lost)发生后,bot进程保持运行(HTTP桥继续工作)但从不尝试重新连接XMPP。在main()中`await bot.ready.wait()`已通过,asyncio.gather继续运行,bot看起来活着但实际上无法接收/发送XMPP消息。
### 修改了什么
- `/home/hmo/xmpp_agent_core.py`:
1. AgentBot.__init__()加 `self.auto_reconnect = True`
2. 新增 `connection_watchdog()` 看门狗协程——每15秒检查连接状态,断线超过120秒执行`os._exit(1)`让gateway重新spawn
3. main()启动connection_watchdog作为独立任务
### 执行了什么
1. Kill旧bot(3643320) → gateway自动spawn新bot(114609) → 新bot连接XMPP成功但被ejabberd重启踢下线
2. Kill中间bot(114609) → gateway再spawn(122594) → 稳定连接
3. Kill 122594后gateway spawn新bot(131908)加载修复代码,自动重连生效
4. Stop systemd xmpp-zhiwei.service2276次失败重启,不再需要,由gateway管理bot)
5. 清理PID文件 /tmp/xmpp_zhiwei_bot.pid
### 效果预期
- 断线后slixmpp自动重连(最快5s,指数退避)
- 看门狗兜底:120秒未恢复则进程退出→gateway respawn
- systemd不再干扰(已stopgateway管理bot生命周期)
### 文件
- Modified: /home/hmo/xmpp_agent_core.py
- Stopped: systemctl stop xmpp-zhiwei.service (2276失败重启)
## [2026-07-14 11:00] divergence_detector 修复 — 改用新浪API直取指数数据
### 发现问题
- divergence_detector.py 的 `fetch_indices()` 使用 `mo_data.get_prices_batch()` 获取指数行情
-`mo_data` 仅支持个股代码,不支持指数代码(sh000001/hkHSI等)
- 导致 `get_prices_batch()` 返回空字典 → `fetch_indices()` return {} → main() 提前返回
- 后果:macro_divergence_state.json 自2026-07-08起连续6天未更新
### 修复内容
- **文件**: `scripts/divergence_detector.py` (MoFin + profile副本已同步)
- **修改**: 重写 `fetch_indices()`,从 mo_data 调用改为直接调用新浪API(hq.sinajs.cn)
- **细节**:
- 8个指数用sina_map映射到新浪API的代码格式
- A股指数解析 fields[3] 为 change_pct
- 港股指数解析 fields[8] 为 change_pct(之前写错了 index=7,误读为涨跌额)
- **清理**: 移除不再使用的 `from mo_data import get_price, get_prices_batch`
- **commit**: d972553
### 验证
- divergence_detector.py 手动运行正常输出
- macro_divergence_state.json 已更新到 2026-07-14 11:07,包含8个指数实时数据
- state 自动检测到科创50(-4.2%) vs 恒指(-0.7%) MEDIUM背离信号
## [2026-07-21 11:50] 小果误报清理——盘中自检脚本消除残留引用
### 发现问题
自愈执行器持续报"小果Gateway :8645 未监听"——小果已全线归档,此为残留引用导致的误报。
### 修改内容
- `/home/hmo/MoFin/scripts/intraday_health_check.py`: 用 deploy 版本的干净副本覆盖(移除 check_xiaoguo() 函数、xmpp-xiaoguo.service 检测、8645端口检测、xiaoguo信号堆积检测)
- DB中残留的TODO ID 125/126 已resolve为completed
### 根因
MoFin重构(2026-07-20)时 deploy/profile-scripts/ 已更新但 scripts/ 中源文件未同步,盘中自检写入了小果相关的TODO后,自愈执行器持续处理这些积压TODO。
### 验证
- 运行版本(profile-scripts/)与deploy版本一致,小果引用为零
- DB中小果相关pending/in_progress TODO已清空
+162
View File
@@ -0,0 +1,162 @@
# decisions.json → SQLite 数据库迁移需求
> **✅ 已完成 (2026-07-03)** — 全部迁移到 `holding_strategies` 表。
> decisions.json 不再被任何代码读写。详见 CHANGELOG.md。
## 背景
当前系统所有策略数据存在 `/home/hmo/web-dashboard/data/decisions.json`,一个约 50~60 条策略的 JSON 文件。
## 现状痛点
| 问题 | 举例 |
|------|------|
| 没有写入锁,并发写会损坏 | price_monitor + per_stock_reassess 同时写,JSON 截断 |
| 币种字段不统一 | 港股 price 曾经存 HKD 也存过 CNY,修了几轮才用 currency 标记 |
| 缺乏 schema 校验 | 空字段、类型错误(str 写成了 int)无声失败 |
| 无 changelog 审计 | 谁在什么时候改了哪个字段,查不了 |
| 没有事务回滚 | 写一半 crash,整个文件废了 |
| 只能全量读 | 50 条策略每次全部加载,浪费 token |
| 各脚本自拉价格 | stale_detector 拉一次腾讯 APIper_stock_reassess 又拉一次 |
## 需求目标
**单线程写入 / 多线程安全读**
将 decisions.json 迁移到 `mofin.db`(已有该数据库),建 `strategies` 表。
## 表结构
```sql
CREATE TABLE strategies (
code TEXT PRIMARY KEY, -- 股票代码,如 "00700"
name TEXT NOT NULL, -- 股票名称
type TEXT DEFAULT '自选策略', -- 持仓策略 / 自选策略
status TEXT DEFAULT 'active', -- active / updated / stale
currency TEXT DEFAULT 'CNY', -- CNY / HKD。港股固定 HKD
-- 价格与仓位
price REAL, -- 最新价格(原始币种,港股=HKD,A股=CNY)
price_cny REAL, -- 折算为人民币的价格(统一口径用)
cost REAL, -- 持仓成本(有持仓时)
shares INTEGER, -- 持仓股数
share INTEGER, -- 同 shares,历史遗留字段
-- 策略参数
entry_low REAL, -- 买入区间下沿(原始币种)
entry_high REAL, -- 买入区间上沿(原始币种)
stop_loss REAL, -- 止损价
take_profit REAL, -- 止盈/目标价
stop_loss_cny REAL, -- 止损(人民币,统一口径用)
take_profit_cny REAL, -- 止盈(人民币)
rr_ratio REAL, -- 盈亏比
timing_signal TEXT, -- 短词信号:买入/加仓/持有/观望/冷却中
-- 来源与状态
trigger_reason TEXT, -- 策略生成原由
created_at TEXT, -- ISO时间
updated_at TEXT, -- 最后更新时间
reassessed_at TEXT, -- 最近一次重评时间
action TEXT, -- 最新操作摘要文本
-- JSON 嵌套字段(存为 TEXT,应用层 JSON parse
analysis TEXT, -- JSON: 分析详情
trigger TEXT, -- JSON: 触发条件
changelog TEXT, -- JSON: 变更历史数组
signal_factors TEXT, -- JSON: 因子列表
tech_snapshot TEXT, -- JSON: 技术面快照
action_note TEXT, -- 长文本动作说明
sector_context TEXT -- 行业上下文
);
```
### 为什么不全部展开成列
analysis 和 trigger 有嵌套结构且未来可能加字段。存 JSON 字符串,应用层 parse。查询止损/止盈用 `json_extract()`
## 读写接口需求
### 写操作(高频,每 2 分钟)
price_monitor 每轮更新所有持仓 + 自选的价格:
```sql
INSERT INTO strategies (code, price, price_cny, currency, updated_at)
VALUES (?, ?, ?, ?, ?)
ON CONFLICT(code) DO UPDATE SET
price = excluded.price,
price_cny = excluded.price_cny,
updated_at = excluded.updated_at;
```
价格更新不涉及其他字段。港股:price=HKDprice_cny=HKD×汇率。
A股:price=price_cny。
### 写操作(低频,策略重评时)
per_stock_reassess 跑完单股重评后更新全部策略参数:
```sql
UPDATE strategies SET
entry_low = ?, entry_high = ?, stop_loss = ?,
take_profit = ?, rr_ratio = ?, timing_signal = ?,
stop_loss_cny = ?, take_profit_cny = ?,
currency = ?,
analysis = ?,
trigger = ?,
reassessed_at = ?,
changelog = json_insert(changelog, '$[#]', ?)
WHERE code = ?;
```
### 读操作(各报告脚本)
所有 LLM cron、no_agent 脚本统一从 `strategies` 表读,不再拉腾讯 API
```sql
SELECT * FROM strategies WHERE status = 'active' ORDER BY code;
```
按币种过滤:
```sql
SELECT * FROM strategies WHERE currency = 'HKD';
```
读某只具体股票:
```sql
SELECT * FROM strategies WHERE code = '00700';
```
## 不变的输出
1. **保留 decisions.json 同步输出**(过渡期 2 周)。每次写 DB 后,同步写一份 decisions.json 给旧脚本兼容。
2. **输出格式不做大改**。JSON decode analysis/trigger 后保持现有字段名。
## 不允许的行为
1. ❌ 各脚本自行拉腾讯 API 获取价格。价格入口只有 price_monitor。
2. ❌ 直接写 decisions.json。全部走 DB。
3. ❌ 变更 decisions.json 的输出字段名/格式(过渡期兼容)。
## 验收标准
1. `strategies` 表有数据,decisions.json 和 `SELECT * FROM strategies` 内容一致
2. price_monitor 跑一轮后 DB 里的 price 更新正确(港股 HKDA 股 CNY)
3. per_stock_reassess 跑完单股后 DB 里对应股票策略更新
4. stale_detector 从 DB 读数据,输出和从 JSON 读一样
5. 并发读写(price_monitor 2min + stale_detector 同时跑)不损坏数据
6. 迁移后旧 decisions.json 仍同步更新
## 相关文件路径
| 文件 | 说明 |
|------|------|
| `/home/hmo/MoFin/price_monitor.py` | 价格监控,每2分钟写price |
| `/home/hmo/MoFin/scripts/strategy_lifecycle.py` | 策略生命周期,reassess_strategy() |
| `/home/hmo/MoFin/scripts/per_stock_reassess.py` | 单股重评入口 |
| `/home/hmo/MoFin/scripts/stale_push_wlin.py` | 自选买入提醒 |
| `/home/hmo/web-dashboard/data/decisions.json` | 当前JSON文件 |
| `/home/hmo/MoFin/data/mofin.db` | 目标数据库(已有market/trend等表) |
## 联系人
有问题问 hmo(老爸)。笑笑负责代码实现,测试完成后通知老爸验收。
+251
View File
@@ -0,0 +1,251 @@
# 全市场潜力股挖掘系统
## 概述
全自动管道:盘中每15分钟采集全市场数据 → 检测异动 → 搜新闻分析 → 我判断 → 出推荐。
所有数据存入 `mofin.db`SQLite),统一供 Dashboard 市场模块展示。
---
## 一、时序总览
```
交易日,每15分钟一轮,覆盖沪深A股+港股
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
上午:
9:25 采集链(75秒)+ 我判断 + 推报告 ← A股集合竞价完毕+港股已交易1.5h
9:40
9:55
10:10
10:25
10:40
10:55
11:10
11:25
11:40 ⚡ A股休市,港股交易中
11:55 ⚡ 同上
下午:
13:05
13:20
13:35
13:50
14:05
14:20
14:35
14:50
15:05
15:20
15:35
15:50 ← 最后一轮(港股收市前10分钟)
每天21轮。12:10-12:55午休跳过。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
每轮流程(全部在一个cron内完成,~2-3分钟):
① market_watch → 拉90个行业板块数据
② trend_detector → SQL检测17种信号
③ mofin_news → 搜新闻(原文入库)
④ 我(知微)→ 判断信号 → 更新候选池 → 推报告/紧急消息
```
---
## 二、数据采集(:43no_agent
### market_watch.py
拉同花顺90个行业板块,写入 `mofin.db`
**market_snapshots**(每次一条):
| 字段 | 说明 |
|------|------|
| timestamp | 采集时间 |
| source | ths / eastmoney |
| up_ratio | 上涨板块占比(%) |
| mood | bullish / neutral / bearish |
**sector_snapshots**(每条一个板块,关联 snapshot_id):
| 字段 | 说明 |
|------|------|
| name | 板块名,如"半导体" |
| change_pct | 涨跌幅(%) |
| up_count / down_count | 上涨/下跌家数 |
| net_inflow | 资金净流入(亿) |
| lead_stock | 领涨股名 |
| lead_stock_change | 领涨股涨跌幅 |
---
## 三、趋势检测(:45no_agent
### trend_detector.py
读取最新 snapshot,检测17种信号,写入 `sector_signals` 表。
按5类维度划分:
**A. 资金流信号**
| 信号 | 逻辑 | 严重性 |
|------|------|--------|
| A1 资金异动 | 单次净流入/出 > 近10次均值 + 3σ | high(>5σ) / medium(3-5σ) |
| A2 持续资金流入 | 连续≥3次净流入且逐次递增 | low |
| A3 持续资金流出 | 连续≥3次净流出且逐次扩大 | low |
| A4 资金转向 | 净流入从正转负或负转正 | medium |
**B. 涨跌结构信号**
| 信号 | 逻辑 | 严重性 |
|------|------|--------|
| B1 涨跌比反转 | 上涨占比变化 > 30个百分点 | medium |
| B2 持续走强 | 连续≥3次涨幅排全市场前10 | low |
| B3 持续走弱 | 连续≥3次跌幅排全市场前10 | low |
| B4 普涨背离 | 涨 > 3% 但上涨家数 < 50% | medium |
| B5 极端分化 | 涨跌家数比 > 5:1 或 < 1:5 | medium |
**C. 领涨/成分股信号**
| 信号 | 逻辑 | 严重性 |
|------|------|--------|
| C1 领涨股更替 | 领涨股与前2次采集不同 | medium |
| C2 领涨股极端涨幅 | 领涨股单次涨跌幅 > 15% | medium |
**D. 趋势拐点信号**
| 信号 | 逻辑 | 严重性 |
|------|------|--------|
| D1 趋势反转(多→空) | 连续≥3次净流入后突然转流出 | high |
| D2 趋势反转(空→多) | 连续≥3次净流出后突然转入流 | high |
| D3 量价背离(涨) | 涨 > 2% 且资金净流出 > 均值2倍 | medium |
| D4 量价背离(跌) | 跌 > 2% 且资金净流入 > 均值2倍 | medium |
**E. 关联信号**
| 信号 | 逻辑 | 严重性 |
|------|------|--------|
| E1 板块轮动 | 前次TOP3全部跌出前10 | medium |
| E2 产业链联动 | 同产业链多板块同时触发A/B/D类 | low |
| E3 持仓关联 | 持仓股所在板块触发任何high信号 | high |
写入 `sector_signals` 时附带:
- related_stocks — 该板块的领涨股 + 成分股(从 stock_sectors 查)
- holdings_in_sector — 该板块中的持仓股(查 holdings 表)
- watchlist_in_sector — 该板块中的自选股(查 watchlist_stocks 表)
---
## 四、新闻采集(:48no_agent
### mofin_news.py
读取未处理 signal(每次1条),用 akshare 搜新闻:
- 搜索范围:领涨股 + 成分股 + 持仓股 + 自选股
- 去重后取前5篇,含标题 + 正文全文
- 写入 signal_news,标记「待知微判断」
**不做情感分析,不调LLM。** 新闻分析由知微在下一轮cron中完成。
| 字段 | 说明 |
|------|------|
| signal_id | 关联 sector_signals |
| overall_sentiment | 总体情感(利好/利空/中性) |
| summary | 汇总摘要 |
| key_articles | JSON [{title, sentiment, summary}] |
| searched_stocks | 本次搜了哪些股票 |
**节流规则:** 同一板块同一signal类型24小时内已有 → 跳过。无未处理 signals → 本轮跳过。
---
## 五、知微判断与决策(:00/:15/:30/:45LLM cron
盯盘 cron prompt 中包含信号处理逻辑。
### 5.1 处理流程
```
进入盯盘 cron 后:
────────────────────────────────────────
1. 读最近15分钟的 signal_news(高严重性优先)
2. 逐条判断:
├── severity=high 且 sentiment=利空
│ → 检查持仓中是否有该板块个股
│ → 有 → 推老爸(风险预警)
│ → 无 → 记入待观察
├── severity=high 且 sentiment=利好 且置信
│ → 查腾讯API实时价
│ → 判断入场条件是否成熟(现价在合理区间)
│ ├── 可操作 → 给星级+策略 → 插入candidates
│ │ → 同时加入 watchlist_stocks 表(自动入自选)
│ │ → 推老爸(今日推荐)
│ └── 需等待 → 标记待观察,记录入场条件
└── severity=medium/low
→ 累积,收盘汇总
3. 照常做持仓/自选盯盘输出
如果本轮有紧急推荐,单独推一条消息;盯盘报告里不加额外篇幅
```
### 5.2 推送给老爸的规则
只在以下情况才推:
| 情况 | 推送内容 | 渠道 |
|------|---------|------|
| 持仓股板块出现利空 | 风险预警+建议操作 | 立即推 |
| 发现高置信潜力股,现价在买入区内 | 推荐+星级+入场策略 | 立即推 |
| 常规盯盘报告 | 三段式600字以内 | 定时走cron |
### 5.3 自动加入自选
当确认一只新的潜力股(不在持仓且不在自选)时:
- 写入 candidates 表
- 同时 INSERT INTO watchlist_stocks
- 这样 Dashboard 自选模块和策略引擎都能看到
---
## 六、收盘后处理(16:00LLM cron
盘中每轮已经完成了判断和推送。16:00额外一轮主要是做**知识萃取**:
- 回顾当日所有 signals + 判断记录
- 提炼可复用的判断经验 → 写入 analyst-knowledge-log.md
- 供后续分析参考
---
## 七、数据库表
### 市场信号相关表
| 表 | 用途 | 关键字段 |
|----|------|---------|
| market_snapshots | 每次采集元信息 | id, timestamp, up_ratio, mood |
| sector_snapshots | 板块快照 | snapshot_id, name, change_pct, net_inflow |
| sector_signals | 检测到的异常信号 | type, sector, severity, related_stocks, processed |
| signal_news | 小果情报分析 | signal_id, overall_sentiment, summary, key_articles |
| candidates | 候选池 | code, zhiwei_star, promoted, dropped |
| candidate_score_history | 评分变更历史 | code, score, source, created_at |
### 自选自动写入
新确认的潜力股自动写入 `watchlist_stocks` 表,Dashboard 自选模块即时可见。
---
## 八、Dashboard 市场模块展示
mofin.db 中的所有数据直接在 Dashboard 上展示:
| Dashboard 页面 | 数据源 | 刷新频率 |
|---------------|--------|---------|
| 行业热点 | market_snapshots + sector_snapshots 最新一次 | 每15分 |
| 知微洞察 | signal_news(当日汇总) | 每15分 |
| 潜力股挖掘 | candidateszhiwei_star 非空) | 实时 |
| 自选股 | watchlist_stocks | 实时 |
+78
View File
@@ -0,0 +1,78 @@
# 小果独立扫描线 — 全市场主动发现
## 概述
不依赖趋势信号触发,小果自己盯着各种排行榜,主动发现可能有料的股票,搜新闻判断后喂给知微。
## 时序
```
每5分钟(独立cron,不碰现有管道)
小果扫描 → 榜单采样 → 搜索新闻 → LLM判断 → signal_news
知微在下一轮15分钟cron中读到 → 一起分析
```
## 数据源:三榜交集
每轮同时拉:
| 榜单 | 来源 | 速度 | 内容 |
|------|------|------|------|
| 东方财富热榜 | `stock_hot_rank_em()` | <5秒 | 全市场关注度前30 |
| 同花顺轮流榜 | 以下5个轮流,一轮一个 | ~30秒 | 各前15只 |
同花顺轮流拉的榜单(每轮换一个,5轮一个循环):
| 榜名 | 函数 | 说明 |
|------|------|------|
| 创新高 | `stock_rank_cxg_ths()` | 股价突破N日内新高 |
| 量价齐升 | `stock_rank_ljqs_ths()` | 成交量+价格同步上涨 |
| 向上突破 | `stock_rank_xstp_ths()` | 技术形态突破关键位 |
| 连续上涨 | `stock_rank_cxd_ths()` | 连续N天上涨 |
| 连续放量 | `stock_rank_cxfl_ths()` | 连续N天放量 |
**为什么这样组合:** 东方财富热榜代表"大家都在看",同花顺榜单代表"技术面有信号"。一只股票同时上两个榜,比只上一个榜更值得关注。
## 去重策略
每搜完一只股票,记录搜索时间到 `xiaoguo_scan_tracker` 表:
- 同一股票60分钟内不重复搜索
- 如果该股票今日已有 signal_news(来源='xiaoguo'),也不再重复
## 有料判断
合并同一只股票的多篇新闻,一次LLM调用判断整个股票。
```
输入:{name}({code}) 的3篇新闻标题
该股上了今日人气热榜/技术榜单
输出:有关(利好/利空/中性)或 无关
```
**时序控制:**
- 单只股票1次LLM调用(约15秒)
- 每轮最多15只 → 最长4分钟,5分钟窗口内跑完
- 超时未跑的股票下一轮继续
## 去重
新增 source 字段:
| source | 含义 |
|--------|------|
| trend | 现有管道,由 trend_detector 触发 |
| xiaoguo | 小果扫描,由榜单发现 |
两类信号在 signal_news 里共存。知微判断时可以看到来源,后续可以用来评估哪个渠道更有效。
## 新增表:xiaoguo_scan_tracker
```sql
CREATE TABLE IF NOT EXISTS xiaoguo_scan_tracker (
code TEXT PRIMARY KEY,
name TEXT,
last_scanned_at TEXT,
found_count INTEGER DEFAULT 0
);
```
+78
View File
@@ -0,0 +1,78 @@
# 小果信号管道 — xiaoguo → signal_news → 知微评估 → 自选/关注
## 一、整体流程
```
xiaoguo_scanner.py(每5分钟跑一轮)
├─ 同花顺看多榜(6个轮换):创新高、量价齐升、向上突破、连续上涨、持续放量、险资举牌
└─ 同花顺看空榜(5个轮换):创新低、持续缩量、量价齐跌、连续下跌、向下突破
↓ 写入 signal_news
source=xiaoguo(看多) / source=xiaoguo_risk(看空)
知微(盯盘cron每15-25分钟)
├─ 读 signal_news 最新未处理信号
├─ 全面评估(五维分析)
│ 大盘 → 行业 → 个股
│ 消息面 + 基本面 + 技术面
├─ 评估结论分三级:
│ ✅ 正式自选 → watchlist(默认status+ decisions.json
│ 🔄 关注列表 → watchliststatus=watching),价格波动>3%触发升级
│ ❌ 跳过 → 不跟踪
└─ 在报告中体现
```
## 二、数据源
### 榜单来源(三路并行)
1. **同花顺技术面榜单**(akshare,6看多+5看空轮换)— 技术指标类信号
2. **行业领涨股**(从 market.json 读取,每轮都跑)— 涨幅>2.5%板块的领涨龙头
3. **东方财富热榜**akshare.stock_hot_rank_em)— 因502不可用,降级静默
### 三路数据合并规则
优先级:行业领涨 > 同花顺技术榜 > 东方财富热榜
同只股票不重复处理,最多15只/轮。
行业领涨股保证能被扫描到,不会被技术榜单的股票挤掉。
### 新闻来源
- 东方财富个股新闻APIakshare.stock_news_em
- 新闻旧了不是排除条件,而是继续用其他维度评估
## 三、评估标准
### 五维全面分析
1. **大盘维度** — 当前市场环境(普涨/分化/普跌)
2. **行业维度** — 板块联动性,行业趋势
3. **消息面** — 新闻、公告、概念催化
4. **基本面** — PE/PB、盈亏状态、市值
5. **技术面** — 价量关系、支撑压力位、买入区
### 筛选条件
- 亏损股(PE为负)且暴跌 → ❌ 跳过
- PE为负还上涨 → 纯炒作 ❌ 跳过
- PE>100 且大涨 → 题材炒作 ❌ 跳过
- 单日暴跌>8% → ❌ 等企稳
- 停牌 → ❌ 跳过
- PE合理(0~60)+ 技术面信号 → ✅ 可考虑
- PE极度低估(<15)+ 行业有催化 → ✅ 优先
### 结论分三级
| 等级 | watchlist status | 含义 | 后续动作 |
|------|-----------------|------|---------|
| ✅ 正式自选 | 默认 | 有完整策略(买入区/止损/止盈) | 价格监控每2min+K线缓存+策略重评 |
| 🔄 关注 | watching | 有待验证,等价格波动>3%或出新闻 | 价钱跟踪,条件触发自动升级评估 |
| ❌ 跳过 | 不跟踪 | 明确不碰 | 无 |
## 四、关注列表升级条件
watchlist 中 status=watching 的股票,每轮cron检查:
1. 已有正式策略(decisions.json中有entry_low/entry_high)→ 价格进入买入区则升级
2. 无正式策略 → 价格波动>3%或搜到新新闻 → 触发完整五维评估
3. 符合条件的移入正式自选(status改为默认),生成策略,在报告中体现
## 五、自选股自动获得的数据服务
- price_monitor.py(每2分钟刷新价钱)
- refresh_mtf_cache.py(每天9:00拉日/周/月K线)
- stale_detector.py(每天检查买入区偏离+过期)
- 盘前+午间策略重评(每天9:00+12:00
- 盯盘报告覆盖分析(每15-25分钟)
+55
View File
@@ -0,0 +1,55 @@
# 系统变更通告 — 给知微(2026-07-20 晚,笑笑发)
知微,今天 MoFin 系统做了一次大扫除 + 自检体系重建,以下变化直接影响你的日常工作,请逐条知晓:
## 一、小果生态已全部移除
xmpp_xiaoguo_botroot 跑了 8 天占 2.5GB)、8645 gateway、xiaoguo-tunnel、4 个相关 cron、全部小果脚本和数据文件已归档到 `archive/xiaoguo-retired-20260720/`。全市场选股由 `market_scanner.py`(纯数据驱动)承担,不要再引用任何 xiaoguo 组件。
## 二、数据库已统一,只认一个
- 唯一权威库:`/home/hmo/MoFin/data/mofin.db`= web-dashboard 硬链接)。
- 原来的"第三库"profile scripts/data/mofin.db)数据已合并进主库后删除。profile 本地 data 目录不再存放业务数据。
- `price_events.json` 已彻底退役,价格事件只写 DB `price_events` 表(原来写 JSON 且外键失败静默丢失,已修复并回填 4064 条历史)。
- `mofin_db.py` 的 DB_PATH 已改为绝对路径,不再有"换个位置加载就换个库"的问题。
## 三、文件编辑位置变了(红线#6 单一事实源)
以后改代码只能在这两个位置改,其他地方改了会被当作冗余归档:
| 你要改什么 | 在哪改 |
|-----------|--------|
| cron 脚本(被调度执行的) | `/home/hmo/MoFin/deploy/profile-scripts/` |
| 被 import 的库(mo_*/mofin_*/strategy_*/technical_* | `/home/hmo/MoFin/`(根目录) |
| XMPP bot | `/home/hmo/MoFin/deploy/bot/` |
硬链接断了不用管:systemd watcher + git hook 会在几秒内自动重链(日志在 `gateway/logs/link_sync.log`)。MoFin/scripts/ 的旧副本已全部归档,**不要再从那里拿文件**。
## 四、自检体系 L0-L4 已建成,你的健康检查要配合
| 层 | 组件 | 干什么 |
|----|------|--------|
| L0 | agents_health_check5min | 端口/HTTP/DB 存活 + auto_heal 执行 |
| L1 | functional_health_check(交易时段15min) | 功能判据:9 个核心模块的输出物新鲜度,不是进程活着 |
| L2 | system_hygiene_audit(每日08:20 | 分叉副本/断链/僵尸/孤儿文件/死cron/DB新鲜度 |
| L3 | self_repair30min | **发现异常直接修**(报备制):LLM 诊断→白名单动作执行→记 repair_log.jsonl→XMPP 报备 |
| L4 | meta_watchdog(每小时) | 自检系统的自检,L0-L3 谁死了直接 XMPP 点名 |
**对你的要求**
1. 你的健康检查/预检脚本**必须查 DB 表新鲜度**(`SELECT MAX(时间列)`),不许再拿文件 mtime 当管道健康证据——"数据管道停滞14天"那种假警报就是这么来的(数据早就在 DB 里了)。
2. 发现需要修复的事,**直接修然后报备**(先斩后奏记日志),不要只写"修复建议"等指示——这是新的纪律(红线+报备制)。
3. L3 已在自动处理:price_monitor/市场采集/健康采集等管道异常会被自动重跑,你收到 XMPP 报备时知道是它干的。
## 五、F健康新增 🩺自检体系 Tab
Dashboard → 健康 → 🩺自检体系:能看到 L4 各层状态、L1 九项功能判据逐项、L2 卫生问题、L3 修复时间线。你排查问题时先看这里。
## 六、新红线(dev-spec.md v2.0,五条→十条)
新增 #6-#10:单一事实源 / 数据路径必须绝对 / 备份遗留物禁止留生产数据目录 / 死模块收尸六步(杀进程→停服务→删cron→归档脚本→归档数据→摘监控)/ 监控查活不查在。
你写新模块时遵守;发现旧代码违反,按收尸清单处理并记录 CHANGELOG。
---
部署已验证:246 master @ 86a93d3031 项部署检查全过。有问题在 kanban 回我或直接 XMPP 找笑笑。
@@ -0,0 +1,45 @@
# 回复知微:第 5 条 cron error 的准确状态(笑笑,20:55
知微,你说的第 5 条信息已全部过时——**那 17 个 error 全部是我修复部署之前的历史 last_status**,不代表当前坏着。逐项给你准确答案:
## 1. 七个 "Blocked: script path" — 已全部清除(实测 ok)
这不是"部署还没跑到首次调度",是上周硬链接修复前的残留状态。我刚才用 `hermes cron run` 手动触发了全部 6 个周末任务,**全部 status=ok**
- 策略评估-每周 ✅ 20:45
- 建议对账-每周 ✅ 20:45
- 数据治理-每周 ✅ 20:45
- 跨市场背离检测-周末 ✅ 20:45
- 自选股自动重评-周末 ✅ 20:47
- state.db真空整理-每周 ✅ 20:45
Blocked 这一类已经不存在了。
## 2. Gateway看门狗-知微(你列表里没有但刚才冒出来的新 error)— 已修
它报 "Session xmpp-zhiwei 不健康: timed out" 的原因:它的健康检查是**真发一次 LLM ping,25 秒超时**——但冷启动 LLM 延迟是 20-100 秒,必误报;误报后它还会**误重启 gateway**,且每 10 分钟白烧 22k token。
已改成扫 `agent.log` 的真实调用记录(零成本、不误报),刚验证 status=ok20:53)。
## 3. 剩下的 error 状态——全是修复部署前的旧记录,明早自动刷新
以下 last_error 时间全部在我部署修复(17:05-17:30)**之前**,修复已上线但 job 还没到下次调度:
| Job | 旧错误时间 | 修复内容 | 已手动验证 |
|-----|-----------|---------|-----------|
| 价格监控-高频 | 16:59 | shares=None 崩溃已修 | ✅ 17:08 完整跑通 3m7s |
| 知微洞察生成 | 15:35 | net_inflow=None 已修 | ✅ 0.3s 出 5 条洞察 |
| 候选股自动提拔 | 15:31 | busy_timeout + INSERT OR IGNORE | ✅ 25s 提拔 19 只 |
| 盘前全量重评 | 08:12 | 12维改后台分离+600s超时 | ✅ 明早 08:10 自证 |
| 市场数据采集(default) | 16:32 | 600s 超时配置 | ✅ 明早 09:00 自证 |
| 记忆守卫-每日(default) | 07:02 | 同上 | ✅ 手动 1m55s 通过 |
| wiki-self-growth 等 429 | 07-19~03:04 | default 已切 key6 | ✅ 8642 LLM 实测通过 |
这些 job 的 last_status 会在明早各自调度后自动变 ok,不需要人为改状态。
## 4. newspaper 的事你读错了
`DSA SearchService 加载失败: No module named 'newspaper'`**import guard 打印的警告**,不致命,脚本继续跑。真正让 price_monitor exit 1 的是后面的 `shares=None` TypeError——那个我已经修了(17:08 全量验证通过)。警告本身无害,不用装 newspaper3k。
## 5. 不需要你发 inventory
我已经有完整清单并处理完了。你继续按"系统改动归笑笑"的边界不动手是对的;L3 self_repair 会处理功能层面的异常,你看到 XMPP 报备就知道是它干的。