本站右下角有一只 Live2D 猫咪——它是访客提问的入口，但不是这篇的重点。这篇要回答的是更底层的问题：
博客文章散落在一篇篇 MDX 里，怎么让 Agent 只基于已写内容作答，而且你能验证它真的答对了？
我的选择是 Open Knowledge Format（OKF）：不是再做一个向量库，也不是每次 query 把全部 Markdown 塞进 prompt，而是把博客知识 编译 成一棵可交换的概念图，再分三层各管一段。OKF 格式本身另文解读；这篇只讲 架构原理。
一分钟版
| 要点 | 内容 |
|---|---|
| 知识真相源 | 博客 MDX 文章——人写的、可 review 的原始稿 |
| 交换格式 | OKF bundle：一个概念一个文件，链接连成知识图 |
| 三层分工 | Authoring 规范 → Build 同步与索引 → 消费侧路由与作答 |
| 核心约束 | 路由阶段只读摘要，作答阶段才读全文 |
| 检索策略 | 倒排索引 + 链接图谱扩展 + LLM 精排（不用向量库） |
| 质量闭环 | 自动生成问题 → 跑引擎 → 引用命中率 + 内容正确性双评分 |
| 拒答原则 | 博客未覆盖的内容明确拒答，不编造 |
总体架构
MDX 文章（真相源）
│
▼ Build：正文同步 + 路由索引
OKF 知识库（摘要元数据 + 全文 + 链接图）
│
▼ 消费：题型检测 → 预过滤 → 倒排召回 → 图谱扩展 → 精排 → 读全文作答
问答结果（答案 + 引用概念）
▲
└── 质量闭环：评测管线反向验证三层并列：Authoring 管「怎么写」、Build 管「怎么编译」、消费 管「怎么答」。评测不是第四层，而是绕回去检验前三层是否真 work 的闭环。
Layer A — Authoring：写的时候就为路由服务
OKF 的消费侧 不扫正文做发现——它先读每个概念的摘要卡片（标题、描述、关键词、标签、类型）。这意味着：authoring 质量直接决定召回。
手写 bundle 时要遵守几条纪律：
- 每个概念有明确的 类型，方便按类过滤；
- 描述和关键词 必须含可检索的实体名——正文里出现但摘要里没有的词，路由阶段根本「看不见」；
- 相关概念 互链，为后面的图谱扩展预埋边。
这是「宽松消费、严格作者」：消费者不应因缺字段拒收 bundle，但作者偷懒会在路由阶段付出代价。
Layer B — Build：把博客编译进 OKF
博客 MDX 是 真相源——作者改文章、走 Git review，OKF 是编译产物，不是第二份要手工维护的 Wiki。
Build 做两件事：
- 正文同步 — MDX 变更时，把归一化后的正文写回对应 OKF 概念；内容 hash 未变则跳过，避免无意义写入。
- 路由索引 — 全库生成倒排表和链接邻接表。运行时 只读索引产物，不在 markdown 文件上全库扫描。
这层把「写作」和「问答」解耦：你继续用熟悉的 MDX 工作流写文章，Build 负责把知识编译成 Agent 能高效消费的形状。
Layer C — 消费：先找对文，再读全文
访客提问进来，引擎按题型分岔：
| 题型 | 路径 |
|---|---|
| 归类（如「有哪些 AI 相关文章？」） | 规则路径：按标签/合集直接返回子集 |
| 事实 / 跨文 | 预过滤 → 倒排 Top-K → 图谱扩展 → LLM 精排 → 加载全文作答 |
事实问答和跨文关联走同一条主干，差别在精排后选几篇、图谱扩展跳几 hop——跨文需要把「A 文引用了 B 文但 B 没被倒排命中」的邻居补进来。
作答阶段的硬约束：
- 只能基于提供的正文——没覆盖就拒答；
- 输出必须带 引用的概念 ID——答案可追溯，也为评测提供硬指标。
拒答或低置信时，引擎 扩大检索范围重试，而不是放宽「不能编造」的底线。
站点若有受保护文章，问答功能整体走 站点门控——未解锁则不可用；解锁后引擎基于全部文章作答。鉴权与知识架构正交，这里不展开。
三条设计护栏
1. 路由 / 全文分离
路由阶段 永远不看正文。摘要卡片和完整概念是两种数据——前者用于「找哪几篇」，后者用于「读了之后怎么答」。
好处很直接：token 可控；更关键的是 防止还没选对文就开始编——如果路由阶段就能读到全文，模型容易「答得像真的」而引用却是错的。
2. 链接图谱扩展
纯倒排索引擅长 模糊命中（关键词对上了），但弱在 关系补全（这篇引用了哪篇、改 A 会影响谁）。
OKF 的概念链接是 预编译好的边。倒排召回 Top-K 之后，沿链接把邻居拉进来——向量 RAG 每次 query 现场「再发现」关系；OKF 模式让关系在 authoring 时就写进图里。
3. 可验证拒答
「博客里没有写到」必须是合法输出，且 citedIds 为空时可机器判定。拒答不是失败，是 可测的行为——评测管线专门生成「博客未覆盖」类问题来检验。
质量闭环：怎么知道它答对了
架构画完不等于能上线。我加了一条 评测回路：
- 从每篇文章 自动生成 测试问题，附带期望引用的概念和参考答案；
- 批量跑引擎，支持断点续跑；
- 双指标评分——引用 ID 命中率（硬指标）+ LLM 评判内容正确性（软指标）。
路由 recall 是 门禁：找错文或漏选，后面作答再漂亮也是零分。早期评测暴露的典型失败是——正文里有某个技术词，但摘要/metadata 没收录，路由阶段「看不见」→ 误拒答。这反过来驱动 Authoring 和 Build 改进（自动提取关键词写回 frontmatter），而不是在消费侧无限加 prompt 魔法。
和相近方案对比
| 方案 | 优点 | 局限 |
|---|---|---|
| 纯 RAG 扫 MDX | 实现快，不用维护第二份知识 | 无预编译关系，跨文关联弱；每次 query 重新检索 |
| 纯 LLM 选文 | 链路短 | 摘要不含正文词时漏选；不可解释、难评测 |
| OKF 三层 + 图谱 | 可解释、可评测、可扩展；写作与消费解耦 | 需要 authoring 与 build 纪律 |
一句话
OKF 把博客知识 编译 成可交换的概念图；Authoring、Build、消费各管一段，路由与全文严格分离；评测闭环保证这不是「能 demo 的猫咪」，而是 可验证的问答系统。
延伸阅读：卡帕西强推的 LLM Wiki，终于有了通用格式——谷歌发布 OKF（OKF 格式规范解读，与本文互补）