项目简介

AI 恋爱大师应用‏可以依赖 AI 大模型解决用户的情؜感问题，支持多轮对话、基于自定义知识库进行问答、自主调用工具和 MC‌P 服务完成任务，比如调用地图服务‏获取附近地点并制定约会计划。

项目收获：

• AI 开发框架（Spring AI + LangChain4j）
• Prompt 工程和优化技巧
• 多模态特性
• Spring AI 核心特性：如自定义拦截器、上下文持久化、结构化输出
• RAG 知识库和向量数据库
• Tool Calling ️工具调用
• MCP 模型上下文协议和服务开发
• AI 智能体 Manus 原理和自主开发

多轮对话

1、 技术方案

Spring AI 通过 ChatClient + Advisors 责任链机制，把对话能力模块化；其中 ChatMemoryAdvisor 配合 ChatMemory 组件，让 AI 具备对话记忆力，实现真正连续、可控的多轮交互。

2、后端实现

AI多轮对话：通过ChatClient + ChatMemory 的组合实现了 AI 多轮对话。技术上有两个核心点：一是构建带有系统提示（System Prompt）的 ChatClient，设定 AI 角色和问答范围；二是结合内存对话记录（InMemoryChatMemory）+ 会话 ID 机制，用 MessageChatMemoryAdvisor 保留上下文（10轮），实现连续对话。这样用户每次对话时，都能在前文基础上给出更连贯、个性化的回复，

自定义日志Advisor

通过实现 CallAroundAdvisor 和 StreamAroundAdvisor 接口中的核心方法，具体而言：①继承 CallAroundAdvisor 和 StreamAroundAdvisor 两个接口，以支持同步和流式两种对话模式的日志处理。②实现 aroundCall() 方法，用于拦截并打印非流式请求和响应。实现 aroundStream() 方法，处理流式响应并聚合输出日志，配合 MessageAggregator 实现完整输出。在方法内通过 log.info() 打印用户输入（request.userText()）和 AI 输出。③设置顺序：通过实现 getOrder() 方法设置 Advisor 的执行优先级。④构建 ChatClient 时注入 Advisor，可以精确打印 AI 请求与响应日志，实现透明、可追踪的对话流程管理。这个方式适用于开发中需要排查问题或记录对话内容的场景，具备良好的解耦性和扩展性。

自定义Re-reading Advisor

通过实现 CallAroundAdvisor 和 StreamAroundAdvisor 接口中的核心方法，具体而言：
① 继承两个接口：继承 CallAroundAdvisor 和 StreamAroundAdvisor 两个接口，以支持同步和流式两种对话模式下对用户请求的“二次阅读”能力增强。
② 实现核心逻辑方法：

• 实现 aroundCall() 方法：用于拦截非流式请求，在请求前对 userText 做改写，增强模型理解能力（例如插入 “Read the question again: xxx” 的提示），然后通过 chain.nextAroundCall() 将修改后的请求继续传递。
• 实现 aroundStream() 方法：类似于 aroundCall()，但作用于流式请求流程中，确保对所有流式请求也能注入增强 prompt。

③ 设置顺序：通过实现 getOrder() 方法设定优先级；数值越小，越优先执行，可确保 prompt 重写逻辑优先应用。
④ 注入 ChatClient：在构建 ChatClient 时注册该 Advisor，实现在客户端对用户请求统一增强的能力，完全透明，支持拓展。

结构化输出

原理：为什么能结构化输出？
结构化输出的核心思想是：在调用大模型前，提供清晰格式提示，引导模型输出特定结构；然后，在调用后通过 converter 将模型输出的文本转换为我们真正需要的 Java 对象或数据结构。

这个过程依赖两个关键组件：

1. FormatProvider 接口：告诉大模型“请输出 JSON 格式，格式参照 xxx”，相当于"提示词增强器"。
2. StructuredOutputConverter 接口：模型输出后，把纯文本再转换为我们想要的 Java Bean、List、Map 等结构。

实际调用：
当调用entity(LoveReport.class)时，Spring AI 框架内部 ①查找注册的 StructuredOutputConverter 实例（比如 BeanOutputConverter），②自动为提示词拼接格式指令（FormatProvider 的 getFormat），③使用 ObjectMapper 转换结构化输出。

对话记忆持久化

在大模型应用中，我们一开始用的是内存型对话记忆（InMemoryChatMemory），这种方式实现简单、响应快，但有个致命问题：服务一重启，上下文就没了，用户体验就像聊天记录突然清空，尴尬得很。

