LLM Wiki 本体论进阶：如何设计强引导型 Agent，让任何专家都能自主建设知识库？

前置阅读：建议先看《LLM Wiki 本体论知识库设计》了解背景。本文是进阶篇，重点讲强引导型 Agent 的完整设计，解决"如何让完全不懂知识库建设的业务专家自主完成知识库搭建"的问题。

背景：工具到位了，方法论还不够

上一篇文章发出后，有朋友问我：你说的 LLM Wiki 本体论很好，但我自己试了试，感觉还是不知道从哪下手。

这问到点子上了。

LLM Wiki 是一套工具，但工具不等于方法论。工具告诉你"可以做什么"，方法论告诉你"第一步做什么、第二步做什么、什么时候该停下来问用户"。没有方法论，工具就是一堆功能点的堆砌。

更关键的问题是：谁来建知识库？

如果要求用户既懂业务、又要懂 AI、还要懂知识库建设——那门槛高得离谱，大部分人直接就放弃了。

所以这一篇，我想专门回答一个问题：

如何设计一个强引导型 Agent，让用户只需要是某个领域的专家，Agent 负责引导整个知识库建设流程？

核心洞察：三个本质矛盾

在和 @Fred 讨论 BCM（业务连续性管理）知识库的过程中，我们发现了三个相互关联的本质矛盾，理解它们是设计引导型 Agent 的前提：

矛盾一：LLM 懂 vs 业务人员懂

LLM Wiki 的 index.md 看起来是一堆扁平标签：

- 组织

系统
流程
文档

但 LLM 回答问题时能隐性消歧、理解层级关系。比如"组织"在不同上下文里可能是"公司""部门""团队"，LLM 知道，但这个隐含的层级结构没有显性化到 index 里。

业务人员打开 index.md，看到的就是这样一堆扁平标签——他不知道从哪导航，也不知道哪些概念是包含关系、哪些是并列关系。

矛盾二：扁平结构的便利 vs 本体论的价值

用现成工具（llm_wiki）建知识库很方便，但沿用了标准模板，LLM 自动提取的实体就是扁平的。

好处是：LLM 回答问题的质量还不错（因为 LLM 内部做了隐性的上下文推理）。

坏处是：知识库本身没有积累下这个推理过程——下次换一个人问，或者在另一个上下文中，原来的消歧逻辑丢失了。

矛盾三：概念分层的质量 vs 领域专家的缺失

如果概念分层决定了知识库的质量，那是否让 LLM 来自动做概念分层？

不行。因为概念分层本质上需要人类判断：

• "机器学习"该分到哪个层级？取决于使用目的，不是客观事实
• 两个实体之间有 100 种可能的关系，该显性表达哪些？需要领域判断
• "系统"这个词在 BCM 里指业务系统，在 IT 里指软件系统——LLM 做了隐性消歧，但这个逻辑没有显性化

解法：强引导型 Agent 的三层架构

经过深入讨论，我们提炼出强引导型 Agent 的核心架构：

┌─────────────────────────────────────────────────────────┐
│                   强引导型 Agent                          │
├─────────────────────────────────────────────────────────┤
│  📦 知识库层   ← LLM Wiki 的 raw/wiki/schema 三层结构    │
├─────────────────────────────────────────────────────────┤
│  🧠 方法论层   ← 本体论框架（骨架→层级→消歧→关系）        │
│                 · P0/P1/P2/P3 各环节的执行逻辑           │
│                 · 环节之间的依赖关系和触发条件             │
├─────────────────────────────────────────────────────────┤
│  💬 交互层     ← IdeaPad 驱动的引导对话                  │
│                 · 何时记录到 IdeaPad                    │
│                 · 何时主动找用户讨论                      │
└─────────────────────────────────────────────────────────┘

三层各有分工：知识库层负责存储和管理内容；方法论层负责知道该做什么、什么时候做；交互层负责在正确的时机、用业务人员能理解的方式和用户沟通。

Agent 能力分级：P0 到 P3

不是所有事情都需要用户参与。Agent 的能力分级决定了人机协作的边界：

P1（消歧）的特殊性

消歧不是一个"做完就结束"的环节，而是持续性挑战：

知识库初期：某概念被消歧
    ↓
