在 AI 应用快速落地的大背景下越来越多的开发团队开始把手里的业务系统与大型语言模型LLM对接。无论是做智能客服、知识库问答还是自动化流程编排都会面对同样的技术选择题模型怎么选、上下文怎么管理、工具怎么编排、服务怎么部署。本文从工程视角梳理 AI 应用开发的完整链路包含核心概念、环境搭建、Spring AI 实战代码、模型部署优化以及高频问题排查适合打算从零开始落地 AI 应用的开发者也适合想系统补全 AI 工程化知识的后端工程师。1. AI技术演进与工程化趋势1.1 当前AI发展的几个明显信号过去两年AI 领域最直观的变化是“模型能力增长”与“工程落地”两条线并行。一方面基础大模型在语言理解、代码生成、多模态理解上的能力持续提升另一方面真正让 AI 进入生产环境的是那些把模型封装成稳定服务的工程链路。早期大家关注的是“哪个模型更强”而现在更关心的是“能不能稳定地接入业务”。从开发者视角观察有几个信号比较明显。开源模型与商业模型的差距在缩小通过量化、蒸馏、微调等手段中小团队也可以在消费级硬件上运行可用的大模型AI 应用从“单次对话”走向“多步骤任务”开发者不再满足于调用一次模型拿结果而是希望模型能理解业务上下文、调用外部工具、按流程完成任务开发工具链越来越完善Spring AI、LangChain、LlamaIndex、Ollama、vLLM 等工具让 AI 应用开发逐渐标准化AI 编程工具也进入了日常工作流基于大模型的代码助手已经能完成相当一部分样板代码和测试代码的编写。这些信号背后有一个共同点AI 的竞争已经从“谁的模型参数多”转向“谁能把模型稳定、可控、低成本地放进业务系统”。1.2 从模型能力到工程落地的转变早期使用 AI 的方式很简单把问题丢给模型拿到回答。这种方式在个人场景足够但在企业级系统中远远不够。企业需要的是稳定的响应时间与吞吐、可解释可审计的决策过程、与现有业务系统订单、用户、库存的安全集成、数据不出内网或符合合规要求以及成本可控、预算可预测。这些诉求把问题从“模型有多强”转移到了“系统如何设计”。同样的模型在不同团队手里的最终效果可能差别很大。区别在于是否有完善的提示词管理、数据接入、上下文组织、工具调用、异常兜底和性能监控。换句话说AI 竞赛的下半场是工程化能力的较量。一个模型能力突出但没有配套工程链路的系统很难在真实业务中长期稳定运行反过来工程链路完善但模型选型一般的系统往往也能通过提示词、检索增强和流程编排达到不错的效果。1.3 技术生态的差异化路径不同技术生态在 AI 落地方式上各有侧重。有些团队擅长快速迭代原型把 AI 功能嵌入现有产品利用成熟的开源生态降低起步成本有些团队则更重视底层基础设施从模型训练、微调到推理优化都自主掌控。这两种路径没有绝对优劣更多是资源禀赋和业务需求的差异。对开发者来说与其争论哪种模式更好不如掌握通用的 AI 工程技能——数据准备、模型调用、RAG、Agent 编排、部署监控。这些能力无论技术风向怎么变都能快速迁移。本文后面介绍的本地模型部署、Spring AI 集成、向量检索等方法也是围绕这条主线展开的理解了这些通用能力你再去看任何新的 AI 框架都会轻松很多。2. AI开发环境准备与工具链2.1 基础运行环境在动手写代码之前先梳理一套比较通用的开发环境。版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。操作系统方面Windows 10/11、macOS 或 Linux 都可以如果是 Java 开发建议 JDK 17 及以上因为 Spring Boot 3.x 需要 JDK 17 作为基础Maven 建议 3.8 以上用于管理项目依赖如果需要做数据处理或模型微调可以准备 Python 3.10 以上的环境模型服务方面可以选择云端 LLM API也可以使用 Ollama 在本地运行开源模型。如果本机还没装 Ollama可以到官网下载对应系统的安装包。安装完成后在命令行执行ollama list能正常输出就说明安装成功。对初学者来说本地模型最大的好处是调试不花钱、数据不出本机等逻辑跑通之后再迁移到云端或服务器成本结构会更清晰。2.2 模型接入方式AI 应用开发首先需要确定“模型从哪里来”。常见方式有两类。第一类是调用云端大模型 API优点是接入简单不用关心 GPU 和部署按量付费接口标准缺点是数据会发送到外部服务成本随调用量线性增长适合业务验证期和中小流量场景。第二类是本地部署开源模型通过 Ollama、vLLM 等工具把 Qwen、Llama 等开源模型跑在自己的服务器上数据不出内网长期调用成本可控缺点是需要准备一定配置的 GPU 服务器运维复杂度更高模型更新也需要自己维护。对初学者来说建议先从云端 API 或本机 Ollama 开始把应用逻辑跑通之后再根据业务需求决定是否迁移到私有化部署。选择模型时除了关注榜单分数还要看社区活跃度、许可证、生态工具是否完善。一个生态完善但分数略低的模型在实际工程中往往比一个分数高但资料稀缺的模型更好落地。2.3 开发框架选择常见的 AI 应用开发框架主要有三个方向。LangChain 是 Python 生态中最成熟的 AI 编排框架适合快速做 RAG、Agent 原型LlamaIndex 偏向数据索引与知识库问答RAG 场景功能很强Spring AI 面向 Java/Spring 生态可以把 AI 能力嵌入既有 Spring Boot 服务对后端团队非常友好。如果你所在团队以 Java 为主第 4 章的 Spring AI 实战会更贴近实际工作如果你更熟悉 PythonLangChain 和 LlamaIndex 的学习成本会低一些。框架不是关键关键是理解背后的核心概念。无论用哪个框架你都会遇到提示词管理、文本向量化、检索召回、工具调用、流式输出、成本统计这些通用问题。先把这些概念吃透再选一个你熟悉的框架动手实践学习效率会高很多。3. AI工程实践核心概念拆解3.1 提示词工程让模型输出更可控提示词工程Prompt Engineering是 AI 应用开发最基础的技能。它解决的问题是通过设计输入给模型的指令让模型输出更符合预期。一个完整的提示词通常包含角色、任务、上下文、输出格式和约束条件等要素。角色是告诉模型“你是一个什么角色”例如“你是一位资深 Java 架构师”任务是明确要求模型做什么例如“请审查以下代码中的线程安全问题”上下文是提供必要的背景信息例如业务规则、已知约束输出格式是约束输出结构例如“输出为 JSON字段包括 errorType 和 suggestion”约束条件是说明不能做什么例如“如果信息不足请回答‘信息不足’不要推测”。下面是一个提示词模板示例你是一名运维工程师负责处理用户提交的技术工单。 请根据以下工单内容判断问题类型网络/数据库/应用/其他 并给出排查步骤。 工单内容 {work_order} 输出格式 {type: 问题类型, steps: [步骤1, 步骤2]}在实际项目中提示词不应该散落在代码里建议统一维护在配置中心或单独的提示词文件中方便迭代和回滚。提示词也是需要版本管理的每次修改都要有记录否则上线后很难定位是模型问题还是提示词变化导致的效果波动。3.2 RAG让模型拥有“私有知识”大模型的知识来自训练数据遇到训练时间之后的信息、企业内部文档、特定业务规则时模型往往会答错。RAGRetrieval-Augmented Generation检索增强生成是解决这个问题的常用方案。它的基本流程可以拆成四步文档切分、向量化、检索、生成。文档切分是把 PDF、Word、Markdown 等文档按段落或固定长度切分成小块向量化是用嵌入模型把每个文本块转成向量存入向量数据库检索是用户提问时把问题也转成向量在向量数据库中检索最相关的若干文本块生成是把检索到的文本块与用户问题一起拼进提示词交给大模型生成回答。整个过程可以用下面这段伪代码表达def rag_answer(question: str) - str: # 1. 生成问题的向量 question_vector embedding_model.encode(question) # 2. 从向量库检索TopK相关文档 docs vector_store.search(question_vector, top_k3) # 3. 拼接上下文 context \n\n.join(doc.content for doc in docs) prompt f基于以下资料回答问题\n{context}\n\n问题{question} # 4. 调用大模型生成 return llm.generate(prompt)RAG 的关键在于“检索质量”。如果检索到的文档与问题无关模型生成得再好也无济于事。因此文档切分的粒度、嵌入模型的选择、TopK 参数都需要针对业务数据做调优。此外还要考虑文档更新频率知识库内容变了向量库里的旧向量是否要清理、多久重建一次索引这些问题在长期运行中都会暴露出来。3.3 AI Agent从“回答问题”到“完成任务”如果说 RAG 解决的是“知识来源”问题AI Agent 解决的是“行动能力”问题。Agent 可以让模型自主规划步骤、调用外部工具、观察执行结果并在必要时调整策略。一个典型的 Agent 循环包含以下环节接收用户目标模型规划需要哪些步骤调用工具查询数据库、调用 API、执行命令把工具返回结果反馈给模型模型判断是否达成目标未达成则继续执行下一步。工具调用Function Calling / Tool Calling是 Agent 的核心能力。模型本身不执行代码但它可以输出一个结构化的“调用意图”由程序去真正调用对应函数。下面是一个工具定义的简化示例{ name: query_order_status, description: 查询订单状态, parameters: { type: object, properties: { order_id: {type: string, description: 订单号} }, required: [order_id] } }当用户问“我的订单 2001 什么时候发货”时模型会输出调用query_order_status的意图并填入order_id2001程序拿到这个意图后执行真实查询再把结果交给模型组织自然语言回复。开发 Agent 时需要注意两个问题一是给工具的 description 要写清楚模型靠它判断什么时候该调用哪个工具二是要设置最大迭代次数和超时时间防止 Agent 陷入死循环。4. Spring AI集成实战Spring AI 是 Spring 官方推出的 AI 应用开发框架目标是让 Java 开发者用熟悉的 Spring 风格接入大模型。下面我们用 Spring AI Ollama 本地模型实现一个最简的对话接口和 RAG 问答接口。4.1 创建项目结构为了方便跟随操作我们先把工程目录结构确定下来。可以使用 IDEA 的 Spring Initializr 新建项目也可以手写 pom.xml 后导入。如果选择 Spring Initializr可以直接勾选 Web 与 Spring AI 依赖IDE 会自动生成标准目录结构这里我们以手写为主方便看清每一步。创建完成后把 pom.xml、启动类、控制器与服务类分别放入对应位置包名统一使用com.example.aidemo。整体结构如下spring-ai-demo ├── pom.xml └── src └── main ├── java │ └── com │ └── example │ └── aidemo │ ├── AidemoApplication.java │ ├── controller │ │ └── ChatController.java │ └── service │ └── ChatService.java └── resources └── application.yml4.2 添加依赖在pom.xml中引入 Spring Boot 与 Spring AI 相关依赖。Spring AI 版本迭代比较快不同版本的依赖坐标和 API 可能有差异本文示例思路以常见稳定版本为准。建议使用 Spring AI BOM 统一管理版本具体版本号请以官方最新稳定版为准避免因为手动指定不兼容版本导致启动失败。parent groupId AI应用开发工程化实战：从Spring AI到RAG与Agent
在 AI 应用快速落地的大背景下越来越多的开发团队开始把手里的业务系统与大型语言模型LLM对接。无论是做智能客服、知识库问答还是自动化流程编排都会面对同样的技术选择题模型怎么选、上下文怎么管理、工具怎么编排、服务怎么部署。本文从工程视角梳理 AI 应用开发的完整链路包含核心概念、环境搭建、Spring AI 实战代码、模型部署优化以及高频问题排查适合打算从零开始落地 AI 应用的开发者也适合想系统补全 AI 工程化知识的后端工程师。1. AI技术演进与工程化趋势1.1 当前AI发展的几个明显信号过去两年AI 领域最直观的变化是“模型能力增长”与“工程落地”两条线并行。一方面基础大模型在语言理解、代码生成、多模态理解上的能力持续提升另一方面真正让 AI 进入生产环境的是那些把模型封装成稳定服务的工程链路。早期大家关注的是“哪个模型更强”而现在更关心的是“能不能稳定地接入业务”。从开发者视角观察有几个信号比较明显。开源模型与商业模型的差距在缩小通过量化、蒸馏、微调等手段中小团队也可以在消费级硬件上运行可用的大模型AI 应用从“单次对话”走向“多步骤任务”开发者不再满足于调用一次模型拿结果而是希望模型能理解业务上下文、调用外部工具、按流程完成任务开发工具链越来越完善Spring AI、LangChain、LlamaIndex、Ollama、vLLM 等工具让 AI 应用开发逐渐标准化AI 编程工具也进入了日常工作流基于大模型的代码助手已经能完成相当一部分样板代码和测试代码的编写。这些信号背后有一个共同点AI 的竞争已经从“谁的模型参数多”转向“谁能把模型稳定、可控、低成本地放进业务系统”。1.2 从模型能力到工程落地的转变早期使用 AI 的方式很简单把问题丢给模型拿到回答。这种方式在个人场景足够但在企业级系统中远远不够。企业需要的是稳定的响应时间与吞吐、可解释可审计的决策过程、与现有业务系统订单、用户、库存的安全集成、数据不出内网或符合合规要求以及成本可控、预算可预测。这些诉求把问题从“模型有多强”转移到了“系统如何设计”。同样的模型在不同团队手里的最终效果可能差别很大。区别在于是否有完善的提示词管理、数据接入、上下文组织、工具调用、异常兜底和性能监控。换句话说AI 竞赛的下半场是工程化能力的较量。一个模型能力突出但没有配套工程链路的系统很难在真实业务中长期稳定运行反过来工程链路完善但模型选型一般的系统往往也能通过提示词、检索增强和流程编排达到不错的效果。1.3 技术生态的差异化路径不同技术生态在 AI 落地方式上各有侧重。有些团队擅长快速迭代原型把 AI 功能嵌入现有产品利用成熟的开源生态降低起步成本有些团队则更重视底层基础设施从模型训练、微调到推理优化都自主掌控。这两种路径没有绝对优劣更多是资源禀赋和业务需求的差异。对开发者来说与其争论哪种模式更好不如掌握通用的 AI 工程技能——数据准备、模型调用、RAG、Agent 编排、部署监控。这些能力无论技术风向怎么变都能快速迁移。本文后面介绍的本地模型部署、Spring AI 集成、向量检索等方法也是围绕这条主线展开的理解了这些通用能力你再去看任何新的 AI 框架都会轻松很多。2. AI开发环境准备与工具链2.1 基础运行环境在动手写代码之前先梳理一套比较通用的开发环境。版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。操作系统方面Windows 10/11、macOS 或 Linux 都可以如果是 Java 开发建议 JDK 17 及以上因为 Spring Boot 3.x 需要 JDK 17 作为基础Maven 建议 3.8 以上用于管理项目依赖如果需要做数据处理或模型微调可以准备 Python 3.10 以上的环境模型服务方面可以选择云端 LLM API也可以使用 Ollama 在本地运行开源模型。如果本机还没装 Ollama可以到官网下载对应系统的安装包。安装完成后在命令行执行ollama list能正常输出就说明安装成功。对初学者来说本地模型最大的好处是调试不花钱、数据不出本机等逻辑跑通之后再迁移到云端或服务器成本结构会更清晰。2.2 模型接入方式AI 应用开发首先需要确定“模型从哪里来”。常见方式有两类。第一类是调用云端大模型 API优点是接入简单不用关心 GPU 和部署按量付费接口标准缺点是数据会发送到外部服务成本随调用量线性增长适合业务验证期和中小流量场景。第二类是本地部署开源模型通过 Ollama、vLLM 等工具把 Qwen、Llama 等开源模型跑在自己的服务器上数据不出内网长期调用成本可控缺点是需要准备一定配置的 GPU 服务器运维复杂度更高模型更新也需要自己维护。对初学者来说建议先从云端 API 或本机 Ollama 开始把应用逻辑跑通之后再根据业务需求决定是否迁移到私有化部署。选择模型时除了关注榜单分数还要看社区活跃度、许可证、生态工具是否完善。一个生态完善但分数略低的模型在实际工程中往往比一个分数高但资料稀缺的模型更好落地。2.3 开发框架选择常见的 AI 应用开发框架主要有三个方向。LangChain 是 Python 生态中最成熟的 AI 编排框架适合快速做 RAG、Agent 原型LlamaIndex 偏向数据索引与知识库问答RAG 场景功能很强Spring AI 面向 Java/Spring 生态可以把 AI 能力嵌入既有 Spring Boot 服务对后端团队非常友好。如果你所在团队以 Java 为主第 4 章的 Spring AI 实战会更贴近实际工作如果你更熟悉 PythonLangChain 和 LlamaIndex 的学习成本会低一些。框架不是关键关键是理解背后的核心概念。无论用哪个框架你都会遇到提示词管理、文本向量化、检索召回、工具调用、流式输出、成本统计这些通用问题。先把这些概念吃透再选一个你熟悉的框架动手实践学习效率会高很多。3. AI工程实践核心概念拆解3.1 提示词工程让模型输出更可控提示词工程Prompt Engineering是 AI 应用开发最基础的技能。它解决的问题是通过设计输入给模型的指令让模型输出更符合预期。一个完整的提示词通常包含角色、任务、上下文、输出格式和约束条件等要素。角色是告诉模型“你是一个什么角色”例如“你是一位资深 Java 架构师”任务是明确要求模型做什么例如“请审查以下代码中的线程安全问题”上下文是提供必要的背景信息例如业务规则、已知约束输出格式是约束输出结构例如“输出为 JSON字段包括 errorType 和 suggestion”约束条件是说明不能做什么例如“如果信息不足请回答‘信息不足’不要推测”。下面是一个提示词模板示例你是一名运维工程师负责处理用户提交的技术工单。 请根据以下工单内容判断问题类型网络/数据库/应用/其他 并给出排查步骤。 工单内容 {work_order} 输出格式 {type: 问题类型, steps: [步骤1, 步骤2]}在实际项目中提示词不应该散落在代码里建议统一维护在配置中心或单独的提示词文件中方便迭代和回滚。提示词也是需要版本管理的每次修改都要有记录否则上线后很难定位是模型问题还是提示词变化导致的效果波动。3.2 RAG让模型拥有“私有知识”大模型的知识来自训练数据遇到训练时间之后的信息、企业内部文档、特定业务规则时模型往往会答错。RAGRetrieval-Augmented Generation检索增强生成是解决这个问题的常用方案。它的基本流程可以拆成四步文档切分、向量化、检索、生成。文档切分是把 PDF、Word、Markdown 等文档按段落或固定长度切分成小块向量化是用嵌入模型把每个文本块转成向量存入向量数据库检索是用户提问时把问题也转成向量在向量数据库中检索最相关的若干文本块生成是把检索到的文本块与用户问题一起拼进提示词交给大模型生成回答。整个过程可以用下面这段伪代码表达def rag_answer(question: str) - str: # 1. 生成问题的向量 question_vector embedding_model.encode(question) # 2. 从向量库检索TopK相关文档 docs vector_store.search(question_vector, top_k3) # 3. 拼接上下文 context \n\n.join(doc.content for doc in docs) prompt f基于以下资料回答问题\n{context}\n\n问题{question} # 4. 调用大模型生成 return llm.generate(prompt)RAG 的关键在于“检索质量”。如果检索到的文档与问题无关模型生成得再好也无济于事。因此文档切分的粒度、嵌入模型的选择、TopK 参数都需要针对业务数据做调优。此外还要考虑文档更新频率知识库内容变了向量库里的旧向量是否要清理、多久重建一次索引这些问题在长期运行中都会暴露出来。3.3 AI Agent从“回答问题”到“完成任务”如果说 RAG 解决的是“知识来源”问题AI Agent 解决的是“行动能力”问题。Agent 可以让模型自主规划步骤、调用外部工具、观察执行结果并在必要时调整策略。一个典型的 Agent 循环包含以下环节接收用户目标模型规划需要哪些步骤调用工具查询数据库、调用 API、执行命令把工具返回结果反馈给模型模型判断是否达成目标未达成则继续执行下一步。工具调用Function Calling / Tool Calling是 Agent 的核心能力。模型本身不执行代码但它可以输出一个结构化的“调用意图”由程序去真正调用对应函数。下面是一个工具定义的简化示例{ name: query_order_status, description: 查询订单状态, parameters: { type: object, properties: { order_id: {type: string, description: 订单号} }, required: [order_id] } }当用户问“我的订单 2001 什么时候发货”时模型会输出调用query_order_status的意图并填入order_id2001程序拿到这个意图后执行真实查询再把结果交给模型组织自然语言回复。开发 Agent 时需要注意两个问题一是给工具的 description 要写清楚模型靠它判断什么时候该调用哪个工具二是要设置最大迭代次数和超时时间防止 Agent 陷入死循环。4. Spring AI集成实战Spring AI 是 Spring 官方推出的 AI 应用开发框架目标是让 Java 开发者用熟悉的 Spring 风格接入大模型。下面我们用 Spring AI Ollama 本地模型实现一个最简的对话接口和 RAG 问答接口。4.1 创建项目结构为了方便跟随操作我们先把工程目录结构确定下来。可以使用 IDEA 的 Spring Initializr 新建项目也可以手写 pom.xml 后导入。如果选择 Spring Initializr可以直接勾选 Web 与 Spring AI 依赖IDE 会自动生成标准目录结构这里我们以手写为主方便看清每一步。创建完成后把 pom.xml、启动类、控制器与服务类分别放入对应位置包名统一使用com.example.aidemo。整体结构如下spring-ai-demo ├── pom.xml └── src └── main ├── java │ └── com │ └── example │ └── aidemo │ ├── AidemoApplication.java │ ├── controller │ │ └── ChatController.java │ └── service │ └── ChatService.java └── resources └── application.yml4.2 添加依赖在pom.xml中引入 Spring Boot 与 Spring AI 相关依赖。Spring AI 版本迭代比较快不同版本的依赖坐标和 API 可能有差异本文示例思路以常见稳定版本为准。建议使用 Spring AI BOM 统一管理版本具体版本号请以官方最新稳定版为准避免因为手动指定不兼容版本导致启动失败。parent groupId