Hermes Agent 扩展体系：Skill、Plugin 与 MCP

前言：第一次看到 Skill、Plugin 和 MCP 时，我也很容易把它们都理解成“给 Agent 加功能”。真正写扩展时才会发现，三者改变的是完全不同的层次。本文先把职责、加载方式、权限和生命周期讲清楚；下一篇再用一个完整项目把三条路线组合起来。

系列导航：这组文章按“总览 → 入口 → 运行时 → 扩展 → 状态 → 协作 → 安全”的顺序展开；第一次阅读可以从总览开始，带着具体问题也可以直接跳到专题。

Skill、Plugin 和 MCP：不是同一种扩展

Hermes Agent 没有把所有扩展都叫“插件”，而是把不同重量的能力拆开了。

扩展方式	主要内容	适合解决的问题	对核心的影响
Skill	`SKILL.md`、参考文件、脚本、模板	操作手册、领域知识、可复用工作流	最轻，按需加载上下文
Plugin	Python 代码、`plugin.yaml`、`register(ctx)`	新工具、Hook、Provider、平台与中间件	进程内全信任执行；能力授权不是沙箱
MCP	独立进程或远程工具服务	结构化外部能力与跨语言集成	松耦合，运行时动态发现

Skill 的系统提示词里通常只放紧凑索引，模型判断匹配后再通过 skill_view 读取完整内容。这种 Progressive Disclosure 很省上下文：平时只承担名称和简介，需要时才加载全部流程；同一文件重复读取还会按指纹去重。

Plugin 则是可执行扩展。加载器会从用户目录、项目目录和 Python entry point 发现插件，处理依赖顺序、兼容性、Profile 作用域和卸载恢复。普通第三方插件默认需要显式启用；Memory Provider、Context Engine、模型 Provider 等专门类型则由各自配置选择。

MCP 适合那些“确实应该是工具，但不应该进核心”的能力。MCP 服务的工具可以动态进入 Registry，服务端发出工具列表变化时也能刷新。这样外部系统不必和 Hermes Agent 的 Python 进程绑定。

flowchart LR
    Need[出现一个新能力需求] --> Existing{现有工具能完成?}
    Existing -->|能| Reuse[复用现有工具]
    Existing -->|不能| Workflow{主要是知识或流程?}
    Workflow -->|是| Skill[写成 Skill]
    Workflow -->|否| Runtime{需要进程内生命周期?}
    Runtime -->|是| Plugin[实现 Plugin]
    Runtime -->|否| MCP[独立 MCP 服务]
    Plugin --> Core{几乎所有用户都需要?}
    Core -->|极少数情况| CoreTool[再考虑核心工具]

我觉得这套“能力足迹阶梯”是整个项目最值得借鉴的设计之一。新增核心工具不只是多一个函数，它会让每轮请求多一份 Schema，还要长期维护权限、错误、兼容和文档。能用 Skill 或 MCP 解决的事，不该急着扩张核心表面积。

扩展怎样重新汇合到 Agent Runtime

我判断扩展放在哪一层时，会先问它改变的是知识、进程内行为，还是外部系统边界。团队排查规范经常变化但不需要确定性代码，适合 Skill；要注册工具、Hook 或 Provider，适合 Native Plugin；需要独立鉴权、独立部署并让其他 Host 复用，则适合 MCP Server。

变化的东西	优先放置	进入模型的方式	主要代价
操作流程与经验	Skill	索引常驻，正文按需读取	依赖模型正确理解说明
进程内确定性逻辑	Plugin	注册 Tool / Hook / Provider	可信代码拥有当前用户权限
远端服务能力	MCP	握手后动态注册工具 Schema	额外进程、网络与认证生命周期

flowchart LR
    User[用户请求] --> Agent[智能体运行时
AIAgent]
    Skill[Skill 操作知识] --> Agent
    Plugin[Plugin Tool 与 Hook] --> Registry[工具注册表
Tool Registry]
    MCP[MCP 服务器
MCP Server] --> Registry
    Registry --> Agent
    Agent --> Model[模型提供方传输层
Provider Transport]
    Agent --> Execute[统一 Tool Executor]

三条路线最终都回到同一个窄腰：Skill 改变模型采用的方法，Plugin 和 MCP 把确定性能力注册进 Tool Registry，所有真实调用仍经过作用域、Hook、审批、结果规范化和会话持久化。扩展方式不同，不代表运行时另起炉灶。

如何决定能力放在哪一层

我会先找出需求中最稳定的边界，再选扩展类型。比如“怎样接手一个陌生仓库”主要是操作顺序，适合 Skill；“每次都返回相同结构的仓库统计”需要确定性代码，适合 Plugin；“访问团队知识库”依赖独立服务和认证，适合 MCP。三者可能出现在同一套安装里，但没有必要为了展示能力而强行放进同一个业务故事。

判断问题	答案倾向	优先选择
只需要告诉模型何时、按什么步骤使用现有工具吗？	是	Skill
需要注册 Python Tool、Hook、Provider 或运行时中间件吗？	是	Plugin
能力是否属于独立进程、远端服务，或需要被其他 MCP Host 复用？	是	MCP