平台要真正跑起来，业务逻辑是什么？

本文对照 docs/platform 架构 SSOT、产品原型 V1.1、当前代码， 说明 Pack 配置域与 Agent 运行域如何闭合。Admin 编排里的「步骤」≠ 全部智能体能力 — LLM / 提示词 / 规划 主要在引擎 agentsvc 内，由 Pack 的 reasoning_contract 约束，而非逐步下拉选择。

阅读顺序：先懂 办事术语 与 本体模型怎么建 → 再看 数据存哪三层 → 最后看运行时主链与 Pack 六步。
一句话：Pack 用 TBox 定义合法世界；用 办事协议（Protocol） 定义一次办事怎么查、怎么写报告；外部数据分三层入图或实时查；引擎按协议执行，Admin 编排配的是协议与契约，不是把 GPT 塞进每一个下拉框。

00a 「办事」相关术语（中英对照 + 场景举例）

这些是 EASH 产品用语（见 docs/planning/EASH-产品用语全局表），不是本体学专有名词，也不是 HTTP/MCP 那种网络协议。 代码里常写英文 protocol，界面中文叫 办事协议 — 指同一件事。

中文（界面）英文（代码/架构）指什么不是什么
用户问题 / utterance User Utterance / Trigger 值班员在 Workbench 输入的一句话，或 Webhook 推来的载荷 不是协议、不是步骤
办事 Agent Run / Task 从触发到交付报告的 一次完整执行（含 LLM、工具、Harness） 不等于用户那一句话本身
办事协议 Protocol Pack 里 YAML 定义的「这类事怎么查、按什么顺序、交付什么」— 如根因分析规程 ≠ HTTP 协议；≠ MCP 传输协议
办事步骤 Protocol Step 协议 steps[] 里的一行：可绑 tool，或 action（如生成报告） ≠ 用户提问；Admin 编排页编辑的就是它
办事链 / 证据链 Evidence Chain 办事过程中在 图谱上追溯 的路径：告警→CI→服务→变更 ≠ Temporal Workflow；是业务语义路径
推理契约 reasoning_contract 约束 LLM：允许调哪些 tool、最多几步、禁止跳步 协议的一部分，单独 YAML 文件
报告/上下文契约 context_contract 规定报告由哪些 数据块 组成（告警块、影响链块、变更块…） 协议的一部分；ContextAssembler 按它拉数
智能体 Agent Workbench 可选的一个「办事入口」，背后绑定一条或多条 Protocol ≠ 大模型本身；模型在 agentsvc 内
「契约」在 EASH 里 = 管理员写好的两条「硬规矩」：① 智能体允许查哪些数据、禁止乱调接口（推理契约）；② 报告必须包含哪几段、每段从哪来（报告契约）。都挂在同一条办事协议下，不是第四种独立东西。

场景举例：故障根因分析（支付网关）

以下用业务语言描述一次完整办事过程；括号内仅为技术备注，非必读。

值班员怎么说：李明在工程师工作台（平时和智能体对话的页面）里问：「ALERT-991 支付网关超时，是不是跟昨晚变更有关？」

  1. 系统接单 — 平台读懂这是在问「告警根因」，自动选用已发布的「支付网关根因分析」智能体来办这件事。（系统内部有意图识别，值班员无感。）
  2. 按哪套规程办 — 管理员事先在后台配好的一套办事协议，相当于 SRE 的「排查检查单」：规定必须先查告警、再追影响链、再查变更，不能跳步。（系统内编号：支付网关根因分析 v0.1。）
  3. 一步步做什么 — 检查单上的办事步骤（在管理后台「智能体编排」里可见、可改）：
    • 查这条告警：严重级别、发生在哪个 IT 组件上（哪台容器/机器）
    • 从该资源往上追：属于哪个技术服务、影响哪些业务
    • 列出近期相关变更单
    • 对照运维规程（例如：未审批的变更不得建议执行）
    • 汇总成一份根因辅助报告
  4. 能查什么、不能查什么 — 推理契约：只允许调用已登记的能力（查告警、追拓扑、列变更等），禁止擅自访问未授权系统。
  5. 报告必须写哪些段 — 报告契约：报告里必须有「告警摘要」「影响链路」「变更情况」三段，每段内容来自上面对应步骤的查询结果。
  6. 查出来的业务关系（办事链） — 先说明每个编号/名称是什么，再串关系：
    ALERT-991
    监控系统里的告警编号（不是设备名）
    pay-gw-03
    容器实例短名 — 支付网关程序的一个运行副本，不是物理机，也不是服务正式名
    「支付网关」
    技术服务名（运维口径的服务统称）
    「在线支付」
    业务系统名（用户侧产品能力）
    CHG00412
    变更单号（ITSM 变更管理系统分配）
    pay-lb-01
    负载均衡实例短名
    SW-CORE-02
    核心交换机设备名称（网络台账主机名，非序列号）
    告警 ALERT-991 关联容器 pay-gw-03 → 归属「支付网关」 → 支撑「在线支付」；变更单 CHG00412 曾调整 pay-lb-01；交换机 SW-CORE-02 端口异常可解释抖动。
    （关系存在知识图谱中，智能体按路径追溯，不是人工翻多台系统。）
  7. 交给值班员 — 输出一份结构化根因分析报告（含结论、证据、是否可建议操作），并记入办事记录，便于复盘和审计。

