做 Java 的都知道这两年 AI 的势头已经没法忽视了。但很多 Java 开发者心里其实有个疑惑AI 不是 Python 的天下吗Java 在这个浪潮里到底能干什么答案是能干的远比你想的多。别的不说绝大多数企业的业务系统、API 网关、用户体系、权限管理、数据持久化跑的都是 Java。AI 要真正落地到产品里跟业务结合十有八九要跟 Java 服务打交道。这篇文章我从框架选型讲到实战落地把 Java AI 技术栈这条线的来龙去脉理一遍。不管你是刚接触 AI 的 Java 新人还是已经在做全栈、微服务的同学都能从这里找到一条清晰的上手路径。先说清楚一个基本事实Java 在 AI 领域的位置主要是“应用层”和“服务层”。底层的大模型训练、复杂的深度学习实验Python 生态确实更占优势。但大模型训练完之后要对外提供服务要对接业务要处理高并发、事务、权限这就是 Java 的主场了。所以现实中的主流做法是Python 负责训练和推理Java 负责把模型能力包装成稳定、可用的企业级服务。近两年随着大语言模型LLM的普及Java 生态也长出了一套完整的 AI 工具链从调用大模型 API 到编排 Agent从向量检索到模型推理你能想到的环节都有对应的框架。这套技术栈我把它拆成两层来看偏业务接入的“智能应用层”和偏底层能力的“模型集成层”。智能应用层干的事情是把大模型的能力当成一种服务来调用比如聊天机器人、知识库问答、文档分析、代码生成助手。这一层的主力框架是 Spring AI它对标的是 Python 那边的 LangChain提供了标准化的接口来对接 OpenAI、通义千问、文心一言、Ollama 本地模型等。另一个值得关注的是 LangChain4j它是 LangChain 的 Java 移植版设计上更贴近原版社区也很活跃。如果你做的是企业级项目大概率会用到若依这类快速开发框架来搭底座再把 AI 能力集成进去。没错现在“若依 AI”已经成了很多中小企业做内部工具的首选组合。模型集成层要解决的是 Java 和 Python 生态的互通问题。最常见的手段是“把模型封装成独立的推理服务”比如用 FastAPI 把 PyTorch 模型包成 HTTP 接口Java 这边用 WebClient 或者 OkHttp 去调用。这种方法架构清晰、耦合度低也是我目前最推荐的生产方案。如果追求更极致的性能可以走 ONNX Runtime Java 或者 DJLDeep Java Library直接进程内推理省掉网络开销但调试成本会高一些。这次的内容不做空中楼阁的科普会直接落地到技术选型和代码层面重点讲清楚不同场景该用什么框架、为什么这么选、上手时有哪些必须知道的细节。特别是网上那些零散教程里不太会讲清楚的东西——类库版本兼容性、流式输出的处理、高并发下怎么防止大模型接口把连接池打爆这些我尽量一次说透。1. 技术栈全景图先看清整体再选路线1.1 按业务场景划分的主干技术选型我一直觉得学习一个技术栈最忌讳的就是逮着某个框架从入门到放弃地学而是应该先建立一张“地图”知道每个环节解决什么问题。对 Java AI 技术栈来说这张地图由六个核心环节组成。第一是业务底座。绝大多数 AI 应用不是空中楼阁它背后需要用户体系、权限控制、菜单管理、操作日志、数据字典这些通用能力。这块不用重复造轮子直接用 Spring Boot 若依框架这类成熟脚手架起步。若依在国内企业级项目里覆盖率很高前端 Vue、后端 Spring Boot代码生成器一键生成 CRUD能把搭项目的时间从一星期压缩到一晚上。第二是模型接入层。这是 Java AI 应用的关键一环。当前阶段真正自己训练大模型的公司是极少数绝大多数场景是调用现成大模型的 API。Spring AI 在 2024 年推出后已经成了 Java 接入 LLM 的事实标准它把 OpenAI、通义、文心等厂商的 API 做了统一抽象你换模型厂商时业务代码几乎不用改。如果你想跟 LangChain 生态保持同步LangChain4j 也是很好的选择。第三是知识库与向量检索。AI 应用里很大一块需求是“私有知识库问答”——把公司文档、产品手册导入系统让大模型基于这些材料回答用户问题。这就要求把文档切片、向量化存到向量数据库如 Chroma、Milvus、pgvector查询时做相似度检索。Java 这边 Spring AI 已经内置了向量存储的抽象切换不同的向量数据库只需要改配置。第四是 Agent 编排层。稍微进阶一点的场景——让 AI 自主调用工具、查询数据库、操作第三方系统——就需要 Agent 框架。这里分了两派一派是直接用 Spring AI 的 Tool 注解给模型挂工具做法简单直接另一派是上 Agent 框架比如 LangChain4j 里的 AiServices 配合 Memory 做复杂对话管理。选型的核心依据是“你需不需要 AI 连续多轮地做决策”。第五是模型部署与推理层。如果业务需要私有化部署模型数据不能出内网那就要考虑推理服务怎么做。主流方案是 Python 侧用 FastAPI 包一层模型服务Java 侧通过 HTTP 调用。做 C 端产品追求低延迟的话再考虑 ONNX Runtime 直接进程内推理。第六是工程化设施。监控、日志、测试、Prompt 管理、评估体系。大模型应用的输出有不确定性所以比传统应用更需要完善的观测体系。我常用的组合是 SkyWalking 做链路追踪Spring AI 自带的 ModelOptions 日志开启 Prompt/响应记录配合用社区轻量的提示词管理平台做版本控制。1.2 为什么 Java 在这个时代反而有优势很多 Java 开发者有个误区觉得自己不学 Python 就没法做 AI。其实在企业级 AI 落地场景里Java 的优势相当硬核。一个直接的例子是并发处理能力。大模型 API 的响应速度一般是秒级比普通接口慢得多。如果一个 AI 功能有大量用户同时使用网关层就需要非常扎实的异步处理能力。Java 生态的虚拟线程从 JDK 21 开始正式发布天然适合这种 IO 密集型场景配合 Spring WebFlux 的响应式编程能实现在同样的硬件配置下支撑远超传统线程模型的并发量。另一个是数据与事务的一致性保障。AI 应用不只是聊天它总要读写数据库生成的内容要入库用户的积分要扣减操作的审计日志要记录。这里就涉及分布式事务、幂等控制、状态机流转等一堆问题。这是 Java 体系深耕二十多年的领域Spring 全家桶 Seata 各种 ORM 框架全是现成而且久经考验的解决方案。Python 生态在这块老实说企业级的最佳实践成熟度差不少。再有一点是安全与合规。企业级项目对权限控制、操作审计、数据脱敏的要求严苛。Java 有 Spring Security、Shiro 等一套成熟的权限治理方案结合若依这类脚手架RBAC 模型几个注解就能搞定。这在涉及金融、政务、医疗等行业的 AI 项目里是刚需。所以我的判断是Java 在 AI 时代不会是配角而是那个负责把 AI 能力真正做成产品、扛住生产流量的主力。Python 在前端探索Java 在后端承载——这个协作模式未来三五年里都会是主流。2. 框架深拆Spring AI、LangChain4j 与模型集成三板斧2.1 Spring AI 凭什么值得学先看一段最基础的代码感受一下 Spring AI 的使用方式。引入依赖后在 application.yml 里配上模型 API Key然后直接注入 ChatClient 就能聊天ChatClient chatClient ChatClient.builder(chatModel).build(); String answer chatClient.prompt() .system(你是一个金融分析师回答需要简洁专业) .user(请解释一下什么是通胀) .call() .content();就这么简单。你不需要去理解底层是什么 HTTP 调用、什么 JSON 结构Spring AI 全都做了封装。关键是它的抽象层次设计得很好ChatModel、EmbeddingModel、VectorStore、ChatMemory 这些接口都是厂商无关的。你今天用的通义千问明天想要换成 DeepSeek或者切换到本地 Ollama只需要改配置代码层面基本不用动。Spring AI 的定位不只是“访问大模型的客户端”它正在逐步长成一个完整的 AI 应用框架。比如它支持结构化输出——让模型直接返回 Java 对象而非纯文本。这在做信息抽取、意图识别时非常有用// 假设有个方法要判定用户评论是好评还是差评 record SentimentResult(String sentiment, double confidence) {} SentimentResult result chatClient.prompt() .user(分析这条评论的情感: text) .call() .entity(SentimentResult.class);背后原理是给模型提供 JSON Schema模型输出按 Schema 结构化框架再反序列化成 Java 类型。这比正则匹配要稳得多。你可能觉得“这有什么好稀奇的不就是一个函数调用吗”但在传统 Java 开发里让模型输出一个带类型的对象回去过去的做法是解析完字符串再手动映射字段一多就头大Spring AI 直接把这个链路打通了。2.2 LangChain4j如果你想要的是原汁原味的 LangChainLangChain4j 的定位跟 Spring AI 略有重合但设计哲学有区别。它是把 Python 的 LangChain 设计思路搬到 Java 世界API 的命名和概念高度对标Chain、Message、Memory、Tool、RAG。如果你之前看过 LangChain 的教程再看 LangChain4j 会格外亲切。LangChain4j 真正强的地方在于 AiServices——它允许你定义一个 Java 接口然后用 AiServices 动态生成实现。这个方法属于“声明式 AI 编程”程序员只需要定义“我要什么能力”不用管模型怎么被调用。举个例子interface CustomerServiceAssistant { SystemMessage(你是客服助手回答要友善简洁) String reply(UserMessage String userMessage, MemoryId String sessionId); } CustomerServiceAssistant assistant AiServices.builder(CustomerServiceAssistant.class) .chatLanguageModel(model) .chatMemory(MessageWindowChatMemory.withMaxMessages(10)) .build(); String reply assistant.reply(我的订单还没收到, session-123);在这里MemoryId 决定了不同用户之间的对话记忆隔离MessageWindowChatMemory 控制记忆窗口大小。你可以像写普通 Spring Service 一样去写 AI 能力接口模块化程度很高。2.3 模型集成层的三种姿势与取舍搞 Java AI一定避不开一个经典问题模型是 Python 训练出来的Java 到底如何跟它协作这里有三种主流方式各有明确的使用场景。第一种HTTP 调用模型服务。这是目前生产环境最常见的模式。用 FastAPI 把模型封装成 REST APIJava 侧用 WebClient 调。好处是语言边界清晰、模型可以独立扩缩容、Java 侧升级不影响模型。坏处是多一次网络跳转延迟会多几毫秒到几十毫秒。这个方案我非常推荐给大多数团队因为它的可维护性最好。# Python 侧FastAPI 封装一个简单的推理服务 app.post(/predict) def predict(request: PredictRequest): inputs tokenizer(request.text, return_tensorspt) with torch.no_grad(): outputs model(**inputs) result post_process(outputs) return {result: result}// Java 侧Spring AI 的 WebClient 方式调用 String response webClient.post() .uri(http://model-service:8000/predict) .bodyValue(Map.of(text, 需要分析的文本)) .retrieve() .bodyToMono(String.class) .block();第二种ONNX Runtime 进程内推理。ONNX 是一个开放的模型交换格式PyTorch 模型可以导出成 ONNX 格式然后用 onnxruntime Java 库直接在 JVM 进程里跑。这种方式省掉了网络开销延迟最低适合对实时性要求极高、模型又不太大的场景比如在线的意图分类、文本纠错。缺点是模型跟业务服务耦合在一起模型大小、GPU 显存、依赖的 native 库都要一起管理上线时要格外谨慎。第三种DJL 深度集成。DJL 是 AWS 开源的 Deep Java Library它允许你在 Java 里直接加载和运行 PyTorch、TensorFlow 模型。它能让你不做 Python 侧的封装纯 Java 推理。但说实话它的学习曲线比前两种陡峭而且社区资料相比 Python 还是少。我建议是除非你的团队完全没有 Python 背景否则优先走第一种或第二种路线DJL 可以作为补充方案了解。3. 知识库问答与向量检索的完整落地3.1 从文档到向量RAG 流程的 Java 实现先解释一下为什么知识库问答需要 RAG检索增强生成这个技术。大模型的知识截止到训练时间而且它不知道你公司的内部数据。RAG 的思路是先把你的文档向量化存起来用户在提问时系统先从库里检索出相关内容片段再把这些片段“喂”给大模型作为上下文让模型基于材料回答。这样既不用微调模型又能保证答案有据可查。Spring AI 实现 RAG 非常顺手整个链路是文档加载 - 分割 - 向量化 - 存储 - 检索 - 汇总问答。直接看代码感受下// 1. 读取 PDF 文档拆分成块 var reader new PagePdfDocumentReader(classpath:docs/product-manual.pdf); ListDocument documents reader.get(); // 2. 文本分割器按 token 数和重叠度切分 var splitter new TokenTextSplitter(500, 100); // 块大小500 token重叠100 token // 3. 向量化并存入向量数据库 vectorStore.add(splitter.apply(documents)); // 4. 检索相关文档组装问答 String question 产品的保修期是多久; ListDocument relevantDocs vectorStore.similaritySearch( SearchRequest.builder(question).withTopK(3).build()); // 5. 把检索结果拼进 Prompt String context relevantDocs.stream() .map(Document::text) .collect(Collectors.joining(\n---\n)); String answer chatClient.prompt() .system(仅基于给定的上下文回答用户问题不要编造) .user(上下文 context \n问题 question) .call() .content();这段代码里块大小和重叠度是最值得解释的两个参数。块太大单次检索的粒度太粗模型一次能利用的上下文有限块太小语义被切断检索召回率下降。常规经验值是文本块 300~500 token、重叠 50~100 token。重叠是为了避免切分时正好把一截关键语义切断。如果你处理的文档是技术手册这类章节清晰的也可以按 Markdown 标题结构切分效果往往比纯按 token 切好。向量数据库的选择也容易让人纠结。生产级场景我会优先考虑 Milvus性能、云原生能力强管理界面齐全。中小项目用 Chroma单机部署省心。如果你的数据本身在 PostgreSQL 里可以直接用 pgvector 插件少维护一个组件。Spring AI 的 VectorStore 对这三者都支持切换时只需改依赖和连接配置。3.2 对话记忆与多轮上下文管理知识库问答一般不止一问一答用户会追问“那维修要多久”系统得知道“那”指的是保修期的相关讨论。这就要求 RAG 流程结合对话历史。实现方式一把对话历史拼进 Prompt。Spring AI 提供了 ChatMemory 概念ChatMemory memory MessageWindowChatMemory.builder() .chatMemoryStore(InMemoryChatMemoryStore()) .maxMessages(20) // 最多保留二十条消息超出自动清理 .build();这种方式简单粗暴适合大多数场景。注意历史消息越多上下文越长Prompt 越长费用和延迟都涨。所以 maxMessages 要按实际测试折中选择我一般从 10 条起步调。实现方式二摘要压缩。当对话超过阈值时先用模型把前面的对话压缩成一段摘要然后只保留摘要加最近几条消息。这种方法对话再长也不会爆上下文但代价是早期聊天细节可能丢失。如果你的业务允许一定程度遗忘用这个方案能省不少 token 成本。不能忽略的一点是——用户敏感信息安全。对于历史消息、文档内容服务端要控制好权限。不能让一个普通员工检索到管理层专属的材料。Spring AI 本身不处理这块但你可以做“文档级权限过滤”就是把每条文档的向量记录里存一个 owner 字段检索时直接拼上权限过滤条件。这个做法在 sanity check 阶段非常重要。4. Agent 与智能工具调用让 AI 真正“动手做事”4.1 从聊天到行动为 AI 挂上你的业务工具到这里聊的还是“AI 回答用户问题”。但真实业务里光问答远远不够。用户说“帮我查一下订单”和“帮我查订单 OK-1001 的状态”——前者只是问后者是要求 AI 去数据库里把那条订单调出来。这就需要 Agent。Agent 的核心机制是 Function Calling / Tool Calling。它的原理是你给大模型描述“有哪些工具可用”、“每个工具接收什么参数”模型在回答时按需选择调用某个工具并把参数以结构化 JSON 形式返回。系统执行工具后把结果回传给模型模型再基于结果生成自然语言回复。Spring AI 的做法干净利落直接用 Tool 注解标注方法Component public class OrderTools { private final OrderService orderService; Tool(description 根据订单号查询订单状态) public String queryOrderStatus(String orderId) { Order order orderService.findByOrderId(orderId); if (order null) { return 订单不存在; } return 订单 orderId 当前状态 order.getStatus() 下单时间 order.getCreatedAt(); } } // 注入工具 Bean ChatClient chatClient ChatClient.builder(chatModel) .defaultTools(new OrderTools()) .build();原理上Spring AI 扫描到 Tool 注解后会生成工具的名称、描述、JSON Schema 元数据随请求一起发给模型。模型觉得需要调用时就返回一个函数调用请求框架自动反射调用对应方法把返回结果重新发给模型让它组织成最终回答。整个链路无需用户感知。4.2 多工具编排与异常处理的实战经验真实场景下一个 Agent 不可能只有一个工具。比如客服机器人手里可能有查订单的、查物流的、查退换货政策的、创建工单的四个工具协同。这里建议把工具按“查、写、创建”分类每个方法描述写精准。模型在工具选择上很大程度依赖 description一个含糊的描述会造成工具乱叫。有次我遇到一个典型的坑——查订单工具的描述是“查询订单信息”没有任何其他说明。结果用户问“我的退款到哪一步了”模型老去调用查订单工具返回的信息对不上回答前言不搭后语。后来把描述改成“查询订单当前状态、物流信息和退款进度适用于订单跟踪类问题”准确率一下子上来了。工具异常也是必坑点。不要让模型感知到 Java 异常的堆栈信息应该把异常转换成人类可读的提示再返回给模型。否则会发生奇怪的事情比如模型看着空指针异常的日志一本正经地问用户“您的订单出现了空指针是否要重试”。Tool(description 按订单号查询物流轨迹) public String queryLogistics(String orderId) { try { return logisticsService.track(orderId); } catch (OrderNotFoundException e) { return 未查询到该订单请用户核对订单号; } }这条经验非常好用把工具的返回值当作一等的“对话内容”来设计少泄内部细节给大模型能让 Agent 表现稳定得多。4.3 Agent 编排框架的选型建议如果你要做的是一个比较复杂的 Agent——比如“让 AI 自主完成多轮资料收集、对比、生成分析报告”那工具直挂的方式就不够用了。这时候该考虑编排框架。社区里 Java 方向的编排框架我会根据复杂程度做如下分层建议简单任务用 Spring AI 的 ChatClient 几个 Tool 方法50 行代码搞定不要引入额外框架。多角色分工任务用 LangChain4j 的 AiServices配合 GroupChat 机制让多个 AI 角色协作。例如研究助理负责找资料编辑负责归纳组长负责输出报告。大规模自动化流程考虑引入 Flowable 这类 BPMN 流程引擎把 AI 能力封装成服务节点用可视化流程定义编排多步操作。这种方法适合企业里那些有明确流程审批规范的场景让 AI 的每一步都被审计追踪。我的核心观点是不要为了用框架而用框架。Agent 的复杂度是由场景定的能用一句话解决的就别写成有状态工作流。我见过许多项目为了炫技堆了一堆 Agent 概念结果生产上一个灵异问题都排查半天。先跑起来遇到真实瓶颈再升级。5. 从零搭建一个 Java AI 全栈项目5.1 环境准备与项目骨架前面讲了不少概念这节真正动手搭一个最小可运行的知识库问答 Agent 工具调用项目。为了贴近大多数 Java 开发者的现状这里技术选择是JDK 17、Spring Boot 3.x、Spring AI 1.0.x、若依框架可选、MySQL pgvector。第一步搭一个 Spring Boot 项目。直接用 Spring Initializrstart.spring.io勾选 Web、JDBC、PostgreSQL Driver、Spring AI。如果你是做企业项目先拉若依的代码生成模板再把 AI 模块作为 Starter 引入。这里特别提醒一个版本坑Spring AI 的版本迭代非常快它跟 Spring Boot 的版本是有对应关系的。别随便从网上下一个旧版教程配最新版依赖会碰到一堆 API 被改名的窘境。我建议直接用 start.spring.io 网页上配好的版本号或者官方文档的 start.spring.io 链接生成这是当前最不容易出错的做法。第二步配置模型。以阿里云百炼平台DashScope为例application.yml 只要写上spring: ai: dashscope: api-key: ${DASHSCOPE_API_KEY} chat: options: model: qwen-plus如果你用的是本地 Ollama则配spring: ai: ollama: base-url: http://localhost:11434 chat: options: model: llama3.1先把一个最简单的 Ping 接口跑通“调用模型返回一句话”。确认配置没问题再往下面进行。5.2 核心代码文档上传、向量入库、检索问答以“产品手册问答”为目标。先定义 ControllerRestController RequestMapping(/ai) public class AiController { private final VectorStore vectorStore; private final ChatClient chatClient; public AiController(VectorStore vectorStore, ChatClient chatClient) { this.vectorStore vectorStore; this.chatClient chatClient; } // 文档导入 PostMapping(/documents) public String upload(RequestParam(file) MultipartFile file) throws IOException { var reader new PagePdfDocumentReader(new ByteArrayResource(file.getBytes())); ListDocument docs reader.get(); vectorStore.add(new TokenTextSplitter(500, 100).apply(docs)); return 导入文档成功共 docs.size() 段; } // 知识问答 PostMapping(/ask) public String ask(RequestBody String question) { ListDocument hits vectorStore.similaritySearch( SearchRequest.builder(question).withTopK(3).build()); String context hits.stream().map(Document::text) .collect(Collectors.joining(\n)); return chatClient.prompt() .system(只根据提供的材料回答无法回答时说明材料中没有相关信息。) .user(材料 context \n问题 question) .call() .content(); } }有个小细节值得提文档导入接口一定要加文件大小限制和类型白名单只允许 PDF、DOCX、TXT不然用户传一个几十兆的扫描件模型推理时间会翻好几倍。可以自定义一个 MultipartFile 校验器或者在 Nginx 层限制。5.3 高并发与超时处理AI 服务的三大保命策略AI 接口跟普通接口的一个巨大差异是响应慢。普通接口要求 200ms 内返回AI 接口可能要 5~10 秒起步。如果你按常规 Feign/HTTP 调用的姿势去接用户端非常容易超时服务端也很容易发生连接池耗尽。我的实战经验总结成下面三条第一一律用 WebClient 异步调用不用 RestTemplate 同步阻塞。Spring AI 底层已经支持 WebClient响应式链路天然适配慢速 IO。拆一个线程专门等大模型响应是生产上最大的抗压点。第二设置合理的超时时间。Chat 补全接口我一般设连接超时 3 秒、读取超时 30 秒。读取超时一定要给足碰见模型负载高生成 500 字可能要 20 秒。时间设短了会频繁触发重试用户看到的就是“AI 下线了”。第三接入限流和并发数控制。相同的大模型 API 并发压力大了会429限流。方案是使用 Resilience4j 的 RateLimiter Bulkhead。我惯用的参数是每路模型分配最大并发 20超出的请求进队列队列满了直接秒回“服务繁忙”。这样不会把模型供应商的额度毛刺放大到整个服务雪崩。6. 常见问题与避坑实录6.1 模型“幻觉”严重怎么办“幻觉”是大模型最容易让人头疼的问题。给出的信息根本不是事实但语气笃定客户经理拿去发给客户那是要出事的。处理方式有优先级排序第一层做 Prompt 约束。这是成本最低的做法在 system prompt 里明确“只基于提供的资料回答不要臆测”“不确定就说出处不够充分并给出用户可能需要的验证途径”。实测下来这套约束能把大部分编造内容挡住。第二层加检索内容可信度。RAG 检索回来的片段带相似度分数如果最高相似度低于指定阈值可以先不调用模型直接返回“抱歉资料库中暂未找到相关内容”。这个逻辑很简单但非常好用我把它叫做“检索兜底闸门”。第三层关键数据走代码校验。如果 AI 输出的内容涉及金额、日期、手机号、订单号这类强规则数据别靠模型保证正确。实现上可以做一个“输出校验 Service”用正则或查库方式对输出里的关键实体做二次核验。做不到百分之百再由人工介入。这一步能在合规场景挡掉大量责任问题。6.2 高并发下把连接池打爆的经典排障有次上线 AI 问答功能刚开始测试一切正常结果大规模推广后运维报警数据库连接池跑满。排查下来发现原因非常反直觉——我们的 AI 对话接口内部要先做向量检索向量检索里底层是 PG而 PG 连接池和业务连接池是共用的。AI 请求慢很多请求一直占着 DB 连接等待向量检索返回连接池很快被占满连带普通业务接口也受影响。解决方案把 AI 相关功能的数据源独立出来单独配置一个 max 更小的连接池并且加上读超时。运维层面再按 AI 接口和普通接口分流网关限流。这件事给我的教训是AI 功能上线前要把请求链路画一遍凡是涉及慢调用的环节都必须跟核心业务的连接池隔离。6.3 Prompt 管理别把提示词硬编码在 Java 里我看到不少团队把 Prompt 直接写在代码字符串拼接里这个习惯在 AI 应用里迟早出事。原因有二一Prompt 的调试频率比代码高得多每次微调都要重新发版效率极低二线上排查时无法快速定位是 Prompt 问题还是代码问题。推荐的做法是把 Prompt 模板放到独立的资源文件或干脆用模板注入专用工具管理。Spring AI 支持在 prompt 中使用占位符参数String message chatClient.prompt() .system(ResourceUtils.fromClasspath(prompts/qa-system.txt)) .user(材料 context \n问题 question) .call() .content();qa-system.txt 里用 {context} 这类占位符包裹改提示词不用重新编译。更进一步可以做一个简单的数据库表保存 Prompt 版本后台界面能直接编辑并热加载。这套“Prompt 即配置”的做法是 AI 应用工程化的基础。6.4 纯 Java 团队做模型服务最稳的捷径很多团队完全没有 Python 背景部署大模型推理服务是一大坎。我的建议是两条接地气的捷径一是直接使用模型供应商的托管推理服务如百炼、OpenAI 等Java 这边只做业务聚合。结合私有化需求再用专有 VPC 来保证数据链路安全。二是对接 Ollama。Ollama 把模型下载、加载、服务化全包了一条命令就能跑起本地模型对外提供 OpenAI 兼容的 API。Java 侧对接它基本跟对接 OpenAI 一致。对于不想碰 Python 的团队这是入门私有化模型部署最平滑的路线。等到团队真的需要 GPU 集群、大规模微调时再考虑招一个懂 Python 推理的助手或者搭建 MLflow/Seldon 这类模型服务平台届时再引入 Python 侧桥接。我的最终体会这套 Java AI 技术栈说穿了就是把“大模型能力”和“企业级工程能力”焊接在一起的那组工具和思维方法。学它的过程有点像组装一部手机——芯片模型是别人造好的你的价值在于设计电路板、系统、外壳和应用商店把各种好用的能力整合成一部好用的手机。我能给的最实在建议是从知识库问答或客服助手这类小而完整的场景起步走通一遍 Spring AI 向量库 模型的链路再去研究 Agent 编排和复杂流程。如果这篇文章对你有一点点启发后续可以从 Spring AI 官方的 “Getting Started” 动手试试。第一批代码不用追求完美先跑通就有下一步。