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