小结：值班员只问一句话；办事协议、步骤、契约都是管理员提前在领域包里配好的「检查单」。系统按单依次查真实数据，大模型负责读懂结果、写成通顺报告——不是让值班员自己一步步点十个按钮。

00a2 本体模型怎么建（先于「数据存哪」）

先定 世界结构（TBox），才知道数据该入图还是实时查。EASH 用 两套维度叠加，不是 CMDB 那种「基础设施→网络→交换机→型号」深树。 详见 docs/platform/EASH-运维本体最佳实践-TBox-2026-07-03.md。

维度 A · 横向 · 语义四层

回答「这类信息在办事里扮演什么角色」— 固定 4 层，不是 CMDB 分类树：

  • 结构层 — 资源/部署物（Pod、交换机、LB）
  • 功能层 — 服务视角（技术服务、业务服务）
  • 动态层 — 发生了什么（告警、指标、工单）
  • 规程层 — 怎么合法地做（变更、Runbook、维护窗口）

维度 B · 纵向 · 父类继承（浅）

所有机房里的「东西」先归到配置项大类，再细分为 Pod、交换机、负载均衡等 — 只继承一层，不建五六层深树。

  • 父类放大家都有的：编号、名称、IP、厂商、环境…
  • 子类放这类特有的：负载均衡的虚拟 IP；容器的命名空间
  • 交换机 vs 路由器：同一类「网络设备」，用「设备角色」字段区分，不另建子子类

举例：核心交换机 SW-CORE-02 在本体里怎么建？

用华东金融云咨询交付里的真实业务名说明；括号内是系统内部写法，给研发对照即可。

从场景出发：值班员问「ALERT-991 跟变更有关吗？」排查时发现链路抖动，怀疑核心交换机 SW-CORE-02 端口异常。智能体必须能答：

  • 这台交换机叫什么、在哪、谁管？
  • 它和支付网关是什么关系？（影响还是仅仅互联？）
  • 它和上下游交换机怎么连？

第一步 · 写能力问题（CQ）

「若 SW-CORE-02 故障，会影响哪些业务？」「告警链路上经过哪些网络设备？」— 能答这些题，本体才算够用。

第二步 · 贴语义四层（维度 A）

四层SW-CORE-02 属于哪层说明
结构层✅ 交换机在这层它是机房里的物理资源，不是「告警」也不是「变更单」
功能层不直接是「支付网关」是技术服务；交换机通过影响关系连到服务
动态层相关但不混类ALERT-991、端口 CRC 告警是另一类对象，用关系连到交换机
规程层不直接是变更单 CHG00412 是规程层对象，可作用于负载均衡，间接相关

第三步 · 定类与属性（维度 B）

在后台「本体构建」里，不为「华三核心交换机」单独建一层类，而是：

  • 类名：网络设备（系统类名：NetworkDevice；父类：配置项 ConfigurationItem）
  • 这台机器上的真实字段举例：
    • 名称：SW-CORE-02
    • 厂商：华三（H3C）
    • 角色：核心交换机（存在「设备角色」字段里，不另建 Switch 子类）
    • 管理 IP：10.2.0.12
    • 机柜：A 机房 A-03
    • 环境：生产
  • 前面几条来自父类「配置项」的公共字段（编号、名称、IP、环境等），后面几条是网络设备常用字段。

第四步 · 定关系（用业务话说，再落到系统）

