当前位置：首页 > news >正文

Java做AI应用开发：RAG与Agent的生产级实践

news 2026/6/24 11:29:13

1. 开篇：AI应用时代，Java还能打吗？——一个十年Java老兵的实测手记

我从2013年开始写Java，那会儿Spring 3.2刚稳定，Maven还是“高级配置”，IDEA还没现在这么智能。十年间，我带过团队做过金融核心系统、做过千万级用户的小程序后端、也搭过高校科研平台的微服务底座。去年底开始密集接触LangChain4j、RAG和Agent开发，不是为了赶时髦，是客户真把需求甩到我桌上了：大学英语教学智能体要嵌入语法纠错+个性化习题生成；某知识产权服务平台要求在商标申请流程中实时比对近似图形与文字库；还有个省级科研管理平台，得让研究员用自然语言查“近三年国家自然科学基金面上项目中，涉及‘钙钛矿太阳能电池’且结题评价为‘优秀’的课题负责人名单”。这些都不是Demo，是签了合同、要上线、要压测、要运维的生产系统。

所以当看到标题里那个问号——“Java还能打吗？”——我第一反应不是查文档，而是打开JDK 21、Spring Boot 3.3、LangChain4j 0.32.0，拉起一个本地Ollama服务跑Qwen2.5-7B，连上PostgreSQL向量库，从零搭了个带检索增强+工具调用+多跳推理的英语语法教学Agent。整个过程没换语言，没切技术栈，连IDE都没重启。Java没死，它只是换了一身更厚实的铠甲，站在了AI应用落地的第一线。这不是理论推演，是我在客户现场踩着坑、调着GC、改着线程池参数、盯着Prometheus监控面板写出来的结论。如果你正纠结要不要放弃Java去学Python做AI，或者正在面试中被问到“Java怎么对接大模型”，又或者已经接到类似需求但不知道从哪下手——这篇就是为你写的。它不讲虚的“Java生态强大”，只说真实场景下，Java怎么扛住RAG的高并发向量检索、怎么让Agent在Spring事务里安全调用外部API、怎么把LangChain4j的StreamResponse塞进WebSocket推给前端、怎么用Java原生能力解决Python生态里常见的内存泄漏和冷启动问题。下面所有内容，都来自我过去8个月在6个真实AI应用项目中的代码、日志和会议纪要。

2. Java在AI应用层的真实定位：不是替代者，而是承重墙

2.1 别再被“Python是AI语言”的幻觉带偏了

网上太多声音说“AI=Python”，这在模型训练和算法研究阶段确实成立。但一旦进入应用层——也就是用户真正用上的产品——情况就完全变了。我拆解过我们交付的6个AI项目，它们的架构图里，Python通常只出现在两个位置：一是模型服务端（用FastAPI封装Llama.cpp或vLLM），二是离线数据处理管道（用Pandas清洗语料、用SentenceTransformers生成Embedding）。而整个应用的主干：用户认证、权限控制、业务流程编排、数据库事务、消息队列消费、文件存储、审计日志、灰度发布、熔断降级——全是Java写的。为什么？因为这些模块对稳定性、可维护性、可观测性、企业级集成能力的要求，远高于对“写几行向量化代码”的要求。

举个具体例子：某高校英语教学智能体，前端是小程序，后端是Spring Boot。学生提问“这个句子为什么用过去完成时？”，系统要：① 先查知识库找相关语法规则（RAG）；② 再调用语法分析工具解析句子结构；③ 然后结合学生历史错题数据生成解释；④ 最后把结果推送到小程序。这四个步骤里，只有第①步的向量检索和第②步的语法分析可能用到Python模型服务。但第③步的“结合历史数据”需要读取MySQL里的学生行为表，第④步的推送要走Redis Pub/Sub + WebSocket，整个链路还要保证事务一致性（比如学生答题记录和AI反馈必须同时落库）。这些，Java的Spring Data JPA、Spring Integration、Reactor响应式编程、Micrometer指标埋点，是Python生态里很难找到同等成熟度的替代方案的。Python的FastAPI再快，也扛不住每秒3000次带事务的数据库写入；它的asyncio再灵活，也难做到Java里ThreadPoolTaskExecutor对线程生命周期的精细控制。

