1. 一个框架停更引发的技术选型焦虑

前几天在技术群里看到有人转了一篇文章，标题大意是某个Java生态的AI框架停更了，底下评论区立刻炸了锅。有人说"Java做AI本来就没戏"，有人说"赶紧转Python吧"，还有人翻出几年前"Java已死"的老梗重新炒了一遍。我当时正在用Java写一个RAG检索增强生成的服务端模块，看到这些讨论，说实话心里也咯噔了一下——毕竟谁都不想把生产系统建在一个没人维护的地基上。

但冷静下来之后，我把这件事从头到尾捋了一遍，发现事情远没有标题党说的那么悲观。一个框架停更，和"Java能不能做AI"完全是两个层面的问题。前者是某个具体开源项目的生命周期问题，后者是一个语言生态在AI工程化领域的定位问题。把这两件事混为一谈，就像因为某家餐厅关门了就说"中餐没希望了"一样荒谬。

这篇文章我想聊清楚三件事：第一，一个AI框架停更到底意味着什么，它影响的是哪一层；第二，Java在AI应用开发中真正的位置在哪里，哪些场景它天然有优势，哪些场景确实不该硬上；第三，如果你正在用Java做AI相关的服务端开发，接下来该怎么调整技术栈和架构思路。不管你是刚接触AI应用开发的Java后端，还是正在做技术选型的技术负责人，希望这篇内容能帮你把焦虑转化成清晰的判断。

2. 框架停更这件事，到底动了谁的奶酪

2.1 先搞清楚停更的是什么层面的东西

很多人一听到"AI框架停更"就慌了，但其实得先看清楚这个框架在技术栈里处于什么位置。AI应用开发大致可以分成这么几层：最底层是模型训练和推理引擎，中间层是模型服务化和编排框架，最上层是应用层的业务逻辑集成。不同层的东西停更，影响完全不一样。

如果停更的是底层推理引擎，那确实比较麻烦，因为这意味着你可能要自己维护算子优化、硬件适配这些极其复杂的东西。但如果停更的是应用层的集成框架——比如某个帮你把大模型API封装成Spring Bean的库——那影响就小得多。这类框架本质上做的是"胶水"工作：把HTTP调用封装一下，把返回结果解析一下，提供几个注解让你少写点样板代码。它的核心逻辑并不复杂，你甚至可以在几天内自己实现一个简化版本。

我仔细看了一下那个停更项目的定位，它主要做的是应用层的集成和编排，包括对话管理、提示词模板、向量库对接这些。这些东西的技术含量不在于代码有多难写，而在于生态整合和持续维护。停更意味着不再有新功能、不再适配新版本的依赖、不再修复bug，但它已经实现的功能不会突然消失，你已有的系统也不会明天就崩掉。

2.2 停更的真正风险在哪里

虽然已有的功能不会消失，但停更确实带来几个实实在在的风险，这些才是你需要认真评估的。

依赖版本锁死是最直接的问题。你用的Spring Boot版本在升级，JDK版本在升级，但那个停更的框架可能只兼容到某个旧版本。时间一长，你的整个依赖树就被它拖住了，想升级其他组件就得先解决兼容性问题。我遇到过类似的情况：一个停更的SDK锁死了某个HTTP客户端的版本，导致我们没法升级到支持HTTP/2的新版本，最后只能把那个SDK的源码扒出来自己改。

安全漏洞无人修复是更隐蔽的风险。AI应用框架通常会处理外部输入——用户的消息、上传的文档、调用的外部API返回——这些都是潜在的攻击面。如果框架里存在注入漏洞或者反序列化问题，停更就意味着不会有官方补丁。你得自己盯着CVE公告，自己评估影响，自己打补丁。

社区知识断层也很要命。一个活跃的项目，你遇到问题去搜，能找到大量讨论、issue和解决方案。停更的项目，你遇到新问题可能全网都搜不到答案，只能自己啃源码。而且随着时间推移，记得这个框架的人越来越少，你能获得的帮助也越来越少。

