Agentic AIOps | 运维智能体 落地:本体、知识图谱与 Harness 该怎么用

前面三篇文章，分别把三块能力讲透，都是为 「本体论、知识图谱、Harness 在运维智能体里该怎么用」 做铺垫。若你还没读过，建议按顺序补一下，读起来会顺很多：

本体论不神秘：就是给AI大模型装一套「业务说明书」：一文搞懂本体论是什么？

知识图谱遇上本体论：谁管事实、谁管规则，项目中如何落地。--知识图谱和本体论的关系是什么？

Harness 驾驭工程与本体论：企业智能体靠什么跑稳

前三篇讲的是 通用企业智能体架构；今天这篇 全部换成运维语境——CMDB、告警、变更、根因、影响面——回答：运维智能体和这三者到底是什么关系。

其实运维圈正在走同一条运维智能体之路：感知层接进 CMDB、监控、日志、工单，上面再挂 运维智能体，做故障根因分析、资产查询、变更评审。行业里有人叫 Agentic AIOps，有人叫 Agentic ITOps，本质一样：让智能体在 IT 运维场景里能查、能推、能办，而不是只会念告警摘要。

感知层已经能采很多数据了，但专业团队最常问的是：本体、知识图谱、Harness 驾驭工程，在智能运维里各管什么、怎么叠、先做哪一步？

今天这篇，用运维语言、运维例子，把 Agentic AIOps 的最小生产组合 讲清楚：有没有必要、怎么抽象本体、Harness 具体干什么、怎么分阶段落地。

总一眼看清：四块在智能运维里各干什么

先把分工记牢，后面例子都按这张图走：

• 本体 · 定概念和规则 — 工程里的 Ontology，是对运维领域 「概念 + 关系 + 规则」的显式说明（TBox）。它规定：允许有哪些类（CI、Alert、ChangeRequest…）、哪些关系合法（runs_on、impact…）、什么条件下能执行什么动作（生产变更要不要 CAB）。不写「pay-gw-03 此刻 CPU 92%」这种具体流水。

• 知识图谱 · 灌事实 — 在本体约束下，把 CMDB、监控、工单 持续同步 进来的实例与边（ABox）：ALERT-991 挂在哪个 Pod、CHG00412 动了哪台 LB、支付网关支撑哪个业务服务。实体归一 是硬活——同一主机多种写法必须合并。

• 智能体 · 用起来（入口） — 大模型 + Agent：听懂值班员提问，GraphRAG 按本体路径读图，Tools 调 MCP 查 CMDB/工单/监控，规划器 对照本体做合规检查——硬逻辑走图与规则，模型负责写报告。

• Harness · 治理与跑稳 — 不是某一个安装包，是让运维智能体 多步跑、错了拦、完了查 的工程外壳：运行时循环、诊断协议、MCP 工具注册、输出治理、评测集、审计日志、HITL 审批。

一句话：本体定概念和规则，知识图谱灌事实，智能体是入口，Harness 是治理。 落到架构上：底层 是 CMDB、Prometheus、工单、日志等源系统；中间层左侧 是本体（TBox），右侧 是图谱实例（ABox）；上层 是大模型与 Agent——GraphRAG 读图，Tools 执行动作，规划器对照本体做合规检查。

01先对齐场景：Agentic AIOps 比传统 AIOps 多要什么

传统 AIOps（Gartner 2016 年提出）主要靠机器学习吃 指标和告警，做降噪、关联、异常检测，价值在「少看屏、快发现」。Agentic AIOps 在此基础上，用大模型和智能体做 理解、规划、跨系统执行——例如自动拉拓扑、对照变更单、生成根因假设、甚至按规程触发回滚或建工单。

感知层通常已经接了多类数据：配置项（CMDB）、监控指标与告警、日志与链路追踪、工单与变更记录，有的还有 运行手册、应急预案、聊天群里的处置记录。数据来自 Zabbix、Prometheus、ELK、ServiceNow、自研 CMDB、Kubernetes API……口径各说各话。

核心判断放到运维里很直白：大模型擅长语言，不擅长替你保证「这台机器」和「那条告警」是不是同一个东西。 智能体要跨系统推理，中间必须有一层 大家认得的语义契约——本体来写；具体告警、CI、工单灌进图谱；多步诊断、工具调用、审计回放、变更拦截，靠 Harness 这套治理外壳撑住。

