Gliding Horse Agent OS 介绍：Rust 构建的工业级 AI Agent 操作系统

Mon, 29 Jun 2026 10:00:00 +0800

项目概览

Gliding Horse Agent OS 是由 doiito 在 GitHub 上开源的 Rust 编写的工业级 AI Agent 操作系统。项目名称源自三国时期诸葛亮发明的"木牛流马"——一种能在险峻山路上自主运输粮草的机械装置,象征"以基础设施驾驭集体智能":不仅构建 Agent,更构建让多个 Agent 协同调度、自主演化、可审计的底层系统。

仓库:doiito/gliding_horse
许可:MIT
当前版本:v0.1.2.preview(2026-06 发布)
语言占比:Rust ≈ 80.9%
定位:面向企业级 AI Agent 系统的多智能体编排框架,提供完整的中文文档

“We don’t just build agents; we build the infrastructure that harnesses their collective intelligence.”

设计哲学

借鉴"木牛流马"的范式:古代机械并不是替换人力,而是把人从机械性劳动中解放出来。Gliding Horse 同样不追求把 Agent 框死在某种刚性流程里,而是提供一套自适应任务复杂度的编排基础设施——从一次性的即时查询,到多周的长流程项目,同一套引擎都能覆盖。

核心理念可以概括为一句话:

“灵活编排适应任务复杂度,而非刚性框架强迫任务就范”(The wise adapt their methods to circumstances, just as water shapes its course according to the ground over which it flows.)

整体架构

仓库分为多个 Workspace,核心层次按职能拆分:

层级	目录	技术栈	职责
核心调度	`crates/` · `src/`	Rust 2021 · PDCA · 5W2H · EventBus	Agent 编排与生命周期
应用层	`apps/software_engineering_team/`	Center (Go+Temporal) + Edge (Rust+axum) + VS Code Plugin	完整 SDLC 联邦
终端助手	`crates/gliding_code/`	Rust (musl 静态二进制)	零依赖命令行 AI 助手
技能定义	`skills/`	RDF / YAML	可插拔的 Skill 描述
数据契约	`proto/` · `workflow.jsonld`	gRPC Proto · JSON-LD 1.1	跨进程/跨语言接口
文档	`docs/`	Markdown (中英双语)	设计文档与设计哲学

核心机制详解

1. 广义 PDCA —— 7 级自适应执行

PDCA(Plan-Do-Check-Act)是经典的戴明环。Gliding Horse 将其广义化为 7 级复杂度,通过任务的 5W2H 元数据动态选择:

级别	含义	触发场景
L0	即时响应	简单问答、不需要工具
L1	单步工具调用	单次搜索、单次代码执行
L2	多步推理	多轮 ReAct,需要思考
L3	子任务分解	任务拆解后并行执行
L4	长链 Pipeline	多阶段流水线
L5	递归 PDCA	任务作为其他任务的子节点
L6	应急模式	异常升级、人工接管

一个引擎覆盖从 L0 的即时查询到 L6 的应急处置——这是 Gliding Horse 区别于其他编排框架的关键:不要求开发者为不同复杂度写不同框架。

2. 5W2H 本体级审计 —— 告别黑盒 PASS/FAIL

传统 Agent 评测只给一个"通过/不通过"的二值信号。Gliding Horse 对每一次执行结果按 5W2H 七个维度独立审计:

维度	失败时动作
What(产物对不对)	重新生成
Why(决策理由是否充分)	重新分析
How(方法是否合理)	重新规划
Where(执行环境/上下文是否合适)	重新规划
When(时序/截止日期)	有条件放行
HowMuch(资源消耗是否在预算内)	有条件放行
(附加)Who/Which	角色/工具匹配

这让精确回滚成为可能——你可以精准定位"哪一维度出问题",而不是把整个流程推倒重做。

3. CPU 缓存启发的 4 层记忆 + MESI 一致性

Gliding Horse 最具创新性的设计之一是把 CPU 缓存架构搬到多 Agent 记忆系统中:

层	类比	技术实现	性能指标
L0	寄存器/缓存	`Sled` KV + `Qdrant` 向量库	读取 ~1ms · 1000 ops/sec
L1	L1 缓存	上下文窗口 / 最近对话	由 LLM 决定
L2	L2 缓存	`Oxigraph` RDF 三元组存储	写入 ~2ms · 500 ops/sec
L3	L3 缓存 / 内存	`SPARQL 1.1` 投影视图	查询 ~15ms · 66 ops/sec

更关键的是引入了 CPU 的 MESI 缓存一致性协议(Modified / Exclusive / Shared / Invalid)的记忆改造版,解决多 Agent 共享记忆时的不一致问题。配合扩散激活式预取(Spreading Activation),常用记忆提前加载,感知延迟下降约 90%。

4. JSON-LD 1.1 通用数据总线

Agent 之间共享数据时,字段命名冲突是隐形大坑。Gliding Horse 用 JSON-LD 1.1 作为跨子系统、跨语言的通用数据契约:

