EASH 产品培训导览 · Pack 构建全流程

不是在平台里重建一个 CMDB。是为「智能体要能办事」定义一套业务语义模型，再把客户现有系统（CMDB、监控、工单）对齐到这套模型上，最后让真实数据实例进图谱，智能体才能查得准。

界面上叫「本体与关系」，本质是第一步：构建本体的数据结构（TBox）——有哪些类、每类什么属性、类之间什么关系。完整端到端见 产品运行逻辑；「四层语义」见 方法论（≠ 构建步数）。

产品原型入口：领域包管理 → 顶部「进入本体构建」，或模块行「构建」。可为每类添加属性、关系；办事规程在左侧「全局办事规程」统一管理，各类详情页可查看「关联规程」。

flowchart TB
  subgraph CONSULT["阶段 0 · 咨询（产品外，工作坊）"]
    WS[场景 + CQ 能力问题]
    STORY[故障/办事故事 ALERT-991]
    WS --> STORY --> ONTO_DRAFT[产出：类/关系/映射草稿]
  end

  subgraph PACK["阶段 1–5 · 领域包（管理端 · 领域包管理）"]
    S1[① 本体 TBox
类/属性/关系/规程]
    S2[② 映射与归一
字段规则 + 归一词典]
    S3[③ 图谱实例 ABox
ETL 写入 Neo4j]
    S35[③½ AI适配 可选]
    S4[④ 可调用工具]
    S5[⑤ 编排 + 评测发布]
    S1 --> S2 --> S3
    S3 --> S35 --> S4 --> S5
  end

  subgraph ADMIN["横切 · 管理端（与②并行配置）"]
    CONN[业务系统连接
URL/密钥/健康检查]
    LIVE[上线工作台八步旅程]
    CONN --> S3
  end

  subgraph RUN["阶段 6 · 运行时（值班员）"]
    WB[工作台对话]
    HAR[Harness 按步骤办事]
    TG[ToolGate 调④已声明能力]
    NEO[(Neo4j ③ 或回源 CMDB/监控)]
    WB --> HAR --> TG --> NEO
    TG --> WB
  end

  ONTO_DRAFT --> S1
  S5 --> WB
          

③ 运行图谱怎么构建？

1. 配置阶段（②）：写好「Prometheus.labels.pod → Pod.name」等映射行 + 归一词典
2. 连接阶段（管理端）：业务系统连接填 base URL、密钥，测试通过
3. 同步阶段（自动）：连接器按策略 ETL / Webhook 推送 → 先映射取值 → 再归一绑 ci_id → 合并写入 Neo4j
4. 验收阶段（③ 页面）：领域包 →「查看图谱实例」按类浏览，确认场景子图节点数（如 15 个）
5. 持续运行：新 Pod 上线、新告警产生 → 连接器持续同步，③ 子图自动增长

还缺哪些环节？（相对完整 To B 系统）

