Spring AI Alibaba 入门实战：Java 开发者如何快速构建第一个 AI 应用

Spring AI Alibaba 入门实战：Java 开发者如何快速构建第一个 AI 应用

在过去很长一段时间里，AI 应用开发似乎更偏向 Python 生态：LangChain、LangGraph、各类 Agent SDK、向量库集成，几乎都默认 Python 是“第一语言”。

但对很多 Java 团队来说，真正的业务系统、网关、流程引擎、权限体系、消息链路、监控治理，依旧是 Spring 体系的主场。这个时候，一个核心问题就出现了：

能不能用 Java 原生方式，把大模型能力真正接进现有业务系统，而不是只做几个 Demo？

Spring AI 和 Spring AI Alibaba，正是在解决这个问题。

Spring AI 提供的是统一的 AI 抽象能力，比如模型调用、Prompt、Tool、Memory、RAG、MCP 等；而 Spring AI Alibaba 则在这个基础上，进一步补足了通义生态接入、Agent Framework、Graph 编排、多智能体工作流、企业级集成等能力。官方文档也明确将其定位为一个面向 Java 开发者的 Agentic AI Framework。

一、为什么是 Spring AI Alibaba

很多人第一次接触大模型接入时，做法通常很直接：

• 拿到 API Key
• 调一个 HTTP 接口
• 拼 prompt
• 返回结果

这样做当然没问题，但只适合一次性验证。真正进入业务后，问题会越来越多：

• 模型提供商不止一个，接口格式不同
• 需要结构化输出，而不是一段自由文本
• 需要工具调用，比如查天气、查数据库、调内部接口
• 需要多轮对话记忆
• 需要接入知识库
• 需要链路观测、失败重试、上下文裁剪
• 后面还可能发展成 Agent 或工作流

Spring AI 的价值，在于它把这些 AI 开发中的“原子能力”统一抽象出来；Spring AI Alibaba 的价值，在于它面向 Java 业务落地，把这些能力与阿里云模型生态、Agent 编排、企业基础设施更紧密地结合了起来。官网把它的核心能力概括为三层：Agent Framework、Graph、Augmented LLM。其中 Agent Framework 面向快速构建 Agent，Graph 更适合复杂流程编排，而底层 Augmented LLM 则承接模型、工具、消息、向量存储等基础抽象。

你可以把它简单理解为：

• Spring AI：AI 开发的“基础设施抽象层”
• Spring AI Alibaba：更贴近 Java 企业落地的“增强框架层”

二、核心概念

1）Model

Model 就是模型能力本身，比如聊天模型、Embedding 模型、多模态模型。

对于 Java 开发者来说，最重要的不是“模型原理推导”，而是要知道一件事：

框架应该帮你屏蔽不同模型厂商之间的调用差异。

Spring AI 的核心价值之一，就是通过统一抽象来屏蔽不同底层模型服务的接入差异；Spring AI Alibaba 则在此基础上提供了通义相关实现，比如 DashScopeChatModel。

2）Prompt

Prompt 不是“随便问一句话”，而是你给模型设定的任务边界、输出约束和上下文材料。

写业务 AI 时，一个好 Prompt 至少要明确：

• 角色
• 任务目标
• 输入边界
• 输出格式
• 错误兜底策略

3）Tool

Tool 可以理解为“给模型外挂手和脚”。

模型本身只会生成文本，它不知道实时天气，不知道你的数据库里有什么，不知道你内部系统的订单状态。要让它能“查”，就得把这些能力以工具的形式暴露给它。

4）Memory

Memory 是多轮对话的上下文记忆能力。

如果没有记忆，用户连续问两句，模型根本不知道上一轮说了什么；如果记忆不受控，又会导致 token 膨胀、成本上升、上下文污染。

5）Agent

模型 + 工具 + 推理决策 + 多轮循环执行

Spring AI Alibaba 官方推荐优先使用 Agent Framework 内置的ReactAgent来快速构建 Agent；同时还提供了SequentialAgent、ParallelAgent、RoutingAgent、LoopAgent等基础工作流模式

三、Spring AI Alibaba 的整体能力图

第一层：模型接入层

这一层解决的是“如何接入模型”。

比如你要接阿里云通义模型，那么可以通过 Spring AI Alibaba 的 DashScope 相关支持来完成接入。官方文档中既提供了 starter 方式，也提供了手动构造DashScopeChatModel的方式。

第二层：应用开发层

这一层解决的是“如何把模型变成一个能工作的应用”。

例如：

• 普通聊天应用
• 结构化提取
• 文本分类
• 工具调用
• 知识库问答

第三层：Agent / Workflow 层

