业务故事站
跨产品

综合演示：一个业务事件贯穿多系统

"华东销售额下滑"——这个业务事件如何在四款产品间流转：AIP 先发现异动（智能），Foundry 定位口径变化（数据），Gotham 追查客户关系异常（决策），Apollo 部署修复配置（交付）。看完这 4 个故事，你就掌握了"一次业务事件的多系统作战"打法。

业务分析师 数据工程师 情报分析师 运维工程师 销售异动 共 4 个故事

能 / 不能速览

✅ 这套平台能做
  • 一个业务事件从"发现 → 定位 → 研判 → 修复"四个环节各由一个产品承接
  • 每环节都有真实 API / 页面返回：AIP 的 SQL 与图表、Foundry 的血缘与口径、Gotham 的链路与聚类、Apollo 的部署与 diff
  • 环节之间靠"人"串起来：分析员把结论传给数据工程师，再传给情报与运维
  • 全程留痕：NLQ 审计、Action 写回审计、部署记录都能回溯
⛔ 这套平台做不了
  • 跨产品不能自动编排：AIP 侧虽有工作流引擎，但发现异动后不会自动触发 Gotham 或 Apollo，四步仍需人工接力
  • 跨库数据不能自动关联：AIP 的张三和 Foundry 的张三要人工比对
  • Apollo 演示 Poller 不真实拉起进程，"修复"是配置层面的收敛不是服务重启
  • AIP 是"问了才答"，没有定时巡检 / 业务阈值告警主动报异动；Apollo 的告警针对部署与配置健康，不覆盖业务指标

适用角色

一次异动作战需要四类角色接力：

  • 业务分析师：AIP 查数发现异动，是"发令枪"。
  • 数据工程师：Foundry 血缘 / 口径定位"数字为什么变了"。
  • 情报分析师：Gotham 图谱追查"是不是客户 / 渠道出了问题"。
  • 运维工程师：Apollo 部署新配置，把修复推下去并防漂移。

能力速览（事件作战）

发现（AIP）

一句话查各区域销售额，聚合 + 对比图表 30 秒出数，异动一眼可见，SQL 可核对。

定位（Foundry）

指标血缘四级链路（源 → 管道 → 对象 → 指标 → 报表）+ 版本历史 diff，定位口径变化而非真实下滑。

研判（Gotham）

把下滑区域大客户放进图谱做展开 / 最短路径 / 中心度，找共同联系人、异常渠道，形成证据链。

修复（Apollo）

新配置作为期望状态版本登记、激活、部署，DAG 门控 + 漂移 reconcile + 失败自动回滚。

界面操作指引（不写代码怎么用）

下面按「打开哪个页面 → 点哪里 → 填什么 → 看到什么」的顺序给出完整操作路径，业务用户照做即可。每步末尾的「API 等价」是给工程师对照用的，可以忽略。

1 发现：在 AIP「智能查询」提出第一个问题 AIP 控制台（18080）→ 左侧菜单「智能查询」
  • 怎么做：用 admin / admin1 登录 AIP，进「智能查询」（/chat），输入区的「数据源」下拉可保持「自动（按问题路由）」，输入「查询最近一周各区域订单销售额」并提交。
  • 会看到：返回意图、置信度、可核对的 SQL、结果表格与图表推荐；对比后华东数值显著低于华北 / 华南。把返回的 SQL 与数字同步给数据工程师。

API 等价：POST /api/v1/chat

2 定位：在 Foundry 用血缘 + 指标 + 版本历史找出真相 Foundry 控制台（18081）→ 数据血缘 / 指标管理 / 版本历史
  • 怎么做：登录 Foundry，打开「数据血缘」（/foundry/lineage）看 total_gmv 的四级链路（源 → 管道 → 对象 → 指标 → 报表）；到「指标管理」（/foundry/metrics）核对 formula 与过滤条件；到「版本历史」（/foundry/versions）看 order 对象最近一次变更的 change_diff。
  • 会看到：血缘图指出口径变化发生在哪一层，版本历史给出变更前后 diff——结论是口径改了，而不是真实下滑。

