Java 架构师的 AI 工程笔记：不学 Python，也能用 Spring Boot 做 AI Agent
10 年 Java 后端经验，做过单体到微服务的迁移。去年开始，我带团队做第二次技术转型：把 AI 能力接进现有业务系统。
现实有点别扭。大部分 AI 教程都围着 Python 转，LangChain、LlamaIndex、CrewAI 这些名字，几乎默认你已经在 Python 生态里了。Java 团队想做 AI，难道还得先整体换语言？
我在项目里对比过 LangChain4j 和 Spring AI Alibaba，最后选了后者。原因不复杂：它把 AI 开发拉回到了 Spring 生态里。ChatClient 的手感接近 JdbcTemplate，Function Calling 的组织方式也更像 Controller 路由，配置还是熟悉的 application.yml。
这事的好处很直接：不用换语言，不用换框架，先把你手里现成的工具栈用起来。
下面这套内容，是我在实际项目里一点点跑出来的。代码都尽量保持可运行，架构决策也会讲清楚取舍。该绕的坑我会直接写出来，省得你再踩一遍。
先看全局地图
正式开始前，先扫一眼这门系列文章的整体结构。不是为了摆图，而是让你知道每一章在系统里处于什么位置。
这张图覆盖了从基础概念到企业实战的整套内容。学到哪一章，回头都能把自己放回这张地图里。
五层系统架构
整个系列围绕一套分层架构展开。每一章不是讲一个孤立技巧，而是在这套架构上逐层补能力：
┌─────────────────────────────────────────┐
│ 接入层 API Gateway / 前端 / 多租户 │ → ch01, ch20
├─────────────────────────────────────────┤
│ 编排层 Graph / Workflow / MultiAgent │ → ch10, ch11
├─────────────────────────────────────────┤
│ 决策层 Agent / ReAct / Context / HITL │ → ch08, ch09
├─────────────────────────────────────────┤
│ 能力层 Tool / Prompt / RAG / Memory │ → ch02-07
├─────────────────────────────────────────┤
│ 基础设施层 安全/成本/测试/可观测/部署 │ → ch14-19
└─────────────────────────────────────────┘
从 Java 架构师的视角看，这就是一套很常见的分层思路。能力层提供零件，决策层负责判断，编排层把流程串起来，基础设施层负责让它能上线、能排障、能迭代。
遇到问题时，先别急着上 Agent
做 AI 系统最容易犯的错，不是不会写，而是上来就把最重的方案端出去。很多场景其实没必要走到 Agent，这棵决策树就是为了减少这种误判：
遇到的问题 推荐方案 对应章节
────────────────────────────────────────────────────────────
需要外部知识？ → RAG → ch06
需要多步推理？ → Agent（ReAct） → ch08
需要结构化流程控制？ → Graph → ch10
需要多角色协作？ → MultiAgent → ch11
需要外部工具？ → Tool / MCP → ch03, ch12
以上都需要？ → 组合架构 → ch13 完整实战
这套判断会贯穿后面的章节。每次讲新技术，我都会先说清楚它适合解决什么，不适合碰什么。AI 系统里，'能不能做'通常不是问题，'值不值得做'才是。
这个系列会做哪些项目
只看概念不动手，学不会。整套内容围绕 1 个主线项目和 3 个企业实战项目展开，覆盖四类典型场景。
主线项目：「票小蜜」机票比价 Agent
它贯穿第 1-13 章，从零搭到可用，第 14-20 章再补生产化能力。
用户说'帮我查明天北京到上海最便宜的机票'，系统会自动查多个平台、比价、给出推荐，等确认后再下单。
用户提问 → 意图理解 → 多平台并行查询 → 比价排序 → 推荐 → 人工确认 → 下单
这个项目之所以适合做主线，是因为它够完整。工具调用、对话记忆、知识库检索、多 Agent 协同、人机协作、安全护栏、可观测性，这些生产级 Agent 常见能力都能覆盖到。