但话说回来，这些风险都是可以管理的。依赖锁死可以通过隔离层来缓解，安全漏洞可以通过代码审计来发现，社区断层可以通过提前储备知识来应对。关键是你得知道自己面对的是什么，而不是被"停更"两个字吓到。

2.3 为什么"Java做不了AI"是个伪命题

每次有Java AI相关的项目出问题，就会有人跳出来说"Java不适合做AI"。这个说法混淆了两个完全不同的概念：AI模型研发和AI应用开发。

模型研发确实主要是Python的天下，因为PyTorch、TensorFlow这些训练框架的生态在Python里最成熟，学术界和工业界的研究人员也都在用Python。但AI应用开发是另一回事。当你把训练好的模型部署到生产环境，要处理高并发请求、要保证服务可用性、要做事务管理、要集成到现有的业务系统里——这些恰恰是Java最擅长的领域。

你想想，一个电商平台要加一个智能客服功能，它需要的是什么？需要的是能扛住双十一级别的并发量，需要的是和现有的订单系统、用户系统无缝集成，需要的是完善的监控、日志、熔断、降级机制。这些能力Java生态积累了二十年，Python在这方面差得远。模型推理可以单独部署成服务，用任何语言调用都行，但业务逻辑的编排和集成，Java仍然是首选。

所以真正的问题不是"Java能不能做AI"，而是"Java在AI技术栈里应该承担什么角色"。想清楚这个问题，框架停更这种事就不会让你慌了。

3. Java在AI应用栈里的真实位置

3.1 模型推理层：Java不是主角但也不必缺席

在模型推理这一层，Java确实不是主流选择。大多数团队会把模型部署成独立的推理服务，用Python或者C++写，然后通过HTTP或gRPC对外提供服务。这种架构下，Java作为调用方，完全不需要关心模型是怎么加载的、推理是怎么加速的。

但有些场景下，你确实可能需要在Java进程内做推理。比如边缘计算场景，设备上只有一个JVM，你不可能再塞一个Python运行时进去。或者对延迟极其敏感的场景，少一次网络调用就能省几毫秒。这时候可以考虑ONNX Runtime的Java绑定，或者一些专门为JVM优化的推理引擎。不过我得说，这条路走起来比较辛苦，工具链不如Python成熟，遇到问题参考资料也少。除非有明确的必要，否则我还是建议把推理独立出去。

3.2 应用编排层：Java的主场

这一层才是Java真正该发力地方。所谓应用编排，就是把模型能力、业务逻辑、外部工具、数据存储这些东西串起来，形成一个完整的AI应用。比如一个智能文档处理系统，它需要：接收用户上传的文档、调用OCR提取文字、调用大模型做摘要和分类、把结果存入数据库、通知用户处理完成。这一整套流程的编排，Java做起来得心应手。

Spring生态在这方面的优势太明显了。依赖注入让你可以轻松替换不同的模型提供商，AOP可以统一处理日志和监控，事务管理保证数据一致性，Spring Batch适合处理大批量任务。这些能力不是专门为AI设计的，但AI应用同样需要。你不需要一个"AI框架"来告诉你怎么做这些事，Spring本身就能做好。

我现在的做法是：把模型调用封装成一个普通的Service，用接口隔离具体实现。这样今天用这家模型，明天换那家，只需要换一个实现类。提示词模板用配置文件管理，方便调整。向量检索封装成Repository，和数据库访问一样的模式。整个架构里没有什么"AI特有"的东西，都是标准的Java企业级开发模式。

3.3 数据处理层：被低估的Java强项

AI应用离不开数据处理——清洗、转换、分块、嵌入、索引。这些工作Java其实很擅长。Apache Tika可以解析几乎所有格式的文档，Lucene/Elasticsearch是成熟的全文检索方案，各种ETL工具和批处理框架也很完善。

特别是当你的数据量上来之后，Java的批处理能力和内存管理优势就体现出来了。Python处理几百万条数据可能会遇到内存和性能瓶颈，Java在这方面有更多的调优空间。而且Java的并发工具包非常成熟，做并行数据处理比Python的multiprocessing要顺手得多。

3.4 什么时候该用Python，什么时候该用Java

