一句话省流

> 流马（Gliding Horse）是一个用Rust构建的AI Agent操作系统，核心理念是"相信AI，但用代码把它铐起来"。它不依赖Prompt Engineering或模型自律，而是通过PDCA循环调度、JSON-LD语义总线、CPU缓存式分层记忆、以及代码级的系统调用门，在运行时硬性约束Agent行为。适合长周期软件工程、多Agent协作、企业级合规场景——但很重，不适合"查个天气"这类轻量任务。

---

一、费曼式核心：为什么Agent需要"操作系统"而不是"框架"？

先讲一个类比。

现在的AI Agent世界是这样的：你有一堆聪明的实习生（LLM），你给他们写提示词（Prompt），告诉他们"你要先搜索、再分析、再写报告"。然后你祈祷他们按步骤执行，不要偷懒、不要跑偏、不要擅自删掉生产数据库。

这相当于没有操作系统的裸机编程——每个程序直接操作硬件，没有内存保护、没有权限隔离、没有进程调度。一个野指针就能让整个系统崩溃。

流马（Gliding Horse）说的是：Agent也需要操作系统。

不是"框架"——框架是可选的库，你可以不用。操作系统是底层基础设施，Agent跑在里面，想违规也违规不了。

命名来自三国时期诸葛亮的"木牛流马"——一种能在险峻山路上自动运输粮草的机械装置。作者doiito的比喻很精准：木牛流马不是更聪明的挑夫，而是一套 harness（马具/Harness）——它约束、引导、保护运输过程，让普通人也能安全地利用机械力。

流马对AI Agent做的，就是同样的事：不指望Agent自觉，而是用工程手段把它 harness 起来。

---

二、五大角色：PDCA不是口号，是硬编码的调度器

流马的核心调度基于PDCA循环（Plan-Do-Check-Act），但不是人类项目管理那种"开会说说"的PDCA，而是代码级硬实现的五个Agent角色：

角色	缩写	职能	类比
调度者	SA (Scheduler Agent)	接收任务、分析5W2H元数据、决定复杂度级别、分派子任务	项目经理
计划者	PA (Planner Agent)	查询技能图谱、生成执行计划、分配资源	架构师
执行者	DA (Doer Agent)	实际干活：写代码、调API、生成文档	程序员
检查者	CA (Checker Agent)	语义审计：不是"有没有"，而是"对不对"	QA/审计
决策者	AA (Arbiter Agent)	最终拍板：通过、打回、升级、终止	CTO/决策者

关键设计：每个角色是独立的Agent实例，有各自的系统提示词、上下文窗口、工具权限。DA不能跳过CA直接提交结果，就像程序员不能直接合并代码到主分支。

---

三、七级复杂度：从"即时回答"到"跨月工程"

流马最聪明的设计之一是动态复杂度分级。SA收到任务后，根据5W2H元数据自动判断该走哪一级：

级别	名称	场景	PDCA模式
L0	即时	"Rust的borrow checker是什么"	SA → DA，跳过Plan和Check
L1	简单	"写个斐波那契函数"	SA → PA → DA
L2	标准	"实现JWT认证中间件"	完整PDCA，单Agent
L3	复杂	"重构用户系统"	完整PDCA，多Agent并行
L4	探索	"调研新的认证方案"	多策略并行，收集证据后决策
L5	递归	"从零构建微服务"	子任务各自独立PDCA
L6	紧急	"生产环境挂了，快修"	跳过Plan，直接Do，事后补Check

5W2H如何决定级别？

What模糊 + Why不明确 → L4（探索型，多策略并行）
What明确 + How有现成Skill → L2（标准任务，走完整PDCA）
When="立即" + What="修复Bug" → L6（紧急模式，跳过Plan）
How步骤超过10个 → L5（递归，子任务独立PDCA）

这不是魔法，是结构化的力量。把一个模糊的自然语言任务，拆成七个维度的结构化卡片，系统就能自动判断执行策略。

---

四、四层记忆系统：CPU缓存的启示

流马的第二个硬货是分层记忆系统，直接借鉴了CPU缓存架构（L0-L3 + MESI一致性协议）。