提示：很多开发者混淆了“AI模型开发”和“AI应用开发”。前者是算法工程师的战场，后者是后端工程师的主阵地。Java的优势不在模型层，而在如何让模型安全、可靠、可控、可审计地服务于业务。

2.2 LangChain4j不是LangChain的Java版，而是为Java世界重新设计的AI胶水

LangChain4j这个名字容易让人误解它是LangChain的简单移植。实际上，它从第一天起就带着明确的Java基因：强类型、不可变对象、Reactive Streams原生支持、与Spring Boot深度集成、默认使用Jackson而非Pydantic做序列化。我对比过LangChain4j 0.32.0和LangChain Python 0.3.7的源码，发现几个关键差异：

工具调用（Tool Calling）设计哲学不同：Python版LangChain的tool是函数，靠装饰器注册，运行时动态反射；LangChain4j的tool是接口实现类，必须继承StructuredTool或JsonSchemaTool，在Spring容器里作为Bean管理。这意味着Java版天然支持依赖注入、AOP切面（比如自动加日志、加熔断）、事务传播。我给一个商标查询tool加了@Transactional(readOnly = true)，它就能自动复用当前HTTP请求的数据库连接，避免额外开连接——这种细节，Python版得自己写上下文管理器。
流式响应（Streaming）实现更贴合Java生态：Python版用yield生成器，前端接收的是分块文本；LangChain4j用Flux<ChatResponse>，底层是Project Reactor，能无缝接入Spring WebFlux的SseEmitter或ResponseBodyEmitter。我们有个实时翻译Agent，前端用EventSource监听，Java后端一行代码return ResponseEntity.ok().body(chatModel.stream(prompt))就搞定，不用手动拼接data:前缀、处理换行符。而Python版得自己写async def stream_response()，还要处理ASGI服务器的兼容性问题。
RAG检索器（Retriever）的扩展点更清晰：LangChain4j把Retriever定义为函数式接口Function<Query, Flux<Document>>，意味着你可以用任何Java方式实现它：可以是调用OpenSearch的SearchRequest，可以是查PostgreSQL的pgvector扩展，甚至可以是读取本地Elasticsearch集群的RestHighLevelClient。它不强制你用某个特定向量库，而是让你用最熟悉的Java客户端。我们有个项目因客户防火墙限制不能连外网，就把Embedding模型换成本地ONNX Runtime加载的MiniLM，检索器直接用JDBC查embedding_vector字段，全程没动LangChain4j的API。

2.3 RAG和Agent不是新概念，而是Java老司机的新赛道

RAG（检索增强生成）听起来很新，但拆开看：检索是Java做了二十年的事（Lucene、Elasticsearch、Solr），增强是规则引擎和策略模式的变种（Drools、Easy Rules），生成才是新部分。Agent（智能体）的核心是“规划-执行-反思”循环，这不就是状态机（State Machine）+ 命令模式（Command Pattern）+ 观察者模式（Observer Pattern）的经典组合吗？我带团队重构一个科研问答Agent时，把整个Agent生命周期画成UML状态图：IDLE → PLANNING → EXECUTING → REFLECTING → IDLE，每个状态转换都对应一个Spring@EventListener监听特定事件，执行逻辑封装在Command子类里。这样做的好处是：调试时直接看日志里打印的状态流转，压测时能精准定位是PLANNING阶段CPU高还是EXECUTING阶段IO阻塞。

注意：别被“Agent框架”这个词吓住。很多所谓Agent框架，本质就是帮你把if-else写得更优雅。LangChain4j的AgentExecutor，核心就三行伪代码：plan = planner.execute(input); actions = plan.getActions(); for(action : actions) { result = action.execute(); }。剩下的，都是Java工程师天天打交道的东西：怎么序列化plan、怎么超时控制action、怎么聚合result。你不需要学新范式，只需要把老技能用在新场景。

3. 实战拆解：用Java从零搭建一个生产级英语语法教学Agent

3.1 项目目标与技术选型依据

我们要做的不是一个玩具Demo，而是一个能嵌入大学教务系统的生产组件。核心需求有四条：

