知识工程绿皮书：RAG、本体与 Agent 全景指南

序 为什么是知识工程，为什么是现在

Why Knowledge Engineering, Why Now

这本绿皮书想回答一个正在变得紧迫的问题：当模型能力越来越像公共品，团队真正的竞争力从哪里来？我们的答案是一个等式——AI 时代的生产力 = 模型能力 × 工程框架 × 领域知识。模型是厂商迭代的，工程框架和领域知识才是团队自己攒得下的。这本书讲的就是怎么攒。

一个等式，两条主线

这个等式里，三个因子的性质完全不同。模型能力的提升是概率性的回报：你追不上厂商的迭代节奏，也无法把别人的基座模型变成自己的壁垒。工程框架是把模型能力兑现为生产力的传动装置——同一个模型，换一套 Harness 设计，成本和上下文消耗能差出数倍（Databricks 的实测数据是成本差两倍、上下文少三倍）（来源：四种Harness设计路线）。而领域知识是那个最难复制的乘数：“数据越通用，竞争价值越低；越独有、越难搞到，价值越高。通识数据是公共品，人人可得，构不成任何壁垒；行业专识才是护城河，恰恰因为它买不到、爬不来，只能自己造。”（来源：高质量数据从哪里来）

围绕这个等式，全书有两条互为表里的主线。第一条是 AI 软件工程——怎么驾驭 AI 干活，它沿着“Prompt → Context → Harness → Loop”的阶梯演进，回答的是工程框架这个因子。第二条是知识工程——AI 的燃料与护城河，从本体论到知识库建设范式再到数据工程流水线，回答的是领域知识这个因子。两条线的交汇点很清晰：工作流是管道，知识才是流过管道的活水（来源：Harness不是目的知识才是护城河）。

为什么是现在

知识工程不是新词，但它的问题域在近两年被彻底改写了。过去的知识管理，消费者是人：图书馆隐喻，有索引、有分类、可检索，评价标准是文档数量和可读性。今天，知识的消费者变成了 Agent——知识库的定义已经改写为“面向 Agent 的持久化知识载体”，其价值公式 = 覆盖率 × 新鲜度 × 可检索性（来源：知识库）。这是一次范式迁移：从知识管理（KM，给人管文档）到知识工程（KE，给机器建知识）。

三个信号说明这个迁移正在此刻发生：

这本书的结构：八个 Part，六个维度

全书 20 节加附录，按六个维度组织——技术趋势、方法论、实践框架、案例、最佳实践、Molio 实践。Molio（本书使用的知识库工作流系统）是贯穿全书的主角：Part 6 整 Part 讲它，Part 1-5、7 每章末尾各有一个“Molio 实践框”，把该章主题落到它的具体能力上。

这本书是怎么写出来的：一次知识工程的自证

需要坦白交代的是：这本书本身就是一次知识工程的实践。它不是凭训练记忆写成的，而是基于一个 270 页的知识工程 wiki 知识库——其中包含本体论五部曲、Palantir Foundry 约 267 万字的官方文档拆解、国家标准 GB/T 48000.3 的语义化建模分析，以及 15 篇 AI 工程一线文章的摘要页。全库由源摘要 22 页、实体 77 页、概念 158 页、对比 6 页、问答 6 页与概述 1 页构成（来源：全库总览）。

写作流程走的正是 Molio 知识库工作流：先由调研 agent 通过 wiki-query 全量读取相关页面，产出 7 份共约 3600 行的调研素材（每条素材逐页标注来源）；再由规划环节把素材组织成章节大纲；最后多个写作 agent 并行成文、合并构建为这本 PDF。书里的每个论断都能回溯到库内的具体页面——这恰好符合本书自己主张的知识库标准：引用可溯源、覆盖可统计、内容可 lint。

读者画像与阅读建议

这本书写给三类读者，不必从头读到尾：

最后一个约定：书中所有引文都标注了来源页名，硬数据（成本差、命中率、规模数字）均出自库内调研素材所引的原始出处，未做臆造；观点性判断则明确归于对应的 wiki 页面。如果你发现某个论断与你的实践相悖，欢迎当作一次 lint——知识库的价值，本来就在使用中越校越准。

§01 AI 工程演进阶梯

The Evolution Ladder of AI Engineering

过去五年，围绕大模型的工程实践沿着一条清晰的阶梯逐级上行：从措辞一条指令的 Prompt Engineering，到决定放什么进上下文的 Context Engineering，到组织能力与边界的 Harness Engineering，到设计自运行反馈系统的 Loop Engineering，再到组织多 Agent 系统的 Graph Engineering。这一节把这条阶梯逐级展开，讲清每一级优化什么、为什么会出现上一级，以及一个已被多组基准反复验证的核心事实：agent = model + harness——同一个模型，换一个 Harness，成本、通过率、可恢复性全都会变。

1.1 五级阶梯：每一级都在回答上一级答不了的问题

AI 工程的演进阶梯不是学术分类，而是一条"问题被逼出来"的历史。当措辞优化到极限，你发现瓶颈是上下文里放了什么；当上下文装配到极限，你发现瓶颈是模型外面的运行时不够稳；当单个 Agent 跑得足够好，你发现瓶颈是多个 Agent 之间没有结构。每一级的出现，都对应上一级触到了天花板。

1.2 三层智能层级：阶梯的理论化

2026 年的一篇 arXiv 综述《大型语言模型智能体时代的图工程》（引用 500+ 篇文献、全文 33 页）把这条阶梯理论化为三层智能层级：

（来源：模型智能、个体智能、系统智能、大型语言模型智能体时代的图工程）

值得注意的是评估难题：仅凭端到端任务成功率不足以判断系统智能——性能提升可能来自更强基座模型、更长上下文或更多计算成本，而非更有效的系统组织（来源：系统智能）。这也是下一小节"四组基准"存在的原因：它们把模型固定住，专门测 Harness 的差异。

1.3 Harness 演化六阶段：边界驱动的部件生长

阶梯的中段——Harness——自己内部也有一条演化路径。它的发生学机制叫边界驱动：复杂性不是一次设计出来的，每当模型试图越过一次调用的边界，系统就必须在模型外面补一个新部件。一句话概括这条生长逻辑："记不住就装配上下文，碰不到世界就接入工具，一步做不完就启动循环，历史装不下就分长期记忆，副作用变多就长出会话/权限/沙箱/事件/子 Agent。"（来源：Harness演化阶梯）

逐阶段看，每一级都对应一次"撞墙"：

（来源：Harness演化阶梯、从一次LLM调用到完整Harness）

这条阶梯贯穿始终的核心原则只有一句：模型看见的一切，都是运行时系统为它构造出来的。理解它，才能判断一个新 Harness 设计补齐的是哪一层边界、付出的 Harness tax 花在了哪里。而且模型变强不会让 Harness 消失——"模型越能行动，外面的运行时越不能含糊"（来源：从一次LLM调用到完整Harness）。

1.4 agent = model + harness：同一模型，不同运行时，不同命运

Harness 演化到今天出现了路线分化。Pi、OpenCode、Codex、Hermes 四个开源项目共享 Agent Loop、Tool Calling、Context Assembly 的基本能力，却选择了不同的演化方向——不同路线交换的是成本、控制力、可恢复性和长期学习能力，选哪一种取决于 Agent 最终要进入怎样的真实环境（来源：四种Harness设计路线）。

（来源：四种Harness设计路线、从一次LLM调用到完整Harness）

适配矩阵很直接：短任务低成本选 Pi；多客户端协作、可审计选 OpenCode；高风险长任务选 Codex；个人长期助理选 Hermes。而"安全"在这套语境里有精确定义："安全不是模型答应会谨慎，而是执行路径中存在模型无法自行跨过的边界"——Q&A Bot 的错误结束在屏幕上，Coding Agent 的错误可能变成被覆盖的文件（来源：四种Harness设计路线）。

四组基准：把模型固定住，测 Harness 的差异

路线之争不靠理念，靠基准。2026 年前后出现的四组基准，从不同侧面量化了"换 Harness"的真实代价与收益：

（来源：从一次LLM调用到完整Harness、四种Harness设计路线）

其中 Databricks 那组数据是"agent = model + harness"公式最硬的实证：模型没换、推理强度没换，只换了 Harness，成本差两倍、上下文少三倍，质量基本不变。换句话说，你在 Harness 上省的每一个 token、少跑的每一轮循环，都是纯利。PAST-Bench 则从另一个方向补全了图景——当任务跨会话、要看"长期学习能力"时，重记忆、重归档的 Hermes 反而成为唯一全项正增益的框架。轻与重没有绝对优劣，只有与环境匹配与否。

1.5 阶梯之下：生产要素的重估

阶梯往上爬的同时，脚下的生产要素也在重估，这构成理解趋势的背景音。代码免费（Ryan Lopopolo/OpenAI）：实现已不再是软件工程的稀缺资源——代码免费产生、免费重构、免费删除，大规模重构"派 15 个 agent 就能收尾"；稀缺资源变成人时、注意力与上下文窗口，价值从"写代码"转移到"到达代码的 prompt 与 guardrails"。Token 亿万富翁：OpenAI 团队实测每天消耗超 10 亿输出 token，把 token 当资本驱动成百上千 agent，其中约三分之一花在 planning 与票证文档、三分之一在实现、三分之一在 CI——"写代码不再是难事，让代码被接受、让代码推进产品才是"。产品悬置（Boris Cherny）：模型今天已具备、但尚无产品让它表达的能力叫 product overhang；模型越强越不需要复杂脚手架，但越需要精心设计的 loop——实践建议是每 6 个月删掉你的 CLAUDE.md、skills、hooks 做一次 ablation（来源：代码免费、Token亿万富翁、产品悬置）。

这些判断共同指向同一个方向：当模型能力和 token 都趋于充沛，瓶颈移向了上下文与知识——模型看见什么、记住什么、按什么结构组织。这正是第二节知识库五范式要回答的问题。

§02 知识库五范式与两条路线

Five Paradigms of Knowledge Bases

上一节的结论是：AI 工程的瓶颈正在从模型移向知识供给。这一节展开知识供给的完整图景——五种知识库建设范式（Naive RAG、LLM Wiki、Graphify、GraphRAG、金字塔）对"知识应该如何组织"给出不同回答；两条供给路线（检索时拼接 vs 训练时内化）对"知识应该放在哪里"给出不同回答；而 OKF 开放知识格式的出现，意味着这些实践正在沉淀为可移植的行业契约。

2.1 五范式横向对比

先给全景表。五种范式在知识表示、积累能力、关联能力、层次感知、适合规模五个维度上各有取舍：

（来源：知识库建设范式对比）

Naive RAG：天花板不在检索，在结构

RAG 把知识库当作模型的"开卷考试参考书"：先检索、再拼接、后生成，全链路七步（文档解析→分块→向量化→索引→检索→重排→生成）。它工具链最成熟、改文档即生效、每句回答可溯源，高频变化的知识（接口参数、订单状态、工单）必须走这条路。但它有三个结构性缺陷：每次从零推导（无积累）、无法连点成线（只做语义相近匹配）、粒度混乱（设计原则与代码实现混在同一个向量空间）。Karpathy 的原话最狠："LLM 在每个问题上都从头重新发现知识，无任何积累。"只塞 chunk 而无分块策略、元数据、重排、评测的库，业内称之为"向量垃圾场"（来源：知识库建设范式对比、LLM_Wiki、RAG）。另一个容易被忽视的事实是：知识库失败案例中约 75% 是业务与工程流程问题——业务脱节、文件堆积、检索不准——技术不行反而是少数（来源：RAG）。

LLM Wiki：LLM 不只是检索者，而是知识的维护者

LLM Wiki 是 Karpathy 提出的范式，核心洞察是把 wiki 变成一个持续累积、持续编译的工件（persistent, compounding artifact）：交叉引用已建好、矛盾已标记、综合分析已反映所有已读内容。人类维护 wiki 从来都失败，因为"维护负担增长快于价值"；而 LLM 恰好擅长这些琐碎维护——"LLM 不无聊、不忘记更新交叉引用、一次能触及 15 个文件"（来源：LLM_Wiki）。

其架构是三层三操作：

（来源：LLM_Wiki）

局限也要说清：wikilink 支持自动与手动两种维护方式，但仍无自动关系推断与社区检测，适合约 500 源文档的中等规模。它解决的是 RAG 的第一缺陷（无积累），但尚未解决关联自动推断（Graphify/GraphRAG 的能力）与层次角色路由（金字塔的能力）。

Graphify 与 GraphRAG：把知识连成图

Graphify 走"代码即图谱"路线：AST 管道（tree-sitter）+ 语义管道（LLM），产出可交互的图与报告，特色输出包括 God Nodes、Surprising Connections、Knowledge Gaps；适合整个代码库规模的关联分析与缺口发现，但不擅长直接问答（"这接口参数是什么"）（来源：知识库分层编排、知识库建设范式对比）。

GraphRAG（Microsoft）用知识图谱 + 社区聚类（Leiden）+ 分层摘要，Global/Local 双搜索模式，解决"连点成线"与"全局理解"——多跳推理（"X 的供应商的子公司有哪些"）是纯向量做不到的。代价是构建成本极高：索引需数百次 API 调用、加新文档要重建整图（1000 篇可达数百美元）；简单事实查询上 vanilla RAG 持平甚至更好——"若 80% 的查询是 X 是什么，用 GraphRAG 是浪费"；还有 schema drift 风险（未验证 schema 胜率从 72% 掉到 48%）、多跳超 3 跳后 LLM 开始编造关系。生产环境的务实选择是 LightRAG 一类双索引 + 增量更新的轻量实现（来源：GraphRAG、知识库建设范式对比）。

金字塔知识库：层次与角色的结构化路由

金字塔范式（阿里内部实践）针对 RAG 的"层次缺失 + 角色不适配"：按稳定性与抽象度分五层——L1 原则（宪法级，年审）/ L2 架构（ADR，法律级，季度）/ L3 规范（规章级，月）/ L4 实现（手册级，周）/ L5 经验（判例级，天）。三个关键机制：7 种有向边跨层关联（governs/defines/constrains/implements/validates/feedback/cross_ref）；角色-层级访问矩阵，各角色独立 context 预算与优先序；分层结构化路由检索——先确定"去哪层找"再精确定位，纯本地、0 API 调用。实测 Pyramid+RAG 混合检索 Hit@3=89%，对比 Naive RAG 约 75%（831 篇源文档、200 QA pair、RAGAS 框架）（来源：金字塔知识库、知识库建设范式对比）。

2.2 两条路线：检索时拼接 vs 训练时内化

五范式之争发生在"知识放在库里怎么组织"这一层。再往上抽象一层，知识供给本身有两条根本不同的路线：检索路在查询时把知识拼进上下文，内化路在训练时把知识熔进模型权重。

内化路的代表是 Engram（2026 年 6 月发布，融资 $98M，顾问含 Karpathy 与 Pieter Abbeel）。它的赌注是：不再把训练算力砸在公共数据上，而是从强预训练模型出发、把算力花在"你关心的上下文"上——每个模型花相当于数百年的时间研读你的上下文：拼合事物、画出从未画出过的连接、发现被忽视的错误。这被称为"新的一维 scaling"。"今天的模型不懂你做什么——它们只在公开网上训练。"（来源：Introducing_Engram、上下文内化）

