Hermes：为什么长期 agent 把 skill 当成程序化记忆而不是 package spec
Hermes 的 skill 很像 SKILL.md，但它的重心不是 package manager，而是长期运行 agent 的程序化记忆。Hermes bundled skills 覆盖很多类别：Apple、GitHub、MLOps、research、creative、social media、autonomous agents 等。它们更像“这个 agent 长期要记住的操作经验”。
这和 Codex / Claude Code 的即时 coding workflow 不同。Hermes skill 常常和 session、profile、toolsets、gateway、channel、memory 一起工作。真实能力并不只由 SKILL.md 声明，而由当前 profile 启用了哪些工具、gateway 接了哪些平台、当前会话有什么上下文共同决定。
它解决的 runtime 问题
Hermes 要回答的是：长期 agent 如何稳定复用经验，而不是每次都从零推理。
一个 Hermes skill 可能描述如何发社交媒体、如何整理 research、如何查某个本地服务、如何处理 Apple Notes 或 GitHub。这里的核心不是“把文件放在哪个路径会被发现”，而是“当 agent 处在某个 profile 和 toolset 里时，如何可靠地做这类事”。
这也解释了 Hermes metadata 的倾向：version、author、license、tags、related_skills 等字段有利于组织长期技能库，而不是表达完整权限系统。
为什么这样设计合理
长期 agent 面临的是经验复用问题。它要跨天、跨 channel、跨工具集工作。用户关心的不是某个 slash command 是否出现，而是 agent 是否记得某个工作流的细节：附件怎么发，什么情况要验证送达，哪个平台要用什么格式，哪些步骤不要重复问。
因此 Hermes skill 更接近“procedural memory”。它承载的是运行经验，而权限和能力由 profile/toolset/gateway 决定。
迁移时要剥离什么
~/.hermes/skills/<category>/<name>的分类和本地路径。- Hermes profile、toolset、session、gateway 假设。
MEDIA:、附件、平台 channel 发送语义。- Hermes-specific skill loader 或
skill_view调用习惯。 related_skills、tags 等组织字段对其他 runtime 的隐含意义。
Adapter 应该写什么
Hermes adapter 应该写适用 profile、需要哪些 toolsets、目标 channel 如何回复、附件如何发送、是否需要显式验证送达、是否依赖 memory、哪些 related skills 应一起加载。portable core 只保留任务步骤和验收。