为了解决服务重启导致记忆丢失的问题，我们实现了一个自定义的 ChatMemory —— 基于文件的持久化记忆组件。

官方虽然没给例子，但 Spring AI 把「记忆算法」和「存储方式」解耦了，也就是说：我们只要改写存储逻辑就能无缝替换默认记忆方式，而不影响对话流程。
Spring AI 提供了 JDBC 实现，但依赖少、功能弱，不支持灵活结构转换，落地成本高。我们需要灵活且轻量的解决方案，所以选择自定义。

因为 ChatMemory 存储的 Message 是一个接口，有多种实现子类（比如 UserMessage、SystemMessage），结构复杂，不统一。用 JSON 序列化有三个痛点：①多子类字段不一致，②没有无参构造函数，③没有实现 Serializable 接口
而 Kryo 是一款高性能的二进制序列化框架，能跳过构造函数、不依赖Serializable，同时支持复杂对象结构，非常适合这种情况。

RAG知识库

简化后的 RAG 开发步骤：

• 文档准备
• 文档读取
• 向量转换和存储
• 查询增强

文档读取

ETL的3大核心组件，按照顺序执行:

• DocumentReader：取文档，得到文档列表
• DocumentTransformer：转换文档，得到处理后的文档列表
• DocumentWriter：将文档列表保存到存储中(可以是向量数据库，也可以是其他存储)

使用的是 MarkdownDocumentReader 来解析项目中的 Markdown 文档内容。它的设计支持将 .md 文件转换为结构化的 Document 对象，便于后续用于向量化、搜索或知识问答场景。

向量转化和存储

为了实现方便，我们先使用 Spring Al 内置的、基于内存读写的向量数据库 SimpleVectorStore 来保存文档。SimpleVectorstore 实现了 VectorStore 接口，而 Vectorstore 接口集成了 DocumentWriter，所以具备文档写入能力。

• 我们先通过 loveAppDocumentLoader 加载本地 Markdown 文档，转成 List
• SimpleVectorStore 会在写入前，自动调用指定的 Embedding 模型（如dashscopeEmbeddingModel），把文本转为向量。

查询增强

Spring Al 通过 Advisor 特性提供了开箱即用的 RAG 功能。主要是 QuestionAnswerAdvisor问答拦截器和 RetrievalAugmentationAdvisor 检索增强拦截器，前者更简单易用、后者更灵活强大。

查询增强的原理其实很简单。向量数据库存储着 A| 模型本身不知道的数据，当用户问题发送给 A1模型时，QuestionAnswerAdvisor 会查询向量数据库，获取与用户问题相关的文档。然后从向量数据库返回的响应会被附加到用户文本中，为 A模型提供上下文，帮助其生成回答。

基于QuestionAnswerAdvisor 实现的查询增强流程为：

1. 用户提问（例如：“Spring AI 支持哪些向量数据库？”）
2. QuestionAnswerAdvisor 触发，查向量数据库（如 SimpleVectorStore / Redis / Qdrant）
3. 拿到相关文档后，拼到 prompt 中
4. 最终 Prompt 是用户问题 + 文档内容组成，发给大模型处理
5. 模型根据「补充上下文」生成回答，避免胡编瞎说

Spring AI + 云知识库

我们文档读取、文档加载、向量数据库是在本地通过编程的方式实现的。其实还有另外一种模式，直接使用别人提供的云知识库服务来简化 RAG 的开发。但缺点是额外的费用、以及数据隐私问题。

这里我们还是选择 阿里云百炼，因为 Spring AI Alibaba 可以和它轻松集成，简化 RAG 开发。

实际开发：我们用 Spring AI 内置的 RetrievalAugmentationAdvisor 结合 DashScope 云向量索引，实现了一个基于向量检索的 RAG 模型，能根据用户问题自动从知识库中检索相关内容并增强大模型的上下文。

QuestionAnswerAdvisor适用于从本地的向量数据库（如 Faiss、Milvus、Qdrant 等）中检索文本片段。RetrievalAugmentationAdvisor适用于远程文档检索服务（比如 DashScopeDocumentRetriever）），可直接接入 SaaS 级别的云知识库服务，你不需要管理 embedding 和索引。

基于 PGVector 实现向量存储