02有没有必要？先问四个问题，再看 Harness 拼不拼得上

不是每个运维场景都要三块齐上。可以用四个问题快速判断 语义层（本体 + 图谱） 要不要建；若答案是需要，再问 Harness 能不能接住生产节奏。

问题一：智能体要不要跨三个以上系统拼答案？

只查 CMDB 里「某 IP 对应哪台主机」，现有检索也许够用。要做 「这条告警影响了哪些业务服务、最近有没有相关变更」，就必须把监控、CMDB、工单串成链——建议上本体和知识图谱。

问题二：名词是不是经常对不上？

监控叫 host-10-1-2-3，CMDB 叫 SRV-DB-PROD-01，工单里写「订单库主库」——三个名字指同一台机器。没有本体的同义词和归一规则，智能体很容易 拼出看似合理、实则张冠李戴 的根因。

问题三：要不要可审计的推理链？

金融、政务、运营商、大型互联网的生产运维，结论要能回溯：依据哪条依赖、哪张变更单、哪条规则。纯向量 RAG 捞几段运维手册，很难达到这个标准——本体 + 图谱更稳。

问题四：智能体要不要执行动作？

只读问答可以凑合；要 自动关联工单、提交变更评审、触发预案脚本，必须在语义层登记 允许的动作和前置条件——这正是本体里「动作 + 规则」要管的；而 Harness 负责把这些动作 登记成 MCP 工具、走诊断协议、留审计日志，不是临场写 Prompt。

归纳：单系统 FAQ、只读查询，可以先用轻量 RAG 试水；根因分析、资产影响面查询、变更评审这类跨域场景，长期看绕不开本体、知识图谱和 Harness。 IETF 网络运维方向多篇草案（如 ITSM 知识图谱、NORIA 相关文档）和 Orange 开源的 NORIA-O 本体，都是在解决同一类问题：把异构运维数据 用共享词汇 织成一张可推理的图。

03回到运维智能体：本体、图谱、Harness 和 Agent 怎么分工

下面把前面「一眼看清」那张表，全部换成运维对象，方便对照你手头的 CMDB 和监控栈。

本体在智能运维里定义什么？

交付物是一份 运维语义说明书（TBox），不是数据库表。它写清楚四类东西：

• 结构层：ConfigurationItem、Dependency、Location——「机器和连线」允许怎么说。
• 功能层：TechnicalService、BusinessService——「业务是怎么被撑起来的」，impact 边怎么传导。
• 动态层：Alert、Incident、Metric——「发生了什么」允许挂到哪个 CI 上。
• 规程层：ChangeRequest、RemediationAction、Runbook——「谁能动、什么条件下能动」。

例如：本体规定「生产环境 + 核心 BusinessService 的变更 = 必须 CAB」——这是 规则；至于昨晚到底有没有 CHG00412，不进本体，进图谱。

知识图谱在智能运维里做什么？

把感知层数据 按本体类型 灌成可遍历的实例网（ABox）：ALERT-991observed_onpay-gw-03，pay-gw-03runs_onNode-07，同期 CHG00412targets 某 LoadBalancer……技术常见 Neo4j + Cypher + GraphRAG；实体归一 决定根因链能不能拼对——监控叫 host-10-1-2-3、CMDB 叫 SRV-DB-PROD-01、工单写「订单库主库」，必须映射到 同一个 CI ID。

Harness 在智能运维里起什么作用？

把「模型想查根因」变成 可重复、可审计的生产流程，主要包括：

• 运行时：LangGraph / Agent 平台的主循环——接请求、调模型、调工具、写记忆。
• 工具层
  ：MCP 封装 get_alert、trace_impact、list_changes——参数 schema 从本体导出，智能体不能乱发明字段。
• 诊断协议：先查拓扑、再查变更、禁止跳步——写进编排，不是每次故障临场 Prompt。
• 输出治理 + 编排 + 可观测性：对照本体规则打回违规建议（如「直接重启生产 LB」）、HITL 审批、全链路审计；

智能体（Agent）在其中的位置？

它是 入口：大模型听懂「991 这条告警要紧吗」；GraphRAG 沿本体路径读图谱；Tools 调 Harness 登记的 MCP；规划器对照本体判「这一步允不允许」。模型负责理解和写报告，推理链和审批规则走图与规则引擎。

