[Feature Request] Skill 自治理机制：从"静态文本"到"活的结构"

背景

在使用 Hermes 的过程中，我发现 skill 系统存在一个结构性问题：skill 是静态文本文件，没有生命周期管理。这导致问题不断积累，需要人工定期清理。

本文档基于一次完整的 Hermes 系统熵减治理实践（2026-09-08），记录了问题的根源和建议的解决方案。

问题诊断

现象

根因

Skill 系统是被动的——它不会检查自己，不会修复自己，不会报告自己。

Skill 是静态 Markdown 文件
  ↓
没有依赖声明 → 引用坏了没人知道
  ↓
没有自验证 → 加载时不检查 references 是否存在
  ↓
没有版本收敛规则 → _v1~v5 长期并存
  ↓
没有废弃检测 → 模型废弃了没人管
  ↓
没有自报告 → 问题积累到人发现才处理
  ↓
人工清理 → 清理本身又引入新问题

建议方案：Skill 自治理机制

核心理念

Skill 不应该只是静态文本，而应该是"活的结构"——有依赖声明、有生命周期、有自检能力。

三层架构

第一层：Skill 元数据增强

当前 SKILL.md 的 frontmatter 只有 name/description/trigger 等基本信息。建议增加：

---
name: my-skill
version: 1.0.0
dependencies:
  scripts:
    - ~/.hermes/scripts/my_script.py
  references:
    - references/my_reference.md
  models:
    - bge-m3  # 如果废弃了，自动警告
  cron_jobs:
    - job_id: 9448b4acd34c  # 如果删除了，自动标记
lifecycle:
  created: 2026-09-08
  last_verified: 2026-09-08
  status: active | deprecated | archived
---

第二层：加载时自验证

Skill 加载时自动检查：

1. References 存在性 → 不存在则报 broken ref
2. Scripts 存在性 → 不存在则提示
3. Cron ID 活跃性 → 不活跃则标记 stale
4. 模型可用性 → 废弃则警告并建议替换
5. 版本收敛性 → 有 _vN 后缀则提示归档旧版本

第三层：内建自检循环

Hermes 内建一个轻量级的 cron 任务（不是外部脚本），定期扫描所有 skill：

每小时/每日扫描
  ├─ 检查所有 skill 的 dependencies 是否有效
  ├─ 报告 broken refs / stale models / deprecated models
  ├─ 可选：自动修复（如删除已完成的 cron 引用）
  └─ 输出报告到 session / 推送给用户

为什么需要这个

当前方式的问题

自治理的优势

实施建议

Phase 1：元数据增强（低优先级，向后兼容）

• 在 SKILL.md frontmatter 中增加可选的 dependencies 字段
• 不破坏现有 skill 的兼容性

Phase 2：加载时验证（中优先级）

• Skill 加载时检查 dependencies 是否有效
• 如果无效，在 session 中提示用户

Phase 3：内建自检循环（高优先级）

• Hermes 内建一个轻量级 cron 任务
• 定期扫描所有 skill 的健康状态
• 自动报告问题

证据

本次治理的完整数据：

• 治理前：stale_items=468（96.8% 假阳性），broken_refs=2
• 治理后：stale_items=0，broken_refs=0

但这不是可持续的——下次更新 Hermes 或创建新 skill 时，问题会再次积累。

真正的解决方案不是手动清理，而是让系统自己知道哪里有问题。

参考

• Hermes 官方仓库：https://github.com/NousResearch/Hermes-agent
• 本次治理实践记录：~/.hermes/skills/skill-audit/SKILL.md（已更新到 2.2.0）

记忆系统：同样的设计缺陷

在深入治理 Skill 系统时，我们发现记忆系统（fact_store + MEMORY.md）存在完全同构的问题——这是同一个架构级缺陷的两个变体。

事实（2026-09-08 实测）

观察到的具体污染

MEMORY.md 里不该有的内容：

• "熵减知识体系现状：12 篇笔记..." → 任务进度快照，不是铁律
• "skill-audit v2 判定真问题时..." → 工具行为观察，应进 skill 文档

USER.md 里不该有的内容：

• "L4 事实数据库：~/macai/..." → AI 行为约束（不存 PDF），不是用户偏好

根因分析

记忆系统的问题与 Skill 系统完全同构：

Skill 系统                    记忆系统
─────────────────────────────────────────
SKILL.md 静态文本             MEMORY.md 手写文本
  ↓                              ↓
没有依赖声明                    没有分类机制
  ↓                              ↓
引用坏了没人知道                铁律、任务进度、观察混在一起
  ↓                              ↓
没有自验证                      没有归属验证
  ↓                              ↓
问题积累到人发现才处理          需要人工审查才能发现污染

更关键的：fact_store 是被动写入系统

• 没有自动沉淀机制
• AI 必须主动调用 fact_store(action='add') 才能写入
• 除非 AI 决定写，否则永远是空的

对比：

建议：记忆自治理机制

参照 Skill 自治理，记忆系统也需要三层：

第一层：记忆元数据增强

在 MEMORY.md / fact_store 的每条记忆增加：

- type: iron_rule | task_snapshot | tool_observation | user_pref
  owner: ai | user
  created: 2026-09-08
  last_verified: 2026-09-08
  source: manual | auto_extracted

第二层：写入时验证

在写入记忆时检查：

1. 归属验证 → USER.md 里放 AI 约束 → 拒绝，重定向到 MEMORY.md
2. 类型分类 → 任务进度快照不该进铁律区 → 拒绝，重定向到 fact_store
3. 过期检测 → 12 个月未访问 → 标记为 cold

第三层：自动沉淀机制

这是最关键的一层——让系统主动从对话中提取事实：

每次对话后
  ├─ 检测"值得记住"的对话模式
  ├─ 提取为 fact → 写入 fact_store
  ├─ 检测"行为铁律" → 写入 MEMORY.md
  ├─ 冲突检测 → 与已有记忆矛盾时提示
  └─ 定期报告 → 推送"你的记忆新增了 3 条 fact"

证据

本次治理的完整数据（记忆系统）：

• 现状：fact_store=2 条，MEMORY.md=15 条，USER.md=23 条
• 已发现污染：4 条错归属（2 条 MEMORY.md + 1 条 USER.md + 1 条 skill-audit 观察）
• lifecycle 脚本状态：正常运行，但只能扫已有的 2 条

这跟 Skill 系统的证据是同一份治理实践——两个系统的缺陷都源于"静态文本无自治理"。

实施建议

Phase 1：记忆元数据增强（可选字段，向后兼容）
Phase 2：写入时验证（拒绝错归属）
Phase 3：自动沉淀机制（从对话提取事实）

Phase 3 是长期方向，但即使只做 Phase 1+2 也能显著减少污染。

总结

Skill 系统的熵增不是 bug，是设计缺陷——静态文本不应该承担生命周期管理的责任。

建议 Hermes 将 skill 从"静态文本"升级为"活的结构"，加入依赖声明、自验证和内建自检循环。这才是源头熵减治理——不是手动清理问题，而是让系统自己知道哪里有问题。

本提案由 Hermes 用户基于实际使用经验提交，欢迎讨论和改进。