1. 项目概述当Agent的“注意力”开始“走神”在构建和部署智能体Agent系统的过程中我们常常会遇到一个令人头疼的现象随着对话轮次或任务步骤的增加Agent的表现会逐渐“失焦”。它可能忘记了几轮对话前用户明确提出的约束条件或者在处理长文档时对关键信息的捕捉能力直线下降。这背后是智能体系统普遍面临的“上下文窗口”与“注意力机制”的经典矛盾。我们既希望Agent拥有海量的记忆长上下文又希望它能精准地聚焦于当前任务最相关的信息高精度注意力。传统的解决方案无论是粗暴地截断历史还是将全部上下文一股脑地塞给大模型都像是给近视的Agent配了一副错误的眼镜——要么视野狭窄要么一片模糊。“Gliding Horse”这个项目正是为了解决这一核心痛点而生。它不是一个全新的底层模型而是一套精巧的、可插拔的“上下文感知与智能压缩”框架。你可以把它想象成Agent大脑中的一个“高级信息处理中心”。这个中心实时监控着对话流和任务状态能够动态地评估历史上下文中每一段信息的重要性并据此进行智能化的压缩、提炼和重组确保传递给核心推理模型通常是LLM的始终是最精炼、最相关、最“高能”的上下文摘要。其目标非常明确在有限的上下文窗口内最大化有效信息的密度从而让Agent的“注意力”永不偏移持续保持高水平的任务完成度和对话连贯性。这套机制对于构建复杂的、多轮交互的AI应用至关重要。无论是需要长时间、多步骤协作的编码助手还是需要深入分析上百页文档的智能分析工具亦或是需要记住用户长期偏好的个性化聊天机器人Gliding Horse都能为其提供稳定的“注意力续航”能力。它让Agent从“金鱼记忆”进化为“侦探思维”不仅记得多更能记得准、用得上。2. 核心架构与设计哲学Gliding Horse的设计并非凭空想象它深深植根于对人类认知系统和现有技术瓶颈的洞察。其核心架构可以概括为“一个循环两层过滤三重感知”。2.1 “感知-评估-压缩”的动态循环整个系统的运作遵循一个紧密的循环感知 - 评估 - 压缩 - 反馈。感知层这是系统的“感官”。它持续摄入原始的对话历史、任务指令、工具调用结果、外部知识片段等一切构成上下文的信息流。感知层不做价值判断只负责高保真地收集和初步结构化数据例如将对话按轮次打上时间戳和发言者标签将工具调用记录其输入、输出和状态。评估层这是系统的“大脑皮层”。它基于多种启发式规则和轻量级模型对感知层收集的每一条信息进行实时的重要性评估。评估维度是多元的任务相关性这条信息与当前活跃任务目标的直接关联度有多高例如在订机票的任务中“用户偏好靠窗座位”的相关性就远高于“用户昨天聊了天气”。信息熵/新颖性这条信息是否包含了新的、未被摘要过的关键事实或约束重复的、冗余的信息得分会降低。时间衰减根据艾宾浩斯遗忘曲线的启发越久远的信息其基础重要性权重会有一个缓和的衰减除非被重新激活。结构性重要性用户明确指出的“必须”、“切记”、“不要”等强约束性语句或系统定义的关键节点如任务开始、子目标达成会被赋予更高的权重。压缩层这是系统的“执行器”。根据评估层给出的重要性分数压缩层决定哪些信息被保留、哪些被压缩、哪些被丢弃。压缩不是简单的删除而是提炼。对于高重要性信息可能原文保留对于中重要性信息可能用一句话摘要对于低重要性但仍有潜在关联的信息则可能被编码成几个关键词或一个向量存入一个可快速检索的“背景知识库”以备不时之需。反馈层压缩后的上下文核心摘要背景知识库指针被送入LLM进行推理和行动。LLM产生的新的行动和结果如新的回答、调用的工具结果会立即作为新的信息流反馈回感知层开启下一个循环。这样上下文的管理是动态、实时、伴随任务演进的。2.2 两层过滤从粗筛到精炼为了平衡效果与效率Gliding Horse采用了两级过滤策略第一层基于规则的快速过滤。这是一套高效的“守门员”规则用于快速剔除明显无关的噪音。例如过滤掉纯问候语如“你好”、“在吗”在若干轮后的历史记录。过滤掉连续失败的、无输出的工具调用记录的具体错误堆栈只保留“XX工具调用失败”这个事实。合并用户连续发出的、语义高度相似的追问。 这一层的目标是减量用极低的计算成本去掉“显然无用”的信息为后续精细处理减轻负担。第二层基于模型的智能精炼。这是核心所在。通常会使用一个比主推理LLM小得多的、专门微调过的“摘要/评估模型”。这个模型接收经过第一层过滤的上下文块并完成以下工作重要性打分为每个上下文片段可能是一句话、一个段落或一个工具调用记录输出一个重要性分数。生成摘要对于需要压缩的片段直接生成凝练的摘要。训练这个模型时目标不是通顺的段落而是最大化保留信息熵的“笔记式”摘要。识别关联识别不同片段之间的隐性关联例如发现用户在第3轮提到的“预算1000元”和第8轮提到的“酒店价格”需要关联起来考虑。注意这里的一个关键技巧是评估/摘要模型不需要拥有强大的世界知识或生成能力它只需要擅长理解和比较文本片段的重要性。因此我们可以选用参数量较小如7B或13B、在“文本重要性判断”任务上精调过的模型从而将整个上下文管理的开销控制在很低水平。2.3 三重感知让上下文“活”起来“上下文感知”不仅仅是感知文本内容Gliding Horse强调三重感知任务状态感知系统始终清楚当前处于哪个任务阶段规划、执行、检查、修正。不同阶段关注的历史信息不同。例如在执行阶段更关注具体的操作指令和参数在检查阶段则更关注最初的任务目标和约束条件。系统内部维护一个简单的“任务状态机”用以动态调整评估层的权重偏向。对话焦点感知通过检测对话中的指代、省略和话题转移系统能跟踪当前的“对话焦点”。当焦点转移时与新焦点相关的历史信息权重会被临时提升。例如用户突然从讨论“机票”转到讨论“酒店”那么之前关于酒店偏好的历史对话权重会立刻升高而机票的细节权重则相应降低。外部反馈感知系统会密切关注LLM或用户的“困惑”信号。例如如果LLM在生成内容中表现出对某些历史信息的模糊如使用“可能”、“好像”等词或者用户直接指出“你忘了我说过要靠窗的”这类反馈会作为一个强信号直接提升相关历史上下文的重要性甚至触发一次对“背景知识库”的主动检索和上下文重写。3. 智能压缩的核心算法与实现策略智能压缩是Gliding Horse的引擎。实现它并非只有一种方法而是一个根据实际资源、延迟要求和效果需求进行权衡的选择题。下面详细解析几种核心策略及其实现细节。3.1 基于嵌入向量聚类的语义压缩这是目前较为成熟和常用的一种无监督方法。其核心思想是语义相近的信息在向量空间中距离也近可以聚类后进行代表性摘要。实操步骤分块与嵌入将经过第一层过滤后的完整上下文文本按语义边界如按对话轮次、按段落切割成多个文本块[C1, C2, ..., Cn]。使用一个轻量且高效的嵌入模型如BGE-M3、text-embedding-3-small为每个文本块生成向量表示[V1, V2, ..., Vn]。时序加权在计算聚类前对每个文本块的向量进行加权。给较新的块赋予较高的权重因子如weight_i decay_factor ^ (n-i)其中i是块序号n是总数decay_factor取0.95-0.99。这相当于在语义相似度的基础上叠加了时间新鲜度的考量。动态聚类使用在线聚类算法如流式K-Means或层次聚类对这些加权后的向量进行聚类。关键点在于聚类数量K不是固定的。我们可以设定一个“簇内最大距离阈值”theta。当尝试将一个新块归入现有簇时计算其与簇中心的距离。若所有距离都大于theta则为此新块创建一个新簇。这样簇的数量由数据本身的分布决定。簇内摘要生成对于每个形成的簇将其包含的所有原始文本块按重要性可通过向量与簇中心的距离倒数来近似距离越近通常越具代表性排序选取Top-K个块或者将它们拼接后送入前文提到的轻量级摘要模型生成该簇的唯一摘要。这个摘要代表了该语义单元的核心信息。摘要排序与拼接将所有簇的摘要按照其对应簇中最新的文本块的时间戳进行排序拼接成最终的压缩上下文。同时记录每个摘要对应的原始文本块ID列表存入“背景知识库”以便需要时溯源。参数选择心得分块大小不宜过大或过小。对于对话按轮次分块是自然的。对于长文档尝试按200-500字符分块并确保在句子边界切割。距离阈值theta这是平衡压缩率和信息损失的关键。建议在开发集上通过实验确定。一个初始值可以设置为所有向量两两之间平均距离的60%-70%。阈值越大压缩越激进簇更少摘要更少阈值越小保留细节越多。摘要模型选择如果对延迟极其敏感甚至可以不用模型而是简单提取每个簇中距离中心最近的文本块作为“代表句”。效果尚可且零延迟。3.2 基于重要性评分的学习式压缩这种方法需要更多的前期准备但效果往往更精准。其核心是训练一个重要性评分模型。模型训练数据构造需要构建一个(长上下文 当前查询/任务 重要性标签)的数据集。可以通过人工标注或者利用更强大LLM如GPT-4进行蒸馏来构造。对于一段历史上下文中的每个句子或片段标注它对于回答当前查询或完成当前任务的重要性等级如0-无关1-相关2-关键。模型选型与训练选用一个编码器架构的模型如DeBERTa、RoBERTa。输入是“当前查询 [SEP] 待评分文本片段”输出是一个重要性分数回归任务或等级分类任务。损失函数可以设计为加权交叉熵给“关键”类别更高的权重。在线推理在运行时将当前任务描述与历史上下文的每一个片段配对送入评分模型得到分数。然后设定一个分数阈值高于阈值的保留或精炼低于阈值的压缩或丢弃。实现技巧缓存机制由于评分模型需要对大量片段进行推理计算量可能较大。可以利用片段内容的哈希值作为键将(片段 任务描述 分数)的结果缓存起来。当相似片段和任务再次出现时可直接使用缓存分数大幅提升效率。分数平滑为了避免重要信息因单次评分波动而被误删可以对同一片段在不同时刻的评分进行滑动平均处理。3.3 混合策略规则打底模型精修在实际的Gliding Horse实现中混合策略往往是最优解。一个典型的工作流如下规则引擎先行应用第一层基于规则的快速过滤去除明显噪音减少后续处理量。轻量模型评分使用一个微型的重要性评分模型可能是蒸馏过的对剩余片段进行快速初筛。这一步可以快速过滤掉大量“可能相关但非关键”的内容。精准摘要生成对于评分中高和关键的部分使用专门的摘要模型进行精炼。对于评分低的部分可以考虑丢弃或仅提取实体/关键词存入背景库。动态上下文组装将精炼后的关键摘要按时间或逻辑顺序组装。同时在提示词Prompt中明确告诉LLM“以下是提炼后的关键上下文...。此外关于[主题A]、[主题B]的更多细节已存档如需可随时告知我进行查询。” 这样既提供了核心上下文又保留了扩展能力。4. 系统集成与工程化实践设计再精妙的算法也需要扎实的工程实现才能落地。将Gliding Horse集成到现有的Agent框架中需要注意以下几个关键环节。4.1 与现有Agent框架的对接Gliding Horse应被设计成一个独立的上下文管理服务或中间件。它位于用户/环境与核心LLM之间。接口设计输入append(new_message_or_event)方法用于接收新的对话或事件。输出get_compressed_context()方法用于获取当前时刻压缩后的上下文。查询query_background_knowledge(topic)方法供LLM在需要时主动查询背景知识库。例如在LangChain或LlamaIndex这类框架中你可以自定义一个GlidingHorseMemory类继承其BaseMemory或BaseRetriever接口无缝替换原有的简单记忆模块。状态管理压缩上下文和背景知识库是核心状态。必须确保其线程安全/会话隔离对于多用户并发场景每个用户会话必须有独立的状态实例。可持久化支持将会话状态压缩上下文、背景库索引序列化存储以便在服务重启或会话恢复时能够还原。资源清理实现LRU最近最少使用等机制定期清理长时间不活跃的会话状态防止内存泄漏。4.2 性能优化与延迟控制上下文管理是实时进行的必须保证低延迟。异步处理append操作应该是非阻塞的。新信息到来后触发异步的压缩流程而get_compressed_context则返回当前最新的、可能稍旧但一致的压缩结果。这牺牲了一点点的“绝对实时性”换来了用户请求的极速响应。模型量化与加速用于评分和摘要的小模型务必进行量化INT8/INT4并使用推理加速库如vLLM, TensorRT-LLM, ONNX Runtime加载以获得最佳的推理速度。向量检索优化如果背景知识库使用了向量检索务必使用高效的向量数据库如Milvus, Qdrant, Weaviate并建立合适的索引HNSW。分级压缩频率不是每次append都触发全量压缩。可以设定策略每积累N条新信息或距离上次压缩超过T秒才执行一次完整的压缩周期。对于中间的信息可以先放入一个“待处理缓冲区”。4.3 效果评估与监控如何判断Gliding Horse是否真的在“帮忙”而不是“帮倒忙”需要建立一套评估体系。离线评估任务完成度在标准测试集上对比使用Gliding Horse和原始完整上下文或简单滑动窗口的Agent其任务成功率的变化。上下文利用率统计LLM生成内容中明确引用或基于被压缩保留的历史信息的比例。幻觉率检查因信息丢失导致的LLM“捏造事实”的比例是否降低。在线监控压缩率监控平均每次压缩后文本长度缩减的比例。这是一个重要的效率指标。用户显式反馈追踪用户说出“你忘了”、“我之前说过”等短语的频率这直接反映了注意力偏移问题。延迟百分位监控get_compressed_context接口的P50、P95、P99延迟确保在可接受范围内。5. 实战踩坑与避坑指南在实际开发和部署Gliding Horse的过程中我们积累了不少血泪教训。以下是一些关键的避坑点。5.1 信息丢失与“记忆扭曲”这是最危险的问题。过度压缩可能导致关键细节丢失甚至摘要模型产生“扭曲原意”的概括。避坑策略保留“原始引用”在任何压缩摘要后面以非提示文本的形式如XML标签注释附上其对应的原始文本块ID。当LLM的输出需要高度精确时如生成代码、法律条款可以配置一个“高精度模式”在此模式下Gliding Horse会附带更多原始文本片段甚至暂时关闭压缩。设置“不可压缩”标签允许开发者为某些特定类型的信息如用户输入的精确数字、系统指令、安全规则打上“不可压缩”标签确保它们永远以原文形式存在于核心上下文中。摘要模型的双重校验训练摘要模型时除了要求信息保留还可以增加一个“忠实度”判别任务让模型同时判断生成的摘要是否忠实于原文将这个分数作为生成时的约束条件。5.2 压缩策略的“滞后性”与“振荡”由于压缩不是瞬间完成的当对话焦点快速切换时系统可能来不及调整导致提供给LLM的上下文“滞后”于当前话题。另一种情况是两个话题重要性评分相近导致压缩结果在不同轮次间剧烈变化振荡让LLM感到困惑。避坑策略引入预测机制除了基于当前状态评估可以尝试用简单的序列模型预测下一个可能的话题焦点并提前微调权重。例如检测到用户提问“那么它的优点呢”可以预测接下来要讨论“优点”从而提前提升历史中关于“优点”描述的权重。使用迟滞阈值在重要性评分用于决定保留/丢弃时设置一个“迟滞区间”。例如丢弃阈值是0.3保留阈值是0.7。一个片段分数从0.8降到0.4时因为仍在区间内所以暂时保留只有降到0.3以下才丢弃。这能有效防止因分数微小波动导致的频繁切换。5.3 计算资源与成本权衡为每个会话都运行一个摘要模型成本可能很高。避坑策略冷热会话分离对于活跃会话频繁交互使用完整的Gliding Horse流程。对于不活跃或免费 tier 的会话可以降级到仅使用规则过滤的简化版。共享评分模型实例评分模型通常很小可以单实例服务多个会话请求通过批处理Batching来提高GPU利用率。定期“快照”与重建不必永远维护完整的压缩历史链。可以每隔一段时间如50轮对话将当前的压缩上下文作为一个“快照”固定下来后续的压缩只基于这个快照和之后的新内容进行。这可以防止压缩链过长带来的累积误差和计算增长。5.4 与LLM Prompt的协同设计压缩后的上下文如何呈现给LLM同样影响巨大。你不能简单地把一堆摘要扔给它。最佳实践清晰的元信息提示在Prompt开头明确告知LLM“接下来的对话历史是经过智能提炼的聚焦于当前任务最相关的部分。如需更早的细节请向我询问。” 这设定了LLM的预期。结构化呈现不要将摘要揉成一段。用清晰的标记进行结构化组织例如【核心任务目标】用户需要预订本周五飞往北京的机票预算不超过1500元偏好靠窗座位。 【近期关键约束】用户补充要求起飞时间最好在上午。 【已执行操作】已查询到航班ABC123价格1400元时间09:30座位可选。 【待确认事项】用户尚未提供乘机人姓名信息。这种结构比纯文本段落更易于LLM理解和引用。提供“查询”工具在给LLM的Tool Calling列表中增加一个query_detail(话题)工具。当LLM觉得自己需要更多信息时可以主动调用此工具Gliding Horse则从背景知识库中检索相关原始细节返回。这实现了按需加载进一步节省了上下文窗口。Gliding Horse所代表的“上下文感知与智能压缩”思路是构建高性能、高可靠Agent系统的关键基础设施。它没有追求无限扩展的上下文长度而是转向追求有限窗口内的信息质量与密度。这套机制的有效性已经在我们的多个复杂任务型Agent中得到了验证。它让Agent摆脱了对“蛮力”的依赖转而依靠“巧劲”真正像一位经验丰富的助手一样在纷繁的信息流中牢牢抓住重点持续输出精准、连贯、令人满意的结果。实现它需要细致的算法设计、扎实的工程实现以及对Agent行为模式的深刻理解但带来的体验提升无疑是革命性的。