企业原本的数据都存于 MySQL 或 PostgreSQL 等关系型数据库，若迁移到 DashScope 等云向量服务，需重新构建同步逻辑、做 embedding 并上传云端，存在开发成本高、数据隐私风险等问题。而 PGVector 作为 PostgreSQL 的扩展，只需本地安装即可支持向量检索，改造成本低、部署灵活，非常适合在原有数据库上直接实现 RAG，是目前企业常用的向量存储方案。
PGVector配置：向量维度1536；语义搜索用余弦相似度；使用 HNSW 索引结构，提升近似搜索性能。

RAG 最佳实践和调优

1、文档收集和切割
在将文档传输给 AI 前，需关注三点：知识完备性、结构清晰性、格式可解析性。

1. 确保知识完整：文档内容要覆盖业务关键点，否则 AI 无法准确生成回答。我们可结合用户反馈和检索命中率，持续补全。
2. 结构清晰、语言规范：文档要结构化（标题分明、层级清晰），表述统一（术语一致、多语言标注），避免冗余内容干扰解析。
3. 格式友好、便于解析：优先使用 Markdown 或 Word 文档，避免使用 PDF（因解析不稳定）；图片需使用公网链接嵌入，确保展示无障碍。

文档切片

①合适的文档切片大小和方式对检索效果至关重要。
文档切片尺‏寸需要根据具体情况灵؜活调整，避免两个极端：切片过短导致语义缺‌失，切片过长引入‏无关信息。最佳文档切片策略是 结合智能分块算法和人工二次校验。
在编程实现上，可以通过 Spring AI 提供的 DocumentTransformer 来调整切分规则，

②元数据标注
可以为文档‏添加丰富的结构化信؜息，俗称元信息，形成多维索引，便于后‌续向量化处理和‏精准检索。
利用 DocumentReader 批量添加元信息，比如我们可‏以在 loadMa؜rkdown 时为每篇文章添加特定标‌签。过读取文件名的倒数第 3 和第 2 个字符，提取出一个状态码（如 “01”），作为标签注入到文档的 metadata 中。然后在构造 MarkdownDocumentReaderConfig 时，通过 .withAdditionalMetadata() 方法把文件名和状态信息一并加入，实现文档内容与业务语义的绑定，方便后续向量检索中按条件筛选。

③自动添加元信息
Spring AI 提供了生成元信息的 Transformer 组件，可以基于 AI 自动解析关键词并添加到元信息中。通过 KeywordMetadataEnricher，结合大模型（如 DashScope ChatModel）对文档进行语义分析，自动提取每个文档的核心关键词，并以 metadata 形式附加到文档对象中。

向量转换和存储

需要根据费‏用成本、数据规模、؜性能、开发成本来选择向量存储方案，比‌如内存 / Red‏is / MongoDB。

文档过滤和检索

①多轮查询
在多轮会话场‏景中，用户输入的提示词؜有时可能不够完整，或者存在歧义。多查询扩展技‌术可以扩大检索范围，提‏高相关文档的召回率。
核心流程是：

1. 基于原始 Query 调用大模型，生成 3~5 个语义多样但相关的查询；
2. 使用每个扩展查询去向量检索文档；
3. 合并去重召回结果，用于丰富上下文或改写 Prompt。
   这样可以有效弥补用户输入的歧义或不完整，提升语义检索质量。

②查询重写和翻译
查询重写（Query Rewrite） 和 翻译（Translation） 是为了让查询更精准、专业，并适配多语言场景，同时保持原始语义不丢失。
查询重写使用 RewriteQueryTransformer 对用户输入的查询进行语言优化、结构规范，让模型更容易理解。
多语言支持若涉及非中文输入，可配置 TranslationQueryTransformer 实现自动翻译为目标语言，如英文。

查询增强和关联

模型需要根据用户提示词和检索内容生成最‌终回答。然而，返回结果可能仍未达到‏预期效果，需要进一步优化。
错误处理机制的核心是兜底 + 引导：当遇到无相关文档、相似度低或查询超时等异常时，我们使用 Spri؜ng AI 的 ContextualQu‌eryAugment‏er 上下文查询增强器，通过开启 allowEmptyContext 允许空上下文查询，结合统一异常处理和友好提示，引导用户补充信息、重试查询，确保系统不崩、体验不烂。

工具调用

在项目中，我为 AI Agent 实现了一个文件操作工具类，通过 @Tool 和@ToolParam注解让模型能调用 readFile 和 writeFile 方法，实现自然语言到文件读写的自动转换。技术上用到了 Hutool 的 FileUtil 简化了 IO 操作，所有写入都自动建目录并做了异常处理，保证调用鲁棒性和安全性。

