持续运行的量化交易系统

晨报只在固定时间运行一次；持续系统则按周期读取行情、账户和信号。假设每 60 秒运行一轮，但周期要按策略和风险要求配置。服务全天在线，也不等于全天允许交易：必须区分交易日、交易时段、休市、集合竞价，以及日线或分钟线是否已经完成。

一轮主循环可以按这个顺序组织：

1. 读取暂停、恢复和熔断状态；
2. 检查行情与交易连接；
3. 刷新持仓、现金、可卖数量和盈亏；
4. 检查账户级日内亏损是否触发熔断；
5. 检查持仓止损、退出和到期条件；
6. 遍历 watchlist（关注清单），计算每个标的的信号；
7. 对拟议订单运行风控；
8. 进入模拟执行，或进入已授权的审批与真实执行流程；
9. 保存状态、信号、订单、事件和心跳。

暂停买入、全局暂停、强制熔断、解除熔断和清仓必须有不同语义。停止新增风险时，账户刷新和风险监测仍应继续。

后端负责数据、信号、风控和订单；控制台负责展示状态并提交人的控制意图；通知模块按严重程度传递事件。页面卡顿不应该拖住风险处理。

环境检查也属于系统边界：数据库、MiniQMT 本地路径、资金账号、模型接口、Python 和依赖版本，都应从实际配置与日志确认。".env.sample"只是配置示例，密钥不能放入课程或公共仓库。"0.0.0.0"表示监听本机所有接口，不是浏览器访问地址，也不代表可以安全地暴露到公网。涉及账户的控制台应认证并限制权限。

回测、模拟账户、策略对比、投研对话和晨会可以接入同一控制台，但各模块的状态和失败要可追踪。历史展示中的年化约 9.31%、RSI 约 5.59%等数字，只能视为特定样本的展示，不能据此承诺某标的或策略长期有效。

共享状态可以暂存在 "live_state.json"，但字段要分成两类：

• 事实：权益、现金、持仓数量和成本、最新价、盈亏、信号、订单、健康度和事件；
• 意图：暂停、恢复、阈值修改等人的控制请求。

事实应由后端从可信数据源写入，网页只读；人的操作写入控制通道，由后端验证、执行并回报。前端不能直接把一个数字改成“真实余额”。每类数据还要明确唯一写入者、格式版本和保留策略。页面可以只展示最近 200 条事件，审计记录则应追加保存，不能因为界面有限就丢失历史。

模拟账户可以从 100 万元初始资金和可配置初始持仓开始，但模拟成交、排队、滑点、部分成交、拒单、涨跌停和延迟可能被简化，不能把模拟状态当成真实账户。

写 JSON 时，可以先在目标目录附近写临时文件，完整写入并关闭后，再用合适的原子替换操作替换正式文件。这样读者不会看到只写了一半的 JSON；需要断电后仍可靠保存时，还要考虑 flush 和 fsync。

但原子可见性不等于多写入者安全。控制台和后端如果都读到旧版本，再分别写入新版本，仍可能互相覆盖。更稳妥的方案包括单写入者、文件锁、版本比较或数据库事务。文件轻量，数据库便于历史查询和事务；两者都需要明确并发边界。

可以把事件按严重程度分为五级：

订单回报超时，不能直接重试：订单可能已经被接受，必须先用唯一订单号核对。普通信息可以约 30 分钟聚合一批，严重事件不能等待聚合。通知发送成功也不代表问题解决。

心跳是定期写出的“我还活着、数据还新鲜”的信号：交易连接可以约 30 秒更新，行情可以约 1 分钟检查，主循环写自己的最新时间戳。三者必须分开显示。

主循环没有更新，可能是进程卡住；行情没有更新，可能是数据源失效；交易连接没有更新，可能无法查询或提交订单。对 60 秒循环，直接把“30 分钟没有更新”当成死锁阈值可能太迟，阈值要按风险设置。监控进程不能和被监控进程一起卡住，关键守护应独立。自动重启后，先核对账户和外部订单，再决定是否恢复交易。

策略实现负责算法，YAML 等配置负责给某个标的选择已有策略和参数；配置里新增名称，不会自动生成算法。新策略还要完成实现、注册、界面暴露和测试，运行中不能在没有版本记录和验证的情况下悄悄替换。

同一根日 K 在每分钟轮询时可能反复满足条件。应使用信号编号、信号时间戳和订单状态去重，让同一信号最多产生预期的一次动作。回测与实盘尽量共用指标和信号函数，把成交模拟与真实执行适配器分开。

模拟盘可以用 100 万元虚拟资金和 mock 持仓运行，不需要券商模拟账号；一次展示中的约 107 万元净值或约 7.27%变化，只代表那次模拟状态，不代表真实收益。执行适配器必须在模拟模式下禁止真实发送。