企业官网建设流程全解析

1. 一份66页工业库是怎么变成Agent主线的

先说结论：我手上这套知识库Agent的主线，不是从什么论文或者开源框架里长出来的，而是从一份66页的工业设备运维手册里硬啃出来的。这份手册是某产线设备的完整技术资料，包含设备参数、故障代码、维护周期、备件清单、接线图说明，页数不算多，但信息密度极高，表格套表格，附录里还有大量非结构化的经验备注。最开始我的目标很朴素——让现场工程师能用一个对话入口查到想要的参数和处置步骤，不用再翻PDF翻到眼花。

做着做着就发现，单纯做“文档问答”根本不够用。工程师问“3号泵振动超标怎么处理”，他需要的不是一段原文摘录，而是一条可执行的判断链：先确认振动值区间，再对照故障代码表，然后给出排查顺序，最后附上备件型号和更换周期。这就逼着我从“检索增强生成”往“Agent编排”方向走。知识库不再只是被检索的静态语料，而是Agent做决策时的“事实底座”和“工具手册”。

所以这篇文章我想聊的是：一份工业库如何被拆解成知识库Agent的主线，中间涉及哪些关键设计决策，踩过哪些坑，以及如果你手上也有类似的技术手册、标准文档、运维资料，怎么照着这条路走一遍。适合正在做企业知识库、RAG应用、Agent开发的同行参考，也适合刚接触这块、想找一个真实项目练手的开发者。全文围绕知识库和Agent两个核心词展开，不堆概念，只讲我实际怎么做的。

2. 为什么工业库不适合直接塞进向量数据库

2.1 工业文档的三个“反RAG”特征

很多人做知识库的第一反应是：切块、嵌入、存向量库、检索、拼prompt。这套流程在通用文档上跑得通，但工业库有三个特征会让它翻车。

第一个特征是表格即答案。工业手册里大量关键信息在表格中，比如“故障代码-原因-处置”三列对照表。你按固定字数切块，很可能把一行故障代码和它的处置措施切到两个块里，检索出来只有代码没有处置，Agent拿到就是残缺信息。我试过用512字符切块，结果“E07”这个代码对应的处置步骤被切到了下一个块，模型回答时直接编了一个处置方案，现场差点按错误步骤操作。

第二个特征是术语强绑定。工业场景里同一个部件可能有多个叫法：正式名称、现场俗称、缩写、英文代号。比如“液压站”在现场可能被叫“油站”“泵站”“HPU”。如果知识库里只存了正式名称，工程师用俗称提问时，向量检索的相似度会很低，召回失败。这不是模型能力问题，是语料表示问题。

第三个特征是版本与适用性。同一份手册可能对应多个设备型号、多个批次，参数表里会标注“适用于A型”“B型除外”。如果检索时不带版本过滤，Agent可能把B型的参数套到A型设备上，这是工业场景里绝对不能接受的错误。

2.2 我的拆解策略：先结构化，再向量化

针对这三个特征，我的做法是先做结构化抽取，再做向量化补充。具体来说，把66页手册拆成三类知识单元：

• 参数类：设备型号、额定值、阈值、周期，这类做成结构化表，存关系库或JSON，检索时精确匹配。
• 流程类：故障处置步骤、维护操作顺序，这类做成有序列表，保留步骤编号和依赖关系。
• 说明类：原理描述、注意事项、经验备注，这类才走向量检索。

这样做的逻辑是：能用精确匹配解决的，不要交给向量相似度。故障代码“E07”是一个确定性的键，直接查表比向量检索快且准。向量检索只用来处理那些表述多样、无法穷举的说明性内容。

注意：不要一上来就全量向量化。先问自己：这条知识有没有确定的键？有键就走结构化，没键才走向量。

2.3 结构化抽取的实操方法

抽取工具我用的是Python加正则加规则模板，没有上大模型做全自动抽取，原因是工业文档格式相对固定，规则抽取的准确率比模型抽取更可控，而且可追溯。具体步骤：

1. 用pdfplumber把PDF按页转成文本和表格，表格单独用extract_tables()提取，保留行列结构。
2. 对表格做人工标注，确定哪些列是键、哪些列是值、哪些列是适用条件。
3. 写规则脚本把表格转成JSON记录，每条记录包含：键、值、适用型号、来源页码。
4. 对非表格文本，按标题层级切分，保留章节路径作为元数据。

这套流程跑下来，66页手册抽出了约420条结构化记录和180个说明性文本块。结构化记录进SQLite，说明性文本块进向量库。Agent在回答时，先判断问题类型，参数类走SQL查询，说明类走向量检索，混合类两者都走再合并。

3. 知识库Agent的主线设计：从检索到编排

3.1 Agent在这套系统里到底干什么

很多人把Agent理解成“会调工具的聊天机器人”，这个理解不算错，但不够具体。在我这套系统里，Agent的核心职责是意图识别加工具路由加结果校验。

