本文为Java自学Agent系列第4篇，带你深入Agent核心机制，从Tools工具调用、Memory记忆存储到Planning规划执行，全面解析如何将大模型从"能聊天"升级为"能干活"。结合Java工程化视角，提供工具描述、参数校验、错误处理等实用技巧，助你快速上手大模型开发。
你请了个特别聪明的助理，脑子灵光、见多识广。但你没给他配手机、没给他开系统权限，他就只能坐在工位上跟你聊天，什么实事也干不了；而且他记性极差，你上句话说完他下句话就忘；遇到麻烦事，他也不知道该先干什么、后干什么。Agent 也是这样。Tool 是它的手脚，Memory 是它的记事本，Planning 是它的做事章法。这三样配上，它才真正开始"工作"。
一、给 Agent 装"手脚"：Tool 与 Function Calling
先说一个关键机制：模型本身不会"执行"任何代码，它只能"提出调用请求"。
想象一个场景，用户说：“帮我查一下订单 ORD-123456 的状态，然后提醒我。”
如果没有工具，模型只能瞎编：“您的订单正在派送中。”——它根本没有权限，也不知道真实状态。
有了 Function Calling，流程变成这样：
重点在第 2 步： 模型不是"直接执行"，而是输出一段结构化的"调用指令"（哪个函数、什么参数）。框架（如 LangChain4j、Spring AI）拿到这段指令后，由你的 Java 代码去真正执行，再把结果回传给模型。
Note
用 Java 类比： 模型就像"服务注册中心"的发现者——它看到工具清单，选出合适的工具并填好参数，但真正干活的是注册中心背后的那个
@Service。执行权始终在你手里，这是安全性的基石： 模型只能调用你暴露的工具，绝碰不到你不想给它的能力。
1.1 实战：把 Java 方法变成 Agent 的"手脚"
以 LangChain4j 为例（第 5 篇会完整实战，这里先看核心概念）。定义一个工具，就是把一个普通 Java 方法加上@Tool注解：
import dev.langchain4j.agent.tool.Tool; public class OrderTools { @Tool("根据订单号查询订单状态，返回订单当前物流状态和预计送达时间") public String queryOrder(String orderId) { // 这里写你的真实业务代码：查数据库、调第三方物流接口…… return "订单 " + orderId + " 状态：已发货，预计明天 18:00 前送达"; } @Tool("根据订单号查询售后进度，返回当前处理阶段和下一步动作") public String queryAfterSale(String orderId) { return "订单 " + orderId + " 售后状态：退款审核中，预计 24 小时内完成"; } }然后把这个工具"装配"到 Agent 上：
import dev.langchain4j.model.openai.OpenAiChatModel; import dev.langchain4j.service.AiServices; public class Main { public static void main(String[] args) { OpenAiChatModel model = OpenAiChatModel.builder() .apiKey(System.getenv("OPENAI_API_KEY")) .modelName("gpt-4o-mini") .temperature(0.0) // 工具调用场景，建议调低温度，保证输出稳定 .build(); Assistant assistant = AiServices.builder(Assistant.class) .chatLanguageModel(model) .tools(new OrderTools()) // 注入工具：这不就是 @Autowired 吗？ .build(); String reply = assistant.chat("帮我查下 ORD-123456 到哪了"); System.out.println(reply); } interface Assistant { String chat(String userMessage); } }运行后，模型会自动判断该调用queryOrder，把真实结果整理成回答返回。全程没有你写一行"调度逻辑"——这正是 Agent 和传统编程的区别。
1.2 工具描述：写给 AI 看的"接口文档"
这里有一个 Java 开发者最容易忽略、却最重要的细节：@Tool注解里的那段描述文字，是写给模型看的，不是给人看的。
回想你写 Swagger 注释的经历：注释写得好，前端调得准。工具描述同理——模型靠这段描述判断"什么时候该用这个工具、参数怎么填"。 描述写得烂，模型就可能在错误的时候调用，或传错参数。
| 描述写法 | 效果 |
|---|---|
@Tool("查询订单") | 太模糊，模型不知道何时用、参数是什么格式 |
@Tool("查询订单状态，仅在用户询问物流/发货/预计送达时调用") | 明确触发条件，模型不会乱调 |
@Tool("查订单状态")+ 参数String orderId | 模型不知道 orderId 长什么样，可能传错 |
| 描述里注明格式：“参数 orderId 为 10 位订单号，形如 ORD-123456” | 模型能正确填参 |
写工具描述的三个要点： 说明"何时用"（触发条件）；说明"参数格式"（给示例）；说明"边界"（做不到什么、什么时候不要调用）。
Tip
核心心法： 工具描述就是"AI 世界的 API 文档"。你给每个工具写描述花的五分钟，能省下你排查"模型为什么不调工具"的五小时。
1.3 工具系统的工程化设计：让工具"靠谱地"被调用
（本小节讲的是工具的"工程化"——让工具能跑起来，和让工具"靠谱地"被调用，是两回事。）
单个工具能跑起来只是第一步。真上生产，你的每个工具都得过一遍"工程化体检"——下面六个问题，是 Java 开发者一眼就能上手的检查清单：
① Schema 校验：参数对了才干活。 模型填参可能不靠谱。你的工具方法第一行就该做参数校验：orderId是不是 10 位订单号？amount是不是合法数字？这就像你平时给接口加@Valid校验注解，只不过校验对象换成了"模型填的参数"。 参数不合法时，返回明确的错误提示，让模型知道"为什么失败、该怎么改"，而不是抛个莫名其妙的异常。
@Tool("查询订单状态，参数 orderId 为 10 位订单号，形如 ORD-123456") public String queryOrder(String orderId) { if (orderId == null || !orderId.matches("ORD-//d{6}")) { return "订单号格式不正确，应为 10 位订单号（形如 ORD-123456），请确认后重试"; } // ... 正常查询逻辑 }② 超时控制：不能无限等。 工具背后调用的是数据库、第三方接口、内部服务，任何一个卡住，整个 Agent 就悬在那儿了。给每个工具调用设置超时时间（比如 3 秒），超时就返回"查询超时，请稍后重试"，让模型走降级逻辑。这正是你平时调外部接口设超时的习惯。
③ 幂等性：重复调用也不能出事。 网络抖动、Agent 重试，都可能导致同一个工具被调用两次。对于"发短信、扣款、建单"这类有副作用的操作，必须设计成幂等的——带业务单号做去重，重复执行结果一致。你在分布式系统里做的幂等设计，原封不动搬过来就行。
④ 错误处理：把"失败"结构化地告诉模型。 工具失败时，不要只给模型一个空字符串或堆栈，而是返回结构化的错误信息：{ "success": false, "reason": "用户不存在" }。模型看到这个，才能正确判断下一步（换个订单号查？还是转人工？）。错误信息就是给模型看的"调试信息"，写清楚对 Agent 的稳定性至关重要。
⑤ 审计日志：谁在什么时候调了什么。 每次工具调用都要记录：哪个用户、哪个会话、调了哪个工具、传了什么参数、结果如何。这一条既是排查问题的需要，也是安全审计的底线——出了纠纷能追溯。类比：你给核心接口打的业务日志。
⑥ 权限边界：只给模型最小可用权限。 工具清单要遵循最小授权原则：模型只需要"读订单"的能力，就别给它"删订单"的工具。上生产前，把工具清单像权限表一样过一遍——每个工具都应该回答一个问题：如果模型在错误场景调用了它，最坏会怎样？
把这六条做成一张检查表，比任何架构都管用：
| 工程点 | 一句话要求 | Java 类比 |
|---|---|---|
| Schema 校验 | 参数不合法就明确拒绝 | @Valid注解 |
| 超时控制 | 每个调用设超时，超时走降级 | HttpClient 超时配置 |
| 幂等性 | 有副作用的操作可重复执行 | 分布式幂等设计 |
| 错误处理 | 失败返回结构化错误给模型 | 统一异常返回体 |
| 审计日志 | 每次调用留痕可追溯 | 业务操作日志 |
| 权限边界 | 最小授权，危险工具不暴露 | RBAC 权限控制 |
二、给 Agent 装"记事本"：Memory 记忆
2.1 为什么需要记忆
还记得第 3 篇说的吗？大模型是无状态的——每次调用它都"失忆"，不记得你上一轮说了什么。
想象一个没有记忆的客服 Agent：用户说"我叫小王，刚才说的那个订单"，Agent 一脸茫然：“哪个订单？您刚才说什么了吗？”——这体验没法用。
Memory 就是给 Agent 加"记事本"。按作用时长分三类：
| 记忆类型 | 类比 Java | 存什么 | 存活周期 |
|---|---|---|---|
| 短期记忆 （对话记忆） | HttpSession | 本次对话的上下文（说了什么、答了什么） | 一次对话结束即清空 |
| 长期记忆 （持久记忆） | 数据库持久化 | 用户偏好、历史事实、重要结论 | 跨对话长期保留 |
| 工作记忆 （任务记忆） | ThreadLocal | 当前任务执行过程中的中间结果 | 本次任务完成即清空 |
2.2 短期记忆：最常用的记忆
在 LangChain4j 里，一条配置就能开启：
import dev.langchain4j.memory.chat.MessageWindowChatMemory; MessageWindowChatMemory memory = MessageWindowChatMemory.withMaxMessages(10); Assistant assistant = AiServices.builder(Assistant.class) .chatLanguageModel(model) .tools(new OrderTools()) .chatMemory(memory) // 记住最近 10 轮对话 .build();它的实现原理，Java 开发者秒懂：把历史消息数组不断塞回给模型。 每一轮对话，框架都把"历史消息 + 新提问"拼成messages发给模型，模型"看到"了历史，自然就"记得"了。
2.3 长期记忆：像数据库一样持久化
短期记忆有个致命问题：上下文窗口有限，对话一长就装不下（第 3 篇讲过）。这时候就要用长期记忆——把重要的信息抽取出来，存到数据库/向量库，下次对话时再"检索"回来。
// 伪代码示意：把关键信息持久化，下次对话时注入 memoryService.save("用户小王偏好夜间下单，收货地址为上海"); // 新会话开始时： String userProfile = memoryService.load("小王"); String systemPrompt = "已知用户信息：" + userProfile + "/n请据此回答。";2.4 记忆的工程实践：别让记忆吃穷你
Memory 不是"越多越好"，它有代价。三个实战建议：
记忆的每一轮都要花 Token。 历史消息塞得越多，单次调用的成本越高、速度越慢。你写 SQL 会避免
SELECT *，管理记忆也要学会"只带需要的字段"。短期记忆窗口（如 10 轮）是性能与成本的平衡点。主动压缩与摘录。 对话太长时，不要盲目加大窗口，而是让模型先做"摘要"：把 50 轮对话总结成 10 条要点，只保留摘要。这就像你会把冗长的日志归档，只留关键信息。
敏感数据不进记忆。 身份证、银行卡、密码绝不能存进长期记忆或发往模型。记忆系统要有访问控制——只有授权的工具能读特定用户的记忆。
Warning
注意： 记忆设计是 Agent 架构里最容易被低估的一环。很多 Agent 项目上线后"失忆"或"串台"，本质都是记忆设计没做好——要么窗口太短记不住，要么装太满又贵又乱。
三、让 Agent 学会"思考"：Planning 与 ReAct
3.1 为什么需要规划：从"单次问答"到"多步任务"
先看两种任务的差别：
任务 A（单步）： “用一句话介绍什么是 Spring 事务。” → 模型一次就能答好，不需要工具，不需要规划。
任务 B（多步）： “分析上周订单增长情况，生成图表，把结论发到钉钉群里。” → 这一个任务其实包含三个动作：查数据、生成图表、发消息。没有 Planning，模型面对任务 B 就只能走一步看一步地硬试——虽然它能靠逐轮推理（也就是下一节的 ReAct）串起三个工具，但容易绕弯路、Token 消耗大，缺少全局章法。
有了 Planning，模型能先把任务拆成子步骤，再逐个执行：
用 Java 类比： 这就像你写一个 Service 方法，里面依次调用了orderDao.query()、chartService.generate()、dingtalkClient.send()——只不过调用顺序和参数是模型在运行期自己决定的，而不是你在编译期写死的。
3.2 ReAct 模式：思考 → 行动 → 观察，循环往复
ReAct 是 “Reasoning + Acting” 的缩写，是目前最主流、最通用的 Agent 执行模式。它的核心是一个循环：
翻译成大白话：做一步、看一眼结果、再决定下一步。 跟你在while循环里写业务逻辑，用返回值决定下一步分支，是同一回事。
一个具体的 ReAct 执行过程（用户问：“我昨天下的订单 ORD-123456 到哪了？顺便看看今天上海天气。”）：
思考(Thought)： 用户要查订单状态，还要查上海天气，是两个独立需求 行动(Action)： 调用 queryOrder("ORD-123456") 观察(Observe)： 返回"订单 ORD-123456 已签收" 思考(Thought)： 订单查完了，接着查天气 行动(Action)： 调用 getWeather("上海") 观察(Observe)： 返回"上海 晴 28°C" 思考(Thought)： 两个需求都完成了，可以汇总回复 回答(Answer)： 您的订单已于今日上午签收；上海今天晴，28°C。注意观察这个循环的精髓：每次"思考"都基于上一次"观察"的真实结果，而不是模型凭空猜测。这大大降低了幻觉——因为它每一步都有工具返回的"事实"支撑。
Note
Java 视角总结： ReAct = 一个 while 循环 + 模型做判断 + 你的工具做执行。循环条件是"任务未完成"，判断逻辑是"下一步干嘛"，执行体是你的 Service 方法。
3.3 Plan-and-Execute：先定计划，再逐步执行
ReAct 是"边想边做"，而 Plan-and-Execute 是"先想好，再动手"。两者的区别，就像"见招拆招"和"按作战计划推进"。
优势： 计划先定好，逻辑清晰、可控性强，适合"步骤明确、可以预先规划"的任务；
劣势： 计划是"预测"，如果中途情况变化（工具失败、数据缺失），可能不按剧本走，需要重新规划。
两种模式的选型对比：
| 维度 | ReAct（边想边做） | Plan-and-Execute（先想再做） |
|---|---|---|
| 执行风格 | 一步一观察，灵活应变 | 先拆解计划，按计划推进 |
| 适合场景 | 步骤不固定、需要探索的任务 | 步骤相对固定、可预判的任务 |
| 优点 | 应变能力强，不易跑偏 | 规划清晰，可观测性好 |
| 缺点 | ||
| Agent 模式 | 一句话描述 | Java 工程类比 |
| — | — | — |
| ReAct | 思考→行动→观察，循环直到完成 | while循环 + 策略分发 |
| Plan-and-Execute | 先规划任务清单，再依次执行 | 工作流引擎 / 任务调度 |
| Router（路由） | 根据意图把请求分给不同 Agent | 网关路由 / 策略工厂 |
| Reflection（反思） | Agent 自己审查、修正自己的输出 | 代码 Review + 二次迭代 |
| Multi-Agent | 多个 Agent 分工协作、互相调用 | 微服务编排 / 消息驱动 |
其中 Multi-Agent 会在第 7 篇详细展开，这里先记住结论：Agent 的编排模式，就是你熟悉的架构模式的"动态化"。 以前是你在代码里写死路由、写死步骤；现在是模型在运行期自己路由、自己编排。
3.5 什么时候让 Agent 规划，什么时候写死流程？
新手最容易犯的错，是所有逻辑都交给模型自由发挥。这是不行的——模型自由发挥意味着不确定、不可控、成本高。给 Java 开发者一条实用的决策准则：
| 情况 | 做法 |
|---|---|
| 流程固定、不容出错 （支付、审批、结算） | 写死代码 / 工作流 ，Agent 只做辅助判断 |
| 步骤可预判、但内容多变 | Plan-and-Execute 拆步骤 |
| 步骤不固定、需要探索试错 | ReAct 自由发挥 |
| 高确定性 + 高成本敏感 | 尽量少用模型，能写死就写死 |
核心原则
用确定性兜底，用 Agent 补灵活性。就像微服务架构里，核心交易链路用强一致的方案，边缘功能才允许最终一致——Agent 架构同理：关键路径写死，开放环节交给模型。 这个"写死 vs 自由"的取舍，在第 6 篇讲 Workflow 时还会再见到。
这一篇，Agent 的"四肢"已经齐了：手脚（Tool）、记事本（Memory）、思考（Planning）。 到目前为止，一个 Agent 能理解指令、能调用工具、能记住上下文、能拆解任务——看起来已经挺能干了。
但还差最要命的一块：用户问的是你公司内部的事情，可模型根本不知道你公司的业务知识。 光靠它脑子里的"全网知识"，答的都是通用话术。怎么把"你的知识"喂给它？这是下一篇的主题——RAG 检索增强生成，并且我们会直接动手，用 Java 做一个完整的智能客服 Agent。
大模型的知识又多又杂，到底怎么学？
做这行久了，被问最多的问题就一个：大模型的知识又多又杂，我到底先学啥？翻了一堆资料，看啥都像重点，结果啥都没学进去。今天把我自己一路摸出来的顺序捋一遍，零基础、应届生、转行的都适用。跟着走，至少方向不乱、不瞎忙，学完拿得出手。
第一阶段（10天）：初阶应用
这一阶段就一个目标：把大模型真正"玩明白"，不是只会聊天那种，而是能调教它、能用代码把大模型和业务接起来。
- 大模型 AI 能干什么？
- 大模型是怎样获得「智能」的？
- 用好 AI 的核心心法
- 大模型应用业务架构
- 大模型应用技术架构
- 代码示例：向 GPT-3.5 灌入新知识
- 提示工程的意义和核心思想
- Prompt 典型构成
- 指令调优方法论
- 思维链和思维树
- Prompt 攻击和防范
- …
第二阶段（30天）：高阶应用
这阶段正式进实战，目标很实在：做出两个能拿出手的东西——一个私有知识库，一个 agent 对话机器人。
为什么要做 RAG
搭建一个简单的 ChatPDF
检索的基础概念
什么是向量表示（Embeddings）
向量数据库与向量检索
基于向量检索的 RAG
搭建 RAG 系统的扩展知识
混合检索与 RAG-Fusion 简介
向量模型本地部署
…
走完这 30 天，Python 或 JavaScript 背景的基本能独立做一套 RAG 应用，简历上也敢写"大模型应用开发"了。
第三阶段（约20天）：动手微调
学到这，你已经开始 “造” 模型了 —— 通过微调，搞出垂直领域的专用小模型。
- 为什么要做 RAG
- 什么是模型
- 什么是模型训练
- 求解器 & 损失函数简介
- 小实验2：手写一个简单的神经网络并训练它
- 什么是训练/预训练/微调/轻量化微调
- Transformer结构简介
- 轻量化微调
- 实验数据集的构建
- …
恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。
到此为止，大概2个月的时间。你从 “只会用” 变成 “能造” 的 AI 小子。那么你还想往下探索吗？
想要入局AI大模型赛道、抢占行业红利的朋友，微信扫描下方CSDN官方认证二维码，即可100%免费领取全套学习资料！
第四阶段（20天）：商业闭环，部署落地
技术学完，落地才算数。这阶段带你搞明白大模型怎么真正跑起来、用起来。
- 硬件选型
- 带你了解全球大模型
- 使用国产大模型服务
- 搭建 OpenAI 代理
- 热身：基于阿里云 PAI 部署 Stable Diffusion
- 在本地计算机运行大模型
- 大模型的私有化部署
- 基于 vLLM 部署大模型
- 案例：如何优雅地在阿里云私有部署开源大模型
- 部署一套开源 LLM 项目
- 内容安全
- 互联网信息服务算法备案
- …
想要入坑大模型的朋友，给大家准备了一份2026 年最新 AI 大模型全套学习资料：
1、大模型系统化学习路线
2、大模型学习视频教程
3、大模型学习书籍&电子文档
4、AI大模型最新行业报告
5、大模型项目实战&配套源码
6、2026大模型大厂面试真题
7、为什么要学习大模型？
我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年，人才缺口已超百万，凸显培养不足。随着AI技术飞速发展，预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。
8、适合谁学？
- 传统后端 / Java / 前端开发，想转型 AI 应用
- 大学生、应届生，想拿更好的 offer
- 产品经理、运营，想武装职业竞争力
- 技术负责人，想给团队落地提效
学习是反人性的，但回报是真金白银。技术会更新，赛道会切换，但只要你先动手，机会就永远站在你这边。
9、这些资料真的有用吗？
这份资料由我和鲁为民博士(北京清华大学学士和美国加州理工学院博士)共同整理，现任上海殷泊信息科技CEO，其创立的MoPaaS云平台获Forrester全球’强劲表现者’认证，服务航天科工、国家电网等1000+企业，以第一作者在IEEE Transactions发表论文50+篇，获NASA JPL火星探测系统强化学习专利等35项中美专利。本套AI大模型课程由清华大学-加州理工双料博士、吴文俊人工智能奖得主鲁为民教授领衔研发。
资料内容涵盖了从入门到进阶的各类视频教程和实战项目，无论你是小白还是有些技术基础的技术人员，这份资料都绝对能帮助你提升薪资待遇，转行大模型岗位。
想要入局AI大模型赛道、抢占行业红利的朋友，微信扫描下方CSDN官方认证二维码，即可100%免费领取全套学习资料！
好了，就写到这。路线是死的，人是活的，卡住了随时来问我。觉得有用就点个收藏，别让它进收藏夹吃灰——动起来比啥都强。