业务上怎么说连到谁系统关系名（研发用）
和汇聚交换机互联SW-AGG-01connected_to（互联）
它的故障会影响支付网关服务技术服务「支付网关」impacts（影响）
放在哪个机房AZ-1 华东金融云 A 机房located_in（位于）
告警与它的关联（经服务链间接）ALERT-991 等告警直接关联某容器；交换机通过服务链参与证据链

梳理时只须想清楚「谁和谁什么关系」；写入本体后，管理后台会显示为「出边 / 入边」，含义相同。

第五步 · 数据从哪来（建完模型之后）

  • 交换机台账（名称、厂商、机柜、IP）→ 从 CMDB 同步进图谱，属于「稳定配置」层
  • 告警 ALERT-991 → 从监控系统推送进图谱，属于「动态事件」层，不写在「类定义」里当演示数据
  • 端口当前 CRC 错误率 → 办事时临时查监控，属于「运行时遥测」，不整表灌进图谱
用一句话串起来（值班员视角）： 核心交换机 SW-CORE-02（华三，A 机房） │ 互联 ├── SW-AGG-01 │ 影响 └── 技术服务「支付网关」──支撑──▶ 业务「在线支付」 告警 ALERT-991 关联容器 pay-gw-03，排查时沿服务链发现 SW-CORE-02 端口异常； 「此刻 CRC 多少」要去监控系统现查，不当作交换机台账里的固定字段。

对照后台：① 本体构建 → 类「网络设备」+ 关系表；② 映射归一 → CMDB「设备名称」对应「名称」；③ 图谱实例 → 同步后能看到 SW-CORE-02 节点及连线。完整类表见运维本体最佳实践文档。

构建顺序（咨询工作坊同款）：

① 定场景
② 写能力问题
③ 画证据链
④ 反推类与关系
⑤ 写入本体
⑥ 交付导入

五步解决「世界怎么建」；⑥ 交付物解决「建完装进系统、跑起来后给用户什么」— 见下文本例。

走一遍：已上线的「支付网关告警根因分析」智能体

对照工程师工作台里可选的根因分析智能体与咨询交付场景 A；五步用业务语言写，括号内仅作后台对照。

背景：2026-06-08 早高峰，李明收到监控系统推送：告警编号 ALERT-991（支付网关响应超时）。他问智能体：「是不是跟昨晚变更有关？」

步骤目的、本质与本例现网对应
① 定场景 目的 先回答「我们要让智能体帮值班员办哪一类事」，划定边界，避免一上来就建全公司所有资产类型。 本质 场景 = 一类重复的值班情境 + 期望交付物。不是某一次具体告警，而是「这类问题以后还会再来」。 本例 李明遇到的是：已有告警编号，怀疑与昨晚生产变更有关，需要根因辅助报告 — 这就是「故障根因分析」场景，不是「列资产清单」场景。 首期场景 S2；工作台：支付网关告警根因分析
② 写能力问题 目的 把有经验值班员脑子里会问的题写出来 — 尤其是带着假设去排查时的追问。不是为了替大模型写死台词，而是为了说明：要支撑这种排查思路，系统里必须存得住哪些事实。 本质 人排查时先有方向，再有问题。李明听说「可能跟昨晚变更有关」，他的思路大概是：
  • 这条告警是什么、多严重、发生在哪个 IT 组件上？（先弄清告警对象是容器还是机器、哪一台）
  • 这台机器属于哪个服务、会影响哪些业务？（看影响面）
  • 昨晚到底改了什么？改的是不是这条链路上的组件？谁批的、有没有回滚方案？（验证「变更假设」）
  • 建议的操作会不会违反运维规程？（核心支付能不能直接重启）
