我用 Rust 写了个 AI Agent 操作系统来写代码，现在它比我还懂我的项目

摘要：本文深入介绍了作者用 Rust 从零开发的 AI Agent 操作系统「Gliding Horse（流马）」，它通过 Agent 编排引擎、四层记忆系统、质量门禁和知识图谱，解决了传统 AI 编码助手「失忆、瞎编、偷懒、不记打」四大痛点。文章详细拆解了流马的架构设计（LLM 作为 CPU，上下文引擎作为操作系统）、五大核心问题解决方案，以及一个真实的开发示例。适合对 AI Agent 架构、Rust 开发、LLM 工程化落地感兴趣的开发者阅读。

关键字：AI Agent 操作系统, Rust AI 开发, LLM 工程化, Agent 编排引擎, 上下文管理, 知识图谱, 质量门禁, Gliding Horse, 流马, AI 编码助手替代, 多 Agent 协作, 记忆系统, Token 优化, SHACL 契约校验, 自进化 AI 工具链

我做了一个“违背祖宗”的决定——我不用 Copilot，不用 Cursor，不用 Claude Code。

不是它们不好，是它们不够好。

于是我花了半年时间，用 Rust 从零写了一个 AI Agent 操作系统，叫 Gliding Horse（流马）。它不是一个“AI 写代码工具”，它是一个能自己管理记忆、自己调度任务、自己检查质量、自己沉淀经验的工程平台。

今天就用我实际开发流马的过程，聊聊这套“自己开发的 AI 工具链”到底给我解决了什么问题。

一、我受够了什么？

在用流马之前，我用过市面上几乎所有 AI 编码助手。它们的共同问题是：

失忆：聊了 20 轮，它忘了第 3 轮我让它“用 Ed25519 做签名校验，别用 RSA”。每次都得重新强调。
瞎编：让它写个 JSON‑LD 解析器，它给我生成了一个 @context 拼错的版本。因为 LLM 训练数据里 JSON‑LD 太少了。
偷懒：让它“写完记得检查”，它满口答应，然后直接提交。因为 Prompt 里的“记得检查”是软约束，LLM 可以在概率上选择忽略。
不记打：上次踩过的坑（比如“Qdrant 的 point_id 是 u64 不是 String”），下次还会踩。因为它没有长期记忆。

本质问题：LLM 是一个无状态的、弱指令遵守的、会产生幻觉的条件概率文本生成器。它不是程序员，它是一个超级赌场——每次生成一个 Token，都在赌概率。温度调高是豪赌，温度调低是保守赌，但本质还是赌。

我需要的不只是一个“更聪明的 LLM”，而是一套能让 LLM 变得可靠的工程体系。这就是流马的设计起点。

二、流马的架构：把 LLM 当成 CPU，给它配个操作系统

流马的核心理念非常简单：把 LLM 当成 CPU，给它配上缓存、内存、文件系统、权限管理和进程调度。 在这个“操作系统”里，所有子系统最终只为两件事服务：合理编排 Agent 和生成精准、简练、高效的上下文。

概要构成图

详细组件构成图

graph TBsubgraph InterfaceLayer["接口层"]User["用户 / 工作流引擎"]IDE["IDE 插件 code-server / VS Code"]MCP["MCP 适配器 外部工具接入"]endsubgraph CoreLayer["双核心引擎"]Orchestrator["Agent 编排引擎 SA 调度器 + 动态PDCA 角色工厂 PA/DA/CA/AA"]ContextEngine["上下文管理引擎 L1窗口组装 摘要/IRI注入 Token预算控制"]Orchestrator <-->|"调度指令 / 上下文需求"| ContextEngineendsubgraph PerceptionLayer["感知系统 — 为决策和上下文提供信息"]Perception["5W2H 解析器 态势感知 健康监控 模式识别 冲突检测 工作区文件监控 (notify)"]endsubgraph MemoryLayer["记忆系统 — 让 Agent 永不丢失上下文"]L2["L2 黑板 Oxigraph 内存图 多 Agent 共享"]L3["L3 投影引擎 SPARQL CONSTRUCT 按需加载子图"]L0["L0 持久化 Oxigraph + Qdrant 全量记忆 + 向量检索"]MESI["MESI 缓存一致性协议"]endsubgraph KnowledgeLayer["知识沉淀 — 让经验可复用"]SkillGraph["技能图谱 JSON‑LD 技能网络 MOC 导航 / 渐进披露"]KnowledgeGraph["知识图谱 实体 / 关系 / 代码AST"]Bridge["知识-技能桥接 实体 ↔ 技能关联"]BatchAgents["后台整理 Agent (8个) 技能合并 / 实体解析 失败挖掘 / 记忆压缩"]endsubgraph InfrastructureLayer["基础设施 — 工具与质量保障"]Tools["工具系统 ToolExecutor / MCP 客户端 结果路由 / Token 优化"]Quality["质量门禁 SyscallGate 三层校验 ToolGuard 拦截 StageGate + SHACL 契约"]EventBus["事件总线 TypeMask 位图路由 Agent 间实时通信"]FileWatch["工作区文件监控 notify + sled 已读/未读状态跟踪"]endInterfaceLayer --> CoreLayerCoreLayer --> PerceptionLayerCoreLayer --> MemoryLayerCoreLayer --> KnowledgeLayerCoreLayer --> InfrastructureLayerPerceptionLayer --> MemoryLayerMemoryLayer --> KnowledgeLayerKnowledgeLayer --> ContextEngineInfrastructureLayer --> ContextEngineInfrastructureLayer --> Orchestrator

