★ FEATURED ARTICLE 做了一年多的 Java 企业级 AI 开发我得先冒个死说句可能不太中听的话从 2025 年往回看大模型应用落地这件事最大的瓶颈从来不是“模型不够聪明”而是“工程化跟不上”。很多人一提到 AI 开发就默认是 Python 的事但真到了生产环境稳定、可控、可审计、能治理这套东西反而让我这个 Java 后端有一种“主场作战”的感觉。这篇文章不是给你讲什么宏大叙事也不是介绍某个炫酷的 Demo。我想把过去一年在真实项目里折腾出来的框架赋能经验、架构取舍、踩坑复盘原原本本记录下来。内容全部围绕 Java 企业级 AI 开发从 Spring AI 这类框架到底帮你解决了什么到多模型接入、RAG 落地、Agent 编排再到线上被模型“忽悠”之后如何填坑。适合正在把大模型往业务里塞、但总觉得哪里没底的后端团队也适合想从 Spring Boot 直接切进 AI 开发的工程同学。1. 讲真企业级 AI 开发里最容易被低估的是 Java 这套底座1.1 从“先跑通再说”到“要稳定运行 90 天”的巨大落差我最早接触大模型应用是在一个智能客服的预研项目里。当时团队用 Python 快速写了一个链路读文档、切文本、算 Embedding、拼 Prompt、调用大模型接口一周时间就能在 Jupyter 里看到不错的问答效果。Demo 汇报时大家都挺兴奋觉得这个产品形态已经很完整了。但真实上线是另一回事。客服系统要跟工单系统打通用户提问进来要先鉴权要带着会员等级去查订单状态还要把回复记录写进审计日志遇到大模型接口抖动要考虑重试和降级管理员要能随时调整 Prompt 甚至禁用某个模型每天的 token 消耗要有报表要有预算熔断。这一套东西加起来Python 脚本式的原型完全撑不住。我们当时做了一个很现实的决定保留 Python 那边的算法实验结果工程部分全部用 Java 重写。这不是简单的“换语言”是把散装代码变成资产的过程。这个经历让我意识到企业级 AI 开发的核心命题不是“哪个模型更强”而是“怎么让模型在业务链路里被稳定地使用”。模型是不稳定的输入源它会超时、会乱说、会突然升级版本而 Java 后端的强项恰恰是把不稳定封装成稳定用接口定义行为边界用事务保证数据一致性用框架约束代码结构。这些东西在 Demo 阶段毫无价值上线三个月后就是生死线。1.2 我坚持 Java 路线的四个不吵架理由我知道只要提“Java 做 AI”一定会有人问为什么不用 Python我的回答从来不是“Java 优于 Python”而是“在绝大多数企业场景里Java 的技术债更可控”。四个理由都很实际第一工程生态完整。权限、配置中心、消息队列、定时任务、灰度发布、链路追踪这些企业级基础设施在 Java 生态里都是现成的。AI 应用不是孤岛它要融进现有平台用 Java 做接入团队不用重新造一套运维体系。第二强类型带来的可维护性。大模型的输入输出本质上是不稳定的 JSON但业务层需要的是稳定的对象。用强类型框架把 JSON 映射成 Record/POJO编译期就能发现字段不匹配比线上跑挂了再排查强得多。第三事务与一致性能力。比如“从知识库更新到向量数据重建”中间涉及多张表、两个存储系统没有事务支撑很难保证一致性。Java 在这一层的积累是很多动态语言给不了的。第四团队资源。大多数后台团队的人均 Java 水平是高于 Python 的。与其让所有人硬转不如把 AI 能力封装成内部服务让团队在熟悉的框架里调用这样开发效率和长期维护都会好很多。这四点不是说 Python 不行而是提醒大家做技术选型时别被“AI 就是 Python”的惯性带着走。你的项目如果不是做模型训练而是做模型应用Java 完全够用而且更稳。2. 框架赋能Spring AI 给了我一种“终于不用自己写胶水层”的解脱感2.1 它解决的核心痛点Prompt 封装、结构化输出、函数调用在 Spring AI 这种框架出现之前Java 接大模型真的是土办法接法用 OkHttp 发 HTTP 请求手动拼 JSON再用 Jackson 解析响应。当时最常见的一段代码是把系统 Prompt、用户问题、历史会话塞进一个 Map然后用 Jackson 序列化发给某个模型接口返回结果再解析成字符串塞进业务对象。单个模型还能忍一旦要接多个模型服务商每个服务商的请求格式、认证方式、超时配置都不一样这堆胶水代码就会变成灾难。Spring AI 给我的最大感受是它把“模型调用”这个动作抽象成了统一的范式。你可以把它理解成一个 JDBC 驱动层的角色业务方不需要关心底层具体是哪个模型服务商只需要面向一套 ChatClient 接口编程。它能帮你做 Prompt 模板管理、结构化输出映射、函数调用注册、记忆对话上下文这些高频又容易出错的细节。尤其是结构化输出以前模型输出稍微带点 Markdown 代码块标记我的 JSON 解析器就崩。现在我可以直接定义好一个 Java Record让框架负责把模型输出转成对象如果格式不对框架还会自动重试一次修正后的请求。这个能力在写业务代码时特别提气因为业务方要的不是“一段文本”而是“一个能落库的对象”。2.2 看一眼真实链路带 RAG 的客服问答长什么样我这里给一段简化版的伪代码大致能看出 Spring AI 在真实链路里承担的角色。假设我们要做一个客服问答接口它需要先从向量库检索相关知识再带着上下文去问模型。Service public class CustomerSupportService { // 由框架构建的 ChatClient本地方案可直接注入 private final ChatClient chatClient; private final VectorStore vectorStore; public CustomerSupportService(ChatClient.Builder builder, VectorStore vectorStore) { this.chatClient builder.build(); this.vectorStore vectorStore; } public Answer answer(Question question) { // 1. 从向量库召回相关知识片段 ListDocument docs vectorStore.similaritySearch( SearchRequest.builder() .query(question.text()) .topK(5) .build() ); String context docs.stream() .map(Document::text) .reduce(, (a, b) - a \n b); // 2. 让模型基于知识库上下文回答 String reply chatClient.prompt() .system(你是一个企业客服助手。只能基于参考资料回答 如果参考资料中没有答案明确说不知道 不要编造。回答要简洁。) .user(参考资料\n context \n\n用户问题 question.text()) .call() .content(); return new Answer(reply, docs); } }这代码不是完整生产版但结构是真实项目里的样子。注意几个点知识库召回结果也要返回给调用方方便前端展示“参考来源”这是企业级应用很核心的信任机制Prompt 里明确约束“不知道就说不知道”能明显降低模型胡编的概率。框架帮你省掉的是模型调用、消息组装、上下文管理这些在一个又一个项目里反复重写的东西。2.3 与另一个 JVM 系大模型编排框架的选型对比别只看 Star 数写到这里我得提一下当时纠结过的另一个方向另一款 JVM 系的框架它在 Python 生态有成熟原型Java 版本也做得比较早很多社区文章都在推。两者的定位其实略有差异。我整理了一张对比表按我们当时的评估视角来看对比维度Spring AI另一款 JVM 系框架与 Spring Boot 的贴合度原生整合自动配置、Starter 机制完善相对独立集成需要自己多写一些代码模型服务商支持覆盖面广常见供应商都有也很广且部分供应商支持更早结构化输出强支持类型映射和自动重试强有自己的链式抽象函数调用/工具调用支持且能利用 Spring 容器管理工具 Bean支持工具定义风格略有不同学习成本对 Spring 用户平滑对熟悉链式调用的人友好社区节奏背靠大的生态体系更新稳定社区活跃但方向偶尔漂移我的结论是如果团队本来就在 Spring Boot 体系里Spring AI 的维护成本最低如果你更看重链式编排的灵活性另一款也可以。真正不要做的事情是“因为某框架火就盲目引入”。框架只是胶水真正决定项目成败的是你周边的工程配套。3. 企业级架构不是“调大模型”而是把模型放进一条受控链路3.1 模型接入层多供应商切换不能靠 if else企业级系统往往不会只用一个模型服务商。原因很现实有的模型中文理解好有的模型函数调用稳有的供应商接口偶尔抖动需要冗余另外商务上通常要保有至少两家供应商避免被一家卡脖子。这就引出一个问题如果业务代码里到处是if (modelProvider A) {...} else if (modelProvider B) {...}那这个系统基本离重构不远了。正确的做法是在接入层定义一个只属于自己业务语义的接口把多模型封装成内部实现。接口可以长这样public interface AiCompletionPort { CompletionResponse complete(CompletionRequest request); }接口参数不要直接用某个模型的原生结构而是定义成业务自己的数据结构比如包含userId、sceneCode、messages、maxTokens、temperature等语义字段。在实现里做供应商映射配置中心动态控制“当前场景默认走哪家模型”。这样切换供应商时业务层零改动。除了切换接入层还要承担重试和降级。我的建议是重试策略一定要按供应商分场景配置。比如 A 家在返回限流错误时可以等几秒重试两次B 家遇到网关报错重试一次就够不要用一个全局配置否则很容易出现“一个供应商抖动系统自动重试引发流量放大”的悲剧。3.2 RAG 落地向量库、切分策略、召回排序的取舍RAG 可能是现在企业级 AI 应用里最热也最容易被做坏的部分。很多团队以为把文档丢进向量库就完事了结果线上问答效果很差最后怪“模型笨”。其实大多数问题出在建模数据阶段你喂进去的参考资料机器都读不明白。以我处理的某产品手册为例原始的 PDF 转出来是一大段一大段的文本里面还有表格、多级标题。如果直接整篇做向量化一次能塞进去几千字语义被均值化检索时根本匹配不到关键段落。后来我们采用的切分策略是先按章节结构切出大块再按段落边界切成 200 到 300 字的小块每块之间保留 30 到 50 字的重叠。这个尺寸不是拍脑袋定的而是因为我们用的模型 Embedding 维度在标准长度附近效果最好太长会稀释重点太短则丢失上下文。切分之外召回之后还有一个常被忽略的动作重排。向量检索只能保证“语义相似”不能保证“答案相关”。一个用户问“怎么退款”向量库里可能召回一堆介绍退款政策的页面但其中最直接的回答可能长在一份专门的售后流程文档里。我们当时用了一个比较轻量的重排方案把召回的前十条丢给一个小模型做一个“相关性打分”取前三条作为最终上下文。成本很低但回答命中率提升非常明显。这里我想提醒的一点是RAG 不只是“向量库 Embedding”的组合。它更像数据管道清洗、结构化、切分、向量化、缓存命中、召回、重排、上下文组装每一环都能影响最终效果。不要迷信某个向量数据库的召回精度数据质量才是天花板。3.3 Agent 编排先想清楚“允许模型做什么”再谈自主Agent 是另一个容易让人膨胀的话题。框架给了你 Tool Calling、多轮对话、任务规划能力开发者容易一不小心就设计出一个“什么都让模型决定”的流程。我在项目里吃过亏一个内部运营助手开放了查询数据库、发送通知、修改配置三个工具模型在一次多轮对话里自己串了一条“查询未支付订单 - 批量发送催付提醒”的动作链而且真执行了。当时测试环境里没事但要是放到生产环境这就是一次不小的风险事故。所以在做 Agent 编排时我心里有一条红线模型只能“建议做什么”不能“决定做什么”。具体来说凡是涉及数据修改、外部发送、资金操作的工具必须走显式确认流程。系统可以生成一个动作计划但最终要由用户在界面上勾选确认再由后端执行。对只读、低风险的工具比如查天气、查文档可以允许模型直接调用。另一个经验是给每个工具写清晰、谨慎的描述。模型调用工具依赖的是函数描述里的语义信息描述如果写得含糊比如“获取用户信息”模型就可能在未授权场景下滥用。应该写成“根据当前登录用户会话中已授权的 userId 查询用户基础资料不要直接接受用户传入的 ID”。这个细节看起来小但能省掉很多权限失控的麻烦。4. 线上踩坑清单Demo 里看不到的五个致命细节4.1 超时和并发请把大模型当成慢 SQL 来处理大部分后端工程师已经有了“数据库慢查询会拖垮系统”的肌肉记忆但面对大模型接口时很多人却会低估它。一个生成式模型的响应时间通常在 2 到 10 秒个别复杂任务甚至超过 30 秒。如果你的接口是同步调用模型那它的线程占用时间会比普通业务接口高一个数量级。我的建议是把模型调用当作慢 SQL 来治理。首先HTTP 客户端超时时间要分级连接超时 3 秒读取超时可以放宽到 60 秒但要根据业务场景调整。其次必须做并发限流最简单的方案是用Semaphore或者并发线程池隔离给每个模型供应商分配独立连接池避免 A 家模型的慢响应把 B 家模型的正常流量也拖死。我见过一个真实案例某接口没有任何隔离结果模型供应商变更后响应时间翻倍整个应用的 Tomcat 线程池被打满连健康检查都挂了。这个锅模型不背是工程没做好防护。另外对于用户反复提相同问题的场景务必要加一层缓存。大模型调用不是“读数据库”费用和时延都高很多会话里前几轮完全可以在本地命中。我一般建议对“相似度极高的问题”做短时缓存命中率通常能到 20% 以上效果非常可观。4.2 Token 成本失控一次重试策略缺陷让我烧掉了几千块的额度这是我最肉疼的一次踩坑。当时一个运营助手接入了某个模型服务商我在接入层写了一个“失败自动重试三次”的通用策略。本来这没什么但偏偏那天供应商接口出了大面积抖动响应全部延迟。重试逻辑没有做“退避”和“超时熔断”模型接口反正超时就重试重试又超时就这样循环轰炸。最要命的是重试时我还把上一次没消费掉的上下文原封不动又发了一遍导致 Token 消耗指数级上涨。等到值班同学发现时当天的费用已经是平时的一百多倍。后来复盘得出几条硬规矩第一重试必须指数退避且设置最大重试次数第二针对“上游超时”不要盲目重试要区分是可恢复的限流还是不可恢复的模型故障第三对单日 Token 消耗做预算熔断超过阈值直接降级到静态问答或者人工通道第四请求日志里必须记录每次消耗的 Token 数便于每日对账。这件事给我的教训是AI 应用的成本控制不是财务部门的事而是工程师的事。你必须在代码层面默认“模型调用是昂贵的”才能在接线上线之前就做好护栏。4.3 输出安全模型说的每一句话都不能直接当成系统输出第二个让我印象深刻的坑在输出侧。模型生成的内容看起来通顺但不代表它符合业务约束。我们做过一个生成商品卖点摘要的功能结果模型在某个批次里虚构了一个不存在的“限时折扣”差点被当成正式活动文案推送出去。从那以后凡是模型输出中涉及价格、时间、联系方式这类关键信息都必须经过规则校验或结构化抽取并和原始数据源核对。输出侧还要做脱敏。大模型在生成过程中可能把知识库里的敏感信息原样吐出来比如某个内部接口地址、某个客户的电话号码。我们的做法是在输出管道层加一个“敏感信息过滤”组件用正则和字段匹配把手机号、邮箱、内部域名替换成占位符同时所有模型输出都走审计日志一旦发现问题可以追溯到具体的请求和模型版本。最后是兜底话术。无论上下文检索还是重排都不可能做到 100% 召回正确内容。要给每个模型响应场景准备一个“不知道”的兜底模板。这个兜底不是简单说“我不清楚”而是要引导用户走人工渠道。靠模型自己判断“该不该承认不知道”不太可靠工程上更好用的策略是当召回文档的相关性分数低于阈值时直接不调用模型而是返回人工客服入口。这既省钱又减少了错误回答。5. 一套可参考的工程骨架与最终选型建议5.1 我现在的项目目录与核心依赖经过几个项目的迭代我落地的工程目录基本形成了稳定结构。它不是标准答案但很适合“模型为核心资产业务系统要稳定”的团队src/main/java/com/example/aiplatform/ ├── adapter / # 接入层封装各模型供应商 │ ├── port/ # 业务端口接口 │ ├── provider/ # 供应商实现 │ └── transform/ # 数据转换 ├── application / # 用例层承载具体业务场景 │ ├── service/ │ └── agent/ ├── domain / # 领域模型比如 Document、Prompt ├── rag / # 切分、向量化、召回、重排、缓存 ├── security / # 权限校验、脱敏、合规 ├── infrastructure / # 向量库、NoSQL、缓存等 └── web / # Controller、DTO、异常处理依赖方面我只列比较通用的东西Spring Boot 作为基础框架带 AI 能力的 Spring 生态模块向量库根据团队运维能力选择常见的是在 Elasticsearch 和独立向量库之间二选一对象存储和文件解析工具是 RAG 的标配。不要一上来就上很重的 BPM 或规则引擎先把核心链路跑通再做编排。5.2 性能与成本实测数据来自某模拟项目 X这里给一组我们内部用模拟项目 X 压测的数据SPA 场景偏咨询类问答。平均响应时间在 2.1 秒左右P95 是 4.8 秒P99 会跳到 7.5 秒主要波动来自模型供应商侧。并发方面我们把模型调用隔离到独立连接池单实例支持约 20 个并发在途请求系统本身没有出现线程耗尽。RAG 召回的总耗时稳定在 350ms 以内其中向量检索约占 120ms重排约占 180ms其余是文档读取和序列化。成本上加了缓存和上下文压缩之后单问题平均 Token 消耗下降了 58%。主要优化手段是不再把整段历史对话全部发过去而是把之前多轮结果压缩成“用户意图摘要”以及定期清理向量库中低点击率的内容减少无效召回。这些数据仅供参考不同模型差别很大但至少说明一个道理AI 应用的性能与成本是可以通过工程手段优化出来的。5.3 如果从零开始我会这样排优先级最后给准备入坑的团队一套优先级建议按这个顺序做返工概率会小很多第一先定义“输出协议”。不要先选模型先把业务需要的结构化输出定下来比如一个回答里必须包含“结论、依据、置信度、建议动作”。协议定稳了后面的 Prompt 和模型选型才有方向。第二再搭接入层。做好多模型抽象、超时隔离、成本预算、日志审计。这个阶段比较枯燥但它是整个系统最值钱的地基。第三然后是 RAG。先把文档处理管道做扎实再谈召回优化。别忘了缓存和安全过滤。第四最后才是 Agent 编排。如果你前两步没做好Agent 会让系统的混乱指数放大反过来前两步做好了Agent 就是水到渠成的上一层封装。这套顺序我亲测下来能让团队在每个阶段都有可交付的成果而不是等到最后一刻才集成爆炸。企业级 AI 开发听起来很大拆开看其实就是把一个不可控的模型服务嵌进一个可控的业务机器里。框架负责帮你省掉胶水代码而真正的护城河永远是工程上的每一道护栏。
阅读完成 · 觉得有帮助？
