EASH · 客户必懂概念图解 · 本体→映射→能力→编排

全景：五步在整条链上各干什么

一句话：本体定义「世界长什么样」；映射告诉系统「客户字段怎么落到这世界」；图谱装「今天这家客户有哪些实例」；可调用工具把对方 API 收成「智能体能调用的工具」；编排把工具串成「可发布的办事流程」。

flowchart LR
  subgraph L3["外系统（客户 / 沙箱）"]
    CMDB[CMDB API]
    ITSM[ITSM API]
    AM[告警 / 监控]
  end
  subgraph Admin["Admin 配置"]
    O[① 本体
类·属性·关系]
    M[② 映射与归一
字段映射·词典]
    C[④ 可调用工具
工具封装]
    A[⑤ 智能体编排
步骤·分支]
  end
  subgraph Runtime["运行时"]
    G[③ 图谱实例 ABox]
    W[Workbench 办事]
  end
  CMDB --> M
  ITSM --> M
  AM --> G
  O --> M
  M --> G
  CMDB --> C
  C --> A
  O --> A
  G --> W
  A --> W

产品交付（内置）

引擎 + ops-pack 本体/协议模板（棋盘规则，不是客户 CI 表）

客户要配

连接器 URL/名称、字段映射、归一词典、创建/导入工具、发布

客户数据

从对方系统同步/推送来的 CI·变更·告警——正式业务数据

① 本体：类 · 属性 · 关系 —— 站在业务视角

本体不是 Excel 原表，而是你们公司统一说的话：什么叫「一台网络设备」、它有哪些属性、跟服务器是什么关系。

概念	业务说法	例子
类（Class）	一类业务对象	网络设备、服务器、应用、业务服务、告警、变更单
属性（Property）	这类对象随身带的字段	设备名、机房、管理 IP、告警级别、变更窗口
关系（Relation）	类与类之间怎么连	应用「部署在」服务器；告警「观测到」某配置项；变更「影响」业务服务

类比：本体 = 人事制度里的「职位说明书」；图谱实例 = 花名册里今天坐在这些职位上的人。先有说明书，再往里同步真实人员，问数/根因才有统一语言。

不同岗位都能懂的类示例

管网络

网络设备 · 链路 · 专线 · 防火墙策略

管服务器

主机 / Node · 机房 · 磁盘池 · 集群

管应用

应用 · 微服务 / Pod · 业务服务 · 依赖

② 映射与归一：在解决什么问题？

客户 CMDB 叫 ci_name，你们本体叫 name；监控里叫 instance=pay-gw-03，图里 CI 主键是 ci-pod-pay-gw-03。 不映射、不归一，智能体无法把「对方嘴里的词」对上「图上的点」。

