业务故事站
跨产品

限制综述：五产品共同边界与替代方案

平台做得好之外，更要讲清楚做不了什么：单机规模上限在哪、AI 离线了怎么办、跨产品集成边界在哪、替代方案是什么。看完这 3 个故事，你会带着"底线清单"去选型、去演示、去承诺。

业务人员 数据工程师 IT 管理员 决策者 边界 替代方案 共 3 个故事

能 / 不能速览

✅ 这套平台能做
  • 把各产品的真实边界汇总成一份"共同底线清单"，演示与承诺前可自查
  • 为每个限制给出可落地的替代方案（换本地算法、分批查询、手工导数据等）
  • 明确区分"已实现 / 未实现 / 愿景"，避免把设计文档当能力宣传
  • 四款已交付产品单机可跑、可离线演示，适合试点与 PoC
⛔ 这套平台做不了
  • 单机规模：Gotham 图存储、AIP 单数据源、Foundry 轻量查询，TB 级是硬上限
  • AIP 的 Text2SQL 依赖外部 LLM API，无 key / 离线时链路中断
  • 跨产品集成：独立登录、用户库不互通、语义层未打通，不能当"超级平台"用
  • Swift 为仿真域 PoC（星座/链路/结算为模拟数据，非真实在轨），监控告警属 V2，都不能进入投产承诺

适用角色

边界问题关系到三类人：

  • 业务人员：知道哪些需求能提、哪些别指望，避免拿着愿景需求进评审。
  • 数据工程师 / IT 管理员：了解单机容量、LLM 依赖、账号体系，规划真实落地。
  • 决策者：用本主题的边界清单做选型与承诺，不被"演示成功"误导成"生产可用"。

能力速览（边界全景）

规模边界

单机优先：Gotham 图内存邻接表 + JSON 落盘、AIP 一次一源（最多 100 行）、Foundry OOL 单对象 ≤3 层、Apollo 单 Agent 演示。

AI 边界

Text2SQL 依赖外部 LLM（无 key 离线中断）；意图识别是关键词规则；语义检索 / 实体解析的向量与 AI 增强默认关闭。

集成边界

各产品独立登录（admin / admin1）独立 JWT、用户库不互通；演示数据互不联通；Swift 为仿真域 PoC（非真实在轨）；监控告警属 V2。

替代方案

规模不够就分批查 / 试点数据；AI 离线就用 Foundry 对象查询与 Gotham 本地算法兜底；集成不强求，各自使用 + 手工衔接。

调整指南（怎么绕）

  • 规模不够：换更小的演示 / 试点数据集；Gotham 展开分 1 度、2 度、3 度分批，别一次要全图。
  • LLM 不可用：检查 LLM 网关路由与降级链；临时用 Foundry 对象查询 / 语义检索取数，不依赖 AI。
  • 跨库不互通：需要跨域追查就手工导出 CSV 再导入目标产品；别承诺"自动关联"。
  • 账号不统一：各产品独立登录就用统一口令策略（都是 admin / admin1）加审计兜底，单点登录记入后续版本。

做得好的场景

边界综述最擅长"把丑话说在前面、把替代方案备好"：
  • 演示不翻车：提前知道 Swift 是仿真域（模拟数据）、跨库不互通，演示时不会当场卡壳。
  • 承诺有依据：哪些能进 SLA、哪些只是愿景，边界清单一目了然。
  • 落地有路径：每个限制都配了替代方案，不至于"知道不行但不知道怎么办"。

限制与不足（本主题的边界）

注意：边界综述本身也只是"当前版本"的快照，会随迭代变化：
  • 快照非合同：本页描述的是当前实现的状态，Roadmap（P2 管道扩展、P3 Git 真相源、V2 监控告警）落地后部分限制会解除。
  • 数字口径演示级：文中金额、人数、容量都是演示数据量级，不能当作生产规模基准。
  • 非性能测试结论：单机 TB 级上限是设计判断，未经真实压测，大规模选型前需做基准验证。

场景故事

