Spring AI 2.0实战：用Java构建智能Agent完整指南

Spring AI 2.0核心更新：原生Agent生态支持

随着大模型能力的快速普及，Java开发者对AI应用开发的需求日益增长。Spring AI 2.0版本的发布回应了这一趋势，其中最核心的更新就是对Agent生态的构建。

所谓Agent（智能体），是指具备自主感知、决策和执行能力的AI系统——它不仅能理解用户意图，还能自主规划执行步骤、调用工具、处理异常并最终完成复杂任务。与简单的聊天机器人不同，Agent具备记忆、推理和行动的闭环能力。Agent的概念源自人工智能研究的早期阶段，最初由MIT的Marvin Minsky等学者在多智能体系统研究中提出。现代AI Agent的设计通常遵循「感知-规划-执行」（Perception-Planning-Action）循环架构。在LLM时代，Agent的核心突破在于利用大语言模型作为「推理引擎」，通过CoT（Chain of Thought，思维链）等技术实现复杂任务的分步规划。典型的Agent架构包括：记忆模块（短期工作记忆+长期知识库）、规划模块（任务分解与策略选择）、工具使用模块（API调用能力）和反思模块（自我评估与纠错）。在AI应用开发中，Agent框架通常需要提供任务分解、工具调用、状态管理、多轮对话控制等基础设施，这正是Spring AI 2.0所构建的核心能力层。

在此前的Spring AI版本中，如果你想进行Agent开发，其实并不算友好——你往往需要结合Spring AI之上的阿里巴巴Agent框架才能顺利落地。Spring AI Alibaba是阿里巴巴在Spring AI基础上构建的增强框架，它提供了Graph（有向无环图）编排能力，支持多Agent协作、ReAct（Reasoning+Acting）推理模式、条件分支和并行执行等高级特性。ReAct是由Princeton大学和Google Brain在2022年提出的Agent推理范式，其核心思想是让大模型在解决问题时交替进行推理（Thought）和行动（Action），每一步中模型先产生推理步骤说明当前思考过程，然后决定执行一个具体动作，再根据动作返回的观察结果（Observation）进行下一轮推理，这种模式模拟了人类「想一想、做一步、看结果、再想想」的认知过程。在Spring AI 2.0发布之前，Java开发者若想实现复杂的Agent工作流，几乎必须依赖该框架的扩展能力。而2.0版本出来之后，它已经对Agent的基座和生态做了一些最基本的实现，让开发者可以更原生地在Spring生态中搭建Agent能力。

这意味着，对于长期深耕Java技术栈的开发者而言，进入AI应用开发领域的门槛进一步降低了。你不再需要依赖Python生态才能构建智能应用，Spring AI让Java也具备了完整的AI应用开发能力。

从传统系统到AI交互：航空智能客服实战

本次讲解的核心项目是一个「图灵航空助手」，它很好地演示了如何用AI对话方式改造传统系统。

传统的事件驱动系统遵循的是GUI（图形用户界面）交互范式，用户需要通过精确的点击、表单填写和页面导航来完成操作。比如用户想要退票，就必须点击某个按钮、找到某个页面、完成一系列操作，学习成本高且容易迷失在复杂的菜单层级中。而引入AI对话式交互（也称NUI，自然用户界面）后，将操作意图的表达从精确的UI操作简化为自然语言描述，用户只需一句话——「你好，帮我退票」——AI就会间接调用系统内部的业务方法，本质上是将用户界面从「用户适应系统」翻转为「系统适应用户」。这种交互范式的转变代表了人机交互领域从CLI（命令行界面）到GUI再到NUI的第三次重大演进，其背后的驱动力是大语言模型在自然语言理解和意图识别方面的能力突破。

例如系统中有一个退票方法cancelBooking，它需要传入预定号和姓名。当AI需要调用这个业务方法时，它会主动向用户索取这些信息，拿到后就帮我们完成退票，并把订单状态从「已预定」改为「已取消」。

这套模式的价值在于普适性：无论你身处医疗、教育还是政务行业，都可以为自己的系统嵌入一个智能客服。很多小白用户找一个功能可能要花半天时间，而AI智能客服可以直接告诉他功能在哪个菜单，或者干脆帮他直接操作完成。

Tools与MCP：内外双通道机制详解

要让大模型能够调用外部能力，需要理解两个关键技术的分工：

Tools：连接自己的内部系统