@context —— 鸭子类型,消除字段命名冲突
@id —— 零成本跨 Agent 实体合并(同一个对象在不同子系统里指向同一 @id 即视为同一对象)
@graph (Named Graphs) —— 命名图机制,允许不同子系统并行写入而不冲突

配套的 workflow.jsonld 把"工作流描述"也建模为带 @id 的实体,可以直接写入 RDF 图并被 SPARQL 查询。

5. 统一知识图谱 —— Oxigraph RDF

所有子系统(技能、记忆、任务、代码知识)共享同一个 Oxigraph RDF 存储,通过命名图隔离,通过 @id 互联:

代码 AST 由 tree-sitter 自动解析为 RDF 三元组入图
跨子系统的 SPARQL JOIN 让"代码模块 ↔ 任务 ↔ 记忆"可以一次性查询
单一 @id 保证实体在所有上下文中的身份一致

这一设计的核心收益是消除信息孤岛:跨子系统的关联不再需要额外的 ETL 管道,直接在图上做关联查询即可。

6. 自演化 Skill Graph

Skill 不是一个静态的 YAML 列表,而是一张自演化的认知网络:

约 7,500+ LOC 的动态 RDF 网络
6 种语义链接:Prerequisite(前置)、Composition(组合)、Related(相关)、Conflict(冲突)、Refine(精炼)、Deprecate(废弃)
任务后学习:/learn 机制根据执行结果创建新知识片段与新链接
去重压缩:/reduce 机制定期合并冗余节点

简单说,系统跑得越多,这张"能力地图"自动生长得越完备。

7. 主动感知引擎

不是等任务失败再处理,Gliding Horse 内置主动监控:

10 类执行触发器:截止日期、Token 预算超 80%、角色失配、环境冲突、循环检测……
60 秒异常去重窗:避免同一异常反复打扰
自动升级人工:超出 Agent 能力的异常自动升级到人介入

8. 微工具系统(Micro-Tool)

当 Agent 输出超过 8 KB 的结果时,Gliding Horse 自动把它包装为一组对话式微工具(例如 search_in_results、summarize_section)。原本 50 KB+ 难以一次性塞进上下文的结果,变成可在上下文里交互式查询的对象——极大降低 LLM 上下文压力。

9. MCP 协议接入

原生支持 Model Context Protocol,一个协议接入 GitHub、Slack、Jira 等所有 MCP 兼容服务,运行时动态发现工具,告别"每接一个外部服务就写一套对接代码"。

10. 检查点与恢复

长任务最怕崩溃丢失进度。Gliding Horse 在关键节点对会话状态打快照:

崩溃后完整恢复到最近检查点,无需重头开始
支持事后回放调试(post-mortem replay)
支撑小时级甚至天级的 Agent 长任务

Center + Edge 联邦架构

这是一个独立于以上机制之上的部署拓扑,值得单独说。

