业务故事站
跨产品

价值链闭环：从数据到决策再到创新

一条业务线如何闭环：Foundry 把数据变成本体与指标（数据）→ AIP 让业务一句话查数（智能）→ Gotham 追查数字背后的人与关系（决策）→ Apollo 把能力安全交付到每个环境（交付）→ Swift 把结算延伸到星基金融（创新·仿真 PoC）。看完这 5 个故事，你就明白为什么五款产品是一套系统。

数据工程师 业务分析师 情报分析师 运维工程师 决策者 价值链 Swift 为仿真域 PoC 共 5 个故事

能 / 不能速览

✅ 这套平台能做
  • 一条业务线从数据建模到智能问答、深度研判、交付运维的完整闭环
  • 同一份业务在四个产品各有侧重：建模 / 查数 / 追查 / 部署，各取所长
  • 演示数据、端口、账号彼此独立，一个浏览器切换体验全部四款已交付产品
  • 每类能力都有对应产品主题页可深入阅读（故事里带"相关阅读"链接）
  • Swift 仿真 PoC 把闭环延伸到跨境结算：报文、国密、星地链路、复式记账、对账全链路可跑（仿真域）
⛔ 这套平台做不了
  • 四产品各自独立登录、用户库不互通，不能"一次登录全平台"
  • 三套演示数据人名相近但互不联通，不能自动跨库关联
  • Apollo 演示 Poller 不真实部署进程，"跨产品自动分发"是 P2 愿景
  • Swift 为仿真域 PoC：星座拓扑、链路、账户余额、外部清算通道均为模拟数据/逻辑，非真实在轨系统

适用角色

价值链上的五个环节各有一类主角：

  • 数据工程师：在 Foundry 建本体、管指标、跑管道——价值链的"数据"起点。
  • 业务分析师：在 AIP 一句话查数、核对口径——"智能"环节的消费者。
  • 情报分析师：在 Gotham 追查客户背后的关系网络——"决策"环节的深度研判。
  • 运维工程师：用 Apollo 把能力分发到各环境并防漂移——"交付"环节的保障。
  • 决策者：消费各环节的结论与报告，评估价值链投入产出——不直接操作。

能力速览（跨产品协作）

数据 → 智能

Foundry 把表建模为 customer / order 对象、定义 total_gmv / aov 口径；AIP 的 NLQ 消费这套语义，问"华东销售额"才有统一依据。

智能 → 决策

AIP 出数后，Gotham 用图分析、实体解析追查订单客户背后的企业网络，把数字结论升级为带证据链的研判。

决策 → 交付

Apollo 把本体定义、模型路由、应用配置作为 bundle 制品声明式分发，期望状态 + Spoke 拉取，控制面永不主动连入。

交付 → 创新

Swift 仿真 PoC 复用 Apollo 的拉取更新机制与 Foundry 的对象 / Action 模型，把价值链延伸到星基跨境结算（仿真域已实现，非真实在轨）。

统一底座

五产品共享 Go 单机底座、admin / admin1 登录、各自 /ops 运维健康页；演示数据启动即就绪，开箱可跑。

调整指南（怎么调整）

  • 改数据口径：到 Foundry 指标管理维护 total_gmv / aov，口径变更走审批；AIP 问法也要跟着改，当前两库语义未自动打通。
  • 改问法：AIP 意图识别是关键词规则，问不出结果就换直白关键词（"销售额""订单数"），或到 Foundry 语义检索先探路。
  • 改研判深度：Gotham 图分析接口仅管理员可用，展开限 3 度、limit 上限 1000；要更深就分批展开。
  • 改部署方式：Apollo 期望状态 YAML 里改组件 / 依赖 / 探针，激活即生效；漂移用 ignore_paths 忽略动态字段。
  • 改集成预期：跨库关联当前只能手工导数据；把"一次登录全平台、语义自动打通"登记为后续版本愿景，不在本期承诺。

做得好的场景

