夜雨聆风✦ 干货分享 ✦
02 / Agent 的三个零件：模型、工具、记忆
◆
"
这是「Java + Spring AI 开发 Agent 应用」保姆级连载的第 2 章。 上一篇（第 1 章）我们通了"大脑"——明白了模型是什么、它怎么理解你的话、Spring AI 又帮我们省了哪些搬运工作。 这篇纯概念，不写代码，我们只干一件事：搞清楚一个 Agent 到底由什么组成，以及"为什么非要这些零件不可"。
"
如果你读上一篇时心里隐约有一点慌——"这不就是个聊天机器人吗？跟 Agent 有什么关系？"——恭喜你，你问到了点子上。这一章就是来解开这个结的。
010. 开场：一条会失忆的金鱼
先听我说个小场景。
你让 AI 助手帮你整理一份周报："把本周的项目进展汇总一下，顺便把我上次提到的那个风险点也写上。"
助手回答："本周进展……风险点？不好意思，我不记得你之前说过什么风险点。"
你："就是我周三说的那个，服务器快到期那个！"
助手："抱歉，我没有关于周三对话的记忆。"
你是不是已经想摔键盘了？
这像什么？像一条金鱼。金鱼只有七秒记忆，你刚跟它说完话，它转头就忘。一个没有记忆的 Agent，就是这条金鱼——你跟它聊了半小时，它隔天再看，脸是陌生的，啥都不记得。
如果你曾经在某个 AI 产品里遇到"说了跟没说一样"的糟心体验，十有八九就是它没有设计好"记忆"——而很多团队根本没意识到这还是一个可以设计的东西。
这一章，我们把一个 Agent 拆开，看看它到底由哪几个零件拼成，每个零件解决什么问题，为什么缺一个都不算"Agent"，只能算"高级聊天框"。
021. 模型：那颗会"犯迷糊"的大脑
任何一个 Agent 的核心，都是一颗大模型（LLM）做的大脑。它负责两件事：理解你的意图，决策下一步该干什么。
听起来很全能，对吧？但它其实是"能力很强、毛病也不少"的一个家伙。别被它唬住，先看看它三个明确的短板，记住了，后面全用得上：
短板一：会"幻觉"。 它特别会一本正经地胡说八道。你问它"DocMind 项目有多少行代码"，它可能煞有介事地告诉你"大概 8000 行"——但它根本没见过你的代码，它只是在编一个听起来合理的数字。它不是在骗你，它是在"猜"，而且猜的时候自己都不知道是猜的。这就是著名的"幻觉"。
短板二：不会算账。 你问它 17×23 等于多少，它可能出错。为什么？因为它是"说下一个最可能的词"的机器，不是一个计算器。它擅长的是"语言规律"，不是"数学精确"。让它做复杂运算，等于让一个文科生心算三位数乘法——不是不行，是不稳。
短板三：知识有"保质期"。 它的知识停在训练完成的那一天。模型训练要花巨量算力和时间，不可能天天更新。所以它不知道今天的天气、最新的新闻、你公司内部的文档。它的知识是"过去的、通用的"，不是"现在的、你专属的"。
现在我们得到了一个关键认知：大脑很强，但它瞎、它笨、它落伍。 那怎么办？总不能因为它有毛病就不用吧。
好，接下来就到重点了：Agent 之所以是 Agent，不是因为它有个大脑，而是因为它有办法补上大脑的这三个窟窿。
032. 工具：给大脑装上"手和眼"
补窟窿的办法，就是给大脑配备工具（Tools）。工具就是大脑的"手和眼"，让它能伸出手去摸、睁开眼睛去看。三个短板，正好对应三类工具：
你看出来了吧——工具不是可有可无的装饰品，它是大脑缺口的"外挂器官"。
不会算账？那模型就不算，它调一个"计算器工具"，让真正的代码去算，拿到精确结果再告诉你。 知识过期？那模型就不凭记忆，它调一个"搜索工具"，上网查最新的回来。 你的业务数据（合同、报告、PDF）模型根本没学过？那它调一个"文档工具"，去你的文件里把相关内容捞出来。
到这里，"模型 + 工具"合在一起，就已经比一个光秃秃的大模型强太多了。但还没完——你还缺刚才那条金鱼的病根。
043. 记忆：别做那条金鱼
第三块拼图，是记忆（Memory）。
记忆分两层，你平时都在不知不觉地使用：
短期记忆 = 对话历史。 就是你跟 AI 一来一回的那些话。你周三提到"服务器快到期"，这个信息得留到周五还能被想起来，全靠短期记忆把对话记录下来、喂回给模型。没有它，模型每次都是"失忆状态"，上一条说的下一条就忘。
长期记忆 = 用户偏好、常用文档。 这是更高级的一层。比如用户永远用中文、用户是老客户所以要客气点、用户上次存过一份"服务器清单"——这些低频但重要的信息，应该被提炼出来，放进一个"长期记忆库"，每次对话都能翻出来用。
记住这个血泪结论：短期记忆让你"聊得下去"，长期记忆让你"认得这个人"。 二级记忆一加，Agent 才算真正"活"了，不再是金鱼。
"
小提示：关于"记忆到底放哪、放什么、怎么不漏不脏"，第 7、8 章我们会用一个专门的东西（RAG）把它做实。现在你只需要建立观念：记忆是可以设计、可以架构的，不是玄学。
"
054. ReAct：大脑的"想→做→看"循环
零件齐了（模型、工具、记忆），它们是怎么协同干活、有秩序地运转的呢？
这里要介绍一个绕不开的经典套路，叫 ReAct。
别被这个高大上的名字唬住，它就是个循环，一共三步：
1 ┌──────────────────────────────┐
2 ▼ │
3 ┌─────────┐ ┌─────────┐ ┌──────────┐
4 │ Reason │ → │ Act │ → │ Observe │
5 │ （想） │ │ （做） │ │ （看结果）│
6 └─────────┘ └─────────┘ └──────────┘
7 算一步： 调工具： 拿到结果
8 该咋办 动手执行 再回来看
翻译成人话，就是一个死循环：
- Reason（想）
：面对问题，动脑子——"我需要知道最新股价，可我现在不知道。" - Act（做）
：决定行动——"那我得去查一下。" - Observe（看）
：真的去查，把结果拿回来——"哦，查到了，股价是 128 块。" - 回到第 1 步
：拿到结果后再想——"那现在可以算这笔交易赚不赚了。"
够不够？就像你做饭：先想菜谱（Reason），进厨房拿菜（Act），看看菜新不新鲜够不够用（Observe），再想下一步怎么切。每一步都是"想→做→看"，看完了再想，直到菜端上桌。
这一步关键话，请你记死：
"
Spring AI 已经把这个循环给你封装好了，你后面写代码的时候，基本不需要手写这个循环——框架帮你转了。
"
但，懂原理和会调参是两码事。 你后面跑出 Bug 了（比如模型反复去调同一个工具、陷在死循环里、或者拿到结果后不知道收手），你要是不懂 ReAct 这个"想→做→看"的结构，你根本不知道去哪儿找问题。先弄懂这台机器的传动原理，出毛病了你才知道去拧哪颗螺丝。
065. Function Calling 的本质：模型不"做"，只"说"
说到工具，就绕不开一个词：Function Calling（函数调用）。这可能是整个 Agent 领域最容易被误解的概念，我们今天必须把它掰开揉碎。
请先记住一句话：
"
模型并不"执行"工具，模型只是"告诉你该调哪个工具、传什么参数"。真正的执行，永远发生在你的 Java 代码里。
"
什么意思？很多人第一次接触会以为：模型神通广大，能直接操纵文件系统、直接上网、直接改数据库。大错特错。
真实流程是这样的：
1你：帮我查一下今天天气
2│
3▼
4┌──────────────┐
5│大模型│←它只是"读懂了你的意图"
6└──────────────┘
7│
8│返回：{"tool":"查询天气","参数":{"城市":"北京"}}
9▼
10┌──────────────┐
11│ Java 代码│←真正执行的是你的代码！
12└──────────────┘
13│你去调真实的天气接口，拿到"晴天 28°C"
14▼
15把结果喂回给模型→模型再组织语言回你："北京今天晴天 28°C"
你发现了没？模型从头到尾没碰过任何"真实世界"。它只做两件事：读懂请求 → 给出调用指令。真正伸手去抓真实数据的，是你的 Java 代码。
我送你一个最好记的类比：
"
模型是"点菜的顾客"，工具是"后厨"。 顾客（模型）只负责看着菜单，说"来一份糖醋排骨，加辣"。它不炒菜，也碰不到锅铲。真正颠勺开火的，是后厨——你的 Java 代码。菜（结果）端上来后，服务员再端给顾客看，顾客点点头："对，就是这么个意思。"然后由它组织语言，向你复述这道菜多好吃。
"
把这个边界刻进脑子里，太重要了。要是你带着"模型能直接操纵文件系统"这种误解去学，后面读 Spring AI 的代码你会完全懵掉——你会奇怪"怎么这个模型是怎么调用 Java 方法的？"，其实根本不是模型在调，是框架在模型和你的代码之间做翻译。
076. 这一章的产物：一张 DocMind 演进路线图
这一章我们没写一行代码，那这一章的价值在哪？
价值在于：你现在脑子里应该有一张"DocMind 会怎么一步步长成"的蓝图了。 我们把后面每一章放在这条演进路线上标个点：
1 DocMind 架构演进路线图
2 ──────────────────────────────
3
4 v0 只有大脑（模型） ← 第1-2章 你在这
5 │
6 v1 长出手和眼（工具：搜索/文件） ← 第5章 长"眼"
7 │
8 v2 再长出手（工具：计算器/精确运算） ← 第6章 长"手"
9 │
10 v3 长出记忆库（RAG：投喂你的文档） ← 第7-8章 长"记忆"
11 │
12 v4 学会自主编排（知道先做什么后做什么） ← 第9章 学会"拿主意"
13 │
14 v5 会记忆（长期偏好/常用资料） ← 第10章 认得"老熟人"
15 │
16 v6 会交作业（把成果整理、交付） ← 第11章 学会"汇报"
看到没有？每个零件不是突然冒出来的，是在特定的章节，专门为它"长出"来的。 一个零件一章，一个零件讲透一个问题。你现在做的，是先把这张地图在脑子里装好，后面我们一章一章往上面填肉。
087. 本章踩坑（必看）
这章是概念章，踩坑也踩的是"思维的坑"。这些坑不踩，后面必定爆雷。
坑一："Agent"这个词被滥用了
现象： 市面上随便接个 API、加个 RAG、能聊两句话，就敢叫自己"Agent"。开会时人人喊 Agent，一打开代码就是个大模型加一个搜索。
根因： 术语被营销玩坏了，大家把"Agent"当成高级点的"聊天机器人"在用。但实际上四者完全是四层不同档次的物种。
解法： 先分清楚，别被带节奏：
| Chatbot | ||
| RAG | ||
| Agent | ||
| 多 Agent |
最扎心的一句提醒："接了个 API + RAG 就敢叫 Agent"，就像装了四个轮子就敢叫汽车——你缺个发动机（自主决策）。 判断标准很简单：它有没有"自主决定调哪个工具、然后根据结果自主决定下一步"的能力。没有，就是 Chatbot 或 RAG，别硬叫 Agent。
坑二：Function Calling ≠ 代码执行
现象： 以为模型能直接读文件、改数据库、上操作系统，觉得"模型什么都能干"。
根因： 没搞懂第 5 节那个边界——模型只"说"不"做"，执行在代码里。
解法： 记住"顾客点菜 vs 后厨炒菜"的类比。模型发出调用指令，你的 Java 代码去执行真实的动作。这也意味着：安全责任在你身上——你写的工具函数如果去删库，模型"下令"删库是它的"建议"，但真正执行删库的是你的代码，锅是你的，权限也是你在控制。所以永远要对你暴露给模型的工具做校验，别把"删全库"这种危险函数直接传给模型当工具。
坑三：一上来就搞多 Agent 协作
现象： 新手看完几个炫酷的多 Agent 演示，就想给自己的项目也上"三个 Agent 分工协作"。
根因： 被高大上的架构晃花了眼，忽略了"单 Agent 都没跑顺"这个前提。多 Agent 会带来编排、通信、死锁、结果冲突一箩筐新问题。
解法：先单 Agent 做扎实。 先把"一个大脑 + 工具 + 记忆"这一个循环搞顺，性能调好，Bug 调干净。多 Agent 是把这个单循环做成多个之后才会自然遇到的问题，那是第 9 章以后的故事。过早多 Agent = 灾难，等你连单 Agent 都调不明白时，多 Agent 只会让你在混乱里火上浇油。
09下章预告
现在你手里已经握着 Agent 的三件套了：模型（大脑）、工具（手和眼）、记忆（金鱼的记忆）。可是——这三个零件到底怎么"咬合"在一起，才算一个真正好用的产品？
这不只是"功能叠加"，而是设计问题：你的 DocMind 核心场景是什么？工具该怎么设计才不多不少？记忆存什么、不存什么？数据组织成什么样，模型用起来才顺手？
第 3 章，我们就来设计 DocMind：把工具、记忆、数据这三块，像齿轮一样严丝合缝地咬合起来。