环境
| 项 |
值 |
| 软件版本 |
v3.32.0（桌面版 Electron） |
| 系统 |
Windows 11 x64 |
| 配置 |
SCHEDULE_ENABLED=true、AGENT_EVENT_MONITOR_ENABLED=true |
问题：告警规则存在两套互不相通的存储
| 存储 |
写入方式 |
谁消费 |
Web 页面可见 |
.env 的 AGENT_EVENT_ALERT_RULES_JSON |
手改 .env + 重启 |
schedule 后台轮询（agent_event_monitor） |
❌ 看不到 |
SQLite alert_rules 表 |
POST /api/v1/alerts/rules（Web 告警中心） |
告警中心手动检查 / 测试 |
✅ 可见 |
实测证据：把 6 条规则写进 .env 的 AGENT_EVENT_ALERT_RULES_JSON 并重启后，
GET /api/v1/alerts/rules 仍返回 total=0（DB 表为空）；改走 API 建规则 → total=6，但 .env 那份不变。
用户侧的实际后果
- 幽灵告警：用户在 Web 页面清仓某股票并删掉相关规则后，
.env 里那份不会跟着变。
若 .env 份里还有旧持仓的规则，SCHEDULE_ENABLED=true 时轮询继续对已清仓股票求值告警。
（实测复现：已清仓股票的规则残留在 .env，DB 已无）
- 用户认知混乱：页面里看不到 schedule 实际消费的规则，无法判断"到底哪些规则在生效"。
- 手改
.env 的规则在告警中心不可见、不可测、不可管理——两套能力割裂。
已排除「配置问题」
对照上游 .env.example：与告警规则相关的配置项只有 AGENT_EVENT_ALERT_RULES_JSON 一个
（模板 line 557），没有任何"让 schedule 改读 DB"或"双向同步"的开关 →
这是设计层面的双数据源问题，无法靠用户配置规避。
说明：本例当前已手工把 .env 那份同步成与 DB 一致（5 条），所以暂未产生实际误报；
但只要用户在 Web 端增删规则而未同步改 .env，两套就会再次分叉——这正是它值得修的理由。
建议修复方向
- 合并为单一数据源：以
alert_rules 表为准，AGENT_EVENT_ALERT_RULES_JSON 仅作首次迁移的导入源；
- 或至少做到双向同步：Web 端增删改时写回
.env，schedule 轮询改读 DB；
- 短期兜底：文档中明确二者职责边界，并在告警中心页面展示"schedule 轮询消费的规则集"，
避免用户以为页面列表就是全部生效规则。
本 issue 由用户实际使用中的「已清仓股票仍在告警」现象切入排查，以上行为均实测复现。
环境
SCHEDULE_ENABLED=true、AGENT_EVENT_MONITOR_ENABLED=true问题：告警规则存在两套互不相通的存储
.env的AGENT_EVENT_ALERT_RULES_JSONalert_rules表POST /api/v1/alerts/rules（Web 告警中心）实测证据：把 6 条规则写进
.env的AGENT_EVENT_ALERT_RULES_JSON并重启后，GET /api/v1/alerts/rules仍返回total=0（DB 表为空）；改走 API 建规则 →total=6，但.env那份不变。用户侧的实际后果
.env里那份不会跟着变。若
.env份里还有旧持仓的规则，SCHEDULE_ENABLED=true时轮询继续对已清仓股票求值告警。（实测复现：已清仓股票的规则残留在
.env，DB 已无）.env的规则在告警中心不可见、不可测、不可管理——两套能力割裂。已排除「配置问题」
对照上游
.env.example：与告警规则相关的配置项只有AGENT_EVENT_ALERT_RULES_JSON一个（模板 line 557），没有任何"让 schedule 改读 DB"或"双向同步"的开关 →
这是设计层面的双数据源问题，无法靠用户配置规避。
建议修复方向
alert_rules表为准，AGENT_EVENT_ALERT_RULES_JSON仅作首次迁移的导入源；.env，schedule 轮询改读 DB；避免用户以为页面列表就是全部生效规则。
本 issue 由用户实际使用中的「已清仓股票仍在告警」现象切入排查，以上行为均实测复现。