跨产品价值链最擅长"把一次业务闭环讲清楚、每层都可演示可验证"：
  • 30 分钟走通一条价值链：数据建模 → 智能查数 → 关系研判 → 部署交付，每步都有真实页面与返回，不是 PPT。
  • 各取所长不抢戏：建模的事 Foundry 干、查数的事 AIP 干、追查的事 Gotham 干、分发的事 Apollo 干，角色清晰。
  • 边界诚实：Swift 明确标注"仿真域 PoC"（星座/链路/结算为模拟），跨库不互通、独立登录都写进限制提示，演示时不会翻车。

限制与不足

以下是明确的边界，演示前先知道：
  • 各产品独立登录：AIP 18080 / Foundry 18081 / Apollo 18082 / Gotham 18083 各自独立 JWT，用户库不互通。
  • 演示数据不互通：三套 demo 人名相近（张三 / 李四 / 王五）但互不联通，跨域追查需手工导数据。
  • Swift 为仿真域：P5 已实现 PoC 可登录演示，但星座拓扑/链路延迟/账户余额/外部清算均为模拟数据与逻辑，不是真实在轨系统。
  • 单机优先：Gotham 图存储内存邻接表 + JSON 落盘、AIP 一次一源、Foundry 轻量查询，TB 级是硬上限。
  • 演示数据每次启动重建：各产品 demo 数据源重启还原，临时改动不持久（平台元数据与审计保留）。

场景故事

故事 1 张工在 Foundry 把订单数据建模成本体 + 指标（数据环节）
场景：本体建模 角色：数据工程师 耗时：约 15 分钟
背景
张工是"订单分析小组"的数据工程师。演示库 foundry_demo_warehouse 里躺着 customers / orders / products 三张表，销售下周要看"销售额"但没人说得清口径。他的任务：把订单表建成 order 对象，并定义 total_gmv、aov 两个指标，让整条价值链从这口"井"里取水。
传统做法对比
以前要先画 ER 图、写建表 SQL、找 IT 排接口排期，快则 3~7 天；口径靠群里发 Excel 对暗号，同一个"销售额"三份报表三个数。现在在平台里十几分钟把表建成对象、指标集中定义，一套口径全场复用。
角色
数据工程师（本体建模 + 指标管理权限）；后续由业务分析师、AIP 的 NLQ 共同消费这套对象与口径。
操作步骤
  1. 登录 Foundry（端口 18081，admin / admin1）
  2. 数据源确认 foundry_demo_warehouse 已注册并导入元数据
  3. 本体工作台新建 order 对象，映射 order_id / customer_id / amount / status / region 属性
  4. 指标管理定义 total_gmv（SUM(amount)）与 aov（total_gmv / 订单数）
  5. 对象查询选中 order 验证能查出 5 条订单
系统响应
对象创建返回结构示例：
{
  "api_name": "order",
  "base_table": "orders",
  "properties": ["order_id", "customer_id", "amount", "status", "region"],
  "version": 1
}
指标 total_gmv 返回 formula 与 dimensions，侧边栏对象列表立即出现 order。
结果洞察
order 对象可查、total_gmv / aov 口径统一，"数据 → 智能"的地基就此落成。后续 AIP 问"华东销售额"、Gotham 追查客户，都从这一套语义出发——这是整条价值链的第一口井。
调整建议
给 region 属性加同义词（"区域、大区"）提升语义检索命中率；给 name 打 PII 标记，列级安全自动生效。相关阅读：Foundry 本体建模、Foundry 指标语义层。
动手试一试
登录：http://127.0.0.1:18081，admin / admin1。页面路径：数据源 → 本体工作台 → 新建对象；指标管理定义 total_gmv。预期结果：对象查询选 order 返回 5 条订单（张三·华东 / 李四·华北 / 王五·华南），指标 total_gmv 可取数。
限制提示
对象查询是"OOL 轻量版"——单对象、最多 3 层深、禁点号；语义检索向量增强默认关闭；demo 数据源每次启动重建，临时改动重启还原。
故事 2 王姐在 AIP 用一句话问"华东订单销售额"（智能环节）
场景：NLQ 查数 角色：业务分析师 耗时：约 30 秒
背景
销售例会前 5 分钟，总监问王姐"华东这周销售额多少"。王姐不会 SQL，打开 AIP 的 /chat，把这句话直接敲进去——这就是价值链的"智能"环节：让业务用自然语言消费数据。
传统做法对比
以前提工单给数据团队，等 1~2 天拿临时报表；或自己学 SQL、拖 BI，半小时起步。现在一句话 30 秒出数，带 SQL 可核对、带图表可上会。
角色
业务分析师（有 AIP 登录权限即可，无需写 SQL）；IT 管理员保证数据源与 LLM key 就绪。
操作步骤
  1. 登录 AIP（端口 18080，admin / admin1）
  2. 进入智能查询 /chat
  3. 输入"查询华东地区订单的销售额"（或点示例问题）
  4. 查看返回的意图 / 置信度 / SQL / 结果表格 / 图表推荐
  5. 对关键数字核对一遍 SQL 后拿去上会