（来源：RAG与上下文内化对比、上下文内化、Introducing_Engram）

两条路线的关系，本库的判断很明确：互补而非替代——高频变化的知识（接口、状态、工单）必须走检索；低频稳定的知识（你是谁、你的项目、你的工作方式）适合内化。内化路的北极星是"一个能吸收任意量数据、持续变好的单一训练算法"，目前还没人做到；而它最大的软肋除了重训周期，还有失去"引用可追溯"这一工程资产（来源：RAG与上下文内化对比、上下文内化）。收束成一句话："载体是第二位的——躺在检索库里，还是熔进模型权重里，都行；为整理知识下的功夫，回报是确定的。"

2.3 OKF：把 LLM Wiki 变成开放契约

2026 年 6 月 12 日，Google Cloud 发布 OKF（Open Knowledge Format）v0.1，把 Karpathy 的 LLM Wiki 模式形式化为 vendor-neutral 的开放格式。它要解决的痛点很具体：模型越强、瓶颈越在上下文，而企业内部知识（表 schema、指标定义、runbook、API 废弃通知）散落在元数据目录、Wiki、代码注释、资深工程师脑子里，每个 vendor 各有一套互不相通的 catalog/SDK/schema——"每个 agent builder 都在从头解决同一个 context-assembly 问题"（来源：OKF、Open_Knowledge_Format）。

OKF v0.1 的形态刻意做到最小：一个 OKF bundle 就是一个 markdown 文件目录，每个文件代表一个概念（表/数据集/指标/runbook/API），文件路径即概念的唯一标识；顶部 YAML frontmatter（type/title/description/resource/tags/timestamp），正文自由 markdown。无压缩方案、无新运行时、无必备 SDK。三条设计原则：

（来源：OKF）

Google 同步发布了参考实现：扫描 BigQuery 自动起草 OKF 文档的 enrichment agent、单文件静态 HTML 可视化、三个样例 bundle（GA4 电商 / Stack Overflow / Bitcoin），规范与实现开源在 GitHub（GoogleCloudPlatform/knowledge-catalog）。此前社区已经摸出但互不相通的模式——Karpathy 的 LLM Wiki、Obsidian vaults、AGENTS.md/CLAUDE.md、index.md/log.md、"metadata as code"——第一次有了统一的交换格式。它的价值观写在设计文档里："价值来自多少人讲它，而非谁拥有它。"（来源：Open_Knowledge_Format、OKF）

§03 国家标准锚点

National Standards as Anchors

知识工程不只发生在企业私有库与 AI Agent 里。2026 年，GB/T 48000《标准数字化》系列国家标准的推进——尤其是第 3 部分用 OWL/RDF + SHACL 把"标准文献本身"建成可推理的本体——标志着知识工程正式上升为国家级规范基础设施。这一节讲清这项国家工程的构成、语义内核的设计，以及它对整个行业的锚定意义。

3.1 标准数字化：把标准从排版文档变成语义资源

标准数字化要解决的问题，一句话概括：让各类主体自主、规范地把"标准"这种知识载体从线性排版文档转化为机器可解析、可推理、可互操作的结构化语义资源。必须强调："标准数字化不是'把标准扫描成 PDF'，而是语义层面的数字化。"（来源：标准数字化）

它针对三类现实痛点：

这项工程已经标准化为 GB/T 48000《标准数字化》系列（全国标准数字化标准化工作组 SAC/SWG29 提出并归口），拟制定六个部分，目前已发布前四部分：

（来源：标准数字化、GBT48000.3标准数字化本体建模要求）

其中第 3 部分是整个系列的语义内核：它定义的标准本体用统一概念体系解决最硬的两条痛点（语义不一致、整合困难），是其余各部分得以语义对齐的基础（来源：标准数字化）。

3.2 GB/T 48000.3-2026：标准本体的解剖

GB/T 48000.3-2026（Standard digitization — Part 3: Requirement for ontology modeling，推荐性国标）把"标准文献"本身当作建模对象：用 OWL/RDF 把一份标准的元数据、结构、技术内容、制定程序拆成可机器解析、可推理、可互操作的概念网络。其核心组成 = 实体类型 + 属性（数据属性/对象属性）+ 公理，与本体五件套（类/属性/关系/公理/实例）高度同构（来源：标准本体）。

规模：18 类实体、34 项对象属性、三类公理

标准本体包含 18 类核心实体类型，按五大组组织；34 项核心对象属性（标准正文表 1，每项明确 Domain/Range/语义）；公理规则分三类（实体类型规则/属性规则/关系规则）。文件结构为 9 章 + 4 附录，附录 D 以 GB/T 31486-2024《电动汽车用动力蓄电池电性能要求及试验方法》为例给出完整的 OWL Turtle 实例化（来源：标准本体、GBT48000.3标准数字化本体建模要求）。

（来源：标准本体）

技术栈：W3C 语义网全家桶

一个精妙的设计细节：OWL 负责开放推断、SHACL 负责闭口校验——开放世界假设与闭世界假设在同一套标准里互补共存。SHACL 约束具体到什么程度？例如统一信用代码必须匹配正则 ^[A-Z0-9]{18}$；关系规则则包括"每个标准只能由一个机构发布"（功能性约束）、"实施日期 ≥ 发布日期"（日期有效性）、"章可含零或多个条，无标题条不可含子条"（层次结构约束）（来源：标准本体）。

精华设计："对象 → 特性 → 约束逻辑"三连

标准本体最有工程价值的设计，是把自然语言条款拆成可机读、可校验的结构链：对象 → 特性 → 约束逻辑。特性分三类——描述型（尺寸/颜色）、能力型（生产效率/兼容性）、约束型（环境温度/安全等级）；约束逻辑承载阈值、允许偏差与测量单位；再往后延伸出行动（动作/路径/判断条件）。以真实条款为例："电池单体初始容量应不低于额定容量且不超过 110%"——这句话被拆成对象（电池单体）、特性（初始容量，能力型）、约束逻辑（≥ 额定容量，≤ 110%），机器可以直接校验（来源：标准本体）。

术语口径与四象归属

两点口径需要交代。其一，标准本体以"实体类型 + 关系"为基本词汇，术语源自 GB/T 42131-2022《人工智能 知识图谱技术框架》——它是"用知识图谱友好的语言写成的语义本体"。其二，按本库的四象框架，标准本体属于语义本体，落在"静态 × 严谨"象限（认识世界 + 追求模型论语义）；其中"行动类（ActionClass）"是动态维度的萌芽，但它是被描述、被引用的静态对象，仍属"认识世界"，不跨入"改造世界"（来源：标准本体）。这个定位提醒我们：国家标准锚定的是语义层，行动层的本体（执行、门禁、审批）仍是企业与 Agent 系统自己的工程课题——本书 Part 3 将展开。

3.3 意义：知识工程成为国家级基础设施

为什么一份关于"标准怎么写成机器可读"的国标，值得放进一本知识工程绿皮书？因为它改写了知识工程的叙事层级。

过去谈知识工程，默认场景是企业为自己的 AI 应用建私有知识库。GB/T 48000 系列代表的是一种"自上而下"的知识工程范式：不是某个团队为某个 AI 应用建知识库，而是国家用标准的形式，为整个标准体系建立统一的语义底座。一旦标准本身可机读、可推理、可互操作，所有下游的合规检查、产品设计、检验检测、监管治理都能直接消费这套语义网络，而不必各自重新解析文档（来源：标准数字化）。

起草单位名单本身也说明这是一项跨产学研的国家工程：山东省计算中心（国家超级计算济南中心）、中国标准化研究院、同方知网、中国标准出版社、中国电子技术标准化研究院、浙江大学、南京理工大学等（来源：GBT48000.3标准数字化本体建模要求）。

放回全书的主线看，这个锚点的分量就更清楚了。本书反复论证一个判断：领域知识的形式化是确定性回报的工程投入——模型会迭代、工具链会更新、工作流会重构，但领域知识永恒。GB/T 48000 系列做的事情，用一句库内评语说，就是"把这句话写进了国家标准"（来源：标准数字化）。当语义本体在国家标准层面获得权威实证，企业级知识工程就不再是超前投资，而是与国家基础设施同频的确定性方向。

§04 四种本体

Four Kinds of Ontology

“本体（Ontology）”是本书的核心词，但它已经被过度重载了。《本体论实战2》把这个词切割成四种工程范式——它们各自自称“本体”，数据模型、形式化程度、核心操作与适用场景却截然不同。理解了这种切割，才算真正走进本体工程。

4.1 一条河流，四个分支

四种本体同源于 Gruber 的经典定义——“一个本体是对一种概念化的显式规约”，后经 Borst 补充“共享”“形式化”，由 Studer 等综合为“共享的概念化的形式化的显式规约”（来源：wiki“本体”）。从这个源头出发，像一条河流分出四个分支，从左至右呈现“形式化程度递降、操作语义递增”的梯度：

一句话概括范式差异：语义本体是“认识论工具”，告诉你世界是什么；Palantir 本体是“操作论工具”，告诉你下一步该做什么（来源：wiki“本体”）。而最大的坑，是把本体当同一个东西跨象限交流——讨论双方误以为说的是同一个“本体”，实则是两个不同范式，由此产生系统性设计偏差。

4.2 四种本体的技术本质

语义本体：世界是什么、什么恒为真

面向严谨工业标准规范的知识表示与推理型本体，属“逻辑推理”级别而非“表单校验”级别。核心机制是推理，数学基础是描述逻辑——一阶逻辑的可判定子集，保证推理算法一定在有限时间内给出确定答案。推理机做三类操作：一致性检查（有无 unsatisfiable 类）、类层次推理（自动补全 is-a 继承）、实例分类（来源：wiki“语义本体”“描述逻辑”）。

公理是机制的“燃料”。例如声明“涡扇发动机是发动机的子类（TurbofanEngine ⊆ Engine）”，推理机就能自动推出“凡通过适航认证的涡扇发动机，其配装机型自动合规”——这条知识从未被显式存储，是推理产生的。实证上，SNOMED CT 超 35 万医学概念基于 DL EL++ 用 ELK 做多项式时间分类；民航适航本体用公理替代人工查表，合规核查从平均每机型 2 小时缩至秒级（来源：wiki“语义本体”）。

技术栈：OWL/RDF、描述逻辑、SHACL、推理机（HermiT/Pellet/ELK）、Protégé。适用问题：医学术语标准化、语义互操作、法规合规推理。选型第一原则是“先定 DL profile 再选推理机——profile 选错是本体项目失败最常见的根因”。

知识图谱本体：实体之间怎么连

知识图谱的 Schema 层，“遍历型”本体，回答“从 A 出发，沿关系走几跳能到谁”。哲学根基是图论、CWA、结构主义。核心操作是多跳遍历、最短路径、社区发现、模式匹配——本质是遍历而非推理：只发现已显式存在的路径，不产生新知识（来源：wiki“知识图谱本体”）。

数据模型上，LPG 属性图的关系本身可携带属性，这是相对 RDF 三元组最大的结构性优势（无需 Reification/RDF-star）。存储选型的第一性原理是“查询模式决定选型，而非反过来”：亿级边内浅遍历用 Neo4j，百亿级边需水平扩展用 NebulaGraph，核心是深遍历与图算法用 TigerGraph。实证：金融风控“六跳关联链”拦截团伙欺诈，公安反诈资金回流环检测，生物医药 Drug→Target→Disease→Pathway 四跳药物重定位——共同点是“把散落孤立的线索织成网”（来源：wiki“知识图谱本体”）。

技术栈：LPG 属性图、Neo4j、Cypher/Gremlin/GQL，增强范式 GraphRAG / Text2Cypher。适用问题：金融风控关系网、推荐系统、反欺诈。

Palantir本体：业务怎么运转

“执行型”本体，不是 Semantic Layer 而是读写闭环的业务运行时——官方直接声明 “The Ontology is not a semantic layer.”，它代表的是“企业中的决策，而不仅仅是数据”。核心是四元对象模型 Object + Link + Action + Function，关键操作是“执行”：触发 Action 改变对象状态并写回源系统（来源：wiki“Palantir本体”）。

建模路径为 Object→Link→Function→Action→Interface→Workshop→执行 Action→Writeback 回流，构成四维闭环：数据（异构源映射为统一业务对象）→逻辑（Function 编码业务规则）→动作（Action 语义包装的业务操作）→安全（权限模型贯穿全链）。Writeback 是真假判据：“从未成功 Writeback 过一次源系统的 Ontology 是假的。”Writeback 有同步（<500ms、强一致）、异步（最终一致，配幂等键/重试）、批量（分钟到小时级）三种模式，原则是“能用同步就别异步、能用异步就别批量”（来源：wiki“Palantir本体”）。

技术栈：Foundry、OSDK、Workshop。适用问题：高价值运营决策、多源异构、强审计合规。实证：供应链断供应急调度闭环约 12 分钟；民航改航系统侧 90 秒完成；电网故障隔离转供电闭环 60 秒，替代人工 5-15 分钟。

Agent本体：Agent 该怎么做

面向 LLM Agent 的行为治理框架。它治理的不是确定性代码执行，而是非确定性 LLM 的决策过程与语义生成——一个“概率推理治理层”，核心价值在“防止越界”而非“表示知识”（来源：wiki“Agent本体”）。

核心机制是四层语义沙箱，设计哲学是先校验后执行：LLM 生成 proposal 不直接触达外部工具，先经四层校验，任一层 BLOCK 级违规即拦截整个 proposal：

Trace/Observability 贯穿全层，压执行不可追溯，可追溯覆盖率必须 100%。分工金句：“LLM 负责想、Harness 负责拦、Skill 负责做。”“LLM 可以‘忘记’规则，Harness 不会。”实证：民航维修工卡 Agent 从 CCAR-145 提取 28 条 MUST/MUST_NOT，查询效率提升 5 倍、安全警告遗漏率降 40%；金融投顾 Agent 合规违规推荐率从 15% 降到 0.3%（来源：wiki“Agent本体”）。

技术栈：JSON Schema、Function Calling、Guardrails、语义沙箱。适用问题：Agent 安全部署、工具治理、幻觉防护。

4.3 三个关键分水岭：为什么不可相互替代

四种本体不可相互替代，底层原因可以收敛成三个根本性分野。它们把十二维对比压缩成三条判据，逐层递进，用于快速判定一个自称“本体”的系统到底属于哪一种（来源：wiki“三个关键分水岭”）。

使用规则：判定一个本体必须三座分水岭逐条过一遍——先看核心计算原语，再看世界假设，最后看写入能力；只记一条会跨象限误判。误区警示有两条：“不要用图遍历替代逻辑推理”；OWA/CWA 只决定查询与否定语义，不决定是推理型还是遍历型——“世界假设”与“核心原语”常被混为一谈（来源：wiki“三个关键分水岭”）。

4.4 开放世界 vs 闭世界：本体与数据库思维的第一课

归属判据很干净：四象框架中只有语义本体走 OWA；知识图谱 Schema、Palantir、Agent 本体均走封闭世界——“严谨-务实轴背后，某种程度上就是 OWA 与 CWA 的分野”。实证：民航适航本体中，若机型未声明发动机，OWA 不会报错（只是未知），必须靠 SHACL 的 sh:minCount 1 才能闭口校验。两句口诀：“认清 OWA，是‘推理型本体’区别于‘数据库思维’的第一课”；“OWL 查逻辑冲突、SHACL 查数据缺失”（来源：wiki“开放世界假设”“闭世界假设”）。

