Ontology，拿我们的网站讲清楚

一场活动结束后，网站上可能留下五篇文章、一份演讲胶片、几个技术术语和一篇论文。把它们分别发布出来很容易。真正有用的是，读者从活动找到演讲，顺着演讲理解概念，再回到原始材料；AI Agent 也能沿着明确的记录和引用读取这些内容。

这就是我想用我们自己的网站解释 ontology 的原因。它最实际的价值，是把“这里有一些内容”变成“这里有哪些东西，它们为什么有关”。

最初做 ARC 的时候，我有过把它做成一个 Git 管理的 CMS 的想法。逐渐用起来以后，发现这个说法装不下我们在做的事情。ArcBlock Site 有文章，但它组织的还有产品、活动、术语、出版物和学习路径。网页把这些对象呈现给人，AFS 给 Agent 一个可以读取它们的入口。先把这个实际例子看明白，再回头看 ontology，反而容易得多。

Palantir 把一个老概念带到了业务操作中

很多人今天接触 ontology，是从 Palantir 开始的。这个词通常译作“本体”或“本体论”，在计算机领域已有多年的研究积累。W3C 的 OWL 标准用类、属性、个体及形式化语义描述领域知识。[1]

用日常语言说，ontology 是对一个领域里“有哪些事物、它们是什么、彼此有什么关系”的明确约定。医院里的病人、就诊和处方，和网站里的活动、演讲和论文，都可以按这种思路组织。

Palantir 的 Foundry 把对象、属性和关系连接到实际数据，还把动作与函数纳入其中，供业务应用使用。操作人员面对的是航班、设备等业务对象，并能通过有规则的动作改变它们。[2] 这种把领域语义接到实际操作上的做法，是本文关注的重点。

对我们有启发的是这个选择：系统围绕人要理解和处理的事物组织，数据存储与界面为它服务。Palantir 自己的设计指南也强调从领域概念出发，并用组合避免过大的万能对象。[3]

它和关系数据库差在哪里？

假设我们要记录一场会议及其文章，关系数据库可以有 events、articles，再用一张关联表连接。这个方案很好，也完全可以继续使用。

关键问题是，那条连接究竟是什么意思？文章可能是会议预告、演讲正文，也可能是事后回顾。外键保证记录能够连上，具体含义还需要领域模型表达。如果它只存在于某段代码或某位开发者的记忆里，另一个应用或 Agent 接进来时，就得重新猜一遍。

所以，表和图不是一道分界线。关系数据库能承载 ontology 方法，图数据库也需要认真建模。我们要做的是把业务意义变成明确、可检查、能被不同入口使用的约定，而不是换一个存储名词。

拿这个网站本身做例子

可以直接打开本站的 ASE 2026 活动记录。它关联了文章、学习材料和术语，其中包括 What Endures 演讲材料、介绍 AFS-UI 的文章，以及 AFS 词条。

这些内容各自是一个对象。活动有时间和地点；文章有作者与发表日期；演讲材料有自己的正文和演示布局；术语有名称、别名和定义。读者可以从不同入口进入，内容不必为了出现在另一个页面上被重新写一份。

这里有一个值得分清的细节。本站 refs 说的是“显式关联哪些对象”，适合帮助读者继续阅读。学习对象的 buildsOn 则明确表示前置知识，产品的 renamedTo 表示名称变化。它们不能都被解释成同一种“相关”。

例如，演讲材料的记录中有这样的字段摘录：

kind: "presentation"
buildsOn: ["afs-ui", "aup"]
refs: {"events": ["ase-2026"]}

这几行分别告诉系统：它是一份演讲材料，理解它需要先掌握哪些知识，它关联哪场活动。afs-ui 和 aup 是指向相应学习记录的对象标识。页面可以按演讲的方式呈现，学习入口也有结构化信息可用。字段背后有实际的对象和查询，文字不只是给某张模板填空。

AFS、Arc Space 和 ARC，各自做什么

要理解这套方法，最好把数据含义、访问方式和运行能力分开看。

领域对象定义“这是什么”；AFS 提供资源访问方式；Arc Space 承载数据及其访问权限；ARC 让应用和视图运行起来。

AFS 是 Agentic File System。它给文件、内容集合和服务等资源提供路径化的访问接口，由资源适配器（provider）连接实际资源。Agent 可以在授权范围内发现、读取、查询或执行资源支持的操作。路径让操作有落点；“这是一份论文”“这条边表示前置知识”仍由领域契约说明。