系统响应
返回结构示例：
{
  "intent": "aggregate",
  "confidence": 0.91,
  "sql": "SELECT region, SUM(amount) AS total FROM orders WHERE region='华东'",
  "result": [{"region": "华东", "total": 12860.0}],
  "chart_type": "metric_card"
}
同时写入审计日志（NLQ_QUERY），"谁查了什么"可回溯。
结果洞察
30 秒出数、链路全透明。注意：AIP 演示库是 aip_demo_warehouse（张三·上海 / 李四·北京 / 王五·广州），与故事 1 里 Foundry 的 foundry_demo_warehouse 是两套库——"华东"要按 AIP 库里的区域关键词来问，语义层当前未自动打通，这是诚实边界。
调整建议
问不出就换直白关键词（"销售额""订单数量"）提高意图命中；重要数字务必核对返回的 SQL。相关阅读：AIP NLQ 入门、意图识别与 RAG 检索。
动手试一试
登录：http://127.0.0.1:18080，admin / admin1。页面路径：/chat。输入内容："查询所有订单"或"查询华东地区订单的销售额"。预期结果：返回意图 / SQL / 结果表格 / 图表推荐。
限制提示
意图识别是关键词规则，口语化 / 省略句命中率不稳定；Text2SQL 依赖外部 LLM（deepseek-v4-flash 经平台网关），无 key / 离线时生成不了 SQL；一次只查一个数据源。
故事 3 苏雯在 Gotham 追查订单客户背后的企业网络（决策环节）
场景：图谱研判 角色：情报分析师 耗时：约 20 分钟
背景
王姐查出的华东大客户名单里有几个名字，销售觉得"背后可能是一伙的"。苏雯是情报分析师，她在 Gotham 把这份名单放进玄武集团关系网络做关联追查，看看这些客户之间有没有共同的联系人、资金往来——这就是价值链的"决策"环节。
传统做法对比
以前靠纸质名单 + Excel VLOOKUP 人肉比对，2000 条关系比对 3 天起步，链路对不对靠肉眼，出了报告也无法快速复核。现在把名单导进图谱，2 度展开、最短路径、中心度一套算法下来，链路清晰可引用。
角色
情报分析师（图分析接口需要 admin 角色）；合规顾问用实体解析做跨源同人归并。
操作步骤
  1. 登录 Gotham（端口 18083，admin / admin1）
  2. 打开图工作台浏览玄武集团关系网络（10 节点 8 边）
  3. 选中"玄武集团"做 1~2 度展开，看邻居高亮
  4. 用最短路径跑一遍"张远 → 赵敏"的资金链路
  5. （可选）到实体解析跑一个作业，看跨源同名是否归并
