大厂 Java 面试实战：从 Spring Boot、Kafka 到 RAG 搜索与 Agent（附完整答案解析）

场景：某一线互联网大厂，业务线是短视频+UGC 内容社区 + AI 智能推荐，小Y来应聘 Java 开发，面试官十分严格，小Y则是一位“看了很多技术栈词条、实战一般”的水货程序员。

---

一、第一轮：基础服务 & 简单业务场景

业务背景： 公司有一条“短视频+UGC内容社区”主站业务：

• 用户可以上传短视频、发布图文动态；
• 有推荐流、关注流、评论、点赞、收藏等功能；
• 后端主要采用 Spring Boot + Spring MVC + MySQL + Redis + Kafka 的常规技术栈。

第一轮主要考察：Spring Boot 基础、Web 层设计、数据库持久化、缓存、简单消息队列应用。

---

第一轮第 1 组问题（请求链路 & 基础架构）

面试官： 我们先从简单点的开始。假设你要实现一个“用户上传短视频”的接口，技术栈是 Spring Boot + Spring MVC + MySQL + Redis。回答下面几个问题：

1. 你会如何设计这个上传接口（大致的 Controller 层和 Service 层划分）？
2. 视频文件一般不会直接存数据库，你会如何存储视频文件本身以及元数据（如标题、时长、封面图）？
3. 假设上传成功后，需要把“新作品”写入 MySQL，同时更新用户作品数，你会如何使用 Spring Data / MyBatis 来实现？
4. 上传成功后，我们希望首页“推荐流”尽快出现这条新内容，你会如何利用 Redis 缓存 或者 消息队列（Kafka/RabbitMQ） 来加速？

小Y：

1. Controller 就写个 @RestController，然后 @PostMapping("/video/upload")，参数就 MultipartFile file、String title 这些。Service 就写个 uploadService.upload() 之类的。
2. 视频嘛，应该就先放在本地磁盘上，或者 OSS 上，然后数据库存一个 URL 就行了，表里就 video_url、title 这些字段。嗯……封面就再一个字段吧。
3. 持久化的话用 MyBatis 吧，就写个 insert，再写个 update user set work_count = work_count + 1。两个 SQL 就完事了。
4. 缓存的话，就把这个视频 ID 放 Redis 里面，比如 lpush 到一个列表？或者发个 Kafka 消息，但我这个业务好像还行，就先这样。

面试官：

• 基本思路是对的，但你忽略了事务与一致性问题；
• Kafka/Redis 的用法需要更明确一些；
• 第一组先这样，后面会深入。

---

第一轮第 2 组问题（缓存与并发）

面试官：

业务继续往下：现在作品详情页流量很高，我们做了 Redis 缓存。请回答：

1. 作品详情（如：标题、作者、点赞数、评论数）你会如何设计 Redis 缓存的 Key 和 Value？
2. 当一个作品被频繁点赞时，会有大量并发更新点赞数，你会如何避免直接每次都写 MySQL？
3. 有什么方案可以解决缓存与数据库不一致问题，比如“先更新 DB 再删缓存”还是“先删缓存再更新 DB”？
4. 你会选用 Redis 的哪种数据结构 来保存点赞数？为什么？

小Y：

1. Key 我就写 video:detail:{id}，Value 就整个 JSON 串，比如用 Jackson 序列化；
2. 点赞的话我就写一个 incr，然后定期把点赞数同步回数据库；
3. 不一致嘛，呃……可以先删缓存，然后更新数据库？或者先更新数据库再删缓存，我记不太清，反正删一下就好了；
4. 点赞就用 String 的 INCR 吧，比较简单，也可以用 Hash，存多个字段。

面试官：

• 有些点你说到了，但对操作顺序和热点数据同步策略理解不够清晰；
• 放心，后面会有标准答案部分给你补课。

---

第一轮第 3 组问题（简单异步 & 日志）

面试官：

最后一组问题：为了提升用户上传体验，我们需要一些异步任务。

1. 用户上传视频后，需要进行转码、截图生成封面，你会如何设计这个异步流程？使用哪些中间件（如 Kafka / RabbitMQ）？
2. 如果用 Spring Boot + Kafka，实现“上传成功即发送转码消息”，你会如何编写 Producer 和 Consumer（大致结构即可）？
3. 系统日志我们使用 Logback + SLF4J，你会如何区分访问日志与业务日志？
4. 如果要追踪一次上传请求的全链路（包括转码服务），你会使用什么工具或组件？比如 Zipkin / Jaeger / Micrometer / Prometheus 中的哪些？