架构的核心思想是：编排器决定“谁在什么时候干什么”，上下文引擎决定“LLM 看到什么”，而其他所有模块——感知、记忆、知识、工具、质量——都是为这两个核心供血的循环系统。
整个系统用 Rust 写成，图数据库用 Oxigraph，向量库用 Qdrant，编译成一个静态二进制文件，没有外部依赖。

三、它给我解决了什么问题？

问题一：Token 消耗暴降，多轮对话不丢上下文

传统 Agent 把整个对话历史塞进 Prompt，Token 消耗 O(n) 增长。流马的做法是：LLM 每次输出必须带一个 summary 字段。上下文只保留摘要和 IRI 引用，完整内容存 L0 图数据库。LLM 需要细节时，用 IRI 去图里查。

比如我让它实现 JSON‑LD 的 @context 展开逻辑，聊了 50 轮。传统方式上下文早爆了，但流马的上下文里只有 50 条摘要（每条十几个 Token），完整讨论细节全在 L0 里。Token 消耗从 O(n) 变成 O(1)。

问题二：AI 不能自己瞎编

LLM 擅长生成“看起来像”的代码，但不擅长“一模一样”。流马的做法是“不信任，只校验”。系统调用门有三层硬拦截：JSON Schema 校验参数格式、Ed25519 签名验证 Skill 是否被篡改、角色白名单检查 Agent 有没有权限。CA 检查 Agent 会自动审计 DA 的产出，不合格直接打回。阶段门禁（StageGate）在阶段流转时用 SHACL 契约强检验收，不达标不放出。

问题三：上下文自动感知文件变化

AI 不知道文件在两次读取之间是否被修改，这是一个很实际的问题。流马通过工作区文件监控系统（notify + sled）实时监听文件变更。每个文件都有状态：read_fresh、read_stale、discovered_unread、written_unread。如果 Agent 试图编辑一个 read_stale 的文件，ToolGuard 直接 Abort：“这文件在外部被改了，你先 file_read 获取最新内容再改。”不是劝，是拦。这是硬约束，Agent 绕不过去。

问题四：后端代码质量靠流程保证

后端开发的错误更隐蔽——AI 帮你设计数据库 Schema 少了个关键索引，上线后 QPS 上来了才发现查询要 5 秒。流马在每个工程阶段出口放一个阶段门禁：需求阶段 PRD 流出前，SHACL 契约校验必须包含功能模块、参与者定义、验收条件；设计文档流出前，必须有架构图、必须追溯到 PRD；代码提交前，自动跑 lint + test + security scan。不合格？直接打回。这套机制借鉴了丰田的“自工程完结”——不接收缺陷、不制造缺陷、不流出缺陷。问题发现得越晚，修复代价越高。

问题五：踩过的坑不再踩第二次

流马的记忆系统把所有决策、修正、失败模式都写成 JSON‑LD 节点存入 L0 知识图谱。下次有类似任务，SA 调度器会自动从知识图谱里检索历史经验，注入给 Agent：“上次类似的 PRD 缺少用户角色定义，这次注意补上。”后台的 Batch Agent 还会自动提炼经验碎片、合并重复技能、挖掘失败模式，让系统越用越聪明。这不是 LLM 变强了，而是 Harness 在持续优化。