flowchart TB
  subgraph INGEST["管道 A · 入图（形成 ③ 图谱实例）"]
    EXT1[(CMDB / Prometheus / ITSM)]
    CONN[业务系统连接 + Connector 插件]
    MAP[② 字段映射 + 归一词典]
    ETL[GraphSync ETL / Webhook]
    NEO[(Neo4j ABox)]
    EXT1 --> CONN --> ETL
    MAP --> ETL --> NEO
  end

  subgraph RUNTIME["管道 B · 办事（④⑤ 智能体运行时）"]
    AGENT[智能体 Harness]
    TG[ToolGate]
    CAP[④ 可调用工具 tools/*.yaml]
    EXT2[(监控 / 日志 / 图谱查询)]
    AGENT --> TG --> CAP
    CAP --> EXT2
    CAP --> NEO
  end

  TBOX[① 本体 TBox] --> MAP
  TBOX -->|OntoCore 导出 labels/constraints| NEO
  TBOX --> CAP
          

③ 图谱实例的前置条件（与 ③½ 无关）

原型 Demo 里已有 15 个图谱节点，是因为预置了华东金融云样例 + 连接器已配好，不代表必须先做 ③½。

各库要不要做「结构设计」？写在哪？

研发主文档：docs/platform/03-平台架构设计.md（OntoCore、GraphSync）· 02-平台能力全景.md §五数据分类 · 08-技术选型方案.md §七图库分层。

flowchart TB
  subgraph P1["第一阶段：本体语义模型（你要先做的）"]
    CQ[能力问题 / 业务场景
如：告警根因、资产查询]
    ONTO[本体类 Class
Pod / Alert / 技术服务…]
    ATTR[类上的属性
name / severity / ci_id…]
    REL[类之间的关系
runs_on / depends_on / supports…]
    RULE[办事规程 R01-R05
硬规则，非 CMDB 字段]
    CQ --> ONTO --> ATTR
    ONTO --> REL
    ONTO --> RULE
  end

  subgraph P2["第二阶段：各系统对齐到本体"]
    CMDB[(蓝鲸 CMDB
有自己的表和字段)]
    PROM[(Prometheus
labels / metrics)]
    ITSM[(ServiceNow ITSM
变更单字段)]
    MAP[字段映射
源系统.类.字段 → 本体.类.属性]
    DICT[归一词典
多源别名 → 统一 ci_id]
    CONN[连接器
地址、密钥、同步频率]
    CMDB --> MAP
    PROM --> MAP
    ITSM --> MAP
    MAP --> DICT
    CONN --> CMDB
    CONN --> PROM
    CONN --> ITSM
  end

  subgraph P3["第三阶段：能力 + 智能体 + 验证"]
    SYNC[ETL / Webhook 同步]
    GRAPH[(知识图谱 Neo4j
实例 ABox)]
    TOOLS[④ 可调用工具
get_alert / trace_ci…]
    AGENT[⑤ 智能体编排
每步绑定可调用工具]
    EVAL[评测题库]
    MAP --> SYNC
    DICT --> SYNC
    SYNC --> GRAPH
    ONTO --> TOOLS
    GRAPH --> TOOLS
    TOOLS --> AGENT
    ONTO --> AGENT
    GRAPH --> AGENT
    AGENT --> EVAL
  end

  subgraph USER["用户侧"]
    WB[值班工作台对话]
    AGENT --> WB
  end
          

实线依赖：必须先有本体（P1），才能做映射（P2）；映射通了，实例才能入图；必须先声明可调用工具（④），才能在智能体编排里绑定（⑤）。

根据业务场景梳理：智能体要回答什么问题，就需要哪些概念（类）、每个概念有哪些属性、概念之间有哪些关系。

类怎么拆？不是 CMDB 式「基础设施→网络→交换机」深树，而是场景 CQ + 四层语义 + 故障链。详见独立文档 《本体类梳理方法论》（含可视化对比图与顾问工作坊步骤）。

打开完整方法论（顾问现场指南）

方法论内新增：能力怎么构建 · 可调用工具原型入口

③ 的里程碑：场景子图可查。④⑤ 的里程碑：值班员能在工作台问告警/根因/资产。

能力说明：可调用工具怎么构建 · 方法论 三步之后完成了吗

CMDB、ITSM、Prometheus 各自有一套表/类/字段。第二步做两件事：

1. 字段映射：源系统的「类.字段」→ 本体的「类.属性」
2. 归一词典：不同系统对同一台设备的不同叫法 → 统一成一个 ID

对齐完成后，连接器同步数据，实例（pay-gw-03、ALERT-991）才进入图谱。详见下文 归一 vs 映射图解 与 图谱实例浏览。

Pod 来自 Kubernetes（K8s），不是物理服务器，也不是集群 Node。可以把它理解成：

物理机 / 虚拟机
└── Node（K8s 集群节点 · 宿主机）
    └── Pod（容器工作负载实例 · 最小调度单元）
        └── Container（真正跑进程的容器）

支付网关（TechnicalService · 逻辑服务）
    ▲
    │ member_of（以下 3 个 Pod 属于该服务）
    │
    ├── pay-gw-01（Pod）
    ├── pay-gw-02（Pod）
    └── pay-gw-03（Pod）

上图 ① 是机房/K8s 物理层级；图 ② 是运维语义层——多个 Pod 实例属于同一个技术服务。不要混成一棵树。

关系链：Pod runs_on Node；多个 Pod member_of 支付网关。告警 ALERT-991 observed_on 某个 Pod，不是 observed_on 某台交换机。

归一词典的目的，是构建图数据吗？——是，但是间接的。归一词典本身是一张「对照规则表」，不直接存图；同步时靠它把多源数据挂到同一个节点上，图才不会碎成一堆重复对象。

sequenceDiagram
  participant CMDB as 蓝鲸 CMDB
  participant PROM as Prometheus
  participant ETL as 同步 ETL
  participant MAP as 字段映射规则
  participant DICT as 归一词典
  participant NEO as Neo4j 图谱

  Note over MAP,DICT: 都在 Pack 里预先配置（设计时）
  PROM->>ETL: 告警 ALERT-991
labels.pod = pay-gw-03
  ETL->>MAP: ① 查映射：labels.pod → Pod.name
  MAP-->>ETL: 取出值 pay-gw-03
  ETL->>DICT: ② 查归一：pay-gw-03 是哪个 ci_id？
  DICT-->>ETL: ci-pod-pay-gw-03
  ETL->>NEO: ③ 写入/合并节点
Pod(ci_id, name, …)
Alert ─observed_on─► Pod
  CMDB->>ETL: 另一条记录 PAY-GW-POD-03
  ETL->>DICT: ② 同一 ci_id
  ETL->>NEO: ③ 合并到同一节点，不新建
          

①② 是设计时在 Pack 里配的规则和模型；③ 是运行时 ETL 同步写入图数据库、智能体和用户实际查询的对象。

flowchart TB
  subgraph Pack["领域 Pack 文件（设计时 · 不进 Neo4j）"]
    TBOX[TBox 本体模型
22 类 / 属性定义 / 关系类型 / 规程]
    MAPR[字段映射规则]
    DICTR[归一词典规则]
  end

  subgraph Runtime["运行时（同步后）"]
    ETL[连接器 + ETL]
    ABOX[(Neo4j 知识图谱
ABox 实例)]
    INST1[Pod pay-gw-03]
    INST2[Alert ALERT-991]
    INST3[ChangeRequest CHG00412]
    ETL --> ABOX
    ABOX --> INST1
    ABOX --> INST2
    ABOX --> INST3
    INST2 -->|observed_on| INST1
    INST3 -->|targets| INST1
  end

  TBOX -.定义结构.-> ETL
  MAPR --> ETL
  DICTR --> ETL

  subgraph External["仍留在源系统（不全量入图）"]
    CMDB[(CMDB 全量台账)]
    LOG[(Elastic 全量日志)]
    MET[(Prometheus 时序)]
  end

  ABOX -.需要时现场查.-> CMDB
  ABOX -.需要时现场查.-> LOG
  ABOX -.需要时现场查.-> MET
          

Pack 存的是「.schema + 规则」（TBox + 映射 + 归一），不是把全公司机器塞进 YAML。Neo4j 存同步后的实例节点和关系边（ABox），供智能体拓扑遍历。原型中可在「图谱实例」页查看已入图对象。

一个对象在 CMDB 里可能有上百个字段——不是全进图谱。按场景能力问题裁剪：智能体办事链路上用得上的才同步入图，其余通过「可调用工具」现场查源系统。

存哪：运行时 Neo4j 图数据库。每个实例是一个节点（带类标签和属性），关系是边。华东金融云样例对齐 seed/neo4j_ops_paygw.cypher。

怎么来：连接器按字段映射 + 归一词典 ETL 同步（或咨询交付种子灌入）。不是用户在「本体构建」里手工逐条录入——那是定义类，不是灌实例。

用户怎么看：产品原型 → 领域包管理 → 「图谱实例」（按类筛选、查看属性与关系、跳转拓扑）。与「本体构建」区别：

问题：同一台支付网关 Pod，CMDB 叫 PAY-GW-POD-03，Prometheus 叫 pay-gw-03，工单里写「支付网关 03 号实例」。如果不对齐，图谱上会变成 3 个节点，智能体就乱了。

归一词典做的事：规定一个主键 ci_id（如 ci-pod-pay-gw-03），把所有别名都指到这个主键上。

数据从哪来：手工维护 + 咨询交付导入；新 Pod 上线持续添加别名。原型中可在「映射与归一 → 归一词典」添加条目。

先分清三件事

flowchart TB
  subgraph VENDOR["第三方（客户侧）"]
    PROM[Prometheus API]
    ITSM[ServiceNow API]
    CMDB[蓝鲸 CMDB API]
  end

  subgraph EASH["EASH 平台"]
    CONN[连接器 Connector
地址/密钥/同步]
    ADP[Adapter 适配器
平台或 FDE 开发]
    TG[ToolGate 工具网关
鉴权/Scope/审计]
    DECL[④ 可调用工具
tools/*.yaml]
    ORCH[⑤ 智能体编排
步骤绑定可调用工具]
    HAR[Harness 运行时]
  end

  PROM & ITSM & CMDB --> CONN
  CONN --> ADP
  DECL --> TG
  ADP --> TG
  ORCH --> HAR
  TG --> HAR
  HAR -->|get_alert| ADP
          

什么才算一条合格的「可调用工具」？

标准文档：docs/platform/10-ToolGate工具接入规范.md · 教辅 教辅-06-MCP工具清单与参数schema.md

三种常见来源（实施现场怎么选）

图谱类 vs API 回源类：
· trace_ci_to_service、trace_impact → 主要查 Neo4j（①②③ 已入图的数据）
· get_alert、list_changes → ToolGate 经 Connector 按需调 Prometheus/ITSM（路径 B）
· query_logs → 回源 Elastic；若②映射未完成，能力标「待对齐」，评测会失败（EV-LOG-03）

三层配置（别混在一起）

运行时怎么拼出完整请求？

为什么选连接器还不够？

一个连接器（如 Prometheus）往往暴露多个 REST 动作：查告警、查指标、查规则……每个动作对应不同的handler + 路径。所以表单里除了选「关联连接器」，还要选 Adapter handler，并预览 API 路由模板（只读）。

图谱类能力（graph_query）无外部 REST，handler 指向 Neo4j Cypher 模板，连接器选平台内置图谱。

工程 SSOT：packs/ops/tools/get_alert.yaml（adapter.connector + adapter.handler）· docs/platform/10-ToolGate工具接入规范.md · 研发落地：FDE 能力开发手册

详细需求：AI接口适配助手-产品需求.md · FDE 手册：开发手册 §AI接口适配助手

入口：领域包管理 → ③½ AI接口适配助手（推荐）或 第四步：进入可调用工具配置。

保存后，智能体编排「绑定可调用工具」下拉自动同步本表；未声明的能力不会出现。三层配置详解见 API 怎么对应。

完整映射是四层，原型「映射与归一 → 字段映射」已按此实现，并支持手工添加数据源与映射行：

入口：领域包管理 → 进入映射与归一 → 左侧「数据源」可先添加 Elastic/Splunk 等，再在「字段映射」里配置四级映射。

flowchart LR
  subgraph CMDB["传统 CMDB · 为人建"]
    H1[资产管理员 / SRE]
    C1[(配置项台账
CI 类型全 · 字段多)]
    H1 -->|查界面、导报表| C1
  end

  subgraph EASH["EASH 本体 · 为智能体建"]
    AG[智能体 + Harness]
    ONTO[本体语义 TBox
类 / 属性 / 关系]
    RULE[办事规程 R01-R05]
    PROTO[诊断步骤 / 评测]
    GRAPH[(Neo4j 场景子图)]
    ONTO --> GRAPH
    RULE --> AG
    PROTO --> AG
    AG -->|trace / 规程检查| GRAPH
  end

  C1 -.同步子集.-> GRAPH
          

重叠部分（Pod、Node、服务、depends_on…）不必重复造轮子——工作坊梳理场景后，从 CMDB 复用类名与关系，经字段映射 + 归一同步实例入图即可。

华东金融云样例已经证明：一条告警根因链 + 一条资产查询链可以用同一套 22 类本体跑通。验证产品可行后，再扩展下一个场景（日志、指标），类表可复用、映射可追加。

在管理控制台 → 智能体编排中，为每个场景智能体定义办事步骤，每步从「可调用工具」清单中绑定一项。Harness 按步骤调用 ToolGate，办事进度在工作台右侧逐步点亮。

打开「智能体编排」

评测中心用真实历史故障脱敏 case检验智能体输出。通过率未达门禁（如 ≥85%）则不得发布。失败案例可跳转字段映射或连接器修复。

打开「评测中心」

连接器是智能体访问客户现网系统的入口（CMDB、Prometheus、ITSM、日志等）。Pack 里的「可调用工具」定义智能体能调什么；连接器定义调到哪里。

业务系统连接 · 数据同步中心 · FDE 手册

打开「数据同步」 · 详见 数据存储架构

上线工作台是租户管理员的汇总页：一眼看清 Pack 安装、连接器、编排、评测是否就绪，以及今日办事情况。

在原型中打开「上线工作台」

工作台是中文对话 + 右侧上下文：不暴露 YAML、protocol_id；值班员用自然语言办事，Harness 在后台按规程执行。右上角皮肤切换支持「值班青绿」与「企业克莱因蓝」（与管理员后台一致）。

在原型中进入「值班工作台」

EASH 支持多种薄入口：后端仍是同一套 Pack + Harness + 智能体，只是用户从企微、工单侧边栏或 Webhook 进来。

在原型中打开「集成与生态」

先做本体还是先接 CMDB？

先定本体语义（哪怕 10 个类），再谈映射。否则不知道 CMDB 字段该对齐到什么。

归一词典和字段映射能合并吗？

概念上分开更清晰：映射管「结构」，归一管「身份」。产品 UI 可以放在同一「对接」工作台里。

本体和 CMDB 是不是一回事？

不是。CMDB 为人建资产台账；EASH 本体为智能体建场景语义。重叠的 CI 结构可从 CMDB 同步，但要额外加办事规程、告警、诊断协议等 CMDB 通常没有的内容。

办事规程为什么在本体里？

都属于「语义契约」——智能体理解业务世界的规则，不是外部系统同步来的数据。

实例数据存在哪？

运行时 Neo4j 图谱（ABox）。Pack 里存的是 schema + 映射规则，不是全公司数据。用户可在原型「图谱实例」页按类浏览已同步对象。

有归一词典了，为什么还要字段映射？

归一只解决「是不是同一对象」。namespace、severity、变更状态等属性仍要从各系统字段映射进来；图谱还要存拓扑边供智能体遍历。

为什么不每次都去源系统查？

跨系统证据链（告警→Pod→服务→变更）需要预汇聚的子图；日志、指标等大体量数据仍现场查。

本体构建和图谱实例是不是一回事？

不是。前者定义「表结构」（TBox），后者是「表里的行和关系」（ABox），由同步写入 Neo4j。