系统响应
展开返回邻居节点与边列表并高亮；最短路径返回路径节点数组（如 玄武集团 → 张远 → 赵敏）；实体解析返回聚类分组与分数（≥0.90 自动合并、0.70~0.90 待人工审核）。
结果洞察
几分钟把"感觉有关"变成可引用的链路与证据链。但诚实说明：Gotham 演示库是玄武集团网络（张远 20 万 / 赵敏 12 万等），与 AIP / Foundry 里的"张三 / 李四"同名不同库、互不联通，跨域追查需手工导数据——这恰恰是当前集成边界最真实的体现。
调整建议
图分析接口仅 admin 可用，给业务分析员开只读图谱浏览权限即可；展开超 3 度或超过 1000 节点会报错，分批展开。相关阅读：Gotham 图分析、实体解析。
动手试一试
登录：http://127.0.0.1:18083，admin / admin1。页面路径：图工作台。输入内容：点击玄武集团 → 展开 2 度；最短路径张远 → 赵敏。预期结果：邻居高亮、路径链路高亮。
限制提示
图存储是自研磁盘实现（内存邻接表 + JSON 落盘），单机 TB 级上限；图分析仅 admin 角色可用、展开限 3 度 1000 节点；实体解析 AI 增强层默认关闭，仅相似度算法。
故事 4 陈工用 Apollo 把分析能力分发到各环境并防漂移（交付环节）
场景：GitOps 部署 角色：运维工程师 耗时：约 15 分钟
背景
价值链前三环跑通后，这套分析能力要部署到演示 / 测试环境。陈工是运维工程师，他用 Apollo 的期望状态声明 demo-app（web 组件依赖 db 组件），交给 spoke-01 拉取部署，再防一手漂移——这是价值链的"交付"环节。
传统做法对比
以前 SSH 登录服务器手工拷包、改配置、重启，5 台机器一晚上；环境被手改了只能人工 diff，出问题靠记忆回滚，一次发布半天到一天。现在声明一次、批量分发，漂移自动检测、reconcile 收敛。
角色
运维工程师（发起部署 / 推进 / 回滚）；安全合规工程师管 bundle 验签与签名者白名单。
操作步骤
  1. 登录 Apollo（端口 18082，admin / admin1）
  2. "期望状态"确认 demo-app 已激活（v1.0.0、web→db 依赖、tcp 探针）
  3. 到"部署"发起部署 demo-app 到 agent=spoke-01
  4. 看 DAG 分批放行（db 先 ready，web 后放行），手动推进到 synced
  5. 到"漂移检测"体验一次 detect → reconcile 收敛
系统响应
部署返回组件状态（pending → ready → synced）与 DAG 分层；漂移检测返回 JSON Patch 路径级 diff（如 {"op":"replace","path":"/config/port","value":8081}）；reconcile 后返回"已收敛到期望状态"。
结果洞察
声明即期望、激活即可部署，能力按依赖顺序安全分发；配置被手改能被检测并调和回来，全程留痕、可回滚。这套机制未来就是 Swift 星上更新的复用底座（拉取式更新）。
调整建议
给动态字段配置 ignore_paths 减少误报；发布前用 bundle 验签（SM3 清单 + SM2 签名 + 签名者白名单信任锚）堵住供应链风险。相关阅读：Apollo GitOps 入门、漂移检测。
动手试一试
登录：http://127.0.0.1:18082，admin / admin1。页面路径：期望状态 → 部署 → 漂移检测。输入内容：发起部署 demo-app 到 spoke-01。预期结果：DAG 分批放行、组件推进到 synced、漂移 detect → reconcile 闭环。
限制提示
演示 Poller 仅拉取 / 上报，不真实部署进程（ProcManager 未挂载时不应用）；"Git 即真相源 + 自动 PR"属 P2；监控 / 告警 / 自愈属 V2。
故事 5 孙倩在评审会上演示 Swift：跨境结算的最后一环（创新环节·仿真 PoC）
场景：星基金融仿真 角色：决策者 / 架构评审 状态：已实现 PoC（仿真域）
背景
孙倩是业务拓展经理，她在价值链评审会上演示最后一块拼图：分析出来的一笔订单，最终变成一笔跨境结算。Swift 仿真 PoC 用 ISO 20022（pacs.008 优先）报文引擎 + 结算状态机 + 星地链路仿真 + 国密全链路（SM3+SM2+SM4），在单机 Go 进程里真实跑通"报文生成 → 国密加密 → 链路传输 → 合规风控 → 复式记账结算 → 对账 → 回执"。是已实现的可运行 PoC，但属于仿真域。
传统做法对比
传统跨境结算经代理行、SWIFT 报文、人工复核，到账 2~3 天，节假日停摆；星基金融结算更是空白。Swift PoC 把"分析 → 决策 → 结算"放进同一条价值链，结算链路全程可演示，延迟从"天"级向"分钟"级演进（目标值，仿真环境）。
角色
决策者（业务拓展经理 / 架构评审人）；结算与合规专家（评审仿真结果与边界）。
操作步骤
  1. 登录 Swift（端口 18084，admin / admin1，内嵌登录）
  2. 在报文实验室生成 pacs.008 报文并签名（SM2），做篡改拒绝演示
  3. 在 GAC 报文工具发起一笔支付，观察支付状态机流转
  4. 在 HCC 管控台看链路态势 / 风控合规 / 复式记账结算 / 对账报告
  5. 点"一键演示"跑完 10 步端到端链路（独立引擎，不污染正式数据）
