operational-ontology

**English** | [日本語](./README.ja.md) # 运行本体 [](https://github.com/gura105/operational-ontology/actions/workflows/ci.yml) [](./LICENSE) > **运行本体是建立在您不拥有的系统数据之上的共享领域模型——对象、链接和动作——其中读取操作遍历模型，写入操作由带有业务规则的动作控制，这些动作经过审计并将更改传播回拥有状态的源系统。** > > 语义层让您可以 *读取* 您的业务。运行本体让您可以 *运行* 它。 <picture> <source media="(prefers-color-scheme: dark)" srcset="./assets/hero-diagram-dark.svg"> <img src="./assets/hero-diagram.svg" alt="读取操作从共享模型传播到代理、应用程序和人员。写入操作通过审计的动作门户进入，写入操作返回到拥有状态的源系统。"> </picture> Palantir Foundry 的 Ontology 是这种模式的一种实现。这个仓库是另一个：一个最小的参考实现，小到可以在一坐读完。它存在是为了使定义精确和可运行；它不是一个框架。您可以 fork 它并重用这些想法。 ## 快速开始 ```sh pnpm install pnpm demo # 物理数据 → 集成 → 索引 → 读取 → 写入 → 拒绝 → 写回 pnpm test # 相同的行为，作为可执行的测试 ``` 演示使用了[本文档附带的文章](https://x.com/gura105/status/2077153028982133080)（日语）中的场景。一家公司收购了竞争对手，并继承了**两个具有不同模式和状态编码的遗留订单系统**。几十行 SQL 和一个小的 TypeScript 映射集成了它们，ontology 在其上建模了 `Customer`、`Order` 和 `Product`，以及 `Note`，一种在源系统中不存在的类型。演示然后显示： - 一个链接遍历，回答“哪些订单包含此产品？”跨越两个系统 - `assignOrder` 写入存在于遗留系统中的状态 - 编辑可以生活在源之上的一层 - `cancelOrder` 在已发货订单上被 `SHIPPED_ORDER_CANNOT_BE_CANCELLED` 拒绝 - `cancelOrder` 在开放订单上成功，遗留 ERP 中的行实际上发生了变化 - 实时遗留系统的重新索引，订单数据从 ERP 刷新，而分配和注释 - ontology 自身拥有的状态 - 存活 - 每次尝试，无论是应用还是拒绝，都记录在审计日志中 https://github.com/user-attachments/assets/02bb8ca0-a476-4e33-b0ea-25c46c6e9dda ## 四个属性 系统实现该模式时，所有四个属性都必须成立。它们约束 *什么* 必须是真实的，而不是 *如何* 构建它：出站或 webhook，SQL 或搜索索引，一个存储或多个存储都是实现选择。将它们视为共享词汇来讨论系统，而不是作为要通过的认证。 1. **语义对象和链接。** 业务实体及其关系被显式建模，在物理数据之上，而物理数据首先由其他系统拥有。 2. **动作门控写入。** 业务决策仅通过命名动作更改状态。没有通用更新路径 - 不适用于用户，不适用于应用程序，不适用于代理。 此层中的状态也会因其他两个原因而更改，并且两者都不是漏洞：重新索引仅重放源已经说的内容，而架构演化（正在审查）更改可以说的内容，而不是更改内容。任何选择业务结果的写入都是决策，无论端点名称如何，并且决策都经过动作。 3. **动作中的业务规则。** 前提条件检查领域不变量（“已发货订单无法取消”）并拒绝违反行为，并带有机器可读的错误。它们不是访问控制，也不是 UI 验证。每次尝试，无论是应用还是拒绝，都记录在审计日志中。 4. **写回系统记录。** 模型为每个状态声明哪个系统拥有它。有三种类型： - **源支持** - 由上游系统拥有的状态，例如 ERP 中的订单状态。更改它会作为受控、有序的副作用传播回源；源保持权威。 - **本体拥有** - 没有源系统列的状态，例如分配者或分类注释。对于此状态，本体的自身存储是记录系统，通过声明。 - **派生** - 计算状态，例如聚合和计数。它永远不会被写入。 该属性禁止状态无声明所有者：源支持数据的本地副本被修改但从未写回，或者任何人都可以放置的写入。 实现没有源支持写入的系统不实现此模式的较小版本；它是一个普通的应用程序，具有自己的数据库。 快速测试：**“您可以从语义层取消订单吗？”** - 如果答案是“否”，则您有一个读取层 - 有用，但它是不同的东西。 - 如果答案是“是”，但任何记录系统中的行都不会更改，则您有一个并行数据库 - 也是不同的东西。 - 如果它还会无投诉地取消已经发货的订单，则您有一个写入 API；属性 3 是整个差异。 ## 为什么需要另一个词？ 该模式需要一个专有的名称，因为“ontology”已经有太多含义： | 被称为“ontology” | 它是什么 | 受控写入？ | | --- | --- | --- | | 哲学本体论 | 存在的研究 | - | | 形式本体论（OWL / RDF） | 机器可理解的语义 | 否 | | 知识图谱 | 实体和关系 - 可写入数据，而不是操作 | 否 | | AI 上下文层（2026 年“ontology”品牌平台功能的浪潮） | AI 答案的语义基础 | 否 | | **运行本体论（Foundry 风格）** | 业务领域模式 **+ 带有规则的动作** | **是** | 每一行都是一个合法的工具，表格不是排名。但改变层的能力 - 它是否接受由业务规则控制的写入 - 贯穿整个表格，没有自己的名称。这个仓库为它提供了一个名称。 ## 实现声明的内容 四个属性留下了机制开放，但一些选择在用户可以观察到的方式上有所不同。这些选择必须声明，而不是保持沉默。有四个： - **权威** - 哪个状态是源支持的，哪个是本体拥有的，哪个是派生的。 - **失败语义** - 当写回和本地提交不同意时发生的情况。 - **重新索引与编辑** - 本体拥有状态在基数刷新时是否存活。 - **可见性默认值** - 没有策略的对象默认为哪个可见性。 此仓库的答案，按顺序排列。所有权在模型中声明 - `owned` 标记本体拥有的属性、链接类型或整个对象类型，而 `writeback: true` 标记动作的更改源支持 - 运行时检查每个编辑计划是否与这些声明相符，而不是信任它们（[详细信息](./IMPLEMENTATION.md#the-authority-line-checked)）。写回在本地提交之前运行，因此如果源拒绝，则此处不会发生任何更改（参见[失败语义](#failure-semantics)）。本体拥有的状态在重新索引时存活：编辑生活在覆盖层中，`load()` 重新应用在新鲜基数上，而拒绝使重新索引孤立的编辑的重新索引被拒绝。可见性默认为开放：没有策略意味着对每个人可见（参见 [FAQ](#faq)）。 所有四个答案也收集在一个可枚举的值 `Runtime.declarations` 中，以便可以在运行时读取它们，而不是信任为原始文本。实现可以以不同的方式回答这四个问题，并且仍然在模式之内。如果产品将其自身称为运行本体，询问其四个答案，而不是证书。 ## 面向 AI 代理（MCP） ```sh pnpm mcp # 通过 stdio 将相同的本体服务于代理 ``` MCP 工具表面由模型生成：`search_order`、`traverse_customer_orders`、`cancel_order`、`read_audit_log`，... - 每个查询形状一个工具，每个动作一个工具。两个结果： - **没有原始 SQL 工具。** 代理获得模型定义的确切操作，而无需其他操作。 - **与人类相同的先决条件控制代理。** 尝试取消已发货订单的代理会收到 `{ "error": { "code": "SHIPPED_ORDER_CANNOT_BE_CANCELLED", … } }` - 它可以读取、恢复和向其用户解释的机器可读拒绝。 读取范围相同。每个查询都运行为一个 `actor` - 调用者代表的身份，并且模型中附加的可见性策略决定了该 actor 可以看到哪些对象。代理会话不是例外；审计日志是唯一一个无范围的管理员视图。所有调用者通过 stdio 折叠成一个 actor。`OO_AGENT=<name> pnpm mcp` 命名该 actor，这是标记而不是身份验证。 https://github.com/user-attachments/assets/28327062-e09f-4103-943e-434a0e55b327 **业务规则存在于本体中，而不是提示中。** | 方法 | 读取 | 写入 | 规则强制执行者 | | --- | --- | --- | --- | | 原始 DB 访问（SQL 工具 / DB MCP） | 表 | 无限制的 `UPDATE` | 没有 - 最多是提示 | | 语义层 / 指标 MCP | 受控指标 | - | 无（只读） | | API 包装器工具 | 端点 | 按端点 | 每个后端，不一致 | | **运行本体** | 对象、链接、聚合 | **仅命名动作** | **模型中的前提条件，审计** | ## 模式 五个概念 - 对象、链接、动作、编辑和审计日志 - 被定义为数据，并由运行时解释（`src/core.ts`）： ```ts const ontology = defineOntology({ name: 'orders', objects: { Customer: defineObject({ primaryKey: 'id', properties: { id: z.string(), name: z.string(), region: z.string() }, }), Order: defineObject({ primaryKey: 'id', properties: { id: z.string(), status: z.enum(['pending', 'shipped', 'cancelled']), total: z.number().int(), // 次要单位 - 金额不是浮点数 assignee: z.string().nullable(), }, owned: { assignee: null }, // 本体自身的状态，已声明 source: 'north.tbl_order ∪ south.SALES_ORDER', // 物理数据优先 }), }, links: { customerOrders: defineLink({ from: 'Customer', to: 'Order', kind: 'one-to-many' }), }, actions: { cancelOrder: defineAction({ object: 'Order', targetParam: 'orderId', params: { orderId: z.string(), reason: z.string().min(1) }, preconditions: [ ({ object }) => object.status === 'shipped' ? reject('SHIPPED_ORDER_CANNOT_BE_CANCELLED', `order ${object.id} has already shipped`) : undefined, ], effects: ({ object }) => [modify('Order', object.id, { status: 'cancelled' })], writeback: true, }), }, }) ``` 由于定义是纯值，因此可以枚举、差异化和版本化；MCP 工具表面是从中机械派生出来的。 `Runtime.execute()` 是 API 公开的唯一操作写入路径。它始终按此顺序运行以下步骤： 1. 验证参数 2. 评估前提条件 3. 运行效果函数，返回编辑计划本身不执行任何操作 4. 通过与提交使用的相同代码进行干燥运行计划，然后回滚 5. 检查计划是否与权限声明一致 6. 写回系统记录 7. 在一个事务中提交编辑和审计条目 此闭包是 API 上的合约，而不是权限边界：运行时位于调用者的进程中，持有数据库句柄的代码可以直接绕过关口（[详细信息](./IMPLEMENTATION.md#transaction-ownership)）。`load()` 是单独的基础设施：它重新索引源 - 重放，而不是决策 - 不属于用户 API。 读取也带有标识。每个 `search` / `get` / `traverse` / `aggregate` 都运行为一个 `actor`，并且对象类型可以附加一个 `visibility` 谓词 - 最小形式的行级安全，存储在模型中。隐藏的对象对于读取和作为动作目标是无法区分的。 编辑也是数据：`modify`、`create` 和 `link` / `unlink`。因此，动作可以更改链接实例，而不仅仅是属性。链接 **类型** 是模型的一部分，不会在此处更改；哪些链接存在于哪些对象之间是状态，并且仅通过动作更改 - 包括基数：运行时拒绝 `link` 将给订单两个客户。 “将此订单重新分配给另一个客户”是 `unlink` 加上 `link`，在与所有内容相同的先决条件下原子应用。创建通过相同的关口：演示的 `addOrderNote` 创建一个本体拥有的注释，并将其链接到其订单在一个原子计划中。删除在此版本中不适用（参见[状态](#status)）；更改模型本身 - 新对象类型，新链接类型 - 是架构演化（参见 FAQ）。 模型是数据而不是类，原因很实用。`class Order { cancel() {} }` 不能枚举成代理工具，不能在应用程序之间共享，也不能在运行时检查，而需要额外的反射层，其签名对于前提条件一无所知。基于类的领域层是特定于一个应用程序的；这个模式的重点是共享的领域层。 ## 它在哪里 三个层次。本仓库仅实现中间层。 <picture> <source media="(prefers-color-scheme: dark)" srcset="./assets/where-this-sits-dark.svg"> <img src="./assets/where-this-sits.svg" alt="三个层次 - 应用程序，运行本体和数据层 - 每个都映射到 Foundry 和本仓库中的实现。本仓库实现了拥有自己的存储的中间层。在本体-数据缝隙处，存在两个合约：集成物理数据给出，写回是一个受控的副作用。"> </picture> **上游合约（与数据平台）：** 集成物理数据给出。管道、数据集事务和回滚属于数据平台。 **下游合约（与记录系统）：** 写回是一个受控的副作用，而不是分布式事务（见下文）。 一个后果将此模式与查询端层分离：仅查询的层可以保持虚拟，但接受写入的层必须拥有状态。编辑在此之前存在 - 或代替 - 记录系统（`assignOrder` 写入本体拥有的状态，没有遗留系统有列），因此本体保留其自身的存储和审计日志。本仓库不拥有使读取在企业规模上快速的索引机制：增量索引、邻接索引、搜索后端。那是实现层的实现，而不是模式。 ## 失败语义 **模式的要求。** 该模式不规定本体和记录系统之间的一致性机制；分布式事务、排序合约、外箱和对账作业都是实现选择。 它要求声明**失败行为**，因为与内部机制不同，失败行为是可观察的：用户可以观察到系统之间的差异。 可以推理的差异是工程问题； 在生产中发现的差异是事故。 **本实现声明的内容。** `WritebackAdapter` 在本地提交之前运行 — Foundry 的写回 Webhook 的排序（Foundry 的两种模式之一；另一种在编辑后运行副作用）。 两个结果： - 如果记录系统拒绝， 本体中没有任何变化。 - 仍然可能出现相反的失败：适配器成功而本地提交失败。 发生这种情况时，系统已经出现分歧， 需要操作员进行协调。 [Palantir 的 Webhook 文档](https://www.palantir.com/docs/foundry/action-types/webhooks) 承认了 Foundry 写回模式下的相同差距。 三个细节限定了这种风险（[完整机制](./IMPLEMENTATION.md#failure-semantics-in-detail)）： 任何无效内容都不会到达记录系统， 因为在适配器运行之前，整个编辑计划都会通过提交自己的代码进行预运行； 审计日志记录了两个失败方向的完整计划， 作为协调材料； 并且“每次尝试都经过审计”意味着运行时观察到的每次尝试。 在其自己的存储中，运行时是事务性的： 操作的编辑和审计条目在单个 SQLite 事务中原子提交， 并且被拒绝的尝试也会被记录。 **前提条件和新鲜度。** 保证：前提条件针对本体存储 - 最新索引快照加上应用的编辑。 不保证：写回步骤不会在源处重新验证不变性， 因此如果源在本体背后更改， 不变性可能不再成立。 缩小这一差距是适配器的选择 - 条件写回、比较和设置、源处重新验证。 演示适配器执行此操作： 一个有保护的 `UPDATE` 允许 ERP 拒绝过时的取消。 **并发编辑。** 保证：此实现是一个同步的单写入器 - 操作一次执行一个， 由运行时序列化 - 并且运行时拒绝在调用者打开的事务中运行， 因此不能在成功被报告后默默回滚已提交和审计的操作。 不保证：`WritebackAdapter` 接口是同步的， 而真正的网络写回会破坏序列化； 实现时必须声明什么取代它。 存储边界的其余部分是一个已声明的合约， 而不是一个被防御的合约： 规则和适配器不得触摸本体存储， 因为没有进程内的检查可以阻止持有数据库句柄的代码（[详细信息](./IMPLEMENTATION.md#transaction-ownership)）。 **重新索引与编辑。** 存储保存了一个从源索引的基础， 以及操作在上面进行的编辑， 并且源不断变化， 因此每个实现都必须决定重新索引对编辑的影响。 这里 - Foundry 的形状， 最小化 - 快照可能只提供源支持的状态； 对本体拥有属性的编辑通过重新应用在新基上覆盖的叠加层而存活下来； 本体拥有的类型和链接完全不受 `load()` 的影响。 拒绝可能使本体拥有的编辑成为孤儿的重新索引， 留下以前的状态： 这是一个协调决策， 运行时不会默默做出协调决策。 完整的规则 - 包括删除遇到存活的编辑， 和部分快照 - 在[实现说明](./IMPLEMENTATION.md#re-indexing-vs-edits)中。 ## 非目标 v0 的范围是固定的， 因此参考实现足够小， 可以一次性读完： - **没有 UI 构建器。** 应用程序使用本体； 它们不是本体的一部分。 - **没有管道框架。** 集成是一个前提； 演示使用普通的 SQL。 - **没有索引基础设施。** 简单查询在演示规模上是足够的； 规模是实现的属性， 而不是模式的。 v0 中的结果集是无界的。 - **没有联合。** 一个本体是一个有限的上下文。 当有多个时， 谁拥有模型是一个现实问题， 在 v0 中没有解决， 像模式演化一样。 - **没有链接属性或复合键（暂无）。** 演示中的订单行数量故意保留在数据层； 它们是否成为一个一级的 `OrderLine` 或链接上的属性是下一个版本的决定。 - **没有 OWL/RDF。** 学术本体是纯语义的 - 没有操作。 不同的工具用于不同的工作。 - **没有通用授权系统。** 模式级部分在这里： 标识通过每个调用（审计日志的管理视图是已声明的例外） 和可见性附加到模型。 机制 - 组， 属性， 策略语言， 单元格级安全， 传播 - 是一个策略引擎的工作。 - **没有 npm 包。** 复刻它； 不要依赖它。 - **不是 Foundry 替代品。** Foundry 实现了所有三个层， 垂直集成； 该存储库命名和演示中间层。 ## 先前的工作 - **Palantir Foundry Ontology** - 本模式提炼的实现， 包括其[语义/动态词汇](https://www.palantir.com/docs/foundry/ontology/overview)， [操作类型](https://www.palantir.com/docs/foundry/action-types/overview)， [写回 Webhook](https://www.palantir.com/docs/foundry/action-types/webhooks)， 和 Ontology MCP。 本存储库独立于任何供应商描述该模式。 - **DDD，CQRS，事件源** - 这些部分故意很旧： 实体， 聚合， 命令， 受保护的状态转换， 仅追加日志。 新的是放置： 域层从单个应用程序中提取出来， 置于其他系统的数据之上， 并由许多应用程序和代理共享。 - **语义层**（dbt，Cube，AtScale，…）和**知识图谱/OWL/RDF** - 受管读取而非受管写入； 与此模式定义的相邻类别。 - **“操作本体”** - 该短语本身已被先前使用。 学术本体工程以无关含义使用它， 而 Vladimir Kozlov 的 2025 LinkedIn 文章（[定义](https://www.linkedin.com/pulse/operational-ontology-semantic-interface-between-data-action-kozlov-njnle)， [Foundry 演练](https://www.linkedin.com/pulse/understanding-palantirs-operational-ontology-beginners-kozlov-d0vse)） 将其应用于与此处描述的相同的血统： Foundry 样式的模型， 携带操作， 而不仅仅是语义。 本存储库添加了一个可测试的边界 - 四个属性， 包括写回和审计 - 和一个参考实现。 ## 常见问题 **这难道不是带有验证的 CRUD 吗？** 这些部分很熟悉； 配置不是。 CRUD 验证存在于一个应用程序中， 在该应用程序拥有的表中。 这里的模型位于其他系统拥有的数据之上， 被每个消费者（UI，脚本，代理）共享， 关闭除操作之外的所有写入路径， 审计每次尝试， 并将接受的更改写回记录系统。 最接近的现有描述是从应用程序中提取的 CQRS 命令层， 并置于其他人的数据之上。 **知识图谱也可以写入吗？** 是的。 SPARQL UPDATE 可以设置 `status = 'cancelled'`， 而 `WHERE` 子句或 SHACL 形状可以使其条件化。 三元存储不提供一个名为第一类单位的其余合约： 命名业务操作， 机器可读的拒绝， 尝试的审计跟踪， 和写回记录系统。 差异不是能力 - 所有这些都可以在三元存储上构建 - 而是什么从模型中命名， 管理， 和第一类出来。 **为什么不使用 OWL/RDF？** 那些描述事物*是什么*（语义）。 模式的一半是*可以做*什么（动态）： 操作， 前提条件， 审计， 写回。 推理器无法取消订单。 **为什么使用 TypeScript 定义而不是 YAML？** 因为业务规则是代码， 而嵌入在 YAML 中的规则表达式往往会发展成临时规则引擎。 TypeScript 对象字面量在规则保持为普通类型代码的同时保持模型可枚举。 （类型涵盖语言， 而不是模型的自身模式 - 参见[状态](#status)。） 结构作为数据， 规则作为函数 - Foundry 在 Ontology Manager 和 Functions 之间做出的相同划分。 **关于事务和回滚呢？** 三个领域， 三个答案。 数据集版本控制和回滚属于数据层（在 Foundry 中： 目录事务和分支）。 操作的编辑的原子应用属于此层（此处实现为真正的 SQLite 事务）。 跨系统写回的一致性机制是实现定义的； 模式要求它被声明， 而此实现声明写回优先排序（参见[失败语义](#failure-semantics)）。 **关于权限和安全呢？** 一个问题隐藏了三个不同的事物： - **身份验证** 在模式之外： 身份已经建立。 这里的`actor`是一个自我声明的字符串 - 此实现演示了放置， 而不是保护。 - **授权**： 其*放置*是模式的一部分 - 策略附加到对象类型和操作， 并绑定每个消费者的读取和写入， 就像 Foundry 将动态安全计为 Ontology 的动态元素一样。 其*机制*（组， 属性， 策略语言， 单元格级安全， 传播）是实现定义的。 - **前提条件** 都不是： 它们是有效性， 而不是许可。 区别对于代理很重要， 它们从每个代理中恢复不同： - **可见性** - 你看不到它 - **许可** - 你不能做 - **前提条件** - 没有人可以 （Foundry 在其操作提交标准中混合了许可和有效性， 并且仍然符合； 分离是一个建议， 而不是要求。） 两个设计选择如下。 `preconditions` 是一个必需键， 而空列表是一个明确的决定： 门控写入是模式的核心， 因此必须声明“无条件”， 而不是默认为。 `visibility` 是一个可选键， 因为是否存在授权本身是实现定义的； 没有策略的对象对每个人都是可见的（**失败打开**）。 没有身份验证的参考实现不能有意义地关闭， 因此它不假装。 Foundry 的基线是相反的 - 离散授予从零扩展访问， 而强制标记在上面拒绝。 关闭的部署首先需要 `visibility`， 而且需要真正的身份验证， 操作权限和作用域审计访问。 另一个已声明的表面： 审计日志读取 API 是无作用域的 - 一个管理视图， 其中不应用可见性过滤。 **关于 Foundry 的 Functions 和派生属性呢？** Foundry 统计了三个动态元素： 操作， 函数， 动态安全。 基于函数的动作已经存在于此模式中 - 前提条件和效果是普通代码， 描述更改； 效果返回编辑计划， 而不执行它们自己， 而副作用属于适配器。 读取时计算 - 派生属性， 查询函数 - 被故意排除： 模式的区分一半是受管写入， 而不是计算读取。 动态安全是上面的权限故事。 **如果代理重试呢？** 此实现没有幂等键。 重试的 `cancelOrder` 被其自身的前提条件拒绝（`ORDER_ALREADY_CANCELLED`）- 自然幂等性通过规则， 而不是保证 - 而重试可能与写回交织， 可以在源处双重应用副作用。 如果操作不是自然幂等的， 则参数中的调用 ID（像所有其他一样经过审计）是最小的起点： 它购买相关性， 而实际重复删除需要在该 ID 上进行唯一性检查。 幂等性是实现定义的， 并且值得声明， 因为代理确实会重试。 **本体本身如何变化？** 模式演化 - 新的对象类型， 更改的属性， 退休的链接 - 是真实的， 而在此处超出了范围， 像联合一样。 Foundry 有版本控制和提案机制， 而学术领域将其作为*本体演化*进行研究。 本存储库贡献的是安全演化的前提条件： 模型是一个普通值， 因此可以像其他代码一样进行差异， 版本控制和审查。 域建模不是一步完成的； 模型不断适应业务。 **可以带上自己的前端吗？** 是的。 应用程序契约是两种调用 - 查询（`search`/`get`/`traverse`/`aggregate`）和 `execute(action)` - 相同的人类和代理， 每个调用都是作为一个执行者。 仪表板使用第一个； “取消”按钮使用第二个。 规则遵循模型， 而不是前端。 ## 状态 v0.2 - 参考实现。 此版本删除了强制执行超出四个属性的誓言的机制 - 规范形式存储检查， 外部事务检测， 无目标操作， 属性镜像链接， 删除 - 并用已声明的合约取代， 保持运行时在一次会话中可读。 四个属性中没有一个丢失。 当前限制， 也是下一个版本的工作清单： - 更改源支持和本体拥有状态的计划被整个拒绝； 按编辑路由是未来工作。 - 创建仅限于本体拥有类型； 通过写回支持的源创建尚未演示。 - 没有删除。 - 没有链接属性或复合键。 - 规则上下文没有完全类型化。 - 嵌套属性没有严格验证。 此实现的声明背后的机制在[实现说明](./IMPLEMENTATION.md)中。 使用 Node 24， better-sqlite3， zod 4， MCP SDK 1.29 构建和验证。 MIT &copy; gura105