Java系统里做Agent+RAG落地实录：让AI从会回答到会干活-北京尧图网络

制造业的Java系统里做AgentRAG落地最难的不是把大模型的API接通也不是把向量库搭起来而是让AI真正从“会回答”跨到“会干活”。我们在一家装备制造企业的维修业务系统上跑通了一个典型场景老师傅的经验沉淀在PDF规范、维修记录和工单备注里新来的维修工不懂“液压泵异响”应该先查哪份手册系统又是典型的Java单体加微服务工单、库存、点检各有各的模块。老板只给了一句话别做个聊天机器人要能自己查资料、自己判断、按流程去干活。这篇文章就把这个项目的方案设计、技术选型、核心实现和排坑过程完整写下来希望能给同样在Java技术上做AI落地的团队一点参考。1. 这个项目到底在解决什么问题制造业的Java系统里做AgentRAG听上去像是一堆技术流行词的组合但真落到代码里你会发现大部分团队的第一反应是把大模型接进来、做个问答框就收工。问答框做完才知道那只是最外面一层皮真正难的是让AI在系统里产生业务价值。这个项目最初的诉求其实特别朴素。某装备制造企业的维修部门几十个工程师面对几千台设备、上万份设备手册、每年几万条维修记录。问题越来越集中老工人经验丰富但知识带不走新工人遇到故障只会翻手册翻半天找不到对应条目系统里明明有历史工单却没人会去借力。企业领导后来给IT提了个要求搞一个AI助手让新人也能像老工程师一样“查得到、想得通、做得出”。1.1 制造业知识库的“三座大山”制造业企业的知识资产至少有三个特征是通用互联网知识库没有的。第一是文档质量参差不齐。设备手册有PDF、有Word、有扫描件还有供应商给的一堆参数表维修记录呢字段填得随心所欲故障描述经常是“泵不转”“声音大”“漏油”这种口语化表达有些SOP流程文件甚至十年没更新过。直接把这些文档丢给大模型结果就是幻觉率居高不下答得顺溜但没一句能落地。第二是术语体系极度混乱。同一个配件设计部门叫“液压站总成”维修部喊“泵组”老师傅直接说“那台嗡嗡响的机器”物料编码在ERP里是一套在EAM系统里又是另一套。通用语义检索在这种场景下经常翻车因为向量模型根本不知道“嗡嗡响”和“液压泵轴承磨损”是同一个问题。第三是知识时效性强。设备的升级改造经常发生供应商会发布新的操作手册老手册里的参数不再适用。如果知识库只管灌数据不管失效管理AI会把过时的扭矩参数当成标准答案推荐给工人这种错误在制造业里就是实打实的安全事故风险。1.2 RAG和Agent分别负责哪一段项目启动以后我们发现团队内部对“RAG”和“Agent”的理解其实很模糊。这里先做个统一RAG是检索增强生成核心是让模型在回答前先去企业内部的知识库里检索相关资料把资料塞进上下文再生成答案。Agent则更进一层它把大模型当作一个“调度大脑”让它自己去决定调用哪些工具、按什么顺序执行最终完成一个多步骤的任务。做个类比你就懂了。RAG相当于给一个新人配了台装满了公司制度和设备手册的平板电脑他回答问题时会去平板里翻资料Agent是给他开了个业务系统账号他不光会查资料还会自己点“新建工单”“提交领料申请”“发送维修通知”——当然账号的权限是有边界的高危操作旁边还要站个审批人。在制造业场景里这两个能力缺一不可。光有RAG没有AgentAI就是个高级搜索框能告诉你“应该换密封圈”但没法在系统里把领料单建好光有Agent没有RAG大模型就完全依赖自己训练时的记忆企业内部的知识一概不懂叫它干活等于让一个没进过车间的大学生去修设备。1.3 我们把目标拆成了三个台阶为了避免项目变成无底洞我们把最终愿景拆成了三层每一层都有独立的验收标准。第一层是知识问答目标是让AI能准确回答设备故障的排查方法、备件更换周期、操作规程等高频问题。验收标准很简单同一个问题问五个人工专家答案一致就算合格。第二层是辅助诊断让AI能根据用户描述的故障现象结合历史维修记录给出可能的故障原因和检查顺序。这层开始用上Agent的推理能力但动作只到“建议”为止不碰系统操作。第三层是自动执行让AI能直接把诊断结论转换成业务动作比如创建维修工单、派工给指定班组、生成备件领用申请。这一层才是真正把Agent的能力落到Java业务系统里也是整个项目里花费精力最多、坑踩得最深的部分。我们内部的原则是第一层必须做好第二层尽量做好第三层只开放读操作写操作一律走人工确认闸口。这个原则在后面帮我们避开了一堆生产事故。2. 整体方案设计与技术选型2.1 先打通一条端到端的链路很多团队做AI落地时喜欢先选模型、先搭框架结果做了一半发现链路根本走不通。我们这次反过来第一步先把端到端的调用链路画出来把所有模块之间的关系聊清楚再回头选组件。实际的链路是这样的用户提问进系统后先做意图识别判断问题类型是“知识查询”还是“动作请求”如果涉及多条知识或多次操作就进入Agent规划阶段Agent需要检索时就调RAG模块需要查系统数据时就调工具服务最后模型生成回复如果是动作请求还要生成一个“动作确认单”等用户在页面点击确认后才真正落库。这条链路里最容易被忽略的一点是Agent不是流水线它有可能反复横跳。用户问一句“一号泵站有点响帮我查下最近类似的故障顺便看看3号备件库存够不够”模型可能先查知识库再查维修记录再调库存接口每一步的中间结果都要被记忆并传给下一步。这就对上下文的组织能力提出了很高的要求绝不是简单地把所有检索结果拼在一起就能解决。2.2 技术组件选型的真实理由由于整个系统是Java技术栈我们一开始就排除了“另外起一个Python AI服务”的选项。原因是多方面的运维团队不熟悉PythonJava服务的监控体系已经成熟而且制造业的IT部门对新增技术栈的审批流程特别长。最终选型如下组件选型理由AI编排框架LangChain4j纯Java生态支持工具调用、记忆管理、流式输出团队上手成本低向量库pgvector直接复用现有的PostgreSQL不引入独立的向量数据库省运维Embedding模型开源中文向量模型bge-m3这一类中文效果稳支持80多种语言最重要的是能本地部署大模型私有化部署的Qwen-70B级别模型数据不出内网符合制造业保密要求OCR识别PaddleOCR对扫描版PDF工程文档的中文识别效果好能输出版面信息关键词检索PostgreSQL全文检索配合pgvector放在同一个库避免多系统编排这个选型方案的核心逻辑只有一句话能少引入一个组件就少引入一个。制造业企业最怕的是AI项目变成“为了新技术而新技术”搞出七八个中间件最后没人能维护。我们用pgvector复用PostgreSQL用LangChain4j复用Java开发能力整条链路里几乎没有需要单独运维的新组件。2.3 制造业场景带来的硬约束如果你也在给制造业企业做AI项目下面这几条硬约束几乎躲不掉。第一私有化部署。设备数据、工艺参数、维修记录都属于企业核心数据资产老板一听“上公有云API”直接就摇头。我们最终把大模型放在内网GPU服务器上虽然是70B级别一次推理要占不少显存但换来的是数据绝对不出内网。第二数据权限隔离。维修工只能看自己班组的工单工程师可以看设备全生命周期记录车间主任能看所有维修绩效。RAG检索和Agent工具调用都必须带上用户角色和机构范围不然AI就变成了越权帮凶。第三与现有系统集成时要“顺势而为”。这套Java系统里有现成的工单服务、库存服务、人员服务都是用Spring Cloud那套注册发现机制管理。Agent要调用它们最合适的方式不是绕过服务直接查库而是让Agent去调HTTP接口把AI编排层当作一个普通客户端。第四写操作必须有审计留痕。命令AI“再派一张工单”很容易但这个动作是谁提出的、基于什么检索结果做出的、经过了谁的确认每一步都必须记录。出了问题才有追溯的抓手。3. 核心实现拆解3.1 知识接入先把PDF变成能检索的“块”制造业知识库的源头特别杂我们第一步做的是把各种格式的文档统一转成标准文本。这个环节看似简单实际坑很多。扫描版PDF必须先过OCR。我们用PaddleOCR做了版面识别尽量把标题、正文、表格分开。这里有个细节工程手册里很多参数是表格型的直接按行读取会丢失上下文。我们在OCR后保留了一个“块结构”信息比如“章节3.2所属设备液压站”“表格4-1换油周期”。这样后续向量化时每个块都自带归属的对象检索时能通过元数据做精确定位。然后是文档切块。制造业文档有自己的结构特点一个章节讲一个主题一个主题里包含若干步骤。我们采用父子分块策略父块是一个完整的章节子块是章节内部的自然段落子块控制在300到500个token之间相邻子块之间保留50到80个token的重叠。实际检索时命中子块后再把父块内容一起塞给模型这样既保住了细节又给了上下文效果比大段落直接塞给模型好很多。切块的时候还做了一个很小的处理把设备编号、物料编号、产品型号统一抽取出来存成元数据字段。这个字段后面在检索时的作用比我们预想的大得多。3.2 检索链路单路不够必须多路召回刚开始我们天真地以为向量检索一把梭就完事了实测很快打脸。你在系统里搜索“叶片泵异响”向量召回能返回一堆语义相关但根本不涉及具体设备型号的资料你想找“CP-300液压泵”的手册向量检索反而会把“CP-300”拆得七零八落召回一堆无关结果。制造业大量查询涉及精确编码这恰恰是纯向量的弱项。我们最终做成多路召回。第一路是向量召回用Embedding模型算文本相似度第二路是BM25关键词召回管精确词和编号的引号匹配第三路是元数据过滤通过设备编号、物料编码、工单编号精确过滤。三条结果统一做RRF融合排序把排名分加权后重新排序再按Top K取前几块送入模型。这里想强调一点RRF融合听着玄乎实现起来就是给每路结果一个固定权重按排名位置而不是原始分数来加权。原因很简单向量分数和BM25分数不在一个量级上直接用原始分数相加毫无意义。位置加权后不同路召回的结果才能公平竞争。上下文构建也有讲究。我们不能把Top K的结果一股脑全丢给大模型因为RAG常见的“中间丢了”问题多是由上下文太长、最相关信息被淹没引起的。我们的做法是按重排分从高到低截取最多6个块每块尽量保留原文标题和来源路径拼成结构化提示词让模型必须标注引用来源。3.3 Agent编排把Java方法变成模型手里的“工具”Agent的实现我们完全依托LangChain4j的Tool机制。核心思路是把现有的Java服务方法注册成AI可调用的工具大模型通过“工具描述”和“参数说明”来理解每个方法的用途。我截取一个典型的工具定义Tool(value 根据故障描述查询相似历史维修记录, description 用于查询历史维修工单中相似故障的处理方式输入设备编号或故障现象返回维修记录列表) public ListRepairRecord searchRepairRecords( ToolParam(name equipmentNo, description 设备编号如果已知则填写否则可为空) String equipmentNo, ToolParam(name symptom, description 用户描述的故障现象例如液压泵异响、漏油、温度过高) String symptom ) { return repairService.querySimilarRecords(equipmentNo, symptom); }这段代码的关键不在业务逻辑而在那两行注释里。大模型没有机会看代码实现它只能依靠工具名和参数描述来决定“什么时候该调用这个工具”。我们把所有工具的注释都按照“输入什么、输出什么、适合什么场景”的模板重写了一遍就是希望模型在规划阶段少犯低级错误。还有一类操作需要小心有些工具不允许模型随意触发比如创建工单、锁定库存、派工。我们是把工具分成两个集合只读工具放在“自动可用集合”里写操作工具放在“确认集合”里。模型可以调用读工具自由检索但一旦要调用写操作就必须先输出一个动作请求由我们的代码拦截下来生成确认单等人点完确认才真的执行。3.4 写回业务系统Agent可以“建议”但“执行”必须过闸这一步是整个项目的分水岭。很多团队实现Agent时直接让模型调用接口落库图省事后果就是在生产环境里出现了一批不知道谁创建的垃圾工单、错误领料单。我们的方案是引入“动作确认单”机制。当Agent的规划结果里包含写操作时框架并不是立即执行而是把动作参数转成一个JSON对象展示给用户页面上有三个按钮确认执行、修改参数、取消。用户确认后后端才真正调用工单服务的接口。同时每个动作都带上一个请求ID作为全链路的幂等键。比如Agent要做“创建维修工单”动作确认单大概是这样的{ action: create_work_order, params: { deviceCode: CP-300-02, faultDesc: 运行时有异常噪声初步判断为轴承磨损, priority: 高, suggestedRepairer: 机修二班, knowledgeCitation: 设备手册章节3.2.1、历史工单WO-2024-0891 } }用户看到这个确认单可以修改优先级别、更换维修班组甚至可以删掉知识来源引用重新让AI再查一次。确认通过后系统把动作记录和AI推理过程一起归档工单服务以请求ID为幂等键落库重复提交不会产生重复工单。这套机制虽然牺牲了一点“全自动”的卖点但在制造业里它换来的是业务部门真正敢用、愿意用。4. 常见问题与排查实录4.1 检索不到知识怎么办从“泵异响”这个case说起项目联调期间出现了一个让我们抓狂的典型问题。维修工问“CP-300液压泵启动后有异响怎么回事”AI返回了一堆“液压泵工作原理”“液压泵保养周期”等泛泛内容完全没有命中那份详细描述“液压泵异响排查流程”的手册。排查了很久原因是两层第一向量模型认为“异响”和“噪声”语义相近但知识库里相关段落写的是“异常噪声”且正文里反复出现“振动”“轴承间隙”等词向量分布上离“异响”远了一点第二检索排序阶段工作原理类的段落因为整体长度长、关键词覆盖多排名反而被抬上去了。解决思路是双管齐下。一是建同义词扩展表把维修工常见口语词映射到文档里的标准术语“异响”映射为“异常噪声”“泵不转”映射为“电机驱动异常”“漏油”映射为“密封失效”。检索前先用这个表对用户输入做一次改写。二是在子块元数据里加入“故障现象”标签如果历史工单中该设备出现过相同现象把对应工单文本加权。实测下来这个处理让“异响类”问题的知识命中率从55%提到82%。你现在去问系统“泵嗡嗡响”它能直接定位到具体章节还会附上一条两年前的同型号维修记录作为参考。4.2 Agent连环调用出错模型总喜欢“顺手”建工单另一个高频坑是Agent的工具调用动作过于积极。用户明明只问“3号仓库还有没有这个型号的密封圈”Agent在规划时竟然先创建了一张领料申请单。这家伙抢跑的毛病简直像刚学会开车的新手一上路就自动变道。排查发现根因是工具描述里的模糊词太多。我们原本给创建领料单工具写的描述是“用于领料申请流程”模型在犹豫时就会把它当作“顺手能做的事”。后来把写操作工具的description收紧为“仅当用户明确要求申请领料时调用不得根据库存查询结果自动发起申请”。我们还加了两个硬规则一是所有写操作在调用前必须经过一个校验函数校验模型上一轮对话里有没有明确的用户指令二是给语言模型提供三个few-shot示例指导它在“用户问A但A附带条件B”时把B拆出来单独询问而不是自行决定操作。加了这两个规则以后误建工单的概率从每周七八次降到了整个测试周期一次。4.3 响应慢得像“下载大文件”性能优化的四板斧制造业用户没什么耐心一个查询如果超过十秒就会被判定为“不好用”。我们的链路细算下来确实慢用户输入要过Embedding模型向量库要检索关键词库要检索RRF融合后还要拼上下文再扔给70B大模型做生成。整套流程平均下来要七八秒高峰期更多。性能优化我们做了四件事。第一语义缓存。完全相同或高度相似的问题直接返回缓存结果缓存命中时响应时间降到1秒以内。第二限制Agent最大调用步数最多调用三个工具超过就到下一个规划阶段避免模型陷入死循环反复调接口。第三向量索引用HNSW算法并调低ef_search参数从“最精确”改成“足够好”。第四大模型生成开启流式输出用户能先看到文字在动等完整结果的时间体感上缩短一大半。优化后非流式接口的平均耗时从8秒压到4.5秒流式模式首字返回在2秒内。这里要说的一个经验是性能优化一定要盯着整个链路做只调大模型的推理参数没用很多时候瓶颈在向量库的查询并发和检索结果集的规模上。4.4 权限与数据安全AI越权问题比想象中隐蔽RAG只是给模型塞资料Agent却真的能动系统权限问题一下子就变得棘手。我们踩过的一个坑是一个维修工登录后Agent调用的历史工单查询接口返回了其他班组的工单原因是业务接口本身没做用户隔离只做了API Token校验。AI把这部分数据当上下文用等于变相对用户泄露了不该看到的信息。解决方法是把权限校验下沉到RAG和工具两层。RAG层面每个知识块在写入时打上部门和设备范围标签检索时根据当前用户的部门过滤工具层面每个工具方法在调用前都拿当前用户信息做一遍行级权限校验无权限就返回空结果并让模型据实回答“没有查询到相关数据”。这个校验逻辑听起来基础但很多快速落地的项目都会漏掉常在权限上埋雷。5. 效果复盘与一点个人体会5.1 一组可量化的落地结果整个项目从搭建到生产环境试点用了四个月测试范围覆盖维修部门两个班组。几个关键指标的变化比较能说明问题指标优化前优化后故障知识问答命中率55%82%维修工创建工单的人工纠错率35%15%平均查询响应时间8秒4.5秒写操作误触发次数周7次不到1次新员工独立完成常见故障排查比例不到四成七成以上客观说这个项目没有做出什么“全自动无人化维修”的壮观场面毕竟制造业的容错率极低AI稍微错一步就是设备停机或物料浪费。但它让一个很实际的事情变成了现实新来的维修工靠自然语言就能把老工程师的经验和流程知识用起来效率提升是实打实的。5.2 几句掏心窝的话这个项目做下来我最大的体会是AI落地的难点从来不在模型参数的多少而在工程系统的缝隙里。大模型是聪明但它对企业内部系统一无所知Java系统是一堆老接口、老数据但对AI来说全是一座等待开挖的矿藏前提是你得把路修好。想给后来人几个建议。第一先解决检索再上Agent。检索质量不过关Agent调用工具再准也没用最后生成的答案照样是垃圾进、垃圾出。第二写操作一定要晚点开放先让Agent老老实实当个“只读顾问”跑一个月让业务人员建立信任再考虑开放到自动创建工单这个级别。第三动作确认机制别省它不只是业务合规的需要更是给AI兜底的最后一道安全网。如果你也在做类似的制造业Java系统AI升级希望这篇内容能帮你少踩几个坑。后面我们准备继续优化两件事一是把工单知识自动沉淀进RAG库里让每次维修都在积累经验二是把Agent的规划能力做得更细尝试让它在多设备联动故障场景里做更复杂的判断。这些都是下一步的好玩方向等有结果了我再来更新。

Java系统里做Agent+RAG落地实录：让AI从会回答到会干活

相关推荐

VC++打印ZPL条码：USB直连GT800完整实现与避坑指南

n8n工作流模板化：从一次性脚本到可复用积木体系

Python+OpenAI API：从零构建带记忆的聊天机器人实战

更多资讯

Kubernetes探针实战：startup/liveness/readiness配置与调优

无人机航拍视角下的目标检测适配：从数据采集到YOLO模型优化落地

技能体系怎么搭？从知识到能力，用技能地图终结无效学习

PXE无人值守安装Ubuntu 20.04：dnsmasq+Apache+autoinstall实战

时域卷积网络TCN：从原理到实战的时间序列建模指南

交通信号灯识别数据集全解析：YOLO训练与82.88%识别率实测

今日更新

微信云开发旅游小程序实战：LBS打卡+UGC社交全栈方案

金融AI代理平台核心拆解：从多代理协作到财报分析实战

基于大数据的智慧旅游推荐与可视化平台架构实践

本周精选

金融AI落地指南：从调研报告到技术选型与工程实践

大模型上下文成本与注意力优化技术深度解析——为何O(n²)平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测

基于GMM的语音识别系统原理与MATLAB实现详解

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？