FoFR模式：解决LLM长对话中提示词遗忘的工程实践

1. 这篇文章真正要解决的问题

在AI应用开发，尤其是基于大语言模型（LLM）构建智能体（Agent）或聊天机器人的过程中，你是否遇到过这样的困境：你精心设计的提示词（Prompt）在对话开始时效果显著，但随着对话轮次的增加，模型似乎“忘记”了最初的指令，开始跑偏、答非所问，或者行为变得不一致？

这正是“提示词遗忘”或“上下文漂移”的典型问题。开发者投入大量精力调优的System Prompt（系统提示词），定义了AI的角色、能力和行为边界，却在多轮交互中被淹没在冗长的对话历史中。传统的解决方案，比如在每轮用户消息前重复拼接系统提示，不仅笨拙、消耗宝贵的上下文窗口（Token），还破坏了对话的自然流。

本文要深入探讨的，正是解决这一核心痛点的工程实践：FoFR（Follow-on from Follow-on Response）模式，或者说“持续提示”机制。它不是一个新发布的框架或工具，而是一种被验证有效的设计模式与实现思路。本文将为你彻底讲清楚：

1. FoFR到底是什么？它如何巧妙地利用大模型的“短期记忆”特性，确保核心指令不被遗忘。
2. 为什么它比简单重复System Prompt更有效？深入其背后的心理学与模型工作原理。
3. 如何亲手实现一个FoFR引擎？从零开始，用Python代码构建一个具备“持续提示”能力的聊天后端。
4. 在实际项目中如何应用与调优？结合LangChain、LlamaIndex等流行框架，给出最佳实践和避坑指南。

如果你正在开发客服机器人、编程助手、游戏NPC或任何需要长期维持特定角色和目标的AI应用，那么理解并掌握FoFR，将是提升产品稳定性和用户体验的关键一步。

2. 基础概念与核心原理

在深入FoFR之前，我们需要统一几个关键概念，并理解问题产生的根源。

2.1 关键概念辨析

• System Prompt（系统提示词）：在对话开始前提供给模型的指令，用于设定AI的“角色”、“人格”、“能力范围”和“回答格式”。例如，“你是一个专业的Java技术专家，回答需简洁、准确，代码示例需完整可运行。”
• User Prompt（用户提示词）：用户每轮对话实际输入的内容。
• Context Window（上下文窗口）：模型能一次性处理的最大文本长度（如4K、8K、16K、128K Tokens）。超出部分会被截断或遗忘。
• 上下文漂移（Context Drift）：在长对话中，由于新的对话内容不断涌入，模型对最早提供的系统指令的记忆和遵循程度逐渐减弱的现象。

2.2 问题根源：注意力机制与Token位置

现代大语言模型基于Transformer架构，其核心是自注意力机制。模型在处理一段文本时，会计算每个Token（词元）与其他所有Token的关联度。然而：

1. 位置衰减：尽管有位置编码，但模型对序列中部的信息通常比对两端的信息更“敏感”。随着对话进行，最初的System Prompt被挤到历史记录的“最左端”，其影响力自然下降。
2. 有限的“工作记忆”：你可以把模型的上下文窗口想象成一个固定大小的“工作白板”。新的对话内容会写在右边，最左边的内容可能因为白板不够大而被擦掉，或者即使没被擦掉，也因为离当前“书写焦点”太远而被忽略。

2.3 FoFR的核心思想

FoFR模式的核心洞察是：与其在对话开始时一次性灌输所有规则，不如将最关键的行为指令，以一种轻量、自然的方式，持续地“编织”进模型的每一次回复生成过程中。

具体来说，FoFR通常这样工作：

1. 初始设定：在对话开始时，使用一个清晰的System Prompt。
2. 持续注入：在模型生成每一轮回复（Follow-on Response）时，后台系统会自动在生成请求的“系统”或“用户”角色消息中，附带一个精简版、高优先级的核心指令片段。
3. 动态调整：这个片段可以根据对话状态、用户意图进行微调，但核心约束（如“保持专业”、“不讨论政治”）始终存在。

