Spring AI 2.0实战：Java程序员的Agent开发入门

Spring AI 2.0 的发布，让 Java 开发者终于可以摆脱“拼凑式”的 Agent 开发体验。图灵课堂徐书老师在一节公开课中直言，2.0 最大的更新在于对 Agent 生态的构建——此前想在 Spring AI 上做 Agent，往往还得叠加阿里巴巴 Agent 框架做大量改造，而现在基座和生态已经有了最基本的实现。

这节课用一个“航空智能客服”项目贯穿，把 Tools、MCP、记忆、Skill、Agent 开发串了一遍。对于从未接触过 AI 应用开发的 Java 程序员，它提供了一条相对完整的入门路径。

从传统系统到对话式交互

课程演示的起点是一个传统的航空服务系统：退票要点击按钮、改签要找到菜单和页面。徐书老师的改造思路是引入对话层，让用户直接说“你好帮我退票”，由 AI 间接调用系统内的 cancel_booking 业务方法。

这个方法需要预定号和姓名两个参数，AI 会主动向用户索取，用户补充后完成调用，状态从“已预定”变为“已取消”。

这个例子点出了大模型的关键短板：它本身无法调用你系统的 API。要让大模型“感知外界”，必须借助 Tools。徐书老师把 Tools 定义为大模型与自有系统通信的方式，而这一点恰恰是很多行业场景的通用需求——医疗、教育、政务系统里，小白用户找不到功能入口的情况普遍存在，智能客服既可以指路，也可以直接代操作。

Tools、MCP、Skill：三条边界要分清

课程里最容易混淆的是 Tools 与 MCP 的分工，徐书老师给出了明确划分：Tools 面向自己系统的 API 方法，MCP 面向外部方法。

演示中，用户退票后想规划重庆到青岛的自驾路线，系统调用了预先配置好的百度地图 MCP Server 中的路径规划能力，返回完整路线。这一步展示的正是 MCP 对接外部服务的能力。

Skill 则是另一层概念。课程中的“私人旅行管家”可以为用户的行程做目的地旅游规划，徐书老师把它描述为“技能”——可以随意养，也可以用来更规范地维护提示词。三者叠加，构成了一个 AI 应用的基础技术栈。

MCP（Model Context Protocol） 是 Anthropic 于 2024 年底提出的开放协议，旨在标准化大模型与外部数据源、工具之间的连接方式。它定义了一套客户端-服务器架构：MCP Server 负责暴露资源（如文件、数据库、API 能力），MCP Client（通常内置于 AI 应用或 IDE）负责按协议调用。相比为每个外部服务单独写适配代码，MCP 让同一个 Server 可以被任意支持该协议的模型或 Agent 复用，类似“AI 世界的 USB 接口”。本文中百度地图 MCP Server 就是一个典型例子：它把路径规划能力封装为标准 MCP 工具，Spring AI 应用只需配置即可调用，无需了解百度地图 API 的细节。

Java 程序员要不要转 AI？

课程中段，徐书老师回应了一个很多听众关心的问题：Java 程序员想进入 AI 行业，是否必须转行。

他的答案是分两个方向。一是“vibe coding”，即用 Codex、Claude Code 这类工具让 AI 提升自己的开发效率，把需求用 Markdown 描述清楚后交给 AI 生成；二是做 AI 应用开发工程师。

他特别强调，当下主流大模型的跑分差距已经不大，决定一个 AI 应用好不好用的，不是大模型本身，而是大模型外面那层“AI 工程”——提示词工程、Tools、MCP、Skill 提供得好不好，以及 AI 应用的自进化能力，能否越用越聪明。

在技术选型上，徐书老师点名了几个可落地的框架：Spring AI 适合轻量级 Agent、聊天机器人；LangChain4j 和 Spring AI Alibaba 可以支撑多 Agent、ReAct 自主规划思考以及基于 Graph 的 Workflow 流程编排，也便于落地 Harness Engineering。他的判断是，Java 生态在两三年前还是一片空白，现在已完全有能力完成 AI 应用开发。

ReAct（Reasoning + Acting） 是一种让大模型交替进行“推理”和“行动”的 Agent 范式。模型先输出思考过程（Thought），决定调用哪个工具（Action），观察工具返回结果（Observation），再基于结果继续推理，循环直至给出最终答案。它使 Agent 能自主拆解多步任务，而不是一次性生成回答。Graph 流程编排 则是把 Agent 的执行过程建模为有向图：节点代表一个处理步骤（如调用某个模型、执行某个工具、条件判断），边代表流转方向。相比 ReAct 的隐式循环，Graph 编排让流程更可控、可观测、可调试，适合企业级复杂业务。LangChain4j 和 Spring AI Alibaba 都提供了对这两类能力的支持，本文提到的 Harness Engineering 即是在此基础上对 Agent 运行框架进行工程化治理。

关于 InBainbone 与微调的务实建议

课程开头，徐书老师对 InBainbone 给出了偏保守的评价：它使用 Kotlin，国内开发者用起来还不太习惯；做 Agent 开发，Spring AI、Spring AI Alibaba 等选择更顺手，没必要单纯跟热点。他提到自己在 InBainbone 0.1 版本发布时就介绍过，但国内实际使用仍然很少。

关于微调，他的定位是：大模型只具备网络训练而来的通用信息，不具备企业垂直业务知识，微调可以把企业数据“存”到基础模型端。但他也坦言，现在微调用得不是很多。

微调（Fine-tuning） 是指在预训练大模型的基础上，用企业自有领域数据继续训练，使模型参数更新、习得垂直业务知识。常见方式包括全参数微调和参数高效微调（如 LoRA）。它的优势是推理时无需附带大量上下文，响应更稳定；局限是成本较高、数据准备复杂，且模型知识更新不如 RAG 灵活。RAG（检索增强生成） 则不改动模型参数，而是在提问时先从知识库检索相关文档，拼入提示词再交给模型生成。两者定位不同：微调偏向“内化能力与风格”，RAG 偏向“外挂实时知识”。本文提到微调可将企业数据“存”到模型端，但因成本与维护问题实际使用不多，RAG 也因此被列入需要覆盖的知识范围。

一套可复用的学习路线

把这节课的内容拆开看，Java 开发者入门 AI 应用的路径大致是：先理解 Tools 让模型调用内部 API，再理解 MCP 对接外部服务，然后用 Skill 规范提示词与技能管理，最后在 Spring AI 2.0 的 Agent 基座上做整合。RAG 因时间关系未在课中展开，但被列入需要覆盖的知识范围。

对于仍在观望的 Java 程序员，这节课传递的核心信息很直接：不必因为大模型很强就觉得自己无用武之地，真正的差异化在于工程层——提示词、上下文、工具与技能的设计，这些恰恰是 Java 工程师可以积累的能力。