能力问题就是把这些追问整理成验收清单：图谱和接口建好后，必须能答上来。它们描述的是数据与语义要覆盖什么，不是运行时发给大模型的唯一提问列表。 本例（李明可能问的） 「告警 ALERT-991 关联的是哪台容器？」「支付网关会影响在线支付业务吗？」「变更单 CHG00412 改了什么、和负载均衡 pay-lb-01 有关吗？」「能建议重启吗？」 		咨询交付 CQ-01～CQ-05；评测 EV-01 验证能否答对
③ 画证据链 目的 把值班员证明或推翻假设时依赖的事实先后顺序画出来 — 报告里要能「拿得出手」地串证据，而不是只有一句「可能是变更」。 本质 证据链 = 一次成功排查后领导能看懂的因果与关联路径。它来自人的思维，但比能力问题更具体：已经用真实案例把「先看到什么、再联想到什么」固定成一条链。 本例 先弄清每个编号/名称是什么（见下表），再串成证据链：
ALERT-991
告警编号（监控系统分配）
pay-gw-03
容器实例短名（支付网关程序的一个副本，非物理机）
「支付网关」
技术服务名
「在线支付」
业务系统名
CHG00412
变更单号
pay-lb-01
负载均衡实例短名
SW-CORE-02
核心交换机设备名称（主机名）
告警 ALERT-991 关联容器 pay-gw-03 → 归属技术服务「支付网关」 → 支撑业务「在线支付」；变更单 CHG00412 曾动过负载均衡 pay-lb-01；交换机 SW-CORE-02 端口异常可解释抖动。报告里须逐条引用这些编号与名称，不能只给结论。
根因报告的结构；场景 A 业务故事
④ 反推类与关系 目的 把证据链里的名词变成系统可存的对象类型，把箭头变成允许的关联方式，这样智能体查图谱时不会「瞎连」。 本质 这是从故事到字典的翻译：告警、容器、服务、变更、交换机各是什么「类」；「告警发生在某组件上」「属于」「支撑」「作用于」各是什么「关系」。再贴上结构/功能/动态/规程四层，避免和 CMDB 深树混在一起。 本例 需要「告警」「容器」「技术服务」「业务服务」「变更单」「网络设备」等类；需要「告警关联到哪台容器」「服务支撑业务」「变更作用于负载均衡」等关系 — 否则证据链在系统里无处安放。 后台「本体构建」类表与关系表
⑤ 写入本体 目的 把上一步的「字典」正式录入领域包，成为全场景共用的合法世界；再接映射、同步，把真实数据灌进图谱。 本质 只登记类型和规则（TBox），不把某次 ALERT-991 写死在类定义里。相当于定好「棋盘和棋子种类」，具体棋局来自监控和 CMDB 同步。 本例 在「本体构建」里录入网络设备、告警、变更等类及关系；ALERT-991、SW-CORE-02 等具体实例等同步后出现在「图谱实例」页。 领域包 → 本体构建；同步后进图谱实例

常见疑问：能力问题列得越全，会不会束缚大模型？

不会 — 如果理解对它用在哪一层。

  • 能力问题用于「建本体、做验收」（设计阶段）：保证图谱能答资深值班员会问的关键事实。它不是运行时发给大模型的唯一 prompt，也不是禁止模型做别的推理。
  • 运行时约束的是「能查什么数据」，不是「能想什么」：办事检查单规定先查告警、再追链路、再列变更；推理契约规定只能调用已登记的能力（查告警、追拓扑等）。大模型仍在这些真数据上自由归纳、写报告、反驳或补充假设 — 但不能编造 CMDB 里没有的 CI，也不能偷偷调未授权接口。
  • 为什么要列问题？ 因为企业落地最怕「模型说得很像真的，但库里根本没有这条边」。能力问题逼我们在数据与语义上先对齐人的排查路径，而不是指望模型凭训练数据「猜」客户环境。
  • 和纯聊天式 AI 的差别： 纯聊天可以天马行空；运维智能体要可审计、可复盘、换模型结论仍稳定 — 所以用能力问题定「世界必须有什么」，用办事检查单定「查证的顺序」，把创造力留给读结果、写结论那一段。
③ 证据链 — 给领导的一句话（括号内为「这是什么」）： 告警编号 ALERT-991（监控告警号） → 容器 pay-gw-03（支付网关程序的一个运行实例，不是整机） → 技术服务「支付网关」（运维服务名） → 业务「在线支付」（面向用户的业务系统） 并行线索：变更单号 CHG00412（昨晚的变更单）→ 动过负载均衡 pay-lb-01（LB 实例名） 交换机 SW-CORE-02（机房核心交换机主机名）端口异常 → 解释网络抖动

和另外两个已实现智能体对比（同一套本体，不同场景）：
· 告警详情查询（S1）：只考「ALERT-991 什么情况、关联哪台组件」— 证据链更短，能力问题更少。
· 支付网关资产与依赖查询（场景 B）：不问变更根因，问「支付网关用了哪些 Pod、LB、数据库？」— 证据链从技术服务往下展开。
四个首期场景共用同一套本体，只是每条场景用到的类和关系多少不同。