API 等价：GET /api/v1/lineage、GET /api/v1/metrics、GET /api/v1/ontology/objects/:id/versions

3 研判：在 Gotham 把客户名单变成图谱并追关系 Gotham 控制台（18083）→ 多源接入 / 图谱映射 / 情报工作台
  • 怎么做：登录 Gotham，到「多源接入」（/gotham/ingestion）把华东大客户名单建成 CSV 源并导入；到「图谱映射」（/gotham/graph-mapping）配置节点类型与属性字段映射；回「情报工作台」（/gotham）对关键节点做 2 度展开、跑最短路径「大客户 A → 异常渠道 B」、用中心度排名确认枢纽节点。
  • 会看到：图谱出现节点与边，展开时邻居高亮并暴露共同联系人；最短路径给出关联链路，中心度排名列出枢纽；结论形成证据链。

API 等价：POST /api/v1/ingestion/sources、GET /api/v1/analysis/graph/expand、GET /api/v1/analysis/graph/path、GET /api/v1/analysis/graph/centrality

4 修复：在 Apollo 登记并激活新版本期望状态 Apollo 控制台（18082）→ Git 仓库 / 部署与漂移
  • 怎么做：登录 Apollo，把修复后的配置写成期望状态 v1.1.0 放进本地 Git 目录，在「Git 仓库」（/apollo/git-repos）的同步目标点「同步」把它落库并激活。
  • 会看到：提示「同步目标 #id 同步成功：commit …」，期望状态变为 active，出现在「部署与漂移」页「发起部署」的期望状态下拉里。

API 等价：POST /api/v1/sync-targets/:id/sync

5 修复：发起部署并推进到 synced 部署与漂移 → 发起部署 → 部署行「推进」
  • 怎么做：在「部署与漂移」（/apollo/deployments）点「发起部署」，选 v1.1.0 的期望状态、填 Agent 名称 spoke-01、策略保持 default，提交；展开部署行，用「推进」把组件依次上报 ready。
  • 会看到：DAG 分批放行（web 依赖 db，db 先 ready）；全部推进完成后部署转 synced。若失败会触发自动回滚。

API 等价：POST /api/v1/deployments/start、POST /api/v1/deployments/:id/advance

6 收尾：漂移检测确认收敛，留好回滚点 部署与漂移 → 漂移检测 / 漂移事件列表
  • 怎么做：在「部署与漂移」页用「漂移检测」表单跑一次 detect，确认无 diff；把 v1.0.0 的期望状态保留在历史里作为回滚点。
  • 会看到：检测无漂移、部署维持 synced。历史期望状态仍可查，回滚始终生成更高版本号的新行。

API 等价：POST /api/v1/drift/check、GET /api/v1/desired-states

提示：四个产品各用独立登录态（端口分别为 18080 / 18081 / 18082 / 18083），跨产品跳转不会被共享登录；这里只是把一条真实业务链路串起来，每段单独操作也可独立演示。

调整指南（怎么调整）

  • 换口径重查：AIP 换了问法、Foundry 改了指标，记得重新核对结论，别拿旧数字开会。
  • 扩研判深度：Gotham 展开限 3 度 1000 节点，深挖时分批展开；图分析接口仅管理员可用。
  • 修配置迭代：Apollo 每次修复都发新期望状态版本（单调版本号），保留历史可回滚，不要原地改线上。
  • 人肉衔接：环节之间结论靠人传递，建议把"发现 → 定位 → 研判 → 修复"沉淀成团队 SOP 文档。

做得好的场景

