“知识库Agent这条主线是从一份66页工业库长出来的。”这句话我到现在都记得是项目启动会上拍板时说的原话。当时我们手头最值钱的资产是一本66页的设备维护手册内容覆盖空压机点检、液压系统参数、报警代码和备件清单。车间老师傅马上要退休新来的维修工查一个报警代码要翻三个文件夹。我们想做的是一个能直接对话的工业知识库而不是让人抱着PDF满车间跑。这本66页手册成了整个知识库Agent项目的原点。从它出发我们一路打通了文档清洗、混合切片、向量检索、RAG问答再到Agent编排和多Agent分工如今这套系统已经在设备维护、工艺查询、新人培训三个方向跑起来了。这篇文章我想把这条主线完整拆开讲清楚从一份工业库到知识库Agent到底要跨过哪些看似不起眼、实际上很容易翻车的坎。内容偏工程实践适合正在做RAG或知识库Agent项目尤其是面向工业、制造、能源等垂直领域的朋友参考。1. 原点66页文档为什么会成为Agent项目的起点先聊当时的环境。很多制造业企业不是没数据而是数据散得太狠。设备参数在Excel里故障处理记录在工单系统里维护周期规范在纸档手册里还有一些关键经验只存在于老师傅脑子里。你问一个新来的维修工“3号压缩机报E-1024是什么意思”他可能得先找人问手册放哪再翻半天PDF最后还要猜老师傅说的“这种情况多半是油分堵了”到底对应哪个部件。这份66页手册是唯一一份相对集中、结构清晰、而且被高频翻阅的资料。我当时判断它可以当作验证知识库Agent的最小可行样本来用。原因有三个后面整个项目也都是围绕这三条展开的。1.1 工业现场的知识困境远比想象中严重我们遇到的不是“没有知识”而是“知识无法触达”。同样是E-1024报警手册里写的是“油气分离器压差过大”工单记录里可能写的是“换油分芯解决”老师傅口述里还可能带上“顺便查下回油管有没有堵”。这三段信息分散在不同介质里人工串联一次至少半小时。工业场景还有一个特点很多知识是过程性的不是“某个值是多少”就能结束。故障排查要按症状走链路维护计划要结合运行时长备件申请要关联物料编码。纯文档堆砌根本解决不了这些问题必须有一个能把多源信息串起来、还能按流程引导用户完成任务的载体。这就是我后来坚定要做Agent而不是只做一个“文档问答机器人”的原因。1.2 为什么从66页而不是直接上大而全的知识平台我也见过不少团队一上来就规划“全公司知识图谱”“所有系统打通”结果项目框了半年还没收到第一份可用的文档。这种做法在工业领域尤其容易死因为你面对的不是一两种格式而是扫描版PDF、老掉牙的Word、格式千奇百怪的Excel、甚至是CAD图纸截图。数据治理还没做完业务部门已经没耐心了。从66页切入的好处是范围小能快速跑通“文档—知识库—Agent”的完整闭环同时它足够典型表格、步骤、告警代码、注意事项全都有代表性并不差。我把这个阶段定义成“打样”。打样阶段不追求覆盖只追求验证技术可用性和效果上限。如果连一本结构清晰的手册都做不好后面接再多的数据源也是白搭。1.3 手册内容画像决定了后续切片方式动手之前我先把这66页做了内容画像。大致分类是这样的技术参数表、操作步骤、维护保养周期表、故障代码表、注意事项、备件清单。不同类型的知识适用的切片和检索策略完全不同。比如表格不能简单按长度切否则一行参数会被拆成两半操作步骤必须整段保留否则Agent拿到半截步骤根本没法执行故障代码表更适合做结构化抽取而不是塞进向量库里模糊检索。这个画像动作看起来简单但它直接决定了后面知识库的质量。我后来接入其他文档时也沿用了这套思路先做内容分类和结构拆解再决定每条知识用什么方式入库。很多人把RAG效果不好归结为模型不行其实大部分问题在入库阶段就埋下了。2. 从“能翻到的PDF”到“能检索的知识库”知识库Agent的底层离不开RAG而RAG的命门在入库。入库这一关不过后面模型再强也是空转。这一节我把从文档到可检索知识的完整链路拆开重点讲最容易出问题的几个环节。2.1 文档解析与清洗工业文档远比你想象的脏这本手册的基础格式还算规整是电子版Word导出的PDF不是扫描件省去了OCR这一步。但工业文档真正让人头疼的不是格式而是“内容杂质”。页眉页脚、目录区、重复出现的公司logo、图纸标注、修订记录表这些如果不清洗切割之后就会变成带噪音的向量块把检索结果带偏。流程上我们分三步做第一把PDF解析成Markdown保留标题层级第二做规则清洗去掉页码、目录、空行乱码第三把表格区域单独抽出来转成Markdown表格而不是让解析器把它识别成纯文本。做这一步时要注意很多PDF解析库对复杂表格的支持很差识别出来是乱的必须人工校验一遍。我当时抽了5页做了对比。清洗过的版本检索命中率明显比直接解析的版本高最直观的变化是问“E-1024报警”时返回的内容不会再夹杂下一页的“检查油位”了。2.2 切片策略不是所有文档都适合固定长度早期我也偷懒用固定512字符切片结果效果一塌糊涂。最大问题是一条完整的维护步骤被从中间切断检索时Top1只返回了前半段LLM拿到半截上下文回答自然也是半吊子。后来我改成混合切片策略有三个原则按章节标题划分段落尽量让每个切片在语义上完整表格按行转成独立条目每个条目附带表头和来源章节操作步骤按编号保留整组步骤不切割单个步骤内部。每个切片都写了元数据包含来源文件名、一级章节、二级章节、设备型号、文档版本。这些字段后面会成为Agent检索的过滤条件。比如用户说“只看3号压缩机的维护周期”检索层就直接用meta过滤而不是每次都在全库里模糊找。这个设计非常关键知识库一旦大了纯靠向量相似度是拉不住精度的。2.3 向量化与Embedding选型先别迷信“通用大模型”Embedding模型这块我踩过一个坑通用Embedding对日常文本表现不错但遇到工业缩写、专业术语就有点发懵。比如“油分芯”“压力开关”“PID调节”这些词在通用模型里的语义表征不够准。一个可以立刻上手验证的方法是准备20条领域问答人工看召回内容的相关度。向量库选型上小规模场景不必一上来就上重型中间件。当时我们单机、文档量小用了pgvector就够跑维护成本也低。后期数据量上来、并发上来之后再迁到独立的向量库或者走商业化方案。选型原则很简单用最少的技术组件跑通流程瓶颈出现在哪再针对性升级别为了“架构先进”牺牲迭代速度。3. 知识库变Agent除了检索增强还加了什么这是题目里“知识库Agent”最核心的部分。很多人以为在RAG外面套一层Prompt就是Agent了其实不是。Agent的意义在于能拆解任务、调用工具、组合多段知识并且能多轮维护对话状态。这一节讲我们在检索之外加的几层东西。3.1 从RAG到Agent为什么单纯问答不够用RAG能解决“某个参数是多少”“这个报警代码是什么意思”这类单跳问题。但工业现场的真实请求往往是复合的比如“3号压缩机最近老跳机帮我分析一下可能原因顺便查下上次维护记录”。这个问题至少涉及三个动作查询报警知识、检索历史工单、按故障树做多步推理。如果只在知识库上做相似度检索LLM没有能力组织整个排查过程。Agent在这里的价值有三点规划把整个问题拆成子任务调用按需触发检索或工具记忆维持多轮上下文。我们把RAG当成Agent的一个工具而不是全部。知识检索负责拿事实Agent负责拿事实之后怎么组织、怎么追问、怎么结合其他系统数据。3.2 Agent的编排逻辑固定Pipeline优先于“让模型自己全选”我一开始也试过完全开放式Agent给LLM一堆工具让它自己决定调用顺序结果在工业场景里可控性太差。LLM经常跳步骤或者自作主张用户问A它先调用B再查C绕一大圈。后来我们改用类似dify知识库流水线的编排思路把主要场景做成固定节点Agent只负责分支处理。一个典型的“故障排查Agent”编排流程是意图识别与槽位抽取设备编号、故障现象→ 按元数据过滤的知识检索只查对应设备型号→ 工具调用查历史工单、查备件库存→ 生成回答并附引用来源。这套流程跑下来稳定性比完全开放式的Agent高很多。比如用户说“3号压缩机跳机怎么办”意图节点先识别出“设备3号空压机”“现象跳机”后续检索和工具调用都在这个上下文里执行。3.3 意图识别与对话管理别小看“它”指什么工业对话有个特点用户输入特别短经常是“它后来又报了”“还是不行”这种指代。如果不做对话状态管理Agent根本不知道“它”指哪台设备。我们在Agent前面加了一层轻量级的会话槽位管理维护当前设备ID、当前故障类型、历史操作记录。举个例子用户第一轮问“3号压缩机报E-1024”第二轮说“怎么处理”槽位里已经记住了设备号和报警代码第二轮不再需要用户重复。这层对话管理不需要很复杂的架构。我是用会话级别的字典槽位加LLM抽取实现的每次用户输入先走一个抽取节点把设备号、现象、时间等关键信息填进槽位再交给下游节点。效果比把全部历史对话丢给LLM自己理解要稳定得多也省Token。4. 实测中踩过的坑图片、表格、并发与幻觉跑Demo过不了瘾真正让人长记性的是上线前后的各种坑。这一节把我们在图片处理、幻觉控制、版本更新和并发性能上遇到的问题完整复盘一遍都是可以直接参考的实测经验。4.1 图片和表格不能只存图也不能只丢给向量库很多工业文档的关键信息藏在表格和图里。表格还好处理转成Markdown或JSON就能入库。图片才是大坑接线图、示意图、液压原理图这些光靠向量检索没有任何意义Embedding模型根本不理解图形内容。我当时的方案分三类处理参数表格结构化抽取后按行转成带表头的文本条目入库设备示意图用图像描述模型生成文字说明附在上下文里一起入库复杂原理图如电气接线图不在RAG阶段硬塞单独维护一份图解索引由人工维护关键词和指向Agent需要时通过工具返回对应图片链接。有一阵子我们偷懒把一张液压原理图的扫描件直接丢了进去结果用户问“油路走向”时Agent一本正经编了一段流程事后核对完全是错的。所以说图片类知识要做的是“把图变成可检索的文本结构”而不是指望向量库理解图片本身。4.2 幻觉与答案置信度工业场景宁可说“不知道”工业领域里幻觉不是一个体验问题是一个安全风险。一次虚报的“液压油更换周期”可能直接导致一次保养误操作。我们用了几个组合手段来控幻觉。检索上把Top-K从3提到5让LLM交叉对比多段内容再回答生成上Prompt里明确要求“只允许依据检索到的资料作答资料中未出现的内容回答‘资料库暂无此内容’”输出上每条回答后面附引用来源用户能回溯。数值类问题我们还加了一道后处理校验让程序把答案中的数值和原文切片里的参数做一致性比对不一致就打回重新生成。印象最深的一次模型回答“液压油每2000小时更换一次”但手册原文其实是“首次2000小时之后每4000小时”。因为检索返回的切片里有两段相近内容模型选错了锚点。加了来源校验之后这类问题基本绝迹。对小团队来说这个校验逻辑实现起来不难但收益极大。4.3 知识更新与版本管理66页手册不会永远不变设备厂家会发修订版企业自己也会加补充说明。知识库最怕的是文档已经更新了向量库里还挂着旧内容。用户问到更新后的问题Agent可能还在引用旧版本一旦出了事再回溯很难定位是哪一次同步的问题。我们做了一个简单的版本管理文档入库前先算文件HashHash变了才触发重入库向量切片里写入文档版本号检索时默认排除旧版本回答里显示“依据XX手册V2.3”。增量更新也比全量重建省很多事。这个设计从一开始就做了因为我知道一旦多本手册接入没有版本管理知识库很快就会混乱到没法用。4.4 并发和性能瓶颈往往不在向量检索项目从测试走向生产第一个迎面而来的问题就是并发。有段时间上线测试上午十点车间一窝蜂提问请求直接排队部分请求超时。我们当时还没上复杂架构就是单机FastAPI加异步调用。排查后发现瓶颈几乎全在LLM接口的响应时间上向量检索本身只要几十毫秒。优化路径分了四步第一给高频问题做缓存完全相同的问法直接走缓存不调LLM第二给LLM调用加排队和限流避免突发流量打爆上游额度第三非核心任务降级比如“生成维护工单草稿”这类低优先级任务放到后台队列处理不阻塞即时问答第四检索层加URL缓存和连接池复用。这套组合下来实测同样的流量下接口成功率从85%出头拉到了98%左右。我的体会是先压住生成层再回头优化检索层别一上来就加一堆分布式组件。5. 66页之后知识库Agent主线的扩展路径系统跑通之后新的问题来了一套只能答66页手册的Agent价值终究有限。下一步怎么扩展这一节讲讲我们后来从单手册到多数据源、从单Agent到多Agent分工的思路。5.1 从一份手册到全量工业文档第一版稳定之后我们开始接入点检表、SOP文件、历史工单、设备技术通报。这里有一句话我觉得特别重要不要等所有数据都整完再上线。工业知识永远整理不完正确做法是让每类文档以“最小可用状态”接入先解决覆盖率痛点再逐步精修。每接入一类文档还是走之前那套方法内容画像、清洗、混合切片、元数据标记。比如历史工单这种非结构化文本数量大、质量参差就不能像手册那样精细处理而是按时间、设备类型、故障现象做粗粒度切片让Agent在检索时按设备ID过滤。多类文档接入后知识库的覆盖面从“一本手册”变成了“一套经验库”Agent回答问题时引用的资料能横跨多份文档实际可用性上了一个台阶。5.2 多Agent分工按知识域和操作类型拆数据多了以后单Agent什么都能答一点但什么都不够精。我们后来拆成了几个专职Agent设备知识Agent负责参数和故障代码工艺知识Agent负责SOP和调试步骤工单Agent负责历史记录和备件信息。前面对话管理节点变成总调度按意图分发给对应专职Agent。拆分有两个原则按知识域拆让每个Agent只检索自己那一亩三分地精度更容易控制按操作类型拆比如“查询类”和“创建工单类”分离避免让Agent同时处理读和写两种风险完全不同的操作。多Agent不是银弹编排和错误传递的复杂度都更高。我的建议是先用固定Pipeline跑稳再在确有分支需要时引入多Agent——而且每个Agent的职责边界必须清晰否则调试起来非常痛苦。5.3 三个让我少走弯路的经验最后分享三条实际体会。第一上线前一定要建回归测试集。我们准备了一个50条工业问答的golden set覆盖参数查询、故障处理、多轮追问、拒答场景每次改完切片策略、Prompt或检索参数先跑一遍回归测试再上线。这个习惯至少帮我们挡掉了七八次“修好一个问题、弄坏三个回答”的尴尬。第二知识处理的工程量远大于模型调优。很多人觉得知识库Agent的瓶颈是模型能力实际上绝大部分问题出在文档不干净、切片不合理、元数据缺失这些“脏活”上。把骨架内容处理好模型才能有米下锅。第三保持“从66页开始”的心态。这句口号背后的含义不是让大家只做小项目而是先用最小闭环验证再用真实反馈驱动扩展。工业知识库Agent这条路没有终点永远有新的数据源、新的场景、新的用户习惯要适配但主线立住了后续都是沿着这根主线往上长。这套从66页工业库长出的知识库Agent直到今天还在持续迭代。每次在车间里看到维修工直接对着屏幕问“这台设备的油分更换周期是多少”而系统在几秒钟内给出带出处、带版本的答案时我都觉得当初那句启动会上的话成真了。如果你也正在做类似的事我建议你从手边最常被翻的那份文档开始把它变成你的第一个66页。