Knowledge vs Palantir
内容提要
Knowledge 项目以“条目+三元组”归一化存储业务数据，本体以规范条目内嵌知识库，通过 JSE 查询语言与定制算子为 AI 提供受控访问，并规划 Action 写侧。作者将其与 Palantir Ontology 对比，认为该数据驱动路线更利于 AI Agent 时代快速扩展。
延伸解读
类型地位：编译期事实 vs 运行期约定
Palantir 的对象类型是编译期事实，数据必须先有类型才能存在，属性集由 Ontology 固定。knowledge 的类型是运行期约定，条目先存在，类型（category/tags/规范条目）是它身上的描述。前者用类型换取强校验与建模工具，后者用最小承诺换取接入速度和扩展空间。一张新表在 Palantir 是建模项目，在 knowledge 是一次写库。
JSE 查询：有限语法内的灵活探索
JSE 强制 AI 只能进行有限访问，但有限空间内表达能力足够灵活。AI 不直接写 SQL，而是把查询意图表达为 JSON 形式的 S 表达式，由应用层编译为参数化 SQL 并强制权限与口径。这既保证安全可审计，又让 AI 能完成条件组合、聚合投影、图遍历等真正探索。定制算子将业务查询模式沉淀为词汇，AI 说“要什么”，算子决定“怎么算”。
语义与方言分离：JSE 作为存储契约
JSE 指令集稳定后，成为知识库与存储层之间的契约。在姊妹项目 hypatia 的重构中，约二十个算子语义被逐条翻译，从 DuckDB+SQLite 双库迁移到单一 SQLite + 自建 JSON 倒排，旧数据无损跨过，AI 侧查询无感。工作模式是“人守住语义契约，AI 完成方言翻译”。相比让 AI 直接写 SQL，JSE 表达意图而非方言，存储引擎只是当前编译目标，未来换存储时 JSE 层资产不会贬值。
写侧规划：Action 以规范条目为 schema
目前系统只读，写入走受控服务端管线。要成为完整 Ontology，缺的是写侧受控语义，即 Action：把一次合法业务变更定义为一等公民，例如创建人物条目并建立导师关系。计划中的 Action 以声明式规范定义类型、前置校验、副作用与权限，且 Action 的 schema 本身也是知识条目，定义新 Action 不需建模团队发版。变更安全模型已包含 archive 条目、snapshot 三元组和 committer 记录，历史是一等数据。
Q&A
Knowledge 项目的存储模型具体由哪些单元构成？
Knowledge 项目的存储层只有两种单元：信息条目（Knowledge）和三元组（Statement）。信息条目以唯一 key 标识，payload 放在动态 JSON 的 content 与 meta 中；三元组用 subject-predicate-object 表达条目间关系，并附带时间范围（start/end）与元数据。整个数据库就是条目表加三元组表。
Knowledge 的 JSE 查询语言如何平衡 AI 访问的安全性与灵活性？
JSE 强制 AI 只能进行有限的访问，但有限空间内表达能力足够灵活。有限意味着安全与可审计：AI 不能写任意 SQL、做 JOIN 任意表、DROP 或绕过行级权限，每次查询都是可序列化、可记录、可审查的表达式树。灵活意味着 AI 仍能完成真正的探索：条件组合、比较与集合算子、JSONB 深层过滤、全文匹配、聚合投影、图遍历都在同一表达式体系内完成。
Knowledge 与 Palantir 在类型处理上的根本区别是什么？
Palantir 的对象类型是编译期事实：类型系统定义在数据之前，对象必须先有类型才存在，属性集由 Ontology 固定。Knowledge 的类型是运行期约定：条目先存在，类型（category/tags/规范条目）是它身上的描述。Palantir 用类型换取强校验与 IDE 级建模工具，Knowledge 用最小承诺换取接入速度和扩展空间。
Knowledge 如何保证动态结构下的检索能力？
Knowledge 依赖一个观察：全文检索与嵌入向量都对文本本身高度敏感，而对文本之外的结构几乎不敏感。因此检索层可以一次建设、普遍覆盖：全文索引、向量索引对所有条目一视同仁，新信息结构落库即入索引。结构信息（分类、标签、关系）则交给三元组与条件过滤去补足精度。动态性与检索能力在这里并不冲突。
Knowledge 的 Action 层规划与 Palantir 的 Action 有何不同？
两者都拒绝让模型直接写数据库，都把业务变更建模为有类型、有校验、有副作用的动作，都要求可审计、可回溯。区别在绑定对象：Palantir 的 Action 类型绑定在 Ontology 的对象类型上；Knowledge 的 Action 预期绑定在规范条目上，动作的 schema 本身也是知识条目，定义新 Action 不需要建模团队发版，FDE 写一条规范条目即可。此外，Knowledge 的变更安全模型已有一套存量约定：修改前旧数据写入 archive 条目、建立 snapshot 三元组、记录 committer，历史本身是一等数据。
Knowledge 的 Ontology 插件系统如何集成 AI Agent？
每个 AI Agent 宿主（如 DSH）通过 Knowledge 插件获得一组语义清晰的工具：条件查询、精确读取、图浏览、搜索、受控保存。插件把 JSE 的纪律带进 Agent 工作流：先加载查询语言与领域技能，先锚定实体再展开图，计数走聚合而不是数截断页，归档与过期口径由服务端强制。Agent 不需要每次重新学习这些纪律，它们已被编译进工具的说明与约束里。插件是宿主中立的，同一套知识库可接入任意 Agent 宿主。
Knowledge 的信息规范是如何定义和存储的？
Knowledge 的约束方式不是外置 schema 文件，而是允许 FDE 定义信息规范，并以条目的方式保存在知识库中。一类信息该有哪些字段、哪些分类、哪些标签口径、用什么谓词关联——这些规范本身写成知识条目，进入同一个归一化的底座。AI 和数据流程在使用数据前可以查询这些规范条目，作为写入与解释的依据。规范的演进就是条目的演进，天然带有历史、归档与 snapshot 三元组追溯。
Knowledge 与 Palantir 在信息架构上的核心差异是什么？
Palantir 是本体先行的信息架构：信息流是“建模 → 管道 → 对象”，Ontology 在数据接入之前就已定义，一切数据必须穿过建模层才能成为对象。Knowledge 是数据本位的信息架构：信息流是“条目化 → 归一存储 → 受控查询”，本体不是准入条件，而是以规范条目的形式住在知识库内部，与事实共享同一套存储。前者换来强校验与企业级确定性，后者换来接入速度、扩展空间，以及本体与事实共享同一套版本历史的自洽。
