木子小站

# Mu-ai-agent-13 # 前言 #12 讲完了检索阶段：怎么从向量库把文档取回来、多路结果怎么合并。这一篇继续往下走 —— 文档取回来之后、拼进 prompt 之前还能做什么优化。 Spring AI 1.1.8 给后处理只留了一个 DocumentPostProcessor 接口，没有任何内置实现。也就是说这一环完全开放，要啥自己写。本篇把实际落地的五个处理器串成一条固定顺序的链路：过滤 → 去重 → 重排 → 预算 → 增强。 # 图一：检索后处理在整条链路中的位置 三个 advisor 的顺序和前几篇一样：记忆最先，检索增强居中，日志最后。检索后处理发生在检索增强 advi

# Mu-ai-agent-12 # 前言 #11 用图把预检索（query 加工）讲了一遍，这篇回到 RAG 链路的下一截：检索阶段（retrieval phase）。 预检索解决的是「拿什么去检索」——把含混的多轮追问补全、改写成检索友好的问题；检索阶段解决的是「拿回文档之后怎么办」——多路结果怎么合并、重复片段怎么去掉、最终喂给模型的上下文窗口怎么控制。 本次实现把检索参数、文档合并器、上下文注入器和检索后处理器从预检索配置里拆出来，单独成一个 mu-ai.rag.retrieval 配置前缀。下面是新增部分的完整位置。 # 图一：检索阶段在整条 RAG 链路中的位置 链路从上到下的顺

# Mu-ai-agent-11 # 前言 #10 写预检索改造时，重点放在「为什么这么改」：多轮追问检索稀散的病因、四个组件的取舍、默认值怎么定。这一篇换个角度，用三张图把「改动之后到底怎么跑」完整拆一遍——文字只做图的补充，想看决策过程的去翻 #10 就好。 行文依据是仓库的当前实现：预检索与检索阶段已经拆成两个配置类，所以这篇里的链路图比 #10 的版本多了合并与后处理两环。 # 图一：预检索站在链路的哪个位置 一次 RAG 问答由三个 advisor 接力完成，order 决定先后： 记忆 advisor（order = -2147482648）最先跑，把对话历史写进 p

# Mu-ai-agent-10 # 前言 前三篇把 RAG 这条链路从无到有搭了起来：#7 用 TikaDocumentReader + TokenTextSplitter + text-embedding-v3 跑通检索增强问答，#8 把内存版向量库换成 PgVectorStore 做持久化，#9 把 embedding 请求的切批职责收进 BatchingStrategy。 链路是通的，但检索质量一直有个说不清的毛病：多轮追问时，检索结果会稀散。 问题出在 QuestionAnswerAdvisor 上。它做的事很朴素——拿用户的原始 query，直接丢给向量库： chatClient

# Mu-ai-agent-9 # 前言 前两篇把 RAG 链路搭了起来：TikaDocumentReader 读文档、TokenTextSplitter 切块、text-embedding-v3 向量化，再换到 PgVectorStore 做持久化。跑通之后，灌库环节留了个隐患。 知识库里的 7 篇 Markdown 最终切出 12 个分块，而 DashScope 的 embedding 接口对「单次请求的文本条数」是有硬性限制的。当时的写法是在 DocumentLoader 里手动按 10 条切片、循环提交： // 改造前：在业务代码里手动绕开厂商限制 for (int

# Mu-ai-agent-8 # 前言 上一篇给项目接上了 RAG：TikaDocumentReader 读文档、TokenTextSplitter 切块、text-embedding-v3 向量化，最后存进 SimpleVectorStore。四步拼起来，技术文档问答就跑通了。 但收尾时我在心得体会里留了一句 " 生产环境需要换持久化方案（PgVector、Redis、Milvus 等）"，然后就翻篇了。这篇把它补上——换成 PgVector 之后，顺带把整条 RAG 链路第一次纳入集成测试。 先摆清楚内存版的两个硬伤： 重启即丢。SimpleVectorStore

2026-07-07🌱上海: ☁️ 🌡️+37°C # 背景 这次改造的核心目标，是把木南项目里的 AI 智能体从“前端按钮 + 固定逻辑”的形态，推进到一个可以后台管理、可以观察运行过程、可以持续演进的配置中心。 在这个版本之前，某些所谓智能体更像是前端快捷入口。比如“拼豆达人”只是一个前端提示词按钮，没有后端 Agent 定义、工具链、Prompt 版本和运行日志，因此它不适合作为真实智能体保留。 本轮最终收敛的范围是 智能体配置中心 v1 + 旅游助手闭环： 后台可以管理智能体定义、Prompt 模板和工具绑定。 Prompt 主视图只展示当前生效版本，历史版本通过展开区查看。

2026-06-26🌱上海: ☀️ 🌡️+95°F 🌬️SE6mph # Mu-ai-agent-7 # 前言 前面几篇文章把 AI Agent 的核心组件都过了一遍：模型调用、Advisor 链、结构化输出、记忆管理、Prompt 模板、多模态视觉。但还有一个非常实用的场景没涉及—让 AI 基于我们自己的文档来回答问题，也就是 RAG（Retrieval-Augmented Generation，检索增强生成）。 用大白话说，RAG 做的事情就是： 把文档切成小块，每块转成向量存到向量数据库里 用户提问时，先把问题也转成向量，去数据库里搜最相关的文档片段 把搜到的文档片段拼到 pro

2026-06-26🌱上海: ☀️ 🌡️+91°F 🌬️SE7mph # Mu-ai-agent-6 # 前言 在前面的五篇文章中，我们的 AI 助手一直是个 " 纯文字选手 "—它能聊面试、记上下文、做结构化输出，但如果你给它发一张图片，它就完全看不懂了。这在很多场景下是个硬伤：比如用户拍了一张报错截图想让助手帮忙排查，或者上传了一张商品图想自动生成描述文案。 这次就来给 Agent 加上 " 眼睛 "—接入通义千问的视觉语言模型 Qwen-VL，让它具备图片理解能力。整体思路和前面的文本对话一样：复用 Spring AI 的 ChatClien

2026-06-24🌱上海: ☀️ 🌡️+90°F 🌬️S8mph # Mu-ai-agent-5 # 前言 在前面的几篇文章中，我们的 prompt 都是直接硬编码在 Java 代码里的—用字符串拼接构造用户消息，或者写一个 static final String 常量当系统提示词。这种做法在小规模项目里没什么问题，但随着 prompt 越来越多、越来越长，弊端就显现出来了： 想调一下措辞让模型回答更好？得改 Java 代码、重新编译、重新部署 多个方法里都有大段的 prompt 字符串，代码可读性很差 想统一修改 prompt 风格？得到处翻、到处改 这个问题其实在 Web 开发