Tools是让大模型与我们自己系统进行通信的方式。 基础大模型本身不具备调用外部API的能力，它只能依据训练时的已有知识回答问题。而通过Tools（也称Function Calling，函数调用），大模型才具备了「感知外界」的能力。Function Calling的技术实现涉及模型训练和推理两个层面：在训练阶段，大模型通过海量的函数调用样本学习了「何时该调用函数」以及「如何正确构造调用参数」的能力；在推理阶段，开发者通过API将可用函数的JSON Schema描述传递给模型，模型在生成回复时如果判断需要外部信息，会停止文本生成，转而输出一个结构化的函数调用请求。这一机制由OpenAI在2023年6月首次引入API，此后各大模型厂商均已支持。

其工作原理是：开发者将业务方法的名称、描述和参数结构注册给大模型，当用户的请求需要调用某个方法时，大模型会生成一个结构化的调用请求（包含方法名和参数值），由应用框架负责实际执行并将结果返回给大模型。比如前面提到的退票方法cancelBooking，就是通过Tools让大模型间接调用系统内部业务API。

MCP：连接外部第三方服务

MCP则专门用于大模型与外部服务的交互。 MCP（Model Context Protocol，模型上下文协议）是由Anthropic于2024年11月正式发布的开放标准协议，旨在为大模型提供统一的外部服务访问接口。其设计灵感来源于LSP（Language Server Protocol，语言服务器协议）——LSP通过标准化协议让IDE与多种编程语言的服务实现解耦，MCP则试图在AI领域实现类似的标准化效果。

MCP采用Client-Server架构，具体包含三层：Host（宿主应用，如IDE或聊天界面）、Client（协议客户端，负责维护与Server的一对一连接）和Server（服务端，封装特定能力）。MCP Server可以暴露三类能力：Resources（数据资源，如文件、数据库内容）、Tools（可执行的操作）和Prompts（预定义的提示词模板）。传输层支持stdio（标准输入输出，适用于本地进程）和HTTP+SSE（适用于远程服务）两种方式。MCP Client则嵌入在AI应用中负责服务发现和调用协调。通过标准化的协议定义，不同厂商的服务可以被大模型以统一方式发现和调用，避免了每接入一个新服务就需要编写定制化集成代码的问题。

两者的区别很清晰：Tools面向内部系统的业务方法，MCP面向外部现成的服务。

举例来说，如果用户想让AI规划「重庆到青岛的自驾路线」，系统就可以通过配置好的百度地图MCP Server来完成路径规划。开发者只需在系统中配置好百度地图的MCP服务（其中包含路径规划等能力），大模型就能调用它给出完整的行程方案。

记住这个核心区分：一个提供内部能力，一个提供外部能力。

Skill技能模块：可复用、可维护的提示词管理

除了Tools和MCP，项目中还演示了Skill（技能）的用法。比如系统中内置了一个「私人旅行管家」，可以帮用户进行行程和目的地的旅游规划。

Skill的本质是所谓「技能」，它是可以被「培养」和积累的。它的价值主要体现在两个方面：

• 复用现成技能：当系统需要用到别人已经封装好的成熟技能时，可以直接引入。这类似于软件开发中的「库」或「包」的概念，社区中已经有人将优质的提示词逻辑封装为标准化的Skill，其他开发者可以直接复用而无需重新调试。
• 规范提示词管理：Skill提供了一种更规范的方式来维护提示词（本质是Markdown格式的描述），让提示词工程不再零散混乱。在实际项目中，提示词往往散落在代码的各个角落，难以版本管理和迭代优化，Skill将其结构化为独立的、可版本控制的模块。

通过Skill，开发者可以把复杂的提示词逻辑抽象成一个个可管理的技能模块，让AI应用更易维护、更具扩展性。这种思路与软件工程中的「关注点分离」原则一脉相承——将AI的行为逻辑（提示词）与应用代码解耦，使两者可以独立演进。

Java程序员如何进入AI开发领域

针对大量Java程序员关心的「如何转型AI」问题，这里给出两个明确方向。

方向一：Vibe Coding（面向环境编程）

第一个方向是用AI赋能自己的日常开发，提升工作效率。Vibe Coding（氛围编程/面向环境编程）是Andrej Karpathy在2025年2月的一条推文中首次提出的编程范式。Karpathy曾任Tesla AI总监、是OpenAI的联合创始人之一，他描述道：「我完全沉浸在氛围中，拥抱指数级增长，忘记代码的存在。」核心理念是开发者不再逐行编写代码，而是通过自然语言描述需求和约束条件，让AI编程助手自动生成实现代码。开发者的角色从「代码编写者」转变为「需求描述者和代码审查者」。

