一、今天学到了什么？

昨天主要是在理解 AI Agent 是什么，包括 LLM、Prompt、Tools、Memory、Planning、Workflow 等核心概念。

今天的学习重点开始从“理论理解”转向“项目实践”。

今天我主要接触到了几个更偏工程化的内容：

  • Spring AI / Spring AI Alibaba；
  • ChatClient 聊天接口；
  • conversationId 会话隔离；
  • Memory 记忆能力；
  • RAG 检索增强生成；
  • Vector Store 向量存储；
  • Milvus 向量数据库；
  • API 接口测试与错误排查；
  • Java 项目中集成 Agent 能力。

也就是说，今天不再只是理解 Agent 的概念，而是开始尝试把 Agent 真正接入到 Java 后端项目中。

二、从“会聊天”到“有记忆”的 Agent

今天我印象比较深的是 conversationId 这个概念。

在普通聊天机器人中，用户每次提问可能都是独立的。但是在 Agent 系统中，如果想让 AI 具备连续对话能力，就需要区分不同的会话。

比如：

用户 A 问：

我是 Java 开发者。

下一轮用户 A 又问：

那我适合怎么学习 Agent？

如果系统有记忆能力，Agent 就应该知道“这个用户是 Java 开发者”，然后结合这个背景来回答。

但是如果没有会话隔离，多个用户的上下文就可能混在一起。

所以 conversationId 的作用可以理解为：

用来区分不同用户或不同对话，让每个会话拥有独立的上下文记忆。

从 Java 后端视角看，它有点像：

userId
sessionId
chatId
conversationId

这些 ID 的共同作用都是为了区分不同请求背后的上下文。

今天我开始意识到，Agent 的 Memory 并不是一个抽象概念，而是可以通过具体的工程参数来实现的。

三、Agent Memory 可以怎么理解？

今天对 Memory 的理解比昨天更具体了。

昨天理解的是：

Memory 是 Agent 的记忆能力。

今天进一步理解为：

Memory 本质上是对上下文信息的保存、检索和再次注入。

也就是说，Agent 并不是像人一样真的“记住”了所有东西，而是系统在背后帮它保存了一些信息。

常见的记忆可以分成几种：

1. 对话上下文记忆

这是最基础的记忆。

比如当前用户前几轮说过什么，系统会把这些历史消息带给大模型，让模型能够继续对话。

2. 用户画像记忆

比如：

用户是 Java 学习者，正在转向 AI Agent 工程师方向。

这类信息可以长期保存，以后回答问题时就能更贴合用户背景。

3. 知识库记忆

比如项目文档、公司制度、技术资料、课程笔记等。

这类内容通常不会直接塞进 Prompt，而是先存入向量数据库，用户提问时再检索相关内容。

这就和 RAG 有关系了。

四、今天开始接触 RAG：让 Agent 能查资料

今天项目记录里出现了 Spring AI RAG、Vector Store、Milvus 等相关内容，这说明学习已经进入到 RAG + Agent 阶段。

RAG 的全称是 Retrieval-Augmented Generation，中文一般叫：

检索增强生成。

简单来说，RAG 的作用是：

先从知识库中查找相关资料，再让大模型基于资料生成答案。

如果没有 RAG，大模型只能依赖自身训练过的知识，容易出现：

  • 回答不准确；
  • 编造内容；
  • 不知道项目内部资料；
  • 无法回答企业私有文档问题。

有了 RAG 之后，Agent 就可以先查询外部知识库，再结合查询结果回答。

流程大概是：

用户提问
  ↓
将问题转换成向量
  ↓
去向量数据库检索相似内容
  ↓
取出相关文档片段
  ↓
把文档片段交给大模型
  ↓
生成更准确的回答

所以我今天理解到：

RAG 是 Agent 连接外部知识的重要能力。

五、Milvus 是什么？

今天项目里遇到了 Milvus 连接相关的问题。Milvus 是一个向量数据库，主要用来存储和检索向量数据。

在普通数据库里，我们可能存的是：

id、name、age、content

而在向量数据库里，核心存的是：

文本内容对应的向量表示

比如一句话：

Java 开发者如何学习 AI Agent？

可以通过 Embedding 模型转换成一组数字向量。

然后系统就可以通过向量相似度，找到语义上相近的内容。

这和传统 SQL 查询不太一样。

传统 SQL 更像是：

select * from docs where title like '%Agent%';

向量检索更像是：

找出和这个问题语义最接近的几段内容。

所以在 Agent 项目中，Milvus 通常承担的是：

  • 存储知识库文档向量；
  • 根据用户问题做相似度检索；
  • 为 RAG 提供上下文材料。

六、今天遇到的问题：Milvus 连接失败

今天日志里出现了一个比较典型的问题：

Failed to initialize connection
DEADLINE_EXCEEDED
localhost:19530

从现象看，这是 Spring Boot 项目启动时，创建 Milvus 客户端失败，导致相关 Bean 初始化失败，最终项目启动失败。

这个问题说明：

Agent 项目不仅仅是会写 AI 调用代码，还要能处理后端服务依赖问题。