缺任何一块的症状：缺本体 → Agent 和 Harness 都拦不住 业务胡说（不知道 impact 边是否合法）；缺图谱 → Agent 无料可查（只有规则、没有 ALERT-991 挂在哪）；缺 Harness → 本体和图谱是 静态说明书，多步诊断靠人肉 Prompt，上不了值班台节奏。

04不用这三块，智能运维智能体通常会踩哪些坑

结合业界实践（包括 Forrester 对 IT 管理「图谱化」的判断，以及多家 AIOps 厂商对 CMDB 局限的讨论），常见问题很集中：

坑一：感知层采得越多，智能体越糊涂。

指标、日志、资产、工单全塞进向量库，检索出来 片段都像对的，但 连不成合法依赖链。告警说 CPU 高，日志说连接超时，变更单说昨晚打了补丁——三者是不是同一故障故事？没有「依赖」「影响」「发生于」这类 显式关系，模型只能编故事。

坑二：CMDB 当本体用，迟早撞墙。

CMDB 存的是 配置项实例和关系（相当于图谱的 ABox），很多企业的 CMDB 还不完整、不实时。更关键的是：CMDB 的「关系类型」往往只有简单的 runs_on、depends_on，业务语义、变更规则、处置动作 并不在里面。把 CMDB 直接丢给大模型，等于 只有数据、没有语法说明书。

坑三：根因分析停在「相关性」，到不了「因果链」。

传统关联算法能把同时段告警捆在一起，但很难回答：「是哪个底层资源失效，沿依赖传导到了哪个业务服务？」 知识图谱按本体定义的路径做 多跳遍历，才适合回答这类问题。Tredence 等在供应链根因场景用「本体 + Neo4j + 大模型」的做法，逻辑可平移到运维。

坑四：变更评审缺「影响面计算」的语义基础。

BMC 等 ITSM 产品做变更影响分析，前提是 CMDB 里 影响关系（impact relationship） 已经建好。智能体要做变更评审，需要知道：改这台主机 → 影响哪些技术服务 → 再影响哪些业务服务 → 是否踩维护窗口、是否要 CAB 审批——这是一条 有类型的图路径，不是一段相似文本。

坑五：只能聊，不能办，或办了不可查。

没有在本体里定义 ChangeRequest、Incident、RemediationAction 等对象及合法状态迁移，智能体要么不敢调 API，要么乱调接口，审计过不了。arXiv 上 2026 年初一篇电信与数据中心 Agentic 诊断 论文讲得很清楚：把基础设施本体抽象成 受控的 MCP 工具接口，智能体 只能走登记过的查询和动作，Harness 才能满足生产环境的安全与可追溯。

坑六：把 Prompt 当 Harness。

每次故障临时写「你要先查 CMDB 再查变更」——不可复现、不可审计。应写进 诊断协议 + 工具编排；没有评测集的 Harness 不算完工。

05运维领域建议抽象的「关键本体」：一张最小清单

第三节讲了本体 在运维里定义什么；这里给出可直接上台工作坊的 MVO 清单。不必第一天就建全行业本体，先覆盖三类场景：根因分析、资产/影响面查询、变更评审。 下面这张清单，对齐 ITIL 常用对象，并参考 NORIA-O 的四维划分（结构、功能、动态、规程）和 ITSM 知识图谱草案里的思路。

（1）结构层——「机器和连线」

• ConfigurationItem（配置项）：服务器、虚拟机、Pod、交换机、数据库实例等。属性示例：主机名、IP、环境（生产/测试）、负责人。
• NetworkLink / Dependency（依赖）：物理连接、部署依赖、软件依赖。关系示例：runs_on（进程跑在主机上）、depends_on（服务依赖数据库）connected_to

• Location（位置）：机房、可用区、机柜——便于和资产查询、变更窗口规则结合。

（2）功能层——「业务是怎么被撑起来的」

• Application（应用）：逻辑应用或应用模块。
• TechnicalService（技术服务）：如「订单 API 服务」「支付网关集群」。
• BusinessService（业务服务）：如「在线下单」「会员支付」——变更评审和根因汇报时，领导往往要听这一层。

关系示例：Applicationpart_ofTechnicalService；TechnicalServicesupportsBusinessService。BMC CMDB 文档里的 影响服务模型（impact service model） 就是这类关系的工程化表达：低层 CI 故障，沿 impact 边向上传导。

