上一期我们讲了业务本体不是又一个知识图谱——它是 KG + Action + Rule + Security 四位一体。
这一期讲方法论——具体怎么建。
核心矛盾：很多企业拿 Palantir 文档照抄，做出来的本体还是"调不动"。因为他们只搬了 4 要素，没看到 4 原则和 3 步治理。
这一期我们把 4 要素+ DDD 4 原则+ 治理 3 步全部讲透，彻底了解怎么建一个"Agent 能用"的本体。
02四要素，少一个都不是 Palantir 式本体
上一期我们讲到Palantir 官方本体有 4 要素，这里展开说：
| 要素 | 是什么 | 例子 |
|---|
| Object Type | 现实实体的 schema | Customer、WorkOrder、Vessel |
| Property | 对象的特征 | order_amount、device_temperature |
| Link Type | 对象间关系 | Customer —places→ Order |
| Action Type | 可执行业务动作（带前置条件/副作用/回写） | ApprovePO、TriggerMaintenance |
但只有这 4 个不够——这是 Palantir 文档里前 4 要素。还少 3 样动力层：
| 要素 | 是什么 | 例子 |
|---|
| Function | App/Agent 可调的业务逻辑（规则、ML、LLM） | calculateTax(order)、summarizeContract(text) |
| Interface | 共享特征抽象（多态性） | Approvable 接口被 PO、ExpenseReport 都实现 |
| Security | 本体级行/列权限 + 治理 | 谁能看哪些数据、谁能改哪些字段 |
7 要素齐全 = 真正的 Palantir 式本体。少任何 1 样，Agent 都会出各种问题。
为什么 Function / Interface / Security 重要？
Function 让 Action 可调用业务逻辑——比如"调 LLM 评估订单风险"。
Interface 让多个 Object 共享行为——"Approvable" 接口被 PO 和 ExpenseReport 都实现，减少 30% 重复代码。
Security 是治理基础——Agent 不能改"别人的数据"。
关键洞察：动力层（Action/Function/Interface/Security）是 Palantir 本体和普通 KG 的真正分野——也是为什么普通 KG 项目"调不动"Agent 的根因。
Palantir 在官方文档里给了 4 个建模原则，优先级有先后：
原则 1：建模现实，不是建模源系统
很多人做本体的第一反应：把 ERP 的几张表抄过来——Customer 抄 CRM、Order 抄 ERP、Product 抄 PLM。
这是错的。
CRM 的 Customer 表里可能有 30 个字段，但其中 5 个是历史遗留，3 个是垃圾字段，10 个是给报表用的冗余字段。
真正建模的是"业务里的 Customer 是什么"——不是数据库表里有什么字段。
类比：建模"客户"不是抄 CRM 表，是回答"在你的业务里，谁是客户"——买你产品的人？付你钱的人？用你服务的人？影响决策的人？4 个问题，每个答案不同。CRM 表只有一个答案。
原则 2：DRY（Don't Repeat Yourself）——同一概念出现 3 次就重构
反例：你建了 PO、Invoice、ExpenseReport 三个对象。3 个对象都有 approver、approved_at、amount 字段。
这是反模式——3 次重复。
正确做法：建一个 Approvable Interface，定义 3 个字段。PO、Invoice、ExpenseReport 都实现这个 Interface。
字段在 Interface 里定义一次，实现 Interface 的对象都自动有这 3 个字段。
原则 3：对扩展开放，对修改封闭（Open-Closed Principle）
反例：你的本体已经上线了 6 个月，跑了 100 个 Action。现在业务方说"我们要加一个新场景"。
如果改 Order 对象（加字段、改 Action）——会破坏现有 100 个 Action 的契约。
正确做法：用 Interface 和 Function 扩展，不改 Object 本身。
新建 OrderExtension 对象（实现 OrderExtensionInterface），通过 Function 注册到本体。原 100 个 Action 不动。
原则 4：组合优于深继承
反例：IndustrialPump → CentrifugalPump → ChemicalCentrifugalPump → AcidicChemicalCentrifugalPump 4 层继承。
这是反模式——任何一层变了，下面所有子类都跟着变。
正确做法：用 Interface 多继承。一个泵可以同时实现 PumpInterface、MaintainableInterface、CorrosiveResistantInterface 3 个接口。组合 = 多个能力可以灵活叠加。
4 原则的优先级：原则 1（建模现实）> 原则 2（DRY）> 原则 3（开闭）> 原则 4（组合）——后 3 个是 OO 通用原则，原则 1 是本体工程独有。
Palantir 内部把"建本体"分成 3 步，90% 的失败源于顺序反了。
Step 1：理解领域（和业务专家坐一起）
这一步不在数据库里——在业务场景里。
找业务专家（车间主任、客户经理、风控经理）。问他们：
你们的"客户"是谁？买我们产品的人？还是付钱的人？
你们的"订单"是什么？客户下的单？还是生产计划？
一笔订单从下单到完成，要经过多少个部门、什么岗位？
这一步要 1-2 个月——但很多企业"跳过这步直接建模"，所以做出来的本体"业务专家看不懂"。
Ubiquitous Language（统一语言）——业务专家和工程师用同样的词描述同一件事——是这步的产物。
Step 2：设计本体（白板 + 建模工具）
用 Protégé、Ontology Designer、或白板，把 Step 1 的"业务语言"翻译成 Object + Link + Action。
这一阶段不要碰数据源——只看业务本身。
这一步要 2-4 周。
Step 3：映射源数据（最后才到技术）
把 ERP/CRM/IoT 表/API/流数据清洗 + 映射到本体 Object。
这步最重技术——但很多企业"倒过来"——先接表再看业务，结果做出来的是"数据镜像"不是"业务本体"。
反了就是 Kitchen Sink——把所有 ERP 字段塞进一个大 Object。这是反模式。
3 步总时间：Step 1（1-2 月）+ Step 2（2-4 周）+ Step 3（4-8 周）= 3-5 月。
正确顺序不能反。
把这期落地方法总结成 4 句话：
四要素齐（Object/Property/Link/Action + Function/Interface/Security），少一个调不动。
四原则排（建模现实 > DRY > 开闭 > 组合），优先级反了必烂。
三步走（理解领域 → 设计本体 → 映射数据），顺序反了变镜像。
业务专家全程参与建模评审——本体工程本质是组织工程，不是工具项目。
4 个验证问题：
业务专家能看懂吗？ — 让 1 个完全没参与建模的业务专家 1 小时读完 Schema → 能不能讲出 80%？
Agent 能用吗？ — 写 1 个"根据自然语言问题查询"的测试 → 1 周内能不能跑通 1 闭环？
Action 稳定吗？ — 跑 100 次同 Action 1 个月 → 失败率 < 1%？
Rule 准确吗？ — 业务规则变了 3 次后 → Rule 自动跟上了吗？
4 题全"Yes"= 本体 OK。
4 要素是骨架，4 原则是肌肉，3 步治理是神经——三者缺一，Agent 跑不动。
粤ICP备14082021号
免费POC，
零成本试错