实现了AI 工具类 WebSearchTool，可以让 AI 实时联网搜索信息。核心是通过 @Tool 和@ToolParam注解让模型能调用 SearchAPI.io 提供的百度搜索接口，传入关键词后，通过 HttpUtil.get() 发起网络请求，然后解析返回的 JSON 数据，提取前 5 条搜索结果返回。

实现了一个 AI 工具类 WebScrapingTool，通过 @Tool 注解暴露方法给 AI 模型使用，允许模型在需要时调用它来抓取网页内容。具体是使用Jsoup.connect(url).get() 获取网页源码。

底层数据结构

AI 之所以知道何时、如何调用工具，是因为每个工具都实现了 ToolCallback 接口，并通过 getToolDefinition() 方法向 AI 模型暴露工具的名称、描述和基于 JSON Schema 的参数定义。模型根据这些信息推理出需要调用的工具及其参数。我们使用 @Tool 和 @ToolParam 注解定义方法时，Spring AI 会自动解析方法签名，生成 ToolDefinition，并将其封装成 ToolCallback 实例（如 MethodToolCallback），同时通过 ToolCallResultConverter 统一处理返回值。这套机制让工具调用对 AI 透明又可控，实现了自然语言与方法调用之间的无缝衔接。

工具上下文

在实际应用中，Spring AI 通过 ToolContext 提供了工具调用时所需的额外上下文信息（如用户登录名、token、请求 ID 等），本质上是一个内部使用的 Map，不会暴露给 AI 模型。这样，模型只负责识别意图和构造工具参数，而不会接触敏感信息。比如在用户发起“我要退款”请求时，系统可以直接从上下文中提取 userId，完成退款操作，无需模型再次询问“你是谁？”。这种机制既增强了安全性，又提升了交互体验。

ToolCallingManager

Spring Al 的工具调用核心在于 ToolCallingManager，它是整个工具调用流程的“大脑”。它根据 AI 模型返回的 toolCalls 指令，自动解析需要调用的工具定义（resolveToolDefinitions），然后执行对应的工具逻辑（executeToolCalls），并把结果返回给模型。它还能统一处理调用过程中出现的异常，保证流程稳定。通常，Spring Boot Starter 会自动初始化 DefaultToolcallingManager，配备了工具观察器、解析器和异常处理器。简单来说，ToolCallingManager 就是 AI 和工具之间的桥梁，负责识别模型意图、调度工具执行、并管理异常，确保工具调用安全高效。

MCP服务

1、技术方案

客户端开发

开发一个 MCP 客户端服务其实就是要自定义一个支持 Spring AI 所需协议的「模型上下文协议（Model Context Protocol, MCP）」服务，它可以让大模型在调用你的服务时，把你定义的工具（Tool）当作插件来用。
配置文件：告诉 Spring AI 如何连接外部的 MCP 工具服务，包括：
• SSE 模式：连接一个运行在 http://localhost:8080 的 MCP 服务；
• Stdio 模式：通过启动本地可执行程序（如 /path/to/server）来使用 MCP 工具，支持传参和环境变量；
• Filesystem 工具：通过 npx 启动文件系统 MCP 服务，允许 AI 访问指定目录的文件。

使用MCP服务3步
1️、注入 McpSyncClient / McpAsyncClient 连接你的 MCP 工具服务
2️、获取 ToolCallback[] 将 MCP 工具转成模型可识别的“插件”
3️、模型调用时传入.tools(toolCallbackProvider) 让 AI 可以调用工具增强能力

服务端开发

开发 MCP 服务端只需四步：首先引入对应的 Spring Boot Starter 依赖（支持 stdio 或 webmvc）；然后在配置文件中指定服务名称、通信方式（如 stdio 或 SSE 端点路径）；接着使用 @Tool 和 @ToolParameter 注解编写业务方法，让它们作为 AI 可调用的工具暴露出来；最后在启动类中注册 ToolCallbackProvider，将这些工具方法交给 Spring AI 自动识别和管理，完成服务端能力开放。

2、后端实现

MCP图片搜索服务端开发

第一步：搭骨架，引入依赖。
我先引入了 Spring AI MCP 服务端相关依赖，选择 WebMVC 模式，搭好项目基础框架。

第二步：写配置，激活模式。
在 resources 下写了两套配置文件 application-stdio.yml 和 application-sse.yml，通过 application.yml 灵活指定激活哪种模式，像切换皮肤一样简单。