知识库扩张：新文档引入新上下文
    ↓
同一个词可能再次产生歧义

比如"系统"这个词在 BCM 里消歧过一次，但随着知识库扩张，新引入的 IT 相关文档可能让"系统"再次产生歧义。

因此需要：

• 已消歧词表：记录所有消歧历史
• 每次 ingest 新文件时：自动检查是否涉及"已消歧词表"，如果涉及，触发 P1 流程

核心工作流：六步引导法

强引导型 Agent 的工作流如下：

Step 1: 用户说明领域
    ↓
Step 2: 用户提供文件（必须的！）
    ↓
Step 3: Agent 触发式 LLM Wiki 分析（增量式）
    ↓
Step 4: Agent 维护 IdeaPad（困惑点清单）
    ↓
Step 5: 用户说"评估知识库状态"（或每天定时）
    ↓
Step 6: Agent 基于 IdeaPad 展示关键未决问题 → 用户业务确认

Step 1-2：启动条件

内部知识库和互联网知识库的核心区别在于：内部知识库以自有文档为主，而不是从互联网抓取内容。

外部信息（LLM 已有知识、互联网资料）只在判断需要时作为参考引入，而不是主动抓取。

Step 3：增量式 LLM Wiki 分析

每次用户引入新文件时，Agent 自动触发 LLM Wiki 分析流程：

• 分析文件内容，提取实体和概念
• 更新知识库的层级结构
• 如果发现可能涉及"已消歧词表"的内容，触发 P1 流程

Step 4：IdeaPad 机制

IdeaPad（思路清单）是这个设计的核心创新之一。

Agent 在分析过程中发现的所有困惑点和未决问题都记录在 IdeaPad 里，而不是在发现的时候就打断用户。IdeaPad 是一个结构化的清单库，每个条目都代表一个需要业务确认或补充的具体问题。

这样做的好处是：用户不需要随时在线，Agent 也不需要每次发现一个问题就停下来问。积累到一定程度后，用户说"评估知识库状态"，Agent 一次性把所有未决问题展示出来。

Step 5-6：审议触发时机

关键设计原则

原则一：给用户的是"业务任务"，不是"AI 任务"

Agent 引导用户时，给出的任务必须是业务相关的确认或补充，不能是 AI 相关的概念。

❌ 错误示范："请确认这个实体的类型是否正确" ✅ 正确示范："在这个 BCM 场景里，'系统'是指业务系统还是 IT 系统？"

原则二：用户对话的优先级高于 raw 文件

用户在任何时候给出的业务信息（解释、纠正、补充），优先级都高于知识库的 raw 文件。

Agent 在每次"消化"新信息时，应该优先处理用户对话内容，而不是机械地重新分析文件。

原则三：消歧显性化

消歧不是一次性事件，而是需要持续监控的专项。

每次 ingest 新文件时，必须检查是否涉及已消歧词表。这不是可选项，而是 P0 级别的强制检查。

与现有工具的对比

llm_wiki（nashsu/llm_wiki，14.8k stars）已经实现了大量工程化改进，包括 4-Signal 知识图谱、Async Review System、Scenario Templates 等功能。

但强引导型 Agent 和 llm_wiki 的定位有一个关键区别：

待攻克的研究方向：本体编辑器

目前最大的难点是：如何让用户可视化地编辑和查看分层结构？

分层结构比文件树复杂——有横向关系，不只是树形的包含关系。传统的树形 UI 不足以表达这种图状结构。

可能的方向包括拖拽式编辑、自然语言交互编辑、模板+自定义混合等。但目前还没有找到成熟的解决方案，这个方向值得持续探索。

总结

强引导型 Agent 的设计，核心回答了一个问题：谁应该为知识库的质量负责？

答案是：人机协作，但各自做自己擅长的事。

• Agent 擅长：提取实体、分析一致性、积累困惑点、触发正确时机
• 人（业务专家）擅长：概念边界的判断、层级结构的取舍、歧义的消解

Agent 不代替人做判断，而是在正确的时机、用正确的方式、把正确的问题抛给正确的人。

这个设计目前还在探索阶段，方法论框架已经成型，工程实现还有很多细节需要攻克。如果你也在做类似的事情，欢迎交流。