Agent应用 学习笔记
Agent 应用 学习笔记
总览
学完 Spring AI 超级智能体项目（Agent 应用开发）后的总结：所有操作都是围绕着提示词来开发的，包括直接、间接给 AI 提示词。 下面先用一句话概括各模块（说的都比较粗糙）：
| 模块 | 一句话理解 |
|---|---|
| 记忆管理 | 每次对话的时候，把历史对话喂给 AI。 |
| RAG | 对于小众、内部的文档，让 AI 阅读，AI 结合文档和你的提问输出答案。 |
| 工具调用 | 告诉 AI 有哪些工具可以调用；AI 根据问题确定要调用的工具和参数，本地执行工具后把结果回传给 AI，AI 再给出最终结果。 |
| MCP | 本质还是工具，不过从 Agent 中抽离出来，算是解耦；加配置即可接入，不必修改代码。 |
核心公式：
Agent = 大模型 + 记忆管理 + RAG + 工具调用 + MCP + 自主规划
💡 学习体会：学了这个才能更了解 AI，知道 AI 的边界，vibe coding 起来也更得心应手。毕竟 AI 是你的助手，对它越了解，就能更好地使用它——这决定了提示词该怎么说它才能理解，也能帮助判断什么时候该新开对话。
下面细说对以上各部分的理解。
1. 大模型
LLM（Large Language Model，大语言模型）：把网上的一些数据（文档、代码等信息）给大模型学习，从而让它学会这些东西。
它的本质还是类似于"成语接龙"——不断根据历史对话，猜测下面应该输出什么 token，所以也可能会出错，这就是大模型的幻觉。
当大模型训练完成后，平台把调用大模型的接口通过 HTTP 提供出来，配合密钥即可调用。
2. 记忆管理
2.1 解决什么问题
大模型是没有记忆的，即 API 是完全无状态的，无法进行多轮对话；并且大模型的上下文长度有限。
2.2 是什么
为了进行多轮对话，就需要对记忆进行管理。
2.3 怎么做
粗暴的做法：把历史对话无脑拼接到用户新的提示词上面，这样每次调用大模型，给 AI 的参数里都包含之前的聊天记录。
一般还需要做记忆持久化：把聊天内容通过文件保存到磁盘，防止对话突然中断后 AI"失忆"。但随着对话次数增多，历史对话会导致上下文超限。目前的解决方案有：
- 滑动窗口：只保留最新的几轮对话，更早的舍去。
- 摘要压缩：专门调用一次大模型，对历史对话做信息提炼，保留关键信息。
- 混合模式：结合滑动窗口和摘要压缩——最新几轮对话保留原文 + 更早的历史消息用摘要。
2.4 长期记忆
上面的都是短期记忆，即当前对话的记忆。长期记忆则是用户的画像等信息，这样每次对话都有可能检索到，让 AI 更懂你。
3. RAG
3.1 解决什么问题
特定文档 AI 没有学习过；每次全量读入，大模型上下文不够。
3.2 是什么
RAG（Retrieval-Augmented Generation，检索增强生成）：给 AI 一个外部知识库文档，弥补其在特定领域的知识匮乏，让 AI 根据实际文档输出答案，减少幻觉。
3.3 怎么做
- 数据清洗：先对文档做清洗，去掉冗余信息。
- 切块（Chunking）：对文档进行切块，策略有定长切块、语义边界等；块与块之间需要有重叠区域，切块时可以为每个块挂上元数据。
- 向量化入库：使用向量模型（Embedding）把每一块文档转化为高维向量，存入向量数据库。
- 检索：用户提问时（问题可先做改写、扩展），对提问做向量化，用得到的向量去向量数据库检索相关片段。也可以做混合检索：BM25 关键字匹配 + 向量语义检索，再对结果做融合。
- 后处理：召回相关片段后，做去重 / 重排 / 压缩。
- 生成：最后把历史对话、用户提问、检索到的相关片段一起交给 AI 生成答案。
3.4 是否需要检索知识库
如何判断一个问题要不要走知识库：
- 关键词匹配：检索前加关键词匹配，命中才检索。
- 小模型 / 分类模型做意图分类：把问题分为几类，只有知识问答类才检索。
- 大模型路由：调用大模型判断问题最适合从哪里获取信息。
- 注册为工具：把检索知识库注册为一个工具，工具描述里写清楚知识库的用处，让大模型自己判断是否调用（即 Agentic RAG）。
3.5 看效果：评估
需要做评估，有点像测试：先看召回的相关片段是否合理，再看混合检索的融合、重排、压缩是否合理等。即沿着 RAG 的检索流程反推，回去定位是哪一步出了问题。
- 检索侧：Recall@k、MRR。
- 生成侧：忠实度（Faithfulness，答案是否只依据召回内容）、答案相关性。
4. 工具调用
4.1 解决什么问题
AI 只能"动嘴皮子"，无法操作文件、执行命令等。
4.2 是什么
本质就是给 AI 提供功能函数接口，AI 有需要时可以按参数传入指定信息来调用函数。
- Spring AI 把工具的注解转化为 JSON Schema 格式；
- 调用大模型时，把这个 Schema 随请求一起发送给大模型，大模型据此知道有哪些工具、该怎么调用；
- Spring 框架约定了有哪些工具可调用，工具参数由 JSON Schema 决定；
- AI 遵循该 Schema 输出调用请求，框架就能执行对应的工具。
5. MCP
5.1 解决什么问题
在 Agent 端不可能拥有一切工具，需要能通过配置加入工具，统一外部工具与 Agent 之间的连接通信。
5.2 是什么
MCP 是 Agent 应用与外部工具 / 数据源进程之间的标准化连接协议（"AI 应用的 USB-C"）。它不改变模型的输出：模型照常发 tool call，由 MCP Client 翻译转发；它统一了工具的发现、描述和调用方式，使外部工具加配置即可接入。
5.3 怎么做
- Agent 端先创建 MCP 客户端，客户端把 MCP 服务解析为工具、数据资源、提示词模板来使用。
- MCP 服务端与客户端通信需要遵循 MCP 协议，报文格式为 JSON-RPC。
- 一般有两种传输模式：
- stdio：本地进程启动服务；
- SSE：服务端在远端（新版规范改称为 Streamable HTTP）。
5.4 补充：安全风险
MCP 有一定危险性：调用别人的工具、使用别人的资源时，不确定其中带有什么内容，可能造成提示词注入风险，诱导 AI 做出错误选择。
6. 自主规划
6.1 解决什么问题
复杂任务不能指望大模型一次给出答案，需要让它有步骤、有依据地行动，直到完成目标。
6.2 是什么
Agent 解决问题时的行为方式，本质是"决策 → 行动 → 观察"的循环，以及循环内部采用什么规划策略。
6.3 通用机制：Agent Loop（执行循环）
用户设定目标后，Agent 自主循环：
输入 / 感知 → LLM 决策 → 行动（调用工具：搜索 / RAG / MCP）→ 观察结果回灌 → 再决策
直到模型给出最终答案，或触发终止条件（最大迭代步数、超时、token 预算、连续失败次数）。
⚠️ 下面的 ReAct、Plan-and-Execute 都是"在这个循环里怎么决策"的策略，不是和 Agent Loop 并列的第四种方式。在 Spring AI 中，注册工具后，"模型请求工具 → 框架执行 → 结果回灌 → 再次请求模型"这个循环是框架自动完成的——业务代码只调用了一次
call()，内部可能已经发生了多轮工具往返。
6.4 循环内的规划策略
-
CoT（Chain-of-Thought，思维链） 只解决【推理】，没有工具调用、没有外部行动。核心是让模型输出中间思考步骤，把复杂问题拆成多步推理。本质是内部思维拆解，严格说不算 Agent 模式，只是推理基线。（现代推理模型如 o1、DeepSeek-R1 已把思维链内化进模型，不靠提示词诱导。）
-
ReAct（Reason + Act，推理 + 行动） 走一步看一步，把【思考 Thought】、【行动 Act】、【观察 Observation】组成循环：思考 → 选择行动（调工具）→ 获取外部观察 → 依据最新观察回到思考，决定下一步。灵活，适合路径无法预知的任务。论文原版靠提示词输出固定文本格式；现代 function calling 实现中思考往往是隐式的，循环由框架代码驱动。
-
Plan-and-Execute（规划然后执行） 先由 Planner 一次性生成完整任务步骤清单，再由 Executor 按步执行。适合多步骤、流程性强的任务，优点是省 token、路径可控、可向用户展示进度。实战中必须支持重规划（Replan）：执行结果可能让原计划失效（资料不存在、工具报错），每完成一步要回到 Planner 判断"继续 / 修改计划 / 终止"——刚性照着清单走是这类 Agent 最常见的翻车点。常见做法是 Planner 用强模型（调用少）、Executor 用便宜模型（按单步指令调工具），靠模型分级省成本；也可与 ReAct 混合（先规划，执行阶段每步走一步看一步）。
6.5 工程护栏
循环本身不难，难的是兜底：
- 最大迭代次数、超时 / 预算限制；
- 工具异常时把错误信息回灌，让模型自救；
- 死循环检测（反复用相同参数调用同一个工具）；
- 每一步的可观测日志。