比如使用Codex、Claude Code等工具，进行所谓「面向环境编程」——本质上是面向Skill这种Markdown描述来编程：先把需求描述清楚，再让AI基于需求自动生成代码。这种范式特别适合原型开发和常规业务逻辑实现，但对于性能关键和安全关键的代码仍需人工把控。Vibe Coding对开发者提出了新的能力要求：清晰的需求表达能力、代码审查能力、系统架构思维，以及知道何时应该手动介入的判断力。

方向二：成为AI应用开发工程师

第二个方向是成为AI应用开发工程师。这里有一个行业共识值得重点关注。

如今主流大模型（Gemini、Claude、通义千问、MiniMax、Kimi等）跑分都相差不大，大模型层面已经「卷得差不多了」。因此，决定一个AI应用好不好、聪不聪明的关键，其实不是大模型本身，而是包裹在大模型外层的「AI工程」能力。

这层能力包括：

• 提示词工程（Prompt Engineering）：通过精心设计的指令、示例和约束条件，引导大模型产生期望的输出行为。提示词工程的核心技术包括零样本提示（Zero-shot）、少样本提示（Few-shot）、思维链（Chain of Thought）、自洽性（Self-Consistency）等策略，每种策略适用于不同的任务场景。
• 上下文工程（Context Engineering）：这是2025年由Andrej Karpathy等人提出的新概念，Shopify CEO Tobi Lütke将其称为「2025年最重要的新技能」。它超越了单纯的提示词工程，关注的是如何在正确的时间将正确的信息以正确的格式提供给大模型。上下文工程的核心挑战在于：虽然大模型的上下文窗口在不断扩大（从最初的4K tokens到如今的100K甚至1M tokens），但「能装下」不等于「能有效利用」——研究表明大模型存在「Lost in the Middle」现象，对上下文中间部分的信息关注度显著低于首尾部分。因此需要精心设计信息的排列顺序、压缩策略和分块方式。典型技术手段包括：对话历史的滑动窗口与摘要、RAG检索结果的重排序（Reranking）、多级系统指令的优先级管理、以及动态上下文组装策略。上下文工程的质量直接决定了AI应用的智能程度，因为大模型的输出质量高度依赖于其接收到的上下文质量。
• Tools、MCP、RAG、Skill等扩展技术：其中RAG（Retrieval-Augmented Generation，检索增强生成）是一种将外部知识库与大模型生成能力相结合的技术架构，最早由Meta AI在2020年提出。其技术实现包含离线索引和在线查询两个阶段：离线阶段将知识库文档进行分块（Chunking），通过Embedding模型将每个文本块转换为高维向量，存入向量数据库（如Pinecone、Milvus、Weaviate等）；在线阶段将用户查询同样转换为向量，通过ANN（近似最近邻）算法在向量数据库中检索语义相似的文档片段，经过重排序后注入提示词，让模型基于最新、最相关的事实信息生成回答。进阶的RAG架构还包括查询改写（Query Rewriting）、假设文档嵌入（HyDE）、多路召回融合、以及GraphRAG（基于知识图谱的检索增强生成）等优化策略，有效解决了大模型知识截止日期的限制和幻觉问题。
• AI应用的自进化能力（能否越用越聪明）：通过用户反馈收集、对话日志分析、提示词自动优化等机制，让AI应用在使用过程中持续改进其表现。这通常涉及RLHF（Reinforcement Learning from Human Feedback，人类反馈强化学习）的轻量化应用、A/B测试框架、以及基于评估指标的自动提示词迭代等工程实践。

掌握这些能力，就能胜任AI应用开发。基于Spring AI可以开发轻量级Agent、聊天机器人；结合Spring AI Alibaba及其Graph能力，还能实现多Agent、ReAct自主规划、Workflow流程编排等更复杂的场景。

结语：Java的AI时代已经到来

可以说，Java生态已经不再是AI领域的一片空白。借助Spring AI及其周边生态，Java开发者完全有能力独立完成从聊天机器人到复杂Agent的AI应用开发。

如果在此基础上再补充一些Python相关技能（如TensorFlow、Transformer底层原理、模型微调算法），竞争力还会进一步提升。不过在当前阶段，微调的应用场景相对有限——企业级应用中大多数需求通过RAG和提示词工程即可满足，只有在特定垂直领域需要模型具备专业知识或特殊行为模式时才需要微调（例如医疗领域的专业术语理解、金融领域的合规表述生成等）。掌握好AI工程这一核心能力，才是Java程序员切入AI领域最务实的路径。