面向业务与 FDE 的入门地图 · 对应厂商 V5（2026-08-30）
这是一套对标 Palantir 产品矩阵的国产自研平台：五款产品、一套共享底座、全部用 Go 写成单机可跑的二进制。 它要解决的不是「再做一个 BI」，而是把数据的口径、AI 的行为、部署的动作三件事， 收进同一套可审计、可回滚、可声明的规则里。
本页把 85 个后端模块、104 个功能页面压缩成一张地图：先看整体架构，再看五个产品各管什么、 它们如何串成一条闭环，最后是两条流程图（怎么建、怎么用）、角色分工，以及诚实的能力边界。 不需要任何技术背景就能读完。
一句话：把企业里散落的数据变成有统一口径的业务对象，让人和 AI 都只能通过同一道受管控的门去读它、改它。
大多数数据平台停在「把数据查出来」。ZY Action Platform 多走了三步，而这三步恰恰是业务上最痛的地方：
total_gmv 的指标定义，谁引用都是同一个算法。「Action」这个名字就来自第二条——平台的核心资产不是报表，是动作（Action）：一个被定义好参数、校验规则、权限和回写方式的写操作。 这也是它敢让 AI 碰生产数据的原因。
厂商文档里反复出现的 R1–R4，是这套系统一切取舍的依据。理解了这四条，后面所有的机制都会显得理所当然。
口径、术语、表列语义捆在一起，本体和检索双向打通，绝不把裸表直接丢给大模型去猜。AI 查得准，靠的是这层语义，不是模型更强。
一切写操作必须走 Action 定义。Agent 和人受完全相同的约束——不是给 AI 单独加一层护栏，而是根本没有第二条路可走。
不引消息队列、不引服务注册、不引外部图库。把分布式系统的机制（拉取式、声明式、离线包）做进单机内核，而不是先做个玩具版将来重写。
本体、Agent 配置、评测集、网关路由、部署期望状态，用同一套 Schema 表达、同一个包分发。跨产品复用的是模型本身，不是接口调用。
本页所有能力描述都来自厂商 V5 文档（docs-ZY-V5/，2026-08-30）。凡是文档自己标注为「未实现 / 规划中 / 仿真」的，本页一律照实标注，不做善意补完。第 11 节专门讲边界。
厂商在 2026-08-29/30 用 S0–S6 七个阶段做了一次整体升级。如果你看过上一版，这一节告诉你差别在哪。
上一版的形状是「四个产品跑通了主干」。V5 补的基本都是把主干变成日常可用的那些东西—— 长任务能看进度了、数据能进平台落成资产了、分析过程能沉淀成 Notebook 和报表了、 数据一变就能自动触发动作了，以及一整套让外部系统接得进来的标准接口。
补上了三块地基：统一调度器（各产品不再各建一套 cron）、异步任务系统（导入元数据、跑管道这种慢操作不再让页面干等，五种状态 + 进度条）、资源 URI（14 类资源有了统一地址格式，跨产品互相引用的前提）。
数据终于能「进平台」而不只是「连过去查」：数据集成为一等资产（可版本发布、可预览、可画像），全量/增量同步把外部数据按计划抽进来，质量画像用四个因子给数据打分，SQL 工作台让你直接用对象名写 SQL。
AI 侧从「查数」扩到「知识」：文档里能抽实体和关系并接进检索（RAG 从四路召回变五路），决策证据链让每个 AI 答案都能逐条追到出处，CDC 能感知源表变化，PDF/Word 解析成「文档—章节—片段」三层树。
分析过程变成可交接的资产：Notebook（文字/SQL/图表三类单元格混排）、块式报表（定时生成快照 + 邮件分发）、Fusion 实体消解（把重复的客户记录合成一条）、流事件规则（数据一变就触发通知/同步/回写）。安全侧补了 TOTP 双因子和审计归档。
Gotham 补上从关系库到图谱的那一跳：行级图谱化导入（分页拉行 + 自动识别外键建边）、图分区压缩（多层 Louvain 把大图折叠成社区图）、时序图分析（按时间窗口看子图和趋势）。
让外部系统接得进来：13 类标准值类型把属性类型收敛并自动归一化，本体函数可在计算属性和条件里调用，MCP 把 Foundry 能力暴露成 LLM 工具（默认关闭），安全标记做第二道列级闸门，本体可导出成 OWL/SHACL 标准格式。
工程化收口：组件市场（本环境建好的资产打包到另一个环境一键装上）、代码仓库（SQL 宏一处维护多处复用）、统一搜索（顶栏一个框搜遍五类资产）、Prometheus 指标、单二进制/Docker、actionctl 命令行。
| 变化 | V5 之前 | V5 之后 |
|---|---|---|
| 长操作不再卡住页面 | 导入元数据、跑管道要在页面上干等几十秒甚至几分钟，超时了也不知道成没成 | 提交后立刻返回任务号，页面显示进度条；服务重启还能自动接着跑 |
| AI 答案能追到出处 | NLQ 返回一个数字和一段 SQL，「为什么是这个数」靠人自己核 | 决策证据链把答案拆成五步，每句话带 [n] 引用；/ai-audit 可回放全过程 |
| 数据变了会主动找人 | 只有人主动打开报表才知道数变了 | CDC 监测到变化 → 流规则判断条件 → 自动发通知、跑同步、触发质检，或直接回写 |
V4 时期文档里 P5 LightSwift 标的是「设计愿景 · 尚未实现」。V5 已改为「已交付（仿真 PoC）」——冒烟 16/16、前端 E2E 33/33 通过，端口 18084 可登录演示。
但厂商 docs-ZY-V5 里 story/swift/index.html 这一页停留在 8 月 9 日仍写着「代码尚未开工」，是没跟上的旧页。同理 site/verification.html、site/apollo.html、site/contracts.html 三页也是 8 月 9 日版本，其中「Gotham 未入网关」的说法已被 8 月 30 日的技术栈页和四份手册推翻（网关现已代理全部五个产品）。看到这几页时以日期新的为准。
四层。看懂这张图，就明白为什么五个产品既能各自独立启动，又能共用同一套权限、审计和数据源。
如果五个产品是五套独立系统，那你会遇到的典型麻烦是：审计日志分散在五个地方，安全策略要配五遍， 同一个数据源要注册五次，而且升级时它们的版本会各走各的。 共享底座把这些收成一份——一条审计规则改一次，五个产品同时生效。
代价也很直接：五个产品必须一起编译、一起发版，不能单独给某一个产品打补丁。 厂商选这条路的理由写在 R3 红线里——单机优先，先把机制做对，不为了「将来能拆」而提前付分布式的复杂度。
对标 Palantir 的产品矩阵。刻意不做「一个超级系统包打天下」——每个环节用最擅长的那一款。
LightFoundry
平台的灵魂。把物理表建成业务对象（客户、订单、商品），定义指标口径，管数据集与同步，并且垄断所有写操作的入口。
谁在用：数据工程师、FDE、本体工程师
LightAIP
一句话查数。自然语言 → SQL → 图表，五路召回 + 行列级安全注入 + 会话记忆；V5 起还能做带引用的决策证据链和文档实体抽取。
谁在用：业务分析师、不会写 SQL 的所有人
LightGotham
追人与关系。多源数据融合成图谱，实体解析把「同一个人的多条记录」归并，再用图算法、时空视图、模式识别找出隐藏关联。
谁在用：情报 / 风控 / 合规分析师
LightApollo
安全地送到现场。声明「这个环境应该长什么样」，目标机上的 Agent 主动来拉、自己验签、自己应用。控制台永不反向连入客户网络。
谁在用：运维工程师、FDE、安全合规
LightSwift
星基跨境结算（仿真域 PoC）。ISO 20022 报文引擎 + 国密全链路 + 复式记账 + 对账，在单机进程里跑通十步端到端。星座、链路、账户余额、清算通道均为模拟。
谁在用：方案评审、演示场景
「哪一款是主产品？」——没有。这套矩阵的设计前提就是各取所长：建模找 Foundry、查数找 AIP、追关系找 Gotham、交付找 Apollo。如果你只想解决其中一件事，装一个也能跑。
| 产品 | 端口 | 网关前缀 | 认证 | 前端页面 |
|---|---|---|---|---|
| LightAIP | 18080 | /aip-api | aip_token | 35 |
| LightFoundry | 18081 | /api | aip_token | 30 |
| LightApollo | 18082 | /apollo-api | apollo_token（独立用户库） | 19 |
| LightGotham | 18083 | /gotham-api | aip_token + WebSocket 刷新令牌 | 16 |
| LightSwift | 18084 | /swift-api | swift_token（内嵌登录） | 4 |
| Web 网关 | 80 | — | 不鉴权，只转发 | — |
注意最后一列之外的那件事：Apollo 和 Swift 有各自独立的用户库，AIP / Foundry / Gotham 共用一套。 也就是说，今天还做不到「一次登录走遍全平台」——这是第 11 节里列的明确边界之一。
数据 → 智能 → 决策 → 交付 → 创新。五个产品之间靠六份冻结的接口契约衔接，不是靠约定俗成。
这六份接口在第一个产品做完时就冻结了签名，后面的产品只能对齐、不能改。 业务上的意义是：换掉任何一个产品，其余四个不用改——因为它们之间约定的是数据形状，不是彼此的实现。
| 契约 | 谁提供 → 谁消费 | 解决什么 |
|---|---|---|
| ① 语义检索 | Foundry → AIP / Swift | 按文本找到指标、对象、属性，返回结构化结果而不是文本块。AI 检索的是「订单收入 = SUM(paid_amount)」这条定义，不是一段描述它的话。 |
| ② Action 执行 | Foundry → AIP / Swift | 唯一的写入口。四种模式：只校验、直接执行、异步执行、先校验再执行。HTTP 200 不等于成功——要看响应体里的校验结论。 |
| ③ LLM 网关 | AIP → Swift / Apollo | 所有大模型调用的统一入口，带降级链和熔断。熔断时返回降级结果并明确标注 degraded=true，不假装正常。 |
| ④ bundle 制品 | Apollo → 全部 | 分发包的格式：文件清单 + 国密哈希 + 整体签名 + 签名者身份。目标机验签的顺序是逐文件校验 → 整体验签 → 签名者是否在白名单 → 版本是否单调递增。 |
| ⑤ 评测集 | AIP → Swift | NLQ 的回归测试用例随发布包一起分发，换个环境也能验证「AI 还答得对不对」。 |
| ⑥ 对象 / 动作模型 | 共享代码包 | 对象、属性、链接、动作的结构体定义本身就是契约。Gotham 的图节点类型、Swift 的结算对象都直接复用它。 |
厂商文档里写着「跨产品语义层未打通」，很多人读成「架构上连不起来」。实际含义是：五套演示数据是各自独立的库（AIP 里的张三和 Foundry 里的张三不是同一条记录）。要让它们连通，把同一个数据源注册进两边即可——契约①和②本来就是为此设计的。这是演示数据的边界，不是架构的边界。
如果只读这份文档的一节，读这一节。前面所有产品的价值都建立在这两件事上。
本体（Ontology）是 Foundry 的核心资产，由四个要素组成。它不是「给表起个中文别名」， 而是把散在数据库里的技术结构，翻译成业务方直接说得出口的语言，并且把口径、约束、权限、动作都钉在上面。
| 要素 | 是什么 | 业务上意味着 |
|---|---|---|
| 对象 Object | 一张主表（最多再挂 3 张补充表）+ 一个稳定的英文名 api_name | 「订单」从此是一个大家都认的东西，而不是 db2.dbo.ord_hdr_v2 |
| 属性 Property | 映射某一列或计算得出；带约束、同义词、PII 标记、列级安全 | 给「区域」加上同义词「大区/片区」，业务怎么说都能查到；给「姓名」打 PII，脱敏自动生效 |
| 链接 Link | 对象之间的关系，带方向和基数（一对一 / 一对多 / 多对多） | 查订单时自动带出客户，不用每次手写 JOIN，也不会有人写错关联键 |
| 动作 Action | 一个被定义好参数、校验规则、权限和回写方式的写操作 | 「把订单标记为已发货」成为一个受控动作，而不是谁都能跑的一条 UPDATE |
本体一旦被报表、指标、AI 检索依赖，随便改就会连累一片。所以它有一套完整的版本状态机： 草稿 → 评审 → 合入，可批准、可驳回、可回滚到任意历史版本。
这是 R2 红线的落地。所有数据回写——人在页面上点的、AI Agent 自动执行的、外部系统通过 MCP 调的、 流规则自动触发的——全部穿过同一条流水线，没有旁路。
调用 Action 返回 200，只代表请求被受理了。真正的成败要看响应体里 validation.result 是不是 VALID。做集成时如果只判状态码，会把失败当成功。
通过 Action 改过的值不直接覆盖源表，而是独立落在编辑态表里，查询时叠加上去。V4 时期只有明细查询叠加，聚合查询不叠加——同一个数字在明细页和汇总页对不上，厂商自己称之为「最大语义债」。
V5 已修复：明细与聚合都会叠加（聚合回退成明细+内存聚合，上限一万行，超限会标注为近似值）。残留：比率型 / 派生型 / 累计型指标仍未叠加，文档标为下一阶段处理。
85 个后端模块，按能力域归类。这一节是查阅用的——先扫标题，需要时再看细节。
| 产品 | 后端模块 | 前端页面 | 能力重心 |
|---|---|---|---|
| P2 LightFoundry | 29 | 30 | 本体语义层 · 数据域 · 协作分析 · 治理 · 互操作生态 |
| P1 LightAIP | 21 | 35 | 查数主链路 · 知识域 · 智能体 · LLM 基础设施 |
| P4 LightGotham | 17 | 16 | 图谱核心 · 时空视图 · 研判产出 · 协作安全 |
| P3 LightApollo | 13 | 19 | 交付核心 · 制品配置 · 环境运行 · 监控自愈 |
| P5 LightSwift | 1 | 4 | 仅收录部署运维；结算能力见故事站 |
| 共享底座 platform/ | 4 | — | 22 个包中 4 个有独立开发文档（V5 新增的调度 / CDC / 通知 / 向量） |
| 合计 85 个后端模块 · 104 个前端页面 | |||
| 能力域 | 包含模块 | 一句话 |
|---|---|---|
| 本体与语义层 | ontology_modeling ontology_sql analytics_engine data_integration | 四要素建模、版本状态机、对象名直接写 SQL、语义翻译成物理 SQL |
| 数据域V5 | dataset sync quality pipeline_builder data_lineage | 数据集版本化、全量/增量同步、四因子质量画像、SQL 步骤管道、四级血缘 |
| 协作分析V5 | notebook report fusion stream visualization_dashboard | 工作簿、定时报表、实体消解、变更驱动流规则、仪表盘 |
| 治理与安全 | access_control core_auth_apikey audit_compliance data_governance | 两层权限、JWT + API Key 双通道、审计五问、术语表与密级 |
| 互操作与生态V5 | mcp actionctl nexus marketplace coderepo | 把能力暴露给 LLM、命令行、统一搜索、组件市场、SQL 宏仓库 |
| 应用与运维 | application_builder collaboration mlops_platform monitoring deployment_ops api_sdk | 低代码应用、工作流、模型注册与推理、指标暴露、部署、OpenAPI 门户 |
| 能力域 | 包含模块 | 一句话 |
|---|---|---|
| 查数主链路 | nlq_engine rag_engine oag visualization_dsl ontology_integration | 意图 → 五路召回 → 安全注入 → 记忆 → 生成 SQL → 执行 → 推荐图表 |
| 知识域V5 | entity_extraction decision schema_annotation knowledge_base | 文档抽实体、五步决策证据链、字段关系自动推断、知识库分层树 |
| 智能体与自动化 | agent_framework tool_system workflow_automation automation_copilot | 多智能体编排、工具注册与鉴权、定时工作流、对话式配置自动化 |
| LLM 基础设施 | llm_gateway prompt_engineering evaluation_monitoring | 多供应商路由降级熔断、Prompt 版本化、评测集与效果监控 |
| 接入与治理 | datasource_connector core_auth_rbac security_governance deployment_ops api_sdk | 数据源与元数据、认证 RBAC + 双因子、敏感列与护栏、部署、OpenAPI |
| 能力域 | 包含模块 | 一句话 |
|---|---|---|
| 图谱核心 | knowledge_graph graph_analysis entity_resolution | 自研磁盘图存储、展开/最短路径/中心性/社群、四层实体解析流水线 |
| 数据接入 | multi_source_fusion search | 四类来源清洗映射入图（V5 支持按行图谱化 + 外键自动建边）、跨域全局搜索 |
| 时空与视图 | geospatial_analysis timeline_analysis multi_view_linkage | 地图要素与框选聚合、时间轴与时间轮盘、图/地图/时间轴三视图联动 |
| 研判与产出 | pattern_recognition intelligence_reporting | 五类规则检测 + 告警去重打分、结构化情报报告与三格式导出 |
| 协作与安全 | collaboration_workflow eventbus_ws access_control_security | 项目任务看板、进程内事件总线 + WebSocket 实时协同、ABAC 属性授权 |
| 基座运维 | core_auth_health ops deployment_ops edge_offline | 认证与健康探针、运维监控、部署、边缘离线运行 |
| 能力域 | 包含模块 | 一句话 |
|---|---|---|
| 交付核心 | hub_deployment gitops_engine cicd_pipeline | 期望状态 + DAG 门控 + 漂移检测 + 回滚、声明式编排、构建流水线 |
| 制品与配置 | artifact_management configuration_management | 统一制品库 + 国密签名验签、多环境配置与密文管理 |
| 环境与运行 | multi_env_management edge_airgap_support hybrid_cloud_deploy | 环境登记与 Agent 状态机、断网/信创场景、混合云（归并视图，无独立代码包） |
| 监控与自愈 | monitoring_observability alerting_self_healing | 四类内置探针自研轻量监控、告警归并成事件单 + 安全边界内自愈 |
| 安全与接口 | security_compliance rbac_audit api_cli_sdk | SBOM 与漏洞扫描、逐路由权限 + 全量 HTTP 审计、REST/CLI 接口面 |
前面架构图里已经画过分组。这里补一句 V5 的四个新包为什么重要——它们不是「又多了几个功能」， 而是把之前各产品各自造轮子的三件事收成了一份：
scheduler / task / resource——之前 AIP 的工作流和 Gotham 的模式检测各有一套定时器，长操作全是同步阻塞。现在定时任务统一注册、长任务统一排队看进度、资源统一寻址。cdc——轮询比对式的变更捕获，不依赖数据库日志、不需要装 Kafka。Foundry 的流规则就消费它的事件。notify——通知渠道抽象层，业务侧只说「往哪个渠道发什么」，不关心邮件还是飞书怎么发。vector 增强——批量写入、带过滤的检索、按文档删除、计数。这四个方法让知识库重建索引这类操作从「重灌整个库」变成「只动这一份文档」。开发文档只收录了 Swift 的 1 个部署运维模块，看上去像是「几乎没做」。实际情况是它的报文引擎、结算状态机、GAC 终端、HCC 管控台、星地链路仿真、国密全链路都已实现并有冒烟与端到端测试通过，只是开发文档尚未补齐。同理，前端页面文档里 Apollo 的 19 页和 Swift 的 4 页也只有索引、没有正文。
FDE 进场到交付撤场的四个阶段，以及每个阶段谁做什么。厂商把这套定位成「轻交付」——一周部署、两周培训，然后靠制品而不是靠人留在现场。
阴影格是这条路上最容易翻车的两步。B2 和 C1 必须同时发生——如果数据工程师建完模型才去问业务口径， 基本上要返工。厂商手册里反复强调的也是这一点：指标定义是业务决定，不是技术决定。
Windows 上双击一键启动脚本，拉起五个后端 + 网关六个进程。信创离线环境同样可行——单一 Go 二进制，无外部服务依赖。
V5 起 Foundry 有独立的数据源页，不再依赖 AIP。导入元数据是任务化的：提交后返回任务号，页面轮询进度。连接器默认只放行 MySQL / SQL Server / PostgreSQL 三类。
从数据源查询拉数、或直接上传 CSV / JSON 建集（XLSX 会明确报错，不静默失败）。数据集可版本发布、可预览、可跑基础画像（空值率 / 唯一值 / Top5）。
全量模式是事务内重写；增量模式按水位线断点续传、冲突跳过。同步成功会自动联动血缘和质量画像刷新。
整条链路里唯一不能省的一步。属性记得加同义词（提升语义检索命中）、给敏感字段打 PII 标记（列级安全自动生效）。V5 起属性类型收敛为 13 类标准值类型，可一键归一化存量属性。
四层结构：实体（决定粒度）→ 维度 / 度量 → 指标。类型分简单、比率、派生、累计四级。口径在指标里现算，不做预聚合——这样改口径不用重跑历史。
单数据源内的有序 SQL 步骤，输出映射到对象。质量规则四类：非空、格式、唯一、引用完整性。error 级问题会直接阻断目标对象同步——脏数据不进本体。
参数 Schema、校验规则、编辑类型、回写模式、幂等键。回写模式分两种：pre 先写源系统成功再提交本体（适合结算对账），post 先提交本体再异步做副作用（适合发通知）。
草稿 → 评审 → 合入。合入前系统列出受影响的指标、报表、AI 检索并给重建建议；被引用的对象禁止删除；有真冲突会阻塞等人处理。
本体 YAML、网关路由、评测集打成签名发布包。目标机上的 Agent 主动拉取，逐文件校验 → 整体验签 → 检查签名者白名单 → 检查版本是否单调递增 → 按依赖顺序应用。控制台不需要能连进客户网络。
日常闭环。和传统 BI 的差别不在第一步，在第三步之后——发现异常之后还能追下去、改回来、并且让下一轮自动发生。
| 想做什么 | 去哪 | 怎么用 |
|---|---|---|
| 快速取个数 | AIP 智能查询 | 用直白关键词提问（「销售额」「订单数量」比口语化更容易命中）。重要数字务必核对返回的 SQL。 |
| 问一个需要理由的问题 | AIP 决策证据链V5 | 系统会拆解问题、三路检索、逐条核验证据、只基于证据作答，答案里的 [n] 可点回原文。 |
| 反复要看的分析 | Foundry Notebook / 报表V5 | Notebook 把「取数 + 说明 + 图表」沉淀成可重跑的工作簿；报表可定时生成快照并邮件分发。 |
| 不知道东西在哪 | Foundry 顶栏搜索V5 | 一个框搜遍对象、指标、数据集、仪表盘、Notebook，按相关度融合排序，点结果直接跳到对应页面。看不见的资产不会出现在结果里。 |
五类角色，五条互不重叠的工作线。角色之间靠「制品」交接——对象、指标、报告、期望状态——而不是靠开会对口径。
| 角色 | 主战场 | 日常做什么 | 交出什么制品 |
|---|---|---|---|
| 数据工程师 语义的生产者 |
Foundry | 建对象与指标、修管道、跑质量画像、管版本合入。一次建模，下游所有人复用。 | 对象定义、指标口径、数据集、本体 YAML |
| 业务分析师 结论的消费者 |
AIP + Foundry | 自然语言查数、核对口径、做 Notebook 与报表。不写 SQL 也能干活，但重要数字要核对生成的 SQL。 | Notebook、报表、结论 |
| 情报 / 风控分析师 深度研判 |
Gotham | 图谱展开与最短路径、实体解析审核、模式规则告警处置、写情报报告。 | 情报报告、告警处置结论 |
| 运维工程师 交付的保障者 |
Apollo + 全平台 | 期望状态与部署推进、漂移检测与收敛、监控指标与告警、回滚兜底、数据库与授权巡检。 | 期望状态 YAML、发布包、运维记录 |
| FDE 前沿部署工程师 最后一公里 |
全部五个 | 进场部署、接客户数据、定制本体、培训业务骨干、交接后撤场。对标 Palantir 的 FDE 角色，但走「轻交付」路线。 | 整套可运行环境 + 交接文档 + 制品清单 |
| 决策者 只读 |
报表 / 报告 | 不碰 SQL 和 YAML。要数字先问「口径来自哪条指标定义」，要结论先问「谁查的、SQL 是什么」。 | 选型与承诺的判断 |
最容易出问题的接缝是数据工程师 ↔ 业务方：模型建完了才去确认口径，基本要返工。其次是数据工程师 ↔ 运维：本体改了但没走发布包分发，目标环境还是旧定义。这两处厂商都给了机制兜底（影响分析、版本单调递增），但机制拦得住错误，拦不住「没沟通」。
这一节按厂商文档自己的标注整理。演示前先看一遍，比事后解释省事。
| 能力 | 状态 | 具体说明 |
|---|---|---|
| 本体建模 · 指标语义层 · Action 写路径 | ✅ 完整 | 四要素、版本状态机、影响分析、七道关卡、幂等与乐观锁，全链路冒烟通过 |
| 数据集 · 同步 · 质量画像 · SQL 工作台 | ✅ 完整 | V5 新增，任务化执行，成功链自动联动血缘与质量 |
| NLQ 查数 · 决策证据链 · 知识域 | ✅ 完整 | 五路召回、行列级安全注入、会话记忆、实体抽取、五步证据链 |
| 图谱分析 · 实体解析 · 时空多视图 | ✅ 完整 | 自研磁盘图存储 + Go 原生算法；V5 补齐行级图谱化导入、图分区、时序分析 |
| 声明式部署 · 签名验签 · 漂移检测 | ✅ 完整 | 纯拉取模型、国密 SM3/SM2、签名者白名单、DAG 门控、自动回滚 |
| 知识库问答 | ◐ 部分 | 知识库只作为检索通道喂给查数链路，没有独立的「问文档」入口——该意图会短路返回提示 |
| MCP 对外暴露 | ◐ 默认关闭 | 需显式开启配置项才注册路由；开启后每次工具调用都落审计，写动作仍走完整写路径 |
| 混合云部署 | ◐ 归并视图 | 厂商明确标注：没有独立代码包，是既有能力的组合说法，无 gRPC 端点、无 K8s 清单渲染 |
| Apollo 演示 Agent | ◐ 仅巡检 | 演示轮询器只拉取和上报，不真实拉起进程；要真部署得挂上进程管理器 |
| Git 真相源 | ◐ 本地目录 | 用本地目录模拟仓库，真实 GitHub / GitLab / Gitea 对接规划中；同步靠手动或定时触发 |
| P5 Swift 星基结算 | ◐ 仿真 PoC | 报文、国密、复式记账、对账全链路可跑（冒烟 16/16、E2E 33/33），但星座拓扑、链路延迟、账户余额、外部清算通道全是模拟，不是在轨系统 |
| 跨产品单点登录 | ✗ 未实现 | Apollo 和 Swift 各有独立用户库，切产品要重新登录 |
| 跨数据源管道 | ✗ 未实现 | 管道只支持单数据源内的 SQL 步骤，跨源 join 不做（与单机优先一致） |
| 字段级全量血缘 | ✗ 浓缩版 | 四级血缘（源 → 管道 → 对象 → 指标）+ Action 写边 + 报表打点，不是逐字段全量 |
图存储是内存邻接表 + JSON 落盘；查数一次只查一个数据源、最多返回 100 行；对象查询最多 3 层深、禁止点号引用。厂商自己说明：TB 级是设计判断，未经真实压测，大规模选型前要做基准验证。
生成 SQL 依赖外部大模型（主力 deepseek-v4-flash，备用 qwen，兜底本地规则）。降级方案：Foundry 的对象查询、SQL 工作台、Gotham 的图算法都是本地计算，断网照样能取数、能研判。
五套演示数据各自独立，人名相近（张三 / 李四 / 王五）但不是同一条记录。跨产品追查演示数据需要手工导。注意这是演示数据的限制，不是架构限制——注册同一个真实数据源即可打通。
各产品的 demo 数据源启动时幂等重建，临时改动重启就还原（平台元数据与审计会保留）。做演示前不要在 demo 库里存重要东西。
数据库连不上 PostgreSQL 时，系统会静默降级到 SQLite 并继续启动。好处是单机永远跑得起来，坏处是——你可能以为在用生产库，其实在用本地文件。降级后运维冒烟脚本里的数据库断言也会失效。
上线前务必检查启动自检日志里的数据库项，或直接确认表建在了 chatbi_action_dev 里。
| 层次 | 结果 | 覆盖 |
|---|---|---|
| Go 单元测试 | 285 个测试函数 / 40 个文件，全绿 | 底座 + 四产品核心包 |
| 真实冒烟 | Foundry 23/23 · Apollo 26/26 · Gotham 44/44 · Swift 16/16 | 跑在真实 PostgreSQL 上，全链路端到端 |
| 浏览器 E2E | Foundry 5/5 · Apollo 5/5 · Swift 33/33 | Playwright 真实点击，AIP / Gotham 走前端骨架 + API 联调 |
| 契约一致性 | OpenAPI 规格与实际路由双向对拍 | V5 新增，防止「文档写了但没实现」和反过来 |
口径提示：单测与前三个冒烟数字来自 site/verification.html（8 月 9 日版，未随 V5 更新），Swift 的数字来自 8 月 10 日的路线图页。
V5 新增的大量模块是否已纳入这些统计，文档没有说明——把它当作「V4 主干的验证证据」来读更稳妥。
读厂商文档时最常撞上的词。带 V5 标记的是这一版新出现的。