（3）动态层——「发生了什么」

• Metric（指标）：CPU、延迟、错误率等；属性含阈值、采集源。
• Alert / Event（告警/事件）：某时某刻某 CI 上的异常信号。
• LogEntry / Trace（日志/链路）：可选入图或仍放日志系统，通过 observed_on

• Incident（事件单）：关联多条告警、处置记录、根因结论。
• Problem（问题单）：重复性根因的归纳对象。

（4）规程层——「谁能动、怎么动」

• ChangeRequest（变更请求）：计划内的配置、版本、网络调整。
• RemediationAction（处置动作）：重启、回滚、扩容、隔离——每种动作绑定 

• Runbook（预案）：和某类 Incident 或 CI 类型关联的标准操作。

注意：本体只定义「允许有哪些类型、哪些关系、哪些规则」；「10.1.2.3 上 CPU 92%」「变更单 CHG00412」是 实例，进图谱的 ABox。Harness 工具层的参数 schema，应从本体 导出——智能体只能填 enum 里的合法值。

06用一条链把三个场景讲透：本体 + 图谱 + Harness 一起走

下面用一个虚构但贴近生产的例子，把 根因、查资产、变更评审 串在同一张语义网上，并补全 Harness 怎么跑。

场景设定：在线支付业务出现超时。监控产生告警 ALERT-991：支付网关 Pod pay-gw-03 响应延迟超阈值。

本体里允许的关系链（简化）：

Alertobserved_onPod→Podruns_onNode→NodehostsTechnicalService「支付网关」→TechnicalServicesupportsBusinessService「在线支付」→ 同期存在ChangeRequestCHG00412targetsLoadBalancerused_byTechnicalService「支付网关」。

Harness 第 1 步 · 接入与意图识别

值班员问：「991 这条告警什么级别？要不要紧？和昨晚变更有没有关系？」运行时接到请求，不把几百条日志扔给模型。

Harness 第 2 步 · 按诊断协议调工具（背后读知识图谱）

登记好的 MCP 工具依次触发，例如：get_alert("ALERT-991") → trace_ci_to_service("pay-gw-03") → list_changes(window=24h, scope=支付网关)。每一步返回 结构化 JSON + 对象 ID，路径沿本体定义的边多跳查询：从 ALERT-991 找到 pay-gw-03 → 找到承载节点与支付技术服务 → 发现 24 小时内有一单变更 CHG00412 动了该服务依赖的负载均衡 → 拉取该变更的实施窗口与回滚方案。

Harness 第 3 步 · 本体规则拦截（输出治理）

若模型建议「直接重启生产 LB」——规程层规定：生产核心链路 RemediationAction 需二线 + 维护窗口。Harness 打回，改建议「关联 Incident、通知变更负责人、拉 Runbook」。

Harness 第 4 步 · 生成报告 + 可选写操作

大模型 只负责 把结构化结果写成值班员能读的段落，必须引用 ALERT-991、CHG00412、BusinessService「在线支付」。若策略允许，调用 link_alert_to_incident（写操作在白名单内，带审计）。

Harness 第 5 步 · 评测与反哺

日志入库；若图谱缺「LB —used_by→ 支付网关」边，工单给 图谱维护；若规则缺失，给 本体维护——这是 Harness → 语义层反馈闭环。

资产/影响面查询：值班员问：「核心交换机 SW-CORE-02 如果宕机，影响哪些业务？」Harness 调 trace_impact("SW-CORE-02")，沿 connected_to / depends_on / supports向上遍历 到所有关联的 TechnicalService 和 BusinessService，返回列表。

变更评审：提交变更「给数据库主机 db-prod-01 打内核补丁」。Harness 调 impact_analysis("db-prod-01")，沿 impact 关系找出受影响的技术服务「订单数据库服务」和业务服务「订单中心」，对照本体规则：生产环境 + 核心业务 = 必须 CAB 审批 + 维护窗口内执行；若图谱显示该主机上还跑着未声明的副本，评审直接 红灯——这是 规则引擎 + 图查询 的判断，不应让模型「感觉可以发」。

07感知层数据怎么映射进本体：常见来源对照

感知层采回来的数据，要通过 ETL / 流式接入 / RML 映射（IETF 知识图谱构建草案里常提的做法）对齐到本体类型，并做 实体解析：

