feat: ship persistent ai playground and alerts foundation

docs/situational-awareness-foundation-plan.md

@@ -0,0 +1,309 @@
+# Situational Awareness Foundation Plan
+
+## 定位
+
+当前这套 AI 能力应被视为 `态势感知服务底座`，而不是完整的态势感知产品。
+
+也就是说，现阶段的目标不是：
+
+- 做一个“什么都能分析”的万能 AI 页面
+- 让模型在证据不足时替代人工研判
+- 过早把页面做成完整指挥大屏
+
+现阶段真正要做的是：
+
+- 先把 `model gateway / backend facade / evidence injection / page-specific brief` 这几层边界搭稳
+- 让系统能够在已有证据上稳定地产出“可读、可回看、可扩展”的摘要
+- 为后续更强的数据联动、agent 推理和 assessment 结构化输出预留好接口与数据模型
+
+## 当前现实约束
+
+### 1. 数据维度不足
+
+目前系统能提供的主要证据仍集中在：
+
+- BGP incidents / anomalies / events
+- collector coverage
+- datasource health / platform alerts
+- prefix geography 的部分归属信息
+
+当前明显还缺：
+
+- 流量异常与业务指标
+- 电商、支付、物流等业务侧指标
+- 更丰富的资产、链路、区域、行业画像
+- 外部舆情、公告、运营商状态、基础设施事件等背景信息
+
+这意味着：
+
+- 模型现在可以做“基于现有证据的摘要与归纳”
+- 但还不能可靠地做“跨维度因果研判”
+
+### 2. 维度之间联动还弱
+
+目前不同模块之间更多是“并列展示”，还不是“强关联分析”：
+
+- 系统告警和 BGP 事件还没有统一事件模型
+- collector bias 与真实区域热度还没有完全剥离
+- datasource health 与 BGP 风险、业务影响之间还没有稳定映射
+
+这意味着：
+
+- 当前更适合做 `brief / overview / operator notes`
+- 还不适合过度承诺“自动态势判断”
+
+### 3. 结构化 assessment 还未成为主输出
+
+虽然已经有 BGP brief、系统告警 brief、态势告警 brief，但目前主输出仍偏向：
+
+- 文本摘要
+- facts/context 附带证据
+
+后续真正要服务态势感知，需要更稳定的结构化输出，例如：
+
+- summary
+- key risks
+- evidence
+- confidence
+- recommendations
+- missing data
+
+## 当前基座已经具备的能力
+
+### 1. AI 调用边界已经明确
+
+- `aiprovider` 负责模型协议与 provider 兼容
+- `backend` 负责业务 API、证据整合和鉴权
+- `frontend` 负责页面入口与结果展示
+
+### 2. 页面级 AI 入口已经开始成型
+
+当前已经有或正在收口的入口：
+
+- `Playground`
+  - 用于链路验证与 provider 诊断
+- `BGP AI 简报`
+  - 用于 BGP 事实摘要和区域风险归纳
+- `Alerts`
+  - 用于系统告警、BGP 告警、态势告警三类入口
+
+### 3. 证据优先的方向已经建立
+
+已经不再只依赖人工在 Playground 中手填 prompt，系统开始具备：
+
+- 从真实业务数据生成事实输入
+- 保存 facts/context 快照
+- 回看 AI 输出时同时回看证据
+
+这一步非常关键，因为它决定后面能否从“玩具 demo”走向“有运维价值的系统”。
+
+## 近期收尾建议
+
+这些事情都属于“底座收口”，值得做，但不应该再继续重产品包装。
+
+### 1. 统一 Alerts 页面
+
+已采用：
+
+- 一个 `Alerts` 页面
+- 三个 tab：
+  - `系统告警`
+  - `BGP 告警`
+  - `态势告警`
+
+收尾重点：
+
+- 保持 tab 的文案、摘要卡和 AI 简报交互一致
+- 不额外扩展成多个独立二级页面
+
+### 2. 保持 Playground 为测试台
+
+原则：
+
+- Playground 只承担链路验证、provider 状态诊断、请求结果观察
+- 不继续堆“万能业务分析器”式交互
+
+### 3. 把 brief 能力当服务能力而不是页面特效
+
+页面现在能看到按钮和结果，这很好，但更重要的是：
+
+- 后端接口稳定
+- facts/context 可追踪
+- 输出结构后续可升级
+
+### 4. 导航结构先收口，不继续平铺一级菜单
+
+随着后续能力扩展，系统很可能继续新增：
+
+- 海缆
+- 算力中心
+- 战争信息
+- 电商分析
+- 其他专题观测页
+
+如果继续把这些入口全部平铺在左侧一级菜单中，会带来两个问题：
+
+- 一级菜单过长，用户难以判断先进入哪个上下文
+- `观测页 / 告警页 / 研判页 / 运维页` 的职责边界会被混在一起
+
+因此近期应明确采用分组导航，而不是继续扩展平铺菜单。
+
+推荐的导航分组如下：
+
+- `总览`
+  - 仪表盘
+  - Earth
+- `专题观测`
+  - BGP 观测
+  - 采集数据
+  - 后续可扩展：海缆、算力中心、战争信息、电商分析
+- `告警与研判`
+  - Alerts
+- `运维与配置`
+  - 数据源
+  - AI Playground
+  - 用户管理
+  - 系统配置
+
+这套结构的含义是：
+
+- `专题观测` 页面负责看某个维度本身
+- `Alerts` 负责跨模块风险与值班工作台
+- `Playground` 保持为测试台，不挤占业务导航语义
+
+短期收尾时，应优先重组现有入口，而不是继续增加新的一级菜单。
+
+## 后续路线
+
+## Phase 1：服务底座稳固
+
+目标：
+
+- 不追求“更炫的 AI 页面”
+- 先把当前接口、证据、存储和页面入口收稳
+
+工作项：
+
+- 统一页面级 AI 入口模式
+- 统一 brief response schema
+- 保证 facts/context 在前后端都可回看
+- 继续清理 mock 和临时分支逻辑
+
+完成标准：
+
+- 每个 AI 入口都是真实链路
+- 每个 AI 结果都能追溯到证据输入
+
+## Phase 2：Evidence-first Assessment
+
+目标：
+
+- 从“文本摘要”升级成“结构化 assessment”
+
+工作项：
+
+- 为 brief/assessment 定义统一 schema
+- 固化：
+  - summary
+  - key_risks
+  - evidence
+  - confidence
+  - recommendations
+  - missing_data
+- 页面以结构化区块展示，而不只是大段文本
+
+完成标准：
+
+- AI 输出可持久化、可比较、可审计
+
+## Phase 3：多维证据接入
+
+目标：
+
+- 让“态势感知”真正拥有更多维度，而不是只靠 BGP 与系统告警
+
+优先接入方向：
+
+- datasource health findings
+- 流量或业务指标
+- 区域/资产/链路映射
+- 外部事件与公告
+- 业务垂直数据，例如电商分析相关指标
+
+完成标准：
+
+- AI 能基于多个维度做交叉说明
+- 不再只围绕单一模块自说自话
+
+## Phase 4：Correlation Layer
+
+目标：
+
+- 不同来源的信号不再只是并列，而是形成统一的事件关联
+
+工作项：
+
+- 统一 signal/finding 模型
+- 跨模块事件聚合
+- 证据来源权重
+- collector bias 与真实热度分离
+
+完成标准：
+
+- 系统能回答“这些异常是不是同一件事”
+- 系统能回答“哪些结论只是观测偏差”
+
+## Phase 5：Agent-assisted Situational Awareness
+
+目标：
+
+- 在证据足够的前提下，再让 agent 负责更复杂的推理与建议
+
+工作项：
+
+- 复用现有 agent runtime 规划
+- 引入 web search / docs fetch / repair proposal 等能力
+- 但始终坚持：
+  - evidence first
+  - proposal before action
+  - no silent mutation of defaults
+
+完成标准：
+
+- agent 成为证据驱动的分析层
+- 而不是一个“万能猜测层”
+
+## 设计原则
+
+### 1. 先底座，后产品化
+
+先把服务链路和证据模型做好，再做更大的页面表达。
+
+### 2. 先证据，后判断
+
+事实输入应先稳定，再让模型做归纳。
+
+### 3. 先专用 brief，后统一态势层
+
+先让各业务页有各自可信的 AI 入口，再考虑统一态势页。
+
+### 4. 先 proposal，后自动动作
+
+涉及修复、覆盖、写配置、调任务的动作，都应经过 proposal 和审计。
+
+## 当前建议结论
+
+对现在这个项目，最合理的定位是：
+
+- `Playground` 是测试台
+- `BGP / Alerts` 是第一批业务 AI 入口
+- `aiprovider + backend AI facade + evidence snapshots` 是核心服务底座
+
+现阶段不需要追求“已经具备完整态势感知能力”。
+
+现阶段真正的成功标准是：
+
+- 这套底座可用
+- 可回看
+- 可扩展
+- 不自欺欺人