小Y：

1. 嗯……这个就发个消息到 Kafka，然后转码服务订阅这个 Topic，拿到消息就去转码、截图。
2. Producer 用 KafkaTemplate 发消息就行，Consumer 我就用 @KafkaListener 注解监听一个 Topic，然后处理一下；
3. 日志的话，用两个 logger？access 和 biz 分别写不同文件；
4. 全链路，我知道 Zipkin，好像还能用 Jaeger……我们就用 Zipkin 吧，接入下 Spring Cloud Sleuth 之类的东西。

面试官：

• 基本还算 OK，不过细节上你回答得比较泛，缺少对可靠性、重试策略的考虑。
• 第一轮先到这，休息一下，第二轮我们聊微服务与推荐系统。

---

二、第二轮：微服务、Kafka 与推荐系统

业务背景： 随着业务发展，我们把单体应用拆分为多个微服务：

• 用户服务（User Service）
• 内容服务（Content Service）
• 推荐服务（Recommend Service）
• 互动服务（Like/Comment Service）

技术栈：Spring Boot + Spring Cloud + OpenFeign + Kafka + Redis + Prometheus + ELK。

第二轮主要考察：微服务拆分、服务调用、消息队列、监控与故障处理。

---

第二轮第 1 组问题（微服务拆分与调用）

面试官：

我们已经将原来的单体拆分成多个微服务。请回答：

1. 你会按照什么粒度来划分这些服务？例如，“内容服务”和“推荐服务”的边界在哪里？
2. 服务之间调用，你会选择 OpenFeign 还是 RestTemplate/WebClient？为什么？
3. 微服务注册中心选型上，如果用 Eureka 与 Consul，你有什么理解？
4. 如果某个下游服务（比如推荐服务）偶尔超时，你会如何使用 Resilience4j 做熔断与限流？

小Y：

1. 嗯……就按业务来拆吧，用户一个服务，内容一个服务，推荐一个服务，评论一个服务，大概这样；
2. 我觉得 OpenFeign 比较简单，有注解就能调；RestTemplate 要写很多代码；
3. Eureka 我知道是 Netflix 的注册中心，Consul 也可以做服务发现，还有 KV 存储；
4. Resilience4j 就是加个注解，比如 @CircuitBreaker、@RateLimiter 啥的，超时多了就熔断一下，感觉这样就行了。

面试官：

• 拆分原则说得太泛；
• 熔断的关键指标和恢复策略你没说出来；
• 不过起码知道组件名字，比啥都不知道强。

---

第二轮第 2 组问题（Kafka 与推荐日志）

面试官：

推荐系统依赖大量用户行为日志（曝光、点击、停留时长等）：

1. 简要说明你会如何使用 Kafka 采集用户行为日志（比如前端埋点 -> 日志网关 -> Kafka Topic）？
2. 你会如何设计 Kafka Topic 的分区与副本数，以支撑高吞吐？
3. 如果 Consumer 消费失败，你会采用什么重试策略？会不会导致消息乱序？
4. 在 Java 中，常用的 Kafka 客户端库有哪些？你会如何在 Spring Boot 中配置？

小Y：

1. 前端打点发到后端网关，网关写 Kafka，一个日志 Topic 就行，推荐服务从里面消费；
2. 分区就多一点，比如 20 个分区，副本就 2 或 3 个；
3. 消费失败就重试几次，不行就写个死信队列；至于乱序嘛……呃，可能会吧，不过应该没事；
4. 客户端就 spring-kafka 吧，写个 @KafkaListener，配置下 bootstrap servers 就完了。

面试官：

• 多分区不等于高吞吐，需考虑Key 分布、顺序性；
• 大致方向还行，但缺少深度。

---

第二轮第 3 组问题（监控与日志）

面试官：

微服务上线后，监控非常关键：

1. 你会如何配合 Prometheus + Grafana + Micrometer 实现接口 QPS、RT 的监控？
2. 日志方面，我们使用 ELK（Elasticsearch + Logstash + Kibana），如何保证日志字段结构化，便于检索？
3. 如果一条请求跨越多个微服务，你会如何做链路追踪？用 Zipkin 还是 Jaeger，需要在代码里做什么配合？
4. 对于线上 Bug 排查，你会如何使用 Sleuth + ELK 做联合排查？

小Y：