综合演示最擅长"把一次跨系统作战讲成有过程、有依据、有闭环的故事"：
  • 每环节可演示：四步都有真实页面与 API 返回，演示时不会冷场。
  • 定位不是猜：AIP 只是"发现数字变"，真正"为什么变"由 Foundry 血缘与口径回答。
  • 决策有证据：Gotham 的链路与中心度让"大客户有问题"可引用，不是拍脑袋。
  • 修复可回退：Apollo 版本化部署，改坏了一键回滚。

限制与不足

以下是明确的边界，演示前先知道：
  • 无跨产品自动编排：AIP 的自动化引擎（条件分支、调用 Foundry Action 等节点）只在 AIP 内编排，不会把异动事件自动推给 Gotham 或 Apollo，四个环节仍靠人接力。
  • 跨库不互通：AIP / Foundry / Gotham 三套演示库人名相近但数据独立，跨库比对需人工导数据。
  • Apollo 不真拉起进程：演示 Poller 只拉取 / 上报，配置收敛不等同服务重启。
  • demo 数据每次启动重建：异动数字、修复结果重启后还原，适合演练不适合留档。

场景故事

故事 1 发现：王姐在 AIP 查各区域销售额，华东明显下滑
环节：发现 角色：业务分析师 耗时：约 30 秒
背景
7 月销售例会前，王姐在 AIP /chat 输入"查询最近一周各区域订单销售额"，本想例行过一遍数字，结果华东的柱子明显比上周矮一截。她意识到这不是常态，异动作战就此打响。
传统做法对比
以前等周报 Excel 汇总，异动被发现时往往已过两周；想对比上周还要手工 VLOOKUP。现在一句话 + 图表 30 秒出对比，异动当天就能被发现。
角色
业务分析师（AIP /chat 查询权限）；她把"华东异动"这个事件作为发令枪，依次传给数据、情报、运维。
操作步骤
  1. 登录 AIP（18080，admin / admin1）
  2. （可选）在输入区「数据源」下拉保持「自动（按问题路由）」，或指定要查的活跃源
  3. /chat 输入"查询最近一周各区域订单销售额"
  4. 看返回图表，华东数值显著低于华北 / 华南
  5. 复制返回的 SQL 与数字，同步给数据工程师张工
系统响应
返回结构示例：
{
  "intent": "aggregate",
  "sql": "SELECT region, SUM(amount) FROM orders WHERE created_at >= date('now','-7 day') GROUP BY region",
  "result": [{"region":"华东","total":8600.0},
             {"region":"华北","total":12900.0},
             {"region":"华南","total":11400.0}],
  "chart_type": "bar"
}
同时写入审计（NLQ_QUERY）。
结果洞察
华东 8600 vs 华北 12900，异动实锤。但 AIP 只回答"数字变了"，不回答"为什么变"——这正是下一个环节（Foundry 定位）的活。
调整建议
把查询条件说全（时间范围、区域）减少意图歧义；异动判断可对比"本月 vs 上月"双查询。相关阅读：AIP 复杂分析。
动手试一试
登录：http://127.0.0.1:18080（admin / admin1）。输入："查询各区域订单销售额"。预期结果：返回各区域聚合数字与 bar 图表，可肉眼对比区域差异。
限制提示
AIP 意图识别是关键词规则，问法太绕可能查偏；一次只查一个数据源——可用输入区「数据源」下拉强制指定某个活跃源（指定不存在的源会被 400 拒绝），但多数据源联合查询未实现；demo 订单日期相对启动时刻生成，重启后"最近一周"范围会变。
故事 2 定位：张工在 Foundry 用血缘 + 版本历史找到口径变化
环节：定位 角色：数据工程师 耗时：约 15 分钟
背景
王姐把华东异动发给数据工程师张工。张工不急着信"销售下滑"，先去 Foundry 看 total_gmv 的血缘和 order 对象的版本历史——数字波动很多时候是口径变了，不是业务变了。
传统做法对比
以前口径变更靠群消息通知，改没改全凭记忆；对不上账就互相甩锅，反复排查大半天。现在血缘图一眼看到指标链路，版本历史里有 change_diff，定位口径变化只要十几分钟。
角色
数据工程师（Foundry 血缘 / 版本 / 指标管理权限）。
操作步骤
  1. 登录 Foundry（18081，admin / admin1）
  2. 打开血缘图，查看 total_gmv 的四级链路（源 → 管道 → 对象 → 指标 → 报表）
  3. 到指标管理核对 total_gmv 的 formula 与过滤条件
  4. 打开版本历史看 order 对象最近一次变更的 change_diff
