【引】新开了这个专栏“本体与AI”，将过去与本体语义、知识图谱相关的内容重新组织，并介绍或补充《本体驱动的AI 大模型：方法与实践》一书中的内容。
LLM固然出色，但企业AI系统必须做的远不止产生看似合理的文本，它必须理解：
- 哪些事实是永久的、哪些是临时的？哪些证据是可信的？
LLM不会自动拥有这种组织理解力。它可能认识"客户"这个词，但不会天生知道你的组织是否将客户定义为：创建账户的人、有活跃合同的公司、经过验证的法律实体、计费账户，或包含多个子公司的母组织。
这就是AI本体变得不可或缺的地方。AI本体是一个形式化的、机器可读的模型，定义了AI系统在某个领域内允许使用的概念、关系、规则、约束和含义，它给AI一个共享的世界模型。
数据库存储记录。
向量数据库检索相似内容。
知识图谱存储连接的事实。
本体定义这些事实的含义。
上下文图选择当前重要的内容。
AI Agent决定做什么。
1. 什么是本体？
"本体"一词起源于哲学，关注存在的本质和类别。在计算机科学和AI中，本体有一个更实用的含义：
本体是对一个领域中的概念以及赋予这些概念含义的关系、属性、规则和约束的显式规范。
考虑一个事件管理领域，可能包含概念：Service、Incident、Deployment、Team、Metric、Alert、Runbook、Policy、Environment、RemediationAction。关系如：
Incident affects Service
Service isOwnedBy Team
Service dependsOn Service
Deployment deploys Service
Incident wasTriggeredBy Deployment
Incident hasAlert Alert
Incident recommends Runbook
Runbook proposesAction RemediationAction
Action requiresApprovalFrom Team
规则如：
这不是一个简单的图结构，它是领域的语义契约。W3C的Web本体语言（OWL）正是为需要处理信息含义而非仅展示它的应用而创建的。
2. 本体不只是分类法
本体常与几个相关概念混淆。词汇表定义接受的术语，但不说明它们如何关联。分类法分层组织概念：
TechnologyAsset
├── Application
├── Database
├── MessageBroker
└── API
分类法主要表达is-a / subclass-of / broader-than / narrower-than。
模式描述的数据结构如下所说：
Incident:
id: string
severity: enum
created_at: datetime
模式回答：这条记录必须包含哪些字段？
本体描述领域含义：
CriticalIncident is a type of Incident.
Incident affects one or more Services.
Service is owned by exactly one Team.
RollbackAction is permitted only when a Deployment exists.
ProductionAction requires an Approval.
本体回答：这些信息意味着什么、如何关联、可以推断什么、什么是有效的？
知识图谱包含遵循本体的实例和事实：
INC-101 is an Incident.
payment-api is a Service.
INC-101 affects payment-api.
payment-api isOwnedBy payments-team.
这种区分常用两个术语表达：TBox（术语模型——类、关系和规则）和ABox（关于实际实例的断言）。本体是模型，知识图谱是填充后的世界。
3. 为什么LLM需要本体
LLM主要通过从数据中学习的统计关联运作，这在企业系统中造成几个问题——
术语歧义：不同系统可能使用customer/client/party/account holder/subscriber/consumer，可能指同一件事或完全不同的事。本体建立显式映射。
关系歧义：没有本体，提取模型可能创建relatedTo、connectedTo、associatedWith等几乎无法用于推理的通用关系。本体用精确语义替代它们。
幻觉结构：LLM在无约束下创建图时，可能发明新实体类型、重复关系、无效方向、无支撑事实和矛盾分类。本体将提取约束在受治理的语义空间内。
弱工具选择：Agent有restartservice、rollbackdeployment、refund_customer等工具。安全选择需要理解每个工具作用于什么对象、所需参数、前置条件、副作用、授权要求以及操作是否可逆。一个操作本体可以描述所有这些。
多Agent通信不一致：一个Agent产生{"app": "payments"}，另一个期望{"service_id": "payment-api"}。共享本体为Agent间通信提供通用实体定义和数据契约。
可解释性差：可靠的企业答案应连接到证据链。W3C PROV-O提供了表示实体、活动、Agent和推导历史的类和属性。
4. 企业AI的语义脊梁
理解本体驱动的AI架构的一种有用方式是一条语义脊梁：含义 → 事实 → 上下文 → 推理 → 行动。
| | |
|---|
| 第1层：本体 | | 什么是Service？什么是Incident？affects意味着什么？ |
| 第2层：知识图谱 | | payment-api dependsOn redis-prod |
| 第3层：上下文图 | | INC-101 affects payment-api; P95延迟8秒; DEP-58在事件前4分钟 |
| 第4层：Agent推理 | | 近期部署+延迟飙升+匹配历史事件→部署可能是触发因素 |
| 第5层：行动 | | 回滚DEP-58; 通知payments-team; 监控恢复15分钟 |
关键在于，本体治理可能的世界，上下文图描述相关的世界。
本体、知识图谱、上下文图和上下文组装，这四个概念相关但不可互换。
- 本体：相对稳定且领域范围的（Service dependsOn Service）
- 知识图谱：已填充并持续维护的（payment-api dependsOn redis-prod）
- 上下文图：临时且任务特定的（当前事件、当前指标值、最近部署、适用政策）
- 上下文组装（Context Fabric）：组装上下文图的基础设施
Prometheus ───────┐
OpenSearch logs ──┤
Neo4j ────────────┤
Vector database ──┤
Jira ─────────────┤
GitHub ───────────┤
Policies ─────────┘
↓
Context Fabric
↓
Small governed context graph
↓
AI agent
有用的本体包含的不只是实体名称，其核心构建块包括：
- 类（Classes）：Incident、Service、Deployment等，子类关系创建特化
- 个体（Individuals）：INC-101 instanceOf CriticalIncident
- 对象属性：Incident affects Service
- 数据类型属性：Incident hasSeverity "critical"
- 域和范围：affects的domain=Incident, range=Service，因此可推断INC-101是Incident、payment-api是Service
- 基数：ProductionService有且仅有一个拥有Team
- 不相交：HumanAgent disjointWith SoftwareAgent
- 等价：ApplicationService equivalentClass BusinessService
- 逆属性：isOwnedBy和owns互逆
- 属性传递：A dependsOn B, B dependsOn C → A indirectlyDependsOn C
- 约束：SHACL（Shapes Constraint Language）是W3C验证RDF数据图的标准
- 溯源：每个重要事实应记录来源、时间、产生者、变换和置信度
一个常见设计错误是把OWL和SHACL当作替代品，实际上它们是互补的。OWL是含义和推理，描述逻辑语义，遵循开放世界假设——缺失信息不自动意味着错误信息。SHACL则是数据验证，检查可用数据是否满足运营要求。
实用规则：OWL问"逻辑上能推出什么？" SHACL问"这些数据可接受吗？"用OWL做语义和推理，用SHACL做质量门和应用验证。
5. 一个Python示例
以下构建一个简化的本体驱动事件推理系统，演示本体创建、知识图谱填充、SHACL验证、基于规则的推理、溯源、运行时上下文图组装、确定性操作推荐和LLM就绪的上下文生成。
安装依赖：
pip install rdflib pyshacl pydantic
示例代码如下：
from __future__ import annotations
from rdflib import(
BNode,
Graph,
Literal,
Namespace,
RDF,
RDFS,
URIRef,
XSD,
)
from rdflib.namespace import OWL, SH
from dataclasses import dataclass
from datetime import datetime,timezone
from typing import Iterable
from pydantic import BaseModel,Field
from pyshacl import validate
# 命名空间
# --------------------------------------
EX = Namespace("https://myproject.com/ontology/")
RES = Namespace("https://myproject.com/resource/")
PROV = Namespace("http://www.w3.org/ns/prov#")
# ----------------------------------------------
# 冲突事件输入
# -----------------------------------------------
class IncidentInput(BaseModel):
incident_id: str = Field(min_length=1)
affected_service: str = Field(min_length=1)
severity: str
p95_latency_ms: float = Field(ge=0)
error_rate_percent: float = Field(ge=0, le=100)
recent_deployment_id: str | None = None
@dataclass(frozen=True)
classContextResult:
incident_uri: URIRef
graph: Graph
recommendations: tuple[str,...]
# --------------------------------------------------
# 本体构建
# --------------------------------------------------
def bind_namespaces(graph: Graph)-> None:
graph.bind("ex", EX)
graph.bind("res", RES)
graph.bind("prov", PROV)
graph.bind("owl", OWL)
graph.bind("sh", SH)
def add_class(
graph: Graph,
class_uri: URIRef,
label: str,
parent: URIRef | None = None,
)-> None:
graph.add((class_uri, RDF.type, OWL.Class))
graph.add((class_uri, RDFS.label, Literal(label)))
if parent is not None:
graph.add((class_uri, RDFS.subClassOf, parent))
def add_object_property(
graph: Graph,
property_uri: URIRef,
label: str,
domain: URIRef,
range_: URIRef,
)-> None:
graph.add((property_uri, RDF.type, OWL.ObjectProperty))
graph.add((property_uri, RDFS.label, Literal(label)))
graph.add((property_uri, RDFS.domain, domain))
graph.add((property_uri, RDFS.range, range_))
def add_datatype_property(
graph: Graph,
property_uri: URIRef,
label: str,
domain: URIRef,
range_: URIRef,
)-> None:
graph.add((property_uri, RDF.type, OWL.DatatypeProperty))
graph.add((property_uri, RDFS.label, Literal(label)))
graph.add((property_uri, RDFS.domain, domain))
graph.add((property_uri, RDFS.range, range_))
def build_ontology()-> Graph:
graph = Graph()
bind_namespaces(graph)
ontology_uri = URIRef("https://myproject.com/ontology")
graph.add((ontology_uri, RDF.type, OWL.Ontology))
graph.add((ontology_uri, RDFS.label, Literal("Ontology-driven incident intelligence")))# Classes
add_class(graph, EX.EnterpriseEntity,"Enterprise entity")
add_class(graph, EX.Service,"Service", EX.EnterpriseEntity)
add_class(graph, EX.ProductionService,"Production service", EX.Service)
add_class(graph, EX.Incident,"Incident", EX.EnterpriseEntity)
add_class(graph, EX.CriticalIncident,"Critical incident", EX.Incident)
add_class(graph, EX.Deployment,"Deployment", EX.EnterpriseEntity)
add_class(graph, EX.Team,"Team", EX.EnterpriseEntity)
add_class(graph, EX.MetricObservation,"Metric observation", EX.EnterpriseEntity)
add_class(graph, EX.Policy,"Policy", EX.EnterpriseEntity)
add_class(graph, EX.Action,"Action", EX.EnterpriseEntity)
add_class(graph, EX.RollbackAction,"Rollback action", EX.Action)
add_class(graph, EX.NotificationAction,"Notification action", EX.Action)
# 对象属性
add_object_property(graph, EX.affects,"affects", EX.Incident, EX.Service)
add_object_property(graph, EX.isOwnedBy,"is owned by", EX.Service, EX.Team)
add_object_property(graph, EX.dependsOn,"depends on", EX.Service, EX.Service)
add_object_property(graph, EX.wasPrecededBy,"was preceded by", EX.Incident, EX.Deployment)
add_object_property(graph, EX.observedFor,"observed for", EX.MetricObservation, EX.Service)
add_object_property(graph, EX.hasObservation,"has observation", EX.Incident, EX.MetricObservation)
add_object_property(graph, EX.governedBy,"governed by", EX.Action, EX.Policy)
add_object_property(graph, EX.targets,"targets", EX.Action, EX.Service)
add_object_property(graph, EX.recommendsAction,"recommends action", EX.Incident, EX.Action)
# Inverse property declaration
graph.add((EX.owns, RDF.type, OWL.ObjectProperty))
graph.add((EX.owns, OWL.inverseOf, EX.isOwnedBy))
# 数据类型属性
add_datatype_property(graph, EX.identifier,"identifier", EX.EnterpriseEntity, XSD.string)
add_datatype_property(graph, EX.severity,"severity", EX.Incident, XSD.string)
add_datatype_property(graph, EX.metricName,"metric name", EX.MetricObservation, XSD.string)
add_datatype_property(graph, EX.metricValue,"metric value", EX.MetricObservation, XSD.decimal)
add_datatype_property(graph, EX.observedAt,"observed at", EX.MetricObservation, XSD.dateTime)
add_datatype_property(graph, EX.confidence,"confidence", EX.Action, XSD.decimal)
add_datatype_property(graph, EX.requiresHumanApproval,"requires human approval", EX.Action, XSD.boolean)
return graph
# -----------------------------------------
# SHACL
# -----------------------------------------
defadd_property_shape(
shapes: Graph,
node_shape: URIRef,
path: URIRef,
*,
min_count: int | None = None,
max_count: int | None = None,
class_: URIRef | None = None,
datatype: URIRef | None = None,
message: str,
)-> None:
property_shape = BNode()
shapes.add((node_shape, SH.property, property_shape))
shapes.add((property_shape, SH.path, path))
shapes.add((property_shape, SH.message, Literal(message)))
if min_count isnot None:
shapes.add((property_shape, SH.minCount, Literal(min_count, datatype=XSD.integer)))
if max_count isnot None:
shapes.add((property_shape, SH.maxCount, Literal(max_count, datatype=XSD.integer)))
if class_ isnot None:
shapes.add((property_shape, SH["class"], class_))
if datatype isnot None:
shapes.add((property_shape, SH.datatype, datatype))
defbuild_shapes_graph()-> Graph:
shapes = Graph()
bind_namespaces(shapes)
# Production service must have exactly one owning team
production_service_shape = EX.ProductionServiceShape
shapes.add((production_service_shape, RDF.type, SH.NodeShape))
shapes.add((production_service_shape, SH.targetClass, EX.ProductionService))
add_property_shape(shapes, production_service_shape, EX.isOwnedBy,
min_count=1, max_count=1, class_=EX.Team,
message="A production service must have exactly one owning team.")
# Incident needs identifier and affected service
incident_shape = EX.IncidentShape
shapes.add((incident_shape, RDF.type, SH.NodeShape))
shapes.add((incident_shape, SH.targetClass, EX.Incident))
add_property_shape(shapes, incident_shape, EX.identifier,
min_count=1, max_count=1, datatype=XSD.string,
message="An incident must have exactly one identifier.")
add_property_shape(shapes, incident_shape, EX.affects,
min_count=1, class_=EX.Service,
message="An incident must affect at least one service.")
# Metric observation requires name, value and timestamp
observation_shape = EX.MetricObservationShape
shapes.add((observation_shape, RDF.type, SH.NodeShape))
shapes.add((observation_shape, SH.targetClass, EX.MetricObservation))
add_property_shape(shapes, observation_shape, EX.metricName,
min_count=1, max_count=1, datatype=XSD.string,
message="A metric observation requires one metric name.")
add_property_shape(shapes, observation_shape, EX.metricValue,
min_count=1, max_count=1, datatype=XSD.decimal,
message="A metric observation requires one decimal value.")
return shapes
# ---------------------------------
# 知识图谱构建
# ---------------------------------
def build_enterprise_knowledge_graph(ontology: Graph)-> Graph:
graph = Graph()
bind_namespaces(graph)
for triple in ontology:
graph.add(triple)
# 团队
graph.add((RES.payments_team, RDF.type, EX.Team))
graph.add((RES.payments_team, EX.identifier, Literal("payments-team")))
graph.add((RES.platform_team, RDF.type, EX.Team))
graph.add((RES.platform_team, EX.identifier, Literal("platform-team")))
# 服务
graph.add((RES.payment_api, RDF.type, EX.ProductionService))
graph.add((RES.payment_api, EX.identifier, Literal("payment-api")))
graph.add((RES.payment_api, EX.isOwnedBy, RES.payments_team))
graph.add((RES.redis_prod, RDF.type, EX.ProductionService))
graph.add((RES.redis_prod, EX.identifier, Literal("redis-prod")))
graph.add((RES.redis_prod, EX.isOwnedBy, RES.platform_team))
graph.add((RES.payment_api, EX.dependsOn, RES.redis_prod))
# 治理策略
graph.add((RES.production_change_policy, RDF.type, EX.Policy))
graph.add((RES.production_change_policy, EX.identifier, Literal("POL-PROD-CHANGE-01")))
# 作为组织记忆
graph.add((RES.INC_072, RDF.type, EX.CriticalIncident))
graph.add((RES.INC_072, EX.identifier, Literal("INC-072")))
graph.add((RES.INC_072, EX.affects, RES.payment_api))
return graph
# ----------------------------------------
# Runtime incident ingestion
# --------------------------------
def safe_resource_id(raw_value: str)-> str:
return raw_value.strip().replace(" ","_").replace("-","_").replace("/","_")
def ingest_incident(graph: Graph, incident: IncidentInput)-> URIRef:
incident_uri = RES[safe_resource_id(incident.incident_id)]
service_uri = RES[safe_resource_id(incident.affected_service)]
incident_class = EX.CriticalIncident if incident.severity.lower()=="critical"else EX.Incident
graph.add((incident_uri, RDF.type, incident_class))
graph.add((incident_uri, EX.identifier, Literal(incident.incident_id)))
graph.add((incident_uri, EX.severity, Literal(incident.severity.lower())))
graph.add((incident_uri, EX.affects, service_uri))
now = datetime.now(timezone.utc).isoformat()
metrics ={"p95_latency_ms": incident.p95_latency_ms,"error_rate_percent": incident.error_rate_percent}
for metric_name, value in metrics.items():
observation_uri = RES[f"{safe_resource_id(incident.incident_id)}_{metric_name}"]
graph.add((observation_uri, RDF.type, EX.MetricObservation))
graph.add((observation_uri, EX.metricName, Literal(metric_name)))
graph.add((observation_uri, EX.metricValue, Literal(value, datatype=XSD.decimal)))
graph.add((observation_uri, EX.observedAt, Literal(now, datatype=XSD.dateTime)))
graph.add((observation_uri, EX.observedFor, service_uri))
graph.add((incident_uri, EX.hasObservation, observation_uri))
# Provenance
graph.add((observation_uri, RDF.type, PROV.Entity))
graph.add((observation_uri, PROV.wasAttributedTo, RES.prometheus))
graph.add((RES.prometheus, RDF.type, PROV.Agent))
if incident.recent_deployment_id:
deployment_uri = RES[safe_resource_id(incident.recent_deployment_id)]
graph.add((deployment_uri, RDF.type, EX.Deployment))
graph.add((deployment_uri, EX.identifier, Literal(incident.recent_deployment_id)))
graph.add((incident_uri, EX.wasPrecededBy, deployment_uri))
return incident_uri
# --------------------------------------------------
# 验证
# -----------------------------------------------
def validate_graph(data_graph: Graph, shapes_graph: Graph)-> None:
conforms, _, report_text = validate(
data_graph=data_graph, shacl_graph=shapes_graph, ont_graph=data_graph,
inference="rdfs", abort_on_first=False, allow_infos=True, allow_warnings=True)
ifnot conforms:
raise ValueError("Knowledge graph failed semantic validation:\n"+ report_text)
# ----------------------------------------
# 轻量级推理 (materialize rdfs:subClassOf)
# ----------------------------------------
def materialize_subclass_types(graph: Graph)-> int:
inferred_count =0
changed =True
while changed:
changed =False
for entity, _, entity_class in list(graph.triples((None, RDF.type, None))):
for _, _, parent_class in list(graph.triples((entity_class, RDFS.subClassOf, None))):
inferred_triple =(entity, RDF.type, parent_class)
if inferred_triple notin graph:
graph.add(inferred_triple)
inferred_count +=1
changed =True
return inferred_count
# --------------------------------------------------------
# 上下文的图装配 (deliberately small, decision-scoped)
# -------------------------------------------------------
def assemble_context_graph(enterprise_graph: Graph, incident_uri: URIRef)-> Graph:
context = Graph()
bind_namespaces(context)
# Current incident facts
for triple in enterprise_graph.triples((incident_uri, None, None)):
context.add(triple)
for triple in enterprise_graph.triples((None, None, incident_uri)):
context.add(triple)
affected_services = set(enterprise_graph.objects(incident_uri, EX.affects))
for service_uri in affected_services:
for triple in enterprise_graph.triples((service_uri, RDF.type, None)):
context.add(triple)
for triple in enterprise_graph.triples((service_uri, EX.identifier, None)):
context.add(triple)
for triple in enterprise_graph.triples((service_uri, EX.isOwnedBy, None)):
context.add(triple)
for triple in enterprise_graph.triples((service_uri, EX.dependsOn, None)):
context.add(triple)
# Include owner details
for owner_uri in enterprise_graph.objects(service_uri, EX.isOwnedBy):
for triple in enterprise_graph.triples((owner_uri, RDF.type, None)):
context.add(triple)
for triple in enterprise_graph.triples((owner_uri, EX.identifier, None)):
context.add(triple)
# Include direct dependency details
for dep_uri in enterprise_graph.objects(service_uri, EX.dependsOn):
for triple in enterprise_graph.triples((dep_uri, RDF.type, None)):
context.add(triple)
for triple in enterprise_graph.triples((dep_uri, EX.identifier, None)):
context.add(triple)
# Similar historical incidents
for similar in enterprise_graph.subjects(EX.affects, service_uri):
if similar != incident_uri:
for triple in enterprise_graph.triples((similar, RDF.type, None)):
context.add(triple)
for triple in enterprise_graph.triples((similar, EX.identifier, None)):
context.add(triple)
# Current observations
for obs_uri in enterprise_graph.objects(incident_uri, EX.hasObservation):
for triple in enterprise_graph.triples((obs_uri, None, None)):
context.add(triple)
# Applicable policy
for triple in enterprise_graph.triples((RES.production_change_policy, None, None)):
context.add(triple)
return context
# ----------------------------------------------
# 确定性推荐规则
# ----------------------------------------------
def derive_recommendations(context: Graph, incident_uri: URIRef)-> tuple[str,...]:
# ... (deterministic rules: latency >= 5000 + error_rate >= 20 + recent deployment
# → recommend rollback with confidence 0.91, requires approval)
# Returns tuple of human-readable recommendations
pass# Simplified for article — full implementation in source
# --------------------------------------------------
# 端到端编排
# --------------------------------------------------
def process_incident(incident: IncidentInput)-> ContextResult:
ontology = build_ontology()
enterprise_graph = build_enterprise_knowledge_graph(ontology)
shapes_graph = build_shapes_graph()
incident_uri = ingest_incident(enterprise_graph, incident)
materialize_subclass_types(enterprise_graph)
validate_graph(data_graph=enterprise_graph, shapes_graph=shapes_graph)
context_graph = assemble_context_graph(enterprise_graph, incident_uri)
recommendations = derive_recommendations(context=context_graph, incident_uri=incident_uri)
return ContextResult(incident_uri=incident_uri, graph=context_graph, recommendations=recommendations)
def main()-> None:
incident = IncidentInput(
incident_id="INC-101",
affected_service="payment-api",
severity="critical",
p95_latency_ms=8_000,
error_rate_percent=32,
recent_deployment_id="DEP-58",
)
result = process_incident(incident)
print("Recommendations:")
for rec in result.recommendations:
print(f"- {rec}")
print("\nLLM-ready governed context:")
print(context_to_text(result.graph))
if __name__ =="__main__":
main()
这个程序实际展示了——
- 本体限制语义空间：声明显式类和精确关系，提取层被约束在已批准概念中
- 知识图谱包含企业记忆：存储稳定事实，可跨数千个事件复用
- SHACL保护数据质量：拒绝无所有者的生产服务、无受影响服务的事件等无效语义状态
- 推理使隐含知识显式化：CriticalIncident subclassOf Incident → INC-101 type Incident
- 上下文图小于企业图谱：Agent只接收当前事件、受影响服务、当前指标、最近部署、服务所有者、直接依赖、适用政策和相似历史事件——这是上下文工程的核心
- 行动受治理：回滚推荐包含目标服务、置信度、适用政策、人工审批要求和生成Agent——远比问LLM"服务挂了，怎么办？"安全得多
6. 本体方法与其他大模型技术的关系
传统RAG在答案直接出现在语义相似文本中时有效。但对于"A团队拥有的、在最近部署期间变更的、受政策P管辖的生产服务有哪些？"这类问题，相似性检索力不从心——答案需要实体身份、类型化关系、多跳遍历、时间过滤和政策语义。
用户问题
↓
本体引导的实体和意图映射
↓
┌─────────────────────────────────────┐
│ 向量搜索：相关文档 │
│ 图搜索：实体和路径 │
│ 关键词搜索：精确标识符 │
│ SQL/API搜索：实时运营数据 │
└─────────────────────────────────────┘
↓
约束和权限过滤
↓
上下文图组装
↓
重排序和Token预算缩减
↓
LLM或Agent
没有本体引导时LLM可能提RELATED_TO/ USES/ CONNECTED_WITH等不一致关系；有本体时只允许dependsOn，且要求规范标识符。本体不限于业务实体，还可以建模Agent行为。一个全面的Agent本体可能包含四个互联领域：
1.领域本体：定义业务世界（Customer、Account、Transaction、Incident、Service、Policy）
2.任务本体：定义任务和分解
InvestigateIncident
├── IdentifyAffectedService
├── RetrieveRecentChanges
├── AnalyzeMetrics
├── ComparePastIncidents
└── RecommendRemediation
3 工具本体：定义能力（QueryPrometheus、SearchLogs、RollbackDeployment、NotifyTeam），每个工具包含输入、输出、前置条件、副作用、所需权限、成本、延迟、可逆性
4 治理本体：定义控制（Role、Permission、Policy、RiskLevel、Approval、ProhibitedAction、SensitiveDataClass）
这让Agent能够推理："我是RCA Agent，任务需要当前延迟，QueryPrometheus提供指标观测。我有权限读取指标，RollbackDeployment变更生产，生产变更需要审批。因此，我可以推荐回滚但不能自主执行。"
MCP可以向AI应用暴露资源和工具，而本体提供理解这些资源和工具的语义模型：
Ontology
├── Defines Service, Incident, Tool and Policy
├── Defines tool input/output semantics
└── Defines permitted relationships
↓
MCP Registry
├── Prometheus tool
├── Log-search tool
├── Deployment tool
└── Incident-management tool
↓
Agent
本体感知的MCP注册表可以回答：哪个工具返回MetricObservations？哪些工具能作用于ProductionService？哪个操作修改生产？哪个工具需要ChangeApprover权限？
本体因此充当工具连接之上的语义发现和治理层。
多Agent系统需要的不仅是消息传递——Agent需要共享语义。没有共享本体：{"system": "payment", "problem": "slow"}——含义模糊。有本体对齐的契约：
{
"@type":"CriticalIncident",
"identifier":"INC-101",
"affects":{
"@type":"ProductionService",
"identifier":"payment-api"
},
"hasObservation":{
"@type":"MetricObservation",
"metricName":"p95_latency_ms",
"metricValue":8000
}
}
每个Agent都能一致地解读同一个对象，本体成为协调的共享语言和世界模型。
7. 如何正确设计AI本体
不要从创建数百个类开始，而要从决策开始。
- 定义业务成果：减少事件诊断时间、防止未授权修复、产生有证据支撑的RCA
- 编写能力问题：哪些服务受影响？谁拥有？事件前变更了什么？哪些依赖不健康？哪些历史事件相似？哪些修复被允许？谁必须审批？哪些证据支持推荐？
- 识别规范概念：提取名词，但不要把每张数据库表变成类
- 将关系定义为动词：Incident affects Service（避免relatedTo/linkedWith等模糊关系）
- 定义标识符和身份规则：决定如何跨系统识别同一实体
- 分离稳定和动态知识：服务所有权是稳定的；当前延迟是动态的
- 添加约束：什么必须始终存在？什么绝不能发生？用SHACL编码
- 从一开始就添加溯源：源、时间戳、Agent/进程、变换、置信度、版本
- 用真实查询测试：评估图能否回答能力问题
- 建立本体治理：本体所有者、领域管家、变更审查流程、版本策略、废弃策略等，本体是活的
- 把本体当作属性图上的标签，仍需清晰定义、关系语义、约束、身份规则、溯源和治理
- 建模数据库而非业务——AI需要Customer/Transaction/Merchant，不需要CUSTOMER MASTER ROW
- 创建一个巨型通用本体：应优先模块化=核心本体+客户本体+支付本体+事件本体+Agent本体
- 只用名词——只有类没有有意义属性的列表是分类法，不是有用的推理模型
- 过度使用relatedTo，每个关系都是relatedTo的图有连接性但几乎没有含义
- 把整个图传给LLM，运行时目标不是最大上下文，而是最小充分上下文
- 假设LLM生成的本体自动正确——LLM可加速候选提取，但领域专家应审查重要语义和监管决策
- 忽视本体演进——业务含义会变化，本体版本和迁移必须像软件发布一样管理
基于本体方法的Agent 参考架构如下：
┌─────────────────────┐
│ Ontology Registry │
│ OWL / SHACL / Docs │
└──────────┬──────────┘
│
┌──────────────┐ ┌─────────▼──────────┐
│ Operational │────▶│ Identity and │
│ databases │ │ semantic mapping │
└──────────────┘ └─────────┬──────────┘
│
┌──────────────┐ ┌─────────▼──────────┐
│ Documents │────▶│ Knowledge graph │
│ logs, APIs │ │ + vector index │
└──────────────┘ └─────────┬──────────┘
│
┌─────────▼──────────┐
│ Context Fabric │
│ Entity resolution │
│ Graph traversal │
│ Hybrid retrieval │
│ Authorization │
│ Temporal filtering │
│ Reranking │
└─────────┬──────────┘
│
┌─────────▼──────────┐
│ Context Graph │
│ Small + relevant │
└─────────┬──────────┘
│
┌─────────▼──────────┐
│ Agent Runtime │
│ LangGraph/CrewAI │
│ MCP tools │
└─────────┬──────────┘
│
┌─────────▼──────────┐
│ Policy + Validation│
│ Approval + Audit │
└────────────────────┘
RDF是W3C设计用于交换和合并图数据的标准模型，但RDF并非每个本体驱动应用的强制要求。可能的实现选择包括OWL/RDF+SPARQL、属性图+Cypher、关系语义层、JSON-LD契约、Pydantic模型、GraphQL模式等。重要要求不是特定数据库，而是保留显式含义、类型化关系、验证、身份、溯源、治理和运行时上下文纪律。
本体质量不能通过计数类来衡量，有用的指标包括：
- 覆盖率：能回答多少能力问题？
- 关系精度：提取的关系有多少语义正确？
- 约束一致性：多少图实体通过SHACL验证？
- 实体解析准确率：别名映射到规范实体的频率？
- 检索精度：组装的上下文有多少实际相关？
- 上下文压缩：图中1000万事实 → 运行时上下文35条事实
- 推理准确率：推断事实与专家结论匹配吗？
- 行动有效性：Agent选择了允许且适当的行动吗？
- 可解释性完整性：每个推荐都能追溯到证据、规则和溯源吗？
- 本体稳定性：变更多频繁地破坏下游消费者？
8.何时不需要本体？
本体的价值随语义误解成本的增加而增加。可能不需要本体的情况：
应用总结孤立文档
领域小且无歧义
无需跨系统实体解析
无自动操作
错误后果低
简单模式提供足够结构。
强烈建议使用本体的情况：
多系统使用不一致术语
Agent必须执行多步操作
政策和权限重要
需要多跳推理
决策必须可解释
数据血统重要
不同Agent必须协调
相同企业概念出现在多个用例中
必须执行监管或运营约束。
本体和LLM解决不同问题——
最大的误解是："一旦我们构建了完整的知识图谱，AI Agent就会变聪明。"完整的图如果在Agent收到过多无关信息时，反而可能让检索和推理更困难。
真正的流水线可能是：
Ontology
↓
Governed knowledge graph
↓
Decision-scoped retrieval
↓
Small runtime context graph
↓
Agent reasoning
↓
Validated action
9 小结
企业级AI应用不仅因为模型不够智能而失败，而经常的失败是因为组织含义仍然碎片化、隐含且不一致。一个系统说client，另一个说customer，第三个说party，政策引用account holder，Agent检索到全部四个然后猜测。
本体用显式语义替代这种猜测。它使组织能够定义：哪些实体存在、关系意味着什么、哪些数据有效、可以推断什么、哪些证据支持结论、哪个工具可以执行操作、哪个政策治理该操作、哪个人类必须审批。
可靠Agent的未来不会仅由LLM构建。它将由一个语义基础构建：本体 + 知识图谱 + 向量检索 + 上下文组装 + 上下文图 + 溯源 + 策略执行 + 人类监督。
最终目标不是一个包含一切的图。而是一个能够交付正确含义、正确事实和正确证据给正确的Agent在正确时刻——以便它能采取正确行动的系统。
让知识图谱成为大模型的伴侣
面向知识图谱的大模型应用
解读知识图谱的自动构建
从语义网到知识图谱
知识图谱与向量数据库的相遇
在大模型RAG系统中应用知识图谱
知识图谱的5G追溯
行业规模的知识图谱——经验和挑战
IOT语义互操作性之本体论
IOT语义互操作性之语义
IOT语义互操作性之标准与开源
IOT语义互操作性之API接口
IOT语义交互性之交叉
老码农眼中的Agent Skill
粤ICP备14082021号
免费POC，
零成本试错
