从知识库到推理引擎——WikiLLM 架构 × Multi-Agent 设计 × Evals 质量体系，一次讲透
一只阿木木约 33 分钟从知识库到推理引擎：IP 创作知识系统的技术深潜完全指南
——WikiLLM 架构 × Multi-Agent 设计 × Evals 质量体系，一次讲透
写在前面：你的知识库为什么能工作（WikiLLM 架构原理）；怎么让多个 AI 协作而不互相干扰（Multi-Agent 设计）；以及你怎么知道系统在变好而不是变坏（Evals 质量体系）。
开篇：你的知识库是"数字书架"还是"推理引擎"？
让我从一个让很多人困惑的问题开始：
"我已经搭建了 Obsidian Vault，放了很多知识进去——但为什么 AI 生成的内容还是经常'不对'？"
这个问题背后，是一个根本性的认知误区：大多数人把知识库当成了更大的 U 盘。
往里放越多东西，以为 AI 就能找到越多。结果放到一定程度，发现 AI 开始"迷失"——它读了太多，但记住的是错的；它检索到了相关片段，但无法把它们连接成完整的推理。
2026 年，这个问题有了清晰的技术答案。
这是 2026 年的知识检索问题：强大的工具存在，但没有清晰的选择框架。真正的问题不是选哪个工具，而是：推理工作应该在哪里发生——以及这个选择带来什么代价？
这篇文章，要把这个问题从根本上讲清楚。
第一章：三种知识系统的本质差异——你用的是哪种？
在理解 WikiLLM 之前，我们需要先建立一个完整的技术地图：知识系统的三种主要架构，以及它们各自能解决什么问题、不能解决什么问题。
1.1 架构一：经典 RAG（检索增强生成）
工作原理：
你的知识被切成"块"（chunks），每一块被转化成一个向量（embedding），存进向量数据库。当你问问题时，系统把问题也转成向量，在数据库里找相似的块，把这些块塞进上下文，让 AI 基于这些块回答。
在经典 RAG 里，每一个新问题都让 LLM 重新开始：索引、检索、综合。模型在每个问题上"从头重新发现知识"，没有任何积累。LLM Wiki 模式把重心转移了：与其每次从原始文档重新生成答案，不如让模型建立并维护一个随时间增长的持久化 Markdown Wiki。
RAG 的致命弱点——语义密度失败：
向量检索是大多数 RAG 系统的主力，但它与多跳推理任务存在根本性的架构错配。2026 年的一项分析直白地指出：核心问题是研究者所称的"语义密度失败"——嵌入空间会把逻辑上不同但语义相似的关系压缩坍塌。知识图谱可以避免这些失败，因为它存储的是显式的、有类型的关系，而不是几何距离。
对 IP 创作者，这意味着什么？
想象你问："在第二纪元末期，主角所在势力的核心矛盾是什么？"
RAG 系统会检索所有"第二纪元"相关的块，所有"主角"相关的块，所有"势力矛盾"相关的块——然后试图拼接它们。但"第二纪元的主角势力的核心矛盾"这个跨三个维度的推理，需要的不是更多相似的块，而是理解三个维度之间的关系。
切分可能会主动破坏结构化内容的连贯性。LLM Wiki 保留了它。
RAG 的优势：速度快，成本低，适合简单的事实性检索。
RAG 的劣势：多跳推理弱，知识不积累，每次回答都从零开始。
RAG 配置的设置代价是巨大的：
设置一个 RAG 流水线需要：选择向量数据库，挑选嵌入模型，编写摄入脚本，处理切分策略，调整检索参数，构建评估循环来检查检索质量。对于一个非平凡的知识库，这需要数天的工作。而一个 Markdown Wiki 可以在一个下午内运转起来。
1.2 架构二：Agent 记忆（Session Memory）
工作原理：
AI Agent 在会话中记录关键信息，存成记忆条目，下次对话时加载相关记忆。
根本限制：
聊天机器人会忘记。每次对话都从新开始。
即使有了会话记忆，它解决的是"记住用户"的问题，但仍然无法跨会话综合知识。记忆是用户画像，不是知识图谱。
你加入了记忆。更好了，但现在 Agent 记住了用户，仍然无法跨会话综合知识。
适用场景：个性化对话助手，需要记住用户偏好的场景。
不适用：需要深度知识推理、跨主题连接、长期知识积累的场景。
1.3 架构三：LLM Wiki（智能知识编译系统）
工作原理：
LLM 是一个编译器，不是对话伙伴。你给它原始材料，它产出结构化知识。输出是你永远拥有的纯 Markdown 文件。
这是根本性的范式转变：
RAG：每次问题 → 即时检索 → 即时回答（知识不积累） LLM Wiki：持续摄入 → 编译成知识页面 → 知识网络持续增长 → 基于知识网络回答（知识在积累）
LLM Wiki 模式（由 Andrej Karpathy 在 2026 年 4 月 4 日的 gist 中提出）用一个由 LLM 增量维护的持久化 Markdown Wiki 替代了临时的 RAG 重新生成。三个层次（来源、Wiki、模式）、摄入/查询/检查工作流、工具：Obsidian、Git、qmd。
1.4 三种架构的决策矩阵
| 设置复杂度 | 低（Markdown 文件） | ||
| 知识积累性 | 高（持续复利） | ||
| 多跳推理 | 强（显式链接） | ||
| 可审计性 | 高（可读文件） | ||
| 版本控制 | 易（Git） | ||
| 成本 | 一次编译，低成本查询 | ||
| 适合 IP 创作 | ✅ |
Markdown Wiki 存在于一个文件夹里。你可以把它提交到 Git，审阅差异，分配所有权，随时间追踪变化。非技术团队成员可以用任何文本编辑器贡献内容。向量数据库，相比之下，是一个黑箱。
第二章：WikiLLM 深度解剖——知识是怎么被"编译"的
2.1 Karpathy LLM Wiki 的核心思想
Andrej Karpathy 发布了一条推文，悄悄打破了 AI 社区对我们应该如何用 LLM 管理知识的理解。两天后，他发布了一个 GitHub gist 叫做 llm-wiki.md。这个想法不是一个产品，不是代码，而是一个模式——一个特殊的模式，可能帮助你在几分钟内创建一个小规模的个人知识库。
核心洞见在一句话里：
模型在每个问题上"从头重新发现知识，没有任何积累"。LLM Wiki 模式把重心转移了：与其每次从原始文档重新生成答案，不如让模型建立并维护一个随时间增长的持久化 Markdown Wiki。
2.2 三层架构详解
知识库的组织方式是三层架构：原始来源（你不可变的阅读材料）、Wiki（LLM 生成的摘要页面、交叉引用和概念图）、以及模式（将 Claude 从通用聊天机器人变成有纪律的 Wiki 维护者的 CLAUDE.md 文件）。数据在层之间流动，这个结构让整个系统运作。
让我对 IP 创作者深度解剖这三层：
第一层：原始来源层（Raw Sources）
这一层的核心原则只有一个：不可变。
原始素材一旦进入 _raw/，就不应该被修改。它是你的知识系统的"事实基础"——你收集的一手资料、你的灵感记录、你保存的参考文章。
/raw — 不可变的来源材料。Web 摘录、转录、文章。文件落地后不做任何编辑。
为什么"不可变"如此重要？
因为 Wiki 层的内容是从这里编译出来的。如果你修改了原始素材，那么 Wiki 的内容就失去了可追溯性——你不知道 Wiki 里的某条信息"是从哪里来的"。
原始层的文件类型，对 IP 创作者来说包括：
text
📁 _raw/
├── clippings/ ← 网页摘录（世界观参考/写作技巧/行业资讯）
├── voice/ ← 语音灵感（你在外出时突然想到的设定）
├── research/ ← 参考论文/书籍摘录（历史/文化/科学背景）
├── images/ ← 视觉参考（附 description.md 说明用途）
└── processed/ ← 已编译进 Wiki 的文件（归档区）
第二层：Wiki 编译层（Compiled Knowledge）
这是整个系统的核心。
Wiki — AI 生成的 Markdown 页面。这些是结构化的输出：概念页面、实体页面、综合页面、比较页面。Agent 在处理 /raw 的文件时创建和更新这些页面。
当一个原始文件进入系统，编译过程产生四种类型的页面：
类型一：实体页面（Entity Pages）
为每一个具名实体创建一个页面：角色、地点、势力、物品、事件。
Markdown
---
type: entity
entity-type: character
name: 李明远
status: active
tags: [主角, 势力A, 第三纪元]
first-mention: [[_raw/processed/故事设定初稿]]
created: 2026-06-15
---# 李明远
## 核心定义
[实体的核心定义，100字以内]
## 关键属性
- 身份：[[势力A]] 的核心成员
- 能力：[[力量系统-基础]] 的进阶使用者
- 关系：[[角色B]] 的师兄
## 相关事件
- [[事件-第一战役]] 中的关键角色
- [[故事线-主线第三章]] 的核心驱动
## 来源
- [[_raw/processed/故事设定初稿]]
类型二：概念页面（Concept Pages）
为抽象概念、规则系统、机制原理创建页面。
Markdown
---
type: concept
category: world-rule
tags: [力量体系, 宇宙法则]
related-entities: ["[[李明远]]", "[[角色B]]"]
---# 力量系统-基础
## 定义
[概念的精确定义]
## 运作规则
1. [规则一]
2. [规则二]
## 限制条件
- [限制一]
- [限制二]
## 相关概念
- 进阶形态：[[力量系统-进阶]]
- 反面：[[禁术系统]]
## 来源
- [[_raw/processed/世界观设定-力量体系]]
类型三：综合页面（Synthesis Pages）
将多个来源的相关内容整合成新的洞见——这是 Wiki 超越简单归档的关键。
Markdown
---
type: synthesis
topic: 主角成长弧
sources: ["[[设定文档A]]", "[[参考分析B]]", "[[受众反馈C]]"]
generated: 2026-06-15
---# 主角成长弧综合分析
## 综合洞见
[跨多个来源的整合洞见，不在任何单一来源中存在]
## 各来源观点对比
| 维度 | 来源A的观点 | 来源B的观点 | 综合判断 |
|---|---|---|---|
## 待验证的假设
- [需要更多证据的推断]
类型四：比较页面（Comparison Pages）
对同一主题的不同观点、不同设计方案进行横向比较。
Markdown
---
type: comparison
comparing: [魔法系统设计方案A, 魔法系统设计方案B]
---# 魔法系统设计对比
## 核心差异
[两个方案的根本区别]
## 各维度对比
[结构化比较]
## 推荐方向
[基于 IP 需求的判断]
第三层：模式层（Schema / CLAUDE.md）
agents.md — 提示文件。这是每一个 Agent 行为的操作规格：如何摄入来源，如何回答查询，如何处理 YouTube 视频，如何处理 CRM 条目。它读起来像一本纯英文的操作手册，因为它就是。
这就是你的 CLAUDE.md 和 SKILL.md 文件——它们是整个知识编译流程的"编译器配置"。没有这一层，AI 会把你的 Vault 当成普通文件夹。有了这一层，AI 知道：
什么格式是标准格式（frontmatter 规范） 什么内容去哪个文件夹 发现矛盾时怎么处理 怎么创建交叉链接
2.3 编译过程的三个操作
系统运行的三个核心斜线命令：/ingest-url（输入一个 URL，Claude 提取文章并将其编译进 Wiki，在单次处理中触碰 5-15 个页面）、/process-inbox（随手记录和快速笔记自动分类和整合）、以及 /lint-wiki（一个健康检查，找出断链、孤立页面、矛盾，以及 Wiki 建议你接下来研究的内容空白）。
让我把这三个操作翻译成 IP 创作者的具体流程：
操作一：/ingest（摄入新素材）
text
触发：有新素材进入 _raw/执行流程：
1. 读取原始文件
2. 提取关键实体（人物/地点/概念/事件）
3. 对每个实体：
- 如果已有页面 → 检查是否需要更新
- 如果是新实体 → 创建新页面
4. 创建概念页面（抽象的规则/机制）
5. 识别跨实体关系 → 在相关页面添加 wikilink
6. 更新 index.md
7. 移动原始文件到 _raw/processed/
8. 在 log.md 记录
操作二：/query（知识查询）
text
触发：你提出一个问题执行流程：
1. 解析问题中的实体和概念
2. 检索相关 wiki 页面（不是原始文件！）
3. 沿着 wikilink 进行多跳推理
4. 综合多个页面的信息生成回答
5. 将这次查询的洞见创建新的综合页面
（查询行为本身在扩展知识库）
6. 更新 index.md
查询保持聚焦。多 Wiki 预览在相关时跨主题找到重叠。
操作三：/lint（健康检查）
text
触发：定期（每周一次）或手动检查项目：
1. 断链检测：[[引用了不存在的页面]]
2. 孤立页面：存在但没有被任何页面引用的页面
3. 矛盾检测：不同页面对同一实体的描述冲突
4. 内容空白：多次被引用但还没有独立页面的概念
5. 过时内容：来源已更新但 wiki 页面未同步
输出：
- graph-health.md（量化的知识库健康报告）
- 待处理的矛盾清单
- 建议创建的新页面清单
Python 层产出一个持久化的 graph-health.md。
2.4 知识图谱的可视化——Obsidian 图谱视图的真正价值
安装 Obsidian，创建新 Vault，把它指向你的 llm-wiki 文件夹，打开图谱视图。你现在看到的是你的知识作为一个网络。节点是页面，边是 Claude 自动添加的链接。
但图谱视图有一个重要的使用警告：
Obsidian 图谱视图可能让知识库看起来比实际上更聪明。
图谱视图不是目的，是诊断工具。真正有意义的是：
反向链接和外向链接因此展示了两个不同的上下文方向。反向链接显示哪些页面指向当前页面，外向链接显示当前页面指向哪些页面。它们合在一起，帮助我们理解一个概念如何在 Wiki 内部被使用以及它连接到哪里。
对 IP 创作者的实际意义：
反向链接多的节点 = 核心概念（很多地方都引用它）→ 需要特别维护质量 孤立节点 = 信息孤岛（没有被引用）→ 要么删除，要么补充连接 链接密度 = 知识成熟度（越密集，推理质量越高）
完整图谱视图会很快变得拥挤，所以当你想检查某个概念的邻域时，局部图谱（Local Graph）往往更有用。
第三章：RAG vs LLM Wiki
3.1 盲判实验的结论
(https://arxiv.org/html/2605.18490v1)这篇论文报告了一项预注册、盲判的两评委对比，在固定的 24 篇论文语料上，用 13 个评估问题跨越六个难度层级对 Vector RAG 和 LLM Wiki 进行比较。两个系统使用同一个查询模型（Claude Opus 4.7）；交叉评委是 GPT-5.4，用 Gemini 2.5 Pro 进行评委间可靠性验证。
约 3.4 倍更低的每次查询 LLM token 成本；Wiki 保留了最强的 LLM 评分的证据-文物声明-引用对齐，但每次查询成本高，且待来源 PDF 验证。
简单翻译：LLM Wiki 在知识质量和引用准确性上胜出，RAG 在每次查询成本上胜出。
3.2 针对 IP 创作者的具体对比
用 IP 创作场景来真实对比：
测试场景：你正在写第五章，需要确认"角色 A 在第二纪元末期所处的势力内部矛盾，如何影响了他在第一战役的决策"。
RAG 的回答路径：
向量检索"角色 A"、"第二纪元末期"、"势力内部矛盾"、"第一战役" 返回每个主题的 top-k 相似块 把 4 组不相关的块拼接进上下文 AI 尝试综合这些块
问题：这四个主题的关联关系没有被检索到，只有各自的内容。AI 需要在回答时即时推断关系，极易产生不一致。
LLM Wiki 的回答路径：
读取 wiki/characters/角色A.md（包含first_appearance,affiliation,decision-log）沿着 [[势力A]]链接读取势力设定沿着 [[事件-第一战役]]链接读取事件记录三个页面都在编译时已经建立了显式的关联描述
结果：回答基于显式建立的知识关系，而不是向量相似度猜测。
深层问题不是选哪个工具，而是：推理工作应该在哪里发生——以及这个选择的代价是什么？
答案对 IP 创作者来说很清楚：推理应该在编译时发生（LLM Wiki），不是在查询时发生（RAG）。原因：IP 世界观的推理需要精确的、显式的关系，而不是向量相似度估计。
3.3 混合架构：何时需要同时用两者
并不是说 RAG 毫无用处。最优的 IP 创作知识系统，可能是这样的混合：
text
┌─────────────────────────────────────────────┐
│ 混合知识系统架构 │
│ │
│ LLM Wiki（主力） │
│ └── wiki/ → 结构化的IP知识图谱 │
│ 用途：世界观推理/角色一致性/设定查询 │
│ │
│ 轻量 RAG（辅助） │
│ └── _raw/ → 原始文献的语义搜索 │
│ 用途：在原始来源中找参考段落 │
│ 工具：Smart Connections 插件 │
│ │
│ Agent 记忆（补充） │
│ └── journal/ → 会话上下文记忆 │
│ 用途：记录你今天在做什么项目 │
└─────────────────────────────────────────────┘
每个人都问的问题是：这实际上比 RAG 更好吗？诚实的答案是：两者都没有赢。它们解决不同的问题。
第四章：Multi-Agent 制造者-检查者架构
4.1 为什么单 Agent 不够用
系列 B 建立的系统使用单个 Agent 运行所有 Loop——摄入素材、编译 Wiki、生成内容、检查一致性。对于初期系统，这足够了。
但随着知识库增长，单 Agent 系统会遇到一个根本性的问题：
Agent 无法有效地检查自己的工作。
当同一个 Agent 既是"写手"又是"审稿人"，它会不自觉地对自己的输出产生认知偏差——它"知道"自己想表达什么，所以即使实际输出存在问题，它也倾向于"读出"正确的意思。
这不是 AI 的特有问题，这是认知科学的基本发现：自我审核比外部审核的效果差很多。
解决方案：制造者-检查者（Maker-Checker）双 Agent 架构。
4.2 Maker-Checker 架构详解
我们的编码工作流使用 Claude Code 的多 Agent 能力实现。在高层次上，我们采用集中式协调者-工作者范式（通常称为 hub-and-spoke 模式）：一个主 Claude 实例（"管理者"）协调几个各自有自己上下文和角色的专业子 Agent。Claude 的框架允许通过简单的 YAML/Markdown 文件定义这些 Agent。
对 IP 创作知识库，Maker-Checker 架构是这样设计的：
text
┌─────────────────────────────────────────────────────┐
│ IP 创作知识库 · Maker-Checker 架构 │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ MAKER Agent │ │ CHECKER Agent │ │
│ │ │ │ │ │
│ │ 职责：生产内容 │───>│ 职责：验证质量 │ │
│ │ │ │ │ │
│ │ 使用模型： │ │ 使用模型： │ │
│ │ claude-sonnet │ │ claude-opus │ │
│ │ （快速，经济） │ │ （慢速，精准） │ │
│ └─────────────────┘ └────────┬────────┘ │
│ │ │
│ ┌─────────────┼─────────────┐ │
│ │ │ │ │
│ PASS FAIL FLAG │
│ │ │ │ │
│ 归档/发布 退回重写 人工审核 │
└─────────────────────────────────────────────────────┘
4.3 agents.md 设计——为 IP 创作定制
agents.md 是各 Agent 的角色定义文件。放在 Vault 根目录，所有 Agent 启动时读取。
Markdown
# IP 创作知识库 · Agent 角色定义
> 版本: 2.0 | 最后更新: 2026-06-15---
## Agent 总览
| Agent 名 | 角色 | 使用模型 | 主要职责 |
|---|---|---|---|
| Wiki-Maker | 知识编译者 | claude-sonnet | 摄入素材，编译Wiki，生成草稿 |
| Consistency-Checker | 一致性守护者 | claude-opus | 验证世界观一致性，检测矛盾 |
| Voice-Checker | 声音守护者 | claude-opus | 验证角色声音，检测语言风格偏差 |
| Audience-Analyst | 受众分析师 | claude-haiku | 分析受众数据，生成洞察报告 |
| Orchestrator | 编排者 | claude-opus | 协调其他Agent，决定任务分配 |
---
## Agent 详细定义
### Wiki-Maker（知识编译者）
职责范围：
- 处理 _raw/ 中的原始素材
- 创建和更新 wiki/ 中的知识页面
- 生成 projects/ 中的内容草稿
工作限制：
- 不评估输出质量（这是 Checker 的工作）
- 不修改 publish/ 中的内容
- 发现不确定内容时，标记 [?] 而不是猜测
- 每次操作后在 log.md 记录
输出标准：
- 所有新文件必须有完整 frontmatter
- 所有引用必须使用 [[wikilink]] 格式
- 新增实体必须在 index.md 注册
触发条件：
- cron：每小时处理 _raw/ 新文件
- 手动：用户明确要求创建内容
---
### Consistency-Checker（一致性守护者）
职责范围：
- 验证 Wiki-Maker 的输出与已有设定的一致性
- 检测世界观矛盾
- 运行定期的全库一致性审计
判断标准（按优先级）：
1. 违反 wiki/world/rules.md 中的宇宙法则 → 严重（FAIL）
2. 时间线逻辑矛盾 → 中等（FLAG）
3. 角色能力描述不一致 → 中等（FLAG）
4. 细节描述差异（颜色/外貌等） → 轻微（WARN）
输出格式：
PASS：内容通过审核，附简短说明
FAIL：[原因] [具体矛盾位置] → 退回 Wiki-Maker
FLAG：[原因] [位置] → 写入 log.md，等待人工裁决
工作原则：
- 只报告，不裁决（矛盾的解决是人工的工作）
- 每个 FAIL 必须有具体的证据引用
- 不因"感觉不对"就 FAIL，必须有设定文件的明确依据
触发条件：
- Wiki-Maker 完成每次摄入后自动触发
- cron：每周日 3:00 全库审计
---
### Voice-Checker（声音守护者）
职责范围：
- 验证生成内容的创作声音是否符合 CLAUDE.md §4
- 检测角色对话是否符合人物卡定义
- 评估语言风格与 IP 整体风格的一致性
判断维度：
1. 叙事声音（视角/时态/句式）
2. 角色声音（语言习惯/词汇偏好/禁忌词）
3. 情感表达方式（外化/直叙）
4. 绝对禁止清单（CLAUDE.md §4 中定义）
输出格式：
PASS：声音一致，可进入发布流程
FAIL：[具体问题] [建议修改方向]
WARN：[细节差异，不影响整体]
工作原则：
- 基于 CLAUDE.md 的具体定义，不主观评价"好坏"
- 比较的基准是 publish/ 里已发布内容的风格，不是一般写作标准
触发条件：
- 内容进入 review 状态时自动触发
- 用户手动调用 /voice-check
---
### Audience-Analyst（受众分析师）
职责范围：
- 分析 crm/audience/ 数据
- 生成受众洞察报告
- 评估内容与受众匹配度
工作原则：
- 使用数据说话，不假设
- 报告中的每个结论必须有数据来源
- 分清"已知事实"和"推断"，分别标注
触发条件：
- 有新受众反馈数据时
- 内容即将发布时（匹配度评估）
- cron：每月第一天生成月度洞察报告
---
### Orchestrator（编排者）
职责范围：
- 接受用户的高层次目标
- 分解任务，分配给对应的子 Agent
- 监控任务进度
- 处理子 Agent 之间的依赖关系
决策框架：
1. 任务是什么类型？（摄入/生成/检查/分析/发布）
2. 需要哪些 Agent？
3. 执行顺序是什么？（依赖关系）
4. 什么是完成标准？
5. 出现 FAIL 时的升级策略是什么？
日志要求：
每次任务启动时在 log.md 记录：
[日期] [Orchestrator] 任务启动：[任务描述]
分配：[任务] → [Agent]
工作边界：
- 不直接执行内容操作（由子 Agent 执行）
- 出现超出授权范围的情况，暂停并通知用户
4.4 Managed Agents API 配置（技术实现）
如果你使用 Claude API，这是最新的 Multi-Agent 配置方式：
所有 Agent 共享同一个沙箱、文件系统和 Vault 凭证，但每个 Agent 在自己的会话线程中运行——一个有自己对话历史的上下文隔离事件流。协调者在主线程中报告活动；当协调者委托工作时，会在运行时生成额外的线程。
这对 IP 创作者的实际意义：
共享文件系统 = 所有 Agent 都能读写同一个 Vault 独立会话线程 = Wiki-Maker 和 Consistency-Checker 不会互相"污染"记忆 主线程报告 = 你在主界面看到整体进度，细节在子线程
4.5 Maker-Checker 的工作流示例
让我用一个真实的例子说明 Maker-Checker 如何工作：
场景：你发现了一篇关于"权力结构与人性"的哲学文章，想把它的核心洞见整合进你的反派角色设定。
text
你：将 _raw/clippings/权力结构分析.md 的洞见整合进角色B的人物卡├── Orchestrator 分解任务
│ ├── Task 1: Wiki-Maker 读取文章，提炼相关洞见
│ └── Task 2: Consistency-Checker 验证新洞见与已有角色B设定的一致性
│
├── Wiki-Maker 执行 Task 1
│ ├── 读取文章
│ ├── 提炼：3个与角色B相关的心理洞见
│ ├── 草拟角色B人物卡的更新内容（新增"权力心理"章节）
│ └── 输出到临时文件，等待检查
│
├── Consistency-Checker 执行 Task 2
│ ├── 读取角色B现有人物卡
│ ├── 读取 wiki/world/rules.md（宇宙法则）
│ ├── 检查新洞见
│ │ ├── 洞见1：与已有设定一致 → PASS
│ │ ├── 洞见2：与角色B的"价值观边界"定义有潜在冲突 → FLAG
│ │ └── 洞见3：与已有设定一致 → PASS
│ └── 输出报告：PASS（1个FLAG需人工确认）
│
├── Orchestrator 汇总
│ ├── 洞见1和3可以直接整合
│ ├── 洞见2的冲突写入 log.md，等待你裁决
│ └── 通知你：整合完成，1个矛盾需要你决策
│
└── 你：查看矛盾，决定如何处理
└── 更新角色B人物卡（选择保留旧设定或采用新洞见）
这个流程保证了：知识在积累，同时设定的一致性在守护，而需要创作判断的地方，控制权始终在你手里。
第五章：/goal 命令与多回合 Loop 设计
5.1 /goal 命令的工作原理
Claude Code 在 2026 年 5 月 11 日的 v2.1.139 版本中加入了 /goal 命令，这是一个跨回合运行的原生 Loop，直到你写的条件为真时停止，并在每次回合后用一个单独的快速模型对工作进行评分。 16 Codex 在 CLI 0.128.0（4 月 30 日发布）中发布了同样的原语，加上一个 Automations 标签和一个分类收件箱。
这是什么意思？
在 /goal 之前，Loop 的"完成判断"是：
你手动检查输出 或者简单的文件存在性检查（"如果文件存在 = 成功"）
在 /goal 之后，每次迭代结束，有一个独立的快速模型作为评委，根据你定义的条件判断目标是否达成。这个评委模型不是同一个 Agent——它专门负责评分，和生产内容的 Agent 分离。
难的不是自主性本身，而是验证、停止条件，以及人在循环中的升级。
5.2 为 IP 创作设计 /goal 条件
/goal 的关键设计点是停止条件。写好停止条件，比写好执行指令更重要。
一个好的停止条件有三个特征：
可测量：评委模型能客观判断（不是"内容好不好"，而是"内容是否满足X标准"） 充分但不过度：条件达成时，工作真的完成了 有失败分支：最大迭代次数，防止无限循环
IP 创作的 /goal 设计示例：
text
/goal 对象：整合本周所有新角色设定到 wiki/characters/停止条件：
✅ _raw/ 中所有本周新增的角色相关文件已被处理（status: processed）
✅ wiki/characters/ 中对应的页面已创建或更新
✅ 每个新页面都有完整的 frontmatter
✅ 每个新页面都有至少 2 个 wikilink 指向相关设定
✅ Consistency-Checker 对每个新页面运行完毕，无 FAIL
失败分支：
❌ 超过 20 次迭代仍未完成 → 停止，报告当前状态
❌ 连续 3 次 Consistency-Checker FAIL 同一个位置 → 停止，等待人工
❌ 处理过程中发现严重矛盾（宇宙法则冲突）→ 立即停止，写入 log.md
评委模型：claude-haiku（快速，低成本）
生产模型：claude-sonnet（质量，经济平衡）
审核模型：claude-opus（精确，高成本，只在最终审核时使用）
5.3 多回合 Loop 的成本控制
有几种值得了解的标准 Loop 架构，每种适合不同任务类型。最简单的模式：Agent 尝试某件事，检查是否成功，如果不成功就重试。何时使用：有明确通过/失败标准的短的、原子性任务。
成本控制的三个策略：
策略一：模型分层
不同任务用不同成本的模型：
策略二：迭代次数硬限制
每个 Loop 必须设置最大迭代次数，防止 token 无限消耗：
YAML
loop:
max_iterations: 15 # 最多运行15次
budget_tokens: 100000 # 最多消耗10万token
time_limit: 30min # 最多运行30分钟
on_exceed: stop_and_report # 超出后停止并报告
策略三：批处理而非逐一处理
把多个小任务合并成一个大的 Loop 运行，而不是为每个文件单独启动一个 Loop：
text
❌ 低效：每个 _raw/ 文件单独调用 API
✅ 高效：一次 Loop 处理所有新文件，批量操作
第六章：Evals——让你的知识库质量可度量
6.1 为什么 Evals 是最被忽视的关键环节
随着 AI Agent 进入生产，评估不再是可选的。根据 LangChain 的 2026 年 AI Agent 状态报告，57% 的组织现在有 Agent 在生产中运行，质量被 32% 的受访者列为部署的首要障碍。
没有 Evals 的系统，就像没有仪表盘的汽车：你以为在前进，但不知道速度是多少，油量还剩多少，发动机是否过热。
对 IP 创作知识库，Evals 回答三个关键问题：
知识库是在变好还是在变坏？（知识质量） AI 生成的内容是否真的一致？（生成质量） 系统的运行是否在正轨上？（系统健康）
6.2 知识库质量的四个核心指标
指标一：链接密度（Link Density）
定义：平均每个 wiki 页面有多少个 wikilink（包括入链和出链）
计算方式：
text
链接密度 = 总 wikilink 数 / 总 wiki 页面数
基准值：
<2 链接/页面：知识库是孤立节点集合，几乎没有推理价值 2-5 链接/页面：基础连接，能支撑简单查询 5-10 链接/页面：良好连接，能支撑多跳推理 10 链接/页面：高密度网络，推理能力强（但要排查无意义链接）
在你的 graph-health.md 里追踪：
Markdown
# 知识库健康报告 - 2026-06-15## 链接密度
- 本周：6.3 链接/页面 ↑ (上周 5.8)
- 趋势：↑ 连续四周增长
- 警告：wiki/characters/ 分类密度仅 3.2，需要补充链接
## 孤立页面
- 总数：12 个（占 wiki 页面的 4.2%）
- 本周新增：2 个
- 建议：运行 /lint-wiki 补充链接或删除冗余页面
指标二：一致性评分（Consistency Score）
定义：每周 Consistency-Checker 运行结果的量化评分
计算方式：
text
一致性评分 = (PASS数量 / 总检查数量) × 100严重程度加权：
- FAIL：扣 10 分
- FLAG：扣 3 分
- WARN：扣 1 分
基准值：
<70 分：知识库有系统性矛盾，需要大规模修复 70-85 分：有待解决的矛盾，正常运营 85-95 分：知识库健康，少量细节需要维护 95 分：理想状态（但要警惕评委太宽松）
指标三：覆盖完整性（Coverage Completeness）
定义：你的 IP 核心概念有多少比例已经有了完整的 wiki 页面
计算方式：先定义你的 IP 核心概念清单（角色/地点/势力/规则/事件），然后检查每个概念是否有：
text
✅ 独立页面
✅ 完整 frontmatter
✅ 核心定义段落（>100字）
✅ 至少3个 wikilink
基准值：
<50%：知识库处于早期阶段，正常 50-80%：中期发展，核心内容在建设中 80%：成熟知识库，进入维护阶段
指标四：知识新鲜度（Knowledge Freshness）
定义：有多少 wiki 页面的 updated 日期已经超过 30 天
计算方式：
text
新鲜度 = 30天内有更新的页面 / 总页面数Dataview 查询：
TABLE updated, datediff(date(today), updated, "days") as 距上次更新天数
FROM wiki/
WHERE datediff(date(today), updated, "days") > 30
SORT 距上次更新天数 DESC
行动触发：如果核心实体页面超过 60 天未更新，可能意味着：
你的 IP 设定有重大演变但未同步到 wiki 该实体已经不重要了（可以归档）
6.3 生成质量的 LLM-as-Judge 评估
Critic（LLM-as-Judge）：评估草稿。如果置信度分数低于 0.85，触发"重写"Loop，返回检索器。
对 IP 创作，LLM-as-Judge 的评估维度应该是这样设计的：
评估框架设计：
Markdown
---
# IP 创作内容评估框架 v1.0
# 使用方式：每次草稿完成后，由 claude-opus 作为评委评分评估维度及权重：
1. 世界观一致性（35%）
- 是否违反 wiki/world/rules.md 中的宇宙法则？
- 时间线是否自洽？
- 地理/势力描述是否与 wiki 一致？
评分标准：
- 5分：与所有已知设定完全一致
- 3-4分：有小细节不一致，但不影响逻辑
- 1-2分：有设定冲突，需要修正
- 0分：违反宇宙法则，必须重写
2. 角色声音准确度（30%）
- 每个角色的对话是否符合人物卡定义？
- 性格表现是否一致？
- 语言习惯是否准确？
评分标准：
- 5分：每个角色声音清晰可辨，符合人物卡
- 3-4分：大体准确，有1-2处细节偏差
- 1-2分：角色声音模糊或有明显偏差
- 0分：角色行为违背已建立的核心特质
3. 叙事声音一致性（20%）
- 是否符合 CLAUDE.md §4 的创作声音指南？
- 是否触犯"绝对禁止"清单？
- 整体风格是否与已发布内容一致？
评分标准：
- 5分：叙事声音与已发布内容高度一致
- 3-4分：整体风格正确，有细节调整空间
- 1-2分：风格有明显偏差，需要较多修改
- 0分：触犯绝对禁止清单，必须重写
4. 内容价值密度（15%）
- 对受众的核心价值是否清晰？
- 信息密度是否适合目标平台？
- 是否有冗余或低价值的段落？
评分标准：
- 5分：每段都有明确价值，无冗余
- 3-4分：核心价值清晰，有少量可删减内容
- 1-2分：价值密度不足，需要大量精简
- 0分：核心价值不清晰，需要重新构思
综合评分 = (维度1分×35% + 维度2分×30% + 维度3分×20% + 维度4分×15%) × 20
通过标准：综合评分 ≥ 80分（满分100分）
审核触发：任何单一维度得0分 → 立即 FAIL，不看综合分
输出格式：
PASS [综合分数] [各维度分数] [1-2句改进建议]
FAIL [失败维度] [具体原因] [必须修改的内容]
---
6.4 系统健康指标——让 Loop 自我诊断
自定义 span 元数据——把 critic_score、iteration_count、retrieval_round 和 token_budget_used 附加到每次追踪上，用于聚合质量监控。成本归因——记录模型层级、token 数量和每个节点的预估成本。检索质量指标——记录重排序前后的块评分；监控 avg_chunk_score、retrieval_miss_rate 和 graph_hit_rate。
对 IP 创作知识库，系统健康指标包括：
Markdown
# 系统健康日报 - 自动生成
生成时间: 2026-06-15 22:00## Loop 运行状态
| Loop | 今日运行次数 | 成功率 | 平均耗时 | Token消耗 |
|---|---|---|---|---|
| 素材摄入 | 24次 | 100% | 2.3分钟 | 1,200/次 |
| 日志生成 | 1次 | 100% | 1.1分钟 | 800/次 |
| 一致性检查 | 0次 | - | - | - |
## 知识库增长
- 今日新增 wiki 页面：3个
- 今日更新 wiki 页面：7个
- 今日处理原始素材：5个
- 当前总 wiki 页面：142个
## 质量信号
- 今日 Consistency-Checker 通过率：94.4%
- 今日发现新矛盾：2个（已写入 log.md）
- 待人工处理的 FLAG：3个
## 资源使用
- 今日 Token 总消耗：28,400
- 本月累计消耗：312,000
- 预估月成本：$4.7
- 预算使用率：47%
## 待处理事项
⚠️ log.md 中有 3 个 FLAG 等待人工决策
⚠️ wiki/characters/角色C.md 超过 45 天未更新
ℹ️ _raw/ 中有 2 个文件处于 unprocessed 状态超过 24 小时
6.5 Evals 的演进：从规则到模型评判
RAG 评估与标准 LLM 评估有根本不同。传统指标衡量文本生成质量，而 RAG 特定指标必须评估：忠实性/基础性（回答是否在没有幻觉的情况下忠实于检索到的上下文？）、答案相关性（生成的回答实际上回答了用户的问题吗？）、引用准确性（来源是否被正确归因？）
对 IP 创作知识库的 Evals 体系演进路径：
第一阶段（现在）：规则驱动 Evals
frontmatter 完整性检查（规则：必须有 type/date/status） wikilink 有效性检查（规则：所有 链接 必须指向存在的文件） 文件命名规范检查（规则：符合命名约定）
第二阶段（1-3 个月后）：模板驱动 Evals
与已发布内容的风格对比评分 角色声音准确度量化（用已有高质量对话作为基准） 世界观细节一致性评分
第三阶段（3-6 个月后）：LLM-as-Judge Evals
用 claude-opus 作为评委，用上述评估框架对所有输出评分 建立历史评分趋势，追踪质量变化 当评分低于阈值自动触发重写 Loop
第七章：知识库长期演化——从系统到生态
7.1 知识库的生命周期阶段
一个健康的 IP 创作知识库会经历三个明显的阶段：
第一阶段：建设期（0-3 个月）
特征：
wiki 页面稀疏，链接密度低（<3） 大量 _raw/ 文件等待处理 Consistency-Checker 发现很多矛盾（这是正常的！早期矛盾意味着设定在演化） Evals 评分可能不稳定
此阶段重点：
确保基础架构正确（frontmatter 标准、文件夹边界） 大量摄入素材，让知识库快速"起量" 不追求完美，追求覆盖
第二阶段：成熟期（3-9 个月）
特征：
wiki 页面数量超过 100，链接密度达到 5+ 核心实体（角色/地点/势力）都有完整页面 Consistency-Checker 通过率稳定在 85%+ Evals 评分趋于稳定
此阶段重点：
精细化知识连接（补充深度 wikilink） 建立 Evals 基准线（"我的系统的正常水平是什么？"） 开始关注知识新鲜度
第三阶段：复利期（9 个月以上）
特征：
wiki 页面数量超过 300，形成真正的知识网络 链接密度超过 8，多跳推理能力强 AI 生成内容质量显著高于初期 知识库开始"提前回答"你还没想到的问题
此阶段重点：
知识图谱的剪枝（删除低价值孤立页面） 引入更复杂的 Multi-Agent 协作 开始对外输出（知识库内容支持更多创作形式）
7.2 知识库的"剪枝"——保持质量不降级
随着知识库增长，有一个反直觉的操作很重要：定期删除页面。
Hub 只是一个注册表——没有内容目录，没有 .obsidian/。所有内容存在于有独立索引和文章的主题子 wiki 中。Init 首先创建核心 wiki 骨架；可选的库存和数据集层在你使用它们时创建。
知识库里的低质量页面，比没有页面更危险：
孤立节点降低图谱的整体密度信号 错误或过时的内容会被 AI 当作有效知识检索 重复内容会让 AI 在综合时产生混乱
剪枝规则（每月运行一次）：
Markdown
删除候选标准（满足任意一条）：
1. 孤立页面：入链 = 0，且超过 60 天未被引用
2. 内容为空：frontmatter 存在但正文少于 50 字
3. 重复页面：内容与另一个页面 85% 以上重叠
4. 过时素材：_raw/processed/ 中早于 6 个月的文件（已完全整合进 wiki）删除前操作：
1. 在 log.md 记录删除意图
2. 检查是否有其他页面引用（如有，先更新引用）
3. 移动到 archive/（不直接删除，保留可恢复性）
4. 更新 index.md
7.3 分离策略：创作 Vault vs. Agent Vault
随着 Loop 自动化程度的提高，有一个重要的架构决策：是否要把 Agent 生成的内容和人类创作的内容分开？
社区实践中出现了一种分离策略：维护一个高信号的个人 vault，同时维护一个面向 Agent 的"处理" vault，防止生成内容对原始创作内容造成污染。
对 IP 创作者，我的建议是软分离：
text
你的创作内容（高信号区）：
- CLAUDE.md（你的核心设定，人工维护）
- wiki/characters/（你深度定义的角色，Agent 可更新但有门槛）
- wiki/world/rules.md（宇宙法则，只有你能修改）Agent 处理区（混合区）：
- wiki/concepts/（Agent 自由创建和更新）
- wiki/storylines/（Agent 整理，你审阅）
- _raw/processed/（Agent 维护的归档区）
完全 Agent 区（低审核）：
- journal/（Agent 自动生成，你可选阅读）
- crm/insights.md（Agent 分析生成）
- index.md（Agent 维护索引）
第八章：Graph RAG——当你的知识库需要更强的推理能力
8.1 什么时候需要从 Wiki 升级到 Graph RAG
LLM Wiki 用 Markdown wikilink 实现知识连接。这对大多数 IP 创作需求已经足够。
但当你的 IP 宇宙变得足够复杂——比如多个平行时间线、几十个角色的复杂关系网、跨越数百年的历史因果链——wikilink 的简单连接可能不够用。
过去两年知识增强 LLM 系统中最重要的发展是 GraphRAG（图谱 + 检索增强生成），由微软研究院在 2024 年初引入，2024 年 7 月开源，已经成为 2026 年将 LLM 与知识图谱结合的参考架构。GraphRAG 是一种检索增强生成技术，使用 LLM 从非结构化文本构建知识图谱，应用社区检测算法将实体聚类成主题组，为每个社区生成 LLM 摘要，并使用这些摘要同时支持实体级别和语料库级别的问答。GraphRAG 在两个阶段运行：构建知识图谱和社区摘要的离线索引阶段，以及使用它们回答问题的在线查询阶段。
升级到 Graph RAG 的信号：
8.2 Graph RAG 对 IP 创作的具体价值
传统 wikilink：
text
[[角色A]] ←→ [[角色B]]
只知道"这两个实体有关联"，不知道关联的类型和强度。
知识图谱关系：
text
角色A --[师父-弟子]-- 角色B (权重:0.9, 时间:第一纪元)
角色A --[曾经的盟友]-- 角色B (权重:0.6, 时间:第二纪元前期)
角色A --[宿敌]-- 角色B (权重:1.0, 时间:第二纪元末期)
有了显式的关系类型和时间属性，AI 就能回答："第二纪元末期，角色 A 和角色 B 的关系对主线冲突有什么影响？"——这是真正的多跳语义推理。
Agent-G 引入了一种新型 Agent 架构，将图谱知识库与非结构化文档检索整合。通过结合结构化和非结构化数据源，该框架增强了 RAG 系统的推理和检索准确性。它采用模块化检索器组、动态 Agent 交互和反馈循环来确保高质量输出。
8.3 轻量级图谱的实现——不需要 Neo4j
大多数创作者不需要部署完整的图数据库。用 Obsidian + Dataview 插件，可以实现"轻量级知识图谱"：
用 frontmatter 表达关系类型：
YAML
---
type: relationship
subject: "[[角色A]]"
predicate: 师父-弟子
object: "[[角色B]]"
weight: 0.9
timeline: 第一纪元
status: 已结束
notes: 在[事件X]后关系破裂
---
用 Dataview 查询特定类型的关系：
dataview
TABLE subject, predicate, object, timeline
FROM "wiki/relationships/"
WHERE predicate = "宿敌"
AND contains(timeline, "第二纪元")
这比传统 wikilink 的信息密度高出一个数量级，而不需要任何专业的图数据库。
第九章：系统的自我意识——让知识库报告自己的状态
9.1 知识库健康仪表盘设计
一个成熟的知识库应该能够"自我报告"。每周的健康报告不只是给你看数字，而是帮助你做决策：这周的创作资源，应该投入到哪里？
完整健康仪表盘模板（每周生成一次，存入 wiki/world/）：
Markdown
---
type: health-report
date: 2026-06-15
generated-by: Orchestrator
---# 知识库健康周报 - 第24周
## 📊 量化指标
### 规模指标
| 指标 | 本周 | 上周 | 趋势 |
|---|---|---|---|
| Wiki 总页面数 | 156 | 149 | ↑+7 |
| 字符总数 | 284,000 | 269,000 | ↑+5.6% |
| 本周新增页面 | 7 | 12 | ↓正常波动 |
| 本周更新页面 | 23 | 19 | ↑ |
### 质量指标
| 指标 | 本周 | 目标值 | 状态 |
|---|---|---|---|
| 链接密度 | 6.8 | >5 | ✅ |
| 孤立页面比例 | 3.2% | <5% | ✅ |
| 一致性评分 | 91.3 | >85 | ✅ |
| 核心实体覆盖率 | 78% | >75% | ✅ |
| 知识新鲜度 | 94.2% | >90% | ✅ |
### 系统指标
| 指标 | 本周 | 状态 |
|---|---|---|
| Loop 总运行次数 | 172次 | 正常 |
| Loop 成功率 | 98.8% | ✅ |
| Token 总消耗 | 198,400 | 预算内 |
| 预估成本 | $3.2 | 预算内 |
---
## 🔍 质量洞察
### 本周发现的矛盾
1. [中等] wiki/characters/角色B.md 与 wiki/storylines/主线第四章.md
描述冲突：角色B在第三纪元是否拥有飞行能力
→ 建议：审阅后决定哪个版本正确
2. [轻微] wiki/world/geography.md 和 wiki/lore/古代战争.md
细节不一致：某城市的建立时间差了50年
→ 建议：参考 _raw/processed/历史设定初稿.md 核实
### 知识空白区
以下概念被多次引用但尚无独立页面（建议创建）：
1. "禁忌契约"（被6个页面引用）
2. "北方联盟"（被4个页面引用）
3. "灵魂烙印系统"（被5个页面引用）
---
## 📈 趋势分析
### 知识增长曲线
（过去8周链接密度）：
4.2 → 4.8 → 5.1 → 5.6 → 6.0 → 6.3 → 6.6 → 6.8
趋势：稳定增长，预计在第28周突破7.0阈值。
### 一致性评分趋势
（过去8周）：
82.1 → 84.3 → 86.0 → 87.2 → 88.9 → 90.1 → 91.0 → 91.3
趋势：持续改善，已连续5周高于90分门槛。
---
## 🎯 本周建议
优先级1（本周必做）：
□ 解决角色B飞行能力矛盾（影响当前进行中项目）
优先级2（本周如有时间）：
□ 创建"禁忌契约"概念页面（被6个地方引用，影响推理质量）
□ 补充角色B人物卡（超过30天未更新）
优先级3（下周）：
□ 创建"北方联盟"和"灵魂烙印系统"页面
□ 修复城市建立时间的历史矛盾
结语：从知识库到认知伙伴
让我用一句话总结核心洞见：
知识库的价值，不在于存了多少东西，而在于知识之间建立了多少显式的、有意义的关系。
Karpathy 明确引用了 Vannevar Bush 的 Memex（1945年）：一个有文档之间联想轨迹的个人知识存储。
这个 1945 年的愿景，在 2026 年终于有了真正可实现的技术路径：
WikiLLM 让知识从被动存储变成主动编译 Multi-Agent 架构 让制造和检查分离，质量有保障 /goal 命令 让 Loop 有了真正的目标和停止条件 Evals 体系 让质量从模糊感知变成可度量的指标
这个工具构建了一个持久的文物——一个随你添加的每条笔记增长的 Wiki，你可以在 Obsidian 中打开、搜索、查询和手动编辑。
但最重要的，是理解这个系统的本质：
它不是在替代你的创意，它是在替代你的记忆负担。
当你不再需要记住角色 A 在第三纪元发生了什么，你就可以把这部分认知资源，用在真正值得创作者思考的地方：
这个故事，值得被讲出来吗？ 这个情节，会让读者感受到什么？ 这个 IP，对世界有什么意义？
这些问题，是任何 AI 系统永远无法替代你回答的。
而一个健康的知识库，恰好能让你把更多时间花在这些真正重要的问题上。
📌 完整技术速查表
三种知识系统选择矩阵
| LLM Wiki | ||
Evals 核心指标基准值
Multi-Agent 模型分层建议
知识库成熟度三阶段
这个体系本身，正是你知识库的第一批"权威来源"。
现在，把它放进你的 _raw/research/ 文件夹，让 Wiki-Maker 开始工作。
我是【一只阿木木】——公开建造我的 AI 第二大脑。
普通人如何用 AI 搭建自己的知识操作系统？
一个程序员出身的知识工作者，公开记录自己如何用 AI 工具搭建个人知识系统、把读过的书和做过的项目变成可复用资产的全过程。
欢迎加入行动营👇获取更多Obsidian + AI数字大脑实践
我相信：在 AI 时代，每个普通人都该拥有一个自动生长的知识系统
欢迎关注【一只阿木木】🌊