这一层解决的是“如何让 AI 不只是回答，而是能执行任务”。

当你的场景从“问答”升级成“查信息 → 判断 → 调接口 → 汇总结果 → 输出结构化结论”时，就会明显感受到 Agent Framework 和 Graph 的价值。

四、环境准备

根据 Spring AI Alibaba 当前文档，快速开始至少需要这些基础条件：

• JDK 17+
• Spring Boot 3.x
• 配置可用的DashScope API Key

五、入门

1. 跑通模型调用
2. Prompt 约束
3. 结构化输出
4. Tool / Agent / RAG

1）Maven 依赖

BOM 管理版本，再引入 DashScope starter。

<dependencyManagement> <dependencies> <dependency> <groupId>com.alibaba.cloud.ai</groupId> <artifactId>spring-ai-alibaba-bom</artifactId> <version>1.0.0.2</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencyManagement> <dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>com.alibaba.cloud.ai</groupId> <artifactId>spring-ai-alibaba-starter-dashscope</artifactId> </dependency> </dependencies>

官方概览页给出的就是 BOM +spring-ai-alibaba-starter-dashscope的入门方式；而官方快速开始页则展示了直接显式写版本的方式。两种都能表达接入思路。

2）配置 API Key

建议优先使用环境变量，而不是把 Key 写死在配置文件里。官方快速开始文档也是这样建议的

export AI_DASHSCOPE_API_KEY=你的Key

如果只是本地测试，也可以在application.yml里配置：

spring: ai: dashscope: api-key: ${AI_DASHSCOPE_API_KEY} chat: options: model: qwen-plus

3） Controller

package com.example.ai.controller; import org.springframework.ai.chat.client.ChatClient; import org.springframework.web.bind.annotation.GetMapping; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.RestController; @RestController public class ChatController { private final ChatClient chatClient; public ChatController(ChatClient.Builder chatClientBuilder) { this.chatClient = chatClientBuilder.build(); } @GetMapping("/ai/chat") public String chat(@RequestParam("message") String message) { return chatClient.prompt() .user(message) .call() .content(); } }

框架已经把模型接入和调用抽象掉了，业务层只需要按 Spring 的方式组织代码即可。Spring AI 的设计目标本身就是为 AI 应用提供 Spring 风格 API 与统一抽象；Spring AI Alibaba 则在此基础上扩展通义接入与 Java 生态实践。

六、加入系统 Prompt

大多数初学者跑通第一个接口后，马上会遇到第二个问题：

为什么模型输出很飘？

原因很简单，你只是让它“回答”，没有告诉它“应该怎么回答”。

比如你要做一个面向开发者的 AI 助手，可以把 Prompt 收敛成这样：

@GetMapping("/ai/guide") public String guide(@RequestParam("question") String question) { return chatClient.prompt() .system(""" 你是一名资深 Java 架构师。 请用中文回答。 回答要求： 1. 先给结论 2. 再解释原因 3. 最后给出一个可执行建议 4. 避免空泛表述 """) .user(question) .call() .content(); }

到了这一步，你就已经从“模型测试”进入“业务提示工程”的范畴了。

这里有一个很重要的经验：

Prompt 不只是控制语气，更是控制结果质量。

在企业场景里，模型能力不稳定，很多时候不是模型不行，而是输入约束太弱。

七、做结构化输出

在真实业务里，很多场景并不需要一大段自然语言，而是需要模型返回结构化结果，比如：

• 是否命中规则
• 分类结果
• 风险等级
• 摘要内容
• 审核原因

这时候你就不能只追求“回答得像人”，而要追求“返回得像接口”。

例如你要做一个工单分类助手，可以把任务描述成：

请对用户问题进行分类，只允许输出 JSON： { "category": "账号问题/支付问题/物流问题/其他", "reason": "分类原因" }

这一类需求，是 Java 团队最容易真正落地的 AI 场景：

• 客服分类
• 审核辅助
• 标签抽取
• 内容摘要
• 文本改写
• 风险识别

因为它们天然适合接到现有系统里，不需要一开始就上复杂 Agent。

八、 Tool

适合上 Tool 的场景

• 需要获取实时信息
• 需要访问企业内部系统
• 需要执行动作，而不是只回答
• 需要组合多个能力链路

比如：

• 查天气
• 查订单
• 查库存
• 创建设备工单
• 发起审批
• 查询司机轨迹异常

不适合上 Tool 的场景

• 单纯文本改写
• 简单内容总结
• 分类/抽取类任务
• 固定知识问答

也就是说：

Tool 不是“高级感配置”，而是“让模型获得外部能力”的必要手段。