基于LLM知识库构建与Harness工程化实践教程

一、教程目标

本教程要帮助读者完成一项非常具体的任务：利用大语言模型，把分散在文章、论文、代码仓库、数据集、图片等来源中的信息，逐步整理成结构清晰、可持续维护、可被后续检索与问答使用的知识库。

这里说的“知识库”并不是简单地把文件堆在一起，而是把原始资料经过模型处理与人工规则约束后，形成一组按目录组织、带有摘要、反向链接和索引关系的 Markdown 文件。最终效果是：当你需要回答一个复杂问题时，可以由模型代理基于这个知识库自主查找、综合并生成答案，而不是每次都从原始资料重新开始。

文章还会引入 Harness Engineering 的视角，解释为什么这种工作方式不只是“整理笔记”，而是一种围绕模型能力构建工程化流程的实践。读者可以把这套方法用于技术调研、产品设计、学习主题整理、业务知识沉淀等场景。

二、适用场景

这套方法适合以下几类情况：

1. 个人技术研究
   例如你正在研究某个技术方向，需要阅读大量文章、论文和文档。原始材料来源分散、格式不一，经常忘记已经看过什么、哪些结论来自哪篇资料。

2. 团队知识沉淀
   团队内部经常产生会议结论、方案记录、排查过程、设计文档。如果不做结构化整理，时间一长就很难复用。

3. 给模型代理提供上下文基础
   当你想让大语言模型基于私有资料回答问题、生成报告或辅助决策时，需要一个比“临时粘贴几段文字”更稳定的知识来源。

4. 长期维护的主题库
   例如持续跟踪某个行业方向、竞品动态或技术演进，希望每次新增资料都能自动更新摘要、关联旧内容，而不是从头整理。

在这些场景中，关键是建立一套可持续运行的流程，而不是一次性导出某个文件。

三、前置准备

开始之前，需要具备以下基础：

• 一个可以持续运行大语言模型代理或调用模型接口的环境；
• 一个用于存放原始资料和生成结果的目录结构；
• 熟悉基础的 Markdown 语法和文件组织方式；
• 具备一定的提示词编写能力，能够描述清楚“如何摘要、如何归类、如何建立链接”；
• 对知识管理的基本概念有了解，例如主题、标签、反向链接、索引文件等。

不需要依赖某个特定云厂商或平台，只要能够访问大语言模型能力即可。如果使用云服务，可以选择支持对象存储、容器任务或定时触发的通用云产品来承载资料文件和批处理任务。

四、整体设计思路

这套知识库构建方式可以抽象为四个阶段：

1. 数据摄取：把外部来源统一放入 raw/ 目录；
2. 编译整理：由模型读取 raw/ 内容，生成摘要、分类、概念条目和链接；
3. 索引维护：维护一个或多个索引文件，记录有哪些主题、哪些文档、哪些概念；
4. 问答输出：基于整理后的知识库，让模型代理查找相关内容并生成答案或可视化产物。

这个过程很像软件工程里的持续集成：原始资料是“源代码”，模型处理是“编译过程”，最终 Markdown 文件是“构建产物”。Harness Engineering 的核心思想之一，就是把模型调用、状态管理和产物生成放到同一个可重复的循环里，而不是每次手动操作。

五、实施步骤

步骤一：建立目录结构

先在本地或云端工作区建立以下基本目录：

knowledge-base/
├── raw/                # 原始资料，不做深度修改
├── wiki/               # 编译后的知识文件
│   ├── concepts/       # 概念条目
│   ├── sources/        # 来源摘要
│   └── indexes/        # 索引文件
└── scripts/            # 模型调用与处理脚本

raw/ 目录尽量保持原始内容不变，这样后续重新编译时可以追溯来源。wiki/ 目录是模型生成内容的主要区域，不建议人工频繁直接修改。

这样拆分的意义在于：原始资料和生成产物分离，便于重复处理、版本管理和问题回溯。

步骤二：采集并归档原始资料

把需要处理的文章、论文、仓库说明、数据集说明、图片等放入 raw/ 目录。对于网页内容，可以转换为 Markdown 格式后保存；涉及图片时，保持图片与文字的相对路径关系，便于模型后续引用。

建议给每个原始文件使用稳定、可读的文件名，并在文件头部补充来源信息和抓取时间。例如：