VS Code Plugin (TypeScript)
 │ WebSocket / REST
 ▼
 Edge Daemon (Rust · axum)
 ├─ API Server (ws / chat / health)
 ├─ Agent Core (SupervisorAgent · DoAgent · LLM Client)
 ├─ Docker Sandbox (安全执行: 编译 / 测试)
 └─ Graph Layer (本地 Sled + Delta Sync)
 │ gRPC + REST
 ▼
 Center (Go · Gin)
 ├─ HTTP API (/api/v1/* · /ws)
 ├─ Temporal Workflow (编排引擎)
 ├─ Agent Manager (注册 · 心跳 · 派发)
 ├─ Executors (req → design → coding → review → test → cicd → deploy)
 └─ Store (SQLite · gRPC Client · Graph Sync)

角色	语言 / 框架	核心职责
Center	Go + Gin + Temporal	全局工作流编排、项目生命周期、Agent 注册中心、图谱同步
Edge	Rust + axum	本地 LLM 执行、Docker 沙箱、VS Code WebSocket 桥
VS Code Plugin	TypeScript	Chat Panel + Graph View + Task Panel,实时呈现 Agent 协作

设计哲学:Center 负责编排,Edge 负责执行,VS Code 负责感知——三者解耦,任一节点宕机不影响其他局部。

两个旗舰应用

1. Software Engineering Team

最完整的多 Agent 协作软件工程团队:

需求 → 设计 → 编码 → 评审 → 测试 → CI/CD → 部署

提供完整 Dashboard(项目总览、Agent 状态、Pipeline 进度)以及 VS Code 插件(Chat Panel / Graph View / Task Panel),让开发者可以实时看到多个 Agent 在背后协作。

这种"联邦式"设计的好处是:Center/Edge 可以独立扩展,VS Code 插件可以独立演进,核心调度引擎不必关心 UI 细节。

2. Gliding Code

零依赖终端 AI 编码助手——Gliding Horse 知识图谱与编排能力的"轻量入口":

平台	包大小	说明
Linux (x86_64, musl)	13.9 MB	完全静态链接
Linux (aarch64, musl)	12.9 MB	-
macOS (Apple Silicon)	12.1 MB	-
Windows (x86_64)	11.6 MB	-

# 下载即用,无需安装任何依赖
tar xzf glidingcode-*.tar.gz

# 设置 API Key(支持 DeepSeek 或任意 OpenAI 兼容端点)
export DEEPSEEK_API_KEY="sk-..."

# 交互式会话
./glidingcode

# 或一次性任务
./glidingcode "Explain how Rust's borrow checker works"

它的特点是把整套"知识图谱 + Agent 编排"塞进一个 13 MB 的二进制——这是 musl 全静态链接的功劳。对于想体验 Gliding Horse 但又不想搭建完整 Center/Edge 的开发者,Gliding Code 是最佳入口。

性能基线

操作	延迟	吞吐
L2 节点写入 (Oxigraph)	~2 ms	500 ops/sec
L3 SPARQL 投影	~15 ms	66 ops/sec
L0 Sled KV 读取	~1 ms	1000 ops/sec
Agent ReAct 一轮	1–5 s	0.2–1 turns/sec
空闲内存	~200 MB	随任务规模线性增长

注意:吞吐数据为仓库 README 公布的基线,实际表现取决于 LLM 调用频次与上下文长度。

上手指南

快速体验:Gliding Code(零依赖)

git clone https://github.com/doiito/gliding_horse.git
cd gliding_horse
# 在 releases 页面下载对应平台的预编译包
./glidingcode --help

完整搭建:Software Engineering Team

前置依赖:

Rust ≥ 1.94
Go ≥ 1.24
Docker
Temporal Server(本地或远端)
一个 OpenAI 兼容的 LLM API Key(DeepSeek、OpenAI、本地 vLLM 均可)

启动步骤:

# 1) 启动 Center
cd apps/software_engineering_team/center
cp center/config.yaml center/config.local.yaml
# 编辑 config.local.yaml,填入 LLM Key、Temporal 地址
go run ./cmd/server/... # API server on :8080
go run ./cmd/worker/... # Temporal worker

# 2) 启动 Edge Daemon
cd ../edge/daemon
cargo run -- daemon start # Agent daemon on :7890

# 3) 安装 VS Code 插件
code --install-extension apps/software_engineering_team/edge/vscode/

也可以直接调用 API:

curl http://localhost:8080/api/v1/projects \
 -X POST -H "Content-Type: application/json" \
 -d '{"name":"My Project","description":"Build a microservice"}'

路线图

核心 OS(持续推进):

扩展 MCP 工具生态与动态发现
多模型路由优化(成本感知调度)
知识图谱查询性能与规模优化
带版本化 Prompt 继承的模板引擎
细粒度订阅过滤的事件系统

应用层(未来):

时间	内容
Q3 2026	原生 Web 仪表板 · Python/TypeScript SDK
Q4 2026	Kubernetes Operator · 多轮对话记忆压缩 · Skill Marketplace 原型
2027	跨 Edge 节点的分布式 Agent Mesh · 多模态 Agent(视觉/音频) · 社区插件注册中心

一些深度观察

作为一份完整的概览,以下是我认为 Gliding Horse 与同类项目相比的几个显著差异点:

PDCA 7 级自适应让它对"什么算 Agent 框架"的定义更宽泛——同一套引擎既可做即时问答,又可跑周级项目,这种"弹性"是 LangChain / AutoGen 目前都没做到的。
CPU 缓存架构 + MESI 一致性是从硬件架构借来的概念,工程上不是新东西,但移植到多 Agent 记忆是很新鲜的一手;若实现得当,能极大缓解"Agent 之间互相覆盖记忆"的常见 bug。
JSON-LD 作为跨子系统数据总线使得"技能/记忆/任务/代码"得以在 RDF 图层统一——这一点与 GraphRAG 全景思路一脉相承,但走得更远。
OpenAI 兼容 API + MCP 双协议意味着开发者不强制绑定任何单一模型生态,DeepSeek、Qwen、本地 vLLM 都可以无缝接入,适合国内闭源/开源混合场景。

目前的不确定性:

项目仍处 v0.1.2.preview,生产环境稳定性未充分验证
官方 Issue 中已有用户反馈"流程太繁琐、跑半天没结果、重问又从头开始"(Issue #3),会话连续性与状态恢复仍是体验痛点
实时统计(stargazer_count / watcher_count)GitHub API 返回 null,需访问仓库页确认当前社区热度

适合谁:正在搭建多 Agent 协作平台 / 企业级 Agent 工作流 / 知识密集型 Agent 系统的团队。不适合谁:只要做一次性 prompt 调用或单 Agent RAG 的项目(用 LangChain / LlamaIndex 更轻)。

系列文章

注:Hugo 的相对路径解析对含空格目录使用 URL 编码(%20);若仍出现 broken 链接,请以博客最终渲染为准。

Rust on Zata-砸它