Spring AI 2.0 是目前 Java 后端接入大模型最直接的一条路径。这次我们不聊理论概念直接手写一个类似 Claude Code 的代码生成助手你在接口里丢一句“帮我生成一个 User 模块的 CRUD”它自己拆解需求、读取项目结构、编写 Java 文件、执行 Maven 编译验证一套流程跑完。对 Java 后端团队来说这比在终端里折腾各种 Python Agent 框架要顺得多因为整个服务可以作为一个 Spring Boot 应用直接集成进现有工程。这个项目的核心不是引入一个新的重型框架而是把 Spring AI 2.0 的 Agent 能力组合成一个可运行、可扩展的代码生成服务。最值得关注的几个点一是支持通过 OpenAI 协议兼容的模型服务接入例如 DeepSeek、OpenAI 等只要配置 base-url 和 api-key 就能切换二是通过 Tool Calling 让模型真正操作文件系统而不是只输出一段 Markdown 代码三是不依赖本地 GPU服务本身是纯 Java 进程部署成本很低四是自带 REST API可以接到自己的管理后台、IDE 插件或批量任务系统里。本文会带读者做四件事搭建一个 Spring AI 2.0 项目、配置模型服务、实现一个带工具调用的代码生成 Agent、通过接口和批量任务验证效果。同时会补充排查清单和工程化建议。这篇文章适合正在学习 Spring AI 的 Java 后端工程师也适合想在公司内部快速搭一个 AI 代码辅助工具但不想引入过多外部依赖的团队。1. 核心能力速览能力项说明项目类型基于 Spring Boot Spring AI 2.0 的 Java Agent 应用技术栈Java 17/21、Spring Boot 3.x、Spring AI 2.0、OpenAI 协议兼容模型 API核心功能对话式代码生成、工具调用读取目录、写文件、执行 Maven 命令、批量生成模型接入通过 OpenAI 协议兼容端点接入如 DeepSeek、OpenAI、通义、Kimi 等按服务商配置切换硬件要求CPU 即可无强 GPU 依赖项目服务不占用显存云模型 API 的硬件由服务商承担启动方式Spring Boot 标准启动可打包成 jar 运行接口能力提供 REST API支持 POST 请求生成代码批量任务支持可基于线程池与任务状态表实现需求列表批量生成显存占用不涉及本地模型推理时基本无显存需求若接本地模型服务显存由该服务决定适合场景Java 后端团队内部工具、CRUD 代码生成、项目脚手架、接口文档转 DTO、批量重构辅助这里的显存、硬件参数需要强调一下如果只是调用云端模型 API那么本项目服务端就是一个常规 Spring Boot 应用内存和 CPU 消耗主要来自 JVM 和并发任务数量如果你选择接入本地 vLLM、Ollama 等模型服务显存占用取决于模型本身与 Spring AI 这一层代码无关。2. Spring AI 2.0 Agent 能做什么Spring AI 2.0 的 Agent 能力简单说就是让大模型在 Java 应用里具备“感知 - 决策 - 行动 - 验证”的闭环能力。传统的大模型调用是“输入一段话输出一段文字”而 Agent 化之后模型可以调用注册好的 Java 工具比如读取某个目录下的文件、创建新文件、执行编译命令然后根据工具返回结果继续决策直到完成整个任务。对照 Claude Code 的模式来理解最直观。Claude Code 是一个终端里的 AI 编程助手用户用自然语言描述需求它会自己查看项目结构、修改文件、运行命令最后交付改动。我们基于 Spring AI 2.0 做的是一个类似的“代码生成 Agent”但形态是 Java 服务可以嵌入到自己团队的代码生成平台、CI 流水线或低代码系统里。Spring AI 2.0 提供给开发者的关键能力包括ChatClient 负责与大模型交互Tool 注解和 ToolCallback 负责把 Java 方法暴露给模型调用ChatMemory 负责保留多轮对话上下文Advisor 负责对请求和响应做统一处理。这套组合几乎就是为 Agent 场景设计的比自己在 Java 里手工拼接消息历史、解析函数调用要省太多事。还需要说明的是Agent 不是一个开箱即用的黑盒它依赖三样东西的配合模型本身是否支持 Tool Calling这是当前主流模型基本都具备的能力工具定义是否清晰模型需要根据工具描述决定调用哪个方法系统提示词是否把流程说清楚模型需要知道什么时候该读目录、什么时候该写文件、什么时候该执行编译命令。这三块在后面的实现代码里都会覆盖。3. 适用场景与使用边界这个代码生成助手适合什么场景首先是重复性代码生成比如根据表结构生成 Entity、Mapper、Service、Controller 这一套标准 CRUD其次是项目脚手架搭建让 Agent 生成 pom.xml、application.yml、主启动类然后是接口文档转代码把接口字段描述成自然语言让 Agent 输出对应的 DTO 和参数校验最后是批量任务比如一次性给 Agent 提交 10 个模块的需求逐个生成后集中评审。不适合什么场景第一不适合让 Agent 直接操作生产数据库。工具调用里如果包含 SQL 执行能力风险非常高建议只开放文件读写和编译命令。第二不适合让 Agent 修改核心业务代码后直接上线。模型生成的代码可能存在逻辑漏洞、安全问题或性能隐患必须经过人工代码评审和自动化测试。第三不适合把公司私有代码不加过滤地发送给云端模型 API这是数据合规问题接入前需要和团队确认。合规边界要单独强调。如果模型服务是云端 API送入模型的内容会离开本地环境涉及敏感业务逻辑、内部系统设计、个人隐私数据时需要做脱敏或改用私有化部署模型。生成代码本身也可能涉及开源许可证和版权问题使用前建议确认模型训练数据来源并在交付前做代码扫描。涉及工具执行命令只放白名单命令禁止直接拼装用户输入的 shell 语句。4. 环境准备与前置条件在开始写代码之前先把环境检查一遍。这个项目不依赖本地 GPU主要适配 Java 后端开发环境整体门槛比本地跑大模型低很多。JDK 17 及以上推荐 JDK 21。Spring Boot 3.x 和 Spring AI 2.0 对 JDK 21 的支持更好ZGC 在低延迟场景也有优势。Maven 3.8 或以上版本用来拉取依赖和打包。Spring Boot 3.3 或以上版本具体版本以 Spring AI 2.0 兼容列表为准。Spring AI 2.0 依赖通过 Maven 中央仓库解析如果遇到仓库解析问题检查是否需要配置 Spring 官方仓库。一个支持 OpenAI 协议兼容的模型 API。DeepSeek 是常见选择配置 base-url 为官方兼容地址填 api-key也可以用 OpenAI、通义、Kimi 等服务商。IntelliJ IDEA 或任意 Java IDE建议开启 Lombok 插件后续示例里会用到简化代码。磁盘空间主要看生成代码量和日志普通项目预留 5GB 以上即可。端口默认 8080如果本机被占用启动前检查或改配置。关于版本问题需要提醒一点Spring AI 的版本更新比较快工具注册、注解包名、属性配置在不同小版本之间可能有调整。本文的示例基于 2.0 的通用 API 编写如果你拉到的版本不同优先看官方文档中当前版本对应的写法不要照抄一个过时的配置。5. 项目搭建与依赖配置先创建一个 Spring Boot 项目。可以直接在 start.spring.io 上选择 Web、Actuator 两个依赖也可以手动创建 Maven 工程。为了接入 Spring AI 2.0需要在 pom.xml 里引入 spring-ai-bom 做依赖版本管理再引入 Spring AI 的 OpenAI 协议 starter。?xml version1.0 encodingUTF-8? project xmlnshttp://maven.apache.org/POM/4.0.0 xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd modelVersion4.0.0/modelVersion parent groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-parent/artifactId version3.4.5/version relativePath/ /parent groupIdcom.example/groupId artifactIdspring-ai-code-agent/artifactId version1.0.0/version properties java.version21/java.version spring-ai.version2.0.0/spring-ai.version /properties dependencyManagement dependencies dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-bom/artifactId version${spring-ai.version}/version typepom/type scopeimport/scope /dependency /dependencies /dependencyManagement dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-actuator/artifactId /dependency dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-model-openai/artifactId /dependency /dependencies /project这个 pom 里的 spring-ai.version 是示例版本号实际构建时以 Maven 仓库里能够拉取到的正式版为准。如果依赖解析失败先确认 Spring AI 的 BOM 是否在默认仓库可访问必要时按官方文档配置对应仓库。接着写 application.yml。这里用 Spring AI 的 openai 协议 starter 兼容 DeepSeek 等模型服务核心是配置 base-url、api-key 和 model 名称。server: port: 8080 spring: application: name: spring-ai-code-agent ai: openai: base-url: ${LLM_BASE_URL:https://api.deepseek.com} api-key: ${LLM_API_KEY:} chat: options: model: ${LLM_MODEL:deepseek-chat} temperature: 0.2 max-tokens: 8192 management: endpoints: web: exposure: include: health,info,metricsapi-key 用环境变量注入不要硬编码到配置文件里。model 名称必须和服务商支持的模型名完全一致比如 DeepSeek 官方接口支持的 deepseek-chat 和 deepseek-reasoner写错任何一个单词都会在调用时报模型不识别。6. 核心实现手写 Claude Code 风格代码生成助手现在进入核心部分。我们要做一个代码生成 Agent它需要具备三个工具读取项目目录结构、写入文件、执行 Maven 编译命令。模型根据用户需求决定调用哪个工具工具返回结果后模型继续决策直到任务完成。首先定义一个请求对象。public record GenerateRequest(String task) { }然后是核心的 Agent 服务。这里使用 ChatClient 构建一个带有系统提示词和默认工具的对话客户端。系统提示词要明确告诉模型它有哪些能力、每一步应该怎么执行、什么情况下需要调用工具。package com.example.codeagent; import org.springframework.ai.chat.client.ChatClient; import org.springframework.stereotype.Service; Service public class CodeAgentService { private final ChatClient chatClient; public CodeAgentService(ChatClient.Builder builder, CodeTools codeTools) { this.chatClient builder .defaultSystem( 你是一个运行在 Java 后端的代码生成助手工作方式类似 Claude Code。 你有以下能力 1. 读取项目目录结构了解现有代码组织方式。 2. 创建或修改文件生成完整代码。 3. 执行 Maven 编译命令验证代码。 执行任务的流程 1. 先读取项目结构确认代码放置位置。 2. 拆解用户需求生成需要的文件清单。 3. 逐个文件写入内容必须完整不允许输出省略号。 4. 写入完成后执行 mvn -q compile 验证。 5. 如果编译失败分析输出并修复后再验证。 ) .defaultTools(codeTools) .build(); } public String generate(String task) { return chatClient.prompt() .user(task) .call() .content(); } }接下来是工具类。Spring AI 通过 Tool 注解把 Java 方法暴露给模型方法名和描述会被模型拿来判断调用时机。工具方法的参数需要使用 ToolParam 注解说明含义这样模型才知道该传什么值。package com.example.codeagent; import org.springframework.ai.tool.annotation.Tool; import org.springframework.ai.tool.annotation.ToolParam; import org.springframework.stereotype.Component; import java.io.IOException; import java.nio.file.Files; import java.nio.file.Path; import java.nio.file.Paths; Component public class CodeTools { private static final Path WORKSPACE Paths.get(.).toAbsolutePath().normalize(); Tool(description 读取项目目录结构返回文件树文本。参数 baseDir 是项目根目录默认用当前工作区。) public String readProjectStructure( ToolParam(description 要扫描的项目根目录路径) String baseDir) { Path root resolveSafe(baseDir); try (var stream Files.walk(root)) { StringBuilder sb new StringBuilder(); stream.filter(Files::isRegularFile) .filter(p - !p.toString().contains(target) !p.toString().contains(.git) !p.toString().contains(.idea)) .limit(200) .forEach(p - sb.append(root.relativize(p)).append(\n)); return sb.toString(); } catch (IOException e) { return 读取目录失败: e.getMessage(); } } Tool(description 将完整代码内容写入到指定文件。path 是相对于项目根目录的路径content 是完整文件内容。) public String writeFile( ToolParam(description 文件相对路径例如 src/main/java/com/example/UserController.java) String path, ToolParam(description 完整文件内容) String content) { Path target resolveSafe(path); try { Files.createDirectories(target.getParent()); Files.writeString(target, content); return 写入成功: target; } catch (IOException e) { return 写入失败: e.getMessage(); } } Tool(description 执行 Maven 编译验证命令仅允许白名单命令。) public String executeMavenCommand( ToolParam(description 执行命令例如 mvn -q compile) String command) { if (!command.startsWith(mvn -q compile) !command.startsWith(mvn -v)) { return 命令不在白名单内仅允许执行 mvn -q compile 和 mvn -v; } try { Process process new ProcessBuilder(command.split( )) .directory(WORKSPACE.toFile()) .redirectErrorStream(true) .start(); String output new String(process.getInputStream().readAllBytes()); int exitCode process.waitFor(); return 退出码: exitCode \n输出:\n output; } catch (Exception e) { return 命令执行失败: e.getMessage(); } } private Path resolveSafe(String relativePath) { Path resolved WORKSPACE.resolve(relativePath).normalize(); if (!resolved.startsWith(WORKSPACE)) { throw new IllegalArgumentException(路径超出工作区范围不允许访问); } return resolved; } }这里有两个关键点。一是路径校验任何从模型传进来的路径都要 normalize 后做前缀检查防止 Agent 被提示词注入后把文件写到工作区之外。二是命令白名单不要直接执行模型拼接的 shell而是只放行预定义的 Maven 编译和版本查看命令这样能最大程度降低风险。最后暴露一个 REST 接口。package com.example.codeagent; import org.springframework.web.bind.annotation.PostMapping; import org.springframework.web.bind.annotation.RequestBody; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RestController; import java.util.Map; RestController RequestMapping(/api/agent) public class AgentController { private final CodeAgentService codeAgentService; public AgentController(CodeAgentService codeAgentService) { this.codeAgentService codeAgentService; } PostMapping(/generate) public MapString, String generate(RequestBody GenerateRequest request) { String result codeAgentService.generate(request.task()); return Map.of( task, request.task(), result, result ); } }到这里一个最小可运行的代码生成 Agent 就完成了。启动 Spring Boot 应用然后向接口提交任务Agent 会尝试读取目录、写文件、执行编译。这个过程在日志里可以看到模型对工具的真实调用记录如果工具调用失败模型通常也会主动修复。7. 功能测试与效果验证代码写完只是第一步关键是验证 Agent 是否真的能完成端到端任务。我建议从单文件生成、多文件脚手架、工具调用、编译验证四个维度依次测试。7.1 单文件生成测试提交任务“生成一个 UserController包含新增、删除、修改、查询四个接口返回 JSON 格式数据。”预期结果是模型直接调用 writeFile 工具写入 UserController.java内容包含四个接口方法。判断成功的标准文件真正落盘代码结构完整无占位符省略。常见失败情况模型只输出代码文本而没有调用工具原因通常是系统提示词没有强调“必须使用工具写入文件”或者模型版本不支持 Tool Calling。解决方式是强化提示词或者换用支持工具调用的模型。7.2 多文件项目骨架测试提交任务“在当前工作区生成一个 Spring Boot 项目骨架包含 pom.xml、application.yml、主启动类和 UserController包名用 com.example.demo。”预期结果是 Agent 连续调用多次 writeFile生成多个文件。这个测试能验证 Agent 的多步规划能力。如果模型只生成一个文件就停下说明它在长任务执行中丢失了计划可以在系统提示词里要求“先列出文件清单然后逐个写入每写一个文件就确认一次进度”。7.3 工具调用触发测试提交任务“先看一下当前项目的目录结构然后创建一个 README.md把目录里的 Java 文件列表写进去。”这个任务强制要求模型先调用 readProjectStructure再调用 writeFile。判断成功的标准是日志中出现两次工具调用并且 README.md 内容包含真实的文件列表。如果模型直接输出文件列表而没有实际写入说明工具调用的触发策略没有生效。7.4 编译验证测试提交任务“生成一个 UserController然后执行 Maven 编译验证如果编译失败就修复代码。包名用 com.example.demo只依赖 Spring Web。”这个测试最能体现 Agent 的价值。模型写完代码后应主动调用 executeMavenCommand 执行编译命令如果编译失败根据报错信息修改代码再重新编译。判断成功的标准是最后一次编译退出码为 0。实际使用中这个环节最容易暴露两个问题一是模型生成的代码缺少 import 或方法签名错误导致编译失败二是模型修复代码时陷入重复错误多次生成同样的问题代码。解决方法是把编译输出注入到上下文里并要求模型“仔细阅读编译错误中的行号和信息定位根因后再修改”。7.5 输出质量抽查代码生成完成后建议人工抽查三点接口返回结构是否统一、异常处理后是否规范、是否有明显的安全漏洞。比如生成的 Controller 是否直接拼 SQL、是否对请求参数做校验、是否把内部异常直接抛给前端。Agent 生成的代码可以作为初稿但不能跳过代码评审。8. 接口 API 与批量任务Agent 服务本身就是 Spring Boot 应用天然适合通过 REST API 对外提供能力。单个任务调用是基础能力更实用的是批量任务。先看单个任务调用示例。启动服务后用 curl 请求curl -X POST http://localhost:8080/api/agent/generate \ -H Content-Type: application/json \ -d {task:生成一个 User 模块的 CRUD 代码包含实体、Mapper、Service、Controller包名 com.example.user}返回结果是一个 JSON 对象包含原始任务和模型最终生成的文本。如果 Agent 真的调用了工具结果中会包含工具调用后的总结文本文件也已经写到了工作区。Python 调用同样简单import requests import json url http://localhost:8080/api/agent/generate payload { task: 生成一个 Order 模块的 CRUD 代码包含实体、Mapper、Service、Controller包名 com.example.order } response requests.post(url, jsonpayload, timeout300) data response.json() print(json.dumps(data, ensure_asciiFalse, indent2))批量任务场景需要单独设计。最直接的做法是提交一个需求列表每个需求对应一个生成任务服务端用线程池并发处理同时记录每个任务的状态。这里给一个简化实现package com.example.codeagent; import org.springframework.stereotype.Service; import java.util.Map; import java.util.concurrent.*; Service public class BatchCodeGenService { private final CodeAgentService codeAgentService; private final ExecutorService pool Executors.newFixedThreadPool(4); private final MapString, FutureString tasks new ConcurrentHashMap(); public BatchCodeGenService(CodeAgentService codeAgentService) { this.codeAgentService codeAgentService; } public String submit(String taskId, String task) { FutureString future pool.submit(() - codeAgentService.generate(task)); tasks.put(taskId, future); return taskId; } public boolean isDone(String taskId) { FutureString future tasks.get(taskId); return future ! null future.isDone(); } public String getResult(String taskId) throws Exception { return tasks.get(taskId).get(); } }批量任务输入可以设计成 JSON 数组[ { taskId: user-module, task: 生成 User 模块 CRUD包名 com.example.user }, { taskId: order-module, task: 生成 Order 模块 CRUD包名 com.example.order }, { taskId: readme, task: 根据项目现状生成 README.md说明模块结构 } ]批量任务要注意三个工程问题一是任务幂等性同一个 taskId 重复提交时不要重复执行二是失败重试模型调 API 可能因为超时、限流失败需要设计重试次数三是日志持久化建议把每个任务的请求、工具调用记录、最终输出写入文件或数据库方便事后排查。9. 资源占用与性能观察这个 Agent 服务本身不加载模型权重所以资源占用核心在 JVM 和模型 API 调用上。通过 Actuator 的 health、metrics 端点可以观察内存和线程状态curl http://localhost:8080/actuator/health curl http://localhost:8080/actuator/metrics/jvm.memory.used如果使用 jconsole 或 jcmd 连接进程可以看到堆内存、GC 频率、活跃线程数。并发任务越多线程池占用和内存峰值都会上涨所以线程池大小和任务队列长度要提前设计。影响性能的关键因素有这么几个。第一是模型 API 的响应延迟这是大头模型生成 token 的速度直接决定单任务耗时。第二是工具调用次数一个任务如果反复修改代码、反复编译耗时会成倍增加。第三是上下文长度任务描述越长、工具返回的目录树和编译日志越大模型每次推理处理的时间就越长。第四是并发数大量并发请求会同时占用线程和内存。常见的调优思路是控制上下文。比如读取项目目录时限制文件数量不超过 200编译命令使用 -q 参数减少输出给工具返回内容设置最大长度避免日志刷爆上下文对批量任务设置固定线程池避免无限并发把 JVM 内存打满。如果你的 Spring AI 应用部署在容器里JVM 堆大小需要合理设置。项目启动参数可以加java -Xmx2g -jar spring-ai-code-agent-1.0.0.jar如果遇到 OOM优先检查堆大小和并发线程数其次检查是否在日志里保存了过大的模型响应。10. 常见问题与排查方法问题现象可能原因排查方式解决方案Spring AI 连接模型后不输出 content接口返回为空模型返回了空 content或响应中只有 reasoning_content也可能 model 名称配置错误打开日志查看模型原始响应 JSON确认 content 字段是否为空检查模型名确认模型名与服务商文档一致调整 temperature查看官方依赖版本对响应字段的映射方式工具调用一直没有触发模型只返回纯文本系统提示词未强调必须使用工具模型不支持 Tool Calling工具描述不清晰查看日志中是否有 tool_calls 字段换一个支持工具调用的模型强化系统提示词使用 Tool 注解时把描述写清楚确认模型 API 开启 function calling模型名不识别报 model is not recognized 之类错误model 参数写错或服务商未提供该模型核对服务商支持模型列表改用官方支持的模型名例如 deepseek-chatAgent 任务执行超时模型 API 响应慢或工具调用链太长导致单任务耗时超时查看任务耗时日志统计工具调用次数加长 HTTP 超时时间减少无效工具调用拆分大任务为小任务Java 进程报 OutOfMemoryErrorJVM 堆过小或并发任务太多查看 GC 日志和堆占用检查线程池配置增大 -Xmx减小线程池限制单次任务上下文长度lombok 编译报错提示编译器版本不支持Lombok 版本与 JDK 版本不匹配检查编译日志中的 Lombok 版本提示升级 Lombok 依赖版本或调整 IDEA Lombok 插件设置端口被占用服务启动失败8080 被其他进程占用netstat -ano | findstr 8080或lsof -i:8080修改 server.port 或释放端口生成的代码写到了错误目录模型传入的路径参数不合理查看工具调用参数日志约束路径前缀读写工具统一做 normalize 校验补充一个很常见的坑DeepSeek 的 deepseek-reasoner 模型会先输出 reasoning_content再输出 content。如果代码里只读取 content 字段在某些中间版本中可能拿到空值。处理办法是先看原始响应结构确认字段名再决定使用该模型的对话接口还是推理接口如果业务场景是代码生成建议优先使用 deepseek-chat响应速度更快content 字段也更稳定。11. 最佳实践与使用建议第一次运行时建议先用最小任务验证链路比如只生成一个 UserController观察日志中模型是否调用了工具、文件是否真正落盘再逐渐加大任务复杂度。这样可以快速定位是模型配置问题、提示词问题还是工具注册问题。保留一套最小可运行配置非常关键。把 pom.xml、application.yml、CodeTools、CodeAgentService 这些代码提交到 Git 仓库作为团队后续扩展的基线。模型服务商的 API Key 用环境变量管理不要在配置文件里写死更不要提交到仓库。工具边界和安全要提前定义。文件读写工具必须限制在项目工作区目录内命令执行工具只放白名单命令不开放任意 shell。代码生成助手是辅助工具不是免审通道所有生成的代码必须经过编译验证和人工评审。对于批量任务建议增加任务状态表和持久化日志。每个任务记录提交时间、状态、模型响应摘要、工具调用列表、输出文件列表。任务失败时支持重试重试要做幂等处理避免同一个文件被重复写入或覆盖。如果接入云端模型涉及公司私有代码时要谨慎。可以先做敏感信息脱敏或者使用私有化部署的模型服务。项目内部可以定义一条规则包含密钥、内部 IP、个人信息的内容不允许作为代码生成任务的输入。多 Agent 协作是下一步可以考虑的方向。比如一个 Agent 负责生成 Controller一个负责生成 Service一个负责写测试用例主 Agent 负责汇总和编译验证。Spring AI 2.0 的 ChatClient 和工具机制可以组合出这种多角色工作流相比单 Agent 长链路任务拆分后稳定性和可观测性都更好。12. 总结与下一步这个基于 Spring AI 2.0 的代码生成 Agent最值得尝试的点在于它把自然语言和 Java 工程操作真正打通了。模型不再是“给一段参考代码”而是能读取项目结构、落盘文件、执行编译并迭代修复这和 Claude Code 的使用体验已经非常接近但跑在 Java 生态里集成成本低得多。建议你最先验证两个功能一是单文件生成后是否真的写入磁盘二是模型能否根据编译错误自动修复代码。这两点跑通基本就证明 Agent 的“规划-执行-验证”链路是正常的。最容易踩的坑集中在模型名称配置错误、工具调用未触发、路径没有做安全校验这三个地方排查时可以优先看日志中的原始模型响应。后续扩展方向很明确把 Agent 接入团队内部代码库让它可以搜索现有代码再生成新模块接入 CI 流水线在提交代码后自动生成改动说明或测试用例做成多 Agent 协作系统由不同 Agent 分别负责检索、生成、测试和文档。先把最小闭环跑起来再逐步加能力这是最稳的推进方式。