4.5 本体五件套与六要素：建模构件与评价尺

本体五件套是一个完整语义本体的五个核心构件，构成从“概念设计”到“推理结果”的完整建模流水线（来源：wiki“本体五件套”）：

判据：“五者缺一不可：缺了任何一个，本体就退化为纯‘数据字典’，丧失推理能力。”工程分层上，概念+公理+约束进 TBox（相对稳定的术语层），实例进 ABox（频繁变化的断言层）。由此得到假本体识别判据：“‘建了一堆术语却没有推理’的假本体，本质就是缺了公理和约束这两件。”四种本体的构件体系各不相同：知识图谱 Schema 用 LPG 节点-关系-属性，Palantir 用 Object/Link/Action/Function/Interface 五构件，Agent 本体用约束规则+工具接口声明，语义本体五件套是形式化程度最高的一套（来源：wiki“本体五件套”）。

本体六要素则是评价一个“本体”项目实现程度的架构尺：Object 建模、Action 执行、Governance（权限/合规约束，如 Cedar/ABAC）、Audit（不可篡改审计，如哈希链）、推理引擎（可运行的类型/规则推理）、Agent 门禁（对 Agent/LLM 决策的硬约束闸门）。《本体论实战1》对 15 个开源项目做过源码级拆解，结论冷峻：“没有任何项目覆盖全部六个要素；OpenFoundry 以 4/6 领先（缺推理引擎与 Agent 门禁）”（来源：wiki“本体六要素”）。

三把尺子分工明确：真本体验证清单管“源码级、六项全过才算真本体”的工程可运行性；六要素管“架构维度覆盖了哪些能力”的体系完整度；四象框架管定位——三者配合使用（来源：wiki“本体六要素”）。

§05 四象框架与选型决策

The Four-Quadrant Framework & Selection

四种本体怎么定位、怎么选？四象框架是定位透镜，回答“这个项目属于哪一种技术体系”；选型决策框架是选型公式，回答“选哪种、怎么组合”；三位一体方法解决“怎么看清”——三个彼此独立的视角交叉验证。三者串起来，就是从看清到选定的完整决策链。

5.1 两个正交维度

四象框架是《本体论实战2》的母体框架，用两个正交维度把四种“本体”划入四个唯一象限（来源：wiki“四象框架”）：

• 静态-动态轴（根本目标轴）：“认识世界”只读表示 vs “改造世界”读写执行。静态的核心操作是查询与推理，动态的核心操作是变更与执行。
• 严谨-务实轴（取舍轴）：“理论正确”模型论语义——每句陈述有确定真假值、推理可被证明；vs “工程可用”——接受语义松弛，换取实现速度、查询效率与上手门槛。

使用步骤：把它当作诊断透镜而非选型公式——面对自称“本体”的系统，先问它在哪个象限（决定技术体系归属），具体“选哪种、怎么组合”交给选型决策框架。注意动态 × 务实象限同时容纳两个范式，光靠象限分不开，要下探到分水岭（来源：wiki“四象框架”）。

5.2 选型决策框架：先定问题特征，再倒推技术

选型决策框架的核心是判断“问题结构与核心计算原语是否匹配”，由五个部分组成：十二维对比矩阵、决策树、十六个典型场景匹配表、三种组合使用模式、四个常见误区（来源：wiki“选型决策框架”）。十二维矩阵覆盖核心命题、哲学根基、数据模型、核心操作、世界假设、推理方式、查询语言、写入能力、安全模型、典型工具、成熟度、适用团队，其关键结论是：“差异在底层哲学假设与核心计算原语，不在表面术语；每种本体在自己核心维度最强、其他维度刻意弱化；四种不可相互替代。”

决策树的用法是识别需求中的信号词——你的问题特征是什么，技术选型自己会浮出来：

决策树旁要标注两大错误导向：技术驱动而非场景驱动——先定技术再找场景，导致过度工程化或约束不足。十六个典型场景的分组速查：语义本体对临床术语标准化（SNOMED CT 的 OWL 本体）；知识图谱本体对反欺诈关联、航线网络、企业知识图谱；Palantir 本体对运行控制、供应链调度、订单全流程；Agent 本体对维修工卡、投顾、诊疗辅助、代码生成 Agent；组合场景如智能客服 = Agent 本体（行为约束）+ 知识图谱本体（知识走图谱）（来源：wiki“选型决策框架”）。

三种组合模式：组合是演进出来的，不是设计出来的

四个常见误区自查（来源：wiki“选型决策框架”）：

1. 用知识图谱替代一切——遍历 ≠ 推理，图节点承载不了 Action 状态机，图属性定义不了行为约束；
2. 混淆概念层级与实例关联——子类关系属 TBox、实例关联属图谱边：概念层用 OWL、实例层用图库、物化/映射桥接；
3. 忽视世界假设后果——OWA 上否定查询会遗漏、CWA 上期望推理完备会误判；
4. 过早追求全栈组合——应先验证单一本体的价值再逐步叠加。

5.3 三位一体方法：三视角交叉验证

选型之前还有一步“怎么看清”。《本体论实战1》第十三章给出、结语定性为“不随时间过时”的核心方法论——三个彼此独立、又可互相印证的分析视角（来源：wiki“三位一体_方法”）：

交叉验证有明确的产出规则。交叉点是高置信度共同结论：Ontology 驱动是下一代数据平台方向；治理（权限+审计）是核心支柱；Agent 治理是独立方向而非权限子功能；没有“一个项目搞定一切”的方案。分歧点需批判性思考：LLM 与 Ontology 的关系（可插拔 vs 融合）、图数据库是否必须自研（亿级开源够用、千亿级以上需自研）、通用平台 vs 垂直深耕、闭源 vs 开源标准（来源：wiki“三位一体_方法”）。

方法论工具链全景

把本节与上一节的工具串起来，是一条从看清到验收的完整链路：

其中四象框架与分水岭“互为表里”：前者宏观定位（往哪个象限放），后者微观判别（用哪条尺子量）；十二维矩阵是完整判据体系，三座分水岭是它的“速记子集”（来源：wiki“四象框架”“三个关键分水岭”）。落地验收还可以借用《本体论驱动》第三卷的“三张面孔”引入路径：先做语义锚点（2-4 周，验证治理意愿）→再做推理引擎（1-3 个月，验证领域建模能力）→最后上行动闸门（3-6 个月，验证组织保障）（来源：wiki“本体论驱动”）。

§06 人的位置

The Human Position

本体与选型解决“系统怎么建”，但方法论还有一条平行线：AI 为中心的软件工程范式里，人站在哪里。答案是四个机制——隐性知识蒸馏（知识从哪来）、二阶控制论与认知边界守卫（偏差谁来拉回）、双爬坡（能力怎么增长）、数据-知识-模型三角（钱先投哪里）。

6.1 隐性知识蒸馏：不能“问出来”，必须“逼出来”

隐性知识蒸馏是把专家脑中“知道但说不出来”的隐性知识（tacit knowledge），通过具体问题/场景驱动，从大脑中逐步蒸馏出来的工程过程。“这是 AI 为中心范式得以成立的关键门槛，也是整套理论里最难、最被低估、最具决定性的一关。”（来源：wiki“隐性知识蒸馏”）

为什么难？三重困难层层咬合：

• 专家自己都不知道自己懂什么。波兰尼说“我们知道的比我们能说出来的多”——能说出来的往往只有 10%，剩下 90% 要等具体问题碰到才涌现。“知识蒸馏在结构上比知识采集难一个量级——你不能‘问出来’，必须‘逼出来’。”
• 死循环。蒸馏需要“对的问题”，但“对的问题”本身需要领域知识才问得出来——AI 不懂领域，就问不出对的问题。
• 知识形态错位。蒸馏出的知识是场景化的（“在 Y 场景下应该怎么办”），而当前 RAG、知识图谱、向量库全是为陈述性知识（“什么是 X”）设计的——缺一个“场景化知识”的存储与检索范式。

破局的四个抓手，由近到远（来源：wiki“隐性知识蒸馏”）：

6.2 二阶控制论与认知边界守卫：AI 拉不回的偏差谁来拉回

哲学根基来自冯·福斯特 1970 年代提出的二阶控制论：一阶控制论是“观察并控制被控对象”；二阶控制论是“观察并控制‘观察并控制’这件事本身”。投射到软件工程：“经典软件工程：人在写代码；AI 软件工程：人在设计‘AI 写代码的系统’——这是身份的转变，不只是工具的转变。”（来源：wiki“二阶控制论”）

经典分层递阶控制假设“下层的扰动不会逆向传播到上层”，但 AI 系统会破坏这个前提：执行层 AI 能力突变会自下而上重塑上层目标；AI 的偏差会“涌现”，无法预先归因到某一层。因此架构需要两处修正：往上扩出一个哲学价值层（价值函数定义，不属于决策层）；在协调层增加横切机制（偏差归因/涌现监测/层级再划界）。

人的位置由此确定：人的统一职能是“处理系统暂无法处理的偏差”——偏差拉回者。“随着系统能力扩张，人从主回路退到边界监督位，但边界本身在扩大，需要守的人反而更多。”这个职能的具体化就是认知边界守卫——AI 时代最稀缺的能力，是处理 AI 拉不回的偏差；“人永远站在工程化边界外侧、专门处理系统暂时没办法处理的偏差”（来源：wiki“二阶控制论”“认知边界守卫”）。

为什么稀缺？经典工程的偏差可枚举、可观测、SOP 化；AI 工程的偏差不可枚举、信号隐蔽、需专家判断、且错误已扩散到下游。AI 不会自主追问——缺“主动开采知识矿”的能力，需要懂行的边界守卫来设判据，这正是隐性知识蒸馏的关键瓶颈。围绕这条边界长出一个岗位群：AI 产线架构师、认知 SOP 工程师、偏差检测工程师、AI 产线调优师、认知边界守卫，以及终极稀缺的产线设计师（定义分治结构）（来源：wiki“认知边界守卫”）。

6.3 双爬坡：AI 能力 × 工程框架成熟度同步爬坡

AI 软件产线的良率提升，依赖两个变量同步爬坡且互相加速（来源：wiki“双爬坡”）：

“这是个正反馈循环，但只在 AI 为中心架构下才能闭合。Copilot 架构下反馈被人这一环节切断，循环转不起来——这就是为什么‘人为中心 + AI 辅助’是弯路。”佐证数据：接入 Copilot 后编码速度提升 20-40%，但项目级 bug 率没明显下降，review 工作量反而上升——“这不是‘AI 不够强’，而是 Copilot 模式本来就不是为消除不确定性设计的”（来源：wiki“双爬坡”“Copilot模式与AI为中心对比”）。

爬坡单位也有讲究：逐节点替换的路线，爬坡单位是节点——每个节点局部优化、整线没人管；闭环优先+节点开放的路线，爬坡单位是回路——整线良率持续爬坡。配套资产“偏差案例库”就是团队积累的领域知识：模型能力是厂商迭代的，工程框架和领域知识才是团队自己攒下来的。

6.4 数据-知识-模型三角：投入优先级

资源有限，先投哪里？三角关系给出了明确排序——“三者不是并列关系，数据是乘数、优先级最高、最先投入”（来源：wiki“数据与知识模型三角”）：

隐含的范式转移：从“模型中心”（数据给定、优化模型拟合数据）转为“数据中心”（模型给定、优化数据提升模型）。金句定性：“‘数据质量 > 模型能力’是 2024-2026 最大的范式转移：所有人都用 Llama/Qwen/DeepSeek 级开源模型时，模型不再是壁垒，数据与知识的组织和质量才是。”动态机制上，数据飞轮是三角关系的运行方式，让数据持续复利（来源：wiki“数据与知识模型三角”）。

知识侧的投入同样有结构判据：知识分层维度取决于“谁在消费知识”，三种切法（按共享范围、按稳定性×抽象度、按问题层次）不互斥，可以同时用；知识库范式上“RAG 的天花板不在检索，在结构”，实测 Pyramid+RAG 混合 Hit@3=89%，而 Naive RAG 约 75%（来源：wiki“三种知识分层方案对比”“知识库建设范式对比”）。

§07 知识工程平台五层架构

Five-Layer Platform Architecture

一个知识工程体系应该长成什么样、每一层该用什么技术、由谁负责？五层架构把零散的工程工具串成一条可运转、可治理的流水线，回答"平台长什么样"；三种平台模式回答"怎么搭"。五层是骨架，模式是路径。

7.1 从采集到应用：五层一条流水线

"模型是气缸，架构是传动，数据与知识库是燃料。"大量 RAG 项目上线即翻车、知识库建了三个月没人用——失败往往不在架构层，而在数据层（来源：本体论实战3）。要让燃料稳定供给，就需要一条从采集到应用的全链路基础设施。知识工程平台五层架构正是这条链路的坐标系：L1 采集 → L2 存储 → L3 加工 → L4 知识 → L5 应用，外加四条贯穿五层的横切治理线（来源：知识工程平台五层架构）。

四条横切线不是某一层的功能，而是每层都必须遵守的治理规则：数据卡管质量、权限管安全、审计日志管合规、成本计量管资产（来源：知识工程平台五层架构）。判断一个团队是否"已经建成平台"，五层架构就是坐标系——每一层有没有明确的技术选型、有没有明确的负责角色、有没有贯穿的治理规则。

7.2 三种平台模式：从轻到重的四档投入梯度

五层定义了平台的目标形态，三种平台模式定义达成它的投入梯度与先后顺序。有意思的是，"三种模式"实际列了四档（A/B/C/D），共同点是"从轻到重、从验证价值到打造资产"（来源：三种平台模式）。

表 7-1 四档平台模式对比（来源：三种平台模式）

升级之后值不值？要回到三本账去算总账（见 §09.6）。"五层是'长什么样'，三种模式是'怎么搭'，三本账是'花多少钱'，21 天最小 DataOS 是'三周怎么落地'——四者互为表里。"（来源：三种平台模式、三本账、21天最小DataOS）

§08 知识库分层与索引

Knowledge Base Layering & Progressive Indexing

RAG 的天花板不在检索，在结构——"知识被当成'一袋词'，而工程知识是'一棵树 + 一张图'"。本节给出三个团队独立实践出的三套知识分层方案、一套三级渐进式索引机制，以及"哪些知识值得写进知识库"的筛选判据。分层维度取决于"谁在消费知识"。

8.1 为什么必须分层：RAG 的三个结构性缺陷

Naive RAG 把文档切块、向量化、平铺检索，有三个结构性缺陷：每次从零推导——Karpathy 的原话是"LLM 在每个问题上都从头重新发现知识，无任何积累"；无法连点成线——只做语义相近匹配；粒度混乱——设计原则与代码实现混在同一个向量空间（来源：知识库分层编排）。金字塔知识库一文给出的目标画面是："程序员问一个问题，AI 在 3 秒内返回正确层次、正确角色、正确关联的答案——而不是 5 段不相关的文本。"