意图识别：判断用户问的是参数查询、故障处置、操作指导还是闲聊。这一步用一个小模型做分类就够了，不需要大模型。我试过用规则加关键词做初筛，再交给小模型兜底，准确率能到九成以上。

工具路由：根据意图选择调用哪个工具。参数查询调SQL查询工具，故障处置调“故障代码查表加步骤检索”组合工具，操作指导调向量检索工具。每个工具的输出格式是固定的，方便Agent后续处理。

结果校验：这是最容易被忽略的一步。Agent拿到工具返回后，要检查结果是否完整、是否与问题匹配、是否包含适用条件。比如用户问A型设备的参数，返回结果里如果标注了“适用于B型”，Agent要能识别并提示用户。

3.2 主线流程的五个环节

整套主线我拆成五个环节，每个环节都有明确的输入输出：

这个流程的好处是每一环都可单独测试和替换。意图识别不准，我只调分类模型；检索召回差，我只调检索策略；生成啰嗦，我只调prompt。不会牵一发动全身。

3.3 为什么不用全自动Agent框架

市面上有很多Agent框架，能自动规划、自动调工具、自动反思。我试过其中几个，最后选择自己写编排逻辑，原因有三个。

第一，工业场景容错率低。框架的自动规划可能产生不可预期的工具调用链，比如该查表的时候去做了向量检索，返回一个相似但不适用的结果。自己写编排，工具调用路径是确定的，可审计。

第二，调试成本。框架抽象层多，出问题时很难定位是检索错了还是规划错了。自己写的编排，每一步都有日志，排查直接看日志。

第三，依赖控制。工业环境往往要求离线部署，框架的依赖链长，打包和升级都麻烦。自己写核心逻辑，只依赖必要的库，部署简单。

这不是说框架不好，而是场景决定选型。通用场景用框架提效，工业场景用可控编排保稳。

4. 核心环节实现：从问题到答案的完整链路

4.1 意图识别的规则加模型双保险

意图识别我用了两层：第一层是关键词规则，第二层是小模型分类。

关键词规则很简单，维护一个意图关键词表：

• 参数查询：包含“多少”“参数”“额定”“阈值”“型号”等词
• 故障处置：包含“故障”“报警”“代码”“E0”“怎么处理”等词
• 操作指导：包含“怎么操作”“步骤”“流程”“先做什么”等词

规则命中就直接给意图标签，不命中才走小模型。小模型我用的是一个蒸馏后的文本分类模型，训练数据是从历史提问里人工标注的约两千条样本。实测下来，规则能覆盖约六成问题，剩下四成里小模型准确率约九成，整体意图识别准确率足够用。

实操心得：规则不是落后手段，在垂直场景里规则加模型的组合比纯模型更稳，而且规则可解释、可快速修正。

4.2 故障处置链的组装逻辑

故障处置是这套系统里最复杂的环节，因为它需要多步知识组合。以“3号泵振动超标”为例，Agent的处理链路是：

1. 从问题中抽取实体：设备“3号泵”，现象“振动超标”。
2. 查设备表确认3号泵的型号和适用手册版本。
3. 在故障代码表中检索“振动”相关条目，得到可能的故障代码列表。
4. 对每个故障代码，检索对应的处置步骤。
5. 按步骤编号排序，组装成处置链。
6. 附加备件信息和维护周期。
7. 校验所有信息的适用型号是否与3号泵一致。

这个链路里，第3步和第4步是关键。故障代码表是结构化的，检索用SQL的LIKE加关键词匹配。处置步骤是说明性文本，走向量检索，但检索时会带上故障代码作为过滤条件，避免召回无关步骤。

组装时我用了模板，把处置链格式化成“确认现象-排查原因-执行处置-更换备件”四段式。这样工程师拿到回答后可以直接按顺序执行，不用自己再整理。

4.3 向量检索的参数调优记录

向量检索这块我调了几轮参数，记录如下：

其中嵌入模型的调整效果最明显。通用嵌入模型对“液压站”和“泵站”的相似度判断不稳定，用工业语料微调后，同义术语的召回率明显提升。微调数据用的是手册里的术语表和同义表述，量不大，但针对性强。

4.4 结果校验的三条规则

结果校验我写了三条硬规则，任何一条不通过就触发重检索或提示用户：

• 完整性规则：故障处置链必须包含至少一个原因和一个处置步骤，否则视为不完整。
• 适用性规则：返回结果中的适用型号必须与问题中的设备型号一致，不一致则过滤。
• 一致性规则：同一问题的多次检索结果如果冲突，标记为待确认，提示用户人工核对。

这三条规则拦住过好几次错误回答。有一次检索把B型的维护周期返回给了A型设备，适用性规则直接过滤掉了，避免了一次误导。

5. 踩过的坑与排查实录