实时性：学生提问后2秒内返回首字节（TTFB < 2s）
准确性：语法解释必须引用权威教材原文，不能幻觉
可追溯：每次回答必须附带引用的知识库片段和置信度
可扩展：后续要接入口语评测、作文批改等新能力

基于这四条，我们定了技术栈：

模型层：Ollama本地部署Qwen2.5-7B（中文强、语法理解好、显存占用低）
向量库：PostgreSQL + pgvector（客户已有PG集群，免运维，ACID保障）
应用框架：Spring Boot 3.3 + LangChain4j 0.32.0（官方Spring AI已合并进LangChain4j，无需额外引包）
前端通信：WebSocket（比HTTP长连接更省资源，适合流式响应）
监控告警：Micrometer + Prometheus + Grafana（客户统一监控平台）

为什么不用Elasticsearch？因为ES的向量检索精度不如pgvector，且客户PG集群已开启pgvector扩展，DBA明确表示“不接受新增中间件”。为什么不用Milvus？同理，运维成本太高，一个AI功能不值得单独上一套分布式向量库。这就是Java工程师的务实：不追新，只选最稳、最省、最易交接的方案。

3.2 知识库构建：用Java把教材PDF变成可检索的向量

第一步不是写代码，是准备数据。我们拿到的是《新概念英语》第三册PDF，共24课，每课含课文、语法讲解、练习题。传统做法是用Python脚本pdfplumber提取文本，再用langchain.text_splitter切分。但我们用Java做了三件事：

第一，自定义PDF解析器，保留结构信息
用Apache PDFBox写了个StructuredPdfParser，它不只提取纯文本，还记录每段文字的字体大小、是否加粗、所在页码、前后空行数。这样，我们能识别出“语法讲解”通常用14号加粗字体，“例句”用12号常规字体，“练习题”用10号斜体。代码核心逻辑：

