Gliding Horse v0.1.4.preview 发布：时间感知、闭环审计与智能增强

摘要：Gliding Horse v0.1.4.preview 正式发布，本次更新聚焦三大核心能力——时间感知、闭环审计与智能增强。Agent 首次具备统一时间线系统，支持时间衰减重排序与时间范围过滤；5W2H 审计从数据容器升级为维度级闭环诊断子系统，Failed 维度自动触发因果引擎根因分析；SA 模块按生命周期拆分为 8 个独立模块，知识图谱上下文注入、Hyperspace 语义搜索、技能图谱冷热分离等智能感知能力同步增强。本文详细解读 v0.1.4 的技术架构与设计思路。

关键词：Gliding Horse, Agent OS, 时间感知, 5W2H审计, 因果引擎, 技能图谱, Rust, AI Agent, 智能增强, 闭环诊断

Gliding Horse 从最初就具备了理解上下文变化、从执行中学习和自我修正的能力——动态 PDCA 编排、四层记忆体系、技能图谱自进化、根因分析引擎，这些在之前的文章里都详细介绍过。

v0.1.4.preview 要做的不是“补课”，而是让这套智能体系更系统、更紧密、更精准。这次更新的核心是三个关键词：时间感知、闭环审计、智能增强。下面逐一展开。

---

一、SA 模块拆分：让“大脑”结构更清晰

在之前的版本中，SA（Supervisor Agent）的所有逻辑集中在一个庞大的文件里。v0.1.4 把它按生命周期阶段拆分为 8 个独立模块：

每个模块职责单一，通过 types.rs 中定义的类型契约通信。最大的 execution.rs 通过 SystemPromptBuilder 的 Region 机制解耦了提示词构建逻辑。为什么按生命周期拆而不是按数据类型拆？因为 SA 的执行流（诊断→规划→执行→评估）相对稳定，而类型定义会随业务频繁变化。按生命周期拆，改业务时不会动到执行框架。

同时，旧的 Workflow Engine 被移除——它的 DAG 执行能力已被 PDCA 的 7 级复杂度模型完全覆盖，减少两层编排系统的维护成本。

---

二、时间感知：Agent 终于有了“时间感”

这是 v0.1.4 引入的全新能力。之前的 Agent 在进行上下文检索和相关性计算时，依赖的是语义相似度——但时间维度是缺失的。一条一小时前的“高度相关”记忆，和一条一分钟前的“高度相关”记忆，权重完全一样。

v0.1.4 新增了统一时间线系统（src/core/timeline.rs），贯穿技能图谱、向量存储和 Agent 提示词：

时间衰减重排序

向量搜索结果在返回前会经过指数时间衰减：

new_score = original_score × exp(-λ · Δt)

λ 默认 0.5，大约 1.4 小时半衰期。一条一小时前的记忆，其权重会自动降到原来的 60% 左右。这个衰减在应用层实现，不影响 HNSW 索引结构，λ 可按场景配置。

下面是一个 Rust 代码示例，展示如何计算指数时间衰减得分：

use std::time::{Duration, SystemTime};

/// 计算指数时间衰减后的相关性得分
///
/// # 参数说明
/// - `original_score`：原始语义相似度得分（0.0 ~ 1.0）
/// - `lambda`：衰减系数 λ，控制衰减速度。λ 越大，衰减越快
/// - `elapsed`：从事件发生到当前的时间间隔
///
/// # λ 对衰减速度的影响
/// - λ = 0.5（默认值）：半衰期约 1.4 小时，1 小时后权重降至约 60%
/// - λ = 1.0：半衰期约 42 分钟，1 小时后权重降至约 37%
/// - λ = 0.1：半衰期约 7 小时，1 小时后权重降至约 90%（衰减缓慢）
fn time_decay_score(original_score: f64, lambda: f64, elapsed: Duration) -> f64 {
    let delta_t = elapsed.as_secs_f64() / 3600.0; // 转换为小时
    let new_score = original_score * (-lambda * delta_t).exp();
    new_score
}

