从“提示词玩具”到“认知操作系统”：Gliding Horse 如何重新定义 AI Agent

几个月前，我在做一个多 Agent 协作的软件工程实验时，被市面上的 AI 编码工具折磨得够呛。Claude Code 聊了 20 轮忘了第 3 轮的约定，Codex CLI 在多个任务间切换时状态全丢，OpenClaw 的 Skill 管理一多就变成灾难……这些工具都很强，但都像“聪明但散漫的实习生”——你需要时刻盯着，关键事情还得自己把关。

于是我决定自己动手。不是写一个 Prompt 模板或编排脚本，而是从零构建一个 AI Agent 操作系统。它叫 Gliding Horse（流马），全部用 Rust 写成，内核级硬约束，图数据库当大脑，JSON‑LD 当语言。

今天我就把它的核心设计扒开给你看，以及它和 Claude Code、OpenAI Codex、OpenClaw、Hermes 这些当红工具的本质区别到底在哪。

---

一、与市面上 Agent 的基因差异

先把结论放在最前面：Gliding Horse 与 Claude Code、Codex CLI、OpenClaw、Hermes 等工具不在同一个品类。

维度	Claude Code	Codex CLI	OpenClaw	Hermes	Gliding Horse
定位	编码助手（Agent Runtime）	终端 AI Agent	插件化 Agent 网关	自进化个人 Agent 框架（常驻+消息平台+跨会话）	Agent 操作系统
语言	TypeScript	Python	Node.ts（6452+ TS）	Python 3.11+ 主业务 + Node.js 工具链/Electron	Rust
记忆	会话文件 + MEMORY.md 自动记忆 + AutoDream 跨会话巩固	会话内上下文 + AGENTS.md 注入（偏薄）	插件内部状态 + ~/.openclaw 本地	SQLite FTS5 会话 + 策展 MD + Honcho 可插拔 6 provider	L0-L3 四层图记忆 + MESI 一致性
数据模型	文本流 + 工具 JSON	文本/JSON	JSON + WS-RPC Schema	JSON + SQLite + Markdown(Skill)	JSON-LD 语义图 + IRI 统一地址总线
安全约束	Prompt 软约束 + Permission Mode + Hooks	macOS sandbox-exec + TOML 审批 + Prompt	自托管 + 插件权限（配置级）	凭据池轮换 + 保护目录 + secret 扫描 + 按钮审批(fail-closed)	系统调用门 + ToolGuard 硬拦截 + SHACL 契约
多 Agent	Subagent 隔离（.claude/agents/ YAML）	Subagent 隔离（线程+沙箱，max_threads=6）	Skills 间接派 + SOUL.md 人格	delegate_tool 委托 + batch_runner 并行 + cron	SA 动态编排 + L2 共享黑板 + 态势感知
知识管理	CLAUDE.md + MEMORY.md + skills（被动）	AGENTS.md + codex.md	Skills 插件（73 官方+52 内置）	自进化 Skill 闭环（agentskills.io，~/.hermes/skills/）	技能图谱 + 知识图谱 + 自进化 Batch Agent
质量保障	人工审查	人工审查	无	无	阶段门禁 + 自工程完结 + 根因引擎

简单说：Claude Code、Codex CLI 是“AI 编码工具”，Gliding Horse 是“运行这些 AI 编码工具的操作系统”。 前者负责聪明，后者负责让聪明变得可靠。

---

二、Gliding Horse 的核心架构

Gliding Horse 的核心理念非常简单：把 LLM 当成 CPU，给它配上缓存、内存、文件系统、权限管理和进程调度。

双核心引擎

调度指令 / 上下文需求

基础设施

工具系统
ToolExecutor / MCP 集成
结果路由 / 微工具生成

质量门禁
SyscallGate 三层校验
ToolGuard 拦截
StageGate + SHACL

事件总线
TypeMask 位图路由
Agent 间通信

知识沉淀

技能图谱
JSON‑LD 技能网络
MOC 导航 / 渐进披露

知识图谱
实体 / 关系 / 代码AST

知识-技能桥接
实体 ↔ 技能关联

后台整理 Agent (8个)
技能合并 / 实体解析
失败挖掘 / 记忆压缩

记忆系统

L2 黑板
Oxigraph 内存图
多 Agent 共享
Agent 态势 + 资源锁

L3 投影引擎
SPARQL CONSTRUCT
按需加载子图

L0 持久化
Oxigraph + sled
全量记忆 + JSON‑LD

MESI 缓存一致性协议

感知系统

5W2H 解析器
态势感知
健康监控
模式识别
冲突检测
工作区文件监控

接口层

用户 / 工作流引擎

MCP 适配器
外部工具接入

Agent 编排引擎
SA 调度器 + 动态PDCA
角色工厂 PA/DA/CA/AA

上下文管理引擎
L1窗口组装
摘要/IRI注入
Token预算控制

架构的核心思想是：编排器决定“谁在什么时候干什么”，上下文引擎决定“LLM 看到什么”，而其他所有模块——感知、记忆、知识、工具、质量——都是为这两个核心供血的循环系统。

---

三、七大“人无我有”的亮点设计

亮点一：CPU 缓存式四层记忆

传统 Agent 的记忆是“全量塞进上下文，超出就截断”。Gliding Horse 则直接抄袭了 CPU 的多级缓存架构：

