Agentic RAG规划缓存：从任务规划到执行复用的性能跃迁-平芜编程栈

1. 项目概述：从传统RAG到Agentic RAG的范式跃迁

最近在优化一个企业级知识库问答系统时，我遇到了一个典型的性能瓶颈：用户每次提问，系统都要完整地走一遍“检索-增强-生成”的流程。对于一些高频、复杂但模式固定的查询，比如“请总结上周所有关于产品A的客户反馈并给出改进建议”，每次都要重新规划、检索多轮、再生成，响应时间慢不说，对计算和检索资源的消耗也很大。这让我开始思考，RAG（检索增强生成）能不能更“聪明”一点？能不能像人一样，记住一些处理复杂问题的“套路”或“蓝图”，下次遇到类似问题直接调用，省去重复的规划开销？

这就是“Agentic RAG规划缓存策略”要解决的核心问题。它不再是简单的文档片段缓存，而是将大模型（LLM）作为智能体（Agent）进行复杂任务分解和规划的能力“缓存”下来。简单来说，就是把Agent思考“如何解决某类问题”的步骤蓝图存起来，下次遇到同类问题，直接按图索骥，跳过耗时的规划阶段。这不仅仅是提速，更是让RAG系统具备了“经验积累”和“工作流复用”的能力，是RAG从“工具”走向“智能助理”的关键一步。

如果你也在构建需要处理多步、复杂查询的RAG应用，并且对响应延迟和成本敏感，那么深入理解并实施Agentic RAG规划缓存，将是提升系统性能和用户体验的必由之路。

2. 核心思路拆解：为什么缓存“规划”比缓存“结果”更有效？

在深入技术细节前，我们必须先厘清一个根本逻辑：为什么要缓存“规划”？

传统的缓存策略，无论是缓存检索到的文档片段（Chunk Cache）还是缓存最终的生成答案（Answer Cache），其粒度都集中在“数据”或“结果”层面。这在处理简单、事实型问答时效果显著。然而，对于复杂的Agentic RAG场景，其瓶颈往往不在于数据检索本身，而在于前期的“任务规划与分解”。

2.1 传统缓存的局限在复杂场景下的暴露

假设一个查询是：“分析我们竞品B最近三个月的市场活动，并评估其对我们的潜在威胁，最后起草一份应对策略简报。”

一个典型的Agentic RAG处理流程可能是：

规划阶段：LLM分析查询，将其分解为子任务：a) 检索竞品B近三个月的市场活动信息；b) 检索我方产品与市场定位信息；c) 进行交叉分析与威胁评估；d) 根据评估结果，生成简报框架与内容。
执行阶段：针对每个子任务，可能发起一轮或多轮检索，调用不同的工具（如搜索引擎、内部数据库、分析模型），并逐步生成中间结果。
合成阶段：汇总所有中间结果，生成最终答案。

在这个流程中，最耗时、最消耗Token的部分往往是第1步（规划）和第2步中多轮LLM调用以协调执行。如果我们只缓存最终答案，那么当用户稍后问“关于竞品B，更新到最近四个月的数据再分析一次”时，缓存失效，系统需要完整重跑所有步骤。如果我们只缓存检索到的文档，虽然节省了部分向量检索时间，但代价高昂的规划与多步LLM协调推理仍需从头开始。

2.2 规划缓存的优势：复用“方法论”

规划缓存的核心思想是：将针对某一类问题的、经过验证的任务分解蓝图（Plan）和执行逻辑（Orchestration Logic）缓存起来。

对于上面的例子，系统在第一次成功处理该类“竞品分析”请求后，可以抽象并缓存这样一个规划模板：

规划模式识别：识别查询意图为“竞品多维分析报告生成”。
固化任务图：缓存一个预定义的任务执行图，例如：[检索竞品动态 -> 检索我方现状 -> 交叉分析 -> 报告生成]。
参数化槽位：将查询中的变量（如“竞品B”、“三个月”）抽象为可填充的槽位（Slots）。

当类似的新查询到来时（如“分析竞品C最近两个月的...”），系统首先进行快速的模式匹配。如果命中缓存的规划模板，则直接加载该模板，将新参数（竞品C，两个月）填充到槽位中，然后跳过耗时的LLM规划阶段，直接进入“按图执行”阶段。

这样做带来了多重好处：