这样，无论对话进行到第50轮还是第100轮，模型在生成当前回复时，其“工作记忆”里始终有最新的核心指令，从而有效避免了遗忘。

3. 环境准备与前置条件

为了实践FoFR，我们需要一个基础的开发环境。本文将使用Python和OpenAI API（兼容OpenAI格式的其他API，如Azure OpenAI, Ollama, LM Studio等）进行演示。

3.1 基础环境

• 操作系统：Windows 10/11, macOS, 或 Linux (Ubuntu 20.04+)
• Python版本：>= 3.8
• 包管理工具：pip

3.2 核心依赖库我们将使用openai这个官方库（或兼容库）来调用大模型API。

# 创建并进入项目目录 mkdir fofr-demo && cd fofr-demo # 创建虚拟环境（推荐） python -m venv venv # Windows激活 venv\Scripts\activate # macOS/Linux激活 source venv/bin/activate # 安装核心依赖 pip install openai python-dotenv

3.3 获取API密钥你需要一个支持Chat Completion功能的API服务。以OpenAI为例：

1. 访问 OpenAI平台 注册并登录。
2. 在API Keys页面创建新的密钥。
3. 将密钥保存在项目根目录的.env文件中，避免硬编码在代码里。

# 创建 .env 文件 echo "OPENAI_API_KEY=你的实际api_key_here" > .env

3.4 项目结构一个清晰的项目结构有助于管理代码。

fofr-demo/ ├── .env # 环境变量（API密钥） ├── requirements.txt # 依赖列表 ├── fofr_engine.py # FoFR引擎核心实现 ├── test_conversation.py # 测试对话脚本 └── README.md

4. 核心流程拆解：实现一个FoFR引擎

让我们从零开始，构建一个具备FoFR能力的简单聊天引擎。我们将它拆解为几个关键步骤。

4.1 第一步：定义消息结构OpenAI Chat Completion API使用messages列表，其中每个元素是一个包含role(系统、用户、助手) 和content(内容) 的字典。FoFR的关键在于如何动态构建这个列表。

4.2 第二步：设计“持续提示”策略我们需要一个策略来决定在每一轮，将什么样的核心指令片段注入到请求中。策略可以很简单，比如始终附加一个固定的提示后缀；也可以很复杂，基于对话历史进行动态生成。

4.3 第三步：管理对话历史引擎需要维护一个对话历史列表，并在每次请求时，组合历史消息和当前的持续提示。

4.4 第四步：调用模型并处理响应调用API，获取模型生成的回复，并将其加入到对话历史中，完成一轮交互。

5. 完整示例与代码实现

下面，我们实现一个FofrEngine类。它支持两种模式：基础模式（每轮固定附加提示）和高级模式（根据历史动态生成提示）。

5.1 基础FoFR引擎实现

