概念笔记 · 学习草稿，不是厂商原文

笔记 02：运行时模型、状态、动作与安全

文中若另有限制，以正文和文献页为准。

笔记 02：运行时模型、状态、动作与安全

类型：对官方文档的结构化整理，加上阅读时必须保留的限制。 主要来源：Core concepts，对象/动作/函数/OSDK/安全/时间序列/Automate/冲突页，平台摘要（2026-07-02）。

运行中的最小模型

一个可运行的 Ontology，至少要同时说清四件事：

1. 对象是什么，如何标识。 对象类型定义实体或事件；实例靠主键区分。支撑数据源可以有一个或多个，也可以没有数据源、只由动作创建对象。显示名称不是身份。
2. 关系如何随时间变化。 关系类型有基数和连接键。设备与传感器、设计用料与实际装配、安装事件与当前服务商，都应按时间保留，而不是用一个静态字段覆盖历史。
3. 什么变更是允许的。 动作类型把一次变更定义为事务：参数、规则、提交条件、副作用。函数提供可复用计算，也可以作为动作的实现；但函数还可以调用外部系统或语言模型，因此不默认等于确定性规则。
4. 谁在何种条件下可以看或改。 安全总览区分强制控制（标记、组织等，随血缘传播）和自主控制（角色，以及行列过滤）。OSDK 写明行列控制是读取时强制，不自动约束应用拿到数据之后做什么。

接口用于表达多个对象类型的共同能力，避免为每一种组合新建深层类型。对象视图是面向人的聚合入口，不是另一套数据真相。

状态与时间

时间序列页给出两种常见做法：把时间序列属性直接放在对象上；或为测点建立传感器对象并链到根设备。后者适合配置差异大、否则会出现大量空属性的设备。教学含义很直接：一台机组不是一条温度曲线；测点身份和设备身份要分开。

平台摘要还提到物化（materialization）：把数据源与用户编辑合成后的最新对象状态写成数据集，供下游使用。这提醒我们：对象当前值可能来自管道，也可能来自动作编辑，复盘时要能区分。

动作不是“写了一条记录”

动作总览说，提交后的变更会反映到各应用，并写入 writeback 数据集。这是平台内对象层的行为。相关专页给出实际限制：

• 快照隔离下，两个动作改同一对象的不同属性也可能冲突。
• 对象类型的支撑数据源更新时，即使未改正在编辑的那一行，动作也可能失败。
• 默认只重试没有外部调用的动作；OSDK 访问被视为外部调用。
• 若动作会触发可能不可幂等的 webhook，不要选择对全部动作自动重试，否则可能重复写入。
• 函数对对象的编辑要整体成功才会交给动作服务提交；在动作之外运行编辑函数，不会真正改数据。
• Automate 中，同一效果里配置多个动作，并不保证执行顺序。

因此，跨 ERP、仓储或其他外部系统的写回，必须另写异常补救和人工接管，不能把“恢复一侧”当成常规自动回滚，更不能在质量拦截已经生效时，为了“两边一致”而自动解除控制。

情景（scenario）的价值在于：先把拟议变更放在沙箱里评审，再提交。自动化可以把已批准的动作执行得更快，但官方 Automate 页也提示：要写清执行身份和影响，并考虑是否先暂存人工审核。

安全与本用户边界

“按提问人权限检索”不能代替实际权限测试。OSDK 的读取过滤，阻止的是未授权读取，不是阻止应用把已读到的字段送到别处。平台可以连接商业大模型，也可以通过 Ontology MCP 让外部 Agent 读对象、执行动作——这是产品事实。

若对象中包含客户或员工个人信息、工单原文、设备序列号，把这些架构直接接到云模型（脱敏也不行）不符合本用户数据边界。学习产品时可以描述它，实施时不能推荐。

一句话对照

规则写在文档里，只解决“应该怎样”；对象状态、动作提交条件和权限策略，才解决“系统此时允许怎样，以及失败后还剩什么”。

文中直接点到的文献

• Core concepts：数据集类比是教学对照，不是强制一对一架构。本页仍写“Roles are the central permissioning model”，需与现行安全与对象权限专页对照，权限模型可能已演进。函数在此未强调可调用语言模型。 年份：年份未记载。类型：官方厂商能力描述。

打开全部 17 条文献