1. Prometheus 我知道可以拉 metrics，Grafana 展示；Micrometer 好像自动暴露指标；
2. 日志就打 JSON 格式，然后 Logstash 解析；
3. 链路追踪就加个 traceId，Sleuth 自动搞定；Zipkin 或 Jaeger 看公司选哪个；
4. 嗯……就是在 Kibana 搜 traceId，顺着查日志，看问题在哪个服务出错……差不多这样吧。

面试官：

• 概念上基本知道，但缺乏对具体指标和告警策略的理解；
• 第二轮就先到这里，第三轮我们聊 AI 检索、RAG、Agent 等新一代智能功能。

---

三、第三轮：AI 检索、RAG 与 Agent 智能客服

业务背景： 公司准备引入 AI 智能客服+搜索：

• 用户可以通过自然语言问问题，如“帮我找一下我昨天看过但还没点赞的视频”；
• 系统需要从日志、用户行为、内容库中检索相关信息；
• 使用 RAG（检索增强生成）+ 向量数据库 + Agent 工作流 实现复杂问答与多工具协作。

技术栈：

• Spring Boot + Spring AI
• 向量数据库：Milvus / Chroma / Redis Vector
• Embedding 模型：OpenAI / Ollama
• 语义检索、RAG、Agentic RAG
• 复杂工作流编排，企业文档问答，工具调用标准化

第三轮主要考察：AI 应用架构设计、RAG 流程、Agent 能力、避免幻觉。

---

第三轮第 1 组问题（AI 搜索与向量检索）

面试官：

我们要实现“语义搜索短视频与用户历史”的功能：

1. 请你简单说一下 语义检索 与传统关键词检索的区别？
2. 若采用向量数据库（如 Milvus/Chroma/Redis 向量），检索流程大致是怎样的？（从用户 Query 到返回结果）
3. Embedding 模型你会选用 OpenAI 还是本地的 Ollama？依据是什么？
4. 如果用户查询“那天我看过的一个猫咪弹钢琴的视频”，但系统日志不完整，你如何减少 AI 幻觉（Hallucination）？

小Y：

1. 语义检索就是用向量找相似意思，关键词就是匹配字符串；
2. 流程就是把 Query 做 Embedding，然后去向量库里相似度搜索，找 topN，再返回内容；
3. OpenAI 精度高，Ollama 本地部署便宜一些，看公司钱多不多；
4. 幻觉的话，就让模型谨慎一点？可能在 Prompt 里说“你不知道就说不知道”，差不多吧。

面试官：

• 大方向还算说到了，但没有提到检索结果与业务实体的对齐；
• 幻觉控制也不只是“加强提示词”这么简单。

---

第三轮第 2 组问题（RAG 架构与 Spring AI）

面试官：

我们准备用 RAG 来做“企业文档问答 + 内容推荐解释”：

1. 简要描述一个 RAG（检索增强生成）的关键步骤；
2. Spring AI 在这里能帮你做什么？例如：模型调用、向量检索、工具执行框架？
3. 在 RAG 中，你如何处理向量检索出来的多条文档（Chunk）？是直接拼接还是要做重排序与摘要？
4. 对于用户隐私（比如医疗场景、健康管理），在 RAG 系统中你会做哪些安全策略？

小Y：

1. RAG 就是先检索再生成，先找文档，再让大模型回答；
2. Spring AI 可以帮我封装下模型调用，感觉写代码少一点；
3. 文档就全拼上，给大模型看；
4. 安全嘛，就注意别泄露隐私，可能加点权限校验？

面试官：

• 你对 RAG 的理解过于粗略；
• Spring AI 的能力你也没说具体，如 Client-Server 架构、工具调用标准化等。

---

第三轮第 3 组问题（Agent 与复杂工作流）

面试官：

最后一组：我们要做一个面向“本地生活服务 + 电商 + 支付”的智能客服 Agent：

1. 简要解释一下什么是 Agent（智能代理），与普通 ChatBot 有什么区别？
2. 当 Agent 需要调用多个工具（比如：订单查询、支付状态查询、物流查询），你会如何设计工具调用框架？
3. MCP（模型上下文协议）或类似标准能解决什么问题？
4. 若 Agent 在一次对话中需要维护用户上下文（聊天会话内存），你会如何设计存储？用 Redis 还是向量数据库？

小Y：