public class StructuredPdfParser { public List<StructuredText> parse(PDDocument doc) { List<StructuredText> results = new ArrayList<>(); for (PDPage page : doc.getPages()) { // 获取页面文本及其样式元数据 TextPosition textPos = ...; // PDFBox API获取坐标和字体 if (textPos.getFont().getName().contains("Bold") && textPos.getFontSize() > 13) { results.add(new StructuredText(textPos.getUnicode(), "GRAMMAR")); } } return results; } }

这样切分出的chunk，每个都带type标签（"GRAMMAR"/"EXAMPLE"/"EXERCISE"），后续RAG检索时可加权重。

第二，用Java调用SentenceTransformers ONNX模型生成Embedding
没用Python的transformers库，而是用ONNX Runtime Java API加载预训练的all-MiniLM-L6-v2模型。好处是：模型加载一次，复用所有请求；内存可控（ONNX Runtime可设MemoryInfo）；无Python进程通信开销。我们封装了OnnxEmbeddingService：

public class OnnxEmbeddingService { private OrtEnvironment environment; private OrtSession session; public OnnxEmbeddingService(String modelPath) { this.environment = OrtEnvironment.getEnvironment(); this.session = environment.createSession(modelPath, new OrtSession.SessionOptions()); } public float[] embed(String text) { // 输入预处理：tokenize -> pad -> toTensor // 模型推理：session.run(...) // 输出后处理：取[CLS]向量 return outputTensor.getFloatBuffer().array(); } }

实测单次Embedding耗时120ms（RTX 4090），比Python调用快18%，且JVM堆内存增长稳定在200MB内。

第三，向量入库时用JDBC Batch Insert，避免OOM
pgvector的vector类型在Java里对应PGobject，我们批量插入时用PreparedStatement.setObject(i, pgObject)。关键技巧：每1000条commit一次，且PGobject创建后立即pgObject.setValue(null)释放引用。否则JVM GC跟不上，OutOfMemoryError: Java heap space必现。这是我们在压测时踩的第一个大坑——初始版本想一口吃成胖子，batch size设5000，结果JVM直接挂掉。

3.3 RAG检索器实现：不只是查向量，更是查业务规则

LangChain4j的Retriever接口很简单，但要让它在生产环境扛住压力，得加三层过滤：

第一层：业务规则过滤（Pre-filtering）
学生问“过去完成时”，我们不查全库，而是先根据问题关键词匹配knowledge_type字段。用JPA Criteria API写：

public List<Document> retrieve(Query query) { String keyword = extractKeyword(query.text()); // 用HanLP分词 if ("past_perfect".equals(keyword)) { // 只查type='GRAMMAR'且tag包含'past_perfect'的文档 return jpaRepo.findByTypeAndTag("GRAMMAR", "past_perfect"); } return jpaRepo.findAll(); // 默认查全库 }

这步把候选集从10万条降到200条，向量检索快了500倍。

第二层：向量相似度检索（Vector Search）
用pgvector的<->操作符，SQL如下：

SELECT id, content, embedding <-> $1 AS distance FROM knowledge_base WHERE type = 'GRAMMAR' AND tag @> ARRAY['past_perfect'] ORDER BY distance ASC LIMIT 5;

注意：$1是传入的查询向量，distance越小越相似。我们给embedding字段建了ivfflat索引（CREATE INDEX ON knowledge_base USING ivfflat (embedding vector_cosine_ops) WITH (lists = 100);），实测10万条数据下P95检索延迟<80ms。

第三层：重排序（Re-ranking）
pgvector的余弦相似度只是粗排，我们用Java实现一个轻量级重排序器：对召回的5个文档，计算其content与问题query.text()的BM25分数（用Lucene的DefaultSimilarity），再与向量距离加权平均。代码就20行，却把准确率从72%提升到89%。这说明：RAG不是“扔给向量库就完事”，Java的老本事——文本相似度计算——依然值钱。

3.4 Agent执行器：把“规划-执行”变成可监控的Spring Bean

我们的Agent不是用LangChain4j的DefaultAgentExecutor，而是自己写了GrammarAgentExecutor，它实现了Function<String, Flux<ChatResponse>>，核心逻辑：

@Component public class GrammarAgentExecutor implements Function<String, Flux<ChatResponse>> { @Override public Flux<ChatResponse> apply(String input) { // 1. 规划：调用LLM生成执行计划（JSON格式） String planJson = planner.invoke(input); // 调用Qwen2.5 // 2. 解析计划，转成Action列表 List<Action> actions = parsePlan(planJson); // 3. 执行每个Action，流式返回结果 return Flux.fromIterable(actions) .concatMap(action -> executeAction(action) .onErrorResume(e -> Flux.just( ChatResponse.builder() .content("执行失败：" + e.getMessage()) .build() )) ); } private Mono<ChatResponse> executeAction(Action action) { switch (action.getType()) { case "RETRIEVE_GRAMMAR": return retriever.retrieve(action.getQuery()) .map(doc -> buildResponse(doc)); case "PARSE_SENTENCE": return syntaxParser.parse(action.getContent()) .map(result -> buildResponse(result)); default: return Mono.just(ChatResponse.builder() .content("不支持的操作类型：" + action.getType()) .build()); } } }

关键设计点：

每个Action都是独立的Mono：失败不影响后续Action，符合“容错”原则
concatMap保证顺序：规划好的执行顺序不会乱，这对语法教学很重要（必须先查规则，再解析句子）
错误兜底：onErrorResume统一处理异常，返回友好提示，而不是让整个流中断

我们给这个Bean加了Micrometer计时器：

@Timed(value = "agent.execution.time", histogram = true) public Flux<ChatResponse> apply(String input) { ... }

Grafana里就能看到agent_execution_time_seconds_bucket直方图，P95延迟超过1.5秒就告警——这才是生产级的可观测性。

4. 高频问题与避坑指南：那些文档里不会写的Java AI实战经验

4.1 JVM调优：别让GC成为AI应用的隐形杀手

AI应用最大的内存敌人不是模型，而是字符串和临时对象。LangChain4j的ChatResponse、Document、Message都是不可变对象，每次流式响应都要新建几十个。我们最初用默认JVM参数（-Xms512m -Xmx2g），压测到QPS 200时，GC频率飙升到每秒3次，G1 Young Generation停顿达400ms。解决方案是三步走：

第一步：增大年轻代，启用G1垃圾回收器

# JVM启动参数 -XX:+UseG1GC \ -XX:MaxGCPauseMillis=200 \ -Xms4g -Xmx4g \ -XX:NewRatio=1 \ # 年轻代占堆一半 -XX:G1HeapRegionSize=2M \ -XX:+UnlockExperimentalVMOptions \ -XX:+UseStringDeduplication

-XX:+UseStringDeduplication是关键，它让相同内容的字符串只存一份，减少堆内存占用。实测后GC频率降到每分钟1次。

第二步：用StringBuilder替代字符串拼接
LangChain4j的StreamingResponseHandler默认用String累加流式文本，我们重写为：

public class StringBuilderResponseHandler implements StreamingResponseHandler { private final StringBuilder sb = new StringBuilder(); @Override public void onNext(String token) { sb.append(token); // 不创建新String对象 } @Override public String getResponse() { return sb.toString(); // 只在最后创建一次 } }

这招让单次响应的临时对象减少70%。

第三步：向量缓存用Caffeine，别用ConcurrentHashMap
我们把高频查询的Embedding结果缓存起来，初始用ConcurrentHashMap<String, float[]>，结果内存暴涨。换成Caffeine：

Cache<String, float[]> embeddingCache = Caffeine.newBuilder() .maximumSize(10000) .expireAfterWrite(10, TimeUnit.MINUTES) .recordStats() .build();

recordStats()开启统计，我们发现缓存命中率92%，但eviction（驱逐）次数过高。于是加了refreshAfterWrite(5, TimeUnit.MINUTES)，让热点数据自动刷新，驱逐率降为0。

实操心得：AI应用的JVM调优，核心是“控住字符串和数组”。别迷信大堆内存，要像外科医生一样精准切除GC瓶颈。我们最终参数：-Xms4g -Xmx4g -XX:+UseG1GC -XX:MaxGCPauseMillis=200 -XX:+UseStringDeduplication，P95延迟稳定在1.2秒内。

4.2 Spring Boot集成：让LangChain4j真正融入企业级架构

LangChain4j官方文档讲怎么用，但没讲怎么在Spring Boot里安全地用。我们总结了三个必须做的集成点：

第一，ChatModel Bean必须是Prototype作用域
因为ChatModel内部有状态（如streaming的buffer），如果设为Singleton，多线程并发会互相污染。正确写法：

@Bean @Scope(ConfigurableBeanFactory.SCOPE_PROTOTYPE) public ChatModel chatModel() { return OllamaChatModel.builder() .baseUrl("http://localhost:11434") .modelName("qwen2.5:7b") .timeout(Duration.ofSeconds(30)) .build(); }

每次@Autowired都会新建实例，互不干扰。

第二，Retriever必须支持事务传播
我们的PostgreSqlRetriever要读数据库，必须能加入当前事务。所以它不能是普通Bean，而要实现TransactionAware接口，并在@Transactional方法里调用：

@Service public class GrammarService { @Transactional(readOnly = true) // 关键！声明事务 public Flux<ChatResponse> handleQuestion(String question) { // retriever的JDBC查询会复用此事务的Connection return agentExecutor.apply(question); } }

第三，Metrics必须暴露为Prometheus格式
LangChain4j自带Micrometer支持，但默认不暴露。我们在application.yml加：

management: endpoints: web: exposure: include: health,info,metrics,prometheus endpoint: prometheus: show-details: always

然后在Grafana里加面板，监控langchain4j_chat_model_requests_total和langchain4j_retriever_retrieve_seconds_count，就能看到哪个环节拖慢了整体性能。

4.3 生产部署：Java的“稳”如何对抗AI的“不可控”

AI模型有幻觉、有延迟、有失败，Java的使命是把它包装成可靠的服务。我们用了三道防线：

防线一：超时熔断（Hystrix + Resilience4j）
给所有外部调用加熔断：

@CircuitBreaker(name = "ollama", fallbackMethod = "fallbackChat") @TimeLimiter(fallbackMethod = "fallbackChat", timeLimit = "5s") public Mono<ChatResponse> callOllama(String prompt) { return chatModel.generate(prompt); } private Mono<ChatResponse> fallbackChat(String prompt, Throwable t) { return Mono.just(ChatResponse.builder() .content("AI服务暂时繁忙，请稍后再试") .build()); }

Resilience4j的CircuitBreaker在连续5次失败后自动熔断，30秒后半开，避免雪崩。

防线二：降级策略（Fallback Strategy）
当Ollama不可用时，我们不是返回错误，而是降级到规则引擎：

public class FallbackGrammarResolver { public String resolve(String question) { if (question.contains("过去完成时")) { return "过去完成时表示在过去某一时间或动作之前已经发生或完成了的动作..."; } // 用Drools规则匹配更多语法点 return "请咨询人工教师"; } }

这招让服务可用性从99.2%提升到99.99%。

防线三：灰度发布（Canary Release）
新模型上线不全量，而是用Spring Cloud Gateway按Header灰度：

spring: cloud: gateway: routes: - id: ai-service uri: lb://ai-service predicates: - Header=X-Canary, true filters: - SetPath=/canary/{segment}

先让10%内部用户用新Qwen2.5模型，监控response_length和hallucination_rate指标，达标后再全量。这才是Java系工程师该有的上线节奏——不冒进，靠数据说话。

5. Java AI开发者的成长路径：从“能用”到“精通”的三阶跃迁

5.1 第一阶：掌握LangChain4j核心API，写出可运行的RAG

这是入门门槛。你需要能独立完成：

用OllamaChatModel调通本地大模型
用PostgreSqlRetriever连上向量库并检索
用StructuredTool封装一个业务工具（如查学生错题）
把三者串成AgentExecutor，流式返回结果

推荐学习路径：官方GitHub的langchain4j-examples仓库，重点看rag和tools模块。不要一上来就啃源码，先跑通PostgreSqlRetrieverExample.java，再改造成自己的业务。我带新人时，要求他们三天内用公司教材PDF搭出一个能回答“什么是虚拟语气”的RAG服务，能跑通就算过关。

5.2 第二阶：深入JVM与Spring原理，解决生产级问题

跨过Demo后，你会遇到真实世界的泥潭：

为什么QPS上不去？是CPU瓶颈还是GC瓶颈？
为什么同样的Prompt，有时快有时慢？是模型服务抖动还是网络问题？
为什么线上日志里一堆OutOfMemoryError，但本地压测没问题？

这时要补两门课：

JVM调优实战：推荐《Java性能权威指南》，重点看GC日志分析、内存泄漏排查、JFR（Java Flight Recorder）使用。我们用JFR录了10分钟压测，发现80%的CPU时间花在String.substring()上，这才意识到要重写文本截断逻辑。
Spring Boot响应式编程：Flux和Mono不是银弹，要用对地方。比如concatMap保序，flatMap并发，switchIfEmpty兜底。我们有个需求是“查知识库+查错题库+查教材库”，三个检索必须并发，就用Flux.merge(retriever1, retriever2, retriever3)，比串行快3倍。

5.3 第三阶：构建AI工程化能力，成为团队技术支柱

最高阶不是写代码，而是建体系：

AI可观测性体系：定义关键指标（llm_latency_p95,retriever_recall_rate,tool_failure_rate），用Micrometer埋点，Grafana看板，Prometheus告警。
AI模型治理流程：建立模型版本管理（用Git LFS存ONNX模型）、AB测试框架（同一请求发给两个模型比结果）、幻觉检测规则（用正则匹配“可能”、“大概”、“我不确定”等弱断言词）。
AI安全防护：输入过滤（防Prompt注入）、输出审核（用规则引擎过滤敏感词）、权限隔离（不同学校的数据用tenant_id物理隔离）。

我们团队现在有个“AI工程规范V1.2”，里面明确规定：所有Agent必须实现AuditLoggable接口，每次调用自动记录input,plan,actions,output,cost_tokens到审计表；所有RAG检索必须返回confidence_score，低于0.6的自动触发人工审核。这才是Java工程师该有的格局——不只让AI跑起来，更要让它跑得稳、跑得明、跑得安。

最后分享一个小技巧：当你被问到“Java在AI时代还有没有前途”，别急着辩解。打开你的IDE，展示一段代码——比如用Caffeine缓存Embedding的5行配置，或者用Resilience4j熔断Ollama调用的3行注解。然后说：“看，这就是Java的AI答案：不炫技，只解决问题。” 这比任何理论都硬核。

查看全文

http://www.jsqmd.com/news/1072405/