解法不是换更大的模型，而是给知识分层。三个团队各自独立实践出三套分层方案，切分维度完全不同，却互为镜像（来源：三种知识分层方案对比）。下面逐一拆解。

8.2 知识库四层分层：按"解决哪一层问题"拆

后端系统 AI Friendly 的四层分层（刘瑞洲实践），把系统知识按"解决哪一层问题"拆成业务、架构、系统、基建四层，让 AI 在正确场景取到正确内容，并且每层都有"事实 + 约束 + 验证"三件套（来源：知识库四层分层）。

表 8-1 知识库四层分层（来源：知识库四层分层、后端系统AI知识库体系建设实践）

关键认知：知识库不是"搜索答案的资料库"，而是贯穿需求理解 → 现状分析 → 方案设计 → 编码执行 → 验证测试 → Review 交付的系统上下文。其中技术方案设计是最关键的放大点——AI 执行速度快、默认"忠实执行"而非"质疑方案"，方案错了会变成高效返工（来源：知识库四层分层）。

8.3 金字塔知识库：按稳定性与抽象度分五层

金字塔知识库（阿里内部实践）为解决 RAG"层次缺失 + 角色不适配"而生：把知识按稳定性与抽象度分为 5 层，加图关联，再加角色感知的检索层（来源：金字塔知识库）。

三个关键机制：一是 7 种有向边支持上溯、下探、反馈环与预定义阅读路径（如新人 Onboarding 走 L1→L2→L3→L5）；二是角色感知——角色-层级访问矩阵，不同人看不同层，各角色有独立 context_budget 与 priority_order；三是分层结构化路由检索——先确定"去哪层找"再精确定位，纯本地、0 API 调用，替代"从所有文档里找最像的"（来源：金字塔知识库）。

它不是替代 Naive RAG / LLM Wiki / Graphify / GraphRAG，而是在顶层加一个结构化的导航与路由层——19 篇分层文档是 831 篇源文档的"索引+摘要+导航图"。实测（831 篇源文档 / 200 QA pair / RAGAS 框架）：Pyramid+RAG 混合 Hit@3=89%，优于 Naive RAG 的约 75%，尤其在代码细节、运维排障、架构概念、导航维度（来源：知识库分层编排）。

8.4 三级渐进式索引：让 Agent 按需查阅，而非被动推送

分层解决"知识放在哪"，索引解决"Agent 怎么找"。三级渐进式索引源于 Karpathy 的 LLM Wiki Pattern，用于在"知识不被淹没"与"上下文不膨胀"之间取平衡（来源：三级渐进式索引）。

8.5 三种分层方案对比：切法不同，互为镜像

表 8-2 三种知识分层方案对比（来源：三种知识分层方案对比）

三套层可以互相翻译：金字塔 L1 原则 ≈ 后端基建层规范 ≈ AI Team Layer 0-T 团队约定（宪法级、低频变更）；金字塔 L2 架构 ≈ 后端架构层；金字塔 L4 实现 ≈ 后端系统层；金字塔 L5 经验 ≈ 后端历史实践 ≈ AI Team pitfall 类型；AI Team Layer 2 业务知识 ≈ 后端业务层（来源：三种知识分层方案对比）。

四条共同设计值得抄作业：分层即检索优化（先确定去哪层找再精确定位，是三级渐进式索引的推广形式）；层间需要边（金字塔用 7 种有向边，后端四层用"业务→技术链路"映射，AI Team 用知识"向上提升"）；不同层不同保鲜周期（越塔顶越稳定年审，越塔底越要天级更新）；都有知识提升机制（项目内验证的知识，跨项目通用后提升到更高层——知识复利的结构化实现）。

8.6 写什么进知识库：高复用、高风险、高隐性

"AI Friendly 不是文档越多越好。大量低价值文档反而干扰 AI 判断、消耗上下文。"判断哪些知识值得显式化，看三特征（来源：高复用高风险高隐性）：

• 高复用：被多个需求/系统/团队反复使用——公共 API、核心领域对象、通用流程、下游依赖、测试策略。
• 高风险：改错后果严重——交易状态机、支付流程、资金对账、权限系统、核心表、MQ schema、风控策略。
• 高隐性：代码里看不出来、难稳定推断——历史兼容原因、线上事故教训、审批规则、组织红线、特殊业务约束。

其中"高隐性"最关键：这些知识是规范性的（not descriptive），不存在于代码中，只存在于人脑、团队约定、事故复盘或分散文档里——"这个 API 字段是公司级红线不能删除""修改状态机必须人工审批"。没人显式化，任何模型都推断不出。一句话："模型再强，也无法推断不存在的信息。"（来源：高复用高风险高隐性）

§09 数据工程流水线

Data Engineering Pipeline

"Garbage in, garbage out 是 AI 第一定律。"数据工程是数据的"采-洗-存-通"端到端基础设施工程实践，类比自来水厂——从水源到水龙头。本节给出六步工程化流程、八维质量模型、评测体系与 LLM-as-Judge、数据飞轮闭环、三本账成本框架，以及数据卡与语义化版本两个资产化规约。

9.1 采-洗-存-通：加工层的定位

数据工程的核心矛盾是"数据的规模与异构性远超处理能力"。它覆盖数据管道全链路——采集、清洗、去重、转换、存储、版本管理、血缘追踪；典型工具栈：预处理 Datatrove/Dolma、版本管理 DVC/LakeFS、质量校验 Great Expectations、调度编排 Airflow/Dagster。产出是可复用、可追溯、质量可控的数据资产（来源：数据工程）。

两条关系要辨清：数据治理是制度层、数据工程是加工层——"一个修管道、一个立交规"，不可混同；数据工程与知识工程的本质区别是"记录 vs 意义"——数据工程管记录，知识工程提炼意义（来源：数据工程、知识工程）。"高质量数据集是'制造'而非'发现'的核心资产，数据质量是被乘数"，投入优先级：数据 → 知识 → 模型（来源：本体论实战3、高质量数据集）。

9.2 六步工程化流程：把"造数据集"变成工程产品

数据集从需求到发布走六步流水线，每步对应一个产出物（来源：数据集工程化流程）：

9.3 八维质量模型：把"高质量"从口号变成可计算指标

八维质量模型木桶原理："任一维度不及格，资产整体不可用。"每维有可计算代理指标（来源：八维质量模型）：

表 9-1 八维质量模型速查（来源：八维质量模型、三分类框架、数据卡）

投入决策按"用途杠杆"而非"数据量"分配：进入生产应用 → 八维全检 + Golden Set 门禁（质量投入占比 30% 以上）；用于微调 → 只检 D1/D6/D7；用于预训练语料 → 统计指标 + 抽样审计。"按用途杠杆分配质量投入，才能把钱花在刀刃上。"（来源：八维质量模型）

9.4 评测体系与 LLM-as-Judge

"评测体系的可靠性决定优化的天花板——没有可信的评测，一切'改进'都只是自我感觉。"评测拆成三层：指标 = 尺子（RAGAS 四维、忠实度、准确率、采纳率）；测试集 = 测什么（Golden Set 金标准）；流程 = 何时测（上线前门禁、CI、每季度抽审）。任一缺失都会让整个体系失效。工程建议顺序：先建测试集（1-2 周）→ 定指标（1 周）→ 接流程（随 CI）。"测试集是最贵的资产，越早投入越好。"（来源：评测体系）

RAGAS 四维各对应一种故障：忠实度 → 幻觉；答案相关性 → 答非所问；上下文相关性 → 召回漂移；上下文精度 → 重排失效。排查顺序：上下文相关性 → 精度 → 忠实度 → 答案相关性（来源：评测体系）。

Golden Set 是"问题 + 标准答案 + 检索依据 + 评分要点"的人工构建样本——"金标准不是'完美答案'，而是'有共识的答案'"。构建五步：定义问题域 → 难度分层（简单 40% / 中等 40% / 困难 20%）→ 双人独立 + 仲裁（IAA 数据来源）→ 标注检索依据 → 封锁与轮换（永不公开、永不进训练语料、MinHash 防泄漏、季度轮换 10-20%）。规模：起步 300-500 题、成熟 1000-2000 题；"500 道精标胜过 5000 道模型生成"（来源：评测体系）。

LLM-as-Judge 与三种"分数游戏"：① 评测集污染——公开基准进训练语料，分数虚高 10-30%，防御靠私有 Golden Set + MinHash 检测 + 公共基准打折看；② Judge 偏差——LLM judge 偏爱长答案、偏爱自己风格、对数字不敏感，防御靠盲评 + 轮换 + 人工校准 + 异厂商裁判；③ 指标游戏——为单一指标优化导致反指标崩坏，防御是任何单指标提升都要伴随"反指标"监控。"评测的价值在'一组指标互相制衡'，而非某个漂亮分数。"（来源：评测体系）

9.5 数据飞轮：从一次性工程到持续工程

"飞轮不是可选项，而是必选项——没有回流闭环，知识库第 3 个月开始腐烂。"数据飞轮是"数据 → 模型 → 应用 → 更多数据"的正反馈闭环（来源：数据飞轮）。

五种停转模式要贴墙上：反馈无归因、合成数据未过滤、评测集污染、版本不可回滚、飞轮转太快。对应五条纪律："自动化不能替代纪律：反馈要归因、合成要过滤、评测要独立、版本要可回滚。"合成数据是规模放大器也是模型崩塌风险源——"永远不要用合成替换真实数据，采取累积策略，真实数据作锚点"（来源：数据飞轮、数据合成、模型崩塌）。"飞轮把数据资产从'三个月保质期'变成'持续增值'，是知识工程长期竞争力的来源。"

9.6 三本账：搭与养到底花多少钱

"不能用'买软件花了多少钱'这一本账，而要用建设、运维、风险三本账。"（来源：三本账）

表 9-2 三本账，成熟项目经验比例约 4:4:2（来源：三本账）

"自建 vs 采购"要用三本账齐算，"结论会从'谁便宜'变成'谁的总成本与风险可承受'"。三本账与选型决策框架的"资产层/能力层/工具层"三层决策互补——三层决策告诉你哪一层的自主权该自持，三本账告诉你每一层到底花多少。预算纪律上，评测预算优先保护："评测是唯一能让其他预算'不白花'的预算。"（来源：三本账）

9.7 数据卡与语义化版本

数据卡是"记录数据集来源/构成/用途/局限的结构化文档"，类比数据资产的出厂合格证：基本信息（名称/版本/创建日期/许可）、数据来源（采集方式/原始来源/授权链）、处理管线（可复现步骤 + 参数）、质量记分卡（八维评分 + 证据链）、已知偏差、变更日志。两条红线：评测污染（Golden Set 混进训练语料，n-gram 重叠 0.8 相似度即命中）；未授权来源（合规维度 0 分一票否决）。"数据卡的价值一半在写、一半在写的过程倒逼出的工程纪律。没有数据卡，数据资产无法交易、无法审计、无法防止评测污染。"（来源：数据卡）

语义化版本（SemVer）把版本管理规范化：major = 数据源变化（换数据源或大改采集口径）；minor = 规则变化（清洗规则调整）；patch = bug 修复。"只在 major 版本做全量评测，使版本升级成本可预期。"版本工具选型：DVC（Git for data，GB-TB，最轻量，小团队 + Git 首选）、LakeFS（对象存储层的 Git，零拷贝版本化，TB-PB 企业首选）、Pachyderm（K8s 容器化管道 + 血缘，注意被 HPE 收购的风险）、HuggingFace Datasets（共享/加载平台，不是版本控制）。常见坑：版本混乱导致下游结论无法对账、把 HF Hub 当版本控制、只做一次——"数据集是持续资产，应配合数据飞轮持续回流更新"（来源：数据集工程化流程）。

§10 21 天最小 DataOS

21-Day Minimal DataOS

从 docker-compose 到端到端闭环的实战开发指南。目标不是搭建 Palantir Foundry 全家桶（那需要 50 人年工程量），而是用三周搭一个能跑通完整闭环的最小系统：定义 Object → 执行 Action → 门禁校验 → 审计追溯。"它不是一份评审报告，而是一份可照抄的开发手册。"（来源：21天最小DataOS）

10.1 五组件与六层架构

最小 DataOS 按"六要素各取所长、用自研集成层拼装"的开源路线搭建，五个组件各司其职（来源：21天最小DataOS）：

表 10-1 五组件；六层 = 存储 / 对象 / Action 执行 / 权限 / 门禁 / 审计（来源：21天最小DataOS）

一次转账请求的穿透路径把六层串起来：请求 → 权限校验（无权 403 拦截）→ 门禁校验（超限 422 / 自转账 422）→ 执行（Temporal 幂等）→ 审计落链。四层延迟模型是 Action 执行层选型的理论基础——热路径用内存/数据库、冷路径用 Temporal Saga（来源：21天最小DataOS）。

10.2 三周路线图

10.3 交付清单与三周后验收

全程配套 8 个可直接复制的文件：docker-compose.yml、init.sql、schema.tql、main.go、transfer.go、bank.cedar、hashchain.go、transfer.yaml；以及 8 个全链路测试用例，覆盖存储层（类型校验/唯一约束）、权限层（403）、门禁 L2（超 100 万分 422）、门禁 L3（自转账 422）、执行层（正常 200 / 幂等）、审计层（哈希链可验证、篡改检测）（来源：21天最小DataOS）。

三周后五步总验收：建 Object 通过 TypeDB 类型校验；执行转账由 Temporal 保证幂等与可恢复；转账前 Cedar 校验权限；转账后 HugAgentOS 门禁校验；所有操作写入哈希链审计且可验证。

§11 Palantir 与生态图谱

Cases: Palantir & the Ecosystem

Palantir Foundry 是全书技术判断的参照系：国内"本体平台型"厂商均以它为对标，15 个开源项目却无一完整复刻。本节压缩呈现三件事——Foundry 三层架构精要、Ontology 四要素、开源生态的技术基因速览，并给出"开源拼装 vs 全家桶"的选型判断。

11.1 Foundry：本体驱动的企业操作系统

Palantir 以美国情报界起家，把多源异构数据融合为可操作情报，产品化为 Gotham（军工/情报）、Foundry（商业企业平台）、AIP（2023 年推出，把 LLM 锚定在 Ontology 上）三大平台，底层由 Apollo 部署基础设施支撑。Foundry 的官方定位是 "Ontology-Powered Operating System for the Modern Enterprise"——本体驱动的现代企业操作系统。它的核心竞争力不是算法，而是"组织级数据到可操作决策"的完整基础设施；护城河也不在架构本身，而在多年累积的行业 Object 类型库、数千 Action Type 模板，以及 FDE 驻场打磨的实施方法论。（来源：Palantir、Palantir_Foundry、FDE_方法论）

11.2 三层架构精要

官方表述是 "One Ontology. Three Layers of Capability."。要注意：三层是循环依赖（Semantic → Kinetic → Dynamic → Semantic）而非上下叠加的金字塔。数字孪生的比喻很贴切——语义层是骨架、动力层是肌肉、动态层是大脑。（来源：Semantic_Layer、Kinetic_Layer、Dynamic_Layer）