fn main() {
    let original = 0.85; // 原始语义相似度得分

    // 模拟一条 1 小时前的记忆，使用默认 λ = 0.5
    let one_hour = Duration::from_secs(3600);
    let score_1h = time_decay_score(original, 0.5, one_hour);
    println!("1 小时前 (λ=0.5): {:.3}", score_1h); // 约 0.515（≈ 60%）

    // 模拟一条 30 分钟前的记忆
    let thirty_min = Duration::from_secs(1800);
    let score_30m = time_decay_score(original, 0.5, thirty_min);
    println!("30 分钟前 (λ=0.5): {:.3}", score_30m); // 约 0.654

    // 对比不同 λ 值对同一时间间隔的影响
    let score_lambda_1 = time_decay_score(original, 1.0, one_hour);
    let score_lambda_01 = time_decay_score(original, 0.1, one_hour);
    println!("1 小时前 (λ=1.0): {:.3}", score_lambda_1);  // 约 0.313（衰减更快）
    println!("1 小时前 (λ=0.1): {:.3}", score_lambda_01); // 约 0.769（衰减更慢）
}

λ 参数调优建议：在实时性要求高的场景（如文件变更监控）可增大 λ 使旧信息快速降权；在长期知识检索场景（如技能图谱查询）可减小 λ 保留更多历史相关性。默认 λ=0.5 在大多数 Agent 任务中取得了较好的平衡。

时间范围过滤

技能图谱可以查询“最近 24 小时内更新过的技能”，向量存储可以限定“只搜索最近 5 分钟的文件变更事件”。时间线查询框架通过 TimelineEntry 枚举统一了不同存储的时间接口。

下面是一个 Rust 代码示例，展示如何使用 TimelineEntry 枚举进行时间范围查询：

use chrono::{Duration, Utc};
use gliding_horse::core::timeline::{TimelineEntry, TimelineQuery};

/// 查询最近 5 分钟内的文件变更事件
fn query_recent_file_changes() -> Vec<TimelineEntry> {
    let now = Utc::now();
    let five_minutes_ago = now - Duration::minutes(5);

    // 构建时间范围查询：限定时间窗口和事件类型
    let query = TimelineQuery::builder()
        .start_time(five_minutes_ago)   // 起始时间：5 分钟前
        .end_time(now)                   // 结束时间：当前时间
        .entry_type("file_change")       // 只查询文件变更事件
        .limit(50)                       // 最多返回 50 条
        .build();

    // 执行查询，返回匹配的 TimelineEntry 列表
    timeline_store.query(query).unwrap()
}

/// 查询最近 24 小时内更新过的技能
fn query_recent_skills() -> Vec<TimelineEntry> {
    let now = Utc::now();
    let last_24h = now - Duration::hours(24);

    let query = TimelineQuery::builder()
        .start_time(last_24h)            // 起始时间：24 小时前
        .end_time(now)                   // 结束时间：当前时间
        .entry_type("skill_update")      // 只查询技能更新事件
        .build();

    timeline_store.query(query).unwrap()
}

关键参数说明：

• start_time / end_time：定义查询的时间窗口，支持任意时间范围组合。
• entry_type：按事件类型过滤（如 file_change、skill_update），对应 TimelineEntry 枚举的变体。
• limit：限制返回条目数，避免大范围查询时内存溢出。
• TimelineQuery 通过 Builder 模式构建，所有参数均为可选——不指定时间范围则查询全部历史。

LLM 也能“看表”

Agent 的系统提示词中新增了 TimeAwareness 区域：

# Time Awareness
- Current time: 2026-07-11 14:30:00 UTC
- Task started at: 2026-07-11 14:00:00Z
- Elapsed time: 30m 0s
- Older information may be less relevant than recent information

LLM 在每次生成时都能清晰感知时间流逝，做出更符合时效性的判断。使用会话创建时间而非当前时间，确保检查点恢复后时间线一致。

---

三、5W2H 审计：从数据容器升级为闭环诊断

5W2H 一直是 Gliding Horse 的任务元数据骨架。之前它是一个结构化的数据容器，v0.1.4 把它升级为完整的维度级审计子系统。