1. Agent 就是更智能的机器人，可以自己决定调用什么工具；
2. 工具框架就搞个统一接口，比如定义个 Tool 接口，里面有 invoke，然后根据名称调用；
3. MCP 我……好像没看过，应该是让模型跟工具对接更统一？
4. 会话内存就存 Redis 里吧，把历史消息串起来，向量库也可以；

面试官：

• 回答得比较泛，尤其是 MCP 和 Agentic RAG 这些；
• 不过至少概念上知道个大概。

---

四、面试结束语

面试官：

今天的问题就到这里。总体来看：

• 你的基础知识（如 Spring Boot、Redis、Kafka）还算了解，但很多地方停留在“听过、写过 Demo”的程度；
• 在微服务、监控、RAG、Agent 等方面，掌握不够系统，缺乏实战；
• 建议你回去之后，多做一些完整业务场景的项目，把这些技术串起来。

我们会在一周内给你反馈，你回去等通知吧。

小Y：

好的好的！我回去就把 Spring AI、RAG、Kafka……全部再看一遍！（小声：希望还能混口饭吃）

---

五、标准答案与详解（小白友好版）

下面是上述问题的“标准答案 + 知识点串讲”，帮助你从业务角度串联技术栈。

---

1. 上传短视频接口设计（Spring Boot + MVC + MySQL + 对象存储）

1）Controller & Service 分层

• Controller 负责：
  • 参数接收与基本校验（如标题是否为空、文件大小限制等）；
  • 调用 Service 完成业务逻辑；
  • 返回统一的响应格式（如 Result<T>）。
• Service 负责：
  • 调用对象存储 SDK 上传视频文件；
  • 生成封面图任务（可能是同步，也可能异步）；
  • 写入数据库（视频元数据表、用户统计表）；
  • 发送消息到 Kafka（通知推荐系统、统计系统）。

@RestController
@RequestMapping("/api/video")
public class VideoController {

    private final VideoService videoService;

    @PostMapping("/upload")
    public Result<VideoDTO> upload(@RequestParam("file") MultipartFile file,
                                   @RequestParam("title") String title,
                                   @RequestParam(value = "desc", required = false) String desc) {
        return Result.ok(videoService.upload(file, title, desc));
    }
}

2）视频文件与元数据存储

• 视频文件：
  • 存储在对象存储（如阿里云 OSS、腾讯云 COS、MinIO）或 CDN；
  • 数据库只存 URL、封面地址、时长、分辨率等。
• 表设计示例（MySQL + JPA/MyBatis）：
  • video(id, user_id, title, description, url, cover_url, duration, status, create_time)。

3）MyBatis / Spring Data 实现

• 使用事务确保：
  • 视频元数据插入成功；
  • 用户作品数更新成功；
• 可使用 Spring Data JPA 或 MyBatis：
  • JPA：@Transactional + save()；
  • MyBatis：Mapper 中定义 insertVideo、updateUserWorkCount。

4）上传成功后的缓存与消息

• 典型做法：
  • 写数据库（主数据）；
  • 发送 Kafka 消息：video_uploaded，包含 videoId、userId 等；
  • 推荐系统消费消息，更新特征、加入推荐候选池；
  • 可在 Redis 中维护一些“最新视频列表”、“用户作品列表”等，加速首页展示。

---

2. Redis 缓存与点赞数并发更新

1）缓存 Key/Value 设计

• Key：video:detail:{videoId}；
• Value：序列化后的 JSON（覆盖标题、作者、计数等）；
• 可加 TTL（如 1 小时），避免缓存永不过期。

2）点赞数高并发更新

• 利用 Redis 做“计数缓冲”：
  • 用户点赞 -> 写 Redis 计数（INCR）；
  • 定时任务或异步任务批量将计数刷回 MySQL；
  • 减少直接写 DB 压力，避免写放大。
• 数据结构：
  • 对某个视频：video:like:count:{id} 使用 String + INCR；
  • 或使用 Hash：video:like:count 的 hash，field 为 videoId。

3）缓存与数据库一致性

常见方案：

• 写 DB 成功后删除缓存（而不是更新缓存），读请求时再回源 DB 重建缓存；
• 避免“先写缓存再写 DB”导致的脏数据；
• 可配合消息队列进行异步缓存构建。

经典策略：

• 读：
  • 查缓存，若不存在 -> 查 DB -> 写缓存；
• 写：
  • 更新 DB；
  • 删除缓存 Key。

---

3. 异步转码与 Kafka 消息

1）异步流程设计

