04 核心概念详解：对象、属性、关系、动作、规则、权限
前三篇讲了本体是什么、为什么要。这一篇是整个系列的"概念字典"：逐个解释本体的六个核心要素（外加动能层里负责计算的"函数"），并用示例商城的售后业务说明每个要素该怎么理解、怎么写、容易在哪里出错。后面的方法篇（第 06、07 篇）和实战篇（第 10 篇）都以这里的定义为准。
1. 全景：名词的一半与动词的一半
本系列把本体分成两半：
- 名词层（Palantir 称为语义元素）：描述"世界里有什么、长什么样、怎么连在一起"，包括对象、属性、关系；
- 动能层（动词）：描述"世界能怎样被改变、在什么条件下、由谁改变"，包括动作、函数、规则、权限。
注意：这里的"名词层"不是数据分析领域常说的"指标语义层"（dbt、Cube 这类管理指标口径的产品，见第 05 篇）。
"动能层"这个说法来自 Palantir 文档里的 kinetic 一词，意思是让本体"动起来"的那部分。Palantir 文档里的动能元素是动作、函数和动态安全；本系列把"规则"单列出来，是为了强调它可复用、有版本。只有名词的本体，Agent 只能解释业务；加上动词，Agent 才可能在规矩之内办事。
| 要素 | 一句话解释 | 示例商城中的例子 |
|---|---|---|
| 对象类型 | 一类业务事物的定义；它的每个具体个体叫对象 | "售后单"是对象类型，AS-2001 是一个对象 |
| 属性 | 对象的特征，有类型、单位和取值范围 | 售后单.申请金额（元，两位小数） |
| 关系 | 两类对象之间有名字、有方向、有数量约束的联系 | 售后单 针对 订单行（每个售后单恰好一个） |
| 动作 | 一次完整的、受控的业务变更 | 发起退款：校验、建退款单、改状态、通知、留痕 |
| 规则 | 必须成立的条件或判断逻辑 | 退款金额不超过 实付金额 减去 已退金额 |
| 函数 | 只计算、不改业务状态的逻辑 | 可退金额 = 实付 − 已退 − 在途（退款中） |
| 权限 | 谁可以看哪些对象和字段、可以执行哪些动作 | 客服可发起退款，超阈值须主管审批 |
2. 对象类型与对象
对象类型是"一类东西"的定义，例如"订单"；对象是其中具体的一个，例如订单 O-1001。这和编程里"类"与"实例"、数据库里"表定义"与"一行数据"的关系类似，但有一个关键区别：对象类型对应的是业务上承认存在的东西，而不是某张表。
2.1 表是来源，不是对象
一位做建模的实践者总结过一句很实用的话："表是来源，不是领域对象。"数据库里的一行，可能是下面任何一种：
- 稳定对象：客户、商品，有长期身份；
- 角色视图：同一个人在订单里是"买家"，在物流里是"收件人"；
- 关系体：订单行连接了订单和商品，还带着自己的数量和单价（见第 4 节）；
- 阶段取值：售后单的"待审核""已退款"只是状态，不是另一类东西；
- 快照：每日库存表记录的是某一天的值。
所以建模时不要"一表一对象"。示例商城的售后系统里可能有一张 refund_apply 大宽表，混着售后单信息、退款信息和审批信息；在本体里，它应该被拆成"售后单""退款单""审批记录"三个对象类型，各有各的身份和生命周期。
2.2 身份：对象必须"认得出来"
每个对象类型都要有主键（唯一标识一个对象的字段）。跨系统时更要明确"以谁为准"：客户可能在会员系统、小程序、客服系统里各有一个编号，本体里的"客户"要么选定一个权威编号，要么建立映射，把多个编号归到同一个客户对象上。身份不清，后面所有关系和规则都会出错。
2.3 角色与阶段：换状态不换身份
两个常见的建模判断：
- 角色不是子类。"VIP 客户"如果建成"客户"的子类，客户降级时就得"变成另一种东西"。更合理的做法是把 VIP 作为客户的一个属性或角色——身份不变，资格变化。
- 阶段不是子类。"已退款售后单"不应该是单独的对象类型，它只是售后单处于某个阶段。状态变化用状态机描述（见第 7 节）。
2.4 接口与共享属性
多个对象类型共有的特征，可以抽成接口（描述一组对象类型共同"形状"的定义）或共享属性。例如"收货地址"同时出现在客户、订单、发货单上，只定义一次，三处共用，避免出现三种地址格式。
3. 属性
属性是对象的特征。一个合格的属性定义，至少包含：
| 项 | 说明 | 例：售后单.申请金额 |
|---|---|---|
| 名称与说明 | 业务名、英文名、一句话含义 | 申请金额 / requested_amount / 客户本次申请退回的钱 |
| 数据类型与单位 | 数字、文本、日期、枚举等；金额要写单位和精度 | 数值，元，两位小数 |
| 取值范围 | 枚举值、上下限、格式 | 大于 0 |
| 是否必填 | 缺失时如何处理 | 必填 |
| 来源 | 来自哪个系统哪个字段，或由函数计算 | 售后系统 refund_apply.amount |
有两类属性值得单独说明：
- 派生属性：不直接存储，由其他属性计算得出。例如"可退金额 = 订单行实付金额 − 该订单行已退金额"。它应由一个函数（只计算、不改数据的逻辑）统一计算，而不是在每个页面各算一遍。注意：在 Palantir 里，函数也可以计算出一组修改（"编辑函数"），但只有被包装成动作执行时才会生效。所以更准确的区分是：是否改变业务状态，由动作决定。
- 时间与来源属性：记录这个值"什么时候生效""来自哪里""谁确认的"。售后争议里，"签收时间以哪个系统为准"往往就是争议的核心。
4. 关系
关系是两类对象之间的业务联系。它和数据库里的外键或表连接看起来相似，本质却不同：外键是技术实现，关系是业务承诺。一个完整的关系定义包括：名称（用动词，如"包含""针对"）、两端的对象类型、方向、基数（数量约束，如一对一、一对多）。
| 关系 | 起点 → 终点 | 基数 | 说明 |
|---|---|---|---|
| 下单 | 客户 → 订单 | 一对多 | 一个订单只属于一个客户 |
| 包含 | 订单 → 订单行 | 一对多，至少一行 | 没有订单行的订单无意义 |
| 对应 | 订单行 → 商品 | 多对一 | 每行恰好一个 SKU |
| 针对 | 售后单 → 订单行 | 多对一 | 一个订单行可以有多次售后 |
| 装运 | 发货单 → 订单行 | 多对多（带数量） | 一个包裹可装多行，一行也可能拆到多个包裹；判断无理由退货期，要沿这条关系找到该订单行所在正向包裹的签收时间 |
| 退货寄回 | 售后单 → 发货单（退货包裹） | 多对零或一 | 一个退货包裹可能装着多个售后单的商品 |
| 产生 | 售后单 → 退款单 | 一对多 | 允许分次退款 |
| 关联 | 工单 → 售后单 | 多对多 | 一次投诉可能涉及多个售后单 |
4.1 什么时候把关系升级为对象
当一段关系自己有属性、有历史、有责任人时，它就应该成为一个独立的对象，这类对象常被称为关系体。"订单行"就是典型：它连接订单和商品，又有自己的数量、单价、优惠分摊。
售后单承载的是一次诉求的处理过程，更准确地说是一个过程对象，但它同样起着关系体的作用：把订单行、退款单和退货包裹连在一起。如果偷懒，直接在客户和商品之间连一条"退过货"的关系，那么"同一件商品退了两次""第一次被驳回、第二次通过"这些事实就无处记录，"这位客户退过几次货"也没法准确回答。有建模者的经验是：历史和责任，应该挂在关系体上。
5. 动作
动作是一次完整的、受控的业务变更。它和"调用一个接口""改一个字段"的区别在于：动作围绕业务目标，而不是围绕数据字段。Palantir 把一次动作定义为一个事务（transaction，一组修改要么全部生效、要么全部不生效），它包含参数、规则、提交条件和副作用，产生的修改会写回数据。要注意，这里的事务只覆盖本体内对象的修改；调用外部系统（比如支付渠道）不在这个事务里。Palantir 的做法是区分两类外部调用：必须先成功的"写回"（失败则整个动作不生效），和本体修改之后才执行、尽力而为的"副作用"。
一位作者把业务动作归纳为六个要素，本系列沿用这个拆法：
| 要素 | 含义 | 发起退款 |
|---|---|---|
| 动作 | 名称和业务意图 | 为一个售后单发起退款 |
| 对象 | 作用于哪些对象、需要哪些参数 | 售后单、退款金额、退款原因 |
| 前置条件 | 执行前必须满足的规则 | 售后单状态为"待退款"；金额不超过可退金额 |
| 执行者 | 谁可以发起、谁需要批准 | 客服发起；超过示例阈值 500 元时，这次动作先进入"待审批"，由客服主管批准后才执行 |
| 结果 | 对哪些对象产生什么修改 | 新建退款单；售后单进入"退款中" |
| 副作用 | 系统外的连带影响 | 调用支付渠道退款（写回步骤：必须成功，需幂等）；短信通知客户（尽力而为，失败可补发）；审计日志由动作引擎同步记录 |
# 动作定义卡（示意，非任何平台的真实语法）
action: initiate_refund # 发起退款
target: AfterSalesCase # 售后单
params:
amount: { type: decimal, unit: CNY, min: 0.01 }
reason: { type: enum, values: [质量问题, 无理由, 少件, 其他] }
preconditions:
- rule: case_status_is_pending_refund
- rule: amount_within_refundable # 退款金额不超过可退金额
approval:
- when: amount > 500 # 示例阈值（规则 R04）
require_role: 客服主管 # 动作实例先进入"待审批"，批准后才执行
edits:
- create: Refund
- set: AfterSalesCase.status = 退款中
writeback: payment_gateway.refund # 必须成功的外部调用；超时视为"结果未知"，先查询再决定
side_effects: [notify_customer] # 尽力而为，失败可补发；审计日志由动作引擎同步记录
idempotency_key: request_id # 调用方在"决定退款"时生成一次，所有重试原样复用
关于最后一行多说一句：幂等键标识的是"这一次退款决定"，不是"这一次网络调用"。所以不要把重试次数放进键里（每次重试的键都不同，幂等就失效了），也不要把金额放进键里（同一售后单两笔金额相同的分次退款会被误判为重复）。
两个容易混的概念：
- 动作不等于工具。一个动作可能编排多个工具调用（查订单、算金额、建退款单、调支付、发通知）；同一个工具（比如"创建任务"）在不同动作里承担的业务责任也不同。
- 动作不等于函数。函数负责计算和查询，可以只读；动作负责改变状态。有人打了个比方："动作是工单，函数是工单里的工具。"
6. 规则
规则是"必须成立的条件"或"如何做判断的逻辑"。它在本体里常以四种形式出现：
| 类型 | 作用 | 示例 |
|---|---|---|
| 约束（不变式） | 任何时候都必须成立 | 累计退款金额不超过订单行实付金额 |
| 前置条件 | 某个动作执行前必须满足 | 发起退款时售后单必须处于"待退款" |
| 派生规则 | 由已知事实推出新事实 | 自签收次日起超过 7 天的订单行（以它所在正向包裹的签收时间为准），"无理由退货资格"为否；7 天是《消费者权益保护法》第二十五条规定的法定底线，平台可以放宽、不能收紧 |
| 决策规则 | 按条件给出处理结论 | 按金额与商品类别决定审批级别 |
决策规则常写成决策表。OMG 发布的 DMN 标准（决策模型与表示法）就是专门描述这类业务决策的规范，可与流程建模标准 BPMN 配合使用。一张决策表最好只回答一个问题，并写明命中策略（多行同时满足时怎么办）。下面把"能不能无理由退"和"要不要审批"拆成两张表，都采用"唯一命中"（任何输入只会命中一行）：
表一：无理由退货资格（规则 R02、R03）
| 商品类别 | 自签收次日起的天数 | 无理由退货资格 |
|---|---|---|
| 非生鲜 | 不超过 7 天 | 有 |
| 非生鲜 | 超过 7 天 | 无（质量问题仍可申请售后） |
| 生鲜 | 任意 | 无（质量问题走补偿流程） |
表二：审批级别（规则 R04）
| 单笔退款金额 | 审批要求 |
|---|---|
| 不超过 500 元 | 客服直接处理 |
| 超过 500 元 | 客服主管审批 |
规则建模的两条经验：一是规则应独立定义、可被复用，有实践者的标准是"被两个以上动作引用时值得独立出来"；二是规则要有版本，每次执行都记下用的是哪一版；三是标出规则的来源：法规、平台政策、商家承诺的优先级不同，比如 7 天无理由退货是法规底线，平台规则只能在它之上放宽。
还有一个技术细节值得新手了解：OWL 一类的本体语言默认采用开放世界假设——没写的信息只是"未知"，不等于"不存在"；而数据库和校验工具通常采用封闭世界假设——没有就是没有。比如客户档案里没有记录过敏信息，在开放世界里是"不知道"，在封闭世界里是"无过敏"。因此只有 OWL 定义而不配 SHACL 这类校验，线上数据的缺失和错误很难被拦住。
7. 状态机：把动作和状态连起来
动作改变对象的状态，状态又决定哪些动作可以执行。用状态机（列出所有状态和允许的转换）把它画出来，是检查动作设计是否完整的好办法：
注意区分两层状态：一层是业务对象的状态（售后单处于"待退款"）；另一层是动作执行实例的状态（这一次"发起退款"处于待审批、执行中、已完成、结果未知还是需人工处理）。比如支付渠道超时：售后单保持"退款中"，动作实例进入"结果未知"——超时只说明不知道结果，不等于失败，要先查询渠道再决定下一步。把两层混在一起，是动作设计里最常见的错误之一（第 07 篇会再谈）。
8. 权限
权限决定谁能看到哪些对象和字段、能执行哪些动作。本体里的权限通常有三个粒度：对象级（能看哪些售后单）、字段级（能否看到客户手机号）、动作级（能否发起退款）。对 Agent 来说，还要区分四种权利：
| 权利 | 含义 | 示例商城的初始设置 |
|---|---|---|
| 查看 | 能读取对象和关系 | AI 客服可查看本人会话涉及的订单和售后单 |
| 建议 | 能给出处理方案，但不提交 | AI 客服可建议退款金额和理由 |
| 申请 | 能提交动作，等待他人批准 | 客服可申请超阈值退款，由主管批准；AI 客服经客户确认后可申请创建售后单 |
| 执行 | 能直接让动作生效 | 主管可批准；小额自动退款需单独开放 |
两条原则：Agent 的权限不能超过它所代表的人；本体层的权限应尽量复用业务系统已有的权限，而不是另造一套——两套规则一旦不一致，排查和审计都会变得非常困难（第 09 篇详述）。
9. 不同出处的叫法对照
| 本系列 | Palantir | Microsoft Fabric IQ | OWL / 语义网 |
|---|---|---|---|
| 对象类型 / 对象 | Object type / Object | 实体类型 / 实体实例 | 类 / 个体 |
| 属性 | Property | 属性 | 数据属性 |
| 关系 | Link type | 关系 | 对象属性 |
| 动作 | Action type | 无直接对应（可由 Agent 等能力承接） | 无直接对应 |
| 函数 | Function | 无直接对应；派生值可用计算列近似。聚合类的计算对应它的"指标"，沿用 Power BI 语义模型里的 DAX 度量（DAX 是 Power BI 的公式语言） | 无直接对应 |
| 规则 | 动作规则与提交条件 | 规则（自然语言描述） | 公理；配合 SHACL 校验 |
| 权限 | 动态安全、标记 | 遵循 Fabric 工作区与项目权限，以及 OneLake 安全和源端的行级、对象级、列级安全（RLS / OLS / CLS） | 不在标准范围内 |
注：Fabric IQ 本体截至 2026 年 10 月仍为预览版，已支持继承、命名空间、命名版本和 RDF / Turtle / OWL 的导入导出，功能变化较快，请以官方文档为准。
10. 把六要素串起来：售后单的完整定义
前面分别讲了六个要素。下面把它们放到一个对象类型上，看一份完整的定义长什么样。这也是第 06、07 篇建模时每个核心对象最终要产出的东西：
| 部分 | 内容 |
|---|---|
| 名称与含义 | 售后单（AfterSalesCase）：客户针对某个订单行提出的一次退货、退款诉求及其处理过程 |
| 身份 | 主键为售后系统的申请编号；权威来源为售后系统 |
| 构型 | 过程对象（同时起关系体的作用）：承载一次诉求的处理过程，连接订单行、退款单和退货包裹，自身有状态和历史 |
| 主要属性 | 类型（仅退款 / 退货退款）、申请数量（不超过购买数量减去已退数量）、申请金额（元，两位小数）、原因（枚举）、状态（见状态机）、创建时间、处理人 |
| 派生属性 | 是否超出无理由退货期（由该订单行所在正向包裹的签收时间和规则 R02 计算） |
| 关系 | 针对 订单行（多对一，必填）；产生 退款单（一对多）；退货寄回 退货包裹（可选，一个退货包裹可能装着多个售后单的商品）；关联 客服工单（多对多） |
| 状态机 | 待审核 → 待退货 / 待退款 → …… → 已退款 / 已关闭（见第 7 节） |
| 相关动作 | 创建售后单、审核售后单、确认退货验收、发起退款、关闭售后单；超阈值的发起退款需经"审批"（作用于待审批的动作实例） |
| 相关规则 | R01 累计退款上限（含累计退货数量不超过购买数量）；R02 无理由退货期；R03 生鲜除外；R04 审批阈值；R05 不得重复申请 |
| 权限 | 客户本人可查看自己的售后单；客服可查看和处理；AI 客服只能查看本会话涉及的售后单 |
| 负责人 | 业务定义：客服运营；数据映射：数据平台 |
这张卡片同时服务三类读者：业务人员看"含义、状态、规则"；工程师看"身份、来源、关系"；AI Agent 通过工具读取的，也正是这些内容。
11. 常见问题
问：规则到底属于名词层还是动能层？
两边都有。描述"什么必须成立"的约束（如累计退款上限）更接近名词层，它在任何时候都应成立；描述"做某件事前要满足什么"的前置条件更接近动能层。本系列把规则统一放在动能层介绍，是因为在企业实践中，规则最常在动作执行时被检查。
问：函数和动作怎么区分？
一个简单的判断：执行完以后，业务数据有没有变化。"计算可退金额"不改任何数据，是函数；"发起退款"会新建退款单、改变售后单状态，是动作。函数可以被动作调用，反过来不行（Palantir 的编辑函数能算出一组修改，但同样要包装成动作执行才会生效）。
问：每个属性都要写那么详细吗？
核心对象的关键属性要写全，尤其是金额、状态、时间这类容易引发争议的属性。次要属性可以先只写名称和来源，等它被某个能力问题用到时再补全。
问：权限写在本体里，和业务系统的权限会不会冲突？
所以建议本体尽量"引用"而不是"复制"业务系统的权限：业务系统决定某个客服能看哪些订单，本体只额外规定 Agent 在动作上的权利（查看、建议、申请、执行）。两者的边界在第 09 篇有更细的讨论。
问：对象类型越细越好吗？
不是。对象类型拆得越细，关系越多、维护越难。判断标准是：拆开后的两类对象，是否有不同的属性、不同的动作或不同的规则。如果没有，就用一个属性来区分，而不是拆成两类。
本篇要点
- 本体分名词层（对象、属性、关系）和动能层（动作、函数、规则、权限）；只有名词只能解释业务，加上动词才能办事。
- 表是来源，不是对象；建模要分清稳定对象、角色、关系体、阶段和快照，并确定对象身份。
- 关系是有名字、有方向、有基数的业务承诺；自带属性和历史的关系应升级为关系体。
- 动作是一次完整的受控业务变更，按"动作、对象、前置条件、执行者、结果、副作用"六要素定义；动作不等于工具，也不等于函数。本体内的修改原子生效，外部调用要区分"必须成功的写回"和"尽力而为的副作用"；幂等键标识的是一次业务决定，而不是一次调用。
- 每个核心对象最终都应有一张完整定义卡，覆盖含义、身份、构型、属性、关系、状态机、动作、规则、权限和负责人。
- 规则分约束、前置条件、派生、决策四类，应独立、可复用、有版本；权限分查看、建议、申请、执行四种权利。
参考引用
- 《Ontology building: Overview》，Palantir Foundry 官方文档。原文
- 《Action types: Overview》，Palantir Foundry 官方文档。原文
- 《Functions: Ontology edits》，Palantir Foundry 官方文档（经本项目调研报告收录）。原文
- 《What is ontology (preview)? — Microsoft Fabric IQ》，Microsoft Learn。原文
- 《OWL 2 Web Ontology Language Document Overview (Second Edition)》，W3C Recommendation，2012-12-11。原文
- 《Shapes Constraint Language (SHACL)》，W3C Recommendation，2017-07-20。原文
- 《Decision Model and Notation (DMN) 1.6》，Object Management Group (OMG)。原文
- 《Ontology Development 101: A Guide to Creating Your First Ontology》，Natalya F. Noy、Deborah L. McGuinness，Stanford University。原文
- 《本体建模过程案例：FDE如何根据业务口述建立静态本体？》，基线沉思。Cubox，原文
- 《我用微软开源工具Ontology Playground可视化了本体推理，顺便在建模层对照了一遍》，基线沉思。Cubox，原文
- 《Action Ontology：让企业 Agent 从“会调用”到“能负责”》，皓月惊鸿 Chatshouse。Cubox，原文
- 《Ontology本体论实践教程:很多人会问,用CRUD拆开写不也一样吗？》，月夜烛峰。Cubox，原文
- 《从本体论到本体建模，从本体建模到 AI 原生—我这一年关于本体的系统性复盘》，何明璐 人月聊IT。Cubox，原文
- 《一文读懂本体四大核心技术：RDF、OWL、SPARQL、SHACL，看懂语义层完整工作流》，女王的专属领地 AI产品观察局。Cubox，原文
- 《深入浅出学习本体论（Ontology）：从哲学根基到实践应用概要》，Tom 汤姆的技术雷达。Cubox，原文
- 《WorkBuddy+金蝶云星空落地一席谈：权限怎么管》，老丁 老丁AI。Cubox，原文
- 《什么是Palantir本体论？不难理解，在12306买一次车票就懂了》，月夜烛峰。Cubox，原文
- 《Action types: Webhooks》，Palantir Foundry 官方文档。原文
- 《中华人民共和国消费者权益保护法》第二十五条，国家市场监督管理总局发布文本。原文
- 《网络购买商品七日无理由退货暂行办法》第十条，中国政府网。原文