说了这么多Java的好话，我也得客观一点。有些场景确实用Python更合适。

这张表不是绝对的，只是一个参考。实际选型还要考虑团队的技术栈、运维能力、招聘难度等因素。但核心思路是：让每种语言做它最擅长的事，而不是强行用一种语言解决所有问题。

4. 框架停更后的技术栈调整方案

4.1 先做影响评估，别急着换

听到框架停更的消息，第一反应不应该是"赶紧换"，而是"先看看影响有多大"。我一般会从这几个维度做评估：

使用深度：你是只用了最基础的几个功能，还是深度依赖了它的各种高级特性？如果只是用它的HTTP客户端封装，那替换成本很低。如果用了它的工作流编排、状态管理、自定义扩展点，那替换起来就麻烦了。

替代方案成熟度：市面上有没有功能对等的替代品？替代品的社区活跃度如何？迁移成本有多大？如果替代品还不如自己维护，那不如不换。

业务关键程度：这个框架支撑的是核心业务还是边缘功能？核心业务求稳，边缘功能可以激进一点。

团队技术储备：团队有没有能力自己维护一个fork？有没有精力跟进上游的安全补丁？

做完这个评估，你可能会发现：有些项目其实可以继续用，只是需要做好隔离和监控；有些项目确实该换，但可以慢慢来，不用一刀切。

4.2 隔离层设计：让框架可替换

不管最终换不换，有一个架构原则是通用的：不要让业务代码直接依赖具体的AI框架。这一层隔离做好了，换框架就是换一个实现类的事。

具体怎么做？定义一组接口，把AI能力的调用抽象出来。比如：

public interface ChatService { ChatResponse chat(ChatRequest request); Flux<ChatResponse> stream(ChatRequest request); } public interface EmbeddingService { List<float[]> embed(List<String> texts); } public interface VectorStore { void add(List<Document> documents); List<Document> search(String query, int topK); }

然后针对每个框架写一个实现类。业务代码只依赖接口，不依赖具体实现。这样今天用A框架，明天换B框架，业务代码一行不用改。

这个模式的好处不仅仅是方便换框架。它还让你可以在测试环境用Mock实现，在生产环境用真实实现；让你可以同时接入多个模型提供商，根据成本或效果动态切换；让你可以在框架出问题时快速降级到备用方案。

4.3 自研轻量级替代方案

如果找不到合适的替代框架，或者替代框架太重，自己写一个轻量级的封装其实不难。我前段时间就自己写了一个，核心代码不到五百行，覆盖了对话、嵌入、向量检索三个最常用的功能。

关键是要想清楚你需要什么。不要试图复刻一个完整的框架，只实现你真正用到的功能。比如对话功能，核心就是构造请求、发送HTTP、解析响应、处理错误这几步。用Java的HttpClient或者OkHttp，加上Jackson做JSON处理，半天就能写出一个可用的版本。

自己维护的好处是完全可控。你不需要等社区更新，不需要迁就框架的设计决策，遇到问题直接改代码。坏处是安全补丁和bug修复都得自己来，所以要做好代码审查和测试覆盖。

4.4 多框架并存的策略

有时候你不需要二选一，可以多个方案并存。比如核心业务用一个稳定的、自己维护的封装，新功能尝试用新的框架。或者不同的业务线用不同的方案，互不影响。

这种策略的关键是做好抽象和隔离。只要接口定义清晰，底层用几个框架都无所谓。而且多方案并存还有一个好处：可以对比不同框架的表现，为未来的技术选型积累数据。

5. 从零搭建一个不依赖特定框架的AI服务

5.1 项目结构设计

说了这么多理论，不如直接动手搭一个。我以一个文档问答服务为例，展示一下怎么用纯Spring Boot加少量自研代码实现一个AI应用，不依赖任何特定的AI框架。

项目结构大概是这样：

src/main/java/com/example/ai/ ├── config/ │ ├── HttpClientConfig.java │ └── ModelProperties.java ├── controller/ │ └── QaController.java ├── service/ │ ├── ChatService.java │ ├── EmbeddingService.java │ └── DocumentService.java ├── store/ │ └── InMemoryVectorStore.java └── model/ ├── ChatRequest.java ├── ChatResponse.java └── Document.java