• L1（上下文窗口）：仅保留摘要 + IRI 指针，Token 恒定。
• L2（共享黑板）：多 Agent 共享的 Oxigraph 内存图，MESI 协议保证并发一致性。
• L3（投影引擎）：按需从 L0 抓取子图，像 MMU 一样换页。
• L0（持久化）：Oxigraph 持久化 + sled + Hyperspace 双空间向量引擎。

效果：聊了 50 轮，上下文只有 50 条摘要，但任意历史细节都可以通过 IRI 秒级调取。Token 消耗从 O(n) 降为 O(1)。

亮点二：JSON‑LD 统一语义总线

Gliding Horse 中没有任何“字符串数据”——所有任务、技能、记忆、设计文档、审计日志全是带 @id 的 JSON‑LD 节点。

• 鸭子类型：一个 Skill 的参数叫 input_file，另一个叫 source_url，通过 @context 自动映射到同一个语义 IRI，零成本对接。
• 自动去重：两个 Agent 写入同一 IRI 的数据在图数据库中自动合并。
• Token 捏合：同一份图数据可按需全展开或仅返回 IRI 引用，精细控制上下文大小。

亮点三：硬约束质量门禁

Gliding Horse 不相信 Prompt 里的“你必须”“你应该”。它用系统调用门（Syscall Gate）做三层硬拦截：

1. JSON Schema 校验：参数格式不合规直接驳回。
2. Ed25519 签名验证：被篡改过的 Skill 直接拒绝加载。
3. 角色白名单：PA 只能读，DA 可读写，CA 可审计。

工具调用时还有 ToolGuard 做前置注入和后置校验，发现敏感文件读取直接 Abort 并发送纠正消息。阶段流转时 SHACL 契约校验产出物，不合格直接打回。

这套机制借鉴了丰田的“自工程完结”——不接收缺陷、不制造缺陷、不流出缺陷。

亮点四：动态 PDCA 编排

Gliding Horse 的 SA 调度器不是一个静态 DAG 引擎。它会分析任务 5W2H，动态决定执行拓扑：

• 简单查询 → 只派一个 DA
• 标准分析 → PA → DA → CA
• 复杂项目 → PA → 三个 DA 并行 → CA → AA
• 探索研究 → DA ↔ CA 循环直到收敛

这不是人编的 YAML，是 SA 实时推理的结果。每个 Agent 的提示词动态生成，Skill 按需从知识图谱加载。

亮点五：技能图谱 + 知识图谱桥接

Skill 不再是 Markdown 文件，而是 JSON‑LD 节点组成的可遍历网络，包含 6 种语义链接类型（前置依赖、组合、关联、替代、扩展、泛化）。MOC（内容地图）节点提供导航入口。

知识图谱存实体和关系，桥接层连接“知识实体”和“技能”。Agent 调用一个技能时，可以顺藤摸瓜获取该技能相关的历史经验、已知失败模式、适用场景。

亮点六：上下文 Token 经济学

Gliding Horse 的上下文管理是一套纵深防御体系：

• 工具结果 IRI 化：大工具结果自动存档到 L0，上下文只保留摘要 + IRI + 微工具，缩减 98%+。
• 跨轮摘要引用化：截断时不是一句“之前已执行 5 轮”，而是结构化列出每轮的关键动作和 IRI 引用。
• 语义淘汰：淘汰低相关度条目时基于向量相似度计算，不误删关键信息。

亮点七：后台自进化与 Batch Agent

Gliding Horse 内置 8 个“保洁阿姨”——Batch Agent，定时做技能合并、实体解析、失败模式挖掘、记忆压缩、模板效果分析。系统越用越聪明，不是因为 LLM 变强了，而是因为知识图谱在持续自我优化。

---

四、一个真实的开发场景

在开发 Gliding Horse 的“行为工程系统”时，我只给了 SA 一句话：“实现一个 RootCauseEngine，当 Agent 执行出错时自动进行 5 级回溯追踪。”

SA 自己分析了 5W2H，决定走 PA → DA → CA。PA 去技能图谱里找到相关的 Skill，生成了执行计划。DA 写代码时，工作区监控系统显示依赖文件都是 read_fresh。CA 发现 trace_backward() 缺少置信度阈值检查，打回。DA 修正后重新提交，CA 通过。AA 把“几何平均比算术平均更能防止单项高分掩盖薄弱环节”作为经验碎片写入知识图谱。

整个过程中，我只给了起始指令。规划、执行、检查、修正、归档全是系统自己完成的。

---

五、Gliding Horse 不是谁的替代品

它不是要替代 Claude Code 或 Codex CLI。相反，它可以成为运行这些工具的底层平台——把它们的聪明才智装进一套有记忆、有约束、有质量保障的工程体系里。

Claude Code 的 Workflow 是一个可复用的命令模板。Gliding Horse 的 PDCA 是实时推理的认知调度器。

Codex CLI 的 Subagent 隔离执行。Gliding Horse 的 Subagent 通过 L2 黑板实时同步状态，边执行边协调。

OpenClaw 的 Skills 是插件配置。Gliding Horse 的 Skill 是语义网络节点，可遍历、可发现、可进化。

Hermes 的模块化是代码级组合。Gliding Horse 的模块化是操作系统的分层架构。