拼图完成聊聊流马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 OSSA调度器收到重构认证系统这个任务先提取 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 / TypeScriptRust记忆滑动窗口 简单向量检索L0-L3 四层记忆 MESI 一致性数据模型字符串/JSONJSON-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敬请期待。