简介这是一套基于Spring Boot构建的人工智能机器人项目源码面向计算机、电子信息工程、数学等专业的大学生可用于课程设计、期末大作业或毕业设计参考。项目已对接GPT-3.5、GPT-4.0、Kimi、百度文心一言等主流对话大模型并集成Stable Diffusion与Midjourney绘图能力覆盖文本问答与AI绘画两类典型场景便于理解多模型接入与统一调度的工程实现。压缩包共1157个文件约26.84MB以584个Java源文件为核心业务代码辅以Vue与JavaScript构建前端交互XML、YML、Properties负责配置与依赖管理另有SQL脚本、Dockerfile及图片、字体等静态资源整体结构完整、层次清晰。目前已有1233人学习下载适合希望快速搭建AI机器人原型、研究大模型接口封装与前后端联调的读者参考借鉴。1. 一个能直接跑的 Spring Boot 人工智能机器人它到底解决了什么问题如果你正在做spring boot 毕业设计选题又恰好落在「人工智能机器人」这个方向大概率会遇到一个很尴尬的局面模型 API 调通了但整个项目只有一段孤零零的curl或者一个main方法没有会话管理、没有上下文记忆、没有前端界面、没有配置分层答辩时老师问一句「你的工程化体现在哪」就答不上来。这份基于 Spring Boot 的人工智能机器人资源解决的正是这个断层——它把OpenAI 大模型的调用封装进了一个标准的 Spring Boot 工程里已经对接了多种主流 OpenAI 兼容模型开箱就能跑起来对话同时保留了完整的后端分层结构方便你在此基础上改造成自己的课题。它适合三类人一是拿它当毕业设计底座、需要快速搭出可演示系统的同学二是想学springboot 整合大模型的标准写法、但不想从零踩 HTTP 客户端坑的开发者三是需要一个能本地部署、可切换模型供应商的轻量对话服务的人。需要提前说清楚的是这类项目的核心价值不在算法而在「把模型能力工程化地接进 Java 体系」所以下面我会重点讲配置、调用链、会话管理和排错而不是泛泛谈大模型原理。2. 工程结构与模型接入先搞清楚请求是怎么发出去的拿到一个 Spring Boot 项目别急着run。先花十分钟把目录结构和依赖关系摸清楚后面改配置、换模型、加功能才不会迷路。这个项目是标准的 Maven 结构常见做法是分成controller、service、config、entity、utils几层模型调用逻辑集中在 service 层配置项抽到application.yml。2.1 目录结构与关键文件定位一个典型的目录长这样你可以对照自己解压后的工程核对src/main/java/com/xxx/robot/ ├── controller/ # 对外接口接收前端对话请求 ├── service/ # 业务层封装模型调用与会话逻辑 │ └── impl/ ├── config/ # 模型客户端、跨域、拦截器配置 ├── entity/ # 请求/响应实体、会话对象 ├── utils/ # 工具类如 HTTP、JSON 处理 └── RobotApplication.java # 启动类 src/main/resources/ ├── application.yml # 模型 key、baseUrl、超时等配置 └── static/ # 前端页面若有定位三个文件基本就能掌握全局启动类看包扫描范围application.yml看模型配置service 实现类看调用逻辑。很多人一上来就改代码结果连请求从哪个 controller 进来的都没搞清这是血泪经验里最常见的一种翻车。2.2 依赖与模型 SDK 的选型理由项目对接多种 OpenAI 大模型通常有两种实现路径一是用官方或社区的 Java SDK二是直接用RestTemplate/WebClient手写 HTTP 请求。这份资源更偏向后者或轻量封装原因是 OpenAI 兼容接口的协议其实很统一手写请求反而更透明、更好排错也避免 SDK 版本和 Spring Boot 版本打架。核心依赖一般包括 Web、Lombok、JSON 处理这几类。下面是一段典型的pom.xml片段dependencies !-- Web 能力提供 REST 接口 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- 简化实体类 getter/setter -- dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency !-- JSON 序列化构造请求体 -- dependency groupIdcom.fasterxml.jackson.core/groupId artifactIdjackson-databind/artifactId /dependency /dependencies逻辑说明spring-boot-starter-web是必须的它自带 Jackson 和 TomcatLombok 用来减少样板代码注意 IDE 要装插件否则编译报「找不到符号」。参数上要留意 Spring Boot 版本springboot版本太高比如 3.2时部分老依赖的javax.*包名要换成jakarta.*这是升级时最容易翻车的地方。2.3 模型配置项的写法与含义模型接入的关键全在配置里。常见做法是把 key、baseUrl、模型名、超时都抽到application.yml方便切换供应商ai: model: # 模型服务地址兼容 OpenAI 协议的都可填 base-url: https://api.openai.com/v1 # 你的 API Key切勿提交到公开仓库 api-key: sk-xxxxxxxxxxxxxxxx # 具体模型名按供应商文档填 model-name: gpt-3.5-turbo # 单次请求超时单位毫秒 timeout: 30000 # 上下文保留的对话轮数 max-history: 10逻辑说明base-url决定了你请求发往哪里只要对方兼容 OpenAI 的/chat/completions协议改这一行就能换供应商这是这套设计最实用的地方。api-key是身份凭证openai的api key获取方法各家不同但拿到后务必通过环境变量或配置中心注入别硬编码进代码。max-history控制上下文长度设太大 token 消耗快、响应慢设太小机器人就「失忆」一般 10 轮左右是平衡点。提示api-key一旦写进application.yml并推到 Git等于公开泄露建议用${AI_API_KEY}占位从环境变量读取。3. 对话接口实现从 Controller 到模型响应的完整链路配置通了只是第一步真正决定这个机器人好不好用的是对话接口怎么设计、上下文怎么维护、异常怎么兜底。这一章把请求链路拆开讲每一步都给你能抄的代码。3.1 Controller 层请求入口与参数校验Controller 的职责很单一——接请求、做基础校验、转给 service。常见做法是定义一个对话接口接收用户消息和会话 IDRestController RequestMapping(/api/chat) public class ChatController { Resource private ChatService chatService; /** * 发送对话消息 * param request 含 sessionId 和用户输入 content * return 模型回复 */ PostMapping(/send) public ResultString send(RequestBody ChatRequest request) { // 基础校验避免空消息打到模型 if (request.getContent() null || request.getContent().isBlank()) { return Result.fail(消息不能为空); } String reply chatService.chat(request.getSessionId(), request.getContent()); return Result.ok(reply); } }逻辑说明RequestBody把前端 JSON 映射成ChatRequestsessionId用来区分不同用户的上下文。参数校验放在最前面空消息直接拦掉省得浪费一次模型调用。Result是统一返回包装类前端好处理。这里要注意跨域问题如果前端是独立部署的 Vue 工程需要在 config 里加 CORS 配置否则浏览器直接报跨域错误。3.2 Service 层上下文拼接与模型调用Service 是核心。它要做三件事取出该会话的历史消息、拼成模型要求的 messages 数组、发请求并解析响应。下面是一段可复现的实现Service public class ChatServiceImpl implements ChatService { Value(${ai.model.base-url}) private String baseUrl; Value(${ai.model.api-key}) private String apiKey; Value(${ai.model.model-name}) private String modelName; Value(${ai.model.max-history}) private int maxHistory; Resource private RestTemplate restTemplate; // 简易内存会话存储生产环境建议换 Redis private final MapString, ListMapString, String sessionStore new ConcurrentHashMap(); Override public String chat(String sessionId, String content) { // 1. 取出或初始化该会话历史 ListMapString, String history sessionStore.computeIfAbsent(sessionId, k - new ArrayList()); // 2. 追加用户消息 history.add(Map.of(role, user, content, content)); // 3. 裁剪历史只保留最近 maxHistory 轮 if (history.size() maxHistory * 2) { history history.subList(history.size() - maxHistory * 2, history.size()); sessionStore.put(sessionId, history); } // 4. 构造请求体 MapString, Object body new HashMap(); body.put(model, modelName); body.put(messages, history); HttpHeaders headers new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_JSON); headers.setBearerAuth(apiKey); // 5. 发送请求 HttpEntityMapString, Object entity new HttpEntity(body, headers); String url baseUrl /chat/completions; ResponseEntityMap response restTemplate.postForEntity(url, entity, Map.class); // 6. 解析响应取出回复文本 String reply extractReply(response.getBody()); history.add(Map.of(role, assistant, content, reply)); return reply; } private String extractReply(Map body) { List choices (List) body.get(choices); Map first (Map) choices.get(0); Map message (Map) first.get(message); return message.get(content).toString(); } }逻辑说明第 1、2 步维护上下文这是机器人「记得住」的关键第 3 步裁剪历史防止 token 无限增长maxHistory * 2是因为一问一答算两条。第 4 步的messages数组格式是 OpenAI 协议的核心role只能是system、user、assistant三种。第 5 步用RestTemplate发 POSTsetBearerAuth自动加Authorization头。第 6 步解析响应注意choices是数组取第一个的message.content。参数上要留意RestTemplate需要手动注册为 Bean并配置超时否则默认无超时模型卡住时线程会一直挂着。常见做法是在 config 里用RestTemplateBuilder设置连接和读取超时。3.3 会话存储与多轮对话的边界上面用的是内存ConcurrentHashMap够跑通演示但有两个明显边界一是重启即丢二是多实例部署时各存各的。如果毕设要求「会话持久化」常见做法是换成 Redis把sessionId当 key历史消息序列化后存 list 结构。改造点集中在sessionStore的读写两处其余逻辑不动。多轮对话还有个容易忽略的点system角色。你可以在历史最前面固定插一条system消息用来设定机器人的人设比如「你是一个专业的客服助手」。这条消息不参与裁剪否则聊久了人设就丢了。参数上system内容别写太长它每轮都会消耗 token。4. 避坑与排查这些错误我几乎每次都遇到模型类项目跑不起来八成不是代码逻辑错而是配置、网络、版本这些环境问题。下面五条是我在调试这类工程时反复踩到的坑按「现象 → 原因 → 解决」整理你对着排查能省不少时间。4.1 启动报错找不到符号或类现象编译期报找不到符号 javax.annotation.Resource或启动时ClassNotFoundException。原因Spring Boot 3.x 把javax.*迁移到了jakarta.*而项目里部分代码还是老包名或者 JDK 版本不匹配3.x 要求 JDK 17。解决统一把javax.annotation、javax.servlet换成jakarta对应包确认pom.xml里的java.version和本机 JDK 一致。springboot版本太高时这类问题最集中降级到 2.7.x 往往能快速绕过。4.2 调用模型返回 401 或 403现象接口能进但一调模型就返回 401 Unauthorized。原因api-key无效、过期或者setBearerAuth拼出来的头格式不对比如 key 里混入了空格、换行。解决先用curl单独验证 key 是否可用排除 key 本身问题再检查配置读取Value注入时如果 yml 里 key 带了引号或多余空格会原样传进去。建议打印一次实际请求头核对。4.3 请求超时或长时间无响应现象前端一直转圈后端日志停在发请求那一步。原因RestTemplate没配超时模型侧网络慢或服务端限流时线程被挂死。解决在 config 里给RestTemplate设置连接超时和读取超时读取超时建议 30 秒以上因为大模型生成本身慢同时给接口加熔断或降级超时后返回友好提示而不是让请求悬着。4.4 上下文错乱或机器人「失忆」现象多轮对话时机器人答非所问或者完全不记得上一句。原因sessionId前端没传或每次都在变导致每次都是新会话或者历史裁剪逻辑写错把最近的对话裁掉了。解决确认前端每次请求带同一个sessionId检查裁剪代码subList的起止下标要取「末尾 N 条」别写成从头取。调试时把history打印出来一眼就能看出问题。4.5 中文乱码或响应解析失败现象模型回复里中文变成问号或者解析choices时抛NullPointerException。原因请求头没设charsetUTF-8或者响应结构和你以为的不一样比如出错时返回的是error字段而非choices。解决Content-Type明确写application/json;charsetUTF-8解析前先判断body里有没有choices没有就取error.message返回避免直接 NPE。5. 进阶玩法换模型、加流式、做验证把基础对话跑通之后这个工程还有不少可挖的地方既能提升毕设的完成度也能让你真正理解大模型接入的工程细节。5.1 一行配置切换模型供应商因为请求走的是 OpenAI 兼容协议切换供应商基本只改application.yml里的base-url和model-name。比如换成国内某个兼容接口把base-url指向对方地址、model-name填对方支持的模型名即可代码一行不用动。这也是我建议手写 HTTP 而不是绑死某家 SDK 的原因——大模型生态变化快协议兼容比 SDK 绑定更抗折腾。切换后记得重新验证一次 key 和模型名不同供应商对模型名的写法不完全一致。5.2 流式输出让回复像打字一样出来非流式接口要等模型全部生成完才返回体验上像卡住。改成流式SSE后回复会逐字吐出。核心改动是把请求体里的stream设为true后端用SseEmitter把模型返回的分块数据转发给前端。下面是一个简化骨架GetMapping(/stream) public SseEmitter stream(RequestParam String sessionId, RequestParam String content) { SseEmitter emitter new SseEmitter(0L); // 0 表示不超时 // 异步线程里调用模型流式接口逐块 emitter.send(...) executor.execute(() - { try { // 请求体加 stream: true逐行读取响应 // 每读到一块 delta 内容就 send 出去 emitter.send(SseEmitter.event().data(片段内容)); emitter.complete(); } catch (Exception e) { emitter.completeWithError(e); } }); return emitter; }逻辑说明SseEmitter是 Spring 对 SSE 的封装0L表示不主动超时。模型流式响应是分块的每块里choices[0].delta.content才是增量文本要逐块解析后send。参数上注意前端要用EventSource接收且这个接口是 GET和普通 POST 对话接口分开。流式改造的坑在于异常处理一旦中途出错要completeWithError否则连接一直挂着。5.3 怎么验证这套东西真的能用验证分三层别只测「能回一句话」就完事。第一层单接口验证用 Postman 或curl直接打/api/chat/send确认返回结构正确。第二层多轮验证连续发三条相关消息看机器人是否记得上下文比如先问「我叫什么」再告诉它名字最后问「我叫什么」。第三层异常验证故意填错 key、断网、发空消息看返回是否友好、日志是否清晰。这三层走完基本能覆盖答辩时老师可能问的场景。# 单接口验证示例 curl -X POST http://localhost:8080/api/chat/send \ -H Content-Type: application/json;charsetUTF-8 \ -d {sessionId:test-001,content:你好介绍一下你自己}逻辑说明sessionId固定成test-001方便连续多次调用验证上下文Content-Type带上charset避免中文乱码。跑通这条命令说明从 Controller 到模型的整条链路是通的剩下的就是前端对接和功能扩展了。从那以后我每次拿到这类模型接入工程都强制先跑一遍「单接口 → 多轮 → 异常」三层验证再动任何业务代码因为环境问题永远比逻辑问题更耗时间。希望这份拆解能帮到你把这份 Spring Boot 人工智能机器人真正用起来、改出自己的东西。本文还有配套的精品资源点击获取
Spring Boot 整合 OpenAI 大模型：人工智能机器人工程化实战
简介这是一套基于Spring Boot构建的人工智能机器人项目源码面向计算机、电子信息工程、数学等专业的大学生可用于课程设计、期末大作业或毕业设计参考。项目已对接GPT-3.5、GPT-4.0、Kimi、百度文心一言等主流对话大模型并集成Stable Diffusion与Midjourney绘图能力覆盖文本问答与AI绘画两类典型场景便于理解多模型接入与统一调度的工程实现。压缩包共1157个文件约26.84MB以584个Java源文件为核心业务代码辅以Vue与JavaScript构建前端交互XML、YML、Properties负责配置与依赖管理另有SQL脚本、Dockerfile及图片、字体等静态资源整体结构完整、层次清晰。目前已有1233人学习下载适合希望快速搭建AI机器人原型、研究大模型接口封装与前后端联调的读者参考借鉴。1. 一个能直接跑的 Spring Boot 人工智能机器人它到底解决了什么问题如果你正在做spring boot 毕业设计选题又恰好落在「人工智能机器人」这个方向大概率会遇到一个很尴尬的局面模型 API 调通了但整个项目只有一段孤零零的curl或者一个main方法没有会话管理、没有上下文记忆、没有前端界面、没有配置分层答辩时老师问一句「你的工程化体现在哪」就答不上来。这份基于 Spring Boot 的人工智能机器人资源解决的正是这个断层——它把OpenAI 大模型的调用封装进了一个标准的 Spring Boot 工程里已经对接了多种主流 OpenAI 兼容模型开箱就能跑起来对话同时保留了完整的后端分层结构方便你在此基础上改造成自己的课题。它适合三类人一是拿它当毕业设计底座、需要快速搭出可演示系统的同学二是想学springboot 整合大模型的标准写法、但不想从零踩 HTTP 客户端坑的开发者三是需要一个能本地部署、可切换模型供应商的轻量对话服务的人。需要提前说清楚的是这类项目的核心价值不在算法而在「把模型能力工程化地接进 Java 体系」所以下面我会重点讲配置、调用链、会话管理和排错而不是泛泛谈大模型原理。2. 工程结构与模型接入先搞清楚请求是怎么发出去的拿到一个 Spring Boot 项目别急着run。先花十分钟把目录结构和依赖关系摸清楚后面改配置、换模型、加功能才不会迷路。这个项目是标准的 Maven 结构常见做法是分成controller、service、config、entity、utils几层模型调用逻辑集中在 service 层配置项抽到application.yml。2.1 目录结构与关键文件定位一个典型的目录长这样你可以对照自己解压后的工程核对src/main/java/com/xxx/robot/ ├── controller/ # 对外接口接收前端对话请求 ├── service/ # 业务层封装模型调用与会话逻辑 │ └── impl/ ├── config/ # 模型客户端、跨域、拦截器配置 ├── entity/ # 请求/响应实体、会话对象 ├── utils/ # 工具类如 HTTP、JSON 处理 └── RobotApplication.java # 启动类 src/main/resources/ ├── application.yml # 模型 key、baseUrl、超时等配置 └── static/ # 前端页面若有定位三个文件基本就能掌握全局启动类看包扫描范围application.yml看模型配置service 实现类看调用逻辑。很多人一上来就改代码结果连请求从哪个 controller 进来的都没搞清这是血泪经验里最常见的一种翻车。2.2 依赖与模型 SDK 的选型理由项目对接多种 OpenAI 大模型通常有两种实现路径一是用官方或社区的 Java SDK二是直接用RestTemplate/WebClient手写 HTTP 请求。这份资源更偏向后者或轻量封装原因是 OpenAI 兼容接口的协议其实很统一手写请求反而更透明、更好排错也避免 SDK 版本和 Spring Boot 版本打架。核心依赖一般包括 Web、Lombok、JSON 处理这几类。下面是一段典型的pom.xml片段dependencies !-- Web 能力提供 REST 接口 -- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- 简化实体类 getter/setter -- dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId optionaltrue/optional /dependency !-- JSON 序列化构造请求体 -- dependency groupIdcom.fasterxml.jackson.core/groupId artifactIdjackson-databind/artifactId /dependency /dependencies逻辑说明spring-boot-starter-web是必须的它自带 Jackson 和 TomcatLombok 用来减少样板代码注意 IDE 要装插件否则编译报「找不到符号」。参数上要留意 Spring Boot 版本springboot版本太高比如 3.2时部分老依赖的javax.*包名要换成jakarta.*这是升级时最容易翻车的地方。2.3 模型配置项的写法与含义模型接入的关键全在配置里。常见做法是把 key、baseUrl、模型名、超时都抽到application.yml方便切换供应商ai: model: # 模型服务地址兼容 OpenAI 协议的都可填 base-url: https://api.openai.com/v1 # 你的 API Key切勿提交到公开仓库 api-key: sk-xxxxxxxxxxxxxxxx # 具体模型名按供应商文档填 model-name: gpt-3.5-turbo # 单次请求超时单位毫秒 timeout: 30000 # 上下文保留的对话轮数 max-history: 10逻辑说明base-url决定了你请求发往哪里只要对方兼容 OpenAI 的/chat/completions协议改这一行就能换供应商这是这套设计最实用的地方。api-key是身份凭证openai的api key获取方法各家不同但拿到后务必通过环境变量或配置中心注入别硬编码进代码。max-history控制上下文长度设太大 token 消耗快、响应慢设太小机器人就「失忆」一般 10 轮左右是平衡点。提示api-key一旦写进application.yml并推到 Git等于公开泄露建议用${AI_API_KEY}占位从环境变量读取。3. 对话接口实现从 Controller 到模型响应的完整链路配置通了只是第一步真正决定这个机器人好不好用的是对话接口怎么设计、上下文怎么维护、异常怎么兜底。这一章把请求链路拆开讲每一步都给你能抄的代码。3.1 Controller 层请求入口与参数校验Controller 的职责很单一——接请求、做基础校验、转给 service。常见做法是定义一个对话接口接收用户消息和会话 IDRestController RequestMapping(/api/chat) public class ChatController { Resource private ChatService chatService; /** * 发送对话消息 * param request 含 sessionId 和用户输入 content * return 模型回复 */ PostMapping(/send) public ResultString send(RequestBody ChatRequest request) { // 基础校验避免空消息打到模型 if (request.getContent() null || request.getContent().isBlank()) { return Result.fail(消息不能为空); } String reply chatService.chat(request.getSessionId(), request.getContent()); return Result.ok(reply); } }逻辑说明RequestBody把前端 JSON 映射成ChatRequestsessionId用来区分不同用户的上下文。参数校验放在最前面空消息直接拦掉省得浪费一次模型调用。Result是统一返回包装类前端好处理。这里要注意跨域问题如果前端是独立部署的 Vue 工程需要在 config 里加 CORS 配置否则浏览器直接报跨域错误。3.2 Service 层上下文拼接与模型调用Service 是核心。它要做三件事取出该会话的历史消息、拼成模型要求的 messages 数组、发请求并解析响应。下面是一段可复现的实现Service public class ChatServiceImpl implements ChatService { Value(${ai.model.base-url}) private String baseUrl; Value(${ai.model.api-key}) private String apiKey; Value(${ai.model.model-name}) private String modelName; Value(${ai.model.max-history}) private int maxHistory; Resource private RestTemplate restTemplate; // 简易内存会话存储生产环境建议换 Redis private final MapString, ListMapString, String sessionStore new ConcurrentHashMap(); Override public String chat(String sessionId, String content) { // 1. 取出或初始化该会话历史 ListMapString, String history sessionStore.computeIfAbsent(sessionId, k - new ArrayList()); // 2. 追加用户消息 history.add(Map.of(role, user, content, content)); // 3. 裁剪历史只保留最近 maxHistory 轮 if (history.size() maxHistory * 2) { history history.subList(history.size() - maxHistory * 2, history.size()); sessionStore.put(sessionId, history); } // 4. 构造请求体 MapString, Object body new HashMap(); body.put(model, modelName); body.put(messages, history); HttpHeaders headers new HttpHeaders(); headers.setContentType(MediaType.APPLICATION_JSON); headers.setBearerAuth(apiKey); // 5. 发送请求 HttpEntityMapString, Object entity new HttpEntity(body, headers); String url baseUrl /chat/completions; ResponseEntityMap response restTemplate.postForEntity(url, entity, Map.class); // 6. 解析响应取出回复文本 String reply extractReply(response.getBody()); history.add(Map.of(role, assistant, content, reply)); return reply; } private String extractReply(Map body) { List choices (List) body.get(choices); Map first (Map) choices.get(0); Map message (Map) first.get(message); return message.get(content).toString(); } }逻辑说明第 1、2 步维护上下文这是机器人「记得住」的关键第 3 步裁剪历史防止 token 无限增长maxHistory * 2是因为一问一答算两条。第 4 步的messages数组格式是 OpenAI 协议的核心role只能是system、user、assistant三种。第 5 步用RestTemplate发 POSTsetBearerAuth自动加Authorization头。第 6 步解析响应注意choices是数组取第一个的message.content。参数上要留意RestTemplate需要手动注册为 Bean并配置超时否则默认无超时模型卡住时线程会一直挂着。常见做法是在 config 里用RestTemplateBuilder设置连接和读取超时。3.3 会话存储与多轮对话的边界上面用的是内存ConcurrentHashMap够跑通演示但有两个明显边界一是重启即丢二是多实例部署时各存各的。如果毕设要求「会话持久化」常见做法是换成 Redis把sessionId当 key历史消息序列化后存 list 结构。改造点集中在sessionStore的读写两处其余逻辑不动。多轮对话还有个容易忽略的点system角色。你可以在历史最前面固定插一条system消息用来设定机器人的人设比如「你是一个专业的客服助手」。这条消息不参与裁剪否则聊久了人设就丢了。参数上system内容别写太长它每轮都会消耗 token。4. 避坑与排查这些错误我几乎每次都遇到模型类项目跑不起来八成不是代码逻辑错而是配置、网络、版本这些环境问题。下面五条是我在调试这类工程时反复踩到的坑按「现象 → 原因 → 解决」整理你对着排查能省不少时间。4.1 启动报错找不到符号或类现象编译期报找不到符号 javax.annotation.Resource或启动时ClassNotFoundException。原因Spring Boot 3.x 把javax.*迁移到了jakarta.*而项目里部分代码还是老包名或者 JDK 版本不匹配3.x 要求 JDK 17。解决统一把javax.annotation、javax.servlet换成jakarta对应包确认pom.xml里的java.version和本机 JDK 一致。springboot版本太高时这类问题最集中降级到 2.7.x 往往能快速绕过。4.2 调用模型返回 401 或 403现象接口能进但一调模型就返回 401 Unauthorized。原因api-key无效、过期或者setBearerAuth拼出来的头格式不对比如 key 里混入了空格、换行。解决先用curl单独验证 key 是否可用排除 key 本身问题再检查配置读取Value注入时如果 yml 里 key 带了引号或多余空格会原样传进去。建议打印一次实际请求头核对。4.3 请求超时或长时间无响应现象前端一直转圈后端日志停在发请求那一步。原因RestTemplate没配超时模型侧网络慢或服务端限流时线程被挂死。解决在 config 里给RestTemplate设置连接超时和读取超时读取超时建议 30 秒以上因为大模型生成本身慢同时给接口加熔断或降级超时后返回友好提示而不是让请求悬着。4.4 上下文错乱或机器人「失忆」现象多轮对话时机器人答非所问或者完全不记得上一句。原因sessionId前端没传或每次都在变导致每次都是新会话或者历史裁剪逻辑写错把最近的对话裁掉了。解决确认前端每次请求带同一个sessionId检查裁剪代码subList的起止下标要取「末尾 N 条」别写成从头取。调试时把history打印出来一眼就能看出问题。4.5 中文乱码或响应解析失败现象模型回复里中文变成问号或者解析choices时抛NullPointerException。原因请求头没设charsetUTF-8或者响应结构和你以为的不一样比如出错时返回的是error字段而非choices。解决Content-Type明确写application/json;charsetUTF-8解析前先判断body里有没有choices没有就取error.message返回避免直接 NPE。5. 进阶玩法换模型、加流式、做验证把基础对话跑通之后这个工程还有不少可挖的地方既能提升毕设的完成度也能让你真正理解大模型接入的工程细节。5.1 一行配置切换模型供应商因为请求走的是 OpenAI 兼容协议切换供应商基本只改application.yml里的base-url和model-name。比如换成国内某个兼容接口把base-url指向对方地址、model-name填对方支持的模型名即可代码一行不用动。这也是我建议手写 HTTP 而不是绑死某家 SDK 的原因——大模型生态变化快协议兼容比 SDK 绑定更抗折腾。切换后记得重新验证一次 key 和模型名不同供应商对模型名的写法不完全一致。5.2 流式输出让回复像打字一样出来非流式接口要等模型全部生成完才返回体验上像卡住。改成流式SSE后回复会逐字吐出。核心改动是把请求体里的stream设为true后端用SseEmitter把模型返回的分块数据转发给前端。下面是一个简化骨架GetMapping(/stream) public SseEmitter stream(RequestParam String sessionId, RequestParam String content) { SseEmitter emitter new SseEmitter(0L); // 0 表示不超时 // 异步线程里调用模型流式接口逐块 emitter.send(...) executor.execute(() - { try { // 请求体加 stream: true逐行读取响应 // 每读到一块 delta 内容就 send 出去 emitter.send(SseEmitter.event().data(片段内容)); emitter.complete(); } catch (Exception e) { emitter.completeWithError(e); } }); return emitter; }逻辑说明SseEmitter是 Spring 对 SSE 的封装0L表示不主动超时。模型流式响应是分块的每块里choices[0].delta.content才是增量文本要逐块解析后send。参数上注意前端要用EventSource接收且这个接口是 GET和普通 POST 对话接口分开。流式改造的坑在于异常处理一旦中途出错要completeWithError否则连接一直挂着。5.3 怎么验证这套东西真的能用验证分三层别只测「能回一句话」就完事。第一层单接口验证用 Postman 或curl直接打/api/chat/send确认返回结构正确。第二层多轮验证连续发三条相关消息看机器人是否记得上下文比如先问「我叫什么」再告诉它名字最后问「我叫什么」。第三层异常验证故意填错 key、断网、发空消息看返回是否友好、日志是否清晰。这三层走完基本能覆盖答辩时老师可能问的场景。# 单接口验证示例 curl -X POST http://localhost:8080/api/chat/send \ -H Content-Type: application/json;charsetUTF-8 \ -d {sessionId:test-001,content:你好介绍一下你自己}逻辑说明sessionId固定成test-001方便连续多次调用验证上下文Content-Type带上charset避免中文乱码。跑通这条命令说明从 Controller 到模型的整条链路是通的剩下的就是前端对接和功能扩展了。从那以后我每次拿到这类模型接入工程都强制先跑一遍「单接口 → 多轮 → 异常」三层验证再动任何业务代码因为环境问题永远比逻辑问题更耗时间。希望这份拆解能帮到你把这份 Spring Boot 人工智能机器人真正用起来、改出自己的东西。本文还有配套的精品资源点击获取