5.1 常见问题速查表

5.2 一次典型的排查过程

有一次现场反馈：问“E07怎么处理”，Agent返回了一个处置步骤，但步骤里提到的备件型号和手册不符。排查过程如下：

第一步，看检索日志。发现E07的处置步骤检索到了，但备件信息是从另一个故障代码的步骤里带出来的。原因是向量检索时，E07的步骤块和E12的步骤块相似度高，召回时混入了E12的内容。

第二步，看切块记录。发现E07和E12的处置步骤在原文里相邻，切块时重叠部分把两者的内容混在了一起。

第三步，解决。把切块策略从固定重叠改成按步骤边界切分，每个故障代码的处置步骤独立成块，块内不混入其他代码的内容。同时检索时加故障代码精确过滤，召回后再做一次代码一致性校验。

这个问题让我意识到：切块策略不是预处理的小事，它直接决定检索质量。工业文档的切块要跟着文档的逻辑结构走，不能按字数一刀切。

5.3 独家避坑技巧

几个我踩坑后总结的技巧，常规文档里不会写：

• 先做检索测试再做生成调优。很多人一上来就调prompt，但如果检索本身召回不准，prompt调出花来也没用。先把检索召回率和准确率测到位，再调生成。
• 保留来源页码。每条知识都记录来源页码，回答时可以附上“参见手册第X页”，方便人工核对，也增加可信度。
• 建一个“负样本”集。收集那些检索失败或回答错误的问题，作为回归测试集。每次调整检索或生成策略，都跑一遍负样本集，确保不退化。
• 同义词表要持续维护。现场工程师的提问用词会不断变化，同义词表不是一次建完就完事，要定期从提问日志里挖掘新词补充进去。
• 版本过滤做成硬约束。不要指望模型自己判断适用型号，在检索层就强制过滤，模型只负责组织语言。

6. 知识库Agent的扩展方向与个人体会

6.1 从单文档到多文档的扩展

这套主线最初只覆盖一份66页手册，后来扩展到同产线的其他设备手册，做法是：

• 每份手册独立做结构化抽取，生成独立的知识表。
• 建一个设备索引表，记录每台设备对应哪些手册、哪些版本。
• Agent检索时先查设备索引，确定要查哪些知识表，再并行检索。
• 结果组装时按设备维度合并，避免跨设备混淆。

扩展到五份手册后，检索延迟从原来的约800毫秒增加到约1.5秒，主要开销在并行检索的调度上。后来加了缓存，常用设备的检索结果缓存十分钟，延迟降回1秒以内。

6.2 知识库图片的处理思路

工业手册里有大量接线图、结构图、流程图。这些图片的处理我走了两条路：

一条是图片转文字描述。对接线图，用多模态模型生成文字描述，比如“该图展示3号泵的电源接线，L1接端子A，L2接端子B”，把描述存入向量库。这样用户问接线相关问题时，能检索到图片描述。

另一条是图片索引加原图返回。给每张图建索引，记录图号、页码、关联设备。用户问“3号泵接线图在哪一页”，Agent返回图号、页码和原图链接，用户自己看图。

两条路结合用，文字描述解决“图里有什么”的问题，原图返回解决“我要看图”的问题。

6.3 小模型能不能扛住这套系统

有人问过：这套系统能不能用小模型做。我的实测结论是分环节看。

意图识别和结果校验这类分类和规则判断任务，小模型完全够用，甚至规则就能覆盖大部分。检索环节不涉及生成，用的是嵌入模型，小尺寸的领域微调嵌入模型效果不差。只有最终的回答生成环节，小模型在组织多步处置链时容易漏步骤或顺序错乱，用稍大一点的模型更稳。

所以不是“小模型能不能做”，而是“哪个环节用什么尺寸的模型”。把大模型用在刀刃上，其他环节用小模型或规则，整体成本和延迟都可控。

6.4 我个人在实际操作中的体会

这套系统从一份66页手册起步，到现在覆盖五份手册、支撑现场日常查询，前后迭代了大概四个月。最大的体会是：知识库Agent的难点不在Agent，在知识库。Agent的编排逻辑是相对标准的，意图识别、工具路由、结果校验，这些都有成熟做法。真正花时间的是把工业文档拆成机器能用的知识单元，是处理表格、术语、版本这些“脏活”。

另一个体会是：不要追求全自动。我见过一些项目想用大模型全自动抽取知识、全自动规划工具调用，结果在工业场景里错误率下不来。人工标注加规则抽取加模型兜底，这个组合看起来笨，但稳。工业场景里，稳比炫重要。

最后分享一个小技巧：如果你也在做类似的知识库Agent，建议先拿一份最小的文档跑通全链路，哪怕只有十页。跑通后再扩文档、扩设备、扩功能。一开始就铺大摊子，很容易在细节里迷失，最后哪一环都没做扎实。