它最核心的想法其实很简单：把 LLM 的上下文窗口当成 L1 Cache，把持久化知识当成磁盘，中间用 Oxigraph 图数据库和 JSON‑LD 语义总线串联起来。这样做的好处是 多轮对话几乎不丢上下文，还巨省 Token，因为你不是把整段历史砸进 Prompt，而是给了 LLM 一把能随时打开任意一扇门的万能钥匙。如果你对 Agent 的记忆管理、技能安全或者 Rust 系统编程感兴趣，可以

Gliding Horse 通过 RelevanceTracker 双维度评分、L1 淘汰策略增强、ContextWindowManager 感知压缩和后台话题连贯性分析，构建了一套完整的上下文相关性感知与智能压缩系统。该系统解决了多轮对话中 Agent 面临的话题漂移和信息过载两大核心痛点，实现了 LLM 注意力窗口的精细化管理，使 Token 利用率提升 20-40%，话题切换响应从被动淘汰升

能力之前之后文件感知Agent 主动轮询，有盲区notify 事件驱动，毫秒级被动感知状态管理Agent 自己记“读过什么”L2 图数据库托管，read_fresh/read_stale 精确追踪文件读取每次全量读盘LRU 缓存 + 差分模式，Token 节省 60%+写入安全靠 Prompt 约束ToolGuard 硬阻断过期写入依赖感知Agent 手动分析ImportScanner 自动更新依

L2 作战地图是 Gliding Horse 多 Agent 协作的基石。只解决“看得见”还不够，必须解决“只看该看的”。通过多维索引、上下文过滤和投影引擎深度集成，Gliding Horse 的每个 Agent 终于拥有了一个干净、专注的工作空间，这或许就是 AI 协作从“草台班子”走向“专业团队”的关键一步。

传统 Agent 怎么处理多轮对话？把每轮的完整回复全塞进上下文。聊 50 轮，上下文就塞满 50 轮完整回复——Token 爆炸，LLM 还容易迷失重点。我的做法：每轮 LLM 回复后，强制它输出一个summary（摘要）。历史上下文只拼接这些摘要，不拼原始内容。历史上下文示例：第1轮摘要: 用户需要分析Q2销售数据，目的是为库存计划提供依据第2轮摘要: 确认数据源为sales_q2.csv，数

触发器：TaskEnd任务结束时（不管是成功还是失败），感知引擎会自动提取经验从任务结果中抽取场景摘要创建Experience对象，成功给 0.9 分，失败给 0.1 分打上标签（experiencetask:任务ID存入 L0 图数据库下次同类任务启动时，TaskStart 触发器会自动检索这些经验，注入给 SA。整个系统形成了一个“经验 → 检索 → 应用 → 再提取经验”的正向循环。"sce

这个系列从"为什么选 JSON-LD"开始，写到 CPU 缓存记忆、Oxigraph 图数据库、丰田安灯绳、技能图谱、知识图谱、事件总线、硬核门禁，到今天把这幅拼图完整摊开。我从不觉得流马是个"完美的系统"。它还缺很多文档、缺更多示例、缺社区的打磨。但它的核心设计——把 Agent 从"提示词工程"升级为"系统工程"——这个方向，我坚信是对的。写代码的人都知道一句话：“相信程序员，但验证他的代码。

将 HyperspaceEngine 增加到 Gliding Horse，并不是简单地替换一个向量数据库，而是为整个 Agent OS 注入一套层次化感知、边云协同、极致性能的记忆与同步基础设施。它让技能图谱真正“长”在双曲空间里，让分布式的 Agent 实例能够像生物体一样同步自己的“大脑”，也让每一次上下文检索都快如闪电。不重新发明轮子，而是将最好的轮子组装成一辆能征服任何地形的越野车。。

分析日期：2026-06-26仓库地址：https://github.com/doiito/gliding_horse最新提交：50e1acb（2026-06-26 18:30:00 “update system prompt”）分析方法：git clone 全量源码 + 逐模块代码审阅 + 作者博客交叉比对 + 编译验证。

先坦白：我选 Oxigraph，一开始是因为它太“Rust”了。Gliding Horse 整个系统都是用 Rust 写的。如果选 Neo4j，就得配 Java 环境；选 PostgreSQL 加 pgvector，又得多部署一个服务。Oxigraph 是 Rust 原生库，直接编译进二进制文件，一行全搞定。没有外部依赖，没有网络开销，没有“在我机器上能跑”的破事。但真正让我惊艳的，是它和JSON