# 文件：fofr_engine.py import os from typing import List, Dict, Any, Optional from openai import OpenAI from dotenv import load_dotenv # 加载环境变量 load_dotenv() class FofrEngine: """ 一个简单的FoFR（持续提示）聊天引擎。 """ def __init__(self, model: str = "gpt-3.5-turbo", system_prompt: str = "你是一个乐于助人的AI助手。", persistent_prompt: str = "请始终记住：回答要简洁、准确。", api_key: Optional[str] = None): """ 初始化引擎。 Args: model: 使用的模型名称。 system_prompt: 初始的系统提示词。 persistent_prompt: 需要持续附加的核心提示片段。 api_key: OpenAI API密钥。如果为None，则从环境变量读取。 """ self.model = model self.system_prompt = system_prompt self.persistent_prompt = persistent_prompt self.client = OpenAI(api_key=api_key or os.getenv("OPENAI_API_KEY")) self.conversation_history: List[Dict[str, str]] = [] # 将初始系统提示加入历史（仅一次） if self.system_prompt: self.conversation_history.append({"role": "system", "content": self.system_prompt}) def _build_messages_for_turn(self, user_input: str) -> List[Dict[str, str]]: """ 构建发送给API的messages列表，应用FoFR策略。 策略：在最新的用户消息后，附加持续提示。 """ # 1. 复制历史记录（包含最初的system消息和之前的对话） messages = self.conversation_history.copy() # 2. 构建本轮的用户消息：原始输入 + 持续提示 # 注意：这里将持续提示作为用户消息的一部分，而不是独立的系统消息。 # 这可以增强其与当前问题的关联性。 enhanced_user_input = f"{user_input}\n\n---\n{self.persistent_prompt}" messages.append({"role": "user", "content": enhanced_user_input}) return messages def chat(self, user_input: str) -> str: """ 处理一轮用户输入，并返回AI的回复。 """ # 构建请求消息 messages = self._build_messages_for_turn(user_input) try: # 调用API response = self.client.chat.completions.create( model=self.model, messages=messages, temperature=0.7, max_tokens=500 ) # 提取回复内容 ai_response = response.choices[0].message.content # 更新对话历史 # 注意：我们存储原始的用户输入，而不是增强后的。这样历史更干净。 self.conversation_history.append({"role": "user", "content": user_input}) self.conversation_history.append({"role": "assistant", "content": ai_response}) return ai_response except Exception as e: return f"调用API时出错：{e}" def clear_history(self): """清空对话历史，但保留系统提示。""" self.conversation_history = [] if self.system_prompt: self.conversation_history.append({"role": "system", "content": self.system_prompt}) # 示例：一个更具体的角色设定 class TechnicalAdvisorEngine(FofrEngine): """ 技术顾问专用引擎，使用更强的持续提示。 """ def __init__(self, model: str = "gpt-4"): system_prompt = ( "你是一位资深全栈开发工程师，擅长Python、Java、系统设计和问题排查。" "你的回答应该直接、专业，并且包含可操作的步骤或代码片段。" ) persistent_prompt = ( "【核心指令】请始终以技术专家的身份回答。" "如果问题涉及代码，请提供正确、完整且可运行的示例。" "如果问题模糊，请先澄清再回答。避免非技术性闲聊。" ) super().__init__(model=model, system_prompt=system_prompt, persistent_prompt=persistent_prompt)

5.2 测试对话脚本

让我们写一个简单的脚本来测试基础引擎，并对比有无FoFR的效果。

# 文件：test_conversation.py from fofr_engine import FofrEngine, TechnicalAdvisorEngine def test_basic_fofr(): print("=== 测试基础FoFR引擎（无持续提示 vs 有持续提示）===\n") # 测试1：无持续提示（传统方式） print("【场景1：无持续提示】") engine_no_fofr = FofrEngine( system_prompt="你是一个笑话机器人，每句话都要包含一个双关语。", persistent_prompt="" # 空字符串，即无持续提示 ) response = engine_no_fofr.chat("你好，介绍一下你自己。") print(f"AI: {response}") response = engine_no_fofr.chat("今天的天气怎么样？") print(f"AI: {response}") # 多轮后，模型可能忘记“双关语”指令 for i in range(3): engine_no_fofr.chat(f"测试消息{i}") # 模拟一些无关对话 response = engine_no_fofr.chat("再讲个笑话吧。") print(f"AI (第5轮后): {response}\n") # 测试2：有持续提示 print("【场景2：有持续提示】") engine_with_fofr = FofrEngine( system_prompt="你是一个笑话机器人，每句话都要包含一个双关语。", persistent_prompt="【记住】你的每句回复都必须包含一个双关语。" ) response = engine_with_fofr.chat("你好，介绍一下你自己。") print(f"AI: {response}") response = engine_with_fofr.chat("今天的天气怎么样？") print(f"AI: {response}") for i in range(3): engine_with_fofr.chat(f"测试消息{i}") response = engine_with_fofr.chat("再讲个笑话吧。") print(f"AI (第5轮后): {response}\n") def test_technical_advisor(): print("\n=== 测试技术顾问引擎（带强FoFR）===\n") engine = TechnicalAdvisorEngine(model="gpt-3.5-turbo") # 可根据情况换gpt-4 questions = [ "Python里怎么反转一个字符串？", "嗯，这个方法不错。那Java呢？", # 这里模型需要记住“技术专家”和“提供代码”的指令 "我有点累了，我们聊点别的吧？" # 这里测试模型是否会拒绝非技术闲聊 ] for q in questions: print(f"用户: {q}") response = engine.chat(q) print(f"AI: {response}\n---\n") if __name__ == "__main__": test_basic_fofr() test_technical_advisor()