⑥ 做完以后，产出的是什么？能导入系统吗？

咨询 / 工作坊的产出不是一篇 Word，而是一套可装进领域包（Pack）、可被系统读取的结构化配置，外加「同步进来的真实数据」和「智能体每次办事生成的报告」。分三层理解：

产出物是什么（业务语言）能否导入/进系统本例（支付网关根因）
① 本体配置 类、属性、关系的类型说明书（世界怎么建） ✅ 导入 Pack「本体构建」 网络设备、容器、告警、变更单等 22 类 +「告警关联容器」等关系
② 字段映射 CMDB/监控字段怎么对应到本体属性 ✅ 导入「映射与归一」 CMDB「设备名称」→ 交换机名称；告警 ID → 告警编号
③ 办事协议 智能体检查单：先查啥、再查啥、报告几段（结构化步骤列表） ✅ 导入「智能体编排」 查告警 → 追服务链 → 列变更 → 规程检查 → 生成报告（7 步）
④ 推理/报告契约 允许查哪些能力；报告必须含哪些段落 ✅ 挂在同一办事协议下 只能查告警/拓扑/变更；报告须有告警段、影响链段、变更段
⑤ 可调用工具 系统可调用的查询动作清单 ✅ 导入「可调用工具」 查告警、追溯服务、列变更、查变更详情…
⑥ 评测用例 验收考题：输入什么问法、必须答出什么编号 ✅ 导入「评测中心」 EV-01：问 ALERT-991，必须提到 CHG00412、在线支付等
⑦ 图谱实例 真实 CMDB/监控同步进来的具体机器、告警、变更 ✅ 经「数据同步」入图，非手写进本体类 同步后图里有 SW-CORE-02、pay-gw-03、ALERT-991 等节点
⑧ 单次办事报告 值班员每次提问后，智能体生成的根因辅助报告 ❌ 不导入；运行时产出，可审计留存 见下方示例

华东金融云咨询交付就是把上述 ①～⑥ 填好的样例，放在 docs/consulting-kit/；工程侧对齐进 packs/ops/，管理后台「咨询交付导入」可看到各模块已对齐状态。

结构化长什么样？举两个你能「看见」的例子：

例子 A · 导入系统的「办事协议」片段（机器读的配置，后台编排页展示为步骤列表）：

智能体名称：支付网关告警根因分析
步骤 1：查询告警（调用「查告警」能力）
步骤 2：从 IT 组件追溯到技术服务与业务
步骤 3：列出过去 24 小时相关变更单
步骤 4：若有变更，查看变更详情
步骤 5：对照运维规程 R01～R05
步骤 6：生成根因报告
步骤 7：记入办事审计
（完整配置在运维领域包内，名称：支付网关告警根因分析 v0.1）

例子 B · 智能体办完一次事后，交给值班员的报告（结构化 JSON，界面显示为中文段落）：

【告警摘要】 告警编号 ALERT-991，级别 P2，关联容器 pay-gw-03。
【影响链路】 pay-gw-03 → 技术服务「支付网关」→ 业务「在线支付」（核心）。
【变更情况】 24 小时内变更单 CHG00412，作用于负载均衡 pay-lb-01（连接池参数调整）。
【规程提示】 核心生产变更须 CAB；未满足条件不得建议直接重启 LB。
【结论摘要】 与近期变更及网络设备 SW-CORE-02 异常相关，建议进一步核查（自然语言段落由大模型在真数据上生成）。
底层字段含 alert_id、observed_on_ci_id、business_services、changes_24h 等，便于评测自动比对是否漏引关键编号。

小结：五步工作坊的「终点」不是 PPT，而是一套可导入的领域包配置 + 同步策略 + 评测题；配置装好后，工作台才能选到「支付网关告警根因分析」；李明每次提问，系统按检查单查证，产出的是报告⑧，不是再导入一份新配置。

三句话分清三件事：能力问题 = 建系统时「世界必须能答什么」；证据链 = 一次故障「事实怎么串起来」；办事检查单 = 智能体运行时「按什么顺序查」— 三者配合，但不互相替代。

00 关键缩写

避免文档里只写缩写而不知道在讲什么。