名词层（Semantic Layer）构成组织的静态图谱，回答"业务中到底存在什么"：有哪些业务实体、什么属性、什么关系。关键要素是 Object Types（语义层基石）、Properties、Link Types、Interfaces（多态抽象）与主键。它是"操作层"与"知识图谱/数据库"分水岭的起点——传统语义本体只解决读/查询，Palantir 把语义层与动力层结合，完成从"读"到"写/操作"的跃迁。（来源：Semantic_Layer）

动词层（Kinetic Layer）把 Ontology 从语义层升级为操作层：Action Types 是本体的"写端"，Functions 承载实现逻辑，配套 Submission Criteria（执行前业务前置条件校验）、Side Effects（通知/Webhook）与跨系统写回治理。它是本体区别于传统知识图谱的根本——没有它，本体只能"看"不能"做"；也是三级闭环中唯一的"执行引擎"。（来源：Kinetic_Layer）

决策层（Dynamic Layer）是决策引擎而非执行引擎：模型直接作用于 Ontology 的对象与动作，执行前先仿真、先评估、先学习，再给出最优行动建议。四个子系统中最有价值的是 Decision Capture & Learning——每次决策作为带完整血缘的新数据被捕获、反馈给 AI/ML，这是 Palantir 最难也最有价值的闭环能力。动态层也是开源生态最大的缺口：几乎没有开源项目能完整复现。（来源：Dynamic_Layer）

11.3 Ontology 四要素：Data / Logic / Action / Security

Ontology 定义了一种协议，让系统把自己的业务对象、属性、关系、动作和权限以统一方式暴露出来。每一次运营决策都被建模为四要素：（来源：Ontology四要素）

官方总结：Ontology 把四要素汇聚为企业"以决策为中心"的模型，可供人类与 agent 共同使用。（来源：Ontology四要素、Palantir_Foundry官方文档中文版）

11.4 15 个开源项目：技术基因速览

《本体论实战1》源码级筛选的 15 个项目里，只有 5 个够得上"真本体"（Semantica、TypeDB、OpenFoundry、HugAgentOS、agentic-redux），6 个是 borderline，其余为空壳或误标；打分最高的 OpenFoundry 也只拿到六维里的四维——"单点称霸在这个领域目前根本不存在"。（来源：真本体验证清单、六维评价模型）

注：六维 = 实现深度 / 架构完整度（本体六要素覆盖率）/ 工程质量 / 对标 Palantir 特征 / 可独立运行 / 社区活跃度。三个隐藏洞察：已实现 ≠ 生产可用；分数低 ≠ 没价值；组合不是简单加法。（来源：六维评价模型、技术基因图谱、真本体验证清单）

11.5 开源拼装 vs 全家桶

15 个项目分属五条血统（Palantir 复刻线、执行底座线、Agent 治理线、语义推理线、元数据线），没有一个能单独复刻 Foundry——"你选的不是一个项目，而是一条血统里的一个角色"。因此可行的开源路线是按架构要素分别选型再用自研集成层拼装：Object 建模选 TypeDB、Action 执行选 Temporal、权限治理选 OpenFoundry + Cedar、全链路审计选 OpenFoundry 哈希链、推理引擎选 Semantica、Agent 门禁选 HugAgentOS。集成层必须干四件事——ObjectID 统一映射、动作事件总线广播、权限策略对所有组件一致生效、所有操作自动记入审计链；它不是简单的 API 网关。成本账：自建开源 3 年 TCO 约 400-600 万，全家桶 2000-3000 万外加千万美元级/年 License 与 3-6 个月起步的 FDE 驻场。但钱补不上的那块是"人"：复刻 Foundry 需要 50 人年工程量之外，再加"怎么把一个行业的业务逻辑转化为 Ontology"的隐性知识壁垒。（来源：开源拼装_vs_全家桶、技术基因图谱、FDE_方法论）

11.6 国内厂商一瞥

国内五家代表厂商分两类："本体平台型"（中国电子云、国投智能、海致科技——自上而下先建本体模型，再补数据层与 Agent 层）与"本体+智能体型"（滴普科技、明略科技——自下而上先有 Agent/图谱，再补语义层）。共性背景是信创双刃剑：涉密与自主可控的天然市场，但封闭性可能使技术迭代慢于商业市场。集体短板有二：一是 Agent 本体治理——只有海致科技以"权限层 + 审议层"显式对标（并有 10 亿+ 节点金融反欺诈图谱的实证）；二是均未形成可复制的 FDE 方法论，交付能力靠资深工程师个人经验，是线性的而非指数的——谁先沉淀方法论谁就能规模化。（来源：中国电子云、国投智能、海致科技、滴普科技、明略科技、FDE_方法论）

§12 领域本体与规则引擎

Cases: Domain Ontology & Rules Engines

如果说 §11 展示的是"改造世界"的执行本体，本节两个案例属于"认识世界"的语义本体：民航适航本体用推理替代人工查表，标准本体把国家标准本身建成语义底座。随后给出规则引擎五大表示范式对比、LLM-规则混合架构的分工红线，以及契约式 AI 的裁决闸门管线。

12.1 民航适航本体：用推理替代人工查表

问题：民航适航合规判定长期依赖人工逐表比对，每个机型平均耗时 2 小时；规则藏在专业规章制度文本里，靠审查员记忆和查表执行。建模（OWL 2 DL）：概念层定义 Aircraft / Engine / TurbofanEngine / TurbopropEngine 四个类，对象属性 hasEngine、certifiedFor 表达关系；核心业务公理是"凡通过适航认证的涡扇发动机，其配装机型自动合规"——把规章制度里的隐式规则显式化为公理；再用 SHACL 做闭世界数据校验（maxSpeed ≥ 0、hasEngine ≥ 1）。推理：当新型发动机 LEAP-1A 被声明为 TurbofanEngine 并获得认证后，推理机自动判定所有声明了 hasEngine LEAP-1A 的机型（如 A320neo）合规，无需人工逐条比对。边界情形也有分工：机型未声明发动机时，开放世界假设下 OWL 不报错（未知≠假），但 SHACL 会标记违规——OWL 查逻辑冲突、SHACL 查数据缺失。效果：合规核查从每机型 2 小时缩短为秒级输出，判定覆盖 100%，且结论可追溯至公理。（来源：民航适航本体、推理机）

12.2 标准本体：GB/T 48000.3-2026

标准数字化 = 让"标准"从线性排版文档转化为机器可解析、可推理、可互操作的结构化语义资源。GB/T 48000《标准数字化》系列拟六个部分，第 3 部分"本体建模要求"（GB/T 48000.3-2026）是整个系列的"语义内核"。它定义了三类构件——实体类型（≈类）、属性（数据属性 + 对象属性）、公理（不可被违反的逻辑约束），并要求用 W3C 语义网技术栈形式化：OWL/RDF/RDFS 描述、Turtle/JSON-LD 序列化、SHACL 约束验证（如统一信用代码正则 ^[A-Z0-9]{18}$）、全球唯一 IRI 标识。核心内容是 18 类实体类型（分核心节点/元数据/结构/技术内容/制定程序五大组）与 34 项对象属性（每项明确定义域、值域与语义）。最精华的设计在技术内容组：把"电池单体初始容量应不低于额定容量且不超过 110%"这类自然语言条款，拆成"对象 → 特性 → 约束逻辑"的可机读语义链；公理层则固化了"实施日期 ≥ 发布日期""每个标准只能由一个机构发布"等规则。它的上位意义是：知识工程不只服务企业私有知识库，也在重塑国家级公共知识资源的组织方式——一旦标准可机读、可推理、可互操作，下游合规检查、产品设计、检验检测、监管治理都能直接消费这套语义网络。（来源：标准本体、标准数字化、GBT48000.3标准数字化本体建模要求）

12.3 规则引擎五大表示范式

所有规则表示共享同一内核——"前提 → 结论"的蕴含式，差别在表现力、可推理性、可维护性三维取舍。规模判据：规则超过 50 条，if-else 维护成本超过规则引擎引入成本；超过 500 条必须上规则管理平台（冲突检测、版本管理、灰度）。（来源：规则表示范式、规则推理引擎）

选型口诀：业务人员自维护→决策表；通用风控/校验→产生式；类层级推理→SWRL；多跳关系网络→图模式。大多数场景 DRL + 决策表混合是最佳实践，且决策表必须留兜底行——最后一行永远是"任意→转人工复核"。（来源：规则表示范式、产生式规则、决策表）

12.4 LLM-规则混合架构：分工而非替代

核心论断：LLM 归纳（从模式到概率），规则演绎（从规则到必然）。分工是裁决权级的——"做什么"（意图/目标）是开放世界的语义理解问题，LLM 有建议权；"怎么做才算合规"（约束满足）是封闭世界的可形式化问题，规则引擎有否决权。因此 LLM 只在离线环节出现：翻译法规为规则草稿、审计规则库漏洞、生成解释文本；在线推理环节 LLM 不参与。这条红线的工程依据很硬：把合规约束放进模型权重，等于让约束经历"模型是否记住了"+"模型这次是否想起来了"两层不可靠叠加——长对话中 LLM 遗忘 prompt 约束指令的比例可达 15-20%。LLM 可以"忘记"规则，Harness 不会。一句话分工：LLM 负责"想"、规则引擎负责"判"、Harness 负责"拦"。（来源：LLM-规则引擎混合架构、规则推理引擎、十条实践红线）

12.5 裁决闸门：五道确定性校验管线

契约式 AI 把"什么能做、什么不能做、做了有什么代价"显式化为可被确定性代码校验的声明式契约。Agent 每次真实动作执行前，都要过五道不可绕过的闸门，任一不过即拒绝并返回带证因的拒绝理由（如"违反第 4 条预算公理：总额 2,340 万 > 上限 1,500 万"），驱动 LLM 重新规划或向用户解释，而不是静默放过。（来源：契约式AI、裁决闸门）

§13 Agent Harness 四项目实证

Cases: Four Agent Harnesses

Pi、OpenCode、Codex CLI、Hermes 共享 Agent Loop、Tool Calling、Context Assembly 的基本能力，却选择了四条不同的演化路线。分工命题一句话说清：Agent 决定下一步做什么，Harness 决定这一步在什么上下文、权限、生命周期与持久化规则下发生。（来源：从一次LLM调用到完整Harness、四种Harness设计路线）

13.1 四条设计路线对比

路线之间没有优劣，只有交换："不同路线交换的是成本、控制力、可恢复性和长期学习能力"。Pi 与 Codex 构成两极——前者默认继承启动用户权限、靠外部沙箱补边界，后者把"安全不是模型答应会谨慎，而是执行路径中存在模型无法自行跨过的边界"做成产品命题，这与 §12 裁决闸门"先校验后执行"的哲学同构。Hermes 则把问题往后推一步："Agent 第二次遇到类似任务时，能不能少走一遍弯路"——自我改进 = 在模型外部维护一层会随使用逐渐变化的认知系统。（来源：Pi、Codex_CLI、Hermes_Agent、四种Harness设计路线）

13.2 Harness 演化六阶段

今天的 Agent 系统像一套小型操作系统，但复杂性不是一次设计出来的——每当模型试图越过一次调用的边界，系统就必须在模型外面补一个新部件：（来源：从一次LLM调用到完整Harness）

13.3 基准硬数据

三组基准给出了"Harness 本身就是变量"的硬证据。第一组，Composio（30 个 Agentic Tasks，同一个 DeepSeek V4 Flash 分别放进四套 Harness）：Pi 通过率 66.7%、中位任务成本 $0.012——完成最多、花费最少。第二组，Databricks 内部基准（数百万行真实代码库的 PR 构造任务）：同模型同推理强度换到 Pi，质量基本不变而单任务成本相差两倍以上；追踪发现原因是 Pi 每轮送入的上下文约少三倍——"极简不是代码审美，直接变成任务成本和执行效率"。第三组，OpenBench（2026.7，同一 gpt-5.6-sol × 7 套 Harness、42 个共同任务）：Codex 完成 31 个（73.8%），但中位耗时 94.6 秒、每成功任务平均 117,107 新 token，都是最重的一档——它选的不是最轻的路，而是让长任务真正可以被监督、中断、恢复和并行管理的路。跨会话维度上，PAST-Bench（26 个场景、204 个跨会话 Episode）显示 Hermes 是现有基线里唯一在 Memory / Procedural Reuse / Information Gathering / Update 四类能力上全部获得正向增益的框架（+0.13，机制证据分 0.64）——自进化路线的收益要在跨会话基准上才显形。（来源：从一次LLM调用到完整Harness、Pi、Codex_CLI、Hermes_Agent）

§14 设计原则与十条红线

Principles & Ten Red Lines

最佳实践的完整形态是一正一负：原则告诉你怎么建才对，红线告诉你什么绝对不能做。本节先给出 Ontology 设计的四条核心原则、六条结构指导与八种反模式，再逐条列出十条实践红线——每一条都对应一个已被验证的失败模式，最后给出一份源码级的"真本体验证清单"，帮你在选型时剔除把本体当营销标签的项目。

14.1 Ontology 设计：四条核心原则

下面四条原则来源于 Palantir 在政府和企业实施中的广泛现场经验，按优先级顺序排列——当原则之间发生冲突时，优先级更高的原则获胜。（来源：Ontology设计最佳实践）

领域驱动设计：Object type 应代表现实世界实体（Patient、WorkOrder、Vessel），而非数据库表、API 响应或电子表格标签页；Link 应代表真实关系而非外键人工制品。被要求"对 dataset 进行本体化"时，要抵制把列 1:1 映射到 property 就完工的冲动——那会直接产生大杂烩反模式。

DRY：重复的 object type、冗余 property、复制粘贴的工作流，对人和 AI agent 都是维护负担与上下文管理问题。实用触发器："一个实例是巧合，两个是模式，三个意味着是时候重构了。"

开闭原则：object type、interface 或工作流一旦经现场测试投入生产，核心结构应保持稳定；其他团队应能添加实现 interface 的新 object type、或消费现有对象的新工作流，而无需修改核心模型。

组合优于深层继承：通过 Interfaces 支持多继承，实体从多个聚焦的抽象中组合行为，而不是挂在单一继承链上。

14.2 结构指导六条

1. 规范化与派生属性："每个事实只存储一次。使用派生属性提供便利。"预计算值（输入稳定、管道摄取驱动）用 Pipeline 转换；动态派生值（依赖链接对象或经 action/automation 变更）用派生属性。
2. Structs：语义相关的多字段值（地址含街道/城市/州/邮编）、带元数据的值（AI 输出的置信度与来源）、带选择逻辑的多值属性，应使用 struct 而非扁平化为单独 property。
3. Interfaces：实现 DRY 与开闭可扩展性的主要工具——定义共享形态（property、link、action）供多个 object type 实现，使工作流针对 interface 而非单个类型编写。
4. 链接类型：每个 link type 应能回答一个明确的领域问题。关系不携带元数据用直接链接；关系携带自己的元数据（日期、角色、状态）用对象支持的链接。
5. 命名约定："一致、描述性的命名是对 Ontology 质量最有影响力的投资之一。"object type 用单数具体名词，link 从双向自然可读，日期遵循单一约定，模糊术语须用具体含义限定。
6. 安全设计：语义上设计安全、遵循最小权限；行级 + 列级安全实现单元格级访问控制；从限制开始有意识地开放，避免为安全目的复制 object type。

（来源：Ontology设计最佳实践）

14.3 八种反模式：正反成对看