可能原因包括：

  • Milvus 服务没有启动；
  • 端口 19530 没有监听；
  • Docker 容器没有正常运行；
  • 配置里的 host / port 写错；
  • 网络连接超时；
  • Spring 启动时强依赖 Milvus，导致连接失败后整个项目启动失败。

从 Java 开发者角度看，这其实就是一个典型的外部服务依赖问题。

比如以前项目连接 MySQL、Redis、Elasticsearch 失败时，也会导致项目启动失败。

现在只不过外部依赖换成了 Milvus。

七、今天还遇到了接口 404 问题

今天还有一个接口测试记录，请求的是：

POST /memory/chat

但是返回了：

{
  "status": 404,
  "error": "Not Found",
  "path": "/memory/chat"
}

这个问题说明请求路径没有匹配到后端 Controller。

常见原因有：

  • Controller 上没有写 /memory/chat；
  • 类上的 @RequestMapping 和方法上的 @PostMapping 拼接后路径不一致；
  • 请求方法不对，比如后端是 GET，测试时用了 POST；
  • 项目没有启动成功；
  • Controller 没有被 Spring 扫描到；
  • 端口或服务地址访问错了。

这个问题让我意识到，做 Agent 项目并不是只学 AI 概念就够了，传统 Java Web 基础依然非常重要。

比如：

  • Controller；
  • RequestMapping；
  • PostMapping；
  • 参数绑定；
  • JSON 请求体；
  • Spring Bean 扫描；
  • 接口调试。

这些都是 Agent 工程落地必须掌握的基础。

八、从 Java 后端角度理解Agent 项目

如果用 Java 后端思维来看，今天的 Agent 项目大概可以拆成这样：

Controller 接收用户请求
  ↓
ChatClient 调用大模型
  ↓
Memory 根据 conversationId 管理上下文
  ↓
RAG 检索知识库内容
  ↓
Vector Store 查询 Milvus
  ↓
大模型结合上下文生成回答
  ↓
Controller 返回结果

也可以类比成传统后端架构：

层次 传统 Java 项目 Agent 项目
接口层 Controller Chat Controller
业务层 Service Agent / Chat Service
数据层 MySQL / Redis Memory / Vector Store
外部服务 第三方 API 大模型 API
查询方式 SQL 查询 向量检索
返回结果 固定业务数据 AI 生成内容

这样一对比，我发现 Agent 并不是完全陌生的东西。

它仍然是一个后端系统，只是多了几个新能力：

  • 大模型调用；
  • 上下文管理；
  • 工具调用；
  • 向量检索；
  • 智能生成。

九、今天最大的收获

今天最大的收获是：

Agent 工程师不是只会 Prompt，也不是只会调用大模型 API，而是要把 AI 能力真正接入工程系统。

昨天我理解的是：

Agent = LLM + Prompt + Tools + Memory + Planning

今天可以进一步补充成：

Agent 项目 = Spring Boot + LLM + ChatClient + Memory + RAG + Vector Store + 外部工具

也就是说，Agent 的工程实现离不开后端基础。

对于我这种 Java 背景的学习者来说，这反而是一个优势。

因为很多 Agent 项目最终都需要：

  • 暴露 API；
  • 管理用户会话；
  • 调用数据库；
  • 接入第三方服务；
  • 做异常处理；
  • 做日志排查；
  • 部署运行环境。

这些都和 Java 后端开发能力高度相关。

十、总结

今天的学习让我感觉，Agent 已经不再只是一个抽象概念，而是逐渐变成了一个可以运行、可以调试、可以排错的 Java 项目。

昨天我理解了 Agent 的核心组成：

LLM + Prompt + Tools + Memory + Planning

今天我进一步接触到了 Agent 的工程实现：

Spring AI + ChatClient + conversationId + Memory + RAG + Milvus

今天也遇到了一些实际问题，比如：

  • Milvus 连接超时；
  • Spring Bean 初始化失败；
  • /memory/chat 接口 404；
  • 项目依赖下载和配置问题。

这些问题虽然看起来是 Bug，但其实正是从“学习概念”进入“工程实战”的必经过程。

对我来说，Java 后端基础并没有浪费。相反，它正在帮助我更好地理解 Agent 的落地方式。

未来要成为 Agent 工程师，不仅要懂大模型，还要懂：

  • 后端接口；
  • 服务配置；
  • 数据库；
  • 向量检索；
  • 日志排查；
  • 系统集成；
  • 工程部署。

所以接下来我要继续沿着这条路线学习：

Java 后端基础
  ↓
Spring AI
  ↓
Memory 记忆
  ↓
RAG 知识库
  ↓
Milvus 向量数据库
  ↓
Tool Calling
  ↓
Agent 项目实战
# java # 人工智能 # 经验分享
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

cover

当你的品牌在AI搜索中“消失”：为什么搜极星是唯一的救命稻草？

avatar AtomGit开源社区
cover

2026年中国市场最受欢迎的五大AI招聘系统厂商盘点

avatar AtomGit开源社区
cover

Hermes记忆升级记：当 vecmem记忆层被污染之后

avatar AtomGit开源社区