flowchart TB
  DS["数据源 = 已配置的连接器
（不是新造库，是「从哪边拉」）"]
  FM["字段映射
对方字段 → 本体属性"]
  ND["归一词典
对方别名/脏 ID → 标准 CI"]
  AB["入图 / 关联"]
  DS --> FM --> AB
  DS --> ND --> AB

	字段映射	归一词典
做什么	「列」对齐：对方 JSON/表字段名 → 本体属性名	「值」对齐：对方各种叫法 → 图上唯一对象
目的	同步进来的记录能写进正确属性	告警 instance、日志 host、简称能挂到同一台设备/同一 Pod
例子	`hostname` → `name`；`site` → `datacenter`	`pay-gw-03` / `10.1.2.7` → `ci-pod-pay-gw-03`

「数据源」是新建的吗？

一般不是。 数据源 = 「系统对接」里已配好的连接器（CMDB/ITSM/监控…）。映射页引用它，声明「这段映射用于从哪个外系统拉数」。商用名字应显示连接器上的客户称呼，而不是写死 Lab。

为什么现在很多是手工填写？应不应该下拉？

今天产品债：不少地方仍手工敲字段名/handler，实施成本高、易错。
目标体验：对接成功后，从外系统拉 schema / 样例 → 下拉选「对方字段」与「本体属性」做映射；handler / 入参尽量从 OpenAPI 或探测结果生成。下版优化建议见同目录 MD。

③ 图谱实例：同步进来的「活数据」

图谱实例（ABox）= 按本体落库后的真实对象列表：同步的 CI、变更、告警等都在这里浏览、抽查。

左侧按本体类筛选（网络设备 / Pod / 告警…）
徽章「外系统同步」= 对接链路进来的正式数据
打开详情可看属性与关系边

关于「隐藏旧教辅种子」： 这是开发期残留开关，不是标准商用功能，不应面向客户露出。正式产品应默认只展示对接数据；种子清理走运维流程，不放在图谱主交互上。（已记入下版优化：移除此勾选/改开发者模式。）

口播：本体是「模具」，图谱实例是「倒出来的铸件」；铸件来自你们对接的系统。

④ 可调用工具：给智能体用的工具（主语永远是「工具」）

分场景叫法（核心都是工具）： 旅程第四步 / 列表页 = 可调用工具；按钮 = 创建工具；编排步骤下拉 = 可调用工具（选项来自④）。旧称呼已废弃，统一用「工具」主语。

「创建工具」本质是：把对方已对接的 API，登记成智能体办事时可调用的一项工具。

完整调用地址 = 连接器 Base URL + Adapter 路由。
连接器管「连到哪、用什么认证」；④ 管「有哪些工具」；⑤ 编排管「哪一步调用哪个工具」。

表单项	含义
工具名称	给人看的名字（如「查询告警详情」）——你要填
系统 ID	系统自动生成（如 `ops:custom_…`），新建时不必填、详情只读
类型 rest_adapter	通过 HTTP 回源对方 API
关联连接器	用哪套 Base URL / 密钥
handler	平台侧适配逻辑；优先从推荐目录勾选
入参	调用时要填的参数（如 `alert_id`）

接口从哪来？有没有更好方式？

今天做法

推荐目录勾选导入工具 + 创建工具；技术 ID 系统生成。

后续方向

从连接器 OpenAPI / Lab「API 接口」勾选导入；AI 适配助手生成草案再确认。

④ ≠ 再建外系统，而是工具登记册；⑤ 编排里选的「可调用工具」就是这里的条目。

⑤ 智能体编排：办事协议 ≈「受控流程」

编排不是无限流程图玩具，而是把「查什么 → 调什么工具 → 是否需人工确认 → 出报告」固化成可评测、可发布的协议。

有判断 / 分支时怎么理解？

产品目标：步骤上可配置条件（例如：严重级别为 critical 才查变更；找不到 CI 则 HITL 让人补全）。

若当前界面分支编辑器能力有限，售前口播用「步骤 + 人工确认点」表达分支意图，并把「可视化条件分支」记为下版能力（见优化建议）。

示例结构（概念）： 1. 取告警详情 2. 关联配置项（归一词典） 3. 若 severity=critical → 拉最近变更 + 查指标否则 → 只查拓扑邻居 4. HITL：是否需要改配置？（需人工点确认） 5. 生成中文根因报告

多角色真实场景（不只 Pod）

场景 1 · 网络设备端口抖动（网工）

谁懂：网络 · 谁配置：映射设备类 + 拉链路监控指标工具

告警(端口 Down) → 归一到「核心交换机A」 → 查同机柜邻居 / 上联 → 查近 1h 变更（是否改过 ACL） → 报告：链路 / 设备 / 建议排查顺序

场景 2 · 主机磁盘将满（系统）

谁懂：服务器 / 系统运维

告警(磁盘 95%) → 挂到「主机 node-07」 → 列主机上跑的应用/Pod → 问数：哪个目录暴涨（若有日志/巡检工具） → 建议：扩容 / 清理 / 转移负载

场景 3 · 业务支付超时（应用 + 运维协同）

谁懂：应用 · SRE · 与 MVP「支付网关根因」同构

告警 → 业务服务「在线支付」 → 依赖：网关 Pod / LB / DB → 近期变更：发布单 / 扩容 → 指标：错误率 / 延迟 → 中文根因与影响面

场景 4 · 纯问数：机房割接影响面（值班长）

不一定要告警；走「资产问数」智能体

「DC-1 机房今晚割接，影响哪些业务服务？」 → 图上按机房/位置关系遍历 → 输出业务清单 + 责任团队（若有属性）

客户高频疑问 · 建议口播

疑问	怎么答
本体和 CMDB 表是不是一回事？	不是。CMDB 是你们库；本体是进 EASH 后的统一语义，靠映射对齐。
映射能不能自动？	方向是「探测 + 下拉点选 + AI 草案」；今天有手工成本，下版重点优化。
Lab / 沙箱算不算正式数据？	对接进来后按正式业务数据处理；沙箱只是货源，可换成客户真系统 URL。
可调用工具是否重复接接口？	不重复接。连接器已接；④只是登记「智能体可调哪些工具」。
编排能做复杂 BPM 吗？	首期是受控办事协议 + HITL；复杂分支持续增强，不是替换客户全部 ITSM 流程引擎。