每个维度的审计逻辑独立：

• What：任务是否完成 + 是否有输出 → Pass/Fail
• Why：成功标准匹配率 ≥80% Pass，≥50% Warning，<50% Fail
• Who/When/Where/How/HowMuch：边界检查与一致性验证

关键的增强在于：Failed 维度会自动通过 CausalObservation 记录到因果引擎，驱动根因分析。这不是“审计完就完了”，而是把审计、感知、根因分析串成了一个闭环。Warning 状态提供了中间态，避免非关键失败触发不必要的重试。

---

四、智能感知的多维度增强

以下能力在之前版本中已有基础，v0.1.4 做了系统性增强，让它们更精准、更紧密地协同工作。

知识图谱上下文注入

Agent 执行器现在会查询知识图谱，获取与任务目标相关的实体，作为系统提示词的一个独立区域注入。而且这个注入不是只在任务开始时做一次——每轮 Agent 执行前都会刷新，确保 SA 干预后的新知识立即可见。

Hyperspace 语义搜索增强

ProactiveEngine 的经验查询以前依赖 L0 标签匹配和子串搜索。现在优先通过 HyperspaceStore 进行嵌入向量语义搜索，配置时间衰减 λ=0.5。Hyperspace 不可用时优雅降级到原来的标签匹配——不会崩，只是精度略降。

技能图谱的冷热分离

技能图谱新增了 LLRU（Least Recently Used）冷归档机制：长期未使用的技能自动序列化为 JSON-LD 写入 L0，过期技能被标记为需要重新索引，会话级临时技能被排除在冷归档之外。每次技能注册、更新、删除都会记录到时间线存储，使技能图谱的演化历史可追溯。

工作区监控器集成因果引擎

文件创建、修改、删除事件会自动记录 CausalObservation，PerceptionEntry 优先级提升。每个任务执行前会自动创建工作区快照，配合目标文件优先注入——Agent 在执行任务时总能拿到最新的文件状态。

---

五、可靠性修复

v0.1.4 修复了几个在特定边界条件下才会触发的问题，让系统更加稳定：

• 预检阶段崩溃：TL 未能匹配技能时不再导致工作流崩溃，而是优雅降级至 L0 执行，保留完整 trace 信息。
• PA 智能体创建失败：补全了 PA 创建上下文中的缺失字段，确保 PauseOnError 路径完整。
• L0 降级执行无输出：Metrics 不可用时提供默认 metrics，确保降级路径始终产出可读响应。
• TL Pend 始终为 0：修复了 TL 聚合中待办数计算错误，SA 不再会因误判而提前终止任务。
• HNSW 并发搜索的数据竞争：visited_gen 改为原子操作，使用 Relaxed 内存序，既保证并发安全又不牺牲性能。

---

六、v0.1.4 的核心叙事

Gliding Horse 从早期版本就建立了“执行 → 感知 → 学习 → 自我修正”的能力框架。v0.1.4 的核心叙事是：把这个框架内部的连接点逐一打通。

执行 (PDCA) → 审计 (5W2H) → 感知 (ProactiveEngine + Hyperspace) → 干预 (SA Intervention) → 修复 (RootCause)

时间感知的加入，让每一个环节都有了“时间感”；审计闭环的形成，让每一次执行都能自动接受维度级审查；SA 模块拆分和 bug 修复，让整个系统的稳定性和可维护性上了一个台阶。

这不是一个“从无到有”的版本，而是一个**“从有到精”**的版本。它让 Gliding Horse 已有的智能体系运转得更加流畅、更加可靠。

---

七、写在最后

Gliding Horse 从第一天起就在回答一个问题：如何让 AI Agent 从“聪明但散漫”变成“可靠且可依赖”。

v0.1.4 让这个答案更完整了一点。如果你对 Agent 操作系统、Rust 系统工程、或者知识图谱与因果推理的结合感兴趣，欢迎来 GitHub 看看：

👉 https://github.com/doiito/gliding_horse

项目还在快速迭代中，文档和示例正在持续补全。如果你愿意一起探索 Agent OS 的边界，star 和 issue 都是最好的支持。