• 上传成功 -> 发送 transcode_task 消息至 Kafka；
• 转码服务订阅该 Topic：
  • 拉取任务 -> 调用转码引擎（FFmpeg 等）；
  • 完成后更新视频状态（如 processing -> done）。

2）Spring Boot + Kafka 示例

@Service
public class VideoService {

    private final KafkaTemplate<String, VideoTranscodeMessage> kafkaTemplate;

    @Transactional
    public VideoDTO upload(...) {
        // 1. 上传文件 + 写 DB
        // 2. 发送转码消息
        kafkaTemplate.send("video_transcode", new VideoTranscodeMessage(videoId, url));
        return dto;
    }
}

@Component
public class TranscodeConsumer {

    @KafkaListener(topics = "video_transcode", groupId = "transcode-service")
    public void onMessage(VideoTranscodeMessage msg) {
        // 调用转码
    }
}

3）日志与链路追踪

• 使用 SLF4J + Logback：
  • 访问日志：Nginx/网关层记录；
  • 业务日志：Service 层记录重要操作；
• 全链路追踪：
  • 使用 Spring Cloud Sleuth + Zipkin/Jaeger；
  • 自动注入 traceId/spanId；
  • 配合 ELK，使用 traceId 在 Kibana 中关联日志。

---

4. 微服务拆分与 Spring Cloud

1）服务拆分边界

• 以业务领域为中心（DDD 思想）：
  • 用户服务：账号、资料、关系链；
  • 内容服务：视频/图文内容的管理、审核；
  • 推荐服务：召回、排序、特征计算；
  • 互动服务：点赞、评论、收藏；
• 原则：
  • 高内聚、低耦合；
  • 避免“细粒度过度拆分”，导致网络调用复杂。

2）服务调用方式

• OpenFeign：
  • 声明式 HTTP Client，接口 + 注解即可；
  • 内置负载均衡、熔断（可与 Resilience4j 集成）；
• RestTemplate / WebClient：
  • 更灵活，但样板代码更多；
• 大厂常用：OpenFeign +统一网关（如 Spring Cloud Gateway）。

3）注册中心选型

• Eureka：
  • Netflix OSS，已停止维护，但在老系统仍广泛使用；
• Consul：
  • HashiCorp 产品，集服务发现、配置、健康检查于一体；
  • 支持多数据中心。

4）Resilience4j 熔断和限流

• 关键配置：
  • 失败率、滑动窗口大小、半开状态、恢复阈值；
• 与 Feign 集成：
  • 通过注解 @CircuitBreaker/@Retry/@RateLimiter；
  • 避免下游服务雪崩。

---

5. Kafka 行为日志与监控

1）行为日志采集链路

• 前端埋点 -> 日志网关（HTTP） -> Kafka Topic（如 user_behavior）；
• 日志网关负责：
  • 校验/规范化字段；
  • 添加用户ID、设备ID、时间戳；
  • 写入 Kafka。

2）Topic 分区与副本

• 分区数：
  • 与消费组实例数、吞吐需求相匹配；
• 副本数：
  • 一般 2~3，兼顾高可用与存储成本；
• Key 设计：
  • 对于需要按用户顺序处理的消息，可使用 userId 作为 key，保证同一用户落在同一分区。

3）消费失败与重试

• 重试策略：
  • 重试次数（例如 3 次）+ 重试间隔；
  • 超过次数后写入 DLQ（死信队列）；
• 保证顺序：
  • 同一 key 的消息必须由同一 partition + 同一 consumer 实例顺序消费；
  • 重试若跨分区，可能导致乱序。

4）监控与日志系统

• Prometheus + Micrometer：
  • 指标：QPS、P95/P99 响应时间、错误率；
  • 配置告警规则，接入钉钉/企业微信/邮箱；
• ELK：
  • 使用 JSON 日志，便于解析与查询；
  • 利用 Kibana 可视化错误分布、慢查等。

---

6. AI 语义检索、RAG 与向量数据库

1）语义检索 vs 关键词检索

• 关键词检索：
  • 基于倒排索引；
  • 强依赖关键词匹配；
• 语义检索：
  • 使用 Embedding 将文本映射到向量空间；
  • 根据向量相似度（cosine/L2）匹配语义相近内容；

2）向量检索流程

1. 离线/增量：
   • 对内容（视频标题、描述、标签等）做 Embedding；
   • 存入 Milvus/Chroma/Redis Vector 等；
