Gliding Horse 上下文动态感知与智能压缩让 Agent 真正“听得进”每一句话摘要本文深入解析 Gliding Horse流马AI Agent 操作系统的上下文动态感知与智能压缩增强方案。针对 Agent 在多轮对话中“失聪”——忽略用户补充输入、上下文窗口 Token 浪费、注意力稀释等核心痛点提出基于 RelevanceTracker 的任务关联度评分、SupplementaryInputStore 补充输入修复、L1Session 增强淘汰算法及 topic_coherence_agent 话题检测等关键技术。实测表明该方案实现补充输入零丢失上下文 Token 消耗平均降低 25-35%为构建真正“听得进话”的智能 Agent 提供了可落地的架构参考。关键词AI Agent上下文管理动态感知智能压缩Gliding HorseRelevanceTracker补充输入修复话题检测Token 优化Agent 操作系统在打造 Gliding Horse流马这个 AI Agent 操作系统的过程中我们花大量精力解决了一个关键问题如何让 Agent 在多轮对话中始终关注最重要的信息同时不会漏掉用户的任何补充这听起来简单但实际做起来却充满挑战。传统 Agent 把对话历史一股脑塞进上下文窗口聊得越多Token 越贵注意力越散。用户中间插一句“不对你应该用 JWT 而不是 Session”系统可能根本没听见——因为补充输入的传递路径断了。我们最近完成了上下文动态感知与智能压缩增强模块的实现。它通过实时相关性追踪、补充输入修复、话题切换检测和增强的淘汰算法让 Gliding Horse 的每一个 Agent 都能精准捕捉上下文变化在保证不丢失关键信息的前提下大幅降低 Token 消耗。一、问题的根源两条输入路径与“失聪”的 AgentGliding Horse 的用户输入分两条路径初始任务输入用户在 TUI 中下达主任务走 TaskStart Hook进入 Agent 执行循环。中间补充输入Agent 执行过程中用户通过 EventBus 发送USER_SUPPLEMENTARY_INPUT事件SA 接收后分类处理再注入给正在运行的 Agent。我们发现在原有实现中第二条路径存在一个严重的 bugSA 确实收到了补充输入并且能将其显示在 TUI 上但实际负责执行的 Agent 并没有收到这条消息。用户以为 Agent “听见了”其实它根本没听进去。这导致 Agent 在后续推理中完全忽略用户的纠正或补充造成任务偏离。同时即使输入成功到达Agent 的上下文管理也缺乏对“这条信息与当前任务到底有多相关”的量化评估。上下文窗口内充斥大量过时或无关的摘要Token 被白白浪费LLM 的注意力也在噪声中稀释。二、设计目标让 Agent 拥有“动态注意力”我们的优化方案围绕三个核心目标修复补充输入路径确保用户的每一条消息都能可靠到达 Agent。为每条输入引入任务关联度系数relevance_score量化其与当前任务全局目标及局部连贯性的关系。基于 relevance_score 增强 L1 上下文淘汰和 CWM 压缩策略实现“越相关的记得越牢不相关的尽早遗忘”。三、整体架构双通道感知与智能淘汰后台话题检测增强淘汰与压缩Agent 执行循环Hook 路径初始输入EventBus 路径两条用户输入路径CycleStart 取出写入注入上下文全窗口重算话题切换信号初始任务输入中间补充输入EventBus.emitUSER_SUPPLEMENTARY_INPUTSA 接收分类SupplementaryInputStore暂存补充输入TaskStart HookRelevanceTracker计算 relevance_scoreAgentRunnerL1Sessionrelevance_score embeddingevict_with_query硬阈值过滤 融合评分ContextWindowManager感知 relevance 压缩topic_coherence_agent触发主动压缩架构的核心思路是RelevanceTracker 负责为每条输入实时打分SupplementaryInputStore 确保补充输入不丢失L1Session 和 ContextWindowManager 利用这些分数做出智能淘汰决策而后台 Batch Agent 则定期审视全窗口检测话题漂移并触发主动压缩。四、核心组件实现4.1 RelevanceTracker任务关联度的“评分器”我们新增了RelevanceTracker组件它在每次用户输入初始或补充时被调用。它利用 Gliding Horse 已有的 Embedding 管线Ollama / OneAPI 等生成文本向量然后计算两个维度的相似度全局任务相关度该输入与任务 5W2H 核心描述what why的余弦相似度。局部连贯性该输入与前一相邻输入的余弦相似度。最终的relevance_score由两者加权融合score α × global_sim (1-α) × local_simα 默认为 0.6保证全局任务目标占主导同时兼顾对话的连贯性。这个分数会随着输入一起写入 L1 的L1Turn元数据中供后续淘汰算法使用。下面是用 Python 伪代码体现的核心逻辑classRelevanceTracker:def__init__(self,embedding_service,alpha0.6):self.embeddingembedding_service# 接入 Ollama/OneAPI 的 Embedding 管线self.alphaalpha# 全局 vs 局部权重defcompute_relevance(self,user_input:str,task_description:str,prev_input:str)-float:# 1. 生成当前输入的向量input_vecself.embedding.embed(user_input)# 2. 计算全局任务相关度与任务 5W2H 描述的余弦相似度task_vecself.embedding.embed(task_description)global_simcosine_similarity(input_vec,task_vec)# 3. 计算局部连贯性与上一条输入的余弦相似度prev_vecself.embedding.embed(prev_input)local_simcosine_similarity(input_vec,prev_vec)# 4. 加权融合得到最终 relevance_scorescoreself.alpha*global_sim(1-self.alpha)*local_simreturnscore4.2 SupplementaryInputStore补充输入的“快递柜”我们新增了SupplementaryInputStore它是一个线程安全的内存共享存储ArcMutexHashMaptask_iri, VecSupplementEntry。当 SA 分类处理完补充输入后不是直接调用一个可能失效的注入方法而是将补充内容、embedding 和 relevance_score 打包存入该 store。每个执行循环开始CycleStart时AgentRunner会检查当前任务是否有未消费的补充条目取出后注入为 ChatMessagerole: user并同步写入 L1Session。这样就彻底修复了补充输入丢失的 bug无论 Agent 处于哪个执行阶段都能在下一次推理前看到用户的补充。下面是用 Python 伪代码体现的核心逻辑importthreadingfromdataclassesimportdataclass,fieldfromtypingimportDict,ListdataclassclassSupplementEntry:content:strembedding:List[float]relevance_score:floatclassSupplementaryInputStore:def__init__(self):# 线程安全的内存共享存储task_iri - 未消费的补充条目列表self._store:Dict[str,List[SupplementEntry]]{}self._lockthreading.Lock()defstore(self,task_iri:str,entry:SupplementEntry):SA 分类处理后调用将补充输入暂存withself._lock:iftask_irinotinself._store:self._store[task_iri][]self._store[task_iri].append(entry)defconsume(self,task_iri:str)-List[SupplementEntry]:AgentRunner 在 CycleStart 时调用取出并清空该任务的所有未消费条目withself._lock:entriesself._store.pop(task_iri,[])returnentries4.3 L1Session 增强让淘汰算法“心中有数”我们对L1Turn数据结构进行了扩展新增relevance_score、last_access和is_supplement字段。同时EvictionConfig增加了三个关键配置项relevance_threshold硬淘汰阈值默认 0.3。safe_window_seconds安全窗口默认 300 秒。beta融合权重控制当前查询相似度与任务历史关联度的比重。增强后的evict_with_query方法采用两步淘汰策略硬阈值过滤对于 relevance_score 低于阈值且超过安全窗口的条目非补充输入直接淘汰不参与后续评分。这能快速清除明显无关的历史摘要。融合评分淘汰对剩余条目计算融合评分综合时间衰减、当前查询相似度、任务关联度以及 Token 成本进行排序淘汰最低分条目。特别地is_supplement为真的条目即用户补充输入不受硬阈值淘汰确保用户的纠正和补充信息不会被意外遗忘。4.4 ContextWindowManager 增强压缩也看“脸色”ContextWindowManager在触发上下文压缩时现在可以读取消息对应的relevance_score映射。压缩中间消息时优先保留高 relevance 的消息而不是机械地截取末尾几条。这让压缩结果更加聚焦于任务核心。4.5 topic_coherence_agent后台的“话题侦探”我们新增了一个 Batch Agent 角色topic_coherence_agent它定期每 2 分钟或由话题切换事件驱动对当前 L1 窗口内的所有 turns 进行全量重算。通过对比相邻 turns 的嵌入向量相似度它能检测出话题边界相似度低于 0.4 视为潜在切换。一旦发现话题切换它会通过 EventBus 发布TopicShiftDetected事件触发一次主动上下文压缩及时清理旧话题残留。五、与 Gliding Horse 架构的深度融合这套感知增强机制并非孤立存在而是与 Gliding Horse 的核心架构紧密交织事件总线补充输入和话题切换检测均通过 EventBus 流转与 TypeMask 位图路由天然兼容任何订阅者都能感知这些事件。四层记忆relevance_score 写入 L1淘汰后的摘要通过 IRI 弱引用回 L0L2 黑板状态不受影响。Hook 系统初始输入利用现有的 TaskStart Hook补充输入通过 AgentRunner 的 CycleStart 注入不改变原有执行流程。Batch Agent 框架topic_coherence_agent 完全复用现有的 SlidingWindow、TriggerSystem 和配置机制无需额外框架改动。Embedding 管线与已有的 Ollama/OneAPI embedding 服务无缝对接实现从文本到语义向量的全自动流水线。六、实现效果与收益经过这些增强Gliding Horse 的上下文管理获得了质的提升补充输入零丢失用户在任何阶段补充的内容都能在 Agent 下一次推理时被准确接收bug 修复率 100%。上下文更聚焦不相关的历史摘要被快速淘汰或压缩相关性高的内容得到保留。实测在多话题长会话中上下文 Token 消耗平均降低 25-35%。主动话题感知后台话题检测能在用户意图漂移时自动清理旧上下文避免 LLM 被过时信息干扰。用户输入受保护补充输入和纠正指令绝不会被误淘汰Agent 始终以最新指示为准。完全可配置α、β、硬阈值、安全窗口等参数均可调整适配不同场景的上下文敏感度需求。七、结语上下文管理是 Agent 系统的基石。我们通过借鉴 CPU 缓存原理引入动态相关性感知修复关键 bug让 Gliding Horse 的 Agent 真正具备了“动态注意力”。它知道哪些信息值得牢记哪些可以遗忘并在用户插话时及时响应。这套设计充分发挥了 Gliding Horse 的事件总线、分层记忆、Hook 机制和 Batch Agent 框架的优势将上下文管理从“静态窗口”升级为“智能感知与自适应淘汰”。如果你也在探索 Agent OS 或上下文优化的边界欢迎来 GitHub 交流https://github.com/doiito/gliding_horse。
