一、什么是知识工程，它的范式为什么过时了​

知识工程（Knowledge Engineering）是构建知识库、知识图谱、本体（Ontology）的工程学科。 2001 年 Noy & McGuinness 的经典教程 Ontology 101 奠定了传统范式的七个步骤：确定领域范围 → 复用已有本体 → 列举关键词 → 定义类层次 → 定义属性 → 定义约束 → 创建实例。

它的隐含假设是：领域专家可以在执行前设计出接近完整的 schema。 对小而清晰的领域（如葡萄酒分类）成立；对大而复杂的领域（如 57 万字的《史记》）会失效：

• 执行前无法预知文本里究竟有多少种实体类型
• schema 定稿后，执行中不断冒出边界案例，被迫返工
• 专家精力耗尽在前期设计，而不是实际的知识提取

2026 年的新条件是：大语言模型能处理复杂语义，AI Agent 能自主执行迭代任务。 知识工程的瓶颈从"执行速度"转移到了"反思质量"——这催生了新范式。

二、三个项目：一条方法论演化链​

注意最后一行：当 SKILL 文档、Butler 框架、Harness 约束都成熟后， 启动一个新知识库（2,510 词条、26 种类型）只花了两天。这就是方法论积累的复利。

三、六个核心特征​

1. 自底向上的本体涌现​

本体不是专家预先设计的蓝图，而是从文本中提取、验证、迭代后涌现出来的结构。

对比两种路径：

• Big Bang 设计（传统）：4 周设计完整 schema → 执行时频繁不匹配 → 大规模返工，总计约 12 周，质量不确定
• JIT 演进（新范式）：第 1 周用 4 类最小本体标注 5 章拿到可用版本，之后每周扩类、扩覆盖、反思，4 周达到 92% 质量

史记的 22 类实体没有一类是一开始"设计"出来的——都是处理具体文本时发现有必要区分才引入的。 例如"器物"类是在处理本纪时才出现的，最终占了 4.6%（926 页）。

2. 多层次自动化反思循环​

质量改进不靠人工逐条审查，靠 Agent 周期性反思。五层架构：

反思是收敛的。史记对 3,198 个事件做了 5 轮年代推断反思：准确率从 60% → 80% → 88% → 92% → 95% → 97%， 每轮修正数递减。收敛判据：每轮修正数降到上一轮 1/3 以下且绝对值 < 50。

反思的发现不会被丢弃，而是沉淀进规律库（史记积累了 134 条），每条规律都带"检测条件 + 修正动作"， 下一轮直接用规律库扫描全库。这相当于代码工程里的回归测试用例库。

3. Schema 的语义演化路径​

知识表示分三代进化：

1. 纯导航链接：[[贾宝玉]] 是 [[荣国府]] 的公子 —— 只能人工浏览
2. 语义 Wikilink：[[金玉良缘::薛宝钗]] —— 关系类型编码进链接，支持关系查询和图谱推理
3. 动态查询块：页面里嵌入 ::: query 块，运行时生成表格 —— schema 变成可编程的数据接口

Frontmatter 同样从静态元数据 → 自动计算的质量字段（quality_score）→ 结构化多维属性（带 surface/canonical/source 的别名结构）。

4. 段落编号（PN）：知识的坐标系​

给原文每个段落分配全局唯一编号（如 003-042），把"引用原文"从模糊的章节定位变成精确坐标。这带来三种能力：

• 精确引用：两个词条引用同一 PN，系统可自动关联
• 覆盖率统计：全库覆盖率变成可精确计算的指标，Butler 据此优先处理盲区
• 矛盾检测：同一 PN 被两个词条给出不同解读时，可自动标记

一句话记忆：没有 PN 就没有精确引用，没有精确引用就没有可验证的质量标准。

5. Harness 驱动的硬约束​

一个血泪教训：2026-04-24，史记 Butler 批量导入引文时，覆盖了 136 个页面的手写引文节—— 尽管 CLAUDE.md 里明确写着"不得覆盖"。结论：