• CMDB / 资产系统
   → ConfigurationItem、依赖关系。主机名、序列号、资产编号映射到 同一 CI 的唯一 ID。
• Kubernetes / 云 API
   → Pod、Node、Deployment，与 CMDB 主机 归一（同一 Node 在不同系统里的多种写法必须合并）。
• Prometheus / Zabbix / 商业 APM
   → Metric、Alert，通过 observed_on 挂到具体 CI。
• 日志 / 链路系统
   → Event 或外挂检索，关键字段与 CI、Incident 关联。
• ServiceNow / Jira / 自研 ITSM
   → Incident、ChangeRequest、Problem，与告警、CI 互链。
• 运维文档 / 应急预案
   → 可 RAG；其中稳定的概念（如「一级故障定义」「支付服务恢复步骤」）应 沉淀进本体或 Runbook 对象，而不是只存在向量块里。

Orange NORIA 平台的做法很有参考价值：用 NORIA-O 本体把网络 结构、功能、动态、规程 四维数据 reconciliation 进一张图，再用 SPARQL 或图查询回答专家定义的 能力问题（Competency Questions）——他们访谈运维专家提炼了 26 个问题，其中 16 个可用图查询直接回答。这说明 本体不是纸上谈兵，是对准真实运维问题的。

08落地架构：三层 + 治理，和开头那张分工表对齐

把开头的分工 画成架构，在 Agentic AIOps 里就是这样叠的：

底层 · 感知 / 数据源

CMDB、Prometheus/Zabbix、日志与链路、ServiceNow/Jira、K8s API、制度与 Runbook 文档——就是各系统里的 表、指标、工单、文档。只负责 采和存；智能体不直连猜表猜字段。

中间层 · 语义核心（本体 + 运维知识图谱）

左侧 · 本体（TBox）——定概念和规则能有哪些 CI、Alert、ChangeRequest 类型；runs_on、impact 哪些边合法；生产变更什么条件下可批、RemediationAction 谁有权执行。相对稳定，要版本治理。右侧 · 知识图谱（ABox）——灌事实ALERT-991 挂在哪个 Pod、CHG00412 动了哪台 LB、支付网关支撑哪个业务服务——从底层 映射、抽取、实体归一 持续同步进来。本体约束图谱「能有什么类型、什么边」；没有本体，CMDB 只是散落的结构化数据；没有图谱实例，本体只是空说明书。可选叠加 上下文层：记录「上次类似告警为什么批准了紧急变更」等决策痕迹。

上层 · 大模型与运维智能体（入口）

GraphRAG（读） — 按本体定义的路径在图谱里多跳检索，不只捞相似日志片段。Tools / MCP（办） — 调用 Harness 登记的工具：trace_impact、list_changes…参数 schema 从本体导出。规划与合规（管） — 对照本体规则判断「这一步是否允许」；影响面计算、变更红绿灯 走图查询 + 规则引擎，不走纯生成。大模型 听懂值班员提问、组织报告；推理与执行 锚在本体与知识图谱。

Harness · 治理（贯穿中间层与上层）

接入（企微/值班台/API）→ 运行时循环 → 诊断协议 → 输出治理 → HITL → 评测集 → 审计日志。本体版本谁批、图谱同步 SLA、Harness 评测通过率、动作白名单——乘法关系，任一维塌了，整体上不了生产。

2026 年初那篇 Agentic 诊断推理 论文的架构选择和咱们一致：本体藏在工具接口后面，智能体不能绕过 schema 乱访问数据——运维、安全、合规团队要的就是这种 可回放、可审计。

09三个运维场景，各自优先建什么

根因分析（RCA）

先建：动态层 + 结构层本体（Alert、CI、Dependency）；图谱打通监控—CMDB—变更。Harness 重点：多跳 GraphRAG 模板、诊断协议、只读先行；评测用历史故障 case。别急着：自动重启、自动变更——写操作后置。

IT 资产 / 影响面查询

先建：结构层 + 功能层（CI、TechnicalService、BusinessService、impact 边）。Harness 重点：trace_impact 类工具、聚合查询走固定 Cypher 模板（统计类勿纯 Text2Cypher）。图谱质量 决定答案；CMDB 关系不全，查再猛也白搭。

变更评审