第三步：写工具，用注解暴露服务。
我写了一个图片搜索类 ImageSearchTool，核心方法加上了 @Tool 和 @ToolParam 注解，把它当成一个 AI 工具暴露出来，供模型远程调用。这个类里封装了访问 Pexels 图片搜索 API 的逻辑，支持关键词搜索返回图片列表。

第四步：注册服务，让 AI 找得到工具人。
在主类里通过定义 ToolCallbackProviderBean，把工具注册到 MCP 框架中，就像告诉 AI：“我这有个能干的图片搜索工具，快来用吧！”

MCP图片搜索客户端开发

客户端通过在配置中指定 MCP 插件服务的启动方式，例如用 Java 启动一个 jar 包，并通过 stdio 通信通道与其交互。这样插件服务就像“一个小弟进程”，客户端扔指令，它马上执行并返回结果。整个通信是轻量的、无网络延迟，适合模型本地调用插件能力。

服务端与客户端交互

通过在客户端注册了 MCP 服务名，Spring AI 会自动启动一个子进程，并读取插件暴露的 Tool 接口定义。大模型根据 prompt 自动决定是否调用这个工具，如果命中，就通过 stdio 调用 MCP 插件返回结果，整个流程像是在让 AI 给你“远程点外卖”，注册菜单 + 交互下单 + 拿结果。

MCP实践心得

1. 根据项目规模选传输模式：小项目用 stdio，直接作为子进程调用，简单高效；中大型项目用 SSE，部署为独立服务，支持多端调用，更易维护和扩展。
2. 工具定义清晰：通过 @Tool 和 @ToolParam 注解，准确描述每个工具的功能和参数，方便 AI 识别和调度。
3. 加强容错处理：对各种异常情况进行统一捕获，返回结构化的错误信息，确保系统稳定性和易于调试。
4. 优化响应性能：对耗时操作使用异步处理，设置合理的超时时间，避免因调用阻塞影响整体体验。

AI智能体构建

1、 技术方案

CoT思维链

CoT（思维链）是一种引导 AI 像人类一样“先思考、再作答”的方法，特别适合解决复杂推理问题。实现上很简单：可以通过提示语（如“我们一步步来”）引导模型逐步推理，或用 few-shot 示例教会它如何展开思路，提升准确率和可解释性。

Agent Loop 执行循环

Agent Loop 执行循环 Agent Loop 是智能体最核心的工作机制，指智能体在没有用户输入的情况下，自主重复执行推理和工具调用的过程。 在传统的聊天模型中，每次用户提问后，AI回复一次就结束了。但在智能体中，AI回复后可能会继续自主执行后续动作(如调用工具、处理结果、继续推理)，形成个自主执行的循环，直到任务完成(或者超出预设的最大步骤数)。

ReAct 模式

ReAct(Reasoning + Acting)是一种结合推理和行动的智能体架构，它模仿人类解决问题时"思考-行动-观察”的循环，目的是通过交互式决策解决复杂任务，是自前最常用的智能体工作模式之一
核心思想!

• 推理(Reason)：将原始问题拆分为多步骤任务，明确当前要执行的步骤。
• 行动(Act)：调用外部工具执行动作，比如调用搜索引擎、打开浏览器访问网页等。
• 观察(Observe)：获取工具返回的结果，反馈给智能体进行下一步决策。
• 循环迭代：不断重复上述3个过程，直到任务完成或达到终止条件。

2、OpenManus实现原理

OpenManus 的代理架构主要包含以下几层：

• BaseAgent：最基础的代理抽象类，定义了所有代理的基本状态管理和执行循环（关键代码就是 Agent Loop 的实现，通过while 实现循环，并且定义了死循环检查机制）
• ReActAgent：实现 ReAct 模式的代理，具有思考(Think)和行动(Act)两个主要步骤（将代理的执行过程分为思考(Think)和行动(Act)两个关键步骤）
• ToolCallAgent：能够调用工具的代理，继承自 ReActAgent 并扩展了工具调用能力（在 ReAct 模式的基础上增加了工具调用能力）
• Manus：具体实现的智能体实例，集成了所有能力并添加了更多专业工具

3、自主实现Manus智能体

核心框架

·BaseAgent:智能体基类，定义基本信息和多步骤执行流程
·ReActAgent:实现思考和行动两个步骤的智能体
·ToolCallAgent:实现工具调用能力的智能体
·YuManus:最终可使用的 Manus 实例

BaseAgent类