prompt 里的规则是软约束，Agent 上下文长了就会遗忘； Harness Hook 里的检查脚本是硬约束，每次工具调用必然触发，无法遗忘。

具体做法：PreToolUse Hook 在每次写入前跑校验脚本（保护节检测、引号规范、单次 diff ≤ 20 行、frontmatter 必填字段）， 不通过就阻止写入并把原因回传给 Agent；PostToolUse Hook 在写入后记录细粒度修订历史（独立于 git 的第二层追踪）。

"单次 diff ≤ 20 行"的价值是控制爆炸半径：即使 Agent 出错，损害也是有界、可回滚的。

6. 方法论的 SKILL 化与自举​

把操作方法提炼为 Markdown 格式的 SKILL 文档（史记积累了 14 个元技能 + 89 个管线技能）。为什么用文档而不是代码？

• 灵活：发现新错误模式，加一条规则即可，后续处理自动获益
• 可读：领域研究者能直接阅读和验证方法论
• 可迁移：元技能层可以直接用于《汉书》《资治通鉴》等新语料
• 自举：知识工程本身可以用知识工程的方法改进

其中"柳叶刀方法"定义了自动化优先级：**能用规则绝不用 LLM，能用代码绝不用人工，LLM 只处理规则覆盖不了的复杂语义，人工只兜底极端案例。**史记最终约 98% 的标注由规则或 LLM 自动完成。

成本数据：57.7 万字的史记完整处理约千元人民币；优化后每 10 万字降到百元级。 以此估算，二十六史（约 4,000 万字）全覆盖约 5–10 万元——从"方法论上不可能"变成"经济上可行"。

四、一张表总结新旧范式​

可进化知识库的完整定义：由 AI Agent 维护的知识系统，本体从原始文本自底向上涌现， 质量通过多层次自动化反思循环持续改进，操作受运行时安全约束保护，方法论以 SKILL 形式沉淀并可跨项目复用。

五、动手清单：如何启动一个可进化知识库​

1. Week 0：3–5 个最核心的实体类型（人、地、事几乎所有领域都需要），处理 5–10% 文本。不求完整，求"可以开始反思"
2. Week 1–2：第一轮反思——哪些类型最频繁？哪些边界最模糊？有没有系统性错误？更新规则和 SKILL
3. Week 3+：广度（覆盖更多文本）与深度（提升已有词条质量分级）并行，每 20–30 轮触发全局反思

五条工程铁律：

1. 尽早配置 Harness——在第一次 Agent 操作前，而不是第一次数据丢失后
2. Frontmatter 第一，正文第二——结构化元数据更容易机器处理和质检
3. 为原文分配 PN 编号
4. 量化一切——没有量化就没有收敛判断
5. SKILL 是一等公民——方法论进化与数据进化同步

延伸阅读​

• Noy & McGuinness (2001). Ontology Development 101. Stanford KSL-01-05.
• 鲍捷 (2026). 史记知识库 / 三体 Wiki / 红楼梦 Wiki
• 原文全文见 memex 仓库 ref/summary/可进化知识库构造.md

传统知识工程的难点是"如何设计完美的本体"； 可进化知识库的难点是"如何设计有效的反思循环"——以及让这个循环本身在项目间传递和进化。

Memex Server 是一个把书自动变成结构化知识库的 AI 编排服务——上传一本 epub/pdf/md/txt， 系统通过多阶段 Agent 流水线（egg → boot → grow → butler）自动生成可检索的 Wiki 站点。

主要能力​

• 四种接入方式：CLI、HTTP API、Web GUI、MCP，满足不同使用场景
• Butler 持续维护：生成完成后，管家在后台按轮次持续补全、提质词条
• 多用户隔离：按用户目录分隔存储，admin/user 角色权限独立
• 实时进度：SSE 订阅流，秒级推送阶段事件和 token 用量

快速上手​

查看 快速开始 文档，5 分钟内跑起来。

有问题或建议，欢迎在 GitLab 提 issue。