大幅降低延迟：避免了每次都由LLM进行任务分解的耗时，响应速度提升可能达到50%以上，尤其对于复杂查询。
显著减少Token消耗：规划阶段通常需要与LLM进行多轮交互（如ReAct, CoT），缓存规划节省了大量提示词和生成Token。
提升结果一致性与可控性：缓存的规划是经过人工校验或历史验证的最佳实践，避免了LLM每次规划可能产生的随机性或偏差，使系统行为更稳定、更符合业务规范。
实现经验沉淀：优秀的处理流程可以固化下来，成为系统的“标准操作程序”（SOP）。

3. 架构设计与核心组件解析

要实现一个高效的Agentic RAG规划缓存系统，我们需要一个精心设计的架构。它不仅仅是加一个Redis那么简单，而是一套感知、抽象、存储、匹配和执行的完整逻辑。

3.1 系统架构总览

一个典型的规划缓存系统包含以下核心组件，它们协同工作：

[用户查询] -> 查询分析器 (意图识别 & 参数提取) -> 规划缓存匹配器 (与缓存索引进行匹配) -> 若命中：加载缓存规划 -> 规划执行引擎 (按缓存蓝图执行) -> 若未命中：原生规划器 (LLM生成新规划) -> 规划执行引擎 -> 规划抽象器 (抽象为模板) -> 存入缓存库 -> 最终结果生成

3.2 核心组件深度解析

3.2.1 查询分析器与意图识别

这是缓存命中的第一道关卡。它的目标不是理解所有细节，而是快速提取查询的“模式指纹”。我们通常采用轻量级、快速的方法：

关键词与实体提取：使用NER模型或规则快速提取关键实体（如产品名、时间范围、动作动词“分析”、“总结”、“对比”）。
意图分类：训练一个轻量级文本分类模型（如FastText、小规模BERT），将查询分到预定义的几大类意图中，如“摘要生成”、“对比分析”、“根因分析”、“报告起草”等。这一步非常关键，它是后续匹配的基础。
参数槽位填充：将提取的实体填入预定义的槽位框架。例如，对于“分析竞品B最近三个月的市场活动”，输出结构化的表示：{intent: “competitive_analysis”， slot: {competitor: “B”， timeframe: “3 months”， subject: “marketing_activity”}}。

实操心得：意图分类模型不需要用巨型LLM，一个在业务日志上微调的小模型就足够，速度极快。重点在于业务意图类别的设计要合理，覆盖核心场景，不求全，但求准。

3.2.2 规划缓存匹配器

匹配器负责将当前查询的结构化表示与缓存库中的规划模板进行匹配。匹配逻辑需要兼顾准确性和效率：

索引结构：缓存库的索引不是存储原始规划，而是存储规划的“特征签名”。这个签名通常包括：意图类别、关键实体/槽位的类型、任务图的拓扑结构哈希等。
匹配算法：
- 精确匹配：适用于高度规范化的场景。当意图和所有槽位类型完全一致时命中。
- 相似度匹配：更常用的方式。计算查询特征与缓存模板特征的相似度（如基于槽位向量的余弦相似度）。需要设置一个阈值（如0.85）。
- 层次化匹配：先匹配意图，在相同意图下再匹配槽位相似度，提高效率。

缓存元数据：每个缓存条目还应包含元数据，用于缓存管理和淘汰。

