在打造 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 压缩策略，实现“越相关的记得越牢，不相关的尽早遗忘”。
三、整体架构：双通道感知与智能淘汰
后台话题检测

增强淘汰与压缩

Agent 执行循环

Hook 路径（初始输入）

EventBus 路径

两条用户输入路径

CycleStart 取出

写入

注入上下文

全窗口重算

话题切换信号

初始任务输入

中间补充输入

EventBus.emit
USER_SUPPLEMENTARY_INPUT

SA 接收分类

SupplementaryInputStore
暂存补充输入

TaskStart Hook

RelevanceTracker
计算 relevance_score

AgentRunner

L1Session
relevance_score + embedding

evict_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 伪代码体现的核心逻辑：

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>>>）。当 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 增强：压缩也看“脸色”