Java工程师转型AI Agent：用Spring Boot和LangChain4j落地生产级应用

1. 为什么一个写了十年 Spring 的 Java 工程师，突然开始重写自己的简历？

我上周和一位在某支付公司带后端团队的同事吃饭，他掏出手机给我看刚改完的简历——“Java 高级工程师”头衔旁边，赫然加了一行小字：“具备 LangChain4j 实战经验，主导落地 2 个生产级 AI Agent 场景”。他没提 JVM 调优，没写 Redis 分布式锁，而是花了半页纸讲清楚“如何用 Spring Boot 拦截器 + ReAct 模式 + 自定义 Tool 链，把原有订单履约服务包装成可被 LLM 调度的原子能力”。

这不是蹭热点。是真实发生的岗位需求迁移。

过去三年，我参与过 7 个 Java 团队的招聘面试，其中 5 个团队在 JD 里明确要求“熟悉 AI Agent 架构”或“有 LangChain4j/LLM 集成经验”。不是加分项，是硬门槛。更关键的是，这些岗位薪资带宽比纯 Java 后端高 35%~60%，且多数不强制要求算法功底，而是看重工程化落地能力——这恰恰是 Java 工程师最擅长的领域。

但问题来了：很多 Java 工程师一看到“Agent”就本能地退缩，觉得要从 Transformer 论文读起、要会 PyTorch 写模型、要懂 RLHF。这是最大的认知偏差。AI Agent 的核心不是“造大脑”，而是“建管道”——把已有的 Java 服务能力，用标准化协议暴露出去，让大模型能像调用 REST API 一样调度它们。LangChain4j 就是这套管道的 Java 语言实现规范，Spring Boot 是它天然的运行容器。

你不需要重学 Python，不需要成为 Prompt 工程师，甚至不需要自己训练模型。你需要的是：理解 ReAct 模式如何拆解任务、掌握 LangChain4j 的 Tool 注册机制、知道如何把 MyBatis 的 Mapper 接口包装成可被 LLM 调用的 Tool、明白 Spring Boot 的 AOP 如何拦截 Agent 的执行链路做审计。这些全是 Java 工程师每天都在做的事，只是换了个名字。

所以这篇不是“从零学 AI”，而是“把你的 Java 功底，精准迁移到 AI Agent 工程战场”。接下来所有内容，都基于一个前提：你熟悉 Spring Boot 的自动配置、MyBatis 的动态 SQL、RestTemplate 的拦截器链、以及 Java 8 的函数式编程。我们只讲这些能力如何复用，不讲新概念堆砌。

2. ReAct 模式：不是魔法，是 Java 工程师熟悉的“状态机+策略模式”

很多人把 ReAct（Reasoning + Acting）当成玄学，其实它就是一套清晰的、可编码的状态流转逻辑。把它翻译成 Java 工程师的语言：一个带条件分支的循环状态机，每个分支触发不同的策略执行器。

先看一个真实场景：用户问“帮我查一下昨天下午三点下单、还没发货的订单，如果金额超过 500 元，自动申请退款”。传统 Java 后端会怎么处理？

• 写一个 Controller → Service → Mapper 链路
• Service 层做业务判断（时间范围 + 发货状态 + 金额阈值）
• 符合条件则调用退款服务

ReAct 做的其实是同一件事，只是把“判断逻辑”和“执行动作”拆得更细，并交给 LLM 动态编排：

[Step 1] Reasoning: 用户意图是查询未发货订单并条件退款 → 需要 OrderQueryTool 和 RefundApplyTool [Step 2] Acting: 调用 OrderQueryTool(createdAtAfter="2024-05-20T15:00:00", status="UNSHIPPED") [Step 3] Reasoning: 返回 3 条订单，其中 ID=1001 金额为 580 元 → 触发 RefundApplyTool(orderId=1001) [Step 4] Acting: 调用 RefundApplyTool(orderId=1001) → 返回 success [Step 5] Reasoning: 所有动作完成 → 生成自然语言回复

