1. 一个停更公告引发的技术选型焦虑前几天在技术群里看到有人转了一张截图说 Spring AI Alibaba 这个项目停更了紧接着就有人问了一句“Java 还有希望吗”。说实话看到这个问题的第一反应是有点哭笑不得——一个开源子项目的维护节奏变化怎么就直接上升到整个 Java 生态的生死存亡了但冷静下来想想这种焦虑其实很真实。这两年 AI 应用开发的浪潮里Python 几乎拿走了所有的聚光灯各种新框架、新工具、新论文的参考实现清一色是 Python 优先Java 开发者确实会有一种“我是不是选错赛道了”的恍惚感。我自己是写了十多年 Java 的人从早期的 SSH 时代一路做到现在的微服务和云原生中间也经历过无数次“Java 要完了”的论调。移动端兴起的时候有人说 Java 要完了Node.js 火的时候有人说 Java 要完了Go 和 Rust 起来的时候又有人说 Java 要完了。结果呢Java 依然是企业级后端开发的主力语言全球范围内运行着海量的关键业务系统。所以这次面对“Spring AI Alibaba 停更”这件事我想从几个更实际的角度来聊聊Java 在 AI 应用开发这条路上到底还有没有戏以及如果你是一个 Java 开发者现在应该怎么规划自己的技术路线。先说清楚一个前提Spring AI Alibaba 这个项目本身是一个把阿里系的大模型能力接入 Spring 生态的集成层它的停更并不意味着 Spring AI 本身出了问题更不意味着 Java 不能做 AI 应用。它只是说明一个具体的开源项目在维护策略上发生了调整。把单个项目的生命周期等同于整个语言生态的前途这个逻辑跳跃太大了。真正值得讨论的是Java 在 AI 应用开发中的定位是什么它的优势和短板分别在哪里以及在实际项目中我们应该怎么组合技术栈这篇文章会从项目停更这件事切入拆解 Java 在 AI 时代的真实处境分析 Spring AI 生态的现状和替代方案给出具体的选型建议和实操路径最后分享一些我在实际项目中踩过的坑和总结的经验。不管你是刚接触 AI 应用开发的 Java 新手还是正在做技术选型的老手应该都能从中找到一些有用的参考。2. 拆解“停更”背后的真实含义与常见误读2.1 开源项目的生命周期不等于技术栈的生死很多人看到“停更”两个字脑子里自动翻译成“这个技术不行了”。但开源项目的停更原因太多了维护者精力有限、公司战略调整、社区贡献者流失、项目目标已经达成进入稳定期、或者被更好的方案替代。Spring AI Alibaba 的停更更可能的原因是 Spring 官方自己的 Spring AI 项目在快速迭代社区维护的集成层需要重新找到自己的定位。这跟 Java 能不能做 AI 应用完全是两码事。我经历过一个类似的事情。早些年有一个很流行的 Java 工具库突然宣布不再更新了社区里一片哀嚎。结果没过多久核心贡献者另起了一个分支继续维护API 基本兼容迁移成本极低。开源生态的韧性就在于只要需求在总会有人接手或者出现替代方案。真正需要担心的不是某个项目停更而是这个需求本身消失了。AI 应用开发的需求显然没有消失反而在爆发式增长。2.2 Java 在 AI 技术栈中的真实位置要理性讨论这个问题得先搞清楚 Java 在 AI 应用开发中到底扮演什么角色。AI 应用开发大致可以分成几个层次底层框架和算法研究、模型训练和微调、模型推理和服务化、应用层集成和业务逻辑。Python 的优势集中在前两个层次因为它的科学计算生态和深度学习框架太成熟了。但到了模型推理服务化和应用层集成这两个层次Java 的优势就体现出来了。企业级应用需要的是什么高并发、低延迟、稳定性、可观测性、成熟的微服务体系、完善的安全机制、丰富的中间件生态。这些恰恰是 Java 深耕了二十多年的领域。一个 AI 功能最终要落地到业务系统里需要跟现有的用户体系、权限系统、数据库、消息队列、缓存、监控告警等一大堆基础设施打交道。在这些方面Java 的成熟度是 Python 短期内很难追上的。2.3 从“能不能做”到“怎么做更好”的思维转换我觉得很多 Java 开发者的焦虑来源于一个错误的比较方式拿 Java 去跟 Python 比谁更适合做 AI 研究。这就像拿卡车去跟跑车比谁跑得快然后得出结论说卡车不行。正确的问法应该是在 AI 应用开发这个完整的链条上Java 最适合承担哪个环节怎么跟 Python 生态配合实际的项目中我见过太多这样的架构模型训练和实验用 Python 做模型服务化用 Python 框架部署但整个应用层、业务逻辑、API 网关、用户系统全部是 Java。两边通过 HTTP 或者消息队列通信。这种混合架构运行得很好各取所长。Java 开发者不需要成为算法专家但需要知道怎么把 AI 能力集成到企业级系统里怎么设计高可用的推理服务调用链路怎么处理超时、降级、限流、缓存这些工程问题。3. Spring AI 生态的现状与可选替代路线3.1 Spring AI 官方项目的进展与能力边界Spring AI Alibaba 停更了但 Spring 官方的 Spring AI 项目一直在活跃开发。它提供了统一的 API 来对接不同的大模型服务包括对话、嵌入、图像生成等能力。核心抽象是 ChatClient、EmbeddingClient 这些接口开发者可以通过配置切换底层实现。这个设计思路很 Spring跟当年 Spring Data 统一各种数据库访问的方式一脉相承。不过要客观地说Spring AI 目前还在快速演进阶段API 时有变动文档也不够完善。我在一个内部项目里用过早期版本踩了不少坑比如配置项的命名前后不一致、某些模型的参数传递方式不统一、流式响应的处理逻辑比较复杂等。但整体方向是对的它解决的是 Java 开发者接入大模型能力的“最后一公里”问题。3.2 直接使用 HTTP 客户端对接模型 API 的可行性如果你不想依赖 Spring AI 这种封装层完全可以直接用 Java 的 HTTP 客户端去调模型服务的 REST API。这种方式最灵活也最可控。我现在的做法是对于简单的场景直接用 Java 11 的 HttpClient 或者 OkHttp 发请求自己封装一个轻量的客户端类。这样不依赖任何框架的版本节奏升级和维护都由自己掌控。具体来说你需要处理几个关键点请求体的 JSON 序列化用 Jackson 或者 Gson、认证信息的配置管理、超时和重试策略、流式响应的解析SSE 格式、错误码的统一处理。这些工作看起来琐碎但一旦封装好后续所有项目都能复用。而且因为不依赖第三方框架你不用担心某个项目停更导致你的代码无法运行。3.3 其他 JVM 生态的 AI 集成方案对比除了 Spring AIJVM 生态里还有一些其他的选择。比如 LangChain4j它的设计思路参考了 Python 的 LangChain提供了链式调用、提示词模板、记忆管理、工具调用等能力。还有 Semantic Kernel 的 Java 版本不过成熟度相对低一些。另外一些云厂商也提供了自己的 Java SDK直接对接自家的大模型服务。方案优势劣势适用场景Spring AI与 Spring 生态无缝集成抽象统一版本迭代快文档待完善Spring Boot 项目快速接入LangChain4j功能丰富链式编排能力强学习曲线较陡社区相对小复杂的 AI 工作流编排直接 HTTP 调用最灵活无框架依赖需要自己处理所有细节对可控性要求高的场景云厂商 SDK与自家服务深度集成绑定特定厂商已使用该云服务的项目选哪个没有标准答案取决于你的项目需求、团队技术栈和对可控性的要求。我的建议是如果是新项目且用 Spring Boot可以试试 Spring AI如果需要复杂的 AI 编排逻辑看看 LangChain4j如果追求极致的可控性和轻量级直接 HTTP 调用最稳妥。4. Java 开发者在 AI 时代的核心竞争力构建4.1 工程化能力才是 Java 开发者的护城河AI 应用开发到最后拼的不是谁更懂模型原理而是谁能把 AI 能力稳定、高效、安全地交付到用户手里。这恰恰是 Java 开发者的强项。我参与过一个智能客服系统的建设模型本身是算法团队用 Python 训练和部署的但整个系统的工程架构是 Java 做的。我们需要处理的问题包括如何管理多轮对话的上下文、如何做意图识别后的路由分发、如何对接工单系统和知识库、如何做灰度发布和 A/B 测试、如何监控对话质量和响应延迟。这些问题没有一个能靠调模型 API 解决全部是典型的后端工程问题。Java 开发者在这个层面的经验积累是巨大的优势。你知道怎么设计高可用的服务架构知道怎么做熔断降级知道怎么用缓存提升性能知道怎么通过日志和指标做问题排查。这些能力在 AI 应用开发中同样核心甚至比模型本身更重要。4.2 需要补哪些 AI 相关的知识短板当然光靠工程能力还不够Java 开发者确实需要补一些 AI 相关的基础知识。但不需要学到能推导反向传播的程度而是理解几个关键概念Token 是什么、上下文窗口怎么影响设计、温度参数怎么控制输出、嵌入向量怎么用于语义搜索、提示词工程的基本原则、RAG 的基本流程。这些知识足够你跟算法团队有效沟通也足够你做出合理的技术决策。我自己的学习路径是先动手调通一个模型 API理解请求和响应的结构然后做一个简单的问答应用体会提示词对输出质量的影响接着尝试用嵌入向量做语义搜索理解向量数据库的作用最后研究 RAG 的完整流程包括文档切分、向量化、检索、重排序、生成。每一步都动手写代码不追求理论深度但求理解实际效果和边界。4.3 从“写代码的”到“解决问题的”角色转变AI 时代对开发者的要求其实更高了。以前你只需要把需求翻译成代码现在你需要理解业务问题判断哪些能用 AI 解决、哪些不能用、怎么用效果最好。这需要你具备更强的业务理解能力和技术判断力。比如同样是做一个文档问答功能你可以选择用大模型直接回答也可以选择用 RAG 先检索再回答还可以选择用传统的全文搜索加规则匹配。每种方案的准确率、成本、延迟、可维护性都不一样。Java 开发者如果能把自己的工程能力跟对 AI 能力的理解结合起来就能从“写代码的”变成“解决问题的”。这个转变过程中沟通能力、架构思维、成本意识都会变得更重要。你需要能跟业务方解释为什么这个需求用 AI 做不划算需要能跟算法团队讨论模型部署的资源需求需要能跟运维团队协调 GPU 资源的分配。5. 实操用 Java 构建一个可落地的 AI 应用骨架5.1 项目结构与依赖选型说了这么多理念还是得落到代码上。我以一个典型的智能问答服务为例展示一下 Java 项目怎么搭建 AI 应用的骨架。项目用 Maven 管理依赖核心依赖包括Spring Boot 作为基础框架、OkHttp 作为 HTTP 客户端、Jackson 处理 JSON、Caffeine 做本地缓存、Micrometer 做指标采集。不引入 Spring AI 或 LangChain4j保持轻量。项目结构大概是这样的controller 层处理 HTTP 请求service 层封装业务逻辑client 层负责跟模型服务通信config 层管理配置model 层定义数据对象。这个结构跟普通的 Spring Boot 项目没有本质区别只是在 service 和 client 层多了跟 AI 相关的处理逻辑。dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.squareup.okhttp3/groupId artifactIdokhttp/artifactId version4.12.0/version /dependency dependency groupIdcom.github.ben-manes.caffeine/groupId artifactIdcaffeine/artifactId version3.1.8/version /dependency /dependencies5.2 模型调用的封装与异常处理模型调用的封装是整个项目的核心。我设计了一个 ModelClient 接口定义了 chat 和 embed 两个方法。实现类用 OkHttp 发请求处理超时、重试、错误码。关键是要把模型服务的响应格式统一转换成内部的数据结构这样上层业务代码不依赖具体的模型服务商。public interface ModelClient { ChatResponse chat(ChatRequest request); EmbeddingResponse embed(EmbeddingRequest request); }异常处理这块要特别注意。模型服务可能返回各种错误认证失败、配额超限、请求格式错误、服务内部错误、超时等。我定义了一个 ModelException包含错误码和原始响应信息。在 service 层根据错误类型决定是重试、降级还是直接返回错误给用户。对于超时设置合理的超时时间很关键一般连接超时 5 秒读取超时 30 秒流式响应的话读取超时要更长。5.3 提示词模板管理与版本控制提示词是 AI 应用的核心资产之一但很多项目把提示词硬编码在 Java 代码里这是个大坑。改一个提示词就要重新编译部署而且没法做版本管理和 A/B 测试。我的做法是把提示词模板放在外部配置文件或者数据库里用模板引擎做变量替换。每个提示词有唯一的 key 和版本号可以动态切换。public class PromptTemplate { private String template; private MapString, Object variables; public String render() { String result template; for (Map.EntryString, Object entry : variables.entrySet()) { result result.replace({{ entry.getKey() }}, String.valueOf(entry.getValue())); } return result; } }提示词的版本控制也很重要。每次修改提示词都应该记录修改人、修改时间、修改原因和效果对比。我一般会在数据库里建一张 prompt_history 表每次修改都插入一条新记录线上用的是最新版本但可以随时回滚到历史版本。5.4 缓存策略与成本控制大模型调用是有成本的而且延迟通常比普通接口高。合理的缓存策略能显著降低成本、提升响应速度。我在项目里用了两级缓存本地 Caffeine 缓存和分布式缓存。对于相同的问题如果短时间内重复提问直接返回缓存结果。对于嵌入向量因为计算成本高且结果确定缓存时间可以设得更长。CacheString, String responseCache Caffeine.newBuilder() .maximumSize(10000) .expireAfterWrite(Duration.ofMinutes(30)) .recordStats() .build();成本控制还有一个重要手段是 Token 用量监控。每次调用模型后记录输入和输出的 Token 数按用户和接口维度做统计。这样能及时发现异常调用比如某个用户短时间内大量请求或者某个接口的提示词设计不合理导致 Token 消耗过高。我一般会设置日限额和月限额超过阈值就告警或者限流。6. 踩坑实录那些文档里不会写的经验教训6.1 流式响应的线程安全问题流式响应是提升用户体验的关键但处理起来比同步响应复杂得多。我踩过的一个坑是在 Spring MVC 的异步请求里处理 SSE 流式响应时多个请求共享了同一个 OkHttpClient 实例结果在高并发下出现了响应串流的问题。一个用户的响应里混入了另一个用户的内容。排查了很久才定位到是 OkHttp 的连接池和事件监听器配置问题。解决方案是给每个流式请求创建独立的 Call 对象并且确保事件监听器里的状态是请求级别的不要用共享的可变状态。另外Spring MVC 的 SseEmitter 要设置合理的超时时间并且在完成或异常时及时调用 complete 或 completeWithError否则连接会一直挂着。6.2 模型输出格式不稳定的应对大模型的输出格式有时候不稳定你要求它返回 JSON它可能给你返回一段带 Markdown 代码块的 JSON或者前后加一些解释性文字。这在解析时就会报错。我的应对策略是第一在提示词里明确要求只返回 JSON不要加任何其他内容第二解析前先做清洗去掉 Markdown 标记和前后空白第三用宽松的 JSON 解析器允许一些格式偏差第四如果解析失败做一次重试重试时在提示词里强调格式要求。public String extractJson(String raw) { String cleaned raw.trim(); if (cleaned.startsWith(json)) { cleaned cleaned.substring(7); } else if (cleaned.startsWith()) { cleaned cleaned.substring(3); } if (cleaned.endsWith()) { cleaned cleaned.substring(0, cleaned.length() - 3); } return cleaned.trim(); }6.3 超时与重试策略的平衡超时和重试的设置需要仔细权衡。超时太短正常的慢请求会被中断超时太长用户等待时间过久。重试次数太多可能加剧服务端压力重试太少偶发失败会影响成功率。我的经验是连接超时设 5 秒读取超时根据场景设 30 到 120 秒流式响应可以更长。重试只针对可恢复的错误比如 429 和 5xx重试次数不超过 2 次并且要用指数退避。还有一个容易被忽略的点重试时要考虑幂等性。如果模型调用是有副作用的比如计费重试可能导致重复计费。这种情况下要么不重试要么在服务端做幂等处理。6.4 日志脱敏与数据安全AI 应用的日志里可能包含用户的敏感信息比如对话内容、个人信息等。直接打到日志里会有数据安全风险。我的做法是在日志输出前做脱敏处理对敏感字段做掩码或者哈希。同时日志的存储和访问要有权限控制不能谁都能看。另外如果用的是外部模型服务要确认数据不会被用于训练这通常在服务条款里有说明。7. 技术选型的决策框架与长期建议7.1 根据团队规模和项目阶段做选择技术选型没有绝对的对错关键看是否匹配团队和项目的实际情况。如果是小团队快速验证想法直接用 HTTP 调用最省事不需要学习新框架。如果是中型团队做正式产品可以考虑 Spring AI 或者 LangChain4j提升开发效率。如果是大团队做平台级产品可能需要自研集成层因为对可控性和定制化的要求更高。项目阶段也很重要。MVP 阶段追求快速上线怎么快怎么来。产品化阶段要考虑可维护性和扩展性需要更规范的架构。规模化阶段要考虑成本、性能和稳定性需要更精细的优化。7.2 保持技术栈的灵活性与可替换性不管选了什么方案都要保持可替换性。核心思路是在业务代码和具体技术实现之间加一层抽象。比如定义一个 ModelService 接口业务代码只依赖这个接口具体的实现可以是 Spring AI、LangChain4j 或者直接 HTTP 调用。这样将来换方案时只需要改实现类业务代码不用动。这个原则在 AI 领域尤其重要因为技术变化太快了。今天流行的框架明天可能就被新的替代了。保持抽象层的稳定让底层实现可以灵活替换是应对变化的最好策略。7.3 对 Java 生态未来的理性判断回到最初的问题Java 还有希望吗我的判断是Java 在企业级应用开发领域的地位短期内不会被动摇而在 AI 应用开发中Java 的定位会越来越清晰——不是做模型训练和算法研究而是做 AI 能力的工程化落地。这个定位的市场空间非常大因为最终所有的 AI 能力都要变成用户可用的产品而产品化恰恰是 Java 的强项。Spring AI Alibaba 停更只是一个小插曲它提醒我们不要过度依赖某个具体的开源项目而应该关注底层能力和工程方法。Java 生态的成熟度、稳定性和人才储备是它在 AI 时代最大的底气。作为 Java 开发者与其焦虑语言的前途不如把精力放在提升自己的工程能力、补充 AI 基础知识、积累实际项目经验上。这些才是真正属于你的竞争力。我在实际项目中的体会是技术浪潮来来去去但解决问题的能力和工程思维是通用的。把 AI 当成一个新的工具和新的场景用你已有的工程能力去驾驭它而不是被它吓倒。这条路我走过虽然有不少坑但每一步都算数。
1. 一个停更公告引发的技术选型焦虑前几天在技术群里看到有人转了一张截图说 Spring AI Alibaba 这个项目停更了紧接着就有人问了一句“Java 还有希望吗”。说实话看到这个问题的第一反应是有点哭笑不得——一个开源子项目的维护节奏变化怎么就直接上升到整个 Java 生态的生死存亡了但冷静下来想想这种焦虑其实很真实。这两年 AI 应用开发的浪潮里Python 几乎拿走了所有的聚光灯各种新框架、新工具、新论文的参考实现清一色是 Python 优先Java 开发者确实会有一种“我是不是选错赛道了”的恍惚感。我自己是写了十多年 Java 的人从早期的 SSH 时代一路做到现在的微服务和云原生中间也经历过无数次“Java 要完了”的论调。移动端兴起的时候有人说 Java 要完了Node.js 火的时候有人说 Java 要完了Go 和 Rust 起来的时候又有人说 Java 要完了。结果呢Java 依然是企业级后端开发的主力语言全球范围内运行着海量的关键业务系统。所以这次面对“Spring AI Alibaba 停更”这件事我想从几个更实际的角度来聊聊Java 在 AI 应用开发这条路上到底还有没有戏以及如果你是一个 Java 开发者现在应该怎么规划自己的技术路线。先说清楚一个前提Spring AI Alibaba 这个项目本身是一个把阿里系的大模型能力接入 Spring 生态的集成层它的停更并不意味着 Spring AI 本身出了问题更不意味着 Java 不能做 AI 应用。它只是说明一个具体的开源项目在维护策略上发生了调整。把单个项目的生命周期等同于整个语言生态的前途这个逻辑跳跃太大了。真正值得讨论的是Java 在 AI 应用开发中的定位是什么它的优势和短板分别在哪里以及在实际项目中我们应该怎么组合技术栈这篇文章会从项目停更这件事切入拆解 Java 在 AI 时代的真实处境分析 Spring AI 生态的现状和替代方案给出具体的选型建议和实操路径最后分享一些我在实际项目中踩过的坑和总结的经验。不管你是刚接触 AI 应用开发的 Java 新手还是正在做技术选型的老手应该都能从中找到一些有用的参考。2. 拆解“停更”背后的真实含义与常见误读2.1 开源项目的生命周期不等于技术栈的生死很多人看到“停更”两个字脑子里自动翻译成“这个技术不行了”。但开源项目的停更原因太多了维护者精力有限、公司战略调整、社区贡献者流失、项目目标已经达成进入稳定期、或者被更好的方案替代。Spring AI Alibaba 的停更更可能的原因是 Spring 官方自己的 Spring AI 项目在快速迭代社区维护的集成层需要重新找到自己的定位。这跟 Java 能不能做 AI 应用完全是两码事。我经历过一个类似的事情。早些年有一个很流行的 Java 工具库突然宣布不再更新了社区里一片哀嚎。结果没过多久核心贡献者另起了一个分支继续维护API 基本兼容迁移成本极低。开源生态的韧性就在于只要需求在总会有人接手或者出现替代方案。真正需要担心的不是某个项目停更而是这个需求本身消失了。AI 应用开发的需求显然没有消失反而在爆发式增长。2.2 Java 在 AI 技术栈中的真实位置要理性讨论这个问题得先搞清楚 Java 在 AI 应用开发中到底扮演什么角色。AI 应用开发大致可以分成几个层次底层框架和算法研究、模型训练和微调、模型推理和服务化、应用层集成和业务逻辑。Python 的优势集中在前两个层次因为它的科学计算生态和深度学习框架太成熟了。但到了模型推理服务化和应用层集成这两个层次Java 的优势就体现出来了。企业级应用需要的是什么高并发、低延迟、稳定性、可观测性、成熟的微服务体系、完善的安全机制、丰富的中间件生态。这些恰恰是 Java 深耕了二十多年的领域。一个 AI 功能最终要落地到业务系统里需要跟现有的用户体系、权限系统、数据库、消息队列、缓存、监控告警等一大堆基础设施打交道。在这些方面Java 的成熟度是 Python 短期内很难追上的。2.3 从“能不能做”到“怎么做更好”的思维转换我觉得很多 Java 开发者的焦虑来源于一个错误的比较方式拿 Java 去跟 Python 比谁更适合做 AI 研究。这就像拿卡车去跟跑车比谁跑得快然后得出结论说卡车不行。正确的问法应该是在 AI 应用开发这个完整的链条上Java 最适合承担哪个环节怎么跟 Python 生态配合实际的项目中我见过太多这样的架构模型训练和实验用 Python 做模型服务化用 Python 框架部署但整个应用层、业务逻辑、API 网关、用户系统全部是 Java。两边通过 HTTP 或者消息队列通信。这种混合架构运行得很好各取所长。Java 开发者不需要成为算法专家但需要知道怎么把 AI 能力集成到企业级系统里怎么设计高可用的推理服务调用链路怎么处理超时、降级、限流、缓存这些工程问题。3. Spring AI 生态的现状与可选替代路线3.1 Spring AI 官方项目的进展与能力边界Spring AI Alibaba 停更了但 Spring 官方的 Spring AI 项目一直在活跃开发。它提供了统一的 API 来对接不同的大模型服务包括对话、嵌入、图像生成等能力。核心抽象是 ChatClient、EmbeddingClient 这些接口开发者可以通过配置切换底层实现。这个设计思路很 Spring跟当年 Spring Data 统一各种数据库访问的方式一脉相承。不过要客观地说Spring AI 目前还在快速演进阶段API 时有变动文档也不够完善。我在一个内部项目里用过早期版本踩了不少坑比如配置项的命名前后不一致、某些模型的参数传递方式不统一、流式响应的处理逻辑比较复杂等。但整体方向是对的它解决的是 Java 开发者接入大模型能力的“最后一公里”问题。3.2 直接使用 HTTP 客户端对接模型 API 的可行性如果你不想依赖 Spring AI 这种封装层完全可以直接用 Java 的 HTTP 客户端去调模型服务的 REST API。这种方式最灵活也最可控。我现在的做法是对于简单的场景直接用 Java 11 的 HttpClient 或者 OkHttp 发请求自己封装一个轻量的客户端类。这样不依赖任何框架的版本节奏升级和维护都由自己掌控。具体来说你需要处理几个关键点请求体的 JSON 序列化用 Jackson 或者 Gson、认证信息的配置管理、超时和重试策略、流式响应的解析SSE 格式、错误码的统一处理。这些工作看起来琐碎但一旦封装好后续所有项目都能复用。而且因为不依赖第三方框架你不用担心某个项目停更导致你的代码无法运行。3.3 其他 JVM 生态的 AI 集成方案对比除了 Spring AIJVM 生态里还有一些其他的选择。比如 LangChain4j它的设计思路参考了 Python 的 LangChain提供了链式调用、提示词模板、记忆管理、工具调用等能力。还有 Semantic Kernel 的 Java 版本不过成熟度相对低一些。另外一些云厂商也提供了自己的 Java SDK直接对接自家的大模型服务。方案优势劣势适用场景Spring AI与 Spring 生态无缝集成抽象统一版本迭代快文档待完善Spring Boot 项目快速接入LangChain4j功能丰富链式编排能力强学习曲线较陡社区相对小复杂的 AI 工作流编排直接 HTTP 调用最灵活无框架依赖需要自己处理所有细节对可控性要求高的场景云厂商 SDK与自家服务深度集成绑定特定厂商已使用该云服务的项目选哪个没有标准答案取决于你的项目需求、团队技术栈和对可控性的要求。我的建议是如果是新项目且用 Spring Boot可以试试 Spring AI如果需要复杂的 AI 编排逻辑看看 LangChain4j如果追求极致的可控性和轻量级直接 HTTP 调用最稳妥。4. Java 开发者在 AI 时代的核心竞争力构建4.1 工程化能力才是 Java 开发者的护城河AI 应用开发到最后拼的不是谁更懂模型原理而是谁能把 AI 能力稳定、高效、安全地交付到用户手里。这恰恰是 Java 开发者的强项。我参与过一个智能客服系统的建设模型本身是算法团队用 Python 训练和部署的但整个系统的工程架构是 Java 做的。我们需要处理的问题包括如何管理多轮对话的上下文、如何做意图识别后的路由分发、如何对接工单系统和知识库、如何做灰度发布和 A/B 测试、如何监控对话质量和响应延迟。这些问题没有一个能靠调模型 API 解决全部是典型的后端工程问题。Java 开发者在这个层面的经验积累是巨大的优势。你知道怎么设计高可用的服务架构知道怎么做熔断降级知道怎么用缓存提升性能知道怎么通过日志和指标做问题排查。这些能力在 AI 应用开发中同样核心甚至比模型本身更重要。4.2 需要补哪些 AI 相关的知识短板当然光靠工程能力还不够Java 开发者确实需要补一些 AI 相关的基础知识。但不需要学到能推导反向传播的程度而是理解几个关键概念Token 是什么、上下文窗口怎么影响设计、温度参数怎么控制输出、嵌入向量怎么用于语义搜索、提示词工程的基本原则、RAG 的基本流程。这些知识足够你跟算法团队有效沟通也足够你做出合理的技术决策。我自己的学习路径是先动手调通一个模型 API理解请求和响应的结构然后做一个简单的问答应用体会提示词对输出质量的影响接着尝试用嵌入向量做语义搜索理解向量数据库的作用最后研究 RAG 的完整流程包括文档切分、向量化、检索、重排序、生成。每一步都动手写代码不追求理论深度但求理解实际效果和边界。4.3 从“写代码的”到“解决问题的”角色转变AI 时代对开发者的要求其实更高了。以前你只需要把需求翻译成代码现在你需要理解业务问题判断哪些能用 AI 解决、哪些不能用、怎么用效果最好。这需要你具备更强的业务理解能力和技术判断力。比如同样是做一个文档问答功能你可以选择用大模型直接回答也可以选择用 RAG 先检索再回答还可以选择用传统的全文搜索加规则匹配。每种方案的准确率、成本、延迟、可维护性都不一样。Java 开发者如果能把自己的工程能力跟对 AI 能力的理解结合起来就能从“写代码的”变成“解决问题的”。这个转变过程中沟通能力、架构思维、成本意识都会变得更重要。你需要能跟业务方解释为什么这个需求用 AI 做不划算需要能跟算法团队讨论模型部署的资源需求需要能跟运维团队协调 GPU 资源的分配。5. 实操用 Java 构建一个可落地的 AI 应用骨架5.1 项目结构与依赖选型说了这么多理念还是得落到代码上。我以一个典型的智能问答服务为例展示一下 Java 项目怎么搭建 AI 应用的骨架。项目用 Maven 管理依赖核心依赖包括Spring Boot 作为基础框架、OkHttp 作为 HTTP 客户端、Jackson 处理 JSON、Caffeine 做本地缓存、Micrometer 做指标采集。不引入 Spring AI 或 LangChain4j保持轻量。项目结构大概是这样的controller 层处理 HTTP 请求service 层封装业务逻辑client 层负责跟模型服务通信config 层管理配置model 层定义数据对象。这个结构跟普通的 Spring Boot 项目没有本质区别只是在 service 和 client 层多了跟 AI 相关的处理逻辑。dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdcom.squareup.okhttp3/groupId artifactIdokhttp/artifactId version4.12.0/version /dependency dependency groupIdcom.github.ben-manes.caffeine/groupId artifactIdcaffeine/artifactId version3.1.8/version /dependency /dependencies5.2 模型调用的封装与异常处理模型调用的封装是整个项目的核心。我设计了一个 ModelClient 接口定义了 chat 和 embed 两个方法。实现类用 OkHttp 发请求处理超时、重试、错误码。关键是要把模型服务的响应格式统一转换成内部的数据结构这样上层业务代码不依赖具体的模型服务商。public interface ModelClient { ChatResponse chat(ChatRequest request); EmbeddingResponse embed(EmbeddingRequest request); }异常处理这块要特别注意。模型服务可能返回各种错误认证失败、配额超限、请求格式错误、服务内部错误、超时等。我定义了一个 ModelException包含错误码和原始响应信息。在 service 层根据错误类型决定是重试、降级还是直接返回错误给用户。对于超时设置合理的超时时间很关键一般连接超时 5 秒读取超时 30 秒流式响应的话读取超时要更长。5.3 提示词模板管理与版本控制提示词是 AI 应用的核心资产之一但很多项目把提示词硬编码在 Java 代码里这是个大坑。改一个提示词就要重新编译部署而且没法做版本管理和 A/B 测试。我的做法是把提示词模板放在外部配置文件或者数据库里用模板引擎做变量替换。每个提示词有唯一的 key 和版本号可以动态切换。public class PromptTemplate { private String template; private MapString, Object variables; public String render() { String result template; for (Map.EntryString, Object entry : variables.entrySet()) { result result.replace({{ entry.getKey() }}, String.valueOf(entry.getValue())); } return result; } }提示词的版本控制也很重要。每次修改提示词都应该记录修改人、修改时间、修改原因和效果对比。我一般会在数据库里建一张 prompt_history 表每次修改都插入一条新记录线上用的是最新版本但可以随时回滚到历史版本。5.4 缓存策略与成本控制大模型调用是有成本的而且延迟通常比普通接口高。合理的缓存策略能显著降低成本、提升响应速度。我在项目里用了两级缓存本地 Caffeine 缓存和分布式缓存。对于相同的问题如果短时间内重复提问直接返回缓存结果。对于嵌入向量因为计算成本高且结果确定缓存时间可以设得更长。CacheString, String responseCache Caffeine.newBuilder() .maximumSize(10000) .expireAfterWrite(Duration.ofMinutes(30)) .recordStats() .build();成本控制还有一个重要手段是 Token 用量监控。每次调用模型后记录输入和输出的 Token 数按用户和接口维度做统计。这样能及时发现异常调用比如某个用户短时间内大量请求或者某个接口的提示词设计不合理导致 Token 消耗过高。我一般会设置日限额和月限额超过阈值就告警或者限流。6. 踩坑实录那些文档里不会写的经验教训6.1 流式响应的线程安全问题流式响应是提升用户体验的关键但处理起来比同步响应复杂得多。我踩过的一个坑是在 Spring MVC 的异步请求里处理 SSE 流式响应时多个请求共享了同一个 OkHttpClient 实例结果在高并发下出现了响应串流的问题。一个用户的响应里混入了另一个用户的内容。排查了很久才定位到是 OkHttp 的连接池和事件监听器配置问题。解决方案是给每个流式请求创建独立的 Call 对象并且确保事件监听器里的状态是请求级别的不要用共享的可变状态。另外Spring MVC 的 SseEmitter 要设置合理的超时时间并且在完成或异常时及时调用 complete 或 completeWithError否则连接会一直挂着。6.2 模型输出格式不稳定的应对大模型的输出格式有时候不稳定你要求它返回 JSON它可能给你返回一段带 Markdown 代码块的 JSON或者前后加一些解释性文字。这在解析时就会报错。我的应对策略是第一在提示词里明确要求只返回 JSON不要加任何其他内容第二解析前先做清洗去掉 Markdown 标记和前后空白第三用宽松的 JSON 解析器允许一些格式偏差第四如果解析失败做一次重试重试时在提示词里强调格式要求。public String extractJson(String raw) { String cleaned raw.trim(); if (cleaned.startsWith(json)) { cleaned cleaned.substring(7); } else if (cleaned.startsWith()) { cleaned cleaned.substring(3); } if (cleaned.endsWith()) { cleaned cleaned.substring(0, cleaned.length() - 3); } return cleaned.trim(); }6.3 超时与重试策略的平衡超时和重试的设置需要仔细权衡。超时太短正常的慢请求会被中断超时太长用户等待时间过久。重试次数太多可能加剧服务端压力重试太少偶发失败会影响成功率。我的经验是连接超时设 5 秒读取超时根据场景设 30 到 120 秒流式响应可以更长。重试只针对可恢复的错误比如 429 和 5xx重试次数不超过 2 次并且要用指数退避。还有一个容易被忽略的点重试时要考虑幂等性。如果模型调用是有副作用的比如计费重试可能导致重复计费。这种情况下要么不重试要么在服务端做幂等处理。6.4 日志脱敏与数据安全AI 应用的日志里可能包含用户的敏感信息比如对话内容、个人信息等。直接打到日志里会有数据安全风险。我的做法是在日志输出前做脱敏处理对敏感字段做掩码或者哈希。同时日志的存储和访问要有权限控制不能谁都能看。另外如果用的是外部模型服务要确认数据不会被用于训练这通常在服务条款里有说明。7. 技术选型的决策框架与长期建议7.1 根据团队规模和项目阶段做选择技术选型没有绝对的对错关键看是否匹配团队和项目的实际情况。如果是小团队快速验证想法直接用 HTTP 调用最省事不需要学习新框架。如果是中型团队做正式产品可以考虑 Spring AI 或者 LangChain4j提升开发效率。如果是大团队做平台级产品可能需要自研集成层因为对可控性和定制化的要求更高。项目阶段也很重要。MVP 阶段追求快速上线怎么快怎么来。产品化阶段要考虑可维护性和扩展性需要更规范的架构。规模化阶段要考虑成本、性能和稳定性需要更精细的优化。7.2 保持技术栈的灵活性与可替换性不管选了什么方案都要保持可替换性。核心思路是在业务代码和具体技术实现之间加一层抽象。比如定义一个 ModelService 接口业务代码只依赖这个接口具体的实现可以是 Spring AI、LangChain4j 或者直接 HTTP 调用。这样将来换方案时只需要改实现类业务代码不用动。这个原则在 AI 领域尤其重要因为技术变化太快了。今天流行的框架明天可能就被新的替代了。保持抽象层的稳定让底层实现可以灵活替换是应对变化的最好策略。7.3 对 Java 生态未来的理性判断回到最初的问题Java 还有希望吗我的判断是Java 在企业级应用开发领域的地位短期内不会被动摇而在 AI 应用开发中Java 的定位会越来越清晰——不是做模型训练和算法研究而是做 AI 能力的工程化落地。这个定位的市场空间非常大因为最终所有的 AI 能力都要变成用户可用的产品而产品化恰恰是 Java 的强项。Spring AI Alibaba 停更只是一个小插曲它提醒我们不要过度依赖某个具体的开源项目而应该关注底层能力和工程方法。Java 生态的成熟度、稳定性和人才储备是它在 AI 时代最大的底气。作为 Java 开发者与其焦虑语言的前途不如把精力放在提升自己的工程能力、补充 AI 基础知识、积累实际项目经验上。这些才是真正属于你的竞争力。我在实际项目中的体会是技术浪潮来来去去但解决问题的能力和工程思维是通用的。把 AI 当成一个新的工具和新的场景用你已有的工程能力去驾驭它而不是被它吓倒。这条路我走过虽然有不少坑但每一步都算数。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