即使经验丰富的设计者也可能陷入这些"最初看起来合理、但随 Ontology 增长会引发严重问题"的陷阱。反模式与正面实践互为镜像，成对呈现最能看清边界。（来源：Ontology设计最佳实践）

知识库侧的设计原则与 Ontology 同构："分层 + 显式化三特征"——按业务/架构/系统/基建四层组织，每层配"事实 + 约束 + 验证"三件套；只显式化高复用、高风险、高隐性的知识，因为"AI Friendly 不是文档越多越好，大量低价值文档反而干扰 AI 判断、消耗上下文"。（来源：知识库四层分层、高复用高风险高隐性）

14.4 十条实践红线

十条红线是《本体论规则引擎》贯穿 34 章的工程安全边界。它们的性质必须先说清楚："十条红线不是'最佳实践建议'，而是'已造成过生产事故的失败模式总结'。在 Agent 时代，这些红线从'业务规则'升级为'智能体的执行宪法'。"（来源：十条实践红线）

（来源：十条实践红线）

红线背后还有配套的选型纪律（五核心抉择）：规则 >50 条、需热更新、需可解释、需冲突治理，才上规则引擎；存储治理按阈值分层——<100 条用文件、100-500 条用数据库、>500 条必须上规则管理平台；LLM 的参与方式限定为"翻译器和审计员离线用（安全），兜底和解释器在线用（标注软结论）"。（来源：本体论规则引擎）

14.5 真本体验证清单：源码级验货

"本体"和"知识图谱"已经是被用滥的营销词。判断一个项目是真本体还是贴标产品，不看 README，看源码——六项验证标准逐项过。（来源：真本体验证清单）

判定规则：六项全过 = 真本体；缺 1-2 项 = borderline；缺 3 项及以上 = 空壳/误标。《本体论实战1》用这份清单拆解了 15 个开源项目：只有 5 个是真本体（Semantica、TypeDB、OpenFoundry、HugAgentOS、agentic-redux），6 个 borderline，其余是空壳或误标——OpenMetadata、DataHub 的"知识图谱"是营销词，Graphiti 其实是 Agent 时序记忆系统，ontology-firewall 只是字段级校验中间件。（来源：真本体验证清单）

§15 知识库七种死法

Seven Ways Knowledge Bases Die

知识库不是建完就活着的。七种死法是一份失败归因目录，正确用法是当作"体检清单"，每季度自查一次、建设团队复盘时逐条对照——"能在项目腐烂前及时纠偏"。先看一个颠覆直觉的数据：业务脱节约 30%、文件堆积约 25%、精度不足约 20%，三者合计 75%——"技术问题反而是少数"，"知识库失败大多不是技术不够，而是组织、专家、业务与流程缺位"。（来源：知识库七种死法）

死法一：文件堆积——仓库越大，答案越远

归因：把知识库理解成"存储文档的地方"而不是"组织知识的系统"——只做了写入，没做组织与检索。深层原因是没有筛选标准，什么都往里放。

死法二：精度不足——答非所问三次，用户永远离开

归因：检索质量从未被度量过。没有测试集、没有指标，"准不准"全凭个别用户的主观印象，改进无从谈起。

死法三：知识过时——半年不更新，库里全是"去年的真理"

归因：根因往往是没有数据反馈与回流——生产中的纠错、未命中的问题、专家的修订没有渠道流回知识库，更新只能靠有人"想起来"。

死法四：静默污染——错误不敲门，悄悄住进来

归因：入库无门槛、无归因。反馈"一股脑塞回"而不先判断是检索没命中还是数据本身错；合成内容不经过滤直接入库——这两种都是数据飞轮停转的典型方式。

死法五：规模超载——库长大了，检索却瞎了

归因：结构没有随规模升级。设计原则与代码实现混在同一个向量空间里（粒度混乱），全量推送而非按需披露，上下文成本失控。

死法六：业务脱节——最高频的死法，约 30%

归因：这是七种死法中频率最高的一种。教训很直接：知识库失败大多不是技术不够，而是组织、专家、业务与流程缺位——只做了技术，忽视了专家与业务。死法与设计原则互为正反：正面是知识库的存活法则，反面就是这些死法，而死法多由"只做技术"导致。

死法七：版本混乱——错了改不回去，也说不清是谁改的

归因：知识被当成"文档"而不是"资产"来管理——资产要有版本号、变更审批与回滚能力，文档没有。这与规则侧的红线 4"无版本不上线"是同一个道理。

§16 治理、评测与踩坑精选

Governance, Evals & Pitfalls

建对了（§14）、防死了（§15），还剩最后一问：怎么让系统长期不腐烂。本节覆盖四块——规则治理五维度、确定性裁判与 Maker-Checker、LLM-as-Judge 评测要点，以及从 60+ 踩坑案例中精选的十条最有代表性的坑。

16.1 规则治理五维度

规则治理解决的是规则从"入库"到"在线生效"之间的关键工程距离，是规则引擎从"开发工具"到"生产平台"的跨越。定性只有一句："没有治理的规则库 = 定时炸弹——你不知道哪些规则已经失效、哪些规则正在误杀、哪些规则互相冲突。"（来源：规则治理）

规则超过 500 条时必须上规则管理平台，平台核心能力：规则 CRUD 与版本管理、热加载与引擎同步、冲突检测与依赖分析、灰度发布与回滚、健康监控与漂移检测、回放评估与死规则清理。"规则治理不是'锦上添花'，而是'从 50 条到 5000 条'的必经之路。"（来源：规则治理）

16.2 确定性裁判与 Maker-Checker

大模型的根本问题是输出的概率性——幻觉、漂移、不可形式化验证，AI 永远无法"自证清白"。一个工程节点能不能把 AI 工程化，取决于该节点上有没有客观的确定性裁判：

过去五十年软件工程"失败"留下的 CI/CD、单测、类型系统、契约编程、形式化方法，恰好是新范式的地基——现成的确定性裁判设施。"让 Agent 能验证自己的工作，是让它放手去做的前提。"（来源：确定性裁判）

Maker-Checker：写代码的 Agent 和检查的 Agent 分开

这是 Loop 中最重要的架构决策之一，理由很朴素："写了代码的模型在评分自己作业时过于宽容。"一个有不同指令的独立检查器（有时用不同模型）能抓住第一个 agent 自圆其说忽略的问题。要点四条：

• 职责分离：制作者负责产出，检查者负责对抗性验证——相当于把人间的 code review 分离搬进 Agent 编排。
• 更强的模型做检查：检查者通常用更强的模型（如 Claude Code 的 /goal 用单独模型判断"是否完成"）。
• 环境隔离：检查者用独立 worktree，避免污染制作者工作区。
• 全绿才放行：检查者就是"确定性裁判"在编排中的体现——跑测试、类型检查、对照规范、验证用户可见行为，只有全绿才 APPROVED，否则给出具体拒绝理由。

与 Agent 门禁的关系：门禁是"先校验后执行"的分层拦截；Maker-Checker 是把校验作为独立智能体去执行，而非被动等待用户 review。（来源：Maker-Checker模式）

16.3 LLM-as-Judge 与评测要点

评测体系三层结构——指标（尺子）、测试集（测什么）、流程（何时测），任一缺失都会让整个体系失效。工程顺序：先建测试集（1-2 周）→ 定指标（1 周）→ 接流程（随 CI）。"测试集是最贵的资产，越早投入越好。"（来源：评测体系）

RAGAS 四维：每一维对应一种故障

Golden Set 与门禁

Golden Set 构建五步：定义问题域 → 难度分层（简单 40%/中等 40%/困难 20%）→ 双人独立作答 + 仲裁 → 标注检索依据 → 封锁与轮换（永不公开、永不进训练语料，MinHash 防泄漏，季度轮换 10-20%）。规模起步 300-500 题、成熟 1000-2000 题——"500 道精标胜过 5000 道模型生成"，"金标准不是'完美答案'，而是'有共识的答案'"。评测门禁进 CI："不过线不许发版"写进流水线，配合三个要点——评测任务可复现（Golden Set/脚本/模型版本锁死）、阈值写进配置并走 PR 评审（防"降阈值"作弊）、评测机器与开发环境隔离（防污染）。（来源：评测体系）

LLM-as-Judge 三纪律

1. 抽样验证一致性：定期抽样验证 judge 与人工评审的一致率，相关系数 <0.8 则不可信，先修提示词；实践一致率 0.75-0.85 可用于批量场景。
2. 缓解偏好偏差：盲评 + 轮换顺序。judge 偏爱长答案、自己的风格、对数字不敏感；"用 GPT-4 评 GPT-4 生成答案 = 偏好同模型输出"。数字类硬指标走结构化校验而非 judge 打分。
3. 不替代人工抽审：judge 只做批量初筛 + 异常标记，保留"judge 与人工不一致"样本的复盘队列，反哺提示词。单独用作发版门禁要非常谨慎，需与 Golden Set 人工样本、领域数字校验配合。

人工评审贵且慢，LLM-as-Judge 让"每个版本都跑一遍评测"成为可能——这是评测门禁进 CI、数据飞轮能转起来的前提；"但也正因它廉价，偏见被放大，管理好 judge 的偏差比选哪个模型更重要"。（来源：LLM_as_Judge）

16.4 踩坑精选：十条最有代表性的坑

以下十条选自《本体论驱动》11 案例 60+ 踩坑卷及其派生概念页，覆盖本体、闸门、评测、知识库四类场景，每条按"场景 → 错误做法 → 后果 → 正确做法"呈现。

§17 从知识管理到知识工程

From Knowledge Management to Knowledge Engineering

前五部分讲的是理论、方法与案例。从这里开始，本书进入它着墨最重的部分：知识工程如何真正落到一套可用的系统上。第一步是把范式迁移说清楚——知识管理（KM）是给人管文档，知识工程（KE）是给机器建知识。这不是名词替换，而是服务对象、知识形态、组织方式、消费方式、失效模式的全面改写。理解了这场迁移，后面两节的 Molio 才有坐标。

17.1 迁移的本质：从“人读文档”到“机器读知识”

传统知识管理的隐喻是图书馆：有索引、有分类、可检索，消费者是人——人来读，人来用。面向 Agent 的知识库换掉了这个隐喻：它是“持久化外部记忆”，消费者变成了模型。知识库的定义随之改写为“结构化/半结构化知识的存储与检索系统，是面向 Agent 的持久化知识载体”，其价值公式 = 覆盖率 × 新鲜度 × 可检索性（来源：wiki“知识库”）。

消费者换人之后，一系列常识被推翻。AI Agent 没有“组织记忆”，只能读你明确给它的东西；而很多关键知识不在代码中，散落在不同仓库、配置、历史 PR、口头约定里——于是问题从“知识库怎么选”变成“把哪些系统知识显式化、以什么形态交给 AI”。这一问句的转换，本身就是 KM→KE 的转折点（来源：wiki“后端系统AI知识库体系建设实践”）。

评价标准同样被改写。知识管理时代看文档数量与可读性；KE 时代的第一条纪律反而是做减法——“AI Friendly 不是文档越多越好。大量低价值文档反而干扰 AI 判断、消耗上下文。”什么值得显式化？三个特征：高复用、高风险、高隐性。其中高隐性最关键，因为“模型再强，也无法推断不存在的信息”——“这个 API 字段是公司级红线不能删除”“修改状态机必须人工审批”，这些知识是规范性的而非描述性的，不存在于代码中，只存在于人脑、团队约定、事故复盘或分散文档里。没人显式化，任何模型都推断不出（来源：wiki“高复用高风险高隐性”）。

迁移也有它的难点。最难的一关是隐性知识蒸馏——把专家脑中“知道但说不出来”的知识，通过具体问题驱动逐步逼出来（本书 §06 已详述）。这里只需强调它与范式迁移的关系：KM 时代知识采集靠“问”，KE 时代知识蒸馏靠“逼”；蒸馏出的知识是场景化的（“在 Y 场景下应该怎么办”），而当前 RAG、知识图谱、向量库全是为陈述性知识设计的——这个错位，正是知识库范式还在快速演化的根本原因（来源：wiki“隐性知识蒸馏”）。

17.2 一条谱系：Wiki 偏阅读，Ontology 偏行动

KE 内部并非铁板一块。所有知识库形态可以放在一条谱系上，谱系的两端是一组对偶：“传统 API 文档告诉 AI 这个接口怎么调；Ontology 更进一步告诉 AI 这个业务世界里有哪些对象、对象之间关系、对象上允许做什么动作、动作执行前需要什么权限与约束。Wiki 偏解释系统，Ontology 偏建模系统；Wiki 偏阅读，Ontology 偏行动。”（来源：wiki“Ontology四要素”“后端系统AI知识库体系建设实践”）

谱系右端的行动型本体，四要素是 Data / Logic / Action / Security：Data 把业务实体建模成对象、属性、链接；Logic 把业务规则与算法绑定到对象上；Action 把决策执行建模为原子化操作，支持模拟、审批和写回；Security 让权限与对象/属性/动作绑定、随场景动态计算。Palantir 官方口径：Ontology 以决策为中心、而非仅以数据为中心，四要素汇聚为“人类与 agent 共同使用的决策模型”——“若数据要素是企业的‘名词’，action 就是‘动词’；在决策被实时做出的同时闭合 action 闭环，正是运营系统区别于分析系统之处。”（来源：wiki“Ontology四要素”，转引 wiki“Palantir_Foundry官方文档中文版”）

17.3 五范式重述：各自在谱系上的位置

本书 §02 已对五种知识库范式做过机制级对比，这里不重复，只回答一个迁移视角的问题：每个范式把 KM→KE 的哪一段路修通了？（来源：wiki“知识库建设范式对比”）

从迁移路径看，五范式是一条“补课链”：RAG 补上机器可检索，LLM Wiki 补上机器可积累，Graphify/GraphRAG 补上关联自动推断，金字塔补上层次与角色路由——每一环都是对前一环结构性缺陷的回应，而全链修完之后，仍然停在阅读端。要让 AI 动手改订单、派工单、隔离故障，还差 Action 与 Security 两个维度，那是行动型本体的事（§19 详述升级路径）。

17.4 喂知识四条路：各答什么问题，按阶段叠加

把视角从“建什么库”切到“怎么喂”，知识进入模型共有四条路，每条回答一个不同的问题（来源：wiki“把知识喂给模型的四条路”“AI落地三问对外版”）：

四条路之前还有第零步：知识小到上下文窗口一次装得下（128k ≈ 300 多页文本），就别检索，直接整段塞进提示词——业内建议“从无搜索开始”，装不下、变复杂了再往上叠；进了检索也先从最基本实现起步，查询改写、混合检索都是后手（来源：wiki“把知识喂给模型的四条路”“RAG”）。

四条路是叠加关系不是互斥选项。按知识的脾气分两拨：随时在变的走 RAG，几乎不变的可以考虑内化——互补而非替代。在此之上：想让模型有积累，叠 LLM Wiki（把知识从“推”改成“按需查”）；想让 AI 不止答题、直接动手，再叠 Ontology。还能套娃——把检索架在本体上做（本体增强生成 OAG），让模型在一副有结构的骨架上查，比在一堆散乱片段里翻准得多。

“现在该走哪条，本质是问：你手里的知识是什么脾气，你想让模型做到哪一步——是用上它、记住它，还是让它动手。”（来源：wiki“把知识喂给模型的四条路”）