缩写英文全称中文 / 作用
MVOMinimum Viable Ontology工作坊用语「最小裁剪法」；产品交付见行业最佳实践本体文档，非「只做最小集」
TBoxTerminological Box术语层 / 模式 — Pack ① 本体构建：类、属性、关系定义（不含具体告警编号）
ABoxAssertional Box断言层 / 实例 — ③ 图谱实例：Neo4j 中具体 CI、服务、告警节点等
PackDomain Pack领域包 — packs/ops/ 内 ontology、tools、protocols 等可安装配置
RCARoot Cause Analysis根因分析智能体场景
MCPModel Context Protocol工具传输协议之一；集成页注册 Server，Pack ④ 声明可用 tool_id

咨询交付 = docs/consulting-kit/（华东金融云等填好的业务样例，可导入 Pack）。 工作坊模板在 docs/teaching-kit/，与咨询交付分工见咨询交付包总导航。

00b 外部数据分三层（入图 ≠ 实时查询）

Kevin 关切：交换机 SW1 的名称/品牌/位置是入图数据；告警当前状态、接口丢包是运行时数据 — 定义位置不同。

第一层 · 稳定配置/catalog（主要「入图」对象）

是什么：变化慢、可同步进 Neo4j 的资产与关系目录。

  • 例：交换机 SW-CORE-02：hostname、厂商、机柜位置、管理 IP
  • 例：Pod pay-gw-03、Node node-07、技术服务「支付网关」、LB pay-lb-01
  • 例：依赖边：pay-gw-03 → pay-lb-01 → 在线支付（业务服务）

在哪定义：① 本体 TBox（类/属性/关系）→ ② 映射（CMDB 字段 host_name → NetworkDevice.name）→ 系统连接 + 数据同步 Pull 入图 → ③ 图谱实例可见。

是不是固定不变？ 会变更（新机器、改配置），但频率低，适合 同步/增量，不是每次排障都打 API。

第二层 · 动态事件（可入图，但属「事件态」）

是什么：告警、工单、变更单等带时间戳的事件。

  • 类定义在 TBox（如 Alert、ChangeRequest）— 只定义「告警有哪些属性」
  • 具体实例如 ALERT-991 不应写死在「本体构建」演示里，应来自 Alertmanager Webhook → Kafka → 入图 或合规的同步任务

在哪定义：TBox 定义类型；实例由同步/推送产生；智能体通过 ops:get_alert 等工具读取（当前实现多查 Neo4j，目标态可标注来源）。

第三层 · 运行时遥测（不入图 bulk 同步，办事时查）

是什么：故障当下才有效的指标与状态 — 排障时必须「再查一次」的数据。

  • 例：某接口当前丢包率、P99 延迟、过去 15 分钟错误日志条数
  • 例：进程是否存活、连接池使用率、本次告警的实时 firing 状态

在哪定义：④ 可调用工具 packs/ops/tools/（如 ops:query_metrics、ops:query_logs）→ ③½ AI 适配 可把 Prometheus/Loki OpenAPI 写成 tool → ⑤ 编排步骤绑定该 tool → 办事时 ToolGate 回源 Prometheus/API。

与第一层关系：先用图知道「这条告警关联的是哪台交换机」；再用 query 工具查「该交换机接口 eth1 现在丢包多少」— 先拓扑、后遥测。

故障排查动作数据层定义位置当前 MVP
查告警关联哪个 IT 组件二/一tool ops:get_alert + 图Neo4j（待接 AM 真推送为主数据源）
追溯 CI→服务→业务一tool ops:trace_ci_to_serviceNeo4j 图模板
查 24h 内变更单二tool ops:list_changesNeo4j/ITSM 图或 PG
查接口丢包/延迟三tool ops:query_metrics（Pack 声明）待开发接通真 Prometheus
查错误日志片段三tool ops:query_logs待开发 Loki

本体最佳实践：docs/platform/EASH-运维本体最佳实践-TBox-2026-07-03.md

实例：交换机 SW-CORE-02 的三层数据长什么样？

一台交换机同时涉及三层，但存法不同 — 不是「交换机类里再分稳定态/事件态子类」。

