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 拥有“动态注意力”

我们的优化方案围绕三个核心目标：

1. 修复补充输入路径，确保用户的每一条消息都能可靠到达 Agent。
2. 为每条输入引入任务关联度系数（relevance_score），量化其与当前任务全局目标及局部连贯性的关系。
3. 基于 relevance_score 增强 L1 上下文淘汰和 CWM 压缩策略，实现“越相关的记得越牢，不相关的尽早遗忘”。

三、整体架构：双通道感知与智能淘汰

graph TB subgraph INPUT["两条用户输入路径"] INIT["初始任务输入"] SUPP["中间补充输入"] end subgraph EVENT["EventBus 路径"] SUPP --> EB["EventBus.emit<br/>USER_SUPPLEMENTARY_INPUT"] EB --> SA["SA 接收分类"] SA --> STORE["SupplementaryInputStore<br/>暂存补充输入"] end subgraph HOOK["Hook 路径（初始输入）"] INIT --> TASK_START["TaskStart Hook"] TASK_START --> TRACKER["RelevanceTracker<br/>计算 relevance_score"] end subgraph AGENT["Agent 执行循环"] STORE -->|"CycleStart 取出"| RUNNER["AgentRunner"] TRACKER -->|"写入"| L1["L1Session<br/>relevance_score + embedding"] RUNNER -->|"注入上下文"| L1 end subgraph EVICT["增强淘汰与压缩"] L1 --> EVICT_ALG["evict_with_query<br/>硬阈值过滤 + 融合评分"] EVICT_ALG --> CWM["ContextWindowManager<br/>感知 relevance 压缩"] end subgraph BATCH["后台话题检测"] BATCH_AGENT["topic_coherence_agent"] -->|"全窗口重算"| L1 BATCH_AGENT -->|"话题切换信号"| COMPRESS["触发主动压缩"] end TRACKER --> BATCH_AGENT CWM --> L1

架构的核心思路是：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 方法采用两步淘汰策略：

1. 硬阈值过滤：对于 relevance_score 低于阈值且超过安全窗口的条目（非补充输入），直接淘汰，不参与后续评分。这能快速清除明显无关的历史摘要。
2. 融合评分淘汰：对剩余条目计算融合评分，综合时间衰减、当前查询相似度、任务关联度以及 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 的上下文管理获得了质的提升：

1. 补充输入零丢失：用户在任何阶段补充的内容，都能在 Agent 下一次推理时被准确接收，bug 修复率 100%。
2. 上下文更聚焦：不相关的历史摘要被快速淘汰或压缩，相关性高的内容得到保留。实测在多话题长会话中，上下文 Token 消耗平均降低 25-35%。
3. 主动话题感知：后台话题检测能在用户意图漂移时自动清理旧上下文，避免 LLM 被过时信息干扰。
4. 用户输入受保护：补充输入和纠正指令绝不会被误淘汰，Agent 始终以最新指示为准。
5. 完全可配置：α、β、硬阈值、安全窗口等参数均可调整，适配不同场景的上下文敏感度需求。

七、结语

上下文管理是 Agent 系统的基石。我们通过借鉴 CPU 缓存原理，引入动态相关性感知，修复关键 bug，让 Gliding Horse 的 Agent 真正具备了“动态注意力”。它知道哪些信息值得牢记，哪些可以遗忘，并在用户插话时及时响应。

这套设计充分发挥了 Gliding Horse 的事件总线、分层记忆、Hook 机制和 Batch Agent 框架的优势，将上下文管理从“静态窗口”升级为“智能感知与自适应淘汰”。如果你也在探索 Agent OS 或上下文优化的边界，欢迎来 GitHub 交流：https://github.com/doiito/gliding_horse。