310 lines
7.6 KiB
Markdown
310 lines
7.6 KiB
Markdown
# 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` 是核心服务底座
|
||
|
||
现阶段不需要追求“已经具备完整态势感知能力”。
|
||
|
||
现阶段真正的成功标准是：
|
||
|
||
- 这套底座可用
|
||
- 可回看
|
||
- 可扩展
|
||
- 不自欺欺人
|