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

一、SA 模块拆分让“大脑”结构更清晰在之前的版本中SASupervisor 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 AwarenessCurrent time: 2026-07-11 14:30:00 UTCTask started at: 2026-07-11 14:00:00ZElapsed time: 30m 0sOlder information may be less relevant than recent informationLLM 在每次生成时都能清晰感知时间流逝做出更符合时效性的判断。使用会话创建时间而非当前时间确保检查点恢复后时间线一致。三、5W2H 审计从数据容器升级为闭环诊断5W2H 一直是 Gliding Horse 的任务元数据骨架。之前它是一个结构化的数据容器v0.1.4 把它升级为完整的维度级审计子系统。FailedWarningFailedFailedFailed任务完成audit_dimensions()What 维度任务是否完成 是否有输出Why 维度成功标准匹配率Who/When/Where边界检查How/HowMuch一致性验证CausalEngine记录 CausalObservation降级通过RootCauseEngine自动根因分析每个维度的审计逻辑独立What任务是否完成 是否有输出 → Pass/FailWhy成功标准匹配率 ≥80% Pass≥50% Warning50% FailWho/When/Where/How/HowMuch边界检查与一致性验证关键的增强在于Failed 维度会自动通过 CausalObservation 记录到因果引擎驱动根因分析。这不是“审计完就完了”而是把审计、感知、根因分析串成了一个闭环。Warning 状态提供了中间态避免非关键失败触发不必要的重试。四、智能感知的多维度增强以下能力在之前版本中已有基础v0.1.4 做了系统性增强让它们更精准、更紧密地协同工作。知识图谱上下文注入Agent 执行器现在会查询知识图谱获取与任务目标相关的实体作为系统提示词的一个独立区域注入。而且这个注入不是只在任务开始时做一次——每轮 Agent 执行前都会刷新确保 SA 干预后的新知识立即可见。Hyperspace 语义搜索增强ProactiveEngine 的经验查询以前依赖 L0 标签匹配和子串搜索。现在优先通过 HyperspaceStore 进行嵌入向量语义搜索配置时间衰减 λ0.5。Hyperspace 不可用时优雅降级到原来的标签匹配——不会崩只是精度略降。技能图谱的冷热分离技能图谱新增了 LLRULeast Recently Used冷归档机制长期未使用的技能自动序列化为 JSON-LD 写入 L0过期技能被标记为需要重新索引会话级临时技能被排除在冷归档之外。每次技能注册、更新、删除都会记录到时间线存储使技能图谱的演化历史可追溯。工作区监控器集成因果引擎文件创建、修改、删除事件会自动记录 CausalObservationPerceptionEntry 优先级提升。每个任务执行前会自动创建工作区快照配合目标文件优先注入——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 已有的智能体系运转得更加流畅、更加可靠。