构建一个抽象的“Agent代理”基础类，用于封装 LLM 多轮交互的控制逻辑。子类只需要实现每一步 step() 的逻辑即可，核心流程、状态管理、上下文记忆都封装在基类里。

run(String userPrompt) 是代理执行的主入口，负责整体流程控制：在状态为 IDLE 时接收用户输入，记录到上下文中，然后循环执行最多 maxSteps 次 step() 方法，每一步代表一次代理行为（如调用大模型或执行工具），并收集每步结果；若执行成功则状态转为 FINISHED，若超步数或出错则分别标记为 FINISHED 或 ERROR；最后统一调用 cleanup() 释放资源。而 step() 是一个抽象方法，由子类实现每一步的具体逻辑，驱动代理逐步推进。

ReActAgent类

ReActAgent 是基于 BaseAgent 扩展的抽象类，实现了典型的 “思考-行动（Reasoning and Acting）” 模式：每个 step 步骤被细化为先执行 think() 判断是否需要行动，再根据结果执行 act() 并返回执行结果。这种设计将逻辑决策与具体执行解耦，方便子类分别实现推理与行动逻辑。它继承了 BaseAgent 的执行框架和状态管理逻辑，同时通过复写 step() 方法嵌入了更具智能性的行为控制流程。

ToolCallAgent类

ToolCallAgent 是一个具备自主工具调用能力的智能代理类，继承自 ReActAgent，完整实现了 think() 和 act() 两个核心方法，实现了一个“思考 → 判断是否调用工具 → 调用工具 → 返回结果”的 ReAct 闭环。

在 think() 方法中，代理根据已有上下文和下一步提示词，调用大模型生成包含工具调用意图的响应（ChatResponse），并解析其中的工具调用信息（如工具名称、参数）；若响应中包含工具调用，则进入 act() 阶段；否则直接结束本轮。

在 act() 方法中，ToolCallAgent 使用 Spring AI 提供的 ToolCallingManager 来执行工具调用，并从中获取调用结果与最新的上下文对话历史（包括工具响应消息），并更新 messageList 以便下一轮交互使用。

该类相较于 ReActAgent，将原本抽象的“行动”具体实现为对 Spring AI 工具的精细控制式调用，通过设置 withProxyToolCalls(true) 禁用了 Spring 内建的工具代理机制，从而保留了对工具选择、参数传递、调用节奏的完全掌控。最终实现了一个可插拔、可观察、可控制的智能工具执行代理，便于集成多个第三方或业务自定义工具，构建复杂多步骤的 AI 任务执行流程。

YuAnManus类

YuAnManus 是一个可直接调用的多工具智能体类，继承自 ToolCallAgent，其核心功能是整合多个工具（ToolCallback[]），借助大模型（如 DashScope）执行复杂任务，具备多轮调用工具、自动决策、任务拆解、结果解释等智能行为。它通过设置系统提示词（system prompt）与下一步提示词（next step prompt），引导模型如何使用工具解决问题。

与 ToolCallAgent 的关系：
YuAnManus 实际是 ToolCallAgent 的具体实现类，ToolCallAgent 提供了通用的工具调用逻辑和执行框架，而 YuAnManus 在此基础上配置了具体的对话模型、提示词、工具集合等参数，形成一个可交互、可嵌入的智能体实例，可被 Spring 容器注入后复用。本质上，它就是“带工具的聊天代理”的具体落地形态。

AI服务化

AI接口开发

1、发起流式对话请求：

Flux 表示多个流式响应 chunk，例如模型一句话一段地输出。

2. 提供前端 SSE 接口

方法一：纯字符串流输出：Flux
方法二：封装成 ServerSentEvent：Flux<ServerSentEvent>
方法三：分装成SseEmitter

AI智能体接口开发

1、BaseAgent

基于 BaseAgent 实现了一个支持流式输出（SSE）的运行方法 runStream(String userPrompt)，是为了让 AI 智能体服务能够边处理边返回内容，前端实时展示结果。这是从阻塞式执行模型升级为非阻塞、流式响应模型的重要变动。
① 使用 SseEmitter 创建长连接；
② 使用 CompletableFuture.runAsync(…) 异步执行，避免阻塞主线程；
③ 在每一个 step() 执行后，用 emitter.send(…) 将结果发给前端
④ 在结束、超时或异常时，调用 .complete()、.completeWithError(…)

2、在 Aicontroller 中编写新的接口

每次对话都要创建一个新的实例