核心思路是：用配置类管理模型参数，用Service封装模型调用，用Store管理向量数据，用Controller暴露API。每一层职责清晰，替换任何一层都不影响其他层。

5.2 模型调用的最小实现

先看模型调用这部分。我用Java 11的HttpClient来发请求，不引入额外的HTTP库。

@Service public class OpenAiChatService implements ChatService { private final HttpClient httpClient; private final ModelProperties properties; private final ObjectMapper objectMapper; public OpenAiChatService(ModelProperties properties, ObjectMapper objectMapper) { this.properties = properties; this.objectMapper = objectMapper; this.httpClient = HttpClient.newBuilder() .connectTimeout(Duration.ofSeconds(10)) .build(); } @Override public ChatResponse chat(ChatRequest request) { var body = Map.of( "model", properties.getModel(), "messages", request.getMessages(), "temperature", request.getTemperature() ); var httpRequest = HttpRequest.newBuilder() .uri(URI.create(properties.getBaseUrl() + "/chat/completions")) .header("Content-Type", "application/json") .header("Authorization", "Bearer " + properties.getApiKey()) .POST(HttpRequest.BodyPublishers.ofString( objectMapper.writeValueAsString(body))) .build(); var response = httpClient.send(httpRequest, HttpResponse.BodyHandlers.ofString()); return objectMapper.readValue(response.body(), ChatResponse.class); } }

这段代码没什么魔法，就是构造JSON、发HTTP请求、解析响应。你可以很容易地加上重试、超时、熔断这些逻辑。而且因为不依赖任何框架，升级JDK或者Spring Boot都不会有兼容性问题。

5.3 向量存储与检索的简化方案

向量存储这块，如果数据量不大（比如几万条以内），完全可以用内存加简单的余弦相似度计算来实现。不需要上专业的向量数据库。

@Component public class InMemoryVectorStore implements VectorStore { private final List<Document> documents = new CopyOnWriteArrayList<>(); @Override public void add(List<Document> docs) { documents.addAll(docs); } @Override public List<Document> search(float[] queryVector, int topK) { return documents.stream() .map(doc -> Map.entry(doc, cosineSimilarity(queryVector, doc.getVector()))) .sorted(Map.Entry.<Document, Double>comparingByValue().reversed()) .limit(topK) .map(Map.Entry::getKey) .collect(Collectors.toList()); } private double cosineSimilarity(float[] a, float[] b) { double dot = 0, normA = 0, normB = 0; for (int i = 0; i < a.length; i++) { dot += a[i] * b[i]; normA += a[i] * a[i]; normB += b[i] * b[i]; } return dot / (Math.sqrt(normA) * Math.sqrt(normB)); } }

这个实现很粗糙，但对于原型验证和小规模应用足够了。等数据量上来了，再换成Elasticsearch的向量检索或者专业的向量数据库，接口不用变。

5.4 提示词模板的管理

提示词模板我建议放在配置文件里，而不是硬编码在Java代码里。这样调整提示词不需要重新编译，也方便做A/B测试。

prompts: qa: system: | 你是一个知识助手，根据提供的上下文回答问题。 如果上下文中没有相关信息，请如实告知。 user: | 上下文： {context} 问题：{question}

然后用Spring的@ConfigurationProperties注入，用简单的字符串替换填充变量。不需要引入模板引擎，Java自带的String.format或者MessageFormat就够了。

6. 实操中踩过的坑和总结的经验

6.1 流式响应的处理比想象中麻烦

如果你要做打字机效果的流式输出，会发现事情没那么简单。SSE（Server-Sent Events）的解析需要处理分块传输、不完整的JSON、连接中断重连等各种情况。我一开始自己写解析逻辑，踩了不少坑：有时候一个JSON对象被拆成两个TCP包，有时候服务端会发送空行作为心跳，有时候网络抖动导致连接断开但客户端不知道。