系统响应
返回真实可运行 API 与页面：POST /api/v1/messages/* 报文生成/解析/验签、/api/v1/payments* 支付状态机（DRAFT→SIGNED→SENT→ACKED/REJECTED）、/admin/balance/validate 借贷平衡校验、/admin/reconciliation 对账报告。冒烟 16/16 PASS、前端 E2E 33/33 PASS。
结果洞察
闭环在逻辑与演示上都是完整的：数据 → 智能 → 决策 → 交付 → 创新。诚实是底线：Swift 是仿真域 PoC——星座拓扑（6 星 2 平面 3 站）、链路延迟/丢包、演示账户余额、外部清算通道（CIPS mock）均为模拟数据/逻辑，真实卫星、真实银行清算网络不在本轮范围。
调整建议
对外演示可跑 Swift 10 步端到端，但话术要标注"仿真域"；复式记账、对账、审计哈希链已真实实现，可作为金融结算软件基座继续演进。相关阅读：Swift 愿景、结算场景、架构设计。
动手试一试
登录：http://127.0.0.1:18084（admin / admin1）。操作：报文实验室生成 pacs.008 → GAC 发起支付 → HCC 看结算/对账；或直接 POST /demo/run 跑一键演示。预期结果：10 步端到端全成功，账户借贷平衡。
限制提示
Swift 为仿真域 PoC：星座/链路/账户/外部清算均为模拟，非真实在轨；星上处理 <4ms 是学术推断值，需在目标硬件实测；ISO 20022 pacs.008 为主路径，MT103 只做只读兼容；真实卫星、真实 CIPS/SWIFT 接入为规划中（V2/V3）。

常见问题

这五个故事是同一个数据在流转吗？

逻辑上是同一类业务（订单分析），但演示数据是各产品独立的：AIP 的 aip_demo_warehouse、Foundry 的 foundry_demo_warehouse、Gotham 的玄武集团网络互不联通。故事把它们串成一条价值链叙事，但"数据真正自动流转"是后续集成愿景，当前需手工导数据衔接。

为什么 AIP 和 Foundry 都有"张三"？

两套演示数据都用了相近的中文姓名（张三 / 李四 / 王五）但属于不同库、不同字段。这个"同名不同库"恰好制造了真实的跨域追查需求——比如想确认 Foundry 的张三和 AIP 的张三是不是同一个人，当前只能靠手工比对，这也是价值链上最现实的缺口。

从哪一环开始体验最好？

按价值链顺序：先 Foundry 建对象（故事 1）→ AIP 查数（故事 2）→ Gotham 研判（故事 3）→ Apollo 部署（故事 4）→ Swift 仿真 PoC（故事 5）。五个产品都是 admin / admin1 登录，各产品 /ops 健康页可统一查看服务状态。Swift 可登录演示但为仿真域。

价值链各环节有没有"一把手"产品？

没有。价值链强调各取所长：建模找 Foundry、查数找 AIP、追查找 Gotham、交付找 Apollo。这正是对标 Palantir 产品矩阵的核心理念——每个环节用最擅长的那款，而非一个超级系统包打天下。

主题小结

一句话：价值链闭环 = Foundry 管数据、AIP 出智能、Gotham 助决策、Apollo 保交付、Swift 拓创新（仿真域 PoC）。五款产品均已交付可演示，一套 admin / admin1 走遍；记住边界：独立登录、演示数据不互通、单机 TB 级上限、AI 依赖外部 LLM、Swift 为仿真域（星座/链路/结算为模拟数据）。