前言
前面几个系列，我们已经完成了 Java、Spring Boot、MySQL、Redis、项目等内容。
这些能力能让我们写出一个结构完整、可以上线的后端项目。
但 AI Agent 开发和传统后端开发有一个明显区别：
传统后端：开发者提前写好每一步规则
Agent 开发：开发者设计目标、约束和工具，让模型在边界内决定下一步
这并不意味着 Java 后端开发者要放弃原来的能力，更不是要求去训练模型、研究算法论文。
恰恰相反，Java 后端的很多能力，在 Agent 项目中非常重要。
这一篇先把路线讲清楚：Java 后端应该如何转向 Agent 开发，到底该学什么、不该急着学什么，以及后面这个系列会怎么推进。
一、Agent 开发到底是什么
很多人刚接触 AI 时，会把 Agent 理解成“接一个聊天接口”。
其实聊天接口只是 Agent 的一部分。
一个比较完整的 Agent，通常具备下面几种能力：
例如用户说：
帮我查一下本月请假情况，如果超过 3 天就提醒我。
普通聊天机器人可能只会回答：
请假超过 3 天需要注意工作安排。
但真正的业务 Agent 应该能够：
识别用户意图
|
调用请假查询工具
|
获取当前用户本月请假天数
|
根据业务规则判断是否超过 3 天
|
生成个性化提醒
这里的大模型负责理解和决策，真正的数据查询和业务执行仍然由后端工具完成。
二、Java 后端开发者有哪些天然优势
很多人看到 Agent、RAG、MCP、Function Calling 这些词，会觉得必须转 Python 才能做。
实际上并不是。
Java 后端开发者进入 Agent 开发，有不少已有能力可以直接迁移。
1. 接口设计能力
Agent 想调用工具，本质上就是调用接口或方法。
例如：
查询订单
查询库存
创建工单
发送通知
获取用户信息
这些能力本身就是 Java 后端擅长的事情。
Agent 开发中，工具设计得是否清晰、安全、稳定，往往比“模型多聪明”更重要。
2. 业务建模能力
传统后端开发要理解：
用户
订单
商品
库存
支付
权限
Agent 开发同样需要理解业务边界。
例如一个“订单助手”不应该直接拥有所有权限，它只能在允许的范围内：
查询订单
查询物流
申请退款
创建售后工单
至于是否允许退款、退款金额如何计算、订单状态能否修改，仍然应该由后端业务规则决定。
模型不能替代业务规则。
3. 数据库和 Redis 能力
Agent 也需要数据存储。
例如：
MySQL、Redis、消息队列、缓存、异步任务，这些都是 Java 后端原本就熟悉的能力。
4. 安全和权限能力
Agent 一旦能调用工具，就必须考虑权限。
例如用户说：
删除所有过期订单
模型可以识别意图，但不能直接执行危险操作。
正确流程应该是：
用户请求
|
Agent 识别操作意图
|
后端检查用户权限
|
必要时要求二次确认
|
业务服务执行操作
|
记录审计日志
所以 JWT、拦截器、权限校验、操作日志、参数校验这些能力，在 Agent 项目中反而更加重要。
5. 部署和可观测能力
Agent 项目不是“接口返回一句话”就结束了。
还需要关注：
模型调用是否成功
工具是否超时
Token 消耗多少
接口响应多久
哪一步失败
用户输入是否异常
前面学习过的 Docker、Nginx、日志、traceId、配置脱敏等内容，都可以继续复用。
三、Java 转 Agent 开发需要补什么能力
Java 后端基础可以复用，但还需要补齐 Agent 相关知识。
建议重点补下面七类能力。
1. 大模型 API 基础
需要理解：
这里不是研究模型训练原理，而是学会正确使用模型 API。
2. Prompt Engineering
Prompt 不只是“写一句提示词”。
在项目中，更像是给 Agent 定义工作规则，例如：
你是谁
你能做什么
你不能做什么
什么时候调用工具
输出格式是什么
遇到不确定信息时怎么办
Prompt 是 Agent 的行为边界之一。
3. 结构化输出
后端系统不能只接收一段自然语言。
例如我们希望 Agent 返回：
{
"intent": "CREATE_TICKET",
"priority": "HIGH",
"summary": "用户无法登录系统"
}
这样后端才能继续执行业务逻辑。
所以要学习如何让模型稳定返回 JSON、枚举、字段和固定格式。
4. Tool Calling
Tool Calling 是 Agent 开发里非常核心的一部分。
大模型本身不知道你的数据库内容，也不能直接调用公司内部接口。
开发者需要把能力封装成工具，例如：
queryOrder
queryProductStock
createWorkOrder
sendMessage
getCurrentWeather
模型负责选择工具，后端负责真正执行工具。
5. Agent Loop 和 ReAct
一个 Agent 通常不是“模型调用一次就结束”。
它可能需要：
思考
|
调用工具
|
获得结果
|
继续判断
|
再次调用工具
|
输出最终答案
这种“思考、行动、观察”的循环，就是后面会讲到的 ReAct 模式。
6. Memory、RAG 和 MCP
这三个概念很容易一起出现，但职责不同。
Memory：记录用户和会话相关信息
RAG：从知识库中检索资料，补充模型不知道的事实
MCP：让 Agent 用统一方式连接外部工具和服务
后面会分别拆开讲，不能混在一起理解。
7. 评估、安全和成本控制
Agent 项目上线后，真正难的不是“能不能回答”，而是：
这些问题决定 Agent 能不能真正进入业务系统。
四、推荐学习路线
这一套系列建议按四个阶段学习。
第一阶段：建立大模型和 Agent 基础
对应文章：
第 1 篇：Java 后端如何转向 Agent 开发
第 2 篇：Agent 系统由什么组成
第 3 篇：大模型 API 基础
第 4 篇：Prompt Engineering
第 5 篇：结构化输出
这个阶段的目标是：知道模型能做什么、不能做什么，以及如何让模型输出稳定结果。
第二阶段：让 Agent 真正行动
对应文章：
第 6 篇：Tool Calling
第 7 篇：ReAct 模式
第 8 篇：Workflow 和 Agent 怎么选
第 9 篇：Agent Memory
这个阶段的目标是：让 Agent 不只是聊天，而是能在规则内调用工具、处理多步骤任务。
第三阶段：让 Agent 使用外部知识和服务
对应文章：
第 10 篇：RAG 知识库
第 11 篇：MCP
第 12 篇：多智能体协作
这个阶段的目标是：让 Agent 能读取项目资料、调用外部服务，并和其他 Agent 分工协作。
第四阶段：让 Agent 可以上线
对应文章：
第 13 篇：质量评估和可观测性
第 14 篇：安全、权限和成本控制
第 15 篇：完整项目实战
这个阶段的目标是：把 Agent 从 Demo 推进到可维护、可排查、可部署的项目。
五、Agent 开发和传统后端开发的思维差异
传统后端代码通常追求：
输入确定
|
固定逻辑
|
输出确定
例如：
if (status == 1) {
return "启用";
}
return "禁用";
Agent 开发中，模型输出具有概率性。
用户可能会这样表达同一个需求：
帮我查订单
查一下我昨天买的东西
我那个包裹到哪了
订单怎么还没到
后端很难为每种说法都写固定规则。
这时可以让模型识别用户意图，再由工具查询真实数据。
但需要注意：
模型可以理解自然语言
业务系统必须执行确定规则
不能把关键业务判断完全交给模型。
例如：
退款金额
库存扣减
支付状态
权限判断
订单状态流转
这些仍然应该由后端代码保证正确性。
六、哪些内容不建议一开始就学
1. 不建议一开始研究模型训练
大多数 Agent 应用开发，重点是调用已有模型和构建应用。
模型训练、微调、分布式训练属于另一条路线。
如果目标是快速做出业务 Agent，先不必从算法和论文开始。
2. 不建议一开始就做多智能体
多智能体听起来很酷，但复杂度很高。
它会带来：
更推荐的顺序是：
单模型调用
|
单 Agent + 单工具
|
单 Agent + 多工具
|
RAG
|
MCP
|
多 Agent
3. 不建议让模型直接操作数据库
不要让模型生成 SQL 后直接执行。
更安全的方式是：
模型选择工具
|
工具校验参数
|
业务服务执行固定 SQL
|
返回受控结果
模型只负责“决定调用什么能力”，不直接拥有数据库权限。
七、建议第一个 Agent 项目做什么
不建议一开始做“万能智能助手”。
建议做一个业务边界清晰的小项目，比如：
项目知识库助手
它可以回答：
后续还可以逐步增加：
文档 RAG
项目文件检索
工具调用
部署状态查询
日志辅助分析
这个项目和前面 Java、Spring Boot、Docker 系列衔接比较自然，也适合做成最终实战项目。
八、常见误区
1. Agent 等于聊天机器人
不完全是。
聊天机器人重点是对话，Agent 更强调目标、工具、执行和反馈。
2. Agent 能替代所有业务代码
不能。
模型负责理解和协调，业务代码负责数据、权限、规则和副作用操作。
3. 接上模型 API 就算 Agent
不算。
如果只有输入一句话、返回一句话，更接近普通对话应用。
Agent 至少应该具备一定的任务拆分、工具调用、上下文或状态管理能力。
4. 模型回答看起来合理就代表正确
不一定。
模型可能生成语句通顺但事实错误的回答。
所以涉及真实数据时，应该通过工具、RAG、权限校验和结果验证降低风险。
九、总结
这一篇我们没有急着写代码，而是先明确了 Java 后端转向 Agent 开发的路线。
核心结论是：
下一篇我们继续拆解一个完整 Agent 到底由哪些部分组成。