TBox · ① 本体构建（模式，无具体告警号） 类 NetworkDevice（父类 ConfigurationItem）
属性定义 name, vendor, device_role, mgmt_ip, rack …
关系定义 connected_to→另一台网络设备，impacts→技术服务，located_in→机房
↓ CMDB 同步 / 映射 ② → Neo4j ③ 图谱实例
第一层 · 稳定配置（ABox 节点 + 边） 节点 SW-CORE-02（ci-net-sw-core-02）
name=SW-CORE-02 · vendor=H3C · device_role=switch · mgmt_ip=10.2.0.12 · 机柜 A-03
边 SW-CORE-02 connected_to SW-AGG-01 · impacts 支付网关(svc-pay-gw) · located_in AZ-1
↓ Alertmanager / ITSM 推送入图（事件实例）
第二层 · 动态事件（ABox，带时间戳） 告警节点 ALERT-991 · severity=P2 · metric=http_latency_p99 · fired_at=…
边 告警 ALERT-991 关联容器 pay-gw-03；告警影响技术服务「支付网关」
变更节点 CHG00412 targets → pay-lb-01（与 SW 间接相关）
梳理数据时写「告警关联配置项」「变更作用于 LB」— 入图后变成上面的关系名。
↓ 办事时 ToolGate 回源（不 bulk 写入 Neo4j）
第三层 · 运行时遥测（此刻才有效） ops:query_metrics：SW-CORE-02 接口 eth1/1 当前 CRC 错误率、丢包率（Prometheus）
ops:query_logs：过去 15min 交换机 syslog 片段
绑定：Pack ④ tools 声明 + ⑤ 编排步骤（排障到网络层时才调）
(SW-CORE-02 在 Neo4j 中的简化子图) [告警 ALERT-991 · 告警编号] --发生在--> [容器 pay-gw-03 · K8s 容器实例名] --属于--> [技术服务 支付网关 · 运维服务名] --支撑--> [业务 在线支付 · 业务系统名] [变更单 CHG00412 · 变更单号] --作用于--> [负载均衡 pay-lb-01 · LB 实例名] [交换机 SW-CORE-02 · 网络设备主机名] --影响--> [技术服务 支付网关] | connected_to v [NetworkDevice:SW-AGG-01] (第三层不画在图上) --query_metrics(eth1_crc)--> Prometheus 即时值

00b2 关系怎么梳理？出边 / 入边是什么？

数据梳理时用业务语言：关联、依赖、支撑、发生在…上、作用于。入 Pack 时写成系统关系名（如 observed_on 表示「告警发生在哪个组件上」）。 Admin 本体页上的 「出边 →」「入边 ←」 只是 以当前类为视角 的展示方式，不是另一种关系类型。

Admin 显示含义举例（当前类 = Alert）
出边 →关系从本类节点指向目标类例：告警「发生在」某台设备/容器上
入边 ←关系从其他类指向本类Incident related_to ← Alert（工单关联告警）

在哪定义：Pack ① packs/ops/ontology/relations.yaml（全 Pack 关系表）+ 各类详情页「关系」Tab（如你截图中 Alert 的 4 条）。工作坊梳理时填 教辅-04 关系清单，导入 Pack。

业务说法（梳理用）关系 id（TBox）方向（域→值域）首期场景
告警发生在哪个 IT 组件上 / 关联到哪台设备observed_onAlert → CIS1 S2
告警影响服务affectsAlert → TechnicalServiceS1 S2
CI 依赖 / 连接depends_on / connected_toCI → CIS2 S3 B
底层影响上层服务impactsCI → TechnicalServiceS2 S3
服务支撑业务supportsTechnicalService → BusinessServiceS2 S3 B
CI 属于服务 / 成员member_ofCI → TechnicalServiceB
Pod 跑在哪个节点runs_onPod → NodeS2 B
LB 被谁使用used_byLoadBalancer → TechnicalServiceS2 B
变更作用于targetsChangeRequest → CIS2
工单关联告警related_toIncident → Alert扩展
告警触发工单triggersAlert → Incident扩展

一共多少种？ 行业最佳实践约 26 种（见最佳实践文档 §七）；现网 Pack 约 23 条。梳理时不必先想出边入边 — 只需填「谁和谁什么关系」；引擎按 from/to 类自动决定方向，Admin 再翻译成出边/入边显示。

00c 提示词为何在代码里？能否在界面改？