故事 1 单机优先与规模边界：50TB 的期望该不该泼冷水
场景：规模评估 角色：决策者 + 数据工程师 耗时：约 20 分钟
背景
某制造企业 CIO 在选型会上问："这个平台能支撑我全量 50TB 订单库吗？"张工（数据工程师）没有直接答能或不能，而是把五产品的规模边界摊开讲了一遍——单机优先是设计原则，TB 级是共同上限。
传统做法对比
以前供应商答"没问题"结果上线翻车；或要求客户先上分布式基建、数月部署。现在把边界摆上台面：演示 / 试点数据量级轻松，TB 级要谈分布式路线，不夸大、不缩水。
角色
决策者（评估承诺）+ 数据工程师（核对各产品容量参数）。
操作步骤
  1. 打开各产品限制清单：Gotham 图存储单机、AIP 单数据源最多 100 行、Foundry 单对象 ≤3 层查询
  2. 评估实际数据量：演示级（数百行）vs 试点级（百万行）vs 全量（TB 级）
  3. 确认替代方案：试点抽子集、分批查询、后续接分布式（Neo4j / 时序库）
  4. 给 CIO 结论：试点可用，全量需另外谈架构
系统响应
真实边界在操作中可见：Gotham 展开超 3 度或超过 1000 节点返回错误；AIP 查询超过 100 行被截断并提示；Foundry 对象查询禁点号引用；Apollo 单 Agent 演示。
结果洞察
把丑话说在前面反而赢得了信任：客户认可"机制浓缩版"定位，愿意先做 100 万行试点，再按试点结果决定架构演进。边界清晰是卖点，不是短板。
调整建议
选型前先跑一遍"规模自检"：把真实表结构导入，看对象查询 / 图展开在什么量级开始吃力。相关阅读：Gotham 图谱入门、Foundry 入门。
动手试一试
尝试：在 Gotham 对玄武集团展开 3 度并尝试填 limit 超过 1000，观察返回错误。目的：直观感受"单机 + 硬 limit"的真实边界。
限制提示
TB 级上限是设计判断未经真实压测；AIP SQL 执行最多 100 行；Gotham 图存储内存邻接表 + JSON 落盘，大图并发能力有限；演示数据每次启动重建。
故事 2 AI 依赖与离线降级：断网那天业务怎么继续
场景：降级演练 角色：数据工程师 + IT 管理员 耗时：约 15 分钟
背景
一次网络演练中，出口被切断。业务分析师习惯的 AIP 一句话查数突然不生成 SQL 了——因为 Text2SQL 依赖外部 LLM API（deepseek-v4-flash 经平台网关）。IT 管理员小周和工程师张工需要给出"断网怎么办"的降级方案。
传统做法对比
以前依赖外部 SaaS 的 BI 断网即瘫，连入口都没有；现在至少能分层降级：AI 层不可用，但 Foundry 对象查询、Gotham 图算法都是本地计算不依赖 LLM，业务照样能取数、能研判。
角色
数据工程师（排查依赖）+ IT 管理员（检查 LLM 网关配置与降级链）。
操作步骤
  1. 检查 LLM 网关路由表与 Provider 健康状态，确认失败原因
  2. 确认降级链：主 Provider 不可用是否自动切换备用
  3. 业务降级：让分析师改用 Foundry 对象查询 / 语义检索取数
  4. 研判降级：Gotham 图分析 / 实体解析均为本地算法，不受影响
  5. 恢复后重放关键查询并核对审计
