一、SA 模块拆分：让“大脑”结构更清晰
在之前的版本中，SA（Supervisor Agent）的所有逻辑集中在一个庞大的文件里。v0.1.4 把它按生命周期阶段拆分为 8 个独立模块：
SA 模块拆分 (v0.1.4)
types.rs
核心类型定义
planning.rs
自我诊断 + 规划策略
execution.rs
执行引擎
intervention.rs
运行时干预决策
process.rs
完整流程编排
agent.rs
生命周期管理
stats.rs
统计指标
actions.rs
高层动作封装
每个模块职责单一，通过 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 {
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 {
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 把它升级为完整的维度级审计子系统。
Failed
Warning
Failed
Failed
Failed
任务完成
audit_dimensions()
What 维度
任务是否完成 + 是否有输出
Why 维度
成功标准匹配率
Who/When/Where
边界检查
How/HowMuch
一致性验证
CausalEngine
记录 CausalObservation
降级通过
RootCauseEngine
自动根因分析
每个维度的审计逻辑独立：
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 已有的智能体系运转得更加流畅、更加可靠。
