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