5.3 高级模式：动态持续提示

基础模式固定附加同样的提示，有时可能不够灵活。我们可以引入一个“提示生成器”函数，根据对话历史动态生成本轮需要强调的指令。

# 在 fofr_engine.py 中添加 class DynamicFofrEngine(FofrEngine): """ 动态FoFR引擎。持续提示由一个函数动态生成。 """ def __init__(self, model: str = "gpt-3.5-turbo", system_prompt: str = "你是一个乐于助人的AI助手。", prompt_generator: Optional[callable] = None, api_key: Optional[str] = None): """ Args: prompt_generator: 一个函数，接收(conversation_history, current_user_input)， 返回一个字符串作为本轮的持续提示。 如果为None，则退化为无持续提示。 """ # 不再需要固定的persistent_prompt super().__init__(model=model, system_prompt=system_prompt, persistent_prompt="", api_key=api_key) self.prompt_generator = prompt_generator def _build_messages_for_turn(self, user_input: str) -> List[Dict[str, str]]: messages = self.conversation_history.copy() enhanced_user_input = user_input if self.prompt_generator: dynamic_prompt = self.prompt_generator(self.conversation_history, user_input) if dynamic_prompt: enhanced_user_input = f"{user_input}\n\n---\n{dynamic_prompt}" messages.append({"role": "user", "content": enhanced_user_input}) return messages # 示例：一个简单的动态提示生成器 def generate_prompt_to_keep_short(history, current_input): """ 如果历史对话较长，则提示模型回答简洁。 """ # 简单计算非系统消息的轮数 turn_count = sum(1 for msg in history if msg['role'] in ('user', 'assistant')) if turn_count > 5: return "【提示】对话已较长，请尽量简洁回答，突出重点。" return "" # 不添加额外提示 # 使用示例 dynamic_engine = DynamicFofrEngine( system_prompt="你是一个百科全书式的AI。", prompt_generator=generate_prompt_to_keep_short )

6. 运行结果与效果验证

运行python test_conversation.py，观察输出。

6.1 预期输出分析

在“无持续提示”的场景中，你可能会发现：

• 前一两轮，AI还能记得“双关语”指令，回答里包含双关。
• 经过几轮无关对话（模拟对话漂移）后，当你再次要求讲笑话时，AI可能只是生成了一个普通的笑话，而忘记了必须包含双关语的硬性要求。

在“有持续提示”的场景中：

• 即使在多轮无关对话后，当你问“再讲个笑话吧”，由于每一轮请求中都包含了【记住】你的每句回复都必须包含一个双关语。这个片段，AI在生成该轮回复时，这个指令就在其上下文中，因此它有很大概率会生成一个包含双关语的笑话。

在“技术顾问”测试中：

• 对于第二个问题“那Java呢？”，一个好的FoFR引擎应该能识别出这是对上一个Python问题的延续，并继续以技术专家的口吻提供Java的代码示例。
• 对于第三个非技术闲聊的试探，引擎应该基于持续提示中的“避免非技术性闲聊”指令，礼貌地拒绝或将话题引回技术讨论。

