1. Java 后端转型 AI Agent到底卡在哪一步很多 Java 开发者第一次接触 AI Agent都会有一种割裂感Spring Boot、MyBatis、Redis 这套东西明明很熟但一看到 Token、Embedding、向量检索、Tool Calling 这些词就不知道从哪里下手。更麻烦的是网上大部分教程要么是 Python 生态的 LangChain 示例要么是纯概念科普看完还是不知道在 Java 项目里怎么落地。我自己是从传统 CRUD 后端一路写过来的也踩过不少坑。最开始我以为 Agent 就是“调个模型接口把返回结果拼一拼”结果真动手才发现模型调用只是整条链路里最不起眼的一环。真正决定一个 Agent 能不能上线的是模型外面那一圈工程能力超时怎么处理、流式输出怎么接、工具调用权限怎么控、RAG 检索结果怎么拼进上下文、Token 成本怎么统计。这篇文章面向的是已经具备 Web、数据库、缓存、消息队列基础想用 Spring AI 做 AI Agent 应用开发的 Java 工程师。我会按“系统链路”而不是“知识点目录”来组织内容从模型接入一路讲到生产级工程化每个阶段都给出可复制的 Spring AI 配置片段和本地验证步骤。你不需要一次学完所有框架先沿链路建立全局认识再用项目逐段补齐能力就行。核心检索词先明确Spring AI 是 Spring 生态里用来接入大模型的框架它能让你用熟悉的依赖注入、配置管理、WebFlux 流式响应来写 AI 应用AI Agent 则是能自主决策、调用工具、完成多步任务的应用形态。这两者结合就是 Java 开发者转型 AI 最顺的一条路。2. 用 TaoToken 打通模型接入层Spring AI 配置不再卡壳在写第一行 Spring AI 代码之前得先解决一个现实问题模型从哪来。很多 Java 开发者卡在这一步不是因为不会写代码而是因为模型接入的配置太碎——不同供应商的 Base URL、鉴权方式、模型 ID 命名规则都不一样切换一次就要改一堆代码。我的做法是先用一个统一的模型接入服务把这件事标准化。TaoToken 提供 OpenAI 兼容的接口Base URL 是https://taotoken.net/api你可以在它的控制台里创建 API Key然后在 Spring AI 里直接按 OpenAI 协议配置。这样业务代码不依赖具体模型 SDK后面换模型只改配置不改代码。具体操作路径是这样的先到官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 了解整体能力然后进控制台创建 API Key地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 。创建完 Key 之后建议先到模型对话页面 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 手动发一条消息确认 Key 能用、模型能返回再去写代码。这一步能帮你排除掉大部分“代码没问题但请求失败”的情况。Spring AI 的依赖引入很简单在pom.xml里加dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-openai-spring-boot-starter/artifactId version1.0.0-M6/version /dependency然后在application.yml里配置spring: ai: openai: base-url: https://taotoken.net/api api-key: ${TAOTOKEN_API_KEY} chat: options: model: gpt-4o-mini temperature: 0.7这里有个细节要注意base-url不要带/v1后缀Spring AI 的 OpenAI starter 会自己拼路径。API Key 建议用环境变量注入不要硬编码在配置文件里后面上生产也方便做密钥管理。配置好之后写一个最小的 Controller 验证RestController public class ChatController { private final ChatClient chatClient; public ChatController(ChatClient.Builder builder) { this.chatClient builder.build(); } GetMapping(/chat) public String chat(RequestParam String message) { return chatClient.prompt() .user(message) .call() .content(); } }启动项目访问http://localhost:8080/chat?message你好如果能看到模型返回的中文回复说明接入层已经通了。这一步看起来简单但它是后面所有 Agent 能力的地基。接入层不稳后面 RAG、工具调用全是空中楼阁。如果你打算长期做编码类 Agent可以顺手了解一下 Coding Plan地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 它针对代码场景做了优化后面接 Claude Code 之类的工具会用到。3. 可复制的 Spring AI 工程配置流式输出、多模型与结构化返回接入层跑通之后下一步是把“能调通”变成“能稳定用”。这一节我给出一套可以直接抄的配置覆盖流式输出、多模型切换、结构化返回三个高频场景。先看流式输出。Agent 应用如果等模型全部生成完再返回用户体验会很差尤其是长回答。Spring AI 配合 WebFlux 可以做 SSE 流式推送GetMapping(value /chat/stream, produces MediaType.TEXT_EVENT_STREAM_VALUE) public FluxString chatStream(RequestParam String message) { return chatClient.prompt() .user(message) .stream() .content(); }前端用 EventSource 接这个接口就能看到打字机效果。这里要注意流式接口的线程模型和普通接口不一样别在流式链路里做阻塞式数据库查询否则会把 Netty 的线程池拖死。多模型切换建议用配置类隔离。不要在每个 Service 里 new 一个 ChatClient而是按场景定义 BeanConfiguration public class ModelConfig { Bean(fastClient) public ChatClient fastClient(ChatClient.Builder builder, Value(${spring.ai.openai.chat.options.model}) String model) { return builder .defaultOptions(OpenAiChatOptions.builder() .withModel(model) .withTemperature(0.3) .build()) .build(); } Bean(reasoningClient) public ChatClient reasoningClient(ChatClient.Builder builder) { return builder .defaultOptions(OpenAiChatOptions.builder() .withModel(gpt-4o) .withTemperature(0.7) .build()) .build(); } }简单任务走fastClient复杂推理走reasoningClient成本和质量都能兼顾。结构化返回是 Agent 里最容易翻车的地方。模型返回的 JSON 经常带 markdown 代码块标记或者字段缺失。Spring AI 提供了entity()方法做映射public record OrderInfo(String orderNo, String status, String reason) {} OrderInfo info chatClient.prompt() .user(查询订单 orderNo 的状态) .call() .entity(OrderInfo.class);但entity()不是万能的模型返回格式不对时照样抛异常。生产环境里我会在它外面包一层校验和有限重试public OrderInfo queryWithRetry(String orderNo, int maxRetry) { for (int i 0; i maxRetry; i) { try { OrderInfo info chatClient.prompt() .user(查询订单 orderNo 的状态只返回 JSON) .call() .entity(OrderInfo.class); if (info ! null info.orderNo() ! null) { return info; } } catch (Exception e) { log.warn(结构化解析失败第 {} 次重试, i 1); } } throw new IllegalStateException(模型输出无法解析为 OrderInfo); }这套配置下来你的模型接入层就不再是“能跑”而是“能扛”。后面接 RAG 和工具调用时这些基础设施会省掉大量重复劳动。4. 本地验证 Agent 请求链路从 /chat 到工具调用的完整跑通配置写完必须验证。我习惯按“单轮对话 → 流式 → 结构化 → 工具调用”四步走每步都有明确的成功标志。第一步单轮对话。访问/chat?message用一句话解释什么是 Token成功标志是返回内容里包含“Token 是模型处理文本的最小单位”这类语义。如果返回 401说明 API Key 没配好如果返回超时检查网络和 base-url 是否正确。第二步流式输出。用 curl 验证curl -N http://localhost:8080/chat/stream?message写一段200字的自我介绍成功标志是终端里逐字逐句出现内容而不是等几秒后一次性刷出来。如果卡住不动检查produces是不是text/event-stream以及有没有被网关缓冲。第三步结构化返回。访问/order/query?orderNo123456成功标志是返回标准 JSON字段和你的 record 定义一致。如果抛JsonParseException说明模型返回里混了 markdown 标记需要在 prompt 里明确“只返回 JSON不要加代码块”。第四步工具调用。这是 Agent 和普通聊天机器人的分水岭。Spring AI 里定义工具很简单Component public class OrderTools { Tool(description 根据订单号查询订单发货状态只用于用户询问订单物流的场景) public String queryOrderStatus( ToolParam(description 订单号长度16-32位) String orderNo) { // 实际业务里这里查数据库 return 订单 orderNo 已发货物流单号 SF123456; } }注册到 ChatClientChatClient agentClient builder .defaultTools(new OrderTools()) .build(); String answer agentClient.prompt() .user(帮我查一下订单 123456 发货了没) .call() .content();成功标志是模型没有直接编答案而是触发了queryOrderStatus然后基于工具返回结果组织语言。你可以在工具方法里打日志确认它被调用了。这里有个我踩过的坑工具描述写得太模糊模型会乱调。比如把工具名写成handle、描述写成“处理业务”模型根本不知道什么时候该用。改成queryOrderStatus、描述写清楚“只用于订单物流查询”命中率立刻上来了。工具名和描述是给模型看的接口文档不是给人看的注释这点一定要转变思路。5. 常见报错排查401、local proxy failed、reading choices、OAuth这一节列几个高频报错和对应处理方式都是我在实际项目里遇到过的。401 Unauthorized。最常见的原因是 API Key 没生效。先确认环境变量TAOTOKEN_API_KEY在当前 shell 里能echo出来再确认 Spring 配置里引用的是${TAOTOKEN_API_KEY}而不是写死的占位符。如果 Key 是从控制台复制的注意前后有没有多余空格。还有一种情况是 Key 被禁用或额度耗尽去控制台 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 检查一下状态。local proxy failed。这个报错通常出现在你本地配了某些网络工具但工具没启动或者端口不对。Spring AI 的 HTTP 客户端会读取系统代理设置如果代理配置指向一个不存在的端口就会报这个。处理方式是检查http_proxy、https_proxy环境变量或者直接在application.yml里显式配置不走代理。企业内网环境里也常见找运维确认出口策略。reading choices 相关报错。典型信息是Cannot deserialize value of type ... from Object value (token JsonToken.START_OBJECT)或者reading choices字段解析失败。这通常是模型返回格式和 Spring AI 期望的 OpenAI 响应结构不一致导致的。先确认 base-url 指向的是 OpenAI 兼容接口再确认模型 ID 拼写正确。如果用的是自定义模型名检查服务端是否真的支持这个模型。OAuth 相关报错。如果你在接 Claude Code 或者某些需要 OAuth 的工具可能会遇到 token 过期、scope 不足的问题。这类问题一般和模型接入本身无关而是工具侧的鉴权配置。处理方式是重新走一遍授权流程确认回调地址和权限范围。Claude Code 的接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里有说明按步骤来就行。排查这类问题的通用思路是先看 HTTP 状态码再看响应体里的 error message最后对照 Spring AI 的日志级别调到 DEBUG把请求和响应都打出来。大部分问题看日志就能定位。6. 从 Demo 到生产Agent 学习路线的阶段划分与持续进阶把前面五节串起来其实已经覆盖了 Java 开发者转型 AI Agent 的主干路径。我把它整理成三个阶段你可以对照自己的进度。第一阶段是接入与对话目标是能稳定调用模型、支持流式和结构化返回。这个阶段的核心产物是一个 AI Chat Gateway能切换模型、记录 Token、处理超时降级。面试时你可以讲“我们做了模型网关层业务代码不直接依赖具体 SDK支持多模型路由和统一错误码”。第二阶段是知识与工具目标是让 Agent 能查私有知识、能调外部系统。这个阶段要啃 RAG 和 Tool Calling。RAG 的重点不是“上传文档、向量检索”这个 Demo 流程而是文档清洗、分片策略、混合检索、重排序、无证据短路这一整套工程细节。工具调用的重点是权限不能交给模型判断参数必须后端校验高风险操作要人工确认。第三阶段是编排与治理目标是让 Agent 能可控地完成多步任务并且能上线运行。这个阶段涉及 ReAct、Plan-and-Execute、Workflow 编排、记忆系统、可观测性、成本控制、灰度发布。能用确定性流程解决的就不要交给模型自由发挥模型输出永远只是候选结果权限、金额、事务必须由后端逻辑兜底。学习节奏上30 天可以建立全局认识能讲清楚一个企业级 Agent 的架构60 天做出完整业务闭环比如企业知识库加订单工具助手90 天补齐生产级治理能力包括网关、评估、成本、审计、灰度。天数只是参考真正的进度看可验证产物接口能不能跑通、引用能不能回溯、失败能不能定位、写操作是不是受控。最后给一个实用建议不要等学完所有东西再动手做项目。先跑通一个最小闭环然后在项目里遇到问题再补知识。Agent 这个领域变化很快追新概念不如把一条链路吃透。你手上那套 Spring Boot、Redis、MQ 的功底在 AI 应用的生产化阶段反而是稀缺能力——模型会调的人很多能把模型调用做成稳定后端服务的人不多。
1. Java 后端转型 AI Agent到底卡在哪一步很多 Java 开发者第一次接触 AI Agent都会有一种割裂感Spring Boot、MyBatis、Redis 这套东西明明很熟但一看到 Token、Embedding、向量检索、Tool Calling 这些词就不知道从哪里下手。更麻烦的是网上大部分教程要么是 Python 生态的 LangChain 示例要么是纯概念科普看完还是不知道在 Java 项目里怎么落地。我自己是从传统 CRUD 后端一路写过来的也踩过不少坑。最开始我以为 Agent 就是“调个模型接口把返回结果拼一拼”结果真动手才发现模型调用只是整条链路里最不起眼的一环。真正决定一个 Agent 能不能上线的是模型外面那一圈工程能力超时怎么处理、流式输出怎么接、工具调用权限怎么控、RAG 检索结果怎么拼进上下文、Token 成本怎么统计。这篇文章面向的是已经具备 Web、数据库、缓存、消息队列基础想用 Spring AI 做 AI Agent 应用开发的 Java 工程师。我会按“系统链路”而不是“知识点目录”来组织内容从模型接入一路讲到生产级工程化每个阶段都给出可复制的 Spring AI 配置片段和本地验证步骤。你不需要一次学完所有框架先沿链路建立全局认识再用项目逐段补齐能力就行。核心检索词先明确Spring AI 是 Spring 生态里用来接入大模型的框架它能让你用熟悉的依赖注入、配置管理、WebFlux 流式响应来写 AI 应用AI Agent 则是能自主决策、调用工具、完成多步任务的应用形态。这两者结合就是 Java 开发者转型 AI 最顺的一条路。2. 用 TaoToken 打通模型接入层Spring AI 配置不再卡壳在写第一行 Spring AI 代码之前得先解决一个现实问题模型从哪来。很多 Java 开发者卡在这一步不是因为不会写代码而是因为模型接入的配置太碎——不同供应商的 Base URL、鉴权方式、模型 ID 命名规则都不一样切换一次就要改一堆代码。我的做法是先用一个统一的模型接入服务把这件事标准化。TaoToken 提供 OpenAI 兼容的接口Base URL 是https://taotoken.net/api你可以在它的控制台里创建 API Key然后在 Spring AI 里直接按 OpenAI 协议配置。这样业务代码不依赖具体模型 SDK后面换模型只改配置不改代码。具体操作路径是这样的先到官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 了解整体能力然后进控制台创建 API Key地址是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 。创建完 Key 之后建议先到模型对话页面 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite 手动发一条消息确认 Key 能用、模型能返回再去写代码。这一步能帮你排除掉大部分“代码没问题但请求失败”的情况。Spring AI 的依赖引入很简单在pom.xml里加dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-openai-spring-boot-starter/artifactId version1.0.0-M6/version /dependency然后在application.yml里配置spring: ai: openai: base-url: https://taotoken.net/api api-key: ${TAOTOKEN_API_KEY} chat: options: model: gpt-4o-mini temperature: 0.7这里有个细节要注意base-url不要带/v1后缀Spring AI 的 OpenAI starter 会自己拼路径。API Key 建议用环境变量注入不要硬编码在配置文件里后面上生产也方便做密钥管理。配置好之后写一个最小的 Controller 验证RestController public class ChatController { private final ChatClient chatClient; public ChatController(ChatClient.Builder builder) { this.chatClient builder.build(); } GetMapping(/chat) public String chat(RequestParam String message) { return chatClient.prompt() .user(message) .call() .content(); } }启动项目访问http://localhost:8080/chat?message你好如果能看到模型返回的中文回复说明接入层已经通了。这一步看起来简单但它是后面所有 Agent 能力的地基。接入层不稳后面 RAG、工具调用全是空中楼阁。如果你打算长期做编码类 Agent可以顺手了解一下 Coding Plan地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 它针对代码场景做了优化后面接 Claude Code 之类的工具会用到。3. 可复制的 Spring AI 工程配置流式输出、多模型与结构化返回接入层跑通之后下一步是把“能调通”变成“能稳定用”。这一节我给出一套可以直接抄的配置覆盖流式输出、多模型切换、结构化返回三个高频场景。先看流式输出。Agent 应用如果等模型全部生成完再返回用户体验会很差尤其是长回答。Spring AI 配合 WebFlux 可以做 SSE 流式推送GetMapping(value /chat/stream, produces MediaType.TEXT_EVENT_STREAM_VALUE) public FluxString chatStream(RequestParam String message) { return chatClient.prompt() .user(message) .stream() .content(); }前端用 EventSource 接这个接口就能看到打字机效果。这里要注意流式接口的线程模型和普通接口不一样别在流式链路里做阻塞式数据库查询否则会把 Netty 的线程池拖死。多模型切换建议用配置类隔离。不要在每个 Service 里 new 一个 ChatClient而是按场景定义 BeanConfiguration public class ModelConfig { Bean(fastClient) public ChatClient fastClient(ChatClient.Builder builder, Value(${spring.ai.openai.chat.options.model}) String model) { return builder .defaultOptions(OpenAiChatOptions.builder() .withModel(model) .withTemperature(0.3) .build()) .build(); } Bean(reasoningClient) public ChatClient reasoningClient(ChatClient.Builder builder) { return builder .defaultOptions(OpenAiChatOptions.builder() .withModel(gpt-4o) .withTemperature(0.7) .build()) .build(); } }简单任务走fastClient复杂推理走reasoningClient成本和质量都能兼顾。结构化返回是 Agent 里最容易翻车的地方。模型返回的 JSON 经常带 markdown 代码块标记或者字段缺失。Spring AI 提供了entity()方法做映射public record OrderInfo(String orderNo, String status, String reason) {} OrderInfo info chatClient.prompt() .user(查询订单 orderNo 的状态) .call() .entity(OrderInfo.class);但entity()不是万能的模型返回格式不对时照样抛异常。生产环境里我会在它外面包一层校验和有限重试public OrderInfo queryWithRetry(String orderNo, int maxRetry) { for (int i 0; i maxRetry; i) { try { OrderInfo info chatClient.prompt() .user(查询订单 orderNo 的状态只返回 JSON) .call() .entity(OrderInfo.class); if (info ! null info.orderNo() ! null) { return info; } } catch (Exception e) { log.warn(结构化解析失败第 {} 次重试, i 1); } } throw new IllegalStateException(模型输出无法解析为 OrderInfo); }这套配置下来你的模型接入层就不再是“能跑”而是“能扛”。后面接 RAG 和工具调用时这些基础设施会省掉大量重复劳动。4. 本地验证 Agent 请求链路从 /chat 到工具调用的完整跑通配置写完必须验证。我习惯按“单轮对话 → 流式 → 结构化 → 工具调用”四步走每步都有明确的成功标志。第一步单轮对话。访问/chat?message用一句话解释什么是 Token成功标志是返回内容里包含“Token 是模型处理文本的最小单位”这类语义。如果返回 401说明 API Key 没配好如果返回超时检查网络和 base-url 是否正确。第二步流式输出。用 curl 验证curl -N http://localhost:8080/chat/stream?message写一段200字的自我介绍成功标志是终端里逐字逐句出现内容而不是等几秒后一次性刷出来。如果卡住不动检查produces是不是text/event-stream以及有没有被网关缓冲。第三步结构化返回。访问/order/query?orderNo123456成功标志是返回标准 JSON字段和你的 record 定义一致。如果抛JsonParseException说明模型返回里混了 markdown 标记需要在 prompt 里明确“只返回 JSON不要加代码块”。第四步工具调用。这是 Agent 和普通聊天机器人的分水岭。Spring AI 里定义工具很简单Component public class OrderTools { Tool(description 根据订单号查询订单发货状态只用于用户询问订单物流的场景) public String queryOrderStatus( ToolParam(description 订单号长度16-32位) String orderNo) { // 实际业务里这里查数据库 return 订单 orderNo 已发货物流单号 SF123456; } }注册到 ChatClientChatClient agentClient builder .defaultTools(new OrderTools()) .build(); String answer agentClient.prompt() .user(帮我查一下订单 123456 发货了没) .call() .content();成功标志是模型没有直接编答案而是触发了queryOrderStatus然后基于工具返回结果组织语言。你可以在工具方法里打日志确认它被调用了。这里有个我踩过的坑工具描述写得太模糊模型会乱调。比如把工具名写成handle、描述写成“处理业务”模型根本不知道什么时候该用。改成queryOrderStatus、描述写清楚“只用于订单物流查询”命中率立刻上来了。工具名和描述是给模型看的接口文档不是给人看的注释这点一定要转变思路。5. 常见报错排查401、local proxy failed、reading choices、OAuth这一节列几个高频报错和对应处理方式都是我在实际项目里遇到过的。401 Unauthorized。最常见的原因是 API Key 没生效。先确认环境变量TAOTOKEN_API_KEY在当前 shell 里能echo出来再确认 Spring 配置里引用的是${TAOTOKEN_API_KEY}而不是写死的占位符。如果 Key 是从控制台复制的注意前后有没有多余空格。还有一种情况是 Key 被禁用或额度耗尽去控制台 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 检查一下状态。local proxy failed。这个报错通常出现在你本地配了某些网络工具但工具没启动或者端口不对。Spring AI 的 HTTP 客户端会读取系统代理设置如果代理配置指向一个不存在的端口就会报这个。处理方式是检查http_proxy、https_proxy环境变量或者直接在application.yml里显式配置不走代理。企业内网环境里也常见找运维确认出口策略。reading choices 相关报错。典型信息是Cannot deserialize value of type ... from Object value (token JsonToken.START_OBJECT)或者reading choices字段解析失败。这通常是模型返回格式和 Spring AI 期望的 OpenAI 响应结构不一致导致的。先确认 base-url 指向的是 OpenAI 兼容接口再确认模型 ID 拼写正确。如果用的是自定义模型名检查服务端是否真的支持这个模型。OAuth 相关报错。如果你在接 Claude Code 或者某些需要 OAuth 的工具可能会遇到 token 过期、scope 不足的问题。这类问题一般和模型接入本身无关而是工具侧的鉴权配置。处理方式是重新走一遍授权流程确认回调地址和权限范围。Claude Code 的接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里有说明按步骤来就行。排查这类问题的通用思路是先看 HTTP 状态码再看响应体里的 error message最后对照 Spring AI 的日志级别调到 DEBUG把请求和响应都打出来。大部分问题看日志就能定位。6. 从 Demo 到生产Agent 学习路线的阶段划分与持续进阶把前面五节串起来其实已经覆盖了 Java 开发者转型 AI Agent 的主干路径。我把它整理成三个阶段你可以对照自己的进度。第一阶段是接入与对话目标是能稳定调用模型、支持流式和结构化返回。这个阶段的核心产物是一个 AI Chat Gateway能切换模型、记录 Token、处理超时降级。面试时你可以讲“我们做了模型网关层业务代码不直接依赖具体 SDK支持多模型路由和统一错误码”。第二阶段是知识与工具目标是让 Agent 能查私有知识、能调外部系统。这个阶段要啃 RAG 和 Tool Calling。RAG 的重点不是“上传文档、向量检索”这个 Demo 流程而是文档清洗、分片策略、混合检索、重排序、无证据短路这一整套工程细节。工具调用的重点是权限不能交给模型判断参数必须后端校验高风险操作要人工确认。第三阶段是编排与治理目标是让 Agent 能可控地完成多步任务并且能上线运行。这个阶段涉及 ReAct、Plan-and-Execute、Workflow 编排、记忆系统、可观测性、成本控制、灰度发布。能用确定性流程解决的就不要交给模型自由发挥模型输出永远只是候选结果权限、金额、事务必须由后端逻辑兜底。学习节奏上30 天可以建立全局认识能讲清楚一个企业级 Agent 的架构60 天做出完整业务闭环比如企业知识库加订单工具助手90 天补齐生产级治理能力包括网关、评估、成本、审计、灰度。天数只是参考真正的进度看可验证产物接口能不能跑通、引用能不能回溯、失败能不能定位、写操作是不是受控。最后给一个实用建议不要等学完所有东西再动手做项目。先跑通一个最小闭环然后在项目里遇到问题再补知识。Agent 这个领域变化很快追新概念不如把一条链路吃透。你手上那套 Spring Boot、Redis、MQ 的功底在 AI 应用的生产化阶段反而是稀缺能力——模型会调的人很多能把模型调用做成稳定后端服务的人不多。