17.5 KM vs KE：一张对照表

把本节收拢成五个维度的对照，这张表也是后两节评价 Molio 的尺子（综合来源：wiki“知识库”“高复用高风险高隐性”“知识库建设范式对比”“知识库七种死法”）：

§18 Molio：一个 LLM Wiki 模式的实现

Molio — the LLM Wiki Pattern in Practice

§17 的谱系上，LLM Wiki 是“持续积累”的代表；本节把它解剖到实现级。Molio（墨流）是一个真实在运行的 LLM Wiki 模式工程实现——而且本书就是用它的知识库写出来的。以下内容全部基于对 Molio 代码库（约 6 万行 TypeScript + 810 行 SKILL.md + 2,956 行确定性脚本）的逐文件调研，随文标注出处。

18.1 定位与技术栈

一句话定位：Molio 是一个本地优先的个人知识底座平台——把 AI runtime（Claude Code / Codex / Gemini CLI / Qwen Code）接到用户本地 vault（纯 Markdown 文件夹）上，Agent 基于全部积累做研究、写作、问答，产出以 Markdown 写回沉淀。官方口径：“让 AI 拥有你的个人知识底座。数据全在本地，始终属于你。”其中“类 Obsidian + LLM Wiki”的知识库组织方式（根 CLAUDE.md 原话），正是 Karpathy LLM Wiki 模式的工程实现（来源：Molio 代码调研，README_zh.md、根 CLAUDE.md）。

工作循环三段：收集与加工（剪藏/导入 → Wiki 自动提取实体与概念、构建索引与摘要）→ Agent 工作（多 Agent 统一图形界面、流式输出、微信/飞书渠道）→ 沉淀回流（产出写回知识空间，“底座越用越厚”）。这三段正是 LLM Wiki 三操作（Ingest / Query / 反哺）的产品化（来源：Molio 代码调研，README_zh.md）。

整个模式的支点藏在一行代码里：spawn agent CLI 时 cwd = vault 路径（RunManager.ts）——Agent 的工作目录就是知识库本身，vault 内的 .claude/skills/ 与 .claude/CLAUDE.md 被 CLI 原生加载。知识不经过任何中间层转译，模型直接在文件系统上工作（来源：Molio 代码调研，apps/daemon/src/core/runtimes/claude.ts、RunManager.ts）。

18.2 架构总览：平台编排，vault 承载知识

Molio 最重要的架构决策是平台与知识机制解耦：“LLM Wiki”不是 daemon 里的一个功能模块，而是一组注入到 vault 的 Agent Skill——平台（TypeScript）负责编排与分发，wiki 的构建/检索逻辑本身以 Markdown 指令（SKILL.md）+ 确定性脚本（.mjs）形式存在，由 Claude Code 等 runtime 在 vault 内执行。任何支持 skill 的 agent CLI 都能驱动同一套 wiki（来源：Molio 代码调研，§2 关键设计）。

平台侧四个关键模块的分工：skill-installer 在 vault 创建/导入时把 7 个内置 skill 整目录镜像到 <vault>/.claude/skills/，并向 vault 的 CLAUDE.md 注入带 BEGIN/END sentinel 的 5 条规则块（“知识库优先”等）；RunManager 以 vault 为 cwd spawn agent CLI、解析流式输出、SSE 推给前端；wiki-status 从 wiki 自身推导每个源文件的入库状态供 UI 文件树标注；graph.ts 解析全 vault wikilink 生成节点-边图供前端可视化（来源：Molio 代码调研，§2 模块职责表）。

18.3 数据流：源文件怎么变成 wiki

入口有四条：本地批量导入 / Obsidian 目录直接打开（vault 就是普通文件夹）、Chrome Web Clipper 剪藏、微信/飞书投递（URL/文件先暂存 raw/wechat/YYYY-MM-DD/，用户确认后触发 wiki-ingest）、Web UI 上传。非文本资料（PDF/Office/音视频）先经 docling skill 转 Markdown——这是注入 vault 的硬规则。整体数据流三层泳道：

构建侧的数据流分两条。普通源文件：扫描 vault（跳过隐藏/wiki/.molio）→ wc -c 判超长 → 通读 → 规划页面清单与类型 → 读已有 wiki 避免重复 → 生成页面（带 frontmatter + 密集 [[链接]]）→ 链接对账 → 更新 INDEX/log/hot——全程 agent 语义工作，无脚本介入。超长源文件（>1.5MB ≈ 50 万中文字，或 Read 2000 行读不完）走 8 步管线，机械活全部交给确定性脚本，agent 只做语义判断（18.6 展开）（来源：Molio 代码调研 §3.3–3.4）。

消费侧有三条路径：问答走 wiki-query 的索引下钻（18.5 展开）；UI 文件树状态由 wiki-status 解析 sources 页 frontmatter + log.md 事件流 + 全文提及兜底，给每个源文件标注 pending / tracked-clean / tracked-modified；知识图谱可视化由 graph.ts 扫全 vault 解析 wikilink 生成。值得一提的工程细节：deadcheck 脚本的链接解析规则刻意与 graph.ts 镜像——“文本约定即 API 契约”，wiki 里写下的每个 [[链接]]，同时是构建门禁的校验对象和 UI 图谱的数据源（来源：Molio 代码调研 §3.5、§5.3）。

18.4 五种页面类型：以本书所在的知识库为例

wiki 层的知识以五种页面类型组织，各页 frontmatter 携带 type / title / created / updated / tags / related / sources 元数据；文件名即规范名（中文直接用中文名，英文 kebab-case），链接名必须与文件名一致（来源：Molio 代码调研，wiki-build SKILL.md）：

另有 1 页概述（overview）作为全库入口，直接内联在根 INDEX 中。写这本书时引用的每一个论点——五范式对比表、四条路、Ontology 四要素、21 天最小 DataOS——都来自这 270 页中已被整理、交叉链接、矛盾标注过的页面，而不是从零检索原始文档，更不是凭模型记忆（§19.3 复盘整条流水线）。

18.5 三级渐进式索引：按需下钻，而非推送

知识库变大会杀死问答链路：根索引若逐页罗列，页面一多就长到 runtime 一次读不完（Read 上限 2000 行）——这是分层的原因，“不要因为‘库还小’而退回单索引”（wiki-build SKILL.md 原文）。Molio 的解法是四级文件构成的渐进式索引，每一级都只提供“够做下一步路由决策的最小信息量”（来源：Molio 代码调研 §5）：

关键性质是根 INDEX 与页面总数解耦：库从 50 页长到 5000 页，根索引始终几十行；单目录索引几百行一次 Read 可读完，不做二次分片。Agent 问答时的下钻路径（wiki-query 的回答流程就是下钻协议）：

效率账：Agent 用几十行成本了解全库，用几百行定位到相关条目，只在真正需要时才读完整内容；对比一次性推送几十条完整知识（5000-10000 行），上下文效率提升一个数量级——知识消费“精准”而非“贪婪”（来源：wiki“三级渐进式索引”）。这正是 §08 所述三级渐进式索引原则在真实产品里的落地形态。

18.6 五大工作流：一套 wiki 的完整生命周期

五个 wiki-* skill 构成知识库全生命周期，同版本号共进（当前 2.0.0）：改任一 skill，五个 version 一起 bump。分发方式是内容哈希镜像——skill-installer 把五件套同步进每个 vault 的 .claude/skills/，runtime CLI 启动时自动发现（来源：Molio 代码调研 §4）：

五件套对应 LLM Wiki 模式的三操作并做了产品化扩展：Ingest → wiki-build/wiki-ingest，Query → wiki-query，反哺 → wiki-save，再加 Lint 做持续治理——“定期查矛盾/过期/孤立页/缺失概念/断裂交叉引用”正是 Karpathy 模式里 Lint 操作的实现（来源：wiki“LLM_Wiki”、Molio 代码调研 §4）。

工程亮点一：超长源文件的分层 digest 与 8 步管线

一本 50 万字的书塞不进任何上下文窗口，Read 也有 2000 行上限。wiki-build 的答案是一条 8 步管线，原则是“机械活全部交给确定性脚本，agent 只做语义判断”（来源：Molio 代码调研 §3.4）：

① prep.mjs 把源文件加工成 5 件产物：编码归一 + 行规范化的 UTF-8 底本（行号 = 稳定地址）、章节分段、实体频率普查（单遍扫描替代 grep 循环——“thousands of candidates cost the same as a handful”）、候选清单与进度清单。② 每个处理范围（≤15 万字）派一个 subagent 只读自己的行号区间，产出带行号证据的 digest——主 agent 从不通读全文。③ curation 是核心决策点：脚本按普查频率预填草稿，agent 按“信息落点”判据审核——删噪音、按主题分组、逐行标注页类（entity/concept）。④ 建页 subagent 读批次 TSV + 底本取证，并发 ≤5-6，只能链接白名单内的名字。⑤ place.mjs 把草稿分发到实体/概念目录并自动生成目录 INDEX，幂等可重跑。⑧ sweep 对全部页面跑引文逐字回查，只修真错（来源：Molio 代码调研 §3.4、§6.5）。

工程亮点二：断点续传——文件系统是唯一事实

多小时的构建随时可能中断，而 LLM 的完成报告不可信。Molio 的对策是把“完成”的定义从“agent 说完成了”改成“产物文件落盘了”：candidates/progress 清单永不覆盖（除非 --force）——“that is what makes a multi-hour build resumable after a crash”；digest 进度以 digests/R###.md 落盘为准而非勾选框，代码注释记录了一次真实事故：“A real 74-range novel build surfaced this: 18 digests, 0 boxes checked”——18 个 digest 已落盘，勾选框一个没打，若信勾选框就会重跑 18 个范围。配套的三道硬门禁全部 exit 1 即中止：verify-drafts（批次声明 vs 磁盘落盘对账，治“subagent 输出被截断后以为自己写完了”）、deadcheck（死链清零才算构建完成）、中间产物齐全性检查（来源：Molio 代码调研 §6.2、§6.3）。

工程亮点三：wikilink 交叉链接是机械 pass，不是写作风格

LLM Wiki 的价值在链接网络，但“模型记不记得打 [[ ]]”不该决定图结构。Molio 用双脚本互补把链接变成机械对账：linkpass 把每个页面名/别名在其他页正文的首次出现自动包成 [[链接]]（别名映射来自批次表——“项王”→ [[项羽|项王]]），保证“该被链的都被链”；deadcheck 全库扫死链，保证“每个链接都有页面”。细节上：每对页面只链首次出现（保持可读）、幂等可重跑、保护区（frontmatter/代码块/已有链接/引文）绝不触碰、拉丁词边界保护（“abi”出现在 “Capabilities” 里不链——这是真实 bug 换来的教训，CJK 无词边界则自由链）。两条规则由此不再互相矛盾：“宁多链接”与“只链存在的页面”同时成立（来源：Molio 代码调研 §6.7）。

工程亮点四：[!contradiction] 矛盾显式化

ingest 的独有要求：新信息与已有 wiki 冲突时，不悄悄覆盖、不和稀泥，而是在两个页面都加 > [!contradiction] callout，说明矛盾内容与可能解决方向，并告知用户；lint 把“内容矛盾”列为 13 项检查中唯一的 error 级。知识网络不追求虚假一致性——矛盾被当作一等公民标注出来，留给下一次阅读裁决。这正是 Karpathy 模式“矛盾已标记”（contradictions flagged）承诺的落地（来源：Molio 代码调研 §4.2、§6.11；wiki“LLM_Wiki”）。

18.7 设计决策表：做法与为什么

把散落在代码注释里的决策理由收拢成一张表——每一条背后都是一次真实事故或一个被否决的方案（来源：Molio 代码调研 §6）：

§19 Molio 实践与升级路径

Molio in Practice — the Upgrade Path

§18 解剖了 Molio 怎么造，本节回答三个更实际的问题：团队做 AI 绕不开的三问，Molio 怎么答？wiki 型知识库的下一跳是什么、什么时候该跳？以及——这本书本身就是用 Molio 的知识库写出来的，整条生产流水线如何自证“知识复利”？最后给一份从一个 vault 开始的启动清单。

19.1 AI 落地三问，用 Molio 作答

三个会议级问题的共同错误是“问题还没定义清楚，就先跳到了技术上”（来源：wiki“团队做AI绕不开的三个问题”）。逐问拆开，每问先给判据、再给 Molio 的回答：

问题一：要不要建知识图谱？

判据：先分清你要的是哪种“本体”——语义本体（推理，百科全书）、知识图谱本体（遍历，交通图）、Palantir 式本体（执行，操作台）、Agent 本体（约束，交通规则）是四种工程范式、四套不能混用的技术栈，定性错了后面全白搭。“本体”这个词已经被重载到失效（来源：wiki“知识到位后让AI对业务动手”，详见本书 §04）。

Molio 的回答：先别建图谱，先建 wiki。图谱的价值在自动关联推断与多跳遍历，但你的团队连“知识显式化”这第一步都还没完成时，图谱是无米之炊。Molio 用零成本的方式先拿到图谱的大部分好处：wikilink 网络 + linkpass 机械补链就是一张显式关系图，daemon 的 graph.ts 直接把它渲染成可视化图谱——不需要图数据库，文本约定即 API 契约。等到手动链接维护不动、需要自动社区检测与缺口发现时，再按 §19.2 的触发信号升级（来源：Molio 代码调研 §5.3；wiki“知识库建设范式对比”）。

问题二：RAG 为什么不好用？

判据：先拆归因——检索质量、知识结构、数据供给是三件事，天花板常在结构不在模型。RAG 的三个结构性缺陷（每次从零推导、无法连点成线、粒度混乱）是范式级的，换更大的模型救不了；失败归因数据也支持这一点：知识库七种死法中约 75% 是业务与工程流程问题，技术不行反而是少数（来源：wiki“知识库建设范式对比”“RAG”“高质量数据从哪里来”）。

Molio 的回答：把“检索拼接”升级成“索引下钻”。RAG 的病根是把知识打碎成 chunk 塞进向量空间——“AI 每次检索都像在翻一个什么都能找得到、但什么都连不成线的抽屉，这种库有个名字，叫向量垃圾场。”Molio 反其道而行：知识先被编译成带结构的页面网络（合成而非搬运、矛盾已标记、交叉引用已建好），检索变成沿三级索引的路由决策（图 18-2），每一步读到的都是最小充分信息。粒度混乱的问题由页面类型系统解决——设计原则住 concepts，源文档结论住 sources，对比分析住 comparisons，不再混在一个向量空间里（来源：wiki“团队做AI绕不开的三个问题”“LLM_Wiki”；Molio 代码调研 §5）。

问题三：怎么让 Agent 不乱跑？

判据：约束要修进流程，不是写在提示词里——“这就像靠贴告示拦闯红灯——规矩得修进马路里，而不是写在路边。”提示词级的约束会被上下文稀释、被静默丢弃（来源：wiki“团队做AI绕不开的三个问题”）。

