集成架构

Gliding Horse Agent OS 实现了统一知识图谱，通过 JSON-LD 和 Oxigraph 无缝集成五个核心子系统：

集成层

核心子系统

JSON-LD 节点

RDF 三元组

AST 提取的事实

5W2H 元数据

序列化格式

验证后的节点

验证后的节点

验证后的节点

验证后的节点

技能图谱
━━━━━━━━
15 个模块
动态进化

L0-L3 记忆系统
━━━━━━━━
受 CPU 缓存启发
MESI 一致性

知识图谱
━━━━━━━━
代码 AST + RDF 三元组
SPARQL 查询

5W2H 任务本体
━━━━━━━━
结构化意图建模
维度级审计

JSON-LD 数据总线
━━━━━━━━
通用互操作
@id/@type/@context

Oxigraph 存储
━━━━━━━━
命名图
SPARQL 1.1 引擎

Harness 引擎
━━━━━━━━
LLM↔JSON-LD 翻译
模式验证

关键创新：不为技能、记忆、任务和代码知识维护独立的数据库，所有数据通过命名图隔离，存在于同一个 Oxigraph 存储中。这使得：

1. 跨子系统查询：SPARQL 可以联合查询技能定义、任务历史和代码产物
2. 统一索引：向量嵌入（HyperspaceEngine）通过 mem:embedding 链接到 RDF 节点
3. 一致的标识：@id 确保同一实体在所有上下文中被一致识别

3.2 实际示例：端到端工作流

让我们追踪这些组件在真实场景中如何协同工作：

场景：用户请求"将认证模块重构为使用 JWT"

步骤 1：任务初始化（5W2H 提取）

{
  "@id": "task:auth-refactor-001",
  "@type": "task:RefactoringTask",
  "task:5W2H": {
    "what": "用 JWT 替换基于 Session 的认证",
    "why": "提升可扩展性，支持无状态微服务",
    "who": { "requiredRole": "agent:Do" },
    "when": { "deadline": "2026-06-01T18:00:00Z" },
    "where": { "targetRepository": "github.com/myorg/auth-svc" },
    "how": {},
    "howMuch": { "tokenBudget": 10000 }
  }
}

→ 存入 L2 黑板（Oxigraph 命名图：blackboard:task-001）

步骤 2：技能发现（SPARQL 查询）

PREFIX skill: <https://agent-harness.os/skill#>
SELECT ?skill WHERE {
  GRAPH system:skills {
    ?skill a skill:AtomicSkill ;
           skill:tags ?tag .
    FILTER(CONTAINS(LCASE(?tag), "jwt"))
    FILTER(?skill/maturity IN ("production", "stable"))
  }
}

→ 返回：skill:rust-jwt-auth, skill:jwt-validation-middleware

步骤 3：代码知识提取（AST 解析）

# Tree-sitter 提取现有认证代码结构
tree-sitter parse src/auth.rs --json > ast_output.json

→ 转换为 RDF 三元组：

code:AuthModule a code:RustModule ;
    code:hasFunction code:session_validate ;
    code:locatedAt "src/auth.rs:42-156" .

→ 存入 L0 持久图谱（system:knowledge）

步骤 4：规划（PA 生成微流程 DAG）

PA 读取 5W2H 约束 + 技能定义 + 代码结构 → 生成执行计划：

{
  "@id": "plan:auth-refactor-001",
  "plan:steps": [
    { "order": 1, "action": "添加 jsonwebtoken 依赖", "skill": "skill:cargo-add" },
    { "order": 2, "action": "定义 Claims 结构体", "skill": "skill:rust-struct-design" },
    { "order": 3, "action": "实现 Token 签发", "skill": "skill:rust-jwt-auth" },
    { "order": 4, "action": "替换 Session 中间件", "skill": "skill:jwt-validation-middleware" }
  ]
}

步骤 5：执行（DA 调用工具）

// DA 通过 Harness 引擎调用工具
let result = harness.execute_tool(
    "skill:rust-jwt-auth",
    json!({ "secretKey": env::var("JWT_SECRET") })
).await?;

// Harness 按 SHACL 模式校验输入
// 用 Ed25519 签名调用
// 将结果写入 L2，@id: "blackboard:task-001/step-3-result"

步骤 6：检查（CA 按 5W2H 维度审计）

{
  "auditBy5W2H": {
    "what": { "verdict": "PASS", "evidence": "JWT 实现完成" },
    "why": { "verdict": "PASS", "evidence": "无状态认证已实现" },
    "when": { "verdict": "PASS", "evidence": "截止日期前完成" },
    "howMuch": { "verdict": "WARNING", "evidence": "Token 预算已使用 85%" }
  }
}

步骤 7：归档与学习（AA 更新技能图谱）

