“可信 Data + 智能体 AI”真正难的地方，不是让模型生成一段看似合理的回答，而是让智能体知道数据中的对象、关系、来源和约束，并在行动前检查这些信息是否足够可靠。本体工作坊的价值，就在于把业务知识整理成机器可理解、可验证、可追溯的结构。
本文不假设某个特定平台或本体标准，重点讨论一种可以逐步落地的实践方式：先定义业务对象和关系，再为数据补充来源与置信信息，最后把这些结构接入智能体的检索、判断和执行流程。
本体不是词汇表，而是可执行的业务约束
一个普通字段名只能告诉我们“这里有一个值”，本体则进一步说明：这个值代表什么对象，它和哪些对象有关，允许出现什么状态，以及哪些关系必须有证据支撑。
例如，在设备运维场景中，可以先定义这些核心概念：
Asset：设备或资产Sensor：传感器Observation：观测结果Alert：告警WorkOrder：工单Technician：维修人员
再定义对象之间的关系：
- 传感器
observes设备 - 观测结果
generatedBy传感器 - 告警
derivedFrom观测结果 - 工单
resolves告警 - 维修人员
assignedTo工单
这组定义直接影响智能体的行为边界。智能体不能因为看到“温度过高”就随意创建工单，它至少需要确认：观测来自哪个传感器、采集时间是什么、传感器是否属于目标设备、告警规则是否适用，以及是否已经存在未关闭工单。
可以把一条可信事实抽象成下面的结构：
主语 --关系--> 宾语
\ /
\-- 来源、时间、置信度、权限 --/
来源信息不是附加装饰，而是智能体判断“能不能用这条事实”的依据。没有来源的事实可以用于探索性回答，但不应该直接触发高风险动作。
为智能体准备可验证的事实
实际系统中，数据通常来自多个系统：资产管理系统提供设备信息，时序数据库提供传感器读数，工单系统提供处理状态，人工记录可能补充现场判断。将这些数据交给模型之前，需要保留最小的可信元数据：
source：事实来自哪个系统或文档observed_at：事实发生或被观测的时间confidence：来源或规则给出的置信度evidence：支持该事实的记录、查询或文档标识valid_until：事实的有效期，避免陈旧数据持续影响决策
下面是一个可直接运行的 Python 示例。它用标准库模拟一个小型知识图谱，并在智能体执行动作前检查事实来源、时效和置信度。示例中的阈值只是实践假设，接入真实业务时应由领域负责人和风险策略共同确定。
from datetime import datetime, timedelta, timezone
FACTS = [
{
"subject": "sensor:S-100",
"predicate": "observes",
"object": "asset:P-01",
"source": "asset-registry",
"confidence": 0.99,
"observed_at": "2025-06-01T08:00:00+00:00",
},
{
"subject": "sensor:S-100",
"predicate": "temperature_celsius",
"object": 93.5,
"source": "timeseries-db",
"confidence": 0.96,
"observed_at": "2025-06-01T08:10:00+00:00",
},
]
def parse_time(value: str) -> datetime:
return datetime.fromisoformat(value.replace("Z", "+00:00"))
def find_fact(subject: str, predicate: str):
return next(
(
fact for fact in FACTS
if fact["subject"] == subject and fact["predicate"] == predicate
),
None,
)
def can_create_work_order(asset_id: str, now: datetime) -> tuple[bool, str]:
relation = next(
(
fact for fact in FACTS
if fact["predicate"] == "observes"
and fact["object"] == asset_id
),
None,
)
if relation is None:
return False, "找不到传感器与设备之间的可信关系"
reading = find_fact(relation["subject"], "temperature_celsius")
if reading is None:
return False, "找不到温度观测结果"
if reading["confidence"] < 0.90:
return False, "观测置信度低于动作阈值"
if now - parse_time(reading["observed_at"]) > timedelta(minutes=30):
return False, "观测结果已过期"
if reading["object"] < 90:
return False, "尚未达到创建工单的温度阈值"
return True, f"允许为 {asset_id} 创建工单，证据来自 {reading['source']}"
if __name__ == "__main__":
decision, reason = can_create_work_order(
"asset:P-01",
datetime.fromisoformat("2025-06-01T08:20:00+00:00"),
)
print({"allow": decision, "reason": reason})
运行方式：
python trusted_agent_check.py
这个例子没有让模型直接“猜”出结论，而是把模型适合做的工作和规则引擎适合做的工作分开：模型可以负责解析用户意图、选择查询路径、生成解释；本体关系、来源校验、时间有效性和动作阈值则应由确定性逻辑或受控工具检查。
工作坊如何从概念走到最小闭环
一次有效的本体工作坊不应从“要不要采用某个复杂标准”开始，而应从一个具体决策场景开始。可以按下面的顺序推进：
选择一个高价值动作
例如“是否为异常设备创建维修工单”“是否批准一笔退款”或“是否向客户发送风险通知”。动作越具体，越容易识别所需事实、责任人和审批边界。
画出事实链
列出智能体完成动作必须知道的对象和关系，并标注每条关系的来源。例如，设备归属可以来自资产系统，当前读数来自时序数据库，工单状态来自工单系统。不要把不同来源拼成一个没有出处的扁平文本。
定义事实的质量门槛
对每类事实明确最低要求：哪些来源可以作为权威来源，允许多长时间的延迟，置信度低于多少必须转人工，哪些字段缺失时动作必须停止。质量门槛应当与动作风险匹配，而不是对所有数据一刀切。
设计智能体的工具契约
工具输入输出应该携带结构化证据。例如，查询工具返回事实列表和来源，动作工具要求调用方提交使用过的事实标识。这样可以在日志中回答“智能体为什么做了这个动作”，也便于回放和审计。
一个简化的工具响应可以长这样：
{
"facts": [
{
"subject": "asset:P-01",
"predicate": "has_temperature",
"object": 93.5,
"source": "timeseries-db",
"observed_at": "2025-06-01T08:10:00Z",
"evidence_id": "reading-8842"
}
],
"quality": {
"fresh": true,
"confidence": 0.96
}
}
落地时要特别关注的边界
可信数据不等于数据绝对正确。来源系统本身可能有延迟、映射错误或权限问题，因此需要保留修正机制、版本信息和人工复核入口。
本体也不应该一开始就覆盖整个企业。范围过大容易让概念争论取代交付。更稳妥的方式是围绕一个动作建立最小本体，验证查询、解释和审计链路后，再扩展到相邻流程。
此外，置信度不能替代权限控制。一个来源可靠但包含敏感信息的事实，仍然不能被无权限的智能体读取或写入。数据可信、身份可信、工具权限和动作审批是四个不同维度，需要分别建模。
一份可执行的检查清单
- 是否明确了一个可衡量的智能体动作？
- 每个关键对象是否有唯一标识？
- 关键关系是否记录了来源和时间？
- 陈旧、冲突或低置信事实如何处理？
- 高风险动作是否经过确定性规则或人工审批？
- 工具返回结果是否包含可追溯的证据标识？
- 是否可以复现一次智能体决策使用过的全部事实？
- 本体变更是否有版本管理和回归测试？
本体工作坊的产出不应只是概念图，而应是一套能支撑查询、验证、解释和执行的最小知识契约。把可信数据放在智能体行动链的前面，模型才有机会从“会回答”走向“能在边界内可靠地做事”。