多轮对话的Prompt链设计上下文继承、意图切换检测与信息压缩策略一、对话越长Prompt越胀第20轮对话时System Prompt已膨胀到3000字多轮AI对话的一个工程挑战是System Prompt的线性膨胀。每轮对话都将上一轮的内容追加到上下文20轮后上下文窗口塞满了历史的细枝末节——用户在第三轮提到今天天气不错这个信息在第二十轮仍在消耗宝贵的token配额。Prompt链设计将传统的一体式Prompt拆分为多个独立的Prompt节点每个节点负责特定职责并独立管理其上下文窗口。链式结构使每个节点的Prompt保持紧凑信息在不同节点间通过结构化的上下文传递对象而非全量历史文本传递。二、Prompt链的三节点架构三个节点各自有着独立的Prompt和职责。上下文管理器负责从全量历史中提取结构化的上下文对象。意图路由器判断用户本轮的整体意图。生成器根据意图和上下文生成最终回复。每个节点在调用LLM时仅携带自己职责所需的最小上下文而非20轮完整历史。三、上下文继承与意图切换的实现# prompt_chain/context_manager.py 上下文管理器 —— Prompt链的第一个节点 设计意图 1. 与全量对话历史解耦不存储完整历史只存储结构化上下文 2. 上下文切换时触发增量更新而非全量重提取 3. 压缩后的上下文传递给下游节点节约Token成本 from dataclasses import dataclass, field from typing import Optional import hashlib dataclass class ConversationContext: 传递给下游Prompt节点的结构化上下文 session_id: str last_user_intent: str # 上一轮用户意图 current_topic: str # 当前话题 topic_duration: int # 当前话题持续的轮数 user_mood: str # 用户情绪 pending_actions: list[str] # 未完成的任务 summary_200: str # 200字以内对话摘要 context_hash: str # 上下文哈希用于检测变化 def has_changed(self, other: ConversationContext) - bool: 判断上下文是否发生了实质性变化避免不必要的下游调用 return self.context_hash ! other.context_hash class ContextManager: 上下文管理节点 def __init__(self, model: str gpt-4o-mini): self.model model self.previous_context: Optional[ConversationContext] None def generate_context( self, user_input: str, full_history: list[dict], # 仅作为输入不存储 ) - ConversationContext: 生成并返回结构化上下文对象 # 从完整历史中提取最近5轮保留原样用于意图判断 recent full_history[-10:] if len(full_history) 10 else full_history # LLM提取结构化信息 context self._extract_structured_context(recent, user_input) # 构建上下文哈希用于下游检测变化 context.context_hash self._compute_hash(context) self.previous_context context return context def _compute_hash(self, ctx: ConversationContext) - str: payload f{ctx.current_topic}|{ctx.user_mood}|{ctx.last_user_intent} return hashlib.md5(payload.encode()).hexdigest()[:8] # prompt_chain/intent_router.py 意图路由器 —— Prompt链的第二个节点 设计意图 1. 仅接收结构化上下文不接触完整对话历史 2. 轻量级分类避免在路由阶段使用大模型 3. 意图切换时触发下游节点的重新初始化 class IntentRouter: INTENT_CLASSIFY_PROMPT 根据当前上下文判断用户意图。 上下文信息 - 当前话题: {current_topic} - 用户情绪: {user_mood} - 上一轮意图: {last_intent} 用户输入: {user_input} 分类为以下之一: chitchat / information_query / task_execution / emotion_support def route(self, user_input: str, context: ConversationContext) - str: 返回意图分类下游根据分类选择不同的生成器 # 快速规则减少不必要的LLM调用 if ? in user_input or 怎么 in user_input or 什么是 in user_input: return information_query if any(kw in user_input for kw in [帮我, 设置, 提醒, 记录]): return task_execution if any(kw in user_input for kw in [难过, 开心, 焦虑, 压力]): return emotion_support return chitchat四、Prompt链的引入开销与适用场景每个额外节点的LLM调用上下文管理器增加了约500ms的延迟和约800 tokens的成本。如果项目只有5-10轮对话增加的延迟不值得。但对话超过20轮时链式结构通过压缩上下文节省的Token每轮约减少2000 tokens的上下文超过了节点自身的调用成本。Prompt链的另一个风险是节点间的错误传播——节点1的意图分类错误会导致节点2生成完全不合适的回应。缓解方案是节点2在检测到回应与当前会话明显不协调时触发回退到全量历史的完整回复。五、总结本次多轮对话Prompt链设计的核心结论结构化上下文对象替代全量历史节点间传递压缩后的信息而非膨胀的对话文本。三节点结构覆盖上下文管理→意图路由→回复生成每个节点独立管理Prompt职责清晰。20轮对话是链式结构的盈亏平衡点少于20轮时简单追加历史成本更低超过20轮时链式Token节约优势显现。上下文管理器是链中最敏感的节点对提取质量直接负责需定期用人工标注评估提取准确率。错误传播需要回退机制下游检测到不协调回应时应支持回退到全量上下文的完整生成路径。