结论：目标态应在 Pack 配置 + Admin 可编辑；当前为研发纵切临时硬编码。 待开发 G3-03
提示词用途当前位置（硬编码）目标态状态
办事主循环 system promptservices/agentsvc/app/llm_client.pypacks/ops/prompts/agent_system.yaml待开发
IntentRouter 路由 promptservices/agentsvc/app/router_prompt.pyPack prompts/router.yaml + Admin 编辑待开发
LLM 可用工具范围reasoning_contract/*.yaml编排页「推理契约」Tab 编辑YAML 有、UI 无
报告段落结构context_contract + schemas编排「报告与数据」Tab 可编只读

为何曾硬编码：G10/G11 先打通 LiteLLM 真调用与 IntentRouter，未做 Pack 提示词仓库与 Admin 表单。 不是产品终态；禁止用 mock 回落掩盖（须 503 明示 LLM 失败）。 第三阶段 P0：prompts/ Pack 化 + 编排页可改（见差距评估 G3-03）。

01 运行时主链（用户提问 → 办事完成）

点击节点查看该环节「设计 / 代码服务 / Admin 是否可见」。

触发
对话/Webhook
AccessGW
鉴权+Scope
IntentRouter
LLM+规则
Harness
Temporal
Context
Assembler
AgentBrain
LLM循环
ToolGate
工具执行
报告+OPA
发布/workbench

02 Pack 六步 + 系统连接（配置域）

Kevin 走查主线：语义 → 映射 → 图实例 → AI适配 → 能力 → 编排。切换 Tab 看每一步「应获取什么 / 现网做了什么」。

03 智能体五要素：配置在哪？运行在哪？

用户找不到「提示词 / LLM」是因为它们不在「步骤下拉」里，而在 Pack 契约 + 引擎服务中。

感知 Perceive

配置：protocol triggers、utterance 解析
运行：agentsvc 理解任务
Admin：触发方式 checkbox ✅
无独立提示词页

记忆 Memory

配置：会话 PG、图 ABox、context_contract blocks
运行：SessionMemory + Neo4j
Admin：图谱实例只读 ✅
契约不可编

规划 Plan

配置：reasoning_contract（allowlist、max_steps）
运行：agent_loop + LiteLLM tool_calls
Admin：步骤绑 tool ≈ 执行图 ⚠️
契约无 UI

执行 Act

配置：protocol steps[].tool、tools YAML
运行：ToolGate → 图模板/连接器 API
Admin：绑能力 ✅
已产品化

交付 Deliver

配置：context_contract.report、schemas
运行：synthesize + OPA
Admin：报告 Tab 只读 ⚠️
不可编模板

04 MCP 与 Pack / 集成 的关系

集成与生态（平台）
  • 注册 MCP Server URL
  • 刷新发现 → mcp:fixture:*
  • Webhook 密钥、API Key
  • 不定义业务语义
Pack ④ 可调用工具（领域）
  • 选用 tool_id（含 mcp:*）
  • schema、handler、连接器
  • 办事动作白名单
⑤ 编排（协议）
  • 步骤绑定已声明 tool
  • reasoning_contract 限制 LLM 只能调这些
  • 与 REST 工具同一套 ToolGate

MCP 不是「第二套接口适配」，而是 ToolGate 的一种 传输协议（见 platform/10 §五）。集成页管「连哪家 MCP」；Pack 管「办事能不能用」。

05 数据真伪一览（演示 vs 真链）

过滤查看各类数据在 MVP 中的实际来源。

数据/能力设计来源当前实现办事时路径状态

06 Kevin 疑问速查

07 设计问题与第三阶段方向

问题根因建议
编排看不到 LLMLLM 在 agentsvc；Admin 只配 tool 步骤编排页增加「推理契约」「提示词」Tab
同步 vs AI适配混淆入图（批）vs 声明 tool（设计时）未分轨展示Pack 首页数据血缘图
本体属性偏少MVO（Minimum Viable Ontology）21 类，非咨询交付 22 类全属性对齐最佳实践 TBox + 关系可编；实例走真同步
图谱含虚构告警seed 含 ALERT-991 等演示节点G3-11 去虚构实例；告警走 AM→ingest
提示词不可改agentsvc 硬编码G3-03 Pack prompts/ + Admin 编辑（待开发）
评测不知测啥smoke 测 tool 通，非金标准比对接 packs/ops/eval/cases
菜单乱配置域/运行域/平台域未分层上线八步 vs Pack 六步导航强化
连接器配置不可用部分按钮未接或仅演示连接器统一 Drawer + PG 双写

完整差距清单：docs/planning/2026-07-03-第三阶段开发计划/EASH-业务运行逻辑差距评估-2026-07-03.md

SSOT：docs/platform/03·16·18·19·10 · 原型 EASH-产品原型-V1.1 · 代码 agentsvc / admin-bff / toolgate · 2026-07-03