先建：规程层本体（ChangeRequest 状态机、CAB 规则、维护窗口）；功能层 impact 链。Harness 重点：输出治理 必须 规则引擎/图查询判红绿灯，模型只写评审说明；HITL 节点写死在编排里。BMC 等 ITSM 的 影响服务模型 是业务侧对标物——低层 CI 变更沿 impact 传到业务服务。

10落地方法：分阶段走，Harness 与图谱同一节奏

阶段 0（1～2 周）· MVO 本体 + 场景选定

建议三选一优先：支付/核心交易链路的根因辅助、核心 CI 资产影响面问答、生产变更影响评审。只定义 15～25 个类、20～30 种关系，工作坊拉上 值班长、CMDB 管理员、监控负责人、ITSM 管理员 一起对表。同步 列出本场景需要的 MCP 工具清单（3～5 个只读工具即可）。产出：本体文档 + 诊断协议 v0.1。

阶段 1（2～4 周）· 主链路入图 + MiniHarness

先打通 一条主链路：CMDB + 一种监控 + 工单。把「同一 CI 多名字」治理到位，比选 Neo4j 还是别的图库更关键。Harness：LangGraph 或厂商 Agent 平台 + MCP 只读工具 + 运行时日志。暂不开放写操作。

阶段 2（2～3 周）· GraphRAG 模板 + 评测集

写 8～15 条 固定图查询模板（类似 Neo4j Aura Agent 教程建议：统计聚合走模板，自然语言转查询只作兜底）。用 30～50 个 真实历史故障和变更案例 评测：对象是否引对、影响面是否完整。Harness 加：总验证脚本——评测不过不算发布。

阶段 3（3～6 周）· 受控写操作 + 变更闭环

开放少量写操作：关联告警到 Incident、变更评审报告草稿、触发 Runbook 第一步。每条动作带 权限、审计日志、规则版本号。Harness 加：HITL 审批节点、PromQL/LogQL 核对（若需验证「服务已恢复」）。

阶段 4（持续）· 制度文档 → 本体提案 + Harness 迭代

从运行手册、变更管理制度、故障报告中，用 OntoEKG、myKG 等工具 提案 新类和新关系，人审 后并入本体。Harness 评测失败 case 分类反哺：补图谱、改本体、还是改工具 schema。

Forrester 2024～2025 年的观察也指出：ServiceNow、Atlassian 等把 CMDB 和协作图谱做得更动态，Dynatrace 等 AIOps 厂商的 依赖图 与 CMDB 双向同步——若你已有这些投资，Agentic AIOps 的落地应是 在现有图上补语义规则、Harness 接口与评测，而不是推倒重来。

关键原则：Harness 与图谱同一迭代节奏——加一种告警类型，本体、映射、工具 schema、评测 case 一起改。

11常见误配：三套技术别用错地方

把 Prompt 当 Harness

应写进 诊断协议 + 工具编排，不是每次故障临场叮嘱。

把 CMDB 当本体

CMDB 是实例为主；业务规则、动作前置条件、同义词 进本体或语义层，别指望 CMDB 字段自带。

Harness 工具不限 schema

让模型直连 SQL 或任意 API——Harness 退化成聊天。工具参数 从本体导出，智能体只能填 enum 里的值。

图谱很大、评测没有

Demo 漂亮，一上生产就幻觉。Agentic AIOps 没有评测集的 Harness 不算完工。

只要 Harness 不要语义层

Coding Agent 在仓库里尚可；运维跨 CMDB/监控/工单，没有本体与图谱，Harness 只能拦格式，拦不住业务错链。

12收个口：专业团队读完应能带走什么

上线前自问六句：

本体：MVO 是否覆盖当前场景的四层（结构、功能、动态、规程）？知识图谱：主链路是否入图、实体是否归一、impact 边是否可信？Harness 运行时：多步诊断是否有固定协议，而非临场 Prompt？Harness 工具：是否 MCP/REST 受控、schema 是否来自本体？Harness 治理：是否有评测集、审计日志、写操作白名单与 HITL？闭环：失败 case 是否分流到「补图谱」还是「改本体」还是「改工具」？

Agentic AIOps 要真解决问题，靠的不是更大的模型，而是 本体定概念和规则 + 知识图谱灌事实 + 智能体作入口 + Harness 做治理 四块一起上。推理链和审批规则 走图与规则引擎，大模型 负责理解人话和写报告——这样才既像智能体，又经得起专业人员挑刺，值班员也敢用。

点击 阅读原文 了解更多