<!-- source: 某技术社区文章 -->
<!-- fetched: 2026-04-04 -->
# 原文标题
正文内容……

这样做的原因是：当模型后期生成摘要或回答问题时，可以引用来源；当需要更新某个主题时，也能快速定位原始文件。

步骤三：让模型生成第一批摘要

第一阶段，先不急着做复杂分类。可以按照 raw/ 中的文件顺序，让模型逐个读取内容，为每个文件生成一段简短摘要，并保存到 wiki/sources/ 目录下。

摘要应至少包含：

• 该资料的核心主题；
• 主要结论或关键信息；
• 与其他资料可能产生关联的关键词；
• 来源文件名或相对路径。

这一步的目的是先建立一个“资料地图”。即使后续只使用这些摘要，也能大幅减少模型每次回答问题时重复读取全文的负担。

步骤四：提炼概念条目

在生成来源摘要之后，观察这些摘要中反复出现的关键词和主题。把这些主题整理成概念列表，例如“知识库构建”“模型代理”“索引维护”“状态工件”等。

然后让模型根据这些概念，结合 raw/ 中的相关内容，撰写概念条目。每个概念条目应该解释：

• 这个概念的通用定义；
• 在当前知识库中的具体含义；
• 与哪些来源有关；
• 与哪些其他概念存在关联。

概念条目保存到 wiki/concepts/ 目录，并在条目末尾加上反向链接，指向相关来源摘要和其他概念。

步骤五：建立索引文件

当概念条目和来源摘要达到一定数量后，需要建立索引文件，帮助模型或人工快速浏览知识库全貌。

一个基础的索引文件可以包含三层信息：

1. 主题列表：列出当前覆盖的主要研究方向；
2. 概念列表：按字母或重要性排序的概念条目；
3. 来源列表：按时间或类型排序的来源摘要。

索引文件放在 wiki/indexes/ 目录下。模型在回答复杂问题时，会优先读取索引，再决定深入哪些概念或来源。

索引文件不需要一开始就非常完整，但至少应该能让一个新读者在几分钟内理解这个知识库大概覆盖了什么内容。

步骤六：构建问答流程

当知识库达到一定规模后，可以开始构建基于模型的问答能力。

流程大致如下：

1. 用户提出问题；
2. 模型先读取索引文件，确定可能相关的主题和概念；
3. 模型再读取相关概念条目与来源摘要，必要时回查 raw/ 中的原始内容；
4. 模型综合这些信息，生成答案；
5. 根据需求，输出为 Markdown 文件、幻灯片格式代码或可视化图表。

在这个流程中，模型并不是一次读取所有文件，而是根据索引逐步缩小范围。这比直接做全量全文搜索更适合中小规模知识库，也能减少无意义的上下文消耗。

步骤七：维护与迭代

知识库不是一次性构建完成的。每次新增资料时，建议执行以下动作：

• 把新资料放入 raw/；
• 让模型生成或更新该资料的摘要；
• 检查是否需要新增概念条目或更新已有概念；
• 更新索引文件；
• 如果某个主题已经积累了较多新内容，可以让模型重新整理该主题下的结构。

这个循环可以被理解为 Harness 中的“on-the-loop”过程：模型不仅在单次任务中执行操作，还会持续把状态写回知识库，让下一轮任务基于更新后的状态继续工作。

六、配置说明与常见取值逻辑

虽然本方案不依赖某个专有平台的固定参数，但在工程化实现时，有几个关键配置需要根据实际情况调整。

配置项	作用	常见取值逻辑	注意事项
单次读取文件数量	控制模型一次处理多少资料	小型资料每次1～3个，大型资料每次1个	一次读取过多会丢失关键信息
摘要长度	控制每个来源摘要的字数	中型知识库建议200～500字	过短难以支撑问答，过长影响索引效率
概念粒度	决定概念条目的细分程度	可按研究主题、技术方向或业务领域划分	过细会导致条目碎片化
索引更新策略	决定何时更新索引文件	每次新增资料后更新，或积累一定数量后批量更新	批量更新可能造成短期索引滞后
回查策略	决定模型何时回查原文	摘要信息不足时回查原始资料	频繁回查会增加处理时间

以上数值不是固定标准，需要根据知识库规模、模型上下文长度和实际使用频率进行调整。