后来我的做法是用成熟的HTTP客户端库（比如OkHttp的SSE支持，或者Spring WebFlux的WebClient），它们已经处理好了这些边界情况。如果非要自己实现，一定要做好缓冲和状态管理，不要假设每次读取都能拿到完整的消息。

6.2 超时和重试策略需要仔细设计

模型调用通常比较慢，几秒到几十秒都正常。超时设太短会导致大量请求失败，设太长会拖垮线程池。我的经验是：连接超时设5秒，读取超时设60秒，根据实际模型响应时间调整。

重试要特别小心。模型调用不是幂等的——同样的请求可能返回不同的结果，而且重试会消耗额外的token。我的策略是：只对网络错误和5xx错误重试，4xx错误直接返回；重试次数不超过2次；重试之间加指数退避。

还有一个容易被忽略的点：流式请求的重试很麻烦，因为部分响应可能已经发送给客户端了。这种情况我一般不做自动重试，而是让客户端决定是否重新发起请求。

6.3 成本控制要从架构层面考虑

用大模型API是要花钱的，而且很容易超支。我见过一个团队因为没做限制，一个月烧掉了几万块。控制成本要从几个层面入手：

缓存是最有效的手段。相同的请求直接返回缓存结果，能省下大量重复调用。对于问答场景，可以对问题进行归一化处理后做缓存。

限流是必须的。按用户、按接口、按时间段设置调用上限，防止异常流量导致费用失控。

降级策略也很重要。当预算快用完时，自动切换到更便宜的模型，或者限制单次请求的token数量。

监控不能少。实时跟踪token消耗和费用，设置告警阈值，发现异常及时处理。

6.4 测试策略要覆盖模型的不确定性

AI应用的测试和传统应用很不一样，因为模型的输出是不确定的。同样的输入，两次调用可能得到不同的结果。这给自动化测试带来了挑战。

我的做法是分两层测试。第一层是单元测试，用Mock的模型响应，验证业务逻辑的正确性。第二层是集成测试，调用真实的模型，但只验证输出的格式和关键特征，不验证具体内容。比如验证返回的JSON结构正确、包含必要的字段、长度在合理范围内，但不检查具体说了什么。

另外，维护一组"黄金测试用例"很有必要。这些用例覆盖了常见的场景和边界情况，每次修改提示词或者换模型后都跑一遍，人工评估输出质量。虽然不能完全自动化，但能及时发现明显的退化。

6.5 日志和可观测性要提前规划

AI应用的调试比传统应用困难得多。用户说"回答不对"，你需要知道：当时用的什么提示词？检索到了哪些文档？模型的原始返回是什么？这些信息如果没提前记录，事后根本查不到。

我的做法是在关键节点打结构化日志：请求进入时记录用户输入和参数，检索完成后记录命中的文档ID和相似度分数，模型返回后记录原始响应和token消耗，最终响应前记录处理耗时。这些日志用JSON格式输出，方便后续分析和检索。

敏感信息要脱敏。用户的原始输入可能包含个人信息，日志里要做好掩码处理。API密钥绝对不能打进日志。

6.6 关于框架选型的个人体会

折腾了这么多，我对框架选型的态度是：用框架但要保持可替换性，能自己写的就别引入重依赖。

框架的价值在于帮你快速起步，但代价是增加了抽象层和依赖。如果一个框架只是帮你省了几十行样板代码，那引入它的收益可能抵不过维护成本。反过来，如果一个框架提供了你很难自己实现的能力（比如复杂的编排引擎、完善的监控体系），那引入它是值得的。

但不管用什么框架，隔离层一定要做。这不仅仅是为了应对框架停更，更是为了保持架构的灵活性。技术变化太快，今天流行的框架明天可能就过时了，唯一不变的是你的业务逻辑和接口定义。

回到最初的问题：某个框架停更了，Java还有希望吗？我的答案是：Java在AI应用开发领域的地位不会因为某个框架的停更而动摇。真正重要的是你对业务的理解、对架构的把控、对技术本质的洞察。框架只是工具，工具会换，但能力不会。把隔离层做好，把核心逻辑掌握在自己手里，任何框架的变动都不会让你措手不及。