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