知识图谱建好了，然后呢？
2024 年到 2026 年，每个做 AI 的团队都在建知识图谱。从源代码里提取实体和关系，写进 Neo4j，配上向量索引，接上 LLM。一条查询能告诉你"这个函数被谁调用了"、“这个类和哪个设计模式对应”。
然后呢？
你让 Agent 去重构一个函数，Agent 说"好"。它调了refactor(credit_card_validator)，代码重写了，测试跑了，提交了。看起来很完美。
但你后来发现——credit_card_validator处理的是用户的信用卡号。它的上游有一个 DataAsset，sensitivity=high，关联了 3 个合规要求。这些信息全在你的知识图谱里。Agent 也查得到。问题是——Agent 没有"必须查"的机制。
知识图谱存了答案，但没有执行约束力。
这就是 99% 的知识图谱的现状：它们是"能查的数据库"，不是"能执法的系统"。你把所有规则写在图里，Agent 绕过它们只需要一个理由——没人让它去查。
传统方案：权限表和知识图谱各管各的
大多数 AI Agent 系统的安全方案长这样：
Agent操作 → RBAC检查 → 有权？→ 执行 ↓ 无权？→ 拒绝RBAC 回答的是"谁"能做"什么"。Agent A 可以读、Agent B 可以读写。这种检查在一件事上完全盲区：“这个操作的对象，在业务上能不能被碰？”
refactor这个操作本身不危险。危险的是refactor的目标是credit_card_validator——一个处理敏感数据的函数。但 RBAC 不关心目标——它只关心操作类型和角色。
于是你只能这么补救：
- 写一条规则：“重构操作需要审批”
- 所有重构都要审批——包括重构一个纯工具函数
- 审批变成橡皮图章——因为 90% 的审批都是安全的
- 有一天，一个真正危险的操作混在 10 个安全操作里被批准了
规则越粗，越无效。规则越细，越不可维护。
本体驱动的思路：约束不写在规则表里，在本体定义里
这个问题的根因是：约束规则和业务数据分家了。
约束规则在 RBAC 表里，业务数据在知识图谱里。两者互不知道对方存在。加一个 DataAsset 实体 → 要手动加一条权限规则。删一个合规要求 → 权限规则还留在那。
本体驱动的思路很简单：约束规则不从外面加，从本体定义自动推导。
你的本体里已经定义了：
DataAsset（数据资产） ├── name: "信用卡号" ├── sensitivity: high ← 这个字段就是约束来源 └── OWNS → ServiceEntity("risk-service") ServiceEntity("risk-service") └── CONTAINS → CodeEntity("credit_card_validator") Constraint └── VALIDATES → DataAsset ← 这个关系就是推导路径 └── requires_approval: DATA_SENSITIVITY当 Agent 操作credit_card_validator时，系统不是去查权限表，而是沿本体关系链做图遍历：
1. credit_card_validator 是什么？ → CodeEntity 2. 谁 OWNS 它？ → risk-service（跳过，需要继续） 3. risk-service 上游有什么？ → 沿 CONTAINS → OWNS → DataAsset("信用卡号") 4. DataAsset 的 sensitivity 是什么？ → high 5. sensitivity=high 对应的约束是什么？ → BLOCK，需要审批这个遍历链是自动跑出来的，不是人写的。运维不需要为每个新 DataAsset 写一条规则。只要 DataAsset 的 sensitivity 是 high，约束自动生效。
关键差异：遍历 vs 查表
| RBAC | 本体驱动 | |
|---|---|---|
| 规则在哪 | 权限表 | 本体定义 + 关系图 |
| 增新实体 | 手动加规则 | 自动推导 |
| 粒度 | 操作级（refactor=审批） | 对象级（refactor+ 高敏感数据对象=审批） |
| 规则的"为什么" | 不知道为什么（人定的） | 可追溯（来源：DataAsset.sensitivity=high） |
| 删实体后 | 规则残留 | 约束自动消失 |
RBAC 的规则是"写的"，本体驱动的规则是"推导的"。这是两者最本质的区别。
约束不是检查一个点，是沿链路传播
最容易出错的安全设计是点检查：只检查操作目标本身。
refactor(risk_service_api) → 检查 risk_service_api 本身：没有 sensitivity 属性 → ALLOW → 执行但risk_service_api调用credit_card_validator，而credit_card_validator处理信用卡号。如果你的检查只停在目标实体，这个调用链路就是安全盲区。
本体驱动的做法是传播检查——沿关系链往外走：
risk_service_api → CALLS → credit_card_validator → OWNS → DataAsset("信用卡号", sensitivity=high) → 合规项 × 3 传播结果：risk_service_api 虽然本身不敏感， 但它的调用链最终触及 sensitivity=high 的 DataAsset → BLOCK传播按距离衰减——直接关联（1 跳）影响权重 1.0，间接关联（3 跳以上）权重降到 0.2 以下自动停止。保证检查既全面又不会无限蔓延。
三层约束：自动推导不够，还需要人参与
只靠自动推导也有问题——本体定义可能不完美，业务场景可能例外。
所以约束框架分三层：
L1：本体自动推导。从实体属性 + 关系链自动生成约束。覆盖面最广，零维护成本。DataAsset.sensitivity=high → 自动 BLOCK。新增 100 个 DataAsset，自动生效 100 条约束。
L2：YAML 手动覆盖。运维人员在 YAML 里调整——把某个约束从 BLOCK 降到 WARN，把某个实体加入白名单，给某个操作新增一条本体定义之外的约束。不需要懂 Python。
# 降级：数据清洗操作不强制审批-type:patchconstraint:data_sensitivityentity:data_cleanupoverrides:guard_level:WARN# 白名单：这个工具函数走快通道-type:allow_alloperation:refactorentity_ids:["format_phone_number"]L3：运行时动态豁免。审批通过后的操作，带一次性 token 重新执行，自动绕过 guard 检查。Token 用完即焚，不能复用。
三层互不覆盖，叠加生效。本体推导保证"不漏"，YAML 覆盖处理"例外"，运行时豁免处理"审批后放行"。
一个完整的例子
Agent 对用户说：“我帮你重构credit_card_validator，但需要审批——它处理的信用卡号数据被标记为高敏感，涉及 3 个合规要求。”
用户说：“批准。”
Agent 带审批 token 重新执行refactor→ 系统检测到有效 token → 跳过 guard 检查 → 执行重构 → 写回结果 → token 失效。
整个过程：
- Agent 知道为什么需要审批（约束来源：DataAsset.sensitivity=high）
- 用户知道审批的是什么（3 个合规要求，不是黑盒）
- 审批后不会重复审批（token 一次性 + scope 绑定）
- 审计日志记录完整链路（谁、何时、审批了什么、执行了什么）
总结
知识图谱不是"建好就行"。它的价值不在存储，在执行约束力。
当你的 Agent 可以绕过知识图谱里的所有规则直接操作数据，你的知识图谱就是死的。当 Agent 的每一步操作都必须沿本体关系链做图遍历——遍历结果决定放行还是阻断——本体才开始真正"驱动"系统。
这不是权限管理的升级。这是从"知识图谱辅助决策"到"知识图谱驱动决策"的跨越。
本文讨论了本体驱动约束框架的核心思路。下一篇将展开本体论在工业界的三种工程姿态——从学术 OWL 到 Palantir 动态本体，为什么同一件事有三种完全不同的做法。