{ "plan_id": "plan_001", "intent": "competitive_analysis", "signature": {"slot_types": ["competitor", "timeframe", "subject"], "task_graph_hash": "a1b2c3..."}, "plan_template": {...}, // 具体的规划蓝图 "hit_count": 42, "last_hit_time": "2024-05-20T10:30:00Z", "creation_time": "2024-05-10T14:20:00Z", "avg_latency_saved": 2.5 // 该规划平均节省的秒数 }

3.2.3 规划抽象器与模板化

这是将一次成功的LLM原生规划转化为可复用模板的关键步骤，也是技术难点。当查询未命中缓存，并由原生规划器（LLM）生成并成功执行了一个新规划后，规划抽象器需要工作：

轨迹记录：完整记录本次Agent执行的轨迹，包括LLM的完整思考过程（Chain-of-Thought）、调用的工具序列、工具参数、中间结果。
泛化与抽象：
- 具体值替换为槽位：将轨迹中的具体查询值（如“竞品B”）替换为通用变量（如{competitor}）。
- 标准化工具调用：确保工具调用的名称和参数结构是标准的。
- 提取任务依赖图：分析工具调用和LLM思考的先后顺序，形成一个有向无环图（DAG），这就是“任务蓝图”。
模板存储：将抽象后的规划，包括意图标签、参数槽位定义、任务DAG、以及每个节点对应的提示词模板或工具调用模板，序列化后存入缓存库。

注意事项：自动化的规划抽象有一定风险，可能抽象出错误或不高效的模板。初期可以采用“人工审核后入库”的半自动模式。系统可以标记出新产生的、执行成功的规划，由开发或业务人员确认后，再将其转化为正式缓存模板。

3.2.4 规划执行引擎

无论规划来自缓存还是LLM实时生成，最终都由执行引擎来按步骤运行。它需要是一个通用的、可解释的工作流引擎：

加载任务图：读取规划模板，实例化任务DAG（将槽位{competitor}替换为实际的“竞品C”）。
协调执行：按照DAG的依赖关系，依次执行每个节点。节点可能是“调用检索工具”、“调用LLM进行信息合成”、“调用代码解释器进行计算”等。
上下文管理：负责将上游节点的输出，作为下游节点的输入进行传递和管理。
异常处理与重试：某个节点执行失败时，需要有预定义的降级策略或重试机制。

4. 缓存策略与存储方案实战

确定了架构，接下来就要解决“怎么存”和“存什么”的具体问题。规划缓存的对象不是简单的键值对，而是结构化的、有生命周期的知识资产。

4.1 缓存对象的序列化设计

规划模板需要被序列化以便存储和检索。JSON是一种灵活的选择。一个简化的规划模板示例如下：

{ "version": "1.0", "intent": "generate_weekly_summary", "description": "生成针对特定产品的每周客户反馈总结与建议", "slots": [ {"name": "product_name", "type": "string", "description": "产品名称"}, {"name": "week_offset", "type": "integer", "description": "周偏移量，0表示本周，-1表示上周"} ], "task_graph": { "nodes": [ { "id": "retrieve_feedback", "type": "tool_call", "tool_name": "vector_search", "parameters": { "query_template": "产品{product_name} 过去一周的用户反馈、投诉、赞扬", "collection": "customer_feedback" }, "output_key": "feedback_docs" }, { "id": "analyze_sentiment", "type": "llm_prompt", "depends_on": ["retrieve_feedback"], "prompt_template": "请分析以下用户反馈列表，总结出正面、中性和负面的主要观点，并归类。反馈：{feedback_docs}", "output_key": "sentiment_analysis" }, { "id": "generate_report", "type": "llm_prompt", "depends_on": ["analyze_sentiment"], "prompt_template": "基于以下情感分析，为产品团队起草一份简洁的每周总结报告，突出关键问题和改进建议。分析结果：{sentiment_analysis}", "output_key": "final_report" } ] }, "sample_input": {"product_name": "产品A", "week_offset": -1}, "sample_output": "...(示例报告文本)..." }

4.2 存储后端选型与考量

缓存存储需要支持快速检索（通过意图/特征）和持久化。常见的方案有：

存储方案	适用场景	优点	缺点	推荐指数
Redis (JSON)	缓存模板的快速读取，存储特征索引。	内存读写，极快；支持丰富数据结构。	持久化可靠性需配置；存储复杂嵌套JSON性能尚可但非最优。	★★★★★ (用于热缓存)
PostgreSQL (JSONB)	持久化存储所有规划模板和元数据。	强一致性，支持复杂查询（如按意图、命中次数筛选），JSONB查询性能好。	绝对速度不如内存缓存。	★★★★★ (用于主存储)
向量数据库	基于规划特征向量的相似度匹配。	可以实现更灵活的相似意图匹配。	过度设计，维护复杂，匹配逻辑需精心设计。	★★☆☆☆ (特定场景)
本地文件/YAML	开发初期或模板数量很少时。	简单，无需运维。	无法支持并发和高效检索，不适合生产。	★☆☆☆☆ (仅原型)

我的实战选择通常是混合架构：

主存储（Source of Truth）：使用PostgreSQL，plan_templates表，利用JSONB字段存储完整的规划模板。这里存放所有经过验证的模板，支持管理后台的增删改查。
热缓存（Hot Cache）：使用Redis。系统启动时，将高频（hit_count > N）或最近的模板从PostgreSQL加载到Redis中。查询匹配器优先查询Redis。Redis中的模板可以设置TTL，并定期与PostgreSQL同步更新。
索引：在PostgreSQL中，对intent、signature等字段建立索引，便于后台管理和批量操作。

4.3 缓存更新与淘汰策略

规划缓存不是一成不变的，业务逻辑和知识库都在变化，缓存也需要新陈代谢。

更新策略：
- 被动更新（懒更新）：当执行一个缓存规划失败时（如工具API变更、返回格式错误），将该规划标记为“失效”，触发一次原生LLM规划流程。新规划成功后，由规划抽象器决定是否更新原有缓存模板（版本升级）或创建新模板。
- 主动更新（定时刷新）：定期（如每周）对高频缓存模板进行“健康检查”，用样本输入跑一遍流程，验证其输出是否依然合理。
- 版本关联：规划模板可以与知识库的版本或工具API的版本绑定。当检测到底层数据源有重大更新时，使依赖该数据源的缓存模板失效。
淘汰策略：基于Redis的缓存和PostgreSQL的存储都需要淘汰机制。
- LRU（最近最少使用）：在Redis中非常有效，自动淘汰最久未访问的模板。
- LFU（最不经常使用）：淘汰命中次数最少的模板。这需要我们在元数据中维护hit_count。
- 基于效果的淘汰：计算每个模板“平均节省的延迟”（avg_latency_saved）。当缓存满时，优先淘汰节省时间少的模板。这是一个更业务导向的策略。
- 综合策略：生产环境中，我常采用加权评分来决定淘汰优先级：优先级分数 = 0.3 * (1 / 最近访问时间) + 0.3 * 命中次数 + 0.4 * 平均节省延迟。分数低的模板优先被淘汰。

5. 实施流程与关键代码示例

让我们从一个具体的场景出发，看看如何一步步实现这个系统。假设我们有一个客服知识库，需要处理“产品故障排查”这类多步查询。

5.1 第一步：定义意图分类与槽位

首先，我们需要定义业务场景。例如，识别出“故障排查”是一个核心意图。

# intent_schema.py INTENT_SCHEMA = { "troubleshooting": { "description": "用户描述产品问题，寻求解决方案", "slots": [ {"name": "product", "type": "string", "required": True}, {"name": "symptom", "type": "string", "required": True}, # 如“无法开机”、“蓝屏” {"name": "error_code", "type": "string", "required": False} ] }, "feature_comparison": {...}, "document_summary": {...} }

5.2 第二步：实现查询分析器

我们用一个轻量级Pipeline来实现：

# query_analyzer.py import re from some_ner_library import EntityRecognizer from intent_classifier import IntentClassifier # 假设我们有一个训练好的小模型 class QueryAnalyzer: def __init__(self): self.ner = EntityRecognizer() self.intent_clf = IntentClassifier.load('models/intent_model.bin') self.slot_patterns = { 'error_code': r'错误[码号]?[：:]?\s*([A-Z0-9\-]+)', # ... 其他正则模式 } def analyze(self, query: str) -> dict: # 1. 意图分类 intent, confidence = self.intent_clf.predict(query) # 2. 实体提取 entities = self.ner.extract(query) # 提取产品名、通用名词等 slots = {} # 3. 基于规则/模式的槽位填充 (补充NER) for slot_name, pattern in self.slot_patterns.items(): match = re.search(pattern, query) if match: slots[slot_name] = match.group(1) # 4. 融合结果，形成结构化表示 # 例如，将NER提取的“iPhone 15”赋给slots['product'] for entity in entities: if entity.type == 'PRODUCT': slots['product'] = entity.text elif entity.type == 'PROBLEM': # 假设NER能识别问题类型 slots['symptom'] = entity.text return { "original_query": query, "intent": intent, "confidence": confidence, "slots": slots }

5.3 第三步：规划缓存匹配器实现

匹配器连接查询分析和缓存存储。

# plan_cache_matcher.py import json import hashlib from typing import Optional import redis from database import PlanTemplateDB # 假设的数据库访问层 class PlanCacheMatcher: def __init__(self, redis_client: redis.Redis, db: PlanTemplateDB): self.redis = redis_client self.db = db self.cache_key_prefix = "plan_cache:" def _generate_signature(self, intent: str, slots: dict) -> str: """生成查询的特征签名，用于匹配""" # 对槽位键进行排序，确保顺序不影响签名 slot_keys = sorted(slots.keys()) slot_str = json.dumps({k: slots[k] for k in slot_keys}, sort_keys=True) raw = f"{intent}::{slot_str}" return hashlib.md5(raw.encode()).hexdigest()[:12] def match(self, analyzed_query: dict) -> Optional[dict]: intent = analyzed_query['intent'] slots = analyzed_query['slots'] sig = self._generate_signature(intent, slots) # 1. 先查Redis热缓存 cache_key = f"{self.cache_key_prefix}{sig}" cached = self.redis.get(cache_key) if cached: self.redis.incr(f"{cache_key}:hits") # 更新命中计数 return json.loads(cached) # 2. Redis未命中，查数据库（可能包含更宽松的匹配，如同意图相似槽位） # 这里简化处理，只做精确匹配查询 template = self.db.find_template_by_signature(intent, sig) if template: # 加载到Redis，设置TTL为1小时 self.redis.setex(cache_key, 3600, json.dumps(template)) return template # 3. 都未命中，返回None，触发原生规划 return None

5.4 第四步：原生规划与抽象流程

当缓存未命中时，我们调用LLM进行规划，并在成功后抽象。

# plan_orchestrator.py from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI import json class PlanOrchestrator: def __init__(self, llm: ChatOpenAI): self.llm = llm self.planner_prompt = ChatPromptTemplate.from_messages([ ("system", "你是一个任务规划专家。请将用户的复杂问题分解为一系列可执行的子任务步骤。"), ("human", "用户问题：{query}\n请输出一个JSON格式的任务规划。") ]) def create_plan(self, query: str, intent: str, slots: dict) -> dict: # 调用LLM进行规划 chain = self.planner_prompt | self.llm # 这里需要引导LLM输出结构化的规划，实践中需用更精确的提示工程和Pydantic解析 raw_plan = chain.invoke({"query": query}) # 解析raw_plan为结构化的任务图... parsed_plan = self._parse_llm_output(raw_plan.content) return parsed_plan def execute_and_abstract(self, parsed_plan: dict, original_query: dict, final_result: str) -> dict: """执行规划，并在成功后进行抽象化""" # 1. 执行规划（这里省略具体的执行引擎代码） execution_success = self._execute_task_graph(parsed_plan) if execution_success: # 2. 抽象为模板 template = self._abstract_plan(parsed_plan, original_query) # 3. 存储模板到数据库 template_id = self.db.save_template(template) # 4. 可选：预热到Redis self.cache_matcher.warm_cache(template_id) return template else: raise Exception("Plan execution failed, abstraction aborted.") def _abstract_plan(self, concrete_plan: dict, original_query: dict) -> dict: """将一次具体的规划实例抽象为可复用的模板""" template = { "intent": original_query['intent'], "slots": [], "task_graph": {"nodes": []} } # 分析concrete_plan中的具体值，将其替换为槽位变量 # 例如，发现concrete_plan中多次出现“iPhone 15”，而original_query的slots中product是“iPhone 15” # 则在template的slots中添加 {"name": "product", "type": "string"} # 并将concrete_plan中所有“iPhone 15”替换为“{product}” # ... 这里是复杂的模式识别和替换逻辑 ... # 简化示例：手动映射 slot_mapping = {} for slot_name, slot_value in original_query['slots'].items(): if slot_value and len(slot_value) > 2: # 避免太短的值 slot_mapping[slot_value] = f"{{{slot_name}}}" template["slots"].append({"name": slot_name, "type": "string"}) # 遍历concrete_plan的节点，进行文本替换 for node in concrete_plan['task_graph']['nodes']: abstract_node = node.copy() for key, value in abstract_node.items(): if isinstance(value, str): for concrete, abstract in slot_mapping.items(): value = value.replace(concrete, abstract) abstract_node[key] = value template['task_graph']['nodes'].append(abstract_node) template['sample_input'] = original_query['slots'] return template

6. 性能评估、监控与常见问题排查

上线不是终点，我们需要用数据来衡量规划缓存的效果，并准备好应对各种问题。

6.1 核心监控指标

建立完善的监控看板，跟踪以下核心指标：

指标类别	具体指标	说明与预期
命中率	规划缓存命中率	`命中次数 / 总查询次数`。初期可能较低，随着缓存积累应稳步提升。健康系统应在核心场景达到60%+。
性能提升	平均响应时间（缓存 vs 未缓存）	对比命中缓存和未命中缓存的请求平均耗时。目标是缓存请求的耗时显著降低（如降低50%）。
P99/P95延迟（缓存 vs 未缓存）	关注长尾延迟的改善情况。
资源节省	LLM Token消耗节省量	估算因跳过规划阶段而节省的Prompt和Completion Token。
工具/API调用次数减少量	缓存规划可能优化了不必要的检索轮次。
缓存质量	缓存模板总数	监控增长情况，避免无限膨胀。
模板使用分布（头部/长尾）	检查是否少数模板承担了大部分流量，长尾模板是否值得保留。
缓存失效/错误率	执行缓存规划时出错的比率。过高表明模板过时或抽象有误。

6.2 常见问题与排查技巧

在实际运行中，你肯定会遇到下面这些问题：

问题1：缓存命中率始终很低。

排查思路：
1. 检查意图识别：分析未命中请求的日志，看意图分类是否准确。很多查询可能被分到了“其他”类别。可能需要优化意图分类模型或增加意图类别。
2. 检查槽位提取：同样的意图，因为槽位值提取的差异（如“iPhone15” vs “iPhone 15”），导致特征签名不同，无法匹配。需要标准化槽位值（如统一去除空格、转为小写）。
3. 检查匹配阈值：如果使用相似度匹配，阈值可能设得太高。可以逐步调低阈值，观察命中率和错误率的平衡点。
4. 缓存预热不足：系统刚上线，缓存池是空的。可以考虑在启动时，用历史高频查询日志进行离线预热。

问题2：命中缓存的请求，返回结果质量下降或出错。

排查思路：
1. 模板过时：这是最常见原因。知识库更新了，但缓存模板里的检索查询语句没变。建立缓存模板与数据源的版本关联，当知识库更新时，使相关模板失效。
2. 抽象错误：规划抽象器错误地将一个本应保持具体的值泛化成了槽位，或者反之。检查出错请求的具体执行轨迹，对比缓存模板，看是哪个节点出了问题。对于复杂模板，初期引入人工审核环节。
3. 上下文污染：缓存的任务图可能包含了上一次执行时的特定中间结果，影响了本次执行。确保模板中每个节点的输入都明确定义为上游输出或初始槽位，避免隐式全局状态。

问题3：缓存模板数量膨胀，管理混乱。

排查思路：
1. 实施淘汰策略：立即启用基于LRU、LFU或综合评分的淘汰策略，控制Redis中热缓存的数量。
2. 定期清理：对于PostgreSQL中的主存储，定期（如每月）归档或删除长期（如90天）未命中且节省延迟低的模板。
3. 模板合并：开发后台工具，识别相似的模板（如仅槽位默认值不同），由管理员手动合并。
4. 设定容量上限：为缓存存储设置硬性上限，达到后必须淘汰旧模板才能加入新模板。

问题4：LLM原生规划阶段耗时依然很长，拖累未命中请求的体验。

优化方向：
1. 规划LLM小型化：任务规划不一定需要最强大的GPT-4，可以尝试用微调过的中小模型（如Qwen-7B, DeepSeek-Coder）专门负责规划，速度更快，成本更低。
2. 规划结果缓存：即使没有完全匹配的模板，对于完全相同的原始查询字符串，可以直接缓存其上次的完整规划结果（注意时效性）。这可以看作规划缓存的一个特例（精确匹配）。
3. 异步规划与预热：对于某些可预测的查询（如每天早上的例行报告），可以在低峰期预先进行原生规划，并将结果模板加入缓存。

6.3 一个实战调试案例：解决“时灵时不灵”的缓存命中

我曾遇到一个坑：一个“周报生成”的查询，有时能命中缓存，有时不能。查看日志发现，查询分析器提取的week_offset槽位，有时是字符串“-1”，有时是数字-1，导致生成的特征签名不同。

解决方案：在_generate_signature函数中，对槽位值进行标准化预处理。对于数字型槽位，统一转为整数；对于字符串，统一进行trim和转小写。

def _normalize_slot_value(self, value): if isinstance(value, str): value = value.strip().lower() # 尝试转为数字 try: if '.' in value: return float(value) else: return int(value) except ValueError: return value return value

在生成签名前，对所有槽位值调用此函数进行标准化，问题迎刃而解。这个案例告诉我们，缓存系统的鲁棒性藏在细节里，必须对输入数据的各种边界情况保持警惕。

Agentic RAG的规划缓存不是一个一蹴而就的开关，而是一个需要持续调优的子系统。它始于对性能瓶颈的洞察，成于精细的架构设计，终于严谨的运维监控。当你看到那些复杂的多步查询响应时间从数十秒稳定降到两三秒，并且LLM的账单也显著下降时，你就会觉得这一切的投入都是值得的。它让你的RAG系统真正开始有了“记忆”和“经验”，向更智能、更高效的方向迈进了一大步。