七、结果验证

构建完成后，可以通过以下方式验证知识库是否满足基本需求。

验证一：概览检查

打开索引文件和概念目录，确认：

• 是否能快速了解知识库覆盖的主题；
• 每个来源是否都有对应摘要；
• 概念之间是否有可用的反向链接。

验证二：单点问答

选择几个已经整理过的主题，向模型提出具体问题，观察模型是否能够：

• 定位到相关概念；
• 引用正确来源；
• 给出与原文一致、逻辑清晰的答案。

如果模型频繁答错或找不到关键信息，说明摘要质量或索引结构需要调整。

验证三：跨主题关联

提出一个需要综合多个概念或来源的问题，检查模型是否能同时调用不同章节的内容。例如：“这个知识库中关于模型代理与索引维护的关系有哪些讨论？”

这一步可以检验反向链接和概念条目是否真正起到了关联作用，而不是只存在孤立的摘要。

八、常见问题与排查

问题一：模型生成的摘要信息量不足

原因：提示词过于简单，或模型只读取了部分内容。

解决思路：在摘要步骤中明确要求提取核心观点、结论、关键词和可能关联的主题；如果文件较长，可以分段读取再汇总。

问题二：知识库规模变大后，问答速度变慢

原因：模型每次读取过多文件，或者索引没有起到缩小范围的作用。

解决思路：优先生成更精确的索引；在问答流程中要求模型先读取索引再选择具体文档；对长期不变的内容，可以提前生成更紧凑的聚合摘要。

问题三：新增资料后，旧概念没有及时更新

原因：维护流程只增加了新摘要，没有检查旧概念是否需要补充。

解决思路：在每次新增资料后，让模型检查该资料是否影响已有概念条目；如果影响较大，则更新对应概念和相关反向链接。

问题四：原始资料格式混乱，模型处理不稳定

原因：网页转换后格式不一，或图片与文字关系不明确。

解决思路：在归档阶段增加格式清洗步骤；对包含大量图片的资料，先提取文字主体，再单独记录图片路径和图片说明，避免模型因格式问题丢失关键信息。

问题五：模型回答时无法稳定引用来源

原因：摘要中没有保留原始文件名或相对路径。

解决思路：在摘要模板中固定加入“来源文件”字段，并要求模型在后续回答中优先引用该字段。

九、优化建议

1. 从简单任务开始

不要一开始就尝试构建庞大的知识体系。可以先选择一个小主题，放入10～20份资料，完整跑通“归档—摘要—概念—索引—问答”流程。流程稳定后再逐步扩展。

2. 让模型维护而不是人工维护

知识库的优势在于可重复生成和自动更新。尽量避免人工直接编辑已编译内容。如果发现问题，优先修改提示词或处理流程，再重新生成相关部分。

3. 控制上下文成本

对于较长资料，可以让模型先读取前一部分生成初步摘要，再结合后文进行修正。对于问答场景，优先使用索引和摘要，仅在必要时回查原文，避免每次都加载完整文件。

4. 把输出格式多样化

除了纯文本答案，还可以让模型生成幻灯片大纲、流程图描述或数据可视化脚本。这样同一个知识库可以服务于文档、汇报和演示等多种用途。

5. 记录每次处理的状态

可以在 wiki/indexes/ 中维护一个简单的状态文件，记录上次更新了哪些资料、何时更新、当前版本号。这样便于回溯问题，也符合状态持续沉淀的工程化原则。

十、总结

本教程围绕“用大语言模型构建可持续维护的知识库”这一目标，完整梳理了从目录设计、原始资料归档、摘要生成、概念提炼、索引维护到问答输出的实施过程。整个过程并不依赖某个特定平台或专有工具，而是基于通用的目录结构、Markdown 文件和模型调用能力完成。

其核心工程思想与 Harness Engineering 一致：把模型的每次产出看作可复用工件，通过索引和反向链接维持知识状态，并在新增资料后持续更新，而不是只做一次性整理。对于开发者、技术负责人和需要管理大量私有资料的企业用户来说，这套方法提供了一种比传统全文检索更轻量、更可控的知识组织方式。

后续可以继续扩展的方向包括：增加定时批处理任务、加入向量检索辅助定位、为不同主题设计专用问答模板，以及在多成员协作场景中引入角色权限和审核流程。