研究问题：LLM Wiki 存储核心知识层，CodeGraph 存储代码执行层——结构上缺少中间的语义层。能否通过 Harness Engineering × AI 本体论思想，补齐关键缺失层，让智能体的技能管理更加科学和完善？
分析日期：2026-06-24
研究方法：联网深度检索 + 6 篇前沿论文交叉分析 + Hermes 技能体系实证
核心发现：2026 年学术界已出现至少 6 个独立框架在解决完全相同的问题——知识层与执行层之间的"语义编译层"缺失
上一轮分析揭示了一个事实：Hermes 技能文件夹的知识管理存在两层分离的结构性问题。
validate_token()。两者之间没有结构化的映射——"哪条原则由哪个脚本实现？改一条原则影响哪些脚本？一个脚本对应哪些知识概念？"这些问题在两层架构中无法回答。
| 断裂类型 | 具体表现 | 后果 |
|---|---|---|
| 概念-实现断裂 | "验证门控"概念存在 knowledge 层，validate_token() 存在 code 层，但两者无结构化关联 | 改知识不知道改代码，改代码不知道影响哪些知识 |
| 依赖-影响断裂 | knowledge 层的"十条原则"有逻辑依赖关系，code 层的 submit() 有调用依赖关系，但两层依赖图无法交叉查询 | 无法做端到端的影响分析 |
| 质量-覆盖断裂 | knowledge 层有"压缩安全性"概念，code 层有 compression_monitor 脚本，但无法自动检测"这个概念是否有对应的实现" | 知识覆盖分析只能靠人工 |
| 版本-演化断裂 | knowledge 层的概念演化（新增原则）和 code 层的代码演化（新增函数）各自独立，没有同步机制 | 知识腐化、代码漂移无人感知 |
根本原因是两个层面的抽象粒度完全不同：
conversation_loop、context_compressor、approval_mode）——精确的、结构化的、可执行的2026 年上半年，至少 6 个独立研究团队发布了直接回应"知识层 ↔ 执行层断裂"问题的框架。它们的共同发现令人震惊：
"提供 2-3 个精准技能的效果优于提供全部文档"——GraSP 论文的大规模基准测试结论。
技能的瓶颈已从可用性转移到编排能力（orchestration）。
arXiv:2603.04448 · 200,000+ 技能 · ALFWorld/WebShop/ScienceWorld 实验
SkillNet 提出了最完整的技能本体架构，由三个互联层组成：
similar_to、compose_with、belong_to、depend_on核心发现：多维度评估框架（安全性 · 完整性 · 可执行性 · 可维护性 · 成本感知），平均奖励提升 40%，执行步骤减少 30%。
arXiv:2604.24026 · 首个 SKILL.md 结构化表示
基于 Schank & Abelson 经典认知语言学理论，将非结构化 SKILL.md 文档映射为类型化的三层 JSON 图：
skill_id、skill_goal、intent_signature、dependencies、entry_scene_id关键数据：技能发现 MRR@50 从 0.649 → 0.729；风险评估 F1 从 0.409 → 0.509。
arXiv:2604.17870 · 首个可执行技能图架构
GraSP 直接回答了你的核心问题——在检索和执行之间必须有一个编译层：
将平铺的技能集编译为类型化有向无环图 (DAG)，节点是技能调用实例，边编码前置条件-效果依赖（state/data/order）。失败时只失效拓扑后代，修复从 O(N) 降到 O(dh)。
GitHub · OWL 2 技能编译器 + SHACL 验证
最接近 Hermes 实际需求的工程化方案：
OWL 2 属性类型：dependsOnSkill（非对称）、extends（传递）、contradicts（对称）、implements（非自反）。效果：100 个技能 ~500KB 文本扫描 → ~1KB SPARQL 查询。
GitHub · 渐进式技能上下文披露
将扁平技能库转化为图结构化的、渐进披露的能力上下文：
requires、specializes、complements、conflicts_with、supersedesarXiv:2605.14259 · 异构业务系统的超图本体
企业级方案，明确定义了三层：
| 共识 | 出处 | 对 Hermes 的启示 |
|---|---|---|
| 知识层和执行层之间必须有语义编译层 | 全部 6 个框架 | 这是架构刚需，不是可选优化 |
| 技能编排比技能数量更重要 | GraSP 基准测试 | Hermes 的 60+ 技能需要编排，不是堆叠 |
| SKILL.md 是原始材料，不是查询接口 | SSL, OntoSkills | 需要从 SKILL.md 编译出结构化表示 |
| 关系类型是语义层的核心 | SkillNet, SkillGraph, OntoSkills | depends_on / contradicts / specializes / implements |
| 验证门控是质量保障的关键 | OntoSkills SHACL, GraSP 前置条件 | 技能必须通过结构化验证才能生效 |
| 局部修复优于全局重规划 | GraSP O(dh) 修复 | 技能失败时只重做受影响的部分 |
SSL 论文（北京大学，2026）的理论根基来自认知语言学的经典工作，这些理论完美映射了 Harness Engineering 的需求：
| 理论基础 | 原始含义 | SSL 映射 | Harness 映射 |
|---|---|---|---|
| Memory Organization Packets (Schank, 1980) | 目标导向的经验组织者 | Scheduling 层：技能路由与调用接口 | Agent 的"什么时候该加载哪个技能"决策 |
| Script Theory (Schank & Abelson, 1977) | 刻板活动的有序场景 | Structural 层：阶段级执行结构 | Harness 的"五层架构"和"Query Loop 心跳" |
| Conceptual Dependency (Schank, 1972) | 原语动作结构 | Logical 层：原子操作与资源使用 | 具体的工具调用、脚本执行、文件操作 |
综合 6 个前沿框架，设计适合 Hermes 的三层技能本体架构：
| 问题 | 两层架构 | 三层架构 | 查询路径 |
|---|---|---|---|
| "验证门控"原则由哪些脚本实现？ | 无法回答 | ✅ 精确回答 | Principle → implements → Skill → 实现引用 → 函数列表 |
改 compression_monitor 影响哪些 Harness 原则？ | 无法回答 | ✅ 反向追溯 | 函数 → 实现引用 → Skill → exemplifies → 原则 |
| 哪些 Harness 概念还没有对应实现？ | 无法回答 | ✅ 覆盖分析 | 遍历 ConceptNode，检查 implements 入度 = 0 |
| verification-gate 和 drift-detector 冲突吗？ | 无法回答 | ✅ 冲突检测 | 检查 contradicts(S1, S2) 边 |
| 执行一个深度研究任务需要哪些技能的什么顺序？ | 靠 LLM 猜测 | ✅ DAG 编译 | GraSP 式编译：检索 → DAG 构建 → 拓扑排序执行 |
语义层的输入是现有的 SKILL.md frontmatter + 正文。编译管线借鉴 OntoSkills 和 SSL：
{
"skill_id": "verification-gate",
"kind": "SkillNode",
"scheduling": {
"goal": "验证任务输出是否满足质量要求",
"intent_signature": ["验证", "质量门控", "代码审查", "输出检查"],
"expected_inputs": ["task_output", "verification_criteria"],
"expected_outputs": ["verification_report", "pass/fail"],
"dependencies": ["code-quality"],
"control_flow": "conditional_branch"
},
"structural": {
"scenes": [
{"id": "classify", "action": "S/M/L 分级判断"},
{"id": "execute", "action": "执行验证检查"},
{"id": "report", "action": "生成验证报告"}
],
"transitions": ["classify → execute → report"]
},
"logical": {
"atomic_actions": [
{"tool": "terminal", "action": "run_tests", "side_effects": ["stdout"]},
{"tool": "search_files", "action": "find_test_files", "side_effects": []},
{"tool": "read_file", "action": "check_syntax", "side_effects": []}
],
"resources": ["pytest", "eslint", "python"]
},
"relations": [
{"type": "implements", "target": "concept:验证门控"},
{"type": "exemplifies", "target": "principle:验证独立性"},
{"type": "depends_on", "target": "skill:code-quality"},
{"type": "complements", "target": "skill:verification-gate"},
{"type": "code_binding", "target": "codegraph:scripts/validate.py"}
]
}| Hermes 现有组件 | 语义层集成方式 | 改动量 |
|---|---|---|
skill_view() 工具 | 在加载 SKILL.md 时，同时查询语义层获取关系子图，注入到返回结果 | 小 — 增加一次 SQLite 查询 |
skills_list 工具 | 返回时附带技能关系摘要（depends_on / conflicts_with） | 小 — 扩展返回字段 |
| Curator 后台进程 | 利用语义层做覆盖分析：哪些概念无实现、哪些关系断裂 | 中 — 新增分析模块 |
| AGENTS.md 技能加载 | 根据语义层的关系图，自动加载相关技能子图（而非逐个匹配描述） | 中 — 修改技能发现逻辑 |
| MCP 协议 | 语义层通过 MCP 暴露 skill_resolve / skill_impact 工具 | 中 — 新增 MCP 工具 |
| Cron job | 定期运行编译管线，增量更新语义层 | 小 — 新增 cron job |
语义层不仅补齐了结构缺失，还直接增强了 Harness Engineering 的多个核心能力：
| Harness Engineering 概念 | 语义层如何增强 | 对应框架 |
|---|---|---|
| 五层 Harness 架构 | 每层对应一组 CapabilityNode，技能通过 requires_capability 声明所需层级 | SkillNet 分类层 |
| 十条原则 | 每条原则是一个 PrincipleNode，技能通过 exemplifies 关联，可查询"哪些技能违反了原则 X" | OntoSkills SHACL |
| Query Loop 心跳 | Structural 层的场景图直接编码了技能内的循环和阶段，可检测无限循环 | SSL Structural 层 |
| 工具权限分级 | Logical 层的原子操作声明了 side_effects，自动推导权限级别 | SSL Logical 层 |
| 错误恢复分级 | GraSP 的 5 种修复算子映射到 Harness 的"续写 → collapse → compact → surface error" | GraSP 修复代数 |
| 上下文治理 | 语义层的渐进披露（SkillGraph 模式）控制了每次注入的 token 量 | SkillGraph 渐进披露 |
| 验证门控 | SHACL 验证是技能级的验证门控——技能必须通过结构化检查才能生效 | OntoSkills SHACL |
| Curator 生命周期 | 语义层的 supersedes 边让 Curator 知道哪些技能已被替代 | SkillGraph supersedes |
deep-research → book-to-skill(可选) → cloudflare-deploydepends_on wrangler v2（macOS 10.15 限制）SELECT concept WHERE NOT EXISTS (?skill implements ?concept)contradicts(verification-gate, delegation-optimizer) = true| 任务 | 方案 | 工具 |
|---|---|---|
| 为 10 个核心技能生成语义节点 | 手工 + LLM 辅助提取 frontmatter → JSON schema | Python script |
| 构建关系图原型 | SQLite 表 + Python NetworkX | SQLite + NetworkX |
| 验证 5 个核心查询 | "X 实现了哪些概念"、"改 X 影响什么"等 | 手动验证 |
| 任务 | 方案 | 借鉴 |
|---|---|---|
| SKILL.md → 语义节点编译器 | LLM 提取 + Pydantic schema 验证 | OntoSkills OntoCore |
| 自动关系推导 | frontmatter 解析 + LLM 推理 contradicts | SkillNet 关系发现 |
| SHACL-lite 验证门控 | Python jsonschema 验证 | OntoSkills SHACL |
| 与 CodeGraph 对接 | code_binding 边连接 CodeGraph 节点 | 自定义 |
| 任务 | 方案 | 借鉴 |
|---|---|---|
| MCP 工具暴露 | skill_resolve / skill_impact / skill_compile_dag | GraSP DAG 编译 |
| Curator 增强 | 覆盖分析 + 冲突检测 + 自动建议 | 自定义 |
| 技能加载优化 | 渐进披露：L0 摘要 → L1 接口 → L2 详情 → L3 全文 | SkillGraph 多级深度 |
| Cron 增量编译 | 文件变更监听 → 增量重编译 | CodeGraph auto-sync |
| 任务 | 方案 | 借鉴 |
|---|---|---|
| GraSP 式 DAG 执行 | 任务编译 → 拓扑执行 → 局部修复 | GraSP 5 种修复算子 |
| LLM Wiki 双向同步 | 语义层变更 → 自动更新 LLM Wiki 图谱 | 自定义 |
| OWL 2 互操作 | 导出 RDF/Turtle，与外部本体工具互操作 | OntoSkills |
| 跨 Profile 技能图谱 | 多 Profile 的技能本体联合查询 | HEAR 超图 |
| 维度 | 无语义层 | 有语义层 | 价值增益 |
|---|---|---|---|
| 技能发现 | LLM 逐词匹配 SKILL.md 描述 | 结构化图查询 + 渐进披露 | MRR@50 提升 12%（SSL 实测） |
| 影响分析 | 只能做代码层或知识层单向分析 | 端到端：原则 → 技能 → 脚本 → 函数 | 从"不可能"到"一次查询" |
| 冲突检测 | 靠人工审查 | 自动 contradicts 边检测 | 预防技能冲突于加载前 |
| 覆盖分析 | 靠人工盘点 | 自动检测"无实现概念" | 系统性知识治理 |
| 技能编排 | LLM 猜测执行顺序 | DAG 编译 + 拓扑执行 + 局部修复 | 奖励提升 40%（SkillNet 实测） |
| Token 效率 | 加载完整 SKILL.md（500KB+） | 按需查询（~1KB） | 上下文预算节省 99% |
| 质量验证 | 运行时才发现技能缺陷 | SHACL 门控：编译时拦截 | 验证前移，降低运行时故障 |
skill_view 工具最兼容Agent Skill Management = Knowledge Layer (LLM Wiki) + Semantic Ontology Layer (🆕) + Code Execution Layer (CodeGraph)