2. 在线查询：
   • 用户 Query -> 分词/预处理 -> Embedding；
   • 向量库相似度搜索，返回 topN 内容 ID；
   • 根据 ID 从 DB/缓存补全详情；
   • 返回结果给用户或作为 RAG 的上下文。

3）Embedding 模型选型

• OpenAI：
  • 精度高，语言泛化强；
  • 受限于外网、成本、隐私；
• Ollama + 本地模型：
  • 数据不出内网；
  • 可控成本；
  • 需要更好的工程化和硬件支持。

4）减少 AI 幻觉

• 检索结果质量：
  • 对向量检索结果设置评分阈值；
  • 若无足够相关文档，直接告诉用户“查不到”；
• 输出控制：
  • Prompt 中明确指示：未匹配到相关内容时要诚实回答；
  • 模型回答仅基于检索文档，不要凭空编造；
• 日志监控：
  • 记录 Q&A 和检索结果，用于后续评估与优化。

---

7. RAG 架构与 Spring AI 应用

1）标准 RAG 步骤

1. 文档加载：
   • 从数据库、对象存储、企业文档系统读取文档；
2. 分段（Chunking）：
   • 按段落/语义切分成小块；
3. 向量化：
   • 调用 Embedding 模型生成向量；
4. 存储：
   • 写入向量数据库（Milvus/Chroma/Redis）；
5. 查询：
   • 用户输入 -> Embedding -> 相似度检索；
6. 生成：
   • 将检索到的文档片段拼接（或重排序）后，交给大模型生成回答。

2）Spring AI 能做什么

• 封装模型调用：
  • 支持 OpenAI、Azure、Ollama 等；
• 提供统一接口：
  • Client-Server 架构，简化 HTTP 调用；
• 集成向量检索：
  • 可以配合向量数据库实现统一的 RAG 管道；
• 工具调用框架：
  • 标准化工具接口（function calling），使 Agent 能调用业务服务。

3）文档 Chunk 处理

• 一般做法：
  • 对 Chunk 重排序（根据相关度/重要性）；
  • 限制总 token 数，避免上下文过长；
  • 可对多个 Chunk 做摘要，再提供给模型，减少冗余。

4）隐私与安全策略

• 数据脱敏：
  • 对医疗、金融数据进行脱敏/匿名化；
• 权限控制：
  • 不同用户只允许检索有权限的文档；
• 审计与日志：
  • 记录每次问答的文档来源与响应，便于审计；
• 模型与存储均在内网，避免数据泄露。

---

8. Agent、工具调用框架与 MCP

1）Agent 与普通 ChatBot 的区别

• ChatBot：
  • 仅基于对话上下文生成回复；
• Agent：
  • 具备决策能力（何时调用哪个工具）；
  • 能执行多步任务（复杂工作流）；
  • 能管理记忆（长期/短期），与外部系统交互。

2）工具调用框架设计

• 定义统一 Tool 接口：

public interface Tool {
    String getName();
    ToolResult invoke(ToolInput input);
}

• 工具注册中心：
  • 按名称或能力标签查找可用工具；
• 标准化输入输出：
  • 使用 JSON Schema 描述工具参数；
  • 模型通过 function calling 方式调用。

3）MCP（模型上下文协议）作用

• 标准化：
  • 模型与工具、数据源之间的通信协议；
• 统一上下文管理：
  • 规范如何传递会话上下文、检索结果、工具响应；
• 可扩展性：
  • 方便接入新工具、新数据源，而不改动模型调用层。

4）聊天会话内存设计

• 短期记忆：
  • 最近几轮对话，可存 Redis（Key: sessionId）；
• 长期记忆：
  • 历史重要信息（偏好、常用地址等），可向量化后存向量数据库；
• 结合方式：
  • 检索近期对话（Redis）+ 语义搜索历史（向量库）；
  • 提供给 Agent 作为上下文，帮助其决策与回答。

---

六、小结

通过这个故事化的面试场景，我们把一条“短视频 + UGC 内容社区 + AI 推荐 + 智能客服”的业务线串了起来：

• 基础：Spring Boot、Spring MVC、MySQL、Redis、Kafka；
• 进阶：微服务拆分、Spring Cloud、OpenFeign、Resilience4j、ELK、Prometheus、Grafana；
• 前沿：语义检索、向量数据库、RAG、Spring AI、Agent、MCP、Agentic RAG；

无论你现在是“小Y”还是已经在大厂工作的工程师，只要能把这些技术在完整业务场景中串起来，你就真正迈入了“工程化 AI + 大规模分布式系统”的世界。