系统响应
血缘返回链路节点列表；指标返回 formula（如 SUM(amount) WHERE status='shipped'）；版本历史返回 change_diff 与影响分析（指出受影响指标 total_gmv / aov）。
结果洞察
真相大白：order 对象最近一次合入把 status 过滤条件从"全部订单"改成了"仅 shipped"，未发货订单被排除，华东"销售下滑"其实是口径变化，不是业务崩了。事件从"发现"进入"定位"。
调整建议
口径变更必须走版本合入并通知消费方；把影响分析结果同步给分析师，避免拿着旧结论开会。相关阅读：数据血缘、版本治理。
动手试一试
登录：http://127.0.0.1:18081（admin / admin1）。操作：血缘页选 total_gmv 看链路；版本历史看 order 的变更记录。预期结果：看到四级血缘与带 diff 的版本记录。
限制提示
血缘是"浓缩版"（四级模型），不是逐字段级全量血缘；跨数据源管道未实现；demo 数据每次启动重建，版本与审计保留在平台库但源表改动还原。
故事 3 研判：苏雯在 Gotham 追查华东大客户背后的渠道与关系
环节：研判 角色：情报分析师 耗时：约 20 分钟
背景
口径排查确认数字可信后，真正的业务疑点浮现：华东下滑区域的大客户名单里，有几个名字同时出现在某个异常渠道的名单上。苏雯把这些名字放进 Gotham 玄武集团关系网络，看它们是不是同一伙人、有没有共同联系人。
传统做法对比
以前名单人肉比对 + Excel VLOOKUP，2000 条关系比对 3 天，链路对不对靠肉眼，报告没人复核。现在导入图谱 2 度展开 + 最短路径 + 中心度，链路清晰可引用。
角色
情报分析师（图分析接口需 admin 角色）；合规顾问可配合实体解析做跨源归并。
操作步骤
  1. 登录 Gotham（18083，admin / admin1）
  2. 把华东大客户名单经数据接入导入图谱（CSV / 手工节点）
  3. 对关键节点做 2 度展开，看邻居与共同联系人
  4. 用最短路径跑"大客户 A → 异常渠道 B"的关联
  5. 用中心度排名确认枢纽节点，形成结论
系统响应
展开返回邻居节点列表并高亮；最短路径返回路径数组；中心度返回排名榜单；实体解析返回聚类（≥0.90 自动合并、0.70~0.90 待审）。
结果洞察
多名"独立"大客户通过同一联系人节点相连，且该联系人与异常渠道直接关联——"感觉有关"升级为可引用的证据链。诚实提示：Gotham 演示数据是玄武集团网络，与 AIP / Foundry 的客户库不同源，名单导入是手工映射，不自动关联。
调整建议
图分析接口仅管理员可用，可给情报员开只读图谱权限；跨源归并交给实体解析作业，别手工猜。相关阅读：多源融合、实体解析。
动手试一试
登录：http://127.0.0.1:18083（admin / admin1）。操作：图工作台对玄武集团展开 2 度；最短路径张远 → 赵敏。预期结果：邻居高亮、路径链路高亮。
限制提示
图存储单机（内存邻接表 + JSON 落盘）、展开限 3 度 1000 节点；实体解析 AI 增强默认关闭仅相似度算法；跨产品数据不互通，需人工导入。
故事 4 修复：陈工用 Apollo 部署新配置，收敛整条链路
环节：修复 角色：运维工程师 耗时：约 15 分钟
背景
事件闭环的最后一环：把修复动作推下去。陈工把"修正后的查询路由配置 / 指标过滤配置"登记为 demo-app 的新期望状态版本 v1.1.0，激活、部署到 spoke-01，再防一手漂移，全程留痕可回滚。
传统做法对比
以前登录服务器手工改配置、重启服务，改错了靠记忆回滚，环境被手改只能靠人肉 diff，一次修复小半天。现在配置走期望状态版本化声明，部署走 DAG 门控，失败自动回滚，收敛有 reconcile。
角色
运维工程师（Apollo 期望状态登记 / 部署 / 回滚权限）。
操作步骤
  1. 登录 Apollo（18082，admin / admin1）
  2. 登记 demo-app 新期望状态 v1.1.0（含修复后的配置项）并激活
  3. 发起部署到 agent=spoke-01，看 DAG 分批放行（web 依赖 db）
  4. 推进组件到 synced，漂移检测确认无 diff
  5. 保留 v1.0.0 历史版本作为回滚点