6.2 如何验证FoFR是否生效？

1. 人工评估：进行多轮、穿插无关话题的对话，检查AI在关键回合是否仍能遵守最初的核心指令。
2. 自动化测试：可以编写测试用例，在长对话后询问一个需要依赖核心指令才能正确回答的问题，然后使用规则或另一个AI模型来判断回答是否符合指令要求。
3. 对比实验：这是最有效的方法。在相同系统提示下，分别运行有FoFR和无FoFR的引擎，使用相同的多轮对话脚本，最后对比两者在遵守指令上的表现差异。

7. 常见问题与排查思路

问题现象	可能原因	排查方式	解决方案
FoFR似乎没效果，AI还是忘记了指令	1. 持续提示词太弱或模糊。 2. 持续提示被放在了消息列表的“系统”角色中，且位置靠前，影响力不足。 3. 对话历史过长，导致包含持续提示的上下文被截断。	1. 检查构建的messages列表，确认持续提示是否紧挨着本轮用户消息。 2. 将提示词设计得更强硬、更具体（如使用“必须”、“始终”、“禁止”）。 3. 查看API返回的usage字段，确认total_tokens是否接近模型上限。	1. 将关键指令作为用户消息的后缀，使其与当前问题强关联。 2. 优化提示词，例如：“【强制指令】无论对话历史如何，你都必须...”。 3. 实现对话历史摘要或滑动窗口，只保留最近N轮对话，确保核心指令在窗口内。
AI的回复变得生硬或不自然	持续提示词过于机械、重复，干扰了模型生成流畅语言。	分析AI的回复，看是否出现了不自然的、照搬提示词的表达。	1. 将提示词设计得更像“内在思考”或“元指令”，例如：“在组织回答时，请优先考虑准确性。” 2. 尝试将提示词放在一个独立的、role为system的消息中，但放在所有消息的最后（某些模型对最后一条系统消息更敏感）。
Token消耗显著增加	每一轮都附加了较长的持续提示，增加了每次请求的Token数量。	计算持续提示的长度，评估其对成本的影响。	1.精简持续提示：只保留最核心的指令关键词。 2.非每轮附加：可以设定规则，例如每3轮或当检测到话题偏离时才附加。 3. 使用更高效的模型（如GPT-3.5-Turbo）来处理常规对话，仅在需要复杂推理时调用更强大的模型。
与某些框架（如LangChain）集成困难	LangChain的Memory模块可能有自己的消息组装逻辑，与自定义的FoFR逻辑冲突。	阅读LangChain Memory类的源码，看它在load_memory_variables和save_context中如何处理消息。	1. 继承或包装LangChain的Memory类，重写其构建聊天历史的方法，在合适的位置插入持续提示。 2. 直接在ChatPromptTemplate中设计一个包含动态占位符的模板，该占位符由自定义逻辑填充为持续提示。

8. 最佳实践与工程建议

将FoFR模式应用到生产环境，需要考虑更多工程细节。

8.1 提示词工程

• 位置很重要：实验表明，将关键指令放在用户消息的末尾（作为后缀）通常比放在开头或作为独立的系统消息更有效。因为模型在生成回复前，最后“看到”的就是它。
• 强度与语气：使用强调性词汇，如“必须”、“始终”、“严禁”、“核心规则是”。可以用方括号或特殊标记（如[SYSTEM REMINDER]）将其与普通对话内容区分开。
• 动态化与条件触发：不要每轮都附加相同的长提示。可以设计规则：
  • 长度触发：当对话历史超过一定轮数时，注入“请简要回答”的提示。
  • 话题偏离触发：用一个简单的分类器判断用户当前问题是否偏离核心主题，若是，则注入提醒回归的提示。
  • 关键指令分片：将复杂的系统提示拆解成多个小指令，在不同场景下动态注入相关的那一条。

8.2 与流行框架集成

