1. 这篇文章真正要解决的问题在AI应用开发尤其是基于大语言模型LLM构建智能体Agent或聊天机器人的过程中你是否遇到过这样的困境你精心设计的提示词Prompt在对话开始时效果显著但随着对话轮次的增加模型似乎“忘记”了最初的指令开始跑偏、答非所问或者行为变得不一致这正是“提示词遗忘”或“上下文漂移”的典型问题。开发者投入大量精力调优的System Prompt系统提示词定义了AI的角色、能力和行为边界却在多轮交互中被淹没在冗长的对话历史中。传统的解决方案比如在每轮用户消息前重复拼接系统提示不仅笨拙、消耗宝贵的上下文窗口Token还破坏了对话的自然流。本文要深入探讨的正是解决这一核心痛点的工程实践FoFRFollow-on from Follow-on Response模式或者说“持续提示”机制。它不是一个新发布的框架或工具而是一种被验证有效的设计模式与实现思路。本文将为你彻底讲清楚FoFR到底是什么它如何巧妙地利用大模型的“短期记忆”特性确保核心指令不被遗忘。为什么它比简单重复System Prompt更有效深入其背后的心理学与模型工作原理。如何亲手实现一个FoFR引擎从零开始用Python代码构建一个具备“持续提示”能力的聊天后端。在实际项目中如何应用与调优结合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的关联度。然而位置衰减尽管有位置编码但模型对序列中部的信息通常比对两端的信息更“敏感”。随着对话进行最初的System Prompt被挤到历史记录的“最左端”其影响力自然下降。有限的“工作记忆”你可以把模型的上下文窗口想象成一个固定大小的“工作白板”。新的对话内容会写在右边最左边的内容可能因为白板不够大而被擦掉或者即使没被擦掉也因为离当前“书写焦点”太远而被忽略。2.3 FoFR的核心思想FoFR模式的核心洞察是与其在对话开始时一次性灌输所有规则不如将最关键的行为指令以一种轻量、自然的方式持续地“编织”进模型的每一次回复生成过程中。具体来说FoFR通常这样工作初始设定在对话开始时使用一个清晰的System Prompt。持续注入在模型生成每一轮回复Follow-on Response时后台系统会自动在生成请求的“系统”或“用户”角色消息中附带一个精简版、高优先级的核心指令片段。动态调整这个片段可以根据对话状态、用户意图进行微调但核心约束如“保持专业”、“不讨论政治”始终存在。这样无论对话进行到第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包管理工具pip3.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-dotenv3.3 获取API密钥你需要一个支持Chat Completion功能的API服务。以OpenAI为例访问 OpenAI平台 注册并登录。在API Keys页面创建新的密钥。将密钥保存在项目根目录的.env文件中避免硬编码在代码里。# 创建 .env 文件 echo OPENAI_API_KEY你的实际api_key_here .env3.4 项目结构一个清晰的项目结构有助于管理代码。fofr-demo/ ├── .env # 环境变量API密钥 ├── requirements.txt # 依赖列表 ├── fofr_engine.py # FoFR引擎核心实现 ├── test_conversation.py # 测试对话脚本 └── README.md4. 核心流程拆解实现一个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_keyapi_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( modelself.model, messagesmessages, temperature0.7, max_tokens500 ) # 提取回复内容 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__(modelmodel, system_promptsystem_prompt, persistent_promptpersistent_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(fAI: {response}) response engine_no_fofr.chat(今天的天气怎么样) print(fAI: {response}) # 多轮后模型可能忘记“双关语”指令 for i in range(3): engine_no_fofr.chat(f测试消息{i}) # 模拟一些无关对话 response engine_no_fofr.chat(再讲个笑话吧。) print(fAI (第5轮后): {response}\n) # 测试2有持续提示 print(【场景2有持续提示】) engine_with_fofr FofrEngine( system_prompt你是一个笑话机器人每句话都要包含一个双关语。, persistent_prompt【记住】你的每句回复都必须包含一个双关语。 ) response engine_with_fofr.chat(你好介绍一下你自己。) print(fAI: {response}) response engine_with_fofr.chat(今天的天气怎么样) print(fAI: {response}) for i in range(3): engine_with_fofr.chat(f测试消息{i}) response engine_with_fofr.chat(再讲个笑话吧。) print(fAI (第5轮后): {response}\n) def test_technical_advisor(): print(\n 测试技术顾问引擎带强FoFR\n) engine TechnicalAdvisorEngine(modelgpt-3.5-turbo) # 可根据情况换gpt-4 questions [ Python里怎么反转一个字符串, 嗯这个方法不错。那Java呢, # 这里模型需要记住“技术专家”和“提供代码”的指令 我有点累了我们聊点别的吧 # 这里测试模型是否会拒绝非技术闲聊 ] for q in questions: print(f用户: {q}) response engine.chat(q) print(fAI: {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__(modelmodel, system_promptsystem_prompt, persistent_prompt, api_keyapi_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_generatorgenerate_prompt_to_keep_short )6. 运行结果与效果验证运行python test_conversation.py观察输出。6.1 预期输出分析在“无持续提示”的场景中你可能会发现前一两轮AI还能记得“双关语”指令回答里包含双关。经过几轮无关对话模拟对话漂移后当你再次要求讲笑话时AI可能只是生成了一个普通的笑话而忘记了必须包含双关语的硬性要求。在“有持续提示”的场景中即使在多轮无关对话后当你问“再讲个笑话吧”由于每一轮请求中都包含了【记住】你的每句回复都必须包含一个双关语。这个片段AI在生成该轮回复时这个指令就在其上下文中因此它有很大概率会生成一个包含双关语的笑话。在“技术顾问”测试中对于第二个问题“那Java呢”一个好的FoFR引擎应该能识别出这是对上一个Python问题的延续并继续以技术专家的口吻提供Java的代码示例。对于第三个非技术闲聊的试探引擎应该基于持续提示中的“避免非技术性闲聊”指令礼貌地拒绝或将话题引回技术讨论。6.2 如何验证FoFR是否生效人工评估进行多轮、穿插无关话题的对话检查AI在关键回合是否仍能遵守最初的核心指令。自动化测试可以编写测试用例在长对话后询问一个需要依赖核心指令才能正确回答的问题然后使用规则或另一个AI模型来判断回答是否符合指令要求。对比实验这是最有效的方法。在相同系统提示下分别运行有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应用。实现的关键是将提示作为用户消息的后缀并做好对话历史管理防止被截断。效果的优劣取决于提示词的设计、注入的时机和动态策略的智能程度。要真正掌握这项技术建议你接下来深入实验用你自己的业务场景设计测试用例对比不同提示词、不同注入位置用户消息尾、独立系统消息、助手消息前缀的效果差异。研究高级模式探索基于对话状态机State Machine的动态提示生成让AI在不同对话阶段接收到不同的核心指令。框架深度集成尝试将FoFR模式深度集成到LangChain或LlamaIndex的工作流中使其成为你AI应用开发基础设施的一部分。关注模型进展最新的模型如GPT-4 Turbo with 128K上下文对长上下文的处理能力更强但FoFR作为一种设计模式其价值在于确保关键信息的“注意力优先级”这与上下文长度是互补的。长对话一致性是构建可靠AI产品的基石之一。希望本文提供的FoFR实践指南能成为你工具箱中一件得力的武器。建议收藏本文并在你的下一个AI项目中尝试应用它亲自感受其对对话质量带来的提升。 FoFR模式：解决LLM长对话中提示词遗忘的工程实践
1. 这篇文章真正要解决的问题在AI应用开发尤其是基于大语言模型LLM构建智能体Agent或聊天机器人的过程中你是否遇到过这样的困境你精心设计的提示词Prompt在对话开始时效果显著但随着对话轮次的增加模型似乎“忘记”了最初的指令开始跑偏、答非所问或者行为变得不一致这正是“提示词遗忘”或“上下文漂移”的典型问题。开发者投入大量精力调优的System Prompt系统提示词定义了AI的角色、能力和行为边界却在多轮交互中被淹没在冗长的对话历史中。传统的解决方案比如在每轮用户消息前重复拼接系统提示不仅笨拙、消耗宝贵的上下文窗口Token还破坏了对话的自然流。本文要深入探讨的正是解决这一核心痛点的工程实践FoFRFollow-on from Follow-on Response模式或者说“持续提示”机制。它不是一个新发布的框架或工具而是一种被验证有效的设计模式与实现思路。本文将为你彻底讲清楚FoFR到底是什么它如何巧妙地利用大模型的“短期记忆”特性确保核心指令不被遗忘。为什么它比简单重复System Prompt更有效深入其背后的心理学与模型工作原理。如何亲手实现一个FoFR引擎从零开始用Python代码构建一个具备“持续提示”能力的聊天后端。在实际项目中如何应用与调优结合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的关联度。然而位置衰减尽管有位置编码但模型对序列中部的信息通常比对两端的信息更“敏感”。随着对话进行最初的System Prompt被挤到历史记录的“最左端”其影响力自然下降。有限的“工作记忆”你可以把模型的上下文窗口想象成一个固定大小的“工作白板”。新的对话内容会写在右边最左边的内容可能因为白板不够大而被擦掉或者即使没被擦掉也因为离当前“书写焦点”太远而被忽略。2.3 FoFR的核心思想FoFR模式的核心洞察是与其在对话开始时一次性灌输所有规则不如将最关键的行为指令以一种轻量、自然的方式持续地“编织”进模型的每一次回复生成过程中。具体来说FoFR通常这样工作初始设定在对话开始时使用一个清晰的System Prompt。持续注入在模型生成每一轮回复Follow-on Response时后台系统会自动在生成请求的“系统”或“用户”角色消息中附带一个精简版、高优先级的核心指令片段。动态调整这个片段可以根据对话状态、用户意图进行微调但核心约束如“保持专业”、“不讨论政治”始终存在。这样无论对话进行到第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包管理工具pip3.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-dotenv3.3 获取API密钥你需要一个支持Chat Completion功能的API服务。以OpenAI为例访问 OpenAI平台 注册并登录。在API Keys页面创建新的密钥。将密钥保存在项目根目录的.env文件中避免硬编码在代码里。# 创建 .env 文件 echo OPENAI_API_KEY你的实际api_key_here .env3.4 项目结构一个清晰的项目结构有助于管理代码。fofr-demo/ ├── .env # 环境变量API密钥 ├── requirements.txt # 依赖列表 ├── fofr_engine.py # FoFR引擎核心实现 ├── test_conversation.py # 测试对话脚本 └── README.md4. 核心流程拆解实现一个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_keyapi_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( modelself.model, messagesmessages, temperature0.7, max_tokens500 ) # 提取回复内容 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__(modelmodel, system_promptsystem_prompt, persistent_promptpersistent_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(fAI: {response}) response engine_no_fofr.chat(今天的天气怎么样) print(fAI: {response}) # 多轮后模型可能忘记“双关语”指令 for i in range(3): engine_no_fofr.chat(f测试消息{i}) # 模拟一些无关对话 response engine_no_fofr.chat(再讲个笑话吧。) print(fAI (第5轮后): {response}\n) # 测试2有持续提示 print(【场景2有持续提示】) engine_with_fofr FofrEngine( system_prompt你是一个笑话机器人每句话都要包含一个双关语。, persistent_prompt【记住】你的每句回复都必须包含一个双关语。 ) response engine_with_fofr.chat(你好介绍一下你自己。) print(fAI: {response}) response engine_with_fofr.chat(今天的天气怎么样) print(fAI: {response}) for i in range(3): engine_with_fofr.chat(f测试消息{i}) response engine_with_fofr.chat(再讲个笑话吧。) print(fAI (第5轮后): {response}\n) def test_technical_advisor(): print(\n 测试技术顾问引擎带强FoFR\n) engine TechnicalAdvisorEngine(modelgpt-3.5-turbo) # 可根据情况换gpt-4 questions [ Python里怎么反转一个字符串, 嗯这个方法不错。那Java呢, # 这里模型需要记住“技术专家”和“提供代码”的指令 我有点累了我们聊点别的吧 # 这里测试模型是否会拒绝非技术闲聊 ] for q in questions: print(f用户: {q}) response engine.chat(q) print(fAI: {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__(modelmodel, system_promptsystem_prompt, persistent_prompt, api_keyapi_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_generatorgenerate_prompt_to_keep_short )6. 运行结果与效果验证运行python test_conversation.py观察输出。6.1 预期输出分析在“无持续提示”的场景中你可能会发现前一两轮AI还能记得“双关语”指令回答里包含双关。经过几轮无关对话模拟对话漂移后当你再次要求讲笑话时AI可能只是生成了一个普通的笑话而忘记了必须包含双关语的硬性要求。在“有持续提示”的场景中即使在多轮无关对话后当你问“再讲个笑话吧”由于每一轮请求中都包含了【记住】你的每句回复都必须包含一个双关语。这个片段AI在生成该轮回复时这个指令就在其上下文中因此它有很大概率会生成一个包含双关语的笑话。在“技术顾问”测试中对于第二个问题“那Java呢”一个好的FoFR引擎应该能识别出这是对上一个Python问题的延续并继续以技术专家的口吻提供Java的代码示例。对于第三个非技术闲聊的试探引擎应该基于持续提示中的“避免非技术性闲聊”指令礼貌地拒绝或将话题引回技术讨论。6.2 如何验证FoFR是否生效人工评估进行多轮、穿插无关话题的对话检查AI在关键回合是否仍能遵守最初的核心指令。自动化测试可以编写测试用例在长对话后询问一个需要依赖核心指令才能正确回答的问题然后使用规则或另一个AI模型来判断回答是否符合指令要求。对比实验这是最有效的方法。在相同系统提示下分别运行有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应用。实现的关键是将提示作为用户消息的后缀并做好对话历史管理防止被截断。效果的优劣取决于提示词的设计、注入的时机和动态策略的智能程度。要真正掌握这项技术建议你接下来深入实验用你自己的业务场景设计测试用例对比不同提示词、不同注入位置用户消息尾、独立系统消息、助手消息前缀的效果差异。研究高级模式探索基于对话状态机State Machine的动态提示生成让AI在不同对话阶段接收到不同的核心指令。框架深度集成尝试将FoFR模式深度集成到LangChain或LlamaIndex的工作流中使其成为你AI应用开发基础设施的一部分。关注模型进展最新的模型如GPT-4 Turbo with 128K上下文对长上下文的处理能力更强但FoFR作为一种设计模式其价值在于确保关键信息的“注意力优先级”这与上下文长度是互补的。长对话一致性是构建可靠AI产品的基石之一。希望本文提供的FoFR实践指南能成为你工具箱中一件得力的武器。建议收藏本文并在你的下一个AI项目中尝试应用它亲自感受其对对话质量带来的提升。