系统响应
部署返回组件状态与 DAG 分层（db 先 ready → web 放行）；漂移检测返回 JSON Patch diff 列表；收敛后返回"已对齐期望状态"；版本列表新增 v1.1.0（单调版本号递增）。
结果洞察
修复配置按依赖顺序分发完成、全程留痕、可回滚。至此"发现 → 定位 → 研判 → 修复"四环节闭环。诚实提示：演示 Poller 只拉取 / 上报不真实拉起进程，这是配置层面的收敛；真环境需挂载 ProcManager。
调整建议
发布前对 bundle 做验签（SM3 清单 + SM2 签名 + 签名者白名单信任锚）；动态字段配 ignore_paths 减少漂移误报。相关阅读：GitOps 入门、bundle 验签。
动手试一试
登录：http://127.0.0.1:18082（admin / admin1）。操作：发起部署 demo-app 到 spoke-01；漂移检测 detect → reconcile。预期结果：DAG 分批放行、组件推进到 synced、无残留 diff。
限制提示
演示 Poller 不真实部署进程；"Git 即真相源 + 自动 PR"属 P2；Apollo 的告警 / 自愈只覆盖部署与配置健康，不覆盖业务指标的"主动发现"，下一次业务异动仍需人查。

常见问题

四个环节能自动串联吗？

不能自动跨产品串联。AIP 自身有工作流 / 自动化引擎（表单式增删改、条件分支、可调用 Foundry Action），但发现异动后不会自动触发 Gotham 或 Apollo——环节之间没有跨产品编排，四步靠人接力。建议把"发现 → 定位 → 研判 → 修复"沉淀成团队 SOP，配合各产品页面手动操作。

为什么华东下滑最后查出来是口径问题？

因为 AIP 只回答"数字变了"，不回答"为什么变"。Foundry 的血缘与版本历史能定位到 order 对象最近合入把 status 过滤改成了"仅 shipped"——数字波动往往是口径或数据问题，先排查再信业务下滑。

三套演示数据为什么不打通？

AIP（aip_demo_warehouse）、Foundry（foundry_demo_warehouse）、Gotham（玄武集团网络）是三套独立演示数据，人名相近但字段不同、互不联通。跨域追查需手工导数据，这是当前最真实的集成边界，也是后续语义层联动的目标。

这个综合演示适合给谁看？

适合给业务决策者和客户做产品演示：一个"华东销售异动"事件，四步走完发现 / 定位 / 研判 / 修复，每步都有真实页面与返回，是五产品协同叙事最直观的开场。

主题小结

一句话：一个业务事件的跨系统作战 = AIP 发现（智能）→ Foundry 定位（数据）→ Gotham 研判（决策）→ Apollo 修复（交付）。四步都能演示、都有依据、都可回退；但记住：无跨产品自动编排、跨库不互通、Apollo 演示不真拉起进程、AIP 不主动巡检报异动。