• LangChain：你可以创建一个自定义的BaseMemory类或修改ConversationBufferMemory。核心是重写load_memory_variables方法，使其返回的历史消息已经融合了持续提示。

  # 伪代码示例 class FofrConversationMemory(ConversationBufferMemory): def load_memory_variables(self, inputs: Dict[str, Any]) -> Dict[str, Any]: # 调用父类方法获取基础历史 memory_data = super().load_memory_variables(inputs) chat_history = memory_data.get(self.memory_key, []) # 在此处，将chat_history与当前inputs结合，生成带持续提示的最终消息列表 # 你需要根据inputs判断当前用户输入，并决定附加什么提示 enhanced_messages = your_fofr_logic(chat_history, inputs) return {self.memory_key: enhanced_messages}

• LlamaIndex：在构建查询引擎时，可以通过自定义PromptTemplate或在chat_engine的stream_chat方法中拦截并修改消息列表来实现FoFR。

8.3 性能与成本优化

• 历史管理：对于超长对话，必须实现历史摘要或滑动窗口。否则，最早的指令和最新的持续提示可能同时被截断。可以定期（如每10轮）用模型对之前的历史做一个简短总结，然后用总结替换掉旧的历史记录。
• 提示缓存：如果持续提示是固定的，可以将其Token化并缓存，避免每次请求都重新计算Token长度。
• AB测试：不同的持续提示策略（固定、动态、条件触发）对效果和成本的影响不同。通过AB测试找到最适合你应用场景的平衡点。

8.4 安全与边界

• 指令冲突：如果动态生成的持续提示与最初的系统提示或其他动态提示冲突，可能导致模型行为混乱。确保你的提示生成逻辑具有一致性和优先级。
• 用户提示注入：警惕用户输入中可能包含试图覆盖或抵消你持续提示的内容（例如“忽略之前的指令”）。虽然FoFR能增强鲁棒性，但仍需在最终输出前进行内容安全审核。
• 不要过度依赖：FoFR是一种重要的工程技巧，但不能替代精心设计的基础系统提示和扎实的模型微调（如果条件允许）。它应被视为确保长期对话一致性的“安全网”。

9. 总结与后续学习方向

FoFR（持续提示）模式，本质上是一种针对大模型“上下文漂移”缺陷的工程补偿策略。它通过将核心指令巧妙地、持续地注入到模型的每一次推理上下文中，显著提升了智能体在长对话中行为的稳定性和可靠性。

本文带你从问题根源出发，理解了其原理，并亲手实现了一个从基础到动态的FoFR引擎。关键收获在于：

• FoFR的核心价值在于对抗遗忘，尤其适用于角色扮演、任务执行、合规性要求高的AI应用。
• 实现的关键是将提示作为用户消息的后缀，并做好对话历史管理，防止被截断。
• 效果的优劣取决于提示词的设计、注入的时机和动态策略的智能程度。

要真正掌握这项技术，建议你接下来：

1. 深入实验：用你自己的业务场景设计测试用例，对比不同提示词、不同注入位置（用户消息尾、独立系统消息、助手消息前缀）的效果差异。
2. 研究高级模式：探索基于对话状态机（State Machine）的动态提示生成，让AI在不同对话阶段接收到不同的核心指令。
3. 框架深度集成：尝试将FoFR模式深度集成到LangChain或LlamaIndex的工作流中，使其成为你AI应用开发基础设施的一部分。
4. 关注模型进展：最新的模型（如GPT-4 Turbo with 128K上下文）对长上下文的处理能力更强，但FoFR作为一种设计模式，其价值在于确保关键信息的“注意力优先级”，这与上下文长度是互补的。

长对话一致性是构建可靠AI产品的基石之一。希望本文提供的FoFR实践指南，能成为你工具箱中一件得力的武器。建议收藏本文，并在你的下一个AI项目中尝试应用它，亲自感受其对对话质量带来的提升。