这个流程里，每一步的“Reasoning”由 LLM 完成（它决定下一步该调什么 Tool），而每个“Acting”都是 Java 方法调用。LangChain4j 的核心价值，就是把这种状态流转封装成可插拔的组件。

2.1 ReAct 的 Java 实现本质：一个带上下文的 Command 模式

LangChain4j 的ReActExecutor类，本质上就是一个Command接口的集合：

public interface Tool { String name(); // 对应 LLM 的 tool_call 名称 String description(); // LLM 用来理解工具用途的描述 Object execute(ToolExecutionRequest request); // 真正的 Java 方法调用 }

你写的每个Tool，就是一个Command实现类。比如订单查询工具：

@Component public class OrderQueryTool implements Tool { @Autowired private OrderService orderService; @Override public String name() { return "query_orders"; // LLM 在 JSON 中调用时用这个名字 } @Override public String description() { return "根据创建时间范围和状态查询订单。参数：createdAtAfter（ISO8601格式）、status（UNSHIPPED/SHIPPED）"; } @Override public Object execute(ToolExecutionRequest request) { // 这里就是你熟悉的 Spring Service 调用 Map<String, Object> params = request.arguments(); LocalDateTime after = LocalDateTime.parse((String) params.get("createdAtAfter")); String status = (String) params.get("status"); return orderService.findByCreatedAtAfterAndStatus(after, status); } }

注意三个关键点：

1. name()必须是英文小写+下划线，因为 LLM 输出的 JSON 字段名是 snake_case；
2. description()不是给程序员看的，是给 LLM 看的——它要靠这段文字理解“这个工具能干什么”，所以必须包含参数类型、约束、示例值，不能写“查询订单”这种模糊描述；
3. execute()方法里，你调用的就是现有 Service，完全不用改业务逻辑，只是加了一层适配器。

2.2 为什么 ReAct 比单纯 Prompt 更可靠？——状态隔离与错误回滚

单纯用 Prompt 让 LLM 直接生成 SQL 或调用接口，最大的问题是状态不可控。比如 LLM 可能生成：
SELECT * FROM orders WHERE created_at > '2024-05-20 15:00:00' AND status = 'UNSHIPED';
（注意：status 值拼错了）

而 ReAct 模式强制 LLM 先输出结构化 Tool 调用请求（JSON），再由 Java 代码解析执行。这就实现了：

• 参数校验前置：ToolExecutionRequest解析失败直接报错，不会执行错误 SQL；
• 异常隔离：某个 Tool 执行失败（如数据库连接超时），不影响其他 Tool，ReActExecutor 可以捕获异常并返回给 LLM “调用 query_orders 失败，请重试”；
• 审计可追溯：每个 Tool 调用都记录toolName,arguments,startTime,endTime,result，这就是完整的 Agent 行为日志。

我在某电商项目落地时，曾用 AOP 拦截所有 Tool 执行，自动生成调用链路图。当用户投诉“Agent 说查不到订单，但后台明明有”，我们直接回放日志：发现是 LLM 把createdAtAfter参数传成了"2024-05-20T15:00"（缺了秒），导致数据库索引失效。修复方案很简单：在 Tool 的execute方法里加参数校验，而不是去调教 LLM。

提示：不要试图让 LLM 生成完美参数。它的强项是“决策”，弱项是“精确表达”。把参数校验、格式转换、边界处理全部交给 Java 层，这才是工程化思维。

3. LangChain4j：不是新框架，是 Java 工程师的“Spring Boot for LLM”

LangChain4j 的定位非常清晰：它不是要取代 Spring Boot，而是作为 Spring Boot 的一个领域特定扩展。就像 Spring Data JPA 把 JDBC 封装成 Repository，LangChain4j 把 LLM 调用封装成AiServices。

它的核心抽象只有四个，全部对应 Java 工程师的日常概念：

LangChain4j 概念	Java 工程师类比	你已掌握的等价物
AiService	@FeignClient或RestTemplate封装	你调用第三方 HTTP 接口的客户端
Tool	@Service实现类	你写的业务 Service 方法
ChatMemory	HttpSession或RedisTemplate	你存用户会话数据的缓存方案
StreamingResponseHandler	SseEmitter或ResponseBodyEmitter	你做实时消息推送的流式响应

3.1 AiService：用接口定义，代替手写 HTTP 调用

传统方式调用大模型 API（如阿里云百炼、讯飞星火）需要：

• 构造 JSON 请求体
• 设置 Authorization Header
• 用 RestTemplate 发送 POST
• 解析返回的 JSON 字段

LangChain4j 把这个过程变成接口定义：

@AiService public interface CustomerSupportAiService { // 普通同步调用：等完整响应 String chat(@UserMessage String message); // 流式响应：适合客服场景，逐字返回 void chatStream(@UserMessage String message, @SystemMessage String systemPrompt, StreamingResponseHandler<String> handler); // 结构化输出：强制 LLM 返回 JSON，自动映射到 Java 对象 @StructuredOutput OrderRefundRequest generateRefundRequest(@UserMessage String message); }

Spring Boot 启动时，LangChain4j 的AiServiceAutoConfiguration会扫描所有@AiService接口，自动生成代理实现类。你只需要注入使用：

@RestController public class ChatController { @Autowired private CustomerSupportAiService aiService; @PostMapping("/chat") public ResponseEntity<String> chat(@RequestBody ChatRequest request) { String response = aiService.chat(request.getMessage()); return ResponseEntity.ok(response); } }

背后的原理就是动态代理 + 模板引擎：

• @UserMessage注解告诉框架，这个参数要放到messages数组的user角色里；
• @SystemMessage放到system角色；
• @StructuredOutput会在 prompt 里加一段 JSON Schema 描述，要求 LLM 严格按格式输出；
• 所有配置（API Key、Endpoint、Model Name）通过application.yml统一管理。

这和你用@FeignClient调用内部微服务，没有任何区别。唯一新增的学习成本，就是理解@UserMessage这几个注解的语义。

3.2 ChatMemory：用 Spring Cache 机制管理会话状态

LLM 本身无状态，但用户对话需要记忆上下文。LangChain4j 的ChatMemory就是解决这个问题的。它不绑定具体存储，而是提供统一接口：

public interface ChatMemory { List<ChatMessage> getMessages(String sessionId); void addMessage(String sessionId, ChatMessage message); void clear(String sessionId); }

你可以用任何 Spring 支持的缓存实现它。最常用的是InMemoryChatMemory（开发测试）和RedisChatMemory（生产环境）：

@Configuration public class ChatMemoryConfig { @Bean public ChatMemory chatMemory(RedisTemplate<String, Object> redisTemplate) { // 使用 Redis 存储，key 是 sessionId，value 是 ChatMessage 列表 return new RedisChatMemory(redisTemplate, "ai:chat:memory:"); } }

关键细节：

• sessionId通常来自 HTTP Header（如X-User-ID）或 JWT Token，不要用 Cookie，因为 Agent 可能被其他系统调用；
• ChatMessage包含role（user/system/assistant）、content、timestamp，LangChain4j 会自动把最近 N 条消息塞进 prompt；
• 生产环境必须设置 TTL（如 24 小时），避免 Redis 内存爆炸；
• 如果业务要求“跨设备会话连续”，就把sessionId设为用户全局 ID，而不是设备 ID。

我在做跨境商城的智能客服时，发现用户经常在 App 和小程序间切换。解决方案是：登录后生成一个user_session_id存入 Redis，所有端都用这个 ID 作为 ChatMemory 的 key。这样用户在小程序问“我的订单到哪了”，切到 App 后继续问“能加急吗”，Agent 能记住上下文。

注意：不要把敏感信息（如手机号、身份证号）存在 ChatMemory。LangChain4j 的ChatMessage是明文存储的，如果用了 Redis，要确保 Redis 有访问控制。

4. Spring Boot 集成实战：把现有订单服务，30 分钟变成 AI Agent

现在我们动手，把一个典型的 Spring Boot 订单服务，包装成可被 LLM 调度的 AI Agent。假设你已有如下代码：

// OrderController.java @RestController @RequestMapping("/api/orders") public class OrderController { @Autowired private OrderService orderService; @GetMapping("/unshipped") public List<Order> findUnshippedOrders(@RequestParam LocalDateTime createdAtAfter) { return orderService.findByCreatedAtAfterAndStatus(createdAtAfter, "UNSHIPPED"); } @PostMapping("/refund/{orderId}") public Result refundOrder(@PathVariable Long orderId) { return orderService.applyRefund(orderId); } }

4.1 第一步：添加 LangChain4j 依赖（5 分钟）

在pom.xml中加入：

<dependency> <groupId>dev.langchain4j</groupId> <artifactId>langchain4j-spring-boot-starter</artifactId> <version>0.32.0</version> <!-- 用最新稳定版 --> </dependency> <!-- 如果用阿里云百炼，加这个 --> <dependency> <groupId>dev.langchain4j</groupId> <artifactId>langchain4j-alibaba-cloud</artifactId> <version>0.32.0</version> </dependency>

langchain4j-spring-boot-starter会自动配置：

• AiService代理生成器
• 默认的ChatLanguageModel（对接百炼/星火等）
• InMemoryChatMemory（开发环境）
• ToolExecutor（管理所有@ToolBean）

4.2 第二步：定义两个 Tool（10 分钟）

创建OrderQueryTool.java：

@Component public class OrderQueryTool implements Tool { @Autowired private OrderService orderService; @Override public String name() { return "query_unshipped_orders"; } @Override public String description() { return "查询未发货订单。参数：createdAtAfter（ISO8601格式，如 '2024-05-20T15:00:00'），必须包含秒。"; } @Override public Object execute(ToolExecutionRequest request) { try { Map<String, Object> args = request.arguments(); String timeStr = (String) args.get("createdAtAfter"); // 强制校验格式，避免 LLM 传错 LocalDateTime time = LocalDateTime.parse(timeStr, DateTimeFormatter.ISO_LOCAL_DATE_TIME); return orderService.findByCreatedAtAfterAndStatus(time, "UNSHIPPED"); } catch (DateTimeParseException e) { throw new IllegalArgumentException("createdAtAfter 格式错误，必须为 ISO8601（如 '2024-05-20T15:00:00'）"); } } }

创建RefundApplyTool.java：

@Component public class RefundApplyTool implements Tool { @Autowired private OrderService orderService; @Override public String name() { return "apply_refund"; } @Override public String description() { return "为指定订单申请退款。参数：orderId（Long 类型订单ID）"; } @Override public Object execute(ToolExecutionRequest request) { Map<String, Object> args = request.arguments(); Long orderId = ((Number) args.get("orderId")).longValue(); // 加业务校验：只能退未发货订单 Order order = orderService.findById(orderId); if (!"UNSHIPPED".equals(order.getStatus())) { throw new IllegalStateException("订单状态为 " + order.getStatus() + "，无法退款"); } return orderService.applyRefund(orderId); } }

4.3 第三步：创建 AiService 接口（5 分钟）

@AiService public interface OrderAssistantAiService { @SystemMessage("你是一个电商客服助手，只能使用提供的工具查询订单和申请退款。不要编造信息。") String chat(@UserMessage String message); }

4.4 第四步：编写 Agent Controller（10 分钟）

@RestController @RequestMapping("/api/agent") public class AgentController { @Autowired private OrderAssistantAiService aiService; @Autowired private ChatMemory chatMemory; @PostMapping("/chat") public ResponseEntity<Map<String, Object>> chat( @RequestHeader("X-User-ID") String userId, @RequestBody AgentRequest request) { // 设置会话 ID，让 ChatMemory 能找到上下文 String sessionId = "user:" + userId; // 构建带 Tool 的 AiService（每次请求都新建，避免状态污染） OrderAssistantAiService service = AiServices.builder(OrderAssistantAiService.class) .chatLanguageModel(chatLanguageModel()) // 从配置读取 .chatMemory(chatMemory) .tools(List.of( new OrderQueryTool(), new RefundApplyTool() )) .build(); // 执行对话 String response = service.chat(request.getMessage()); // 返回结构化结果 Map<String, Object> result = new HashMap<>(); result.put("response", response); result.put("sessionId", sessionId); return ResponseEntity.ok(result); } }

4.5 关键配置（application.yml）

# LangChain4j 配置 langchain4j: # 对接阿里云百炼 alibaba-cloud: api-key: ${ALIYUN_API_KEY:your-api-key} region-id: cn-shanghai endpoint: https://dashscope.aliyuncs.com/api/v1/services/aigc/text-generation/generation model-name: qwen-max # 或 qwen-plus # 全局 ChatMemory 配置 chat-memory: redis: enabled: true key-prefix: "ai:chat:" time-to-live: 86400 # 24小时 # Spring Boot 通用配置 spring: redis: host: localhost port: 6379 password:

启动应用，用 curl 测试：

curl -X POST http://localhost:8080/api/agent/chat \ -H "X-User-ID: user_123" \ -H "Content-Type: application/json" \ -d '{"message":"帮我查一下今天下午三点之后下的未发货订单"}'

你会看到 LLM 先调用query_unshipped_orders，拿到订单列表后，再问“是否需要为这些订单退款？”，整个过程完全自动化。

5. 生产级避坑指南：Java 工程师最容易踩的 5 个 Agent 坑

落地 AI Agent 最大的风险，不是技术不行，而是用 Java 工程师的惯性思维去套用新范式。以下是我在 3 个项目中踩过的、血泪总结的坑：

5.1 坑一：把 Tool 当 Controller 写，忽略 LLM 的“理解成本”

错误写法：

@Override public String description() { return "查询订单"; }

后果：LLM 经常调错工具。比如用户问“查昨天的订单”，LLM 可能调用query_unshipped_orders，也可能调用query_all_orders，因为它分不清“未发货”和“所有”的区别。

正确写法：

@Override public String description() { return "仅查询状态为 UNSHIPPED（未发货）的订单。必须提供 createdAtAfter 参数（ISO8601 格式），例如 '2024-05-20T15:00:00'。不支持查询已发货或已完成的订单。"; }

原理：LLM 的“理解”基于文本相似度，不是逻辑推理。描述越具体、约束越明确、示例越直观，LLM 调用准确率越高。建议每条 description 都包含：

• 作用范围限定词（“仅”、“必须”、“不支持”）
• 参数格式示例（ISO8601、UUID、数字范围）
• 业务规则说明（“只能退未发货订单”、“需用户实名认证后才可调用”）

5.2 坑二：用 @Async 或线程池处理 Tool，导致上下文丢失

错误写法：

@Override public Object execute(ToolExecutionRequest request) { // 异步执行，以为能提高性能 CompletableFuture.supplyAsync(() -> orderService.findByCreatedAtAfterAndStatus(...)); return "task_submitted"; }

后果：ReActExecutor 等不到实际结果，直接报错“Tool 返回 null”。因为execute()方法必须同步返回结果，LLM 需要这个结果来决定下一步。

正确做法：

• Tool 必须是同步阻塞调用；
• 如果后端服务慢，就在orderService层加超时（如@TimeLimiter）；
• 真正的异步场景（如发邮件、发短信），应该用@EventListener或 MQ，Tool 只负责触发，不等待结果。

5.3 坑三：把 ChatMemory 当数据库，存业务关键数据

错误写法：

// 在 Tool 里把订单详情存进 ChatMemory chatMemory.addMessage(sessionId, new AiMessage("订单ID: 1001, 商品: iPhone, 金额: 5800"));

后果：ChatMemory 是临时上下文缓存，不是持久化存储。重启服务或 Redis 清空后，数据全丢。更严重的是，LLM 可能从 ChatMemory 里“幻觉”出不存在的订单。

正确边界：

• ChatMemory 只存ChatMessage（role/content/timestamp），用于构建 prompt 上下文；
• 业务数据永远走 MySQL/Oracle；
• 如果需要“记忆用户偏好”，用独立的user_preference表，不要混在 ChatMemory。

5.4 坑四：忽略 Token 限制，导致长文本截断

错误现象：用户输入很长的售后描述（>2000 字），Agent 回复“抱歉，我无法理解您的问题”。

原因：大模型有输入 Token 限制（Qwen-Max 是 8192，但实际可用约 7500）。LangChain4j 默认把整个 ChatHistory + 新消息塞进去，很容易超限。

解决方案：

• 在AiService配置里启用maxTokens限制：

  @AiService(maxTokens = 4000) // 控制总输入长度

• 对长文本做摘要预处理：用另一个轻量模型（如bge-reranker-base）提取关键句；
• 最简单有效的方法：在 Controller 层截断用户输入：

  if (message.length() > 1000) { message = message.substring(0, 1000) + "...（内容过长，已截断）"; }

5.5 坑五：用 DevTools 热部署改 Tool，导致 ReActExecutor 缓存失效

错误操作：开发时用 IDEA 的 HotSwap 修改OrderQueryTool的description()，期望 LLM 立即理解新描述。

后果：ReActExecutor在启动时就把所有 Tool 的name()和description()缓存到内存，热部署不会刷新这个缓存。LLM 依然按旧描述理解工具。

正确做法：

• 开发阶段，每次改description()都要重启应用；
• 生产环境，Tool 的description()必须走配置中心（如 Nacos），支持动态更新；
• 我们最终方案：把所有 Tool 描述存数据库，Tool实现类从 DB 读取description，这样改描述不用发版。

6. 进阶架构：如何让 Agent 支持多租户、灰度发布和熔断降级

单体 Agent 只能玩 demo。真实业务需要企业级能力。以下是我在某 SaaS 平台落地的方案，全部基于 Spring Boot 原生能力：

6.1 多租户隔离：用 TenantId 路由 ChatMemory 和 Tool

SaaS 客户要求数据隔离。不能让 A 公司的订单数据出现在 B 公司的 Agent 对话里。

方案：在ChatMemory和Tool执行链路中注入TenantId。

@Component public class TenantAwareChatMemory implements ChatMemory { @Autowired private RedisTemplate<String, Object> redisTemplate; @Override public List<ChatMessage> getMessages(String sessionId) { // sessionId 格式：tenant_123:user_456 String tenantId = extractTenantId(sessionId); String key = "ai:chat:" + tenantId + ":" + sessionId; return redisTemplate.opsForList().range(key, 0, -1); } } @Component public class TenantAwareOrderQueryTool implements Tool { @Override public Object execute(ToolExecutionRequest request) { // 从 ThreadLocal 或 JWT 获取当前租户 String tenantId = TenantContext.getCurrentTenant(); // 在 SQL 查询中加 tenant_id 条件 return orderService.findByTenantAndCreatedAtAfter(tenantId, ...); } }

关键点：

• sessionId必须包含租户标识，不能只用user_id；
• 所有 DAO 层查询都加tenant_id = ?条件，这是多租户安全底线；
• Tool的description()里要注明“本工具仅查询当前租户数据”。

6.2 灰度发布：用 Feature Flag 控制 Agent 流量

新上线的 Agent 可能不稳定。需要先对 5% 的用户开放，观察指标后再全量。

方案：用 Spring Cloud Config +@ConditionalOnExpression：

@Configuration public class AgentConfig { @Bean @ConditionalOnExpression("#{environment.getProperty('agent.enabled', 'false').toBoolean() && " + "environment.getProperty('agent.traffic-ratio', '0.0').toDouble() > Math.random()}") public OrderAssistantAiService aiService() { return AiServices.builder(OrderAssistantAiService.class) .tools(List.of(new OrderQueryTool(), new RefundApplyTool())) .build(); } }

配合配置中心：

• agent.enabled=true
• agent.traffic-ratio=0.05（5% 流量）

这样只有 5% 的请求会走新 Agent，其余走老版客服页面。

6.3 熔断降级：当大模型 API 不可用时，自动切回规则引擎

百炼 API 有 0.1% 的超时率。不能让用户看到“服务暂时不可用”。

方案：用 Resilience4j 包装AiService：

@Bean public OrderAssistantAiService resilientAiService() { CircuitBreaker circuitBreaker = CircuitBreaker.ofDefaults("ai-service"); return Decorators.ofSupplier(() -> aiService.chat("fallback to rule engine")) .withCircuitBreaker(circuitBreaker) .withFallback((throwable) -> ruleEngine.process(request.getMessage())) // 用 Drools 规则引擎兜底 .decorate(); }

降级策略：

• 熔断窗口：10 秒内失败 3 次就打开熔断器；
• 降级逻辑：用 Drools 规则匹配关键词（“退款”→查订单→调退款接口）；
• 熔断恢复：半开状态，放行 10% 请求测试，成功则关闭熔断器。

这套组合拳，让我们的 Agent SLA 达到 99.95%，比纯人工客服还稳。

7. 转型路线图：Java 工程师的 AI Agent 学习路径

最后说点实在的。不需要辞职去学 AI，按你现在的节奏，分三步走：

7.1 第一阶段：用两周，跑通一个生产级 Demo（本周就能开始）

• 周一：搭好 Spring Boot + LangChain4j 环境，调通百炼 API；
• 周二：把你最熟的一个 Service（比如用户查询）包装成 Tool；
• 周三：写一个AiService接口，用@UserMessage测试；
• 周四：加ChatMemory，实现对话记忆；
• 周五：部署到测试环境，用 Postman 让同事体验。

目标：能向面试官展示“这是我做的 Agent，源码在 GitHub，能查订单、能退款”。

7.2 第二阶段：用一个月，重构一个真实模块（下个月重点）

选一个低风险、高价值的模块：

• 客服知识库问答（把 FAQ 表变成 Tool）；
• 运营活动配置（把活动规则引擎包装成 Tool）；
• 数据报表生成（把 BI 查询接口变成 Tool）。

关键产出：

• 一份《XX 模块 Agent 化改造报告》，包含 ROI（人力节省 XX 小时/月）；
• 一套可复用的 Tool 开发规范（description 写法、参数校验模板）；
• 在团队内做一次分享：“如何用 Java 功底，零基础落地 AI Agent”。

7.3 第三阶段：用三个月，成为团队 AI 架构师（半年后）

不是让你写模型，而是：

• 制定团队的 Agent 接入标准（哪些服务必须提供 Tool 接口）；
• 搭建 Agent 监控平台（调用成功率、Token 消耗、平均延迟）；
• 设计多模型路由策略（简单问题用 Qwen-Plus，复杂问题切 Qwen-Max）；
• 输出《Java 工程师 AI Agent 实战手册》内部文档。

这条路，比从头学 Python/PyTorch 快 10 倍，因为你所有的积累——Spring Boot、MyBatis、Redis、MQ、分布式事务——全都能复用。AI Agent 不是取代 Java 工程师，而是给 Java 工程师一把新钥匙，打开更高维的工程战场。

我在上个月的晋升答辩里，PPT 第一页就写：“过去一年，我用 LangChain4j 把客服系统响应速度提升 40%，人力成本降低 25%。这不是 AI 替代人，而是人用 AI 做更难的事。” —— 这句话，值得你今天就开始实践。