Arc Space 是承载用户和应用数据的空间。对本站来说，发布内容位于 blocklet 的包数据中；登录用户的剪藏等个人数据则有自己的用户空间。数据的归属与访问权限，和页面长什么样，是分别处理的问题。

blocklet 是运行在 ARC 上的应用包。ARC 是运行这些应用包及其声明能力的运行时。本站的 schema、集合、布局和内容交给它处理，形成列表、详情、搜索等阅读入口。

本站 articles 集合的声明可以摘出这样一段：

articles:
  type: article
  scope: /packages
  faces:
    web: true
    sitemap: true
    jsonld: true
    mcp: [search, list, get]

这段配置选择同一集合要提供哪些出口。Web 面向读者，MCP 是 Agent 调用搜索、列表、读取等工具的一种接口，在这里提供工具访问；搜索索引还有独立的索引声明。其他集合可以作不同选择，例如文档集合还声明面向语言模型的文本出口。

人的阅读页面和 Agent 的工具入口，因此可以围绕同一份源内容建立。各入口仍有自己的配置和权限条件，而我们无需为每种出口维护一套文章正文。

为什么 CMS 不再足以描述我们的工作

CMS 擅长处理内容编辑、审核和发布。成熟的 headless CMS 也能定义自有类型、关联对象、提供 API。这些能力都值得认真对待。

我改变说法，是因为在我们的实际工作里，出版文章只是其中一种结果。我们把工作方法、对象契约、资源访问和可阅读结果放在同一个项目环境中。Agent 可以读取规则、整理材料、维护对象，运行工具检查，再把结果交给人审阅。文章、活动或演讲，只是这次工作的不同对象。

这是组织方式的比较，不是 CMS 的功能上限。我们选择 ARC 的意义，在于 AFS 访问、运行能力和对象视图可以一起使用，而不必为这个站再建立一套专门的应用后端。

这些工具本身不是 ontology。对象与关系的约定，让工具处理的是同一套可识别、可检查的工作对象。

今天这个仓库就有很具体的例子：schema 说明内容形状，写作 skills 说明怎样查证与组织文章，命令行检查验证内容和页面，发布流程负责交付。判断仍由作者承担。Agent 的工作环境里同时有材料、规则和工具，人的一句请求才有条件变成可审阅的结果。

规则要落在数据上，也要知道管到哪里

本站的学习内容会检查前置知识是否存在、前置依赖有没有循环。出版物与学习内容之间的引用，也会检查目标和双语身份字段。它们守的是明确的数据条件：打错目标不能悄悄变成一个消失的关联。

语义约定也帮助我们决定什么不应该推导。文章关联一个产品，表示它与产品有关；证明某项能力，则需要具体实现和运行依据。W3C 的 PROV 模型把产物、活动和责任主体区分开，提供了一个理解来源的参考。[4] 对编辑和工程工作而言，知道材料从哪里来，与判断材料是否正确，需要分别承担责任。

我们借鉴的是这些可用的纪律。记录一个简单想法时，不必先定义整个世界；当某种关系反复参与阅读、查询或检查时，再把它明确下来。本站也没有必要为了采用 ontology 方法，先换成一套三元组存储或增加通用推理引擎。

怎样亲自看懂这套结构

可以从活动记录进入，打开关联的演讲材料，再沿着概念和学习内容继续读；也可以从 AFS 学习入口 出发，查看概念之间的联系。想核对原始出处时，Everything is Context 的出版物记录 保留了论文的作者、版本标识和原始链接。

如果准备按这种方法组织自己的站点，我会从读者真正需要回答的问题开始：这是哪个产品？文章属于哪次活动？这份材料需要什么基础？然后给这些事物建立各自的记录，只添加能够被页面、查询或检查实际使用的关系。

只有几页介绍文字的网站，简单页面就够了。随着材料变多、同一内容要被多个入口使用、Agent 也参与维护时，明确的对象关系能减少重复整理和错误关联。

回到开头那场活动：文章让人理解发生了什么，演讲材料保留完整表达，术语帮助理解概念，论文提供原始出处。它们各有自己的形态，又能在同一个阅读过程中连起来。

这就是我们采用 ontology 方法的实际落点：让内容成为有意义、可查询、可检查、可继续使用的对象。网站把这些对象和关系呈现给读者，Agent 也能读取同一份记录。

参考