Molio 的回答：Molio 自己就吃过这个亏并给出了工程答案。系统提示注入被 CLI 静默丢弃后，vault 问答曾纯凭记忆作答——修复不是换个提示词写法，而是三重保险的结构化改造：常驻规则写进 CLAUDE.md（CLI 原生加载，可靠到达）、面板按钮发确定性触发语、渠道帧把指令前置到消息本身（“message prepend always reaches the model”）。构建侧同理：不靠叮嘱 agent“记得建链接”，而是 linkpass/deadcheck 脚本门禁 exit 1 即中止。规矩修进了马路，而不是写在路边（来源：Molio 代码调研 §6.8、§6.3）。

19.2 升级路径：wiki → 结构型 → 行动型

Molio 的现状是阅读型知识库（LLM Wiki 模式），它是 KE 光谱的入口段而非终点：LLM Wiki 解决了 RAG 的第一缺陷（无积累），但尚未解决关联自动推断（Graphify/GraphRAG 的能力）与层次/角色路由（金字塔的能力），更未触及行动（Ontology 的能力）。升级路径两跳，每一跳都有明确的触发信号——“组合是演进出来的，不是设计出来的”（来源：wiki“绿皮书选题评估”“知识库建设范式对比”“知识到位后让AI对业务动手”）：

第一跳（阅读型 → 结构型）：LLM Wiki 的局限（wikilink 之外无自动关系推断与社区检测）正是 Graphify/GraphRAG 的强项；金字塔则补上层次感知与角色适配。三者与 wiki 不互斥，同一套库可以叠加使用。理论依据是“分层即检索优化”——先确定去哪层找再精确定位，把搜索空间从全量缩到子集，这是三级渐进式索引的推广形式；层间需要边，不同层不同保鲜周期（来源：wiki“LLM_Wiki”“三种知识分层方案对比”）。

第二跳（结构型 → 行动型）：Ontology 四要素中 Action/Security 是 wiki 完全没有的维度。这一跳有个容易踩空的前提——行动型本体需要闭世界假设，只有“查不到就是不存在，或者违规”的世界才做得了机制级门禁校验；阅读型知识库天然是开放世界（查不到只代表还没入库）。落地形态是 Agent 门禁/裁决闸门一类的机制（详见本书 §10 的 21 天最小 DataOS）。演进不是推倒重来：“图谱先发现风险关联，执行本体再触发处置动作；Agent 调动作之前，先过一道门禁校验。层，是这么长出来的。”（来源：wiki“Ontology四要素”“知识到位后让AI对业务动手”）

面向未来的注脚：大模型正在内化“自主编排多个工具”的能力，所以知识库建设不是和未来模型赛跑——“把团队业务理解、架构经验、系统约束、工程规范显式化为组织工程能力的结构化资产”，这件事无论模型怎么迭代都作数（来源：wiki“后端系统AI知识库体系建设实践”）。

19.3 本书即自证：一条知识复利的生产流水线

这本书本身就是 Molio 知识库的一次完整消费。生产流水线复盘（来源：本书工程记录）：

知识复利体现在每一步。调研 agent 提取素材时，读的不是散落的原始文档，而是已经过 ingest/build 编译的页面——交叉引用已建好、矛盾已标注、跨源综合观点已沉淀在 concepts 与 comparisons 页里；本书 §17 引用的五范式对比表、四条路、Ontology 四要素，全部直接取自库内成品页面，每处标注（来源：wiki“页面名”）。写作 agent 被明确禁止凭训练记忆编造——“检索优先，禁止凭记忆”的 wiki-query 纪律被写进任务书，这正是 §18.6 三重保险机制在真实生产中的运用。素材里连“本文件仅为写作素材，不修改任何 wiki 页面”这样的只读红线，都是知识库治理纪律的延续。

对比一下没有知识库的写法：每个写作 agent 都要从零检索几十篇原始文档、各自重复消化同一批材料、观点冲突无人裁决、引用无从核验——这就是 RAG“每次从零推导”缺陷在写作场景的重演。而有了 270 页的积累，7 个调研 agent 只需沿三级索引下钻，各取所需；一次入库的知识，在这次写作中被多个章节反复消费。每沉淀一条经过验证的知识，后续所有工作流都受益——“团队知识是有复利效应的资产”，这本书就是那张复利账单（来源：wiki“知识复利”“绿皮书选题评估”）。

19.4 落地建议：从一个 vault 开始的启动清单

如果你读完本书只想做一件事，那就从一个 vault 开始。不需要平台、不需要图数据库、不需要向量索引——vault 就是一个普通文件夹，纯 Markdown，零迁移、无锁定，随时可以切回 Obsidian（来源：Molio 代码调研，根 README）：

最后的提醒回到全书主线：“做 AI 这件事，拼的不是谁先拿到更聪明的模型，而是谁先把自己的问题想明白。”模型的能力会趋同，拼到最后，拼的是谁能把自己那份知识递得更准——谁先把知识摆对了地方，谁就先被模型喂饱（来源：wiki“团队做AI绕不开的三个问题”“把知识喂给模型的四条路”）。

§20 展望：知识永恒

Outlook: Knowledge Endures

全书走到这里，技术趋势、方法论、实践框架、案例、最佳实践与 Molio 的落地路径已经铺完。最后一章不预测任何具体产品的兴衰——那类预测的半衰期只有几个月。它只回答三个更根本的问题：当 Agent 开始"动手"，知识以什么形态被消费？当智能从单体走向系统，知识以什么结构被组织？当系统开始自我改进，知识以什么方式被回流？三个问题指向同一个收束：模型会迭代、工具链会更新、工作流会重构，但领域知识永恒。

20.1 Ontology：Agent 时代的执行协议

本书双主线——AI 软件工程与知识工程——在四个交汇点上合流，其中最具决定性的一条是：Ontology 正在成为 Agent 时代的执行协议（来源：全库总览）。这句话的准确含义，被一句对偶句反复验证：

"偏阅读"与"偏行动"的分界，正是知识工程下一个十年的分界。阅读型知识供给——RAG、LLM Wiki、金字塔——回答的是"模型怎么知道"；行动型知识供给——Ontology——回答的是"模型怎么被允许做"。Palantir 官方把行动型 Ontology 拆成四要素，四要素汇聚为"人类与 agent 共同使用的决策模型"，以决策为中心、而非仅以数据为中心（来源：Ontology四要素，转引 Palantir_Foundry官方文档中文版）：

为什么这条线在 Agent 时代变得不可回避？因为 Agent 的角色正在从"给答案"升级为"做动作"。答案错了可以重来，动作错了无法撤回——规则引擎与契约式 AI 的价值随之从"算对结论"升级为"拦住错误动作"（来源：Agent_Harness四层规则嵌入、规则推理引擎）。本书 §12、§16 给出的机制——裁决闸门五道确定性校验、四层规则嵌入、Agent 门禁的 L1-L5 安全模型——本质上都是同一句话的运行时表达：LLM 提议，规则引擎否决；校验必须发生在"一道可执行、可证明、不可绕过的确定性闸门上，而不是模型的自律"（来源：契约式AI、裁决闸门、本体论规则引擎）。

还要记住那条容易搞错的世界假设分水岭：阅读型知识库可以活在开放世界里——查不到只代表还不知道；行动型本体必须活在封闭世界里——查不到就是不存在，或者违规。只有后者才做得了"查不到就不许通行"的机制级门禁校验（来源：知识到位后让AI对业务动手）。从 wiki 走向 Ontology，不只是加几个构件，而是切换世界假设。

20.2 从个体智能到系统智能：图工程

第二条趋势线关乎智能的组织形态。图工程综述建立了三层智能层级（来源：模型智能、个体智能、系统智能、大型语言模型智能体时代的图工程）：

从个体到系统的跃迁，不是"把 Agent 做得更强"，而是承认单个 Agent 有三个结构性瓶颈：并行与依赖任务的调度、专业能力与独立验证的整合、持久状态与故障恢复。"这些瓶颈的根源不是'Agent 不够强'，而是架构不匹配——复杂任务需要分布式组织，单一 Agent 环无法提供。"（来源：个体智能）系统智能的核心判断因此是：智能必须分布在多个专业化 Agent 之间，并在系统层面进行组织；关键不在 Agent 数量，而在结构（来源：系统智能）。

"结构"的工程学就是图工程——用显式、动态、持续演化的图结构外化任务、智能体与运行时状态之间的关系，支持系统层面的组织、协调、监控、恢复与优化。它在 AI 工程演进阶梯中位于 Loop 之上，但不取代 Harness 与 Loop："Harness 决定单个 Agent 能访问什么能力，Loop 决定单个 Agent 如何持续执行，图工程决定多个 Agent 如何作为一个整体协同工作。"（来源：图工程）三大支柱——任务组织、智能体协同、运行时状态管理——之上还有一道横梁：系统演化，利用执行证据持续优化任务结构、团队结构与状态管理。

对本书而言，图工程最重要的注脚是它与知识工程的关系：显式图结构本身不能保证系统实体和关系的一致定义，本体工程为图工程提供语义基础——本体定义共享概念模型，图工程把它实例化为任务特定结构，运行时机制强制执行其操作后果（来源：大型语言模型智能体时代的图工程）。换句话说，多 Agent 系统外化的那张"任务图 + Agent 图 + 状态图"，本身就是一种新的知识资产：它记录了一个组织如何分解目标、如何分配能力、如何从故障中恢复。综述给出的未来方向——图原生能力基底、自演化图系统、图原生智能体操作系统（任务/Agent/能力/状态作为一等系统对象）——每一个都以这份资产的持续沉淀为前提。

20.3 自进化：系统开始养活自己

第三条趋势线是时间维度上的：知识体系不再是"建完就静止"的交付物，而是一个会自我改进的系统。所有自进化系统的核心控制架构是 MAPE 控制循环，源自自洽计算（Autonomic Computing）（来源：MAPE控制循环）：

MAPE 的核心纪律是"先归因、再干预"——不是所有失败都触发同一修复，检索失败、生成失败、路由失败、知识缺口各有各的解法。这条纪律的数据侧对应物，就是本书 §09 的数据飞轮：反馈信号采集→样本加工→数据回流→评测验证，把知识工程从"一次性工程"变成"持续工程"。"飞轮不是可选项，而是必选项——没有回流闭环，知识库第 3 个月开始腐烂。"（来源：数据飞轮、自进化）

自进化的成立有三个条件：可定义的优化目标、可搜索的算子空间、可计算的反馈信号。当前工程实践覆盖前两个，第三个最薄弱——所以自进化的下一步"不是让算法更聪明，而是让反馈信号更可靠"，这又回到了评测体系的核心论点：评测的可靠性决定优化的天花板（来源：自进化）。与之配套的是自指系统的铁律：外部锚点原则——可以自我迭代，但不能自我验证，Golden Set、交叉裁判、人工分层抽样必须留在回路之外（来源：自进化）。

自进化不是纸面概念，运行时层面的证据已经出现：

• Hermes Agent 把自我改进做成框架的第一目标——"在模型外部维护一层随使用逐渐变化的认知系统"：Session Archive 留下原始经历，Memory/Skills 承载稳定事实与可复用流程，Background Review 决定哪些经验值得影响未来。PAST-Bench（26 场景/204 跨会话 Episode）上，它是唯一在 Memory、Procedural Reuse、Information Gathering、Update 四类能力上全部正增益的框架（总体 +0.13，机制证据分 0.64）（来源：Hermes_Agent、从一次LLM调用到完整Harness）。
• 门禁侧的本体演化：被拦截的失败经蒸馏成为版本化本体提案，而非直接改规则——仅经人工复核后生效且可回滚，防住"温水煮青蛙"式的提权攻击（来源：熔断_自愈）。
• Palantir 动态层：每次决策作为带完整血缘的新数据被 Decision Store 捕获，回流 AI/ML 模型，配合偏差检测→重训练→灰度发布的 Feedback Loop——官方体系中最难也最有价值的闭环能力（来源：Dynamic_Layer）。

三条证据共享同一个结构：执行产生证据，证据回流知识，知识改进下一次执行。区别只在回流的对象是记忆、本体还是模型。对知识工程的启示是：自进化的终点不是"模型更聪明"，而是"知识库更准"——每一次失败、纠正与拦截，都应该沉淀为一条可版本化、可追溯、可回滚的知识。

20.4 收束：模型会迭代，知识永恒

三条趋势线——行动型 Ontology、系统级图结构、自进化回流——看似指向不同的技术，实则共享同一个底层判断，也是本书从第一页带到最后一页的核心命题：

这个判断的论据在本书中反复出现过：模型能力提升的回报是概率性的——你无法保证下一代模型恰好擅长你的领域；知识工程的投入是确定性回报的——整理好的结构、显式化的约束、沉淀下来的判例，无论载体是检索库还是模型权重，都不会被任何一次模型迭代清零（来源：知识复利、RAG与上下文内化对比）。"工作流是管道，知识才是流过管道的活水……Harness 是实现手段，知识沉淀才是护城河。"（来源：Harness_Engineering）

于是全书落到最后一句 actionable 的判断：每个团队都需要自己的 Molio。它不需要一步到位，路径在 §02 的五范式谱系和 §19 的升级路径里已经画好：

三步的共同纪律只有一条：组合是演进出来的，不是设计出来的——先验证单一形态真能创造价值，再谈叠加与扩展（来源：21天最小DataOS、知识到位后让AI对业务动手）。也不必焦虑于追赶模型："知识库建设不是和未来模型赛跑，而是把团队业务理解、架构经验、系统约束、工程规范显式化为组织工程能力的结构化资产。"（来源：后端系统AI知识库体系建设实践）

模型还会继续变强，Harness 不会因此消失——"模型越能行动，外面的运行时越不能含糊"（来源：从一次LLM调用到完整Harness）。而运行时的最深处，放着的是你这个团队独有的那份领域知识。这就是知识工程的全部承诺：它不保证你赢得某一次模型竞赛，它保证你在每一次竞赛中都带着别人拿不走的筹码入场。

附 术语表与参考来源

Appendix: Glossary & References

本附录汇总全书核心术语与知识底座。A.1 术语表按术语在书中的首现章节排序，给出中英文对照与一句话定义（英文以素材原文为准，原文无英文者留空）；A.2 参考来源列出支撑本书的 22 个源文献，按书籍与标准、论文与官方文章、公众号与工程实践文章三组编排；A.3 说明本书知识底座的构成方式。

A.1 术语表

A.2 参考来源

本书内容全部基于以下 22 个源文献经 Molio 知识库工作流加工后的 wiki 页面，正文引用以（来源：页面名）标注。按文献类型分三组。

一、书籍与标准（7 项）

二、论文与官方文章（6 项）

三、公众号与工程实践文章（9 项）

A.3 本书的知识底座

本书不是从空白文档写起的，而是从一个持续维护的 wiki 知识库中“编译”出来的。这个知识库共 270 页，构成如下：

写作流程为：先由调研 Agent 从库内产出 7 份分维度素材（技术趋势/方法论/实践框架/案例 ×2/最佳实践/KM→KE，合计约 3600 行，每条标注来源页名）；再由 8 个写作 Agent 按章节并行产出 HTML 片段；最后统一合并构建为本书。本书由 Molio 知识库工作流辅助写成——正文中所有（来源：…）标注均可回溯到库内对应页面，页面再回溯到 A.2 所列源文献。这既是一次工程实践，也是本书核心命题的自证：知识沉淀一次，被消费多次，复利可在生产过程中直接观察。