【Agent Harness】Gliding Horse 上下文动态感知与智能压缩：让 Agent 真正“听得进”每一句话
Gliding Horse 上下文动态感知与智能压缩：让 Agent 真正“听得进”每一句话
摘要：本文深入解析 Gliding Horse（流马）AI Agent 操作系统的上下文动态感知与智能压缩增强方案。针对 Agent 在多轮对话中“失聪”——忽略用户补充输入、上下文窗口 Token 浪费、注意力稀释等核心痛点，提出基于 RelevanceTracker 的任务关联度评分、SupplementaryInputStore 补充输入修复、L1Session 增强淘汰算法及 topic_coherence_agent 话题检测等关键技术。实测表明，该方案实现补充输入零丢失，上下文 Token 消耗平均降低 25-35%，为构建真正“听得进话”的智能 Agent 提供了可落地的架构参考。
关键词：AI Agent；上下文管理；动态感知；智能压缩；Gliding Horse；RelevanceTracker；补充输入修复；话题检测；Token 优化；Agent 操作系统
在打造 Gliding Horse（流马）这个 AI Agent 操作系统的过程中，我们花大量精力解决了一个关键问题：如何让 Agent 在多轮对话中，始终关注最重要的信息，同时不会漏掉用户的任何补充？
这听起来简单，但实际做起来却充满挑战。传统 Agent 把对话历史一股脑塞进上下文窗口，聊得越多，Token 越贵，注意力越散。用户中间插一句“不对，你应该用 JWT 而不是 Session”，系统可能根本没听见——因为补充输入的传递路径断了。
我们最近完成了上下文动态感知与智能压缩增强模块的实现。它通过实时相关性追踪、补充输入修复、话题切换检测和增强的淘汰算法，让 Gliding Horse 的每一个 Agent 都能精准捕捉上下文变化，在保证不丢失关键信息的前提下，大幅降低 Token 消耗。
一、问题的根源：两条输入路径与“失聪”的 Agent
Gliding Horse 的用户输入分两条路径：
- 初始任务输入：用户在 TUI 中下达主任务，走 TaskStart Hook，进入 Agent 执行循环。
- 中间补充输入：Agent 执行过程中，用户通过 EventBus 发送
USER_SUPPLEMENTARY_INPUT事件，SA 接收后分类处理，再注入给正在运行的 Agent。
我们发现在原有实现中，第二条路径存在一个严重的 bug：SA 确实收到了补充输入，并且能将其显示在 TUI 上，但实际负责执行的 Agent 并没有收到这条消息。用户以为 Agent “听见了”，其实它根本没听进去。这导致 Agent 在后续推理中完全忽略用户的纠正或补充，造成任务偏离。
同时，即使输入成功到达，Agent 的上下文管理也缺乏对“这条信息与当前任务到底有多相关”的量化评估。上下文窗口内充斥大量过时或无关的摘要，Token 被白白浪费，LLM 的注意力也在噪声中稀释。
二、设计目标：让 Agent 拥有“动态注意力”
我们的优化方案围绕三个核心目标：
- 修复补充输入路径，确保用户的每一条消息都能可靠到达 Agent。
- 为每条输入引入任务关联度系数（relevance_score），量化其与当前任务全局目标及局部连贯性的关系。
- 基于 relevance_score 增强 L1 上下文淘汰和 CWM 压缩策略，实现“越相关的记得越牢，不相关的尽早遗忘”。
三、整体架构：双通道感知与智能淘汰
架构的核心思路是：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 伪代码体现的核心逻辑：
class RelevanceTracker:
def __init__(self, embedding_service, alpha=0.6):
self.embedding = embedding_service # 接入 Ollama/OneAPI 的 Embedding 管线
self.alpha = alpha # 全局 vs 局部权重
def compute_relevance(self, user_input: str, task_description: str, prev_input: str) -> float:
# 1. 生成当前输入的向量
input_vec = self.embedding.embed(user_input)
# 2. 计算全局任务相关度：与任务 5W2H 描述的余弦相似度
task_vec = self.embedding.embed(task_description)
global_sim = cosine_similarity(input_vec, task_vec)
# 3. 计算局部连贯性：与上一条输入的余弦相似度
prev_vec = self.embedding.embed(prev_input)
local_sim = cosine_similarity(input_vec, prev_vec)
# 4. 加权融合得到最终 relevance_score
score = self.alpha * global_sim + (1 - self.alpha) * local_sim
return score
4.2 SupplementaryInputStore：补充输入的“快递柜”
我们新增了 SupplementaryInputStore，它是一个线程安全的内存共享存储（Arc<Mutex<HashMap<task_iri, Vec<SupplementEntry>>>>）。当 SA 分类处理完补充输入后，不是直接调用一个可能失效的注入方法，而是将补充内容、embedding 和 relevance_score 打包存入该 store。
每个执行循环开始（CycleStart）时，AgentRunner 会检查当前任务是否有未消费的补充条目，取出后注入为 ChatMessage（role: user），并同步写入 L1Session。这样就彻底修复了补充输入丢失的 bug，无论 Agent 处于哪个执行阶段，都能在下一次推理前看到用户的补充。
下面是用 Python 伪代码体现的核心逻辑：
import threading
from dataclasses import dataclass, field
from typing import Dict, List
@dataclass
class SupplementEntry:
content: str
embedding: List[float]
relevance_score: float
class SupplementaryInputStore:
def __init__(self):
# 线程安全的内存共享存储：task_iri -> 未消费的补充条目列表
self._store: Dict[str, List[SupplementEntry]] = {}
self._lock = threading.Lock()
def store(self, task_iri: str, entry: SupplementEntry):
"""SA 分类处理后调用，将补充输入暂存"""
with self._lock:
if task_iri not in self._store:
self._store[task_iri] = []
self._store[task_iri].append(entry)
def consume(self, task_iri: str) -> List[SupplementEntry]:
"""AgentRunner 在 CycleStart 时调用，取出并清空该任务的所有未消费条目"""
with self._lock:
entries = self._store.pop(task_iri, [])
return entries
4.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 弱引用回 L0，L2 黑板状态不受影响。
- 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。
浙公网安备 33010602011771号