AI Agent上下文感知与智能压缩：突破长文本处理瓶颈的工程实践

1. 从“左耳进右耳出”到“过目不忘”为什么你的Agent需要上下文感知最近在折腾各种AI Agent框架时我发现一个普遍存在的“通病”很多Agent看起来能说会道但稍微聊长一点或者给它一个包含多步骤、多条件的复杂任务它就“失忆”了。你前面刚说完“帮我查一下北京明天的天气”紧接着问“那上海呢”它可能一脸茫然地反问你“上海什么”。或者当你把一份冗长的技术文档丢给它让它总结核心要点时它往往只记住了最后几段前面的关键信息被无情地“遗忘”了。这背后的核心问题就是上下文Context的处理能力。对于大语言模型驱动的Agent来说上下文就是它的“工作记忆区”。然而这个记忆区有两个致命限制长度限制和理解限制。长度限制众所周知比如模型可能有4K、8K、16K甚至更长的上下文窗口但成本、速度都会随之飙升。而理解限制更隐蔽即使窗口足够长模型也未必能有效识别和利用散落在长篇对话或文档中的关键信息它可能只是“看”到了却没有“理解”和“记住”。这就引出了我们今天的主题上下文动态感知与智能压缩。这不仅仅是把长文本变短那么简单它的目标是让Agent具备一种“智能摘要”和“焦点记忆”的能力——能自动识别当前对话或任务中最相关的历史信息并对其进行精炼、重组以最经济的方式保留核心语义从而让Agent真正“听得进”每一句话并在需要时精准“回想”起来。我将其称为“Gliding Horse”滑翔之马的核心理念既要有骏马的驰骋能力处理长上下文又要像滑翔一样轻盈高效低成本、高精度地聚焦关键信息。2. 拆解“Gliding Horse”动态感知与智能压缩的双引擎“Gliding Horse”不是一个单一的技术而是一套组合策略。我们可以把它拆解为两个核心引擎动态感知引擎和智能压缩引擎。两者协同工作共同解决上下文管理的难题。2.1 动态感知引擎Agent的“注意力机制”动态感知解决的是“理解限制”。它的任务是实时分析当前的对话流或任务流判断哪些历史信息与当前时刻最相关。2.1.1 基于向量相似度的语义检索这是最基础也是最常用的一层感知。其原理是将对话中的每一轮发言或文档中的每一个片段转换为一个高维向量嵌入存储到向量数据库中。当Agent需要回应或执行下一步时它会将当前最新的查询或状态也转换为向量然后去向量库中检索与之最相似的K条历史记录。注意这里的“相似”是语义上的而非字面匹配。例如历史中提到“购买一台高性能笔记本电脑”当前查询是“推荐一款适合编程的电脑”即使没有重复词汇基于嵌入的检索也能将它们关联起来。然而单纯依赖向量检索存在局限时间衰减忽略它可能检索到语义相关但年代久远、已不适用于当前对话阶段的记录。逻辑关系缺失它无法理解信息之间的因果、顺序、依赖关系。比如“因为A所以B”中的A和B被单独检索出来时其逻辑链就断了。2.1.2 基于对话状态跟踪的关联性判断为了弥补上述不足我们需要引入更复杂的对话状态跟踪。这包括实体链接与共指消解识别并跟踪对话中提到的实体如“北京”、“那份报告”、“李经理”并理解“它”、“那个”、“他”等代词具体指代什么。当用户说“把它发给我”Agent需要知道“它”是上一轮刚提到的“会议纪要”。意图与槽位继承在任务型对话中用户的意图如“订机票”和相关的槽位信息如“目的地上海”、“时间明天”需要在多轮对话中保持和累积。动态感知引擎需要维护一个动态的“对话状态”明确哪些槽位已填充哪些还缺失并据此判断历史中哪些信息是完成当前任务所必需的。话题分割与焦点识别通过分析对话的连贯性和主题词变化自动将长对话分割成不同的话题段落。当对话切换到新话题时可以适当降低旧话题历史记录的权重甚至将其移出活跃上下文聚焦于当前话题相关的历史。动态感知引擎的输出是一个经过筛选和排序的“相关历史片段列表”这个列表是基于语义、时间和逻辑多维评估后的结果。2.2 智能压缩引擎从“完整录像”到“精彩集锦”动态感知帮我们找到了“相关片段”但相关片段的总长度可能仍然超过模型的上下文窗口或者即使不超过全部塞进去也会造成不必要的计算开销和可能的注意力分散。这时就需要智能压缩引擎上场了。智能压缩的目标不是无损压缩而是语义有损下的高效保留。它要把找到的相关历史片段压缩成一段高度凝练、保留核心信息的摘要。2.2.1 传统摘要方法的局限抽取式摘要直接从原文中抽取重要的句子或段落。优点是保真度高不会产生事实性错误。缺点是不够灵活当关键信息分散在不同句子中时拼凑起来可能不连贯且无法进行概括。生成式摘要利用模型通常是小一点的模型或大模型本身重新组织语言生成概括性文字。优点是连贯、精炼。缺点是存在“幻觉”风险可能遗漏或歪曲细节。2.2.2 “Gliding Horse”的混合压缩策略在实践中我倾向于采用一种分层混合策略第一层关键信息提取。针对每个相关历史片段先进行一轮信息提取。这不仅仅是找关键词而是提取结构化或半结构化的信息元组。例如从一段关于天气的对话中提取(实体: 北京, 属性: 天气, 值: 晴, 温度: 22-28°C, 时间: 明天)。从一段项目讨论中提取(决策: 采用方案A, 负责人: 张三, 截止时间: 周五)。这些元组占用空间极小但信息密度极高。第二层生成式摘要。将提取出的关键信息元组连同片段的原始文本或经过裁剪的文本一起送入一个摘要模型可以是主模型本身也可以是一个专门的摘要模型生成一段通顺、连贯的文本摘要。指令可以设计为“请根据以下关键事实生成一段简洁的对话历史摘要用于辅助后续对话理解。” 这样生成过程有了事实锚点降低了幻觉风险。第三层动态长度控制。根据当前剩余上下文窗口的大小、以及当前任务的重要性动态调整摘要的详细程度。如果窗口充裕摘要可以稍详细如果窗口紧张则必须极度精炼甚至只保留最关键的信息元组。通过这种“提取-生成-调控”的流程我们能在可控的风险下将一大段相关历史压缩成一小段“精华”从而为最新的查询和思考腾出宝贵的上下文空间。3. 实战架构构建你自己的上下文感知Agent理论说再多不如动手搭一个。下面我将分享一个基于现有开源工具栈如LangChain、LlamaIndex实现“Gliding Horse”核心思想的简化架构。这里我们假设使用 OpenAI 的 GPT-4 作为核心LLM。3.1 系统组件设计整个系统可以分为以下几个模块对话历史存储器存储完整的原始对话记录通常用简单的数据库如SQLite或内存结构即可。向量索引器负责将每一轮对话的文本转换为向量并存入向量数据库如Chroma、Pinecone、Weaviate。这里需要注意存储的单元可以是单轮对话也可以是基于语义的片段需要先做文本分割。动态感知模块检索器结合当前查询从向量库进行相似性检索。对话状态跟踪器一个轻量级模块维护当前对话的实体表、意图-槽位状态。可以用规则或小模型实现。相关性融合器将向量检索的结果和对话状态跟踪的结果进行融合、去重、按时间或逻辑重要性重新排序输出最终的相关片段列表。智能压缩模块信息提取器可以基于预定义的Schema或利用LLM的Function Calling能力从相关片段中提取关键信息。例如定义一个“天气查询”信息Schema让LLM自动填充。摘要生成器调用LLM的摘要能力。为了节省成本可以考虑使用更便宜的模型如gpt-3.5-turbo专门负责摘要任务。上下文组装器负责将压缩后的历史摘要、最新的用户查询、以及系统指令Role Prompt组装成最终发送给核心LLM的提示词Prompt。3.2 核心代码流程示意以下是一个高度简化的伪代码流程展示了从接收到用户消息到生成回应的核心步骤class GlidingHorseAgent: def __init__(self, llm, vector_store, state_tracker): self.llm llm self.vector_store vector_store self.state_tracker state_tracker self.full_history [] # 存储完整对话 def process_message(self, user_input: str): # 1. 更新完整历史 self.full_history.append({role: user, content: user_input}) # 2. 动态感知获取相关历史片段 # 2.1 语义检索 semantic_snippets self.vector_store.similarity_search(user_input, k5) # 2.2 状态跟踪例如更新提到的实体 self.state_tracker.update(user_input) state_relevant_snippets self.state_tracker.get_relevant_history() # 2.3 融合与去重 relevant_snippets self._merge_and_rank(semantic_snippets, state_relevant_snippets) # 3. 智能压缩将相关片段压缩成摘要 if self._is_context_too_long(relevant_snippets): # 提取关键信息 key_info self._extract_key_information(relevant_snippets) # 生成摘要 compressed_history self._generate_summary(key_info, relevant_snippets) else: compressed_history \n.join([snippet.content for snippet in relevant_snippets]) # 4. 组装最终Prompt system_prompt 你是一个具有强大记忆力的助手。以下是当前对话的压缩历史摘要供你参考 final_prompt f{system_prompt}\n\n【历史摘要】\n{compressed_history}\n\n【当前用户输入】\n{user_input} # 5. 调用LLM获取回应 llm_response self.llm.invoke(final_prompt) # 6. 更新历史存储和向量库 self.full_history.append({role: assistant, content: llm_response}) self.vector_store.add_texts([user_input, llm_response]) # 简化处理实际需分轮次 return llm_response def _is_context_too_long(self, snippets): # 简单估算token长度 total_len sum(len(snippet.content) for snippet in snippets) return total_len 3000 # 假设阈值 def _extract_key_information(self, snippets): # 调用LLM进行信息提取这里使用结构化输出 extraction_prompt f请从以下文本片段中提取关键的事实性信息以JSON格式输出。 重点关注人物、地点、时间、事件、决策、数字、目标等。 片段{snippets} # 调用支持JSON模式的LLM key_info_json self.llm.invoke(extraction_prompt, response_format{ type: json_object }) return json.loads(key_info_json) def _generate_summary(self, key_info, snippets): summary_prompt f基于以下关键信息点和原始文本片段生成一段非常简洁、连贯的对话历史摘要用于让AI助手理解对话背景。 关键信息点{json.dumps(key_info, ensure_asciiFalse)} 原始片段{snippets[:3]}...已截断 请生成摘要 return self.llm.invoke(summary_prompt) # 可以用更便宜的模型3.3 参数调优与经验之谈在实际搭建和调试这类系统时有几个参数和设计点需要仔细考量检索数量K每次检索多少条相关历史太少可能遗漏关键信息太多则增加压缩负担和噪声。通常从3-5开始测试根据任务复杂度调整。压缩触发阈值上下文长度达到多少时启动压缩这个阈值需要略低于模型上下文窗口上限为当前查询和系统指令留出空间。例如对于4K窗口阈值可以设在3500 tokens左右。摘要的“保真度”与“简洁度”权衡在给摘要生成模型的指令中明确强调“基于提供的关键信息”和“避免编造”可以大幅减少幻觉。同时通过指令控制长度如“用不超过5句话概括”。向量嵌入模型的选择不同的嵌入模型如OpenAI的text-embedding-3-small开源社区的BGE-M3在语义捕捉能力上差异很大。对于中文场景优先选择在中文语料上训练良好的模型。对话状态跟踪的粒度是跟踪每一个实体还是只跟踪核心任务相关的槽位过于精细的跟踪会增加系统复杂性也可能引入错误。建议从最核心的1-2个状态开始逐步迭代。4. 避坑指南让“滑翔之马”平稳落地在实现上下文动态感知与压缩的过程中我踩过不少坑这里分享几个最常见的陷阱及其规避方法。4.1 信息丢失与扭曲压缩的“阿喀琉斯之踵”这是智能压缩最大的风险。一次糟糕的摘要可能导致后续对话完全偏离轨道。坑点摘要模型过度概括丢失了关键的限制条件或否定信息。例如用户说“除了周三其他时间都可以”摘要可能变成“用户时间可用”导致后续安排出错。避坑方法强化关键信息提取在压缩前先用规则或小模型明确提取出带有否定词不、除了、禁止、精确数字、时间日期、枚举列表等信息并在生成摘要时强制要求包含这些提取出的信息点。保留原始片段引用在摘要中对于极其重要的信息可以保留其原始表述用引号标注。例如摘要写成“用户明确了时间要求‘除了周三其他时间都可以’。”设置“不压缩”白名单定义一些绝对不能压缩的信息类型如用户提供的账号、密码、订单号等关键数据。这些信息必须原封不动地保留或采用抽取式的方式直接嵌入摘要。4.2 上下文连贯性断裂拼贴的历史即使每段历史都被很好地压缩了但简单地将它们拼接起来可能依然无法形成一个逻辑连贯的背景故事。坑点摘要A是关于项目立项摘要B是关于技术选型但A和B之间的因果关系、时间顺序在拼接后丢失了。Agent看到的是两个孤立的事件。避坑方法生成全局性摘要不要仅仅对每个片段独立摘要然后拼接。可以定期例如每10轮对话或当话题明显转变时利用所有相关片段生成一个全局的、连贯的“故事线”摘要。这需要更多的计算但效果更好。在摘要中增加时间戳和逻辑连接词强制摘要模型在生成时使用“首先”、“然后”、“然而”、“因此”等连接词并标明大致的时间顺序如“在之前的讨论中”、“用户最新提出”。维护一个超简化的时间线在系统内部维护一个仅包含核心事件和决策点的时间线列表如[T1: 决定用Python, T2: 选择FastAPI框架, T3: 数据库定为PostgreSQL]在组装上下文时将这个时间线放在摘要之前帮助模型快速建立脉络。4.3 性能与成本的平衡动态感知和智能压缩本身也需要消耗计算资源尤其是频繁调用LLM进行摘要生成。坑点每轮对话都进行全文检索和深度压缩导致响应延迟极高API调用成本失控。避坑方法分层缓存对检索结果和摘要结果进行缓存。如果用户查询与缓存键高度相似则直接使用缓存的摘要避免重复计算。异步与懒加载非关键路径的操作可以异步执行。例如在Agent思考生成回应的同时异步进行本轮对话的向量化存储和与历史的相关性分析为下一轮对话做准备。轻量级模型优先对于信息提取、简单分类等任务优先尝试使用轻量级的本地模型如通过ONNX Runtime加速的BERT变体而不是动辄调用GPT-4。设置压缩频率不是每一轮对话都需要压缩。可以设置一个压缩周期或者仅在上下文长度超过“软阈值”且新增内容相关性较低时才触发深度压缩。4.4 评估难题如何知道它真的“记住”了这是一个非常实际的问题。你如何定量评估你的上下文感知Agent比普通的、带有固定长度上下文窗口的Agent更优秀坑点缺乏客观的评估指标只能靠主观感觉或有限的测试用例。避坑方法构建针对性测试集设计一系列多轮对话的测试用例这些用例需要依赖前面的关键信息才能正确回答最后的问题。例如一个长达20轮的旅行规划对话最后问“我们第一天晚上准备在哪里吃饭”正确答案依赖于第三轮对话中提到的酒店位置。定义可量化的指标关键信息召回率在长对话末尾针对之前出现过的N个关键信息点如日期、名字、决策Agent的回答中正确包含的比例。上下文相关响应率人工或通过模型判断Agent的回应是否恰当引用了历史信息而不是通用回复。任务完成率对于任务型对话是否能基于所有历史信息成功完成最终任务。A/B测试在相同的测试集上对比“基础Agent带长上下文”和“增强AgentGliding Horse策略”的表现。不仅要看最终答案的正确率还要比较两者的Token使用量成本和响应延迟性能。5. 超越对话Gliding Horse思想的其他应用场景上下文动态感知与智能压缩的思想绝不局限于聊天对话Agent。任何涉及处理长序列信息、需要聚焦关键内容的场景都可以从中受益。5.1 长文档分析与问答当你向Agent提交一本数百页的PDF手册并连续提问时Gliding Horse机制可以将文档智能分块并建立向量索引。针对每个新问题动态检索最相关的几个章节块。将这些相关块进行智能压缩提炼出与问题最相关的核心内容再送入LLM生成答案。这比直接将整个文档或所有相关块原文塞进上下文要高效、准确得多。5.2 代码库智能助手程序员向AI助手询问一个大型代码库中的问题。助手可以感知当前编辑的文件和光标位置。动态检索代码库中相关的函数、类、依赖文件通过代码抽象语法树AST和向量检索结合。将检索到的复杂代码逻辑压缩成简洁的自然语言描述或调用关系图再结合具体问题给出建议。这使得助手能“理解”超出其上下文窗口的大型项目结构。5.3 持续学习与个性化记忆一个长期与用户交互的个性化Agent可以利用Gliding Horse机制来管理用户的“长期记忆”。将日常交互中的用户偏好、习惯、重要事实存储到向量数据库和传统数据库中。在新的对话中根据话题动态检索相关的长期记忆。将这些记忆压缩成一段“用户画像摘要”作为系统指令的一部分让Agent始终保持对用户的个性化认知。例如“用户偏好深色模式对咖啡因敏感最近在学习围棋”。实现一个真正能“听得进、记得住”的Agent上下文动态感知与智能压缩是不可或缺的核心能力。它不是一个炫技的功能而是解决大模型实际应用瓶颈的关键工程。从简单的向量检索到融合了状态跟踪、信息提取和生成式摘要的混合策略每一步都需要精心设计和反复调优。这个过程充满了挑战比如如何在压缩中保真如何平衡性能与成本如何评估效果。但当你看到你的Agent能在长达数十轮的复杂对话中始终把握主线精准回溯关键细节时你会觉得这一切都是值得的。这匹“滑翔之马”最终能让你的AI应用在能力的广度和资源的效率之间找到那个完美的平衡点。