告警队列负责需要立刻中断当前工作的事件，仪表板负责随时可查的全局现状，定时摘要负责固定节奏的复盘，AI 审查笔记负责把原始记录压缩成可读的上下文。四者的时间尺度分别是秒、分钟、天和事件级——把它们塞进同一个界面，结果是四件事都做不好。
监控团队很少因为缺数据而失败。他们失败，是因为让同一块屏幕同时回答三个时间尺度完全不同的问题：现在发生了什么、系统整体是什么状态、明天该先处理哪一件。这三个问题各自需要不同的载体，混在一起时，紧急的事情被淹没，重要的事情没人复盘。
四种载体，四种时间尺度
先把概念分清楚。下面四样东西经常被统称为「监控」，但它们解决的是完全不同的问题：
- 告警队列：有状态的待办。每一条都需要被认领、处理、关闭。时间尺度是秒到分钟。
- 仪表板：无状态的现状。任何人任何时候打开，都能看到系统此刻的样子。时间尺度是分钟到小时。
- 定时摘要：固定节奏的横向对比。同样的口径、同样的时点，用来发现趋势而不是发现事件。时间尺度是天到周。
- AI 审查笔记：把一堆原始记录压缩成人能读的上下文。它不是一个时间尺度，而是一道加工工序，可以服务于上面任意一层。
判断一个信号该进哪一层，只需要问一个问题：看到它的人，需要在多久之内做出反应？需要立刻停下手上的事，进告警队列；需要知道但不需要立刻动，进仪表板；需要在某个固定时刻回顾，进摘要。
告警队列：只放需要中断的事件
告警最容易犯的错误是把「值得知道」当成「需要中断」。一条告警如果没有明确的处置动作，它就不该存在——这条规则可以在两周内把大多数团队的告警量削减一半，同时提高响应速度。
对接了交易接口的系统，真正配得上实时告警的通常只有四类：
- 连接中断：账户会话断开、WebSocket 长时间无心跳。
- 保证金触线：保证金比例跌破预设阈值，接近经纪商的强平线。
- 订单执行失败：下单被拒、部分成交后剩余未处理、平仓请求超时。
- 数据异常：净值在没有成交的情况下发生跳变，通常意味着对账口径出了问题。
每条告警规则都必须写明三件事：触发条件、处置动作、关闭标准。没有关闭标准的队列会在两周内退化成一个没人看的列表，而真正的故障会淹没在陈旧条目里。
仪表板：随时可看，但不承担待办
仪表板的价值在于让任何人在任何时刻都能回答「现在整体怎么样」。它不应该有「已读/未读」，也不应该指望有人盯着它——盯屏是告警的工作。
首屏放多少指标？不超过八个。筛选标准很简单：这个数字变化时，是否会立刻改变某个人的行动。改变不了行动的指标，放进二级页面或摘要里。
对多账户系统来说，值得放上首屏的通常是：在线账户数与断连数、账户净值合计与今日变化、最低保证金比例账户、今日订单成功率、平均执行延迟、当前未关闭告警数。
定时摘要：固定口径，固定时点
摘要的价值不在信息量，而在口径与节奏的稳定。同样的四类内容、同样的计算窗口、每天同一时间发出，它才具备横向对比的意义。
| 层面 | 摘要里应该出现的内容 |
|---|---|
| 账户层 | 净值与回撤变化、保证金占用区间、账户在线率 |
| 执行层 | 成交笔数、订单成功率、滑点分布、平均执行延迟 |
| 风控层 | 规则触发次数、被拒单原因分布、人工干预记录 |
| 系统层 | 连接中断次数与时长、错误码计数、告警开闭数量 |
频率上，多数团队适合「每日一次 + 每周一次」：每日面向执行复盘，每周面向策略与资金分配决策。盘中高频推送摘要是把摘要当监控用，两头都做不好。
AI 审查笔记：让它归纳，不要让它判断
AI 在这套体系里的合理位置很窄，但很有价值：把当日成交、偏差记录与告警日志压缩成结构化的异常候选清单，附上可能原因，交给人决定是否处理。
三条边界值得写进流程文档：
- 数字由程序算，措辞由模型写。所有指标从接口数据直接计算后填入模板，不让模型自行推算数值。
- 只输出候选，不输出结论。「这三笔成交的滑点超出本月 95 分位」是候选；「策略失效」是结论，应该由人来下。
- 保留可追溯链接。每条笔记都要能点回原始订单记录，否则它就是一段无法验证的文字。
运维分诊：谁决定，什么时候升级
分诊解决的是「这条告警到底归谁」。规则检测负责发现，AI 负责归纳，但仍然有一类案子是模糊的、或者影响面大到必须有人签字的——那就是分诊存在的理由。
一个够用的分诊规则只需要三档：自动处理（有明确修复动作，如自动重连并校验持仓）、值班处理（有处置手册，值班人按手册执行）、升级处理（涉及资金安全或客户影响，必须由负责人决定）。每一档都要有明确的责任人和轮值机制，没有 owner 的队列一定会积压。
决策表：什么信号放哪一层
| 信号 | 告警队列 | 仪表板 | 定时摘要 | 理由 |
|---|---|---|---|---|
| 账户连接断开 | ✓ 主载体 | ✓ 状态 | — | 需要立刻恢复，否则后续所有指令都会失败 |
| 保证金比例跌破阈值 | ✓ 主载体 | ✓ 状态 | ✓ 趋势 | 既是紧急事件，也是需要长期观察的风险指标 |
| 单笔订单被拒 | 仅连续失败时 | ✓ 计数 | ✓ 原因分布 | 单笔失败是噪声，连续失败才是事件 |
| 滑点超出历史分布 | — | ✓ 主载体 | ✓ 主载体 | 解释性信息，中断没有意义 |
| 跟单偏差扩大 | 超过资金影响阈值时 | ✓ 主载体 | ✓ 主载体 | 多数偏差属于预期范围，需要的是趋势视角 |
| 策略净值回撤 | — | ✓ 状态 | ✓ 主载体 | 属于决策问题，不属于运维问题 |
| 接口错误码激增 | ✓ 主载体 | ✓ 计数 | ✓ 复盘 | 通常是上游变更的第一个信号 |
六个反模式
- 把仪表板当告警用。指望有人盯着屏幕，等于把可靠性押在注意力上。
- 把告警当日志用。什么都发一条，三周后所有人都学会了忽略它。
- 摘要口径随时改。今天用净值、明天用余额，横向对比就失去了意义。
- 队列没有关闭标准。「已处理」如果没有定义，队列长度就只会单调增长。
- 让 AI 下结论。模型给出的判断没有可追溯依据，出问题时无法复盘。
- 四层用四份数据源。同一个指标在四个界面上显示四个数字，是信任崩塌最快的方式。
用一份数据把四层建起来
最后这一条值得单独说：四种载体应该派生自同一份原始数据。通过 MetaTrader API 的 REST 接口按周期拉取账户摘要与历史订单、用 WebSocket 订阅连接状态与净值变化，把原始记录落库之后，实时视图、日聚合与待办事件都是这份数据的不同投影。
这样做的直接好处是三个界面上的数字永远一致；间接好处是当口径需要调整时，只改一处计算逻辑，历史数据可以重算。相比之下，从终端手工导出报表既无法自动化，也无法回溯。
需要具体接入方法，可以看快速上手教程；如果还在决定用哪种方式接入，四种接入方式对比会更有帮助。采集时用到的接口字段、认证方式与请求参数，以官方 API 文档为准。
落地顺序：先建哪一层
先建数据采集
没有稳定的原始数据，后面三层都是空中楼阁。先把账户摘要、订单流与连接状态落库，保证幂等与去重。
再建告警队列
从四条规则起步：连接中断、保证金触线、订单执行失败、净值异常跳变。每条都写明处置动作与关闭标准。
然后建每日摘要
成本最低、收益最稳定的一层。固定四个层面的内容，固定发送时间，两周后就能看出趋势。
最后建仪表板
等你已经知道哪些数字真正会改变行动，再决定首屏放什么。反过来做，八成会做出一个没人看的漂亮界面。
常见问题解答 (FAQ)
告警队列和仪表板可以合并吗？
不建议。告警队列是有状态的待办，每条都需要认领和关闭；仪表板是无状态的现状，用于随时了解全局。两者混用的结果通常是既没人处理告警，也看不清整体情况。
怎么判断一条告警该不该存在？
看它有没有明确的处置动作。如果收到告警后没有人知道该做什么，或者做法是「先观察一下」，那它就应该降级为仪表板指标或摘要内容。
定时摘要发多频合适？
多数团队适合每日一次加每周一次。每日面向执行复盘，每周面向策略与资金分配决策。盘中频繁推送摘要，等于把摘要当监控用，两件事都会做不好。
AI 生成的审查笔记可靠吗？
在数据口径固定、模板受控的前提下可靠。建议让模型只负责措辞与异常归纳，所有数字由程序从接口数据直接计算后填入模板，避免模型自行推算数值。
多账户场景下这四层怎么组织？
按账户分组做告警、按策略维度做仪表板、按资金方维度做摘要。底层数据只有一份，三种视图是它的不同投影，这样才能保证同一个指标在任何界面上都是同一个数字。
小团队有必要建这么多层吗？
有必要，但可以很轻。四条告警规则加一封每日邮件，就已经是完整的两层，用定时任务就能实现。真正要避免的不是层数少，而是把所有东西堆进同一个界面。