# 更新技能统计
INSERT {
  skill:rust-jwt-auth skill:graphMeta ?newMeta .
  ?newMeta skill:usageCount 48 ;
           skill:successRate 0.92 .
}
WHERE {
  skill:rust-jwt-auth skill:graphMeta ?oldMeta .
  # 计算新成功率...
}

结果：整个工作流利用了：

• ✅ 5W2H 进行结构化任务定义和审计
• ✅ JSON-LD 进行可互操作的数据交换
• ✅ 技能图谱 提供可复用的能力
• ✅ 知识图谱 进行代码理解
• ✅ L0-L3 记忆 实现高效的上下文管理
• ✅ Oxigraph 作为统一存储后端

3.3 性能特征

操作	延迟	机制
L2 节点插入	~2ms	Oxigraph 内存 INSERT
L3 SPARQL 查询	~15ms	CONSTRUCT + Frame 投影
L0 向量搜索	~1ms	HyperspaceEngine HNSW 索引
技能发现	~20ms	SPARQL + 向量相似度
代码 AST 解析	~100ms	Tree-sitter 增量解析
Harness 验证	~5ms	JSON Schema + SHACL 检查

可扩展性：

• L2 支持约 500 ops/sec（适用于活跃任务工作集）
• L0 可扩展到数百万节点（磁盘存储 + 压缩）
• 命名图提供逻辑隔离而无需性能代价

---

4. 技能图谱与知识图谱融合：自进化认知架构

这是 Gliding Horse 区别于所有同类系统的一项根本性架构创新。传统设计中，技能（Skills）是静态指令文件，知识（Knowledge）是外部检索的文本块，两者彼此割裂。Gliding Horse 基于 JSON‑LD 语义总线，将技能、知识碎片、经验教训统一表达为图节点，使 Skill Graph 与 Knowledge Graph 天然融为一体。

4.1 三层自进化能力

经验自动回写： 每个任务完成后，AA（决策 Agent）自动从执行轨迹中提取失败模式、新关联和成功路径，以 KnowledgeFragment 形式挂载到对应技能节点上。下次执行同类任务时，这些碎片作为"免疫情报"自动注入上下文，避免重复踩坑。

技能图自生长： 当 DA（执行 Agent）遇到现有技能无法覆盖的问题时，系统触发 /learn 机制，SA 自动创建新技能草稿节点并建立与现有图谱的语义链接；/reduce 机制则从解决方案中提炼出标准化步骤，使技能从"草稿"演化为"已验证"状态。

信任与成熟度演化： 每个技能节点携带 successRate、usageCount、maturity 等运行时指标。随着成功执行的累积，技能自动从 experimental → stable → production 升级，信任体系逐层传递，无需人工干预。

4.2 与同类系统的对比

维度	其他 Agent 框架	Gliding Horse
技能组织	静态 Markdown 文件或代码函数，需人工维护	JSON‑LD 图节点，6 种语义链接，可遍历、可推理
知识经验	独立于技能的向量库文本块，无结构化关联	经验碎片作为技能节点的附属图节点，自动挂载注入
技能演化	依赖开发者手动更新版本或重写	AA 自动回写成功率、失败模式，成熟度自动升级
技能发现	按文件名或标签匹配	SPARQL 语义查询 + 链接遍历，沿 Prerequisite/Related/Alternative 边发现最优技能链
上下文效率	全量技能描述注入	五级渐进式投影，按需从 MOC → 摘要 → 链接 → 步骤 → 全文逐层加载，Token 节省 >90%

4.3 行业现状：两条技术路线各走各路

纯向量检索（RAG）方案（LangChain + Pinecone/Chroma）语义模糊匹配强，但无法表达"A是B的父类"这类结构化关系，实体间的精确关系淹没在向量空间里。纯知识图谱方案（Neo4j + SPARQL）精确关系查询强，但无法处理"跟这个意思差不多"的模糊匹配，需要精确 IRI 或关键词才能命中。

行业痛点是：大多数系统选择其中一条路，或者简单拼接（先向量搜、再图谱查，或反过来），两者之间缺乏统一的语义总线来调度和融合结果。

4.4 统一方案：JSON‑LD IRI 作为"统一地址总线"

Gliding Horse 从根本上解决了这个割裂问题：

结果

融合调度

双通道检索引擎

统一语义总线

查询入口

IRI 列表

子图

用户 / Agent 查询

JSON-LD IRI 地址总线
所有实体和文档都有唯一 IRI

HyperspaceEngine
语义近似匹配
返回相似文档/实体的 IRI 列表

Oxigraph 图数据库
精确关系遍历
SPARQL 查询实体间关系

L3 投影引擎
根据查询类型智能调度：
- 模糊概念 → 先向量再图谱
- 精确查询 → 直接图谱
- 混合查询 → 双通道并行

融合结果：
既有语义相近的文档
又有精确的实体关系图

三个关键创新：