拼图完成！聊聊流马（Gliding Horse）到底是个什么东西
SEO摘要：流马（Gliding Horse）是一个基于 Rust 的 AI Agent 操作系统，通过五大系统（调度层、记忆层、知识层、执行层、安全层）协同工作，实现从需求分析到编码上线的全流程自动化。本文用真实场景拆解流马的运行机制，对比主流 Agent 框架的差异，并给出适用场景建议。适合关注 AI Agent 工程化落地、多 Agent 协作、企业级 AI 合规架构的开发者阅读。
这个系列写了十来篇，从 JSON-LD 到 CPU 缓存，从 Oxigraph 到丰田安灯绳，从技能图谱到硬核门禁。每篇都在讲"一个零件"，但一直没有把整辆车的图纸摊开给你看。
今天这篇，就是把所有零件拼起来，让你一眼看清：流马（Gliding Horse）到底是什么，它能做什么，它和市面上所有 AI Agent 框架的区别在哪。
一、先用一个真实场景开局
假设你有一个需求：“重构用户认证系统，从 Session 升级到 JWT。”
在传统开发流程里，这事儿大概这么干：产品经理写 PRD → 架构师出方案 → 开发写代码 → 测试测一轮 → 上线。中间任何一个环节出问题，代价往后传递，越晚发现越贵。
现在，把这件事交给流马。会发生什么？
二、流马的五大系统是如何协同的？
阶段一：需求分析（需求Agent OS）
SA（调度器）收到"重构认证系统"这个任务，先提取 5W2H 元数据，然后决定：这是个标准任务，走 PA → DA → CA 流程。
PA（计划者）去技能图谱里找相关技能——它发现了skill:rust-jwt-auth和skill:token-security，还顺着技能图谱的链接发现这两个技能都依赖skill:rust-basics。于是 PA 自动生成了执行计划。
DA（执行者）按照计划干活，产出了一份 PRD 文档。知识图谱里存着这个任务的所有实体：entity:JWT、entity:认证系统、role:后端开发…… 这些实体通过知识-技能桥接链接着相关的技能和历史经验。
DA 准备把 PRD 流转给 CA 时，阶段门禁（Stage Gate）启动了。它加载 SHACL 契约，检查这份 PRD：有没有定义功能模块？有没有列出系统参与者？所有检查通过，放行。如果有缺失，打回给 DA 重新补。
CA（检查者）做语义审计——不是检查"有没有"，而是检查"对不对"。JWT 的有效期设 24 小时合理吗？和现有系统的兼容性考虑了吗？
AA（决策者）最终拍板：PRD 合格，进入设计阶段。
整个过程，所有的思考、决策、修正，都被记录为 JSON-LD 节点，写入 L0 知识图谱。六个月后你想查"为什么当时选了 JWT 而不是 OAuth2"，顺着 IRI 一查，完整的决策链就在那里。
阶段二：系统设计（设计Agent OS）
工作流引擎把 PRD 的 IRI 传给设计 Agent OS。设计 OS 启动时，L3 投影引擎自动从 L0 拉取 PRD 的子图，注入到 L2 黑板。
设计 SA 又走了一遍 PA → DA → CA 流程，产出设计文档。技能图谱里的skill:jwt-middleware被自动发现，知识图谱里entity:认证系统的关联实体（entity:用户表、entity:权限系统）被自动注入上下文。
设计文档出炉后，同样要过阶段门禁。SHACL 契约要求设计文档必须有架构图、必须有对 PRD 的追溯链接。不合格？打回重做。
阶段三：编码实现（编码Agent OS）
设计文档的 IRI 传给编码 Agent OS。这次 SA 决定：三个模块可以并行开发，启动三个 DA 实例。
每个 DA 拿到自己的任务后，通过技能图谱发现需要的技能，通过知识图谱了解相关实体的上下文，通过MCP 协议调用外部工具（比如 GitHub 创建分支、数据库查询 Schema）。
关键来了：系统调用门在这里发挥了全部威力。每个 DA 的工具调用都要过三层硬校验——参数合不合法？签名对不对？角色有没有权限？DA 想删文件？白名单里没有，直接拒绝。DA 想访问一个不在任务范围内的敏感文件？ToolGuard在工具执行后扫描结果，发现异常立刻拦截，并向 DA 发纠正消息。
三个 DA 并行干活，写入 L2 黑板时，内存总线的 MESI 协议保证了数据一致性——DA-1 修改了某个模块的接口，DA-2 立刻收到 Invalidate 信号，重新加载最新版本。
阶段四：测试与上线
编码完成后，代码提交到 Git 仓库，CI/CD 流水线自动触发。测试 Agent OS 启动，CA 做自动化审计——不是"能不能跑"，而是"符不符合设计文档、有没有遗漏边界条件"。
所有质量事件写入知识图谱。如果有问题，SA 决定是回退到编码阶段还是打补丁。
最后，部署上线。
三、用一张表看清流马的完整架构
| 系统层 | 核心模块 | 干什么用 |
|---|---|---|
| 调度层 | SA 调度器 + 动态 PDCA | 根据任务 5W2H 自动决定执行拓扑（单兵/串行/并行/循环） |
| 记忆层 | L0-L3 四层记忆 | CPU 缓存式记忆管理，MESI 协议保证多 Agent 一致性 |
| 知识层 | 知识图谱 + 技能图谱 + 桥接 | 存"是什么"和"怎么做"，关联历史经验 |
| 执行层 | PA/DA/CA/AA 统一 AgentRunner | 动态注入提示词，按角色赋予不同能力边界 |
| 安全层 | 系统调用门 + ToolGuard + 阶段门禁 | 三层硬校验 + 运行时拦截 + SHACL 结构约束 |
| 通信层 | 事件总线 + 内存总线 | Agent 间实时通信，O(1) 位图路由 |
| 数据层 | JSON-LD + Oxigraph + Qdrant | 统一语义总线，图存储管逻辑，向量库管直觉 |
| 集成层 | MCP 协议 + Docker 沙箱 + code-server | 接入外部工具，安全隔离执行环境 |
四、流马和市面上的 Agent 框架，到底区别在哪？
| 维度 | 主流 Agent 框架 | 流马 (Gliding Horse) |
|---|---|---|
| 定位 | Agent 编排工具 / 应用框架 | Agent 操作系统 |
| 语言 | Python / TypeScript | Rust |
| 记忆 | 滑动窗口 + 简单向量检索 | L0-L3 四层记忆 + MESI 一致性 |
| 数据模型 | 字符串/JSON | JSON-LD 图数据 + IRI 地址总线 |
| 安全 | Prompt 约束（软限制） | 系统调用门 + ToolGuard（硬拦截） |
| 质量保障 | 靠人检查或事后审计 | 阶段门禁 + SHACL 契约（写入前强制校验） |
| 技能 | Markdown 文件 | JSON-LD 技能图谱，可遍历、可发现、可进化 |
| 多 Agent | 预定义流程，固定角色 | SA 动态编排，Agent 间通过黑板 + 事件总线协作 |
| 可审计 | 靠日志翻查 | 所有决策写入知识图谱，IRI 精确追溯 |
五、流马到底适合什么场景？
不适合：写个周报、帮你查个天气、单轮问答。这些轻量场景，任何 LLM 工具都能搞定，用流马是杀鸡用牛刀。
最适合：
- 长周期软件工程项目：需求→设计→编码→测试→部署，全流程自动化，每个阶段产出物都有质量门禁。
- 多 Agent 协作场景：需要多个 AI 角色（规划者、执行者、检查者、决策者）协同完成复杂任务。
- 企业级合规场景：需要完整审计链，能追溯每个决策的来源、每个操作的主体、每次校验的结果。
- 知识密集型任务：需要持续积累和复用历史经验、领域知识、技能模式的场景。
六、最后说句心里话
这个系列从"为什么选 JSON-LD"开始，写到 CPU 缓存记忆、Oxigraph 图数据库、丰田安灯绳、技能图谱、知识图谱、事件总线、硬核门禁，到今天把这幅拼图完整摊开。
我从不觉得流马是个"完美的系统"。它还缺很多文档、缺更多示例、缺社区的打磨。但它的核心设计——把 Agent 从"提示词工程"升级为"系统工程"——这个方向，我坚信是对的。
写代码的人都知道一句话：“相信程序员，但验证他的代码。”
AI Agent 时代，这句话应该改成：“相信 AI，但用代码把它铐起来。”
这就是流马在做的事。
GitHub 地址：https://github.com/doiito/gliding_horse
这个系列到此告一段落。如果你对 AI Agent 的工程化落地感兴趣，欢迎来 star、提 issue、一起搞。接下来我可能会出一系列视频，把这些概念变成可运行的 Demo，敬请期待。