层级	技术	作用	类比
L0	Sled + Qdrant	持久化存储（磁盘级）	硬盘
L1	上下文窗口	当前对话/任务上下文	CPU寄存器
L2	Oxigraph（内存RDF图）	实时共享黑板，所有Agent读写	L1缓存
L3	SPARQL投影引擎	从L0/L2按需加载子图到L1	L2缓存

MESI协议落地：多Agent并行时，DA-1修改了一个模块的接口，DA-2立刻收到Invalidate信号，重新加载最新版本。这解决了多Agent共享状态的经典难题——没有MESI，两个Agent会在不一致的记忆上各自推理，结果必然冲突。

智能预取：L3投影引擎根据当前任务自动从L0拉取相关子图。比如DA在实现JWT认证时，L3自动把"entity:用户表"、"entity:权限系统"的关联实体注入上下文。论文声称这能把感知延迟降低90%。

---

五、JSON-LD语义总线：为什么不用JSON？

流马的所有数据交换都用JSON-LD 1.1，不是普通JSON。

为什么？因为普通JSON没有语义。

// 普通JSON：field name是约定，易冲突
{
  "name": "JWT认证",
  "type": "task"
}

// JSON-LD：每个field有IRI（全局唯一标识符）
{
  "@context": "https://glidinghorse.org/schema/v1",
  "@id": "task:jwt-auth-001",
  "@type": "gh:Task",
  "gh:name": "JWT认证",
  "gh:status": "in-progress"
}

三个核心优势： 1. @context duck-typing：不同技能定义的"name"不会冲突，因为每个有独立命名空间 2. @id零成本合并：两个Agent各自提到"entity:JWT"，系统自动知道是同一个实体 3. @graph命名图：并行写入不冲突，每个Agent在自己的命名图里写，事后合并

这让流马的所有子系统（技能、记忆、任务、代码知识）共享同一个Oxigraph RDF存储，通过SPARQL做跨子系统查询。代码AST被tree-sitter解析后自动转成RDF三元组，链接进同一个图。

---

六、系统调用门 + ToolGuard：AI想做恶也做不了

这是流马最硬核的部分，也是和现有Agent框架最根本的区别。

现有框架的安全模型： > "请Agent不要删除生产数据库。如果你删了，我会在日志里看到。"

流马的安全模型： > "Agent根本调用不了删除数据库的工具。即使它想，系统调用门会拒绝。"

三层硬校验

层级	机制	作用
调用前	参数合法性校验 + 签名验证 + 角色权限检查	DA想删文件？白名单里没有，拒绝
调用后	ToolGuard扫描返回结果	DA返回了异常内容（如敏感数据泄露）？拦截并纠正
运行时	系统调用门（Syscall Gate）	所有工具调用必须经过硬编码的权限矩阵

类比：这是从"让用户承诺不闯红灯"到"在路口装红绿灯+摄像头+罚款"的区别。Prompt里写"不要作恶"是软约束；代码级权限检查是硬约束。

---

七、质量门禁：SHACL契约 + 5W2H维度审计

每个阶段流转（如PRD → 设计文档 → 代码）必须通过质量门禁（Stage Gate）。

门禁加载SHACL契约（W3C标准的形状约束语言），硬性检查产出物：

PRD必须有功能模块定义、系统参与者列表
设计文档必须有架构图、对PRD的追溯链接
代码必须通过ToolGuard扫描

CA的5W2H维度级审计：

What/Why失败 → 重新分析
How/Where失败 → 重新规划
When/HowMuch失败 → 条件通过（可降级处理）

不再是黑盒的"PASS/FAIL"，而是精确到维度的反馈。

---

八、感知引擎：在失败发生之前抓住它

10个执行触发器，60秒异常去重：

截止时间违规
Token预算超支（>80%）
角色错配（DA干PA的活）
环境冲突
结果质量异常

自动升级到人类（Andon绳机制——来自丰田生产系统）。

---

九、联邦架构：Center + Edge

VS Code Plugin (TypeScript)
        ↕ WebSocket/REST
Edge Daemon (Rust + axum)
  - Agent Core (SupervisorAgent · DoAgent · LLM Client)
  - Docker Sandbox
  - Local Store (sled)
        ↕ gRPC + REST
