1. 一份66页工业库是怎么变成Agent主线的先说结论我手上这套知识库Agent的主线不是从某个开源框架的README里长出来的也不是从某篇讲RAG架构的论文里抄来的而是从一份66页的工业设备运维手册里硬生生啃出来的。这份手册是某产线设备的全生命周期文档包含安装参数、故障码表、巡检项、备件清单、润滑周期、电气接线说明页数不多但信息密度极高表格套表格图号交叉引用还有大量见第X页第Y节的跳转。我最初的想法很朴素把它塞进一个向量库做个问答机器人让现场的人不用翻PDF。结果第一版上线三天就被打回来了因为现场问的问题根本不是润滑周期是多久这种能直接命中一段文字的问题而是三号机昨天下午报E17我该先看哪里这种需要跨章节、跨表格、结合时序和上下文的问题。这就是知识库Agent这条主线的起点。它不是一个把文档切块、做embedding、检索、拼prompt的流水线而是一个需要理解文档结构、理解提问意图、理解现场约束的决策系统。我后来复盘发现真正把这条主线立起来的是三个很土但很关键的动作第一把66页手册拆成结构化的知识单元而不是等长的文本块第二给Agent设计了一套先定位、再取证、后回答的工作流而不是一步到位的检索问答第三把现场反馈变成知识库的持续修正信号而不是一次性交付。如果你现在也在做知识库相关的Agent不管是用dify知识库流水线、还是自己用ollama搭本地RAG、还是在研究agent框架与编排我建议你先别急着选框架。先问自己一个问题你的知识库是一堆文档还是一个有结构的领域模型这个问题的答案基本决定了你后面Agent主线的走向。下面我按自己踩过的顺序把这条主线拆开讲。2. 为什么切块向量检索在工业文档上会翻车2.1 等长切块切断了表格的语义完整性我第一版用的是最常见的做法按500字左右切块重叠100字然后丢进向量库。问题出在那份手册的故障码表上。这张表有六列故障码、含义、可能原因、排查步骤、关联部件、复位方式。按字数切经常出现故障码E17、含义伺服过载在一块里而排查步骤被切到下一块甚至复位方式被切到第三块。检索的时候用户问E17怎么复位向量检索命中的是含E17的那一块但那一块里没有复位方式。Agent拿着半截信息去回答要么答非所问要么开始编。这不是embedding模型不行是切块策略和文档结构不匹配。工业文档的语义单元是表格行和章节条目不是字数窗口。我后来改成按结构切表格按行切每行补上表头章节按最小标题层级切保留父级标题路径。切完之后每个知识单元都自带上下文比如第4章 故障处理 4.3 伺服系统 故障码E17 复位方式断电重启后长按复位键3秒。这样检索命中的单元本身就是完整的。2.2 向量相似度不等于业务相关性第二个坑更隐蔽。现场问三号机报E17向量检索会优先命中含E17的块这没问题。但现场还问昨天下午那台机器声音不对是不是要保养了这种问题里没有任何故障码、没有任何手册里的原词向量检索基本抓瞎。因为声音不对和手册里的异常噪音轴承磨损润滑不足在字面上不重合embedding虽然能拉近一点但拉得不够近。我当时的解法是加了一层意图路由先用一个轻量分类器判断问题类型——是故障码查询、是现象描述、是保养周期、还是操作步骤。不同类型走不同的检索策略。故障码查询直接走结构化查询查表现象描述走现象-原因映射表加向量检索兜底保养周期走规则计算。这层路由不复杂但效果立竿见影。后来我看到很多人在讨论agent架构和agent框架与编排其实核心就是这个Agent不是只有一个检索工具而是有一组工具关键是怎么根据意图选工具。2.3 单轮检索撑不起多跳问题最典型的多跳问题是E17复位后还报下一步查什么。这需要先查E17的复位方式再查复位后仍报的分支处理再查关联部件的检测方法。单轮检索只能拿到第一跳后面两跳要么靠模型瞎猜要么靠prompt里塞一大堆无关内容。我后来把Agent的工作流改成显式的多步第一步定位故障码第二步取复位方式第三步判断是否有仍报分支第四步取分支下的检测步骤。每一步都是一次独立的检索或查表步与步之间用状态传递。这样虽然慢一点但准确率从原来的五成多提到了八成以上。提示多跳问题的关键不是让模型一次想清楚而是把想拆成可验证的步骤每步都有明确的输入和输出。这跟agent记忆的设计是一个道理记忆不是把历史全塞进去而是把关键状态结构化地传下去。3. 把66页手册拆成Agent能吃的知识单元3.1 先做文档结构解析别急着embedding我现在的标准动作是拿到任何一份文档先做结构解析再做知识建模最后才做embedding。结构解析的目标是识别出文档的骨架——章节层级、表格边界、图号引用、交叉引用。这份66页手册里章节层级用编号区分1、1.1、1.1.1表格有明确的表头行图号是图3-2这种格式交叉引用是见4.3节。这些模式用正则加规则就能抽出来不需要上大模型。解析完之后我得到一棵文档树。每个节点有类型章节、表格、图、段落、有路径从根到当前节点的标题链、有内容。这棵树是后面所有工作的基础。很多人一上来就切块embedding相当于把树砍成木屑再想拼回家具费劲且容易丢信息。3.2 知识单元的三种形态条目、映射、规则从文档树往下走我把知识拆成三种形态。第一种是条目型知识就是故障码E17对应什么含义、什么原因、什么步骤这种结构化记录一条一条的适合存关系库或JSON。第二种是映射型知识比如现象异常噪音可能对应原因轴承磨损润滑不足异物进入这是多对多的映射适合存图或映射表。第三种是规则型知识比如运行满2000小时必须更换润滑油这是可计算的规则适合存成可执行的条件表达式。这三种形态对应三种检索方式条目型走精确查询映射型走向量加图遍历规则型走规则引擎。Agent在回答时根据问题类型调用不同的检索通道。这套设计比单一向量库复杂但它是知识库而不是文档库的分界线。我见过太多项目卡在文档库阶段就是因为所有知识都被压成了同一种形态——文本块。3.3 图片和表格怎么处理才不丢信息热词里有人问rag知识库能存储图片嘛知识库图片怎么处理我正好踩过这个坑。那份手册里有接线图和结构爆炸图纯文本检索完全覆盖不到。我的做法是图片不直接存进向量库而是给每张图生成一个图元描述——图号、图名、图中标注的关键部件、图对应的章节。这个描述是文本可以embedding。同时原图存在对象存储里检索命中描述后把原图URL一起返回给前端展示。表格的处理更细。表格不整体embedding而是按行拆成行知识单元每行补上表头作为字段名。比如故障码表的一行变成{故障码: E17, 含义: 伺服过载, 可能原因: [...], 排查步骤: [...], 关联部件: [...], 复位方式: ...}。这样既保留了结构又能被检索。如果表格很大还可以给每行生成一句自然语言摘要用于向量检索原始结构化数据用于精确查询。两条通道并行效果比单通道好很多。知识形态存储方式检索方式适用问题条目型关系库/JSON精确查询故障码、备件号、参数值映射型图/映射表向量图遍历相似度现象诊断、原因推断规则型规则引擎条件匹配保养周期、更换阈值图元描述向量库对象存储向量检索URL返回接线、结构、位置4. Agent工作流先定位、再取证、后回答4.1 为什么不让模型一步到位我试过让模型直接拿着检索结果生成回答结果很不稳定。同样的提问有时候答得对有时候把两个故障码的步骤混在一起。原因是模型在一步之内要同时做四件事理解问题、判断意图、筛选检索结果、组织答案。这四件事里任何一件出错最终答案就错。而且出错之后没法定位是哪一步的问题。改成多步工作流之后每一步只做一件事每步的输出都可以检查。第一步意图识别输出问题类型和关键实体第二步检索定位输出候选知识单元第三步取证验证检查候选单元是否真的覆盖了问题所需的信息第四步组织回答只基于验证过的单元生成。这样即使出错也能快速定位是意图识别错了还是检索没召回还是取证太宽松。4.2 意图识别用规则还是用小模型热词里有人问卡帕西的知识库可以用小模型做吗我的经验是意图识别这种分类任务小模型完全够用甚至规则加关键词就能覆盖大部分场景。工业场景的提问模式很有限无非是故障码、现象、保养、操作、参数这几类。我用了一个几百条标注数据微调的小分类模型准确率就很高了。真正需要大模型的是最后的答案组织和多跳推理那部分小模型确实吃力。这里有个取舍意图识别用规则维护成本低但覆盖有限用小模型需要标注数据但泛化好用大模型不用标注但延迟和成本高。我的选择是规则兜底加小模型主判规则处理高频明确模式小模型处理模糊表达。这个组合在工业场景下性价比最高。4.3 取证环节是准确率的分水岭我后来发现准确率提升最大的一步不是换更好的embedding模型而是加了取证环节。取证就是拿到候选知识单元后不直接生成答案而是先检查这个单元是否真的能回答问题。比如用户问E17复位方式候选单元里必须有复位方式这个字段且有值否则就判定为未召回触发二次检索或转人工。这个检查可以用规则做字段存在性检查也可以用小模型做判断单元与问题的相关性。我两种都用结构化字段用规则检查非结构化文本用小模型打分。加了取证之后答非所问的比例大幅下降。很多人做RAG只关注召回率忽略了召回的内容是否可用取证就是补这个缺口。注意取证环节会增加一次模型调用或规则判断延迟会上升。我的做法是分级高置信度的结构化查询跳过取证低置信度的向量检索必须取证。这样在准确率和延迟之间取平衡。5. 现场反馈怎么变成知识库的修正信号5.1 把答错了拆成可归因的几类现场反馈不能只记一个答错了那样没法修正。我把错误分成四类意图识别错、检索未召回、取证误判、答案组织错。每类对应不同的修正动作。意图识别错补标注数据检索未召回检查切块和embedding取证误判调整阈值或规则答案组织错优化prompt或换模型。这样每次反馈都能落到具体的改进点上而不是笼统地再调调。我甚至在Agent的输出里加了一个隐式的归因字段记录这次回答走了哪条路径、命中了哪些单元、取证结果如何。现场反馈回来时直接看这个字段就能定位问题。这个做法借鉴了agent execution terminated due to error这类错误处理思路——不是等崩了再查而是每一步都留痕。5.2 高频问题反哺知识库结构运行一段时间后我发现有些问题被反复问但知识库里没有对应的知识单元。比如三号机和四号机的E17处理一样吗手册里没有直接对比但现场很关心。这类高频问题就是知识库的缺口。我的做法是定期统计高频未召回问题人工整理成新的知识单元补进去。补的时候不是简单加一段文本而是按前面的三种形态建模该是映射就建映射该是规则就写规则。这个过程让知识库从静态文档变成活的结构。我后来看到有人讨论kg知识库、rag知识库和结构知识库的区分以及应用场景其实核心就是这个纯RAG是静态的知识图谱是结构化的两者结合才能既覆盖广又结构清。我的方案算是轻量版的混合没有上完整的图数据库但映射型知识已经用图的方式在存了。5.3 版本管理和回滚不能省知识库一改Agent的行为就可能变。我吃过一次亏更新了一批知识单元后原本答得对的问题开始答错查了半天发现是新单元和旧单元冲突检索时新单元把旧单元挤掉了。后来我加了版本管理每次知识库更新都打版本号Agent的回答记录里带上版本号。出问题时可以快速回滚到上一个版本再对比两个版本的知识差异。这个做法在软件工程里很常见但知识库项目里经常被忽略。很多人觉得知识库就是一堆文档改了就是改了。实际上知识库是Agent的事实来源它的变更必须像代码一样被管理。我现在用Git管知识单元的源文件用版本号管发布用回答日志管追溯。这套流程不复杂但能省掉大量排查时间。6. 并发、安全与本地化上线后才暴露的真问题6.1 并发不是加机器就能解决热词里有人问ai agent 怎么扛并发我的体会是Agent的并发瓶颈往往不在模型推理而在检索和状态管理。多步工作流意味着一次提问要多次检索、多次模型调用每次调用都有延迟。并发上来之后检索连接池、模型调用队列、状态存储都会成为瓶颈。我的做法是把无状态的检索和模型调用做成可水平扩展的服务把有状态的工作流状态存到外部存储比如Redis这样每个请求可以落到任意实例上。另外多步工作流要支持部分失败重试。比如第三步取证失败了不需要从第一步重来直接从第三步重试即可。这要求每一步的输入输出都可序列化、可恢复。这个设计在低并发时看不出价值高并发时能省掉大量重复计算。6.2 Agent安全要从工具权限入手Agent安全这个话题很大我只讲我踩过的具体点。Agent能调用的工具必须做权限隔离。比如查故障码的工具只能读不能写更新知识库的工具必须走审批不能由Agent自动执行。我见过有人让Agent直接改知识库结果一次误操作把一批知识单元删了。工具权限最小化是Agent安全的第一道防线。第二道防线是输出过滤。Agent的回答里不能包含未经验证的信息尤其是涉及操作步骤和安全注意事项的。我的做法是所有涉及操作的回答必须来自取证通过的知识单元且单元里必须标注来源章节。没有来源的回答一律不输出。这个规则很死但工业场景下宁可少答也不能错答。6.3 本地化部署的真实取舍热词里有ollama 简易本地 rag 知识库【零基础可复制教程】怎么在mac上搭建rag知识库本地化确实是很多人的需求。我的经验是本地化不是把所有东西都塞进本地而是把敏感数据和核心推理放本地把非敏感的工具调用放云端。比如知识库本身和embedding模型放本地答案组织可以用云端大模型如果数据脱敏后允许。这样既满足数据不出本地的要求又能用上更强的推理能力。如果必须全本地那就要接受模型能力下降和硬件成本上升。我试过用本地小模型做全流程意图识别和检索没问题但多跳推理和答案组织明显不如大模型。折中方案是本地做检索和取证云端做最终组织中间用脱敏后的知识单元传递。这个方案在合规和效果之间取了个平衡点。7. 这条主线还能往哪走我现在回头看这份66页工业库给我的最大启发不是某个技术点而是一种工作方式先把领域知识的结构摸清楚再设计Agent的工作流最后才选技术栈。很多人反过来先选框架再想知识怎么组织结果框架换了好几轮知识还是乱的。如果继续往下走我会做两件事。一是把映射型知识做成真正的图支持多跳推理和路径解释这样Agent不仅能答是什么还能答为什么。二是把现场反馈闭环做得更自动让高频未召回问题自动聚类、自动生成候选知识单元、人工审核后自动入库。这两件事都不容易但方向是清楚的。最后分享一个我一直在用的小技巧每次Agent答错我都会把那次完整的调用链路存下来包括问题、意图、检索结果、取证结果、最终答案。攒到几十条之后回看这些链路比看任何架构图都更能发现问题。知识库Agent这条主线说到底是在知识的结构和问题的结构之间找映射链路日志就是最好的地图。