升级后 ConversationService.process 的完整执行链：

AI 客服系统安全加固：JWT 鉴权 + Bucket4j 三层限流

先说Router + 多 Agent 的价值不在于"高大上"，而在于让每个 Agent 的 Prompt 专注、工具干净；多轮记忆迁移 Spring AI 官方实现后反而geng省事，踩坑主要在 API 设计理解上。

我们的核心架构分为两大部分:升级的NLU引擎和稳健的对话状态管理。.意图识别和实体抽取是智Neng客服的 大脑 .核心痛点集中在三点:高并发下的系统稳定性、复杂多变的用户意图准确理解、以及跨多轮对话的上下文连贯性保持.

原来的 CustomerServiceAgent 要处理：产品咨询、订单查询、退款申请、物流追踪、投诉安抚……Prompt 超过 字，工具挂了 个。说实话跑起来以后发现模型经常"混淆"：用户说"东西用着不好用"它有时候当 RAG 处理，有时候当投诉处理，飘忽得hen。

覆盖内容：JWT Filter 链接入 Spring Security、三层令牌桶限流、链路追踪 Filter、生产密钥强校验。项目里这些Yi经实现完整，下一篇逐层拆开讲。

LLM 识别不是百分百可靠，设了一个置信度阈值兜底：

public abstract class BaseAgent { protected final ChatClient chatClient; protected final ChatMemory chatMemory; protected BaseAgent { this.chatClient = chatClient; this.chatMemory = chatMemory; } /** * 核心对话方法：记忆 Advisor + 额外 Advisor + 工具 * * @param extraAdvisors 子类传入的额外 Advisor */ protected String chatWithAdvisors { var memoryAdvisor = MessageChatMemoryAdvisor.builder .conversationId .build; // 区分 Advisor 和 Tool List<Advisor> advisors = new ArrayList<>; advisors.add; List<Object> tools = new ArrayList<>; for { if { advisors.add; } else { tools.add; } } // ... 构建 ChatClient 调用链 }} CustomerSupportRouter 是一个纯规则路由器，不调 LLM，延迟稳定：

public String chat { // . 情绪优先：ANGRY 直接走投诉 Agent if == EmotionLevel.ANGRY || ctx.intentType == IntentType.COMPLAINT) { return complaintAgent.chat; } // . 售后意图 → 售后 Agent if )) { return postSalesAgent.chat; } // . 其余 → 售前 Agent return preSalesAgent.chat;}private boolean isPostSalesIntent { return intent == IntentType.ORDER_QUERY || intent == IntentType.REFUND || intent == IntentType.LOGISTICS;}

关于 Spring AI ChatMemory官方封装比自己写 Redis 省事，但前提是kan懂三层接口结构。文档这块写得不够直观，hen多人第一反应是"直接把 JdbcChatMemoryRepository 当 ChatMemory 用"，然后编译报错。建议把那张关系图打印出来贴桌上。

@Servicepublic class SensitiveWordServiceImpl implements SensitiveWordService { // 从 DB 加载，内存缓存 private volatile Set<String> sensitiveWords = new HashSet<>; @Override public String filter { if || text == null) return text; String result = text; String replaceChar = getReplaceChar; // 默认 "***" for { result = result.replace; } return result; } @Override public boolean containsSensitiveWord { if || text == null) return false; return sensitiveWords.stream.anyMatch; }} SensitiveWordController 的管理接口，以及刷新缓存的 API，放在下一版迭代里。

RAG 知识库和转人工流程计划放在后续篇章单独展开。

维度改造前改造后 Agent 数量1 个全Neng Agent 个专业 Agent + 规则路由Prompt 长度500+ 字，大杂烩每 Agent ≤ 字，专注清晰 多轮记忆手写 Redis + 手动 recordMemorySpring AI官方 JdbcChatMemoryRepository，Advisor 自动读写 记忆依赖RedisPostgreSQL，与业务 DB统一 敏感词 无双向过滤，配置存DB，可运营后台管理 意图识别LLM 单点识别LLM +关键词兜底双保险 降级策略无Router失败 →关键词规则 →转人工三级降级 几个Zuo完之后的感悟

关于多 Agent拆分 起初觉得 个 Agent是 "过度设计"，跑起来以后发现Zui明显的收益是 debug容易多了。投诉 Agent回了一句奇怪的话，我只要kan ComplaintAgent 的 Prompt和上下文，不用在一个 字的大杂烩里找原因。

当然缺点也有：新增意图类型时需要改代码。等后续有机会再评估升 LlmRoutingAgent。 踩坑提醒：MessageChatMemoryAdvisor.Builder 在 Spring AI.x里 没有 windowSize 方法 ,窗口大小由 MessageWindowChatMemory