Center (Go + Gin + Temporal)
  - Workflow Orchestrator
  - Agent Manager
  - Executors (req → design → coding → review → test → cicd → deploy)
  - SQLite Store

Center：Go写，负责工作流编排（Temporal）、项目管理、Agent注册、图同步
Edge：Rust写，本地LLM执行、Docker沙箱、VS Code桥接
VS Code插件：开发者UI，实时Agent协作

这个设计意味着：你可以在公司内部署一个Center，每个开发者的笔记本跑一个Edge，形成联邦式多Agent网络。

---

十、技能图谱：自演化的认知网络

7500+行代码的动态技能网络，6种语义链接：

Prerequisite（前置依赖）
Composition（组合）
Related（相关）
...

AA在每个任务后创建知识片段和新链接。/learn和/reduce机制实现自主技能获取。

这意味着：系统用得越久，技能图谱越丰富。下一次遇到类似任务，PA能更快生成计划。

---

十一、诚实边界：流马不适合什么？

场景	适合？	原因
长周期软件工程（需求→设计→编码→测试→部署）	✅ 非常适合	完整PDCA + 质量门禁 + 审计链
多Agent协作（规划者+执行者+检查者）	✅ 非常适合	角色分离 + MESI记忆一致性
企业级合规（需完整审计链）	✅ 非常适合	JSON-LD全链路可追溯
知识密集型任务（需积累历史经验）	✅ 适合	技能图谱自演化
写个周报、查个天气、单轮问答	❌ 不适合	杀鸡用牛刀，启动成本太高
需要低延迟的简单API调用	❌ 不适合	Agent ReAct轮次1-5秒
快速原型验证	⚠️ 较重	需要Rust+Go+Docker+Temporal全栈

性能指标：

L2节点写入：~2ms，500 ops/sec
L3 SPARQL投影：~15ms，66 ops/sec
Agent ReAct轮次：1-5秒
空闲内存：~200MB

---

十二、费曼式总结：流马的本质是什么？

流马不是"又一个Agent框架"。它是Agent的基础设施——从"框架层"下沉到了"操作系统层"。

现有框架（LangChain、AutoGen、CrewAI）做的是：给Agent提供工具、定义工作流、写提示词。但Agent仍然是一个"自由个体"——它可以跳过步骤、可以调用不该调用的工具、可以在上下文里编造记忆。

流马做的是：给Agent建一个监狱，但这是一个舒适的、功能齐全的监狱。

Agent想跳过Plan直接Do？PDCA调度器不允许。
Agent想访问敏感文件？系统调用门拒绝。
Agent想删掉生产数据库？ToolGuard拦截。
Agent之间记忆不一致？MESI协议保证。
Agent想胡说八道？CA做语义审计。

这不是不信任AI，而是工程上的正确选择。正如作者doiito说的：

> "相信程序员，但验证他的代码。AI Agent时代，这句话应该改成：相信AI，但用代码把它铐起来。"

流马的真正价值不在于某个单独的技术（PDCA、JSON-LD、MESI都有人做过），而在于把这些技术整合成一个完整的可信执行环境。它回答了一个很少有人认真回答的问题：

> 当AI Agent开始自主执行长周期、多步骤、高风险任务时，我们用什么保证它不会搞砸？

流马的答案是：不是更好的Prompt，不是更强的模型，而是更硬的约束。

---

附录：快速体验

轻量版：Gliding Code（终端AI助手）

零依赖，下载即用（11-14MB）：

# Linux/macOS
tar xzf glidingcode-x86_64-unknown-linux-musl.tar.gz
export DEEPSEEK_API_KEY="sk-..."
./glidingcode "Explain how Rust's borrow checker works"

完整版：Software Engineering Team

需要 Rust 1.94+、Go 1.24+、Docker、Temporal Server。

git clone https://github.com/doiito/gliding_horse.git
cd gliding_horse/apps/software_engineering_team

# 启动Center
cd center
go run ./cmd/server/...  # :8080
go run ./cmd/worker/...  # Temporal worker

# 启动Edge
cd edge/daemon
cargo run -- daemon start  # :7890

---

#流马 #GlidingHorse #AIAgent #操作系统 #Rust #PDCA #知识图谱 #JSON-LD #可信AI #多智能体 #系统调用门 #ToolGuard #企业级Agent