系统响应
AIP 查询返回失败或降级提示（Provider unavailable / degraded=true）；LLM 网关返回错误码 LLM_PROVIDER_UNAVAILABLE；Foundry 对象查询与 Gotham 图接口正常返回——因为它们是本地计算。
结果洞察
断网 2 小时内，靠 Foundry + Gotham 的本地能力保住了取数与研判，只有"一句话 AI 查数"停摆。结论：AI 是增强不是地基，关键业务路径要备本地兜底。
调整建议
给 LLM 网关配多 Provider 路由与降级链；把"离线演练"纳入上线 SOP。相关阅读：LLM 网关与模型路由、Foundry 语义查询。
动手试一试
尝试：临时停掉 LLM key 后打开 AIP /chat 查询，观察失败提示；再打开 Foundry 对象查询，确认本地查询不受影响。目的：亲身体验降级边界。
限制提示
Text2SQL 无 key / 离线时生成不了 SQL；语义检索向量增强默认关闭；实体解析 AI 增强默认关闭（仅相似度算法）；多 Provider 降级链配置取决于网关路由表是否完备。
故事 3 集成边界：为什么不能"一个账号登录所有产品"
场景：集成评估 角色：IT 管理员 + 决策者 耗时：约 10 分钟
背景
老板问 IT 负责人："AIP 里能不能直接查 Gotham 的图谱？能不能用 Apollo 一键把整套系统部署上线？"答案并不都是"能"。小周把这些集成边界整理成一张"能 / 不能 / 替代方案"清单，避免团队对外乱承诺。
传统做法对比
以前厂商常以"规划中"模糊处理，客户上线才发现要手工衔接；现在边界提前白纸黑字：独立登录、用户库不互通、语义层未打通、Swift 为仿真域——每一条都配替代方案。
角色
IT 管理员（账号 / 权限 / 集成评估）+ 决策者（承诺口径）。
操作步骤
  1. 确认各产品独立登录：AIP 18080 / Foundry 18081 / Apollo 18082 / Gotham 18083 各自 JWT
  2. 确认演示数据不互通：三套 demo 库人名相近但字段独立
  3. 确认边界项：Swift 为仿真域（模拟数据非真实在轨）、监控告警 V2、Apollo Git 真相源 P2
  4. 给出替代方案：统一口令 + 审计兜底、手工导数据衔接、各自 /ops 看健康
  5. 把"单点登录 / 语义层打通"登记为后续版本愿景
系统响应
切换产品需要重新登录（各自返回独立 JWT）；/ops 运维健康页四服务健康卡可统一查看各后端存活；各产品审计日志独立，跨产品追查要分别查。
结果洞察
把边界讲清楚后，老板的预期回到现实：五款产品是"一套底座上的五个独立系统"，集成是路线图目标不是现状。诚实的边界清单让对外承诺有了依据。
调整建议
对外用统一话术"四产品已交付、各自可演示、集成在路线图"；对内把 限制综述 作为销售 / 交付培训必读。相关阅读：AIP 安全治理、Gotham ABAC。
动手试一试
尝试：同时打开 18080（AIP）与 18081（Foundry）两个登录页，分别用 admin / admin1 登录，观察各自会话与导航。目的：直观理解"独立登录、独立 JWT"。
限制提示
跨产品用户库不互通，无单点登录；Swift 为仿真域 PoC，不能当真实在轨/真实清算承诺；Apollo 演示 Poller 不真实部署进程；监控 / 告警 / 自愈属 V2——集成与运维能力以 Roadmap 为准。

常见问题

这些边界会一直存在吗？

不会。本页描述的是当前实现状态的快照。Roadmap 里已列明演进：P2 扩展管道与查询、P3 上 Git 真相源、V2 补监控告警、后续打通语义层与单点登录。边界综述需要随版本持续更新。

哪些限制是"硬"的、哪些是"软"的？

硬限制：Swift 为仿真域（非真实在轨/真实清算）、AIP 依赖外部 LLM、跨产品用户库不互通、单机容量上限——当前就是做不到。软限制：Gotham 展开 3 度 / 1000 节点、AIP 100 行、实体解析 AI 增强关闭——属配置或后续版本可解除。

演示数据每次重启重建，会不会影响演示？

不影响演示效果，但影响"留档"：demo 数据源（AIP / Foundry）与 Gotham 演示数据会在启动时重建，临时改动重启还原；平台元数据、审计、版本记录保留。要长期数据请接 PostgreSQL 正式数据源。

边界清单应该给谁看？

给三类人：演示人员（避免翻车）、销售 / 交付（避免乱承诺）、决策者（选型依据）。对内建议作为必读材料，对外作为"能力边界说明"附在方案里。

主题小结

一句话：五产品共同的底线是——单机优先（TB 级上限）、AI 依赖外部 LLM（离线降级靠本地算法）、跨产品集成未打通（独立登录 / 数据不互通 / Swift 为仿真域）。每个限制都有替代方案；边界综述是快照，随 Roadmap 演进持续更新。