Hermes Agent 如何用工具、技能和 MCP 扩展能力边界
很多人第一次接触 Hermes Agent 时，容易把“扩展能力”理解成一件事：给它多接点东西就行。真上手后你会发现，Hermes 其实拆得很清楚。内建工具、Skills、MCP 都能让它变强，但它们各自负责的那一段并不一样。
你可以先记住一个很顺手的理解方式：工具负责直接执行，Skill 负责复用流程，MCP 负责接入外部系统。把这三层分清楚，后面不管是做本地自动化，还是接公司内部 API，都会顺很多。
先把三种扩展方式分清楚
Tools 是 Hermes 自带的能力函数，而且按 toolset 组织，可以按平台启用或停用。官方文档里提到的覆盖面很广，已经包括 web search、browser automation、terminal execution、file editing、memory、delegation、Home Assistant 等等。换句话说，如果你要做的事情本来就在这套能力里，最省事的办法通常不是“再接一个新系统”，而是先把现成工具用好。
Skills 不是新的外部接口，它更像一份按需加载的“过程性知识”。官方把它定义成 on-demand knowledge documents，而且用了 progressive disclosure 机制，只有真正需要时才展开完整内容。这样做有两个直接好处：一是 token 用得更省，二是复杂任务终于有地方沉淀，不用每次都从头讲一遍。
MCP 则是另一条线。它的作用是把 Hermes 之外已经存在的能力接进来，比如 GitHub、数据库、文件系统、浏览器栈或者内部 API。对 Hermes 来说，这些能力会以工具的形式出现，所以你平时使用起来仍然是“让模型调用工具”，只是这些工具的提供者不再是 Hermes 内建模块，而是外部 MCP server。
Skills 适合把复杂任务收纳成可复用流程
Skills 的落点很明确：把一段反复出现、而且不止一步的工作流整理成可复用的知识包。Hermes 默认把技能放在 ~/.hermes/skills/，这也是它的主目录和 source of truth。已安装的技能会自动变成 slash command，所以你既可以直接调用，也可以在自然语言里点名让 Hermes 使用某个 Skill。
这一套交互方式很实用。你可以先用 /skills 或 hermes skills list 看看当前有哪些技能，再用 /skills search 按关键词找。真正执行时，既可以像命令一样直接输入 Skill 名，也可以用普通对话触发。对日常使用来说，这比“记住一大堆固定参数”轻松得多。再加上 Skills 本身就是按需展开的，技能很多也不等于每轮对话都很重，只有用到时才会加载完整内容。
还有一个很值得补进来的细节，是 Skills 不只是“能不能用”，还涉及“该不该出现”。它能根据当前会话里有没有某些工具或 toolset 来决定自己要不要露面。像 fallback_for_toolsets、requires_toolsets 这类字段，本质上是在回答一个很实际的问题：如果内建能力已经够用，这个 Skill 就别出来抢戏；如果某个工具缺席，它再作为补位方案出现。这样一来，Skill 和内建工具之间就不是互相替代，而是可以做很自然的分工。
如果你手里有团队共用的技能目录，Hermes 还支持扫描外部 skill directories。也就是说，本地技能目录之外，还可以把共享技能一起纳入索引。这个设计对团队协作很友好，但边界也没有写得含糊：外部目录主要负责发现，真正创建或编辑技能时，Hermes 仍然写回 ~/.hermes/skills/；如果本地和外部有同名 Skill，本地版本优先。这样既能共享经验，又不容易把“谁在覆盖谁”搞乱。
MCP 适合接外部系统，但最好小步快跑
MCP 的强项是“把外部能力接进来”，而不是“把所有东西都接进来”。Hermes 支持两种 MCP server：一种是本地 stdio server，另一种是远程 HTTP server，配置都写在 ~/.hermes/config.yaml 的 mcp_servers 下。Hermes 启动时会自动发现并注册这些工具；如果 server 支持资源或 prompts，它还会补上对应的工具包装。
从使用感受上看，MCP 接进来之后并不会变成一团看不懂的新能力。官方文档提到，注册后的工具会带上 mcp_<server_name>_<tool_name> 这样的前缀，而且只要某个 server 至少贡献了一个工具，它还会形成一个 mcp-<server> 运行时 toolset。你平时不一定需要手动去敲这些名字，但知道这层结构之后，排查“这个能力到底来自哪里”会轻松很多。
一个很适合起步的配置，就是先给 Hermes 一块边界清楚的文件系统访问范围：
mcp_servers:
project_fs:
command: "npx"
args: ["-y", "@modelcontextprotocol/server-filesystem", "/home/user/my-project"]
这种做法的好处很直接：你先让它看一个明确目录，确认工具确实加载成功，再决定要不要继续往外扩。官方指南也建议这样做，先从单个、安全、范围小的 server 开始，而不是开局就把一大串系统全挂上去。如果后面改了配置，当然可以用 /reload-mcp；另外文档也提到，有些 MCP server 还能通过 notifications/tools/list_changed 主动通知 Hermes 刷新工具列表，所以它并不是一个只能“配完重启”的静态接入层。
真正难的不是接入，而是控制暴露面
MCP 最值得认真对待的地方，不是“能接多少”，而是“你到底要让模型看到多少”。Hermes 在这方面给了比较细的控制粒度。你可以对每个 server 单独配置 tools.include、tools.exclude、tools.resources、tools.prompts，也可以直接用 enabled: false 整个关闭。还有一个细节很关键：如果 include 和 exclude 同时存在，include 优先。
这套设计背后的思路很朴素，但特别重要。对敏感系统来说，白名单通常比黑名单更稳；对资源和 prompts 这类附加能力，也不是默认全开就更好。官方文档里把这件事说得很直白：好的 MCP 用法不是“全都连上”，而是“连接正确的东西，并把暴露面控制在最小但够用的范围里”。
这类治理还不只体现在“工具清单”上。对于 stdio server，Hermes 默认不会把你整个 shell 环境变量一股脑传进去，而是只传显式配置的 env 和一组安全基线。这一点很实在，因为很多时候能力边界的问题，不是模型会不会多调一个工具，而是你是不是顺手把不该暴露的上下文也送进去了。
顺着这个思路再看，就能理解为什么官方还专门提醒：如果内建工具已经能把事情做好，就没必要为了“看起来更高级”再上 MCP。扩展不是叠罗汉，够用比热闹重要。
一个顺手的判断法：什么时候用工具、Skill 或 MCP
如果你只是需要 Hermes 直接完成搜索、浏览、终端执行、文件编辑这类动作，优先用内建工具，路径最短。
如果问题难点不在“缺能力”，而在“这件事总有一串固定步骤、容易遗漏细节、值得复用”，那就更适合写成 Skill。Skill 的价值不在新增接口，而在把经验固化下来。
如果能力本身已经在 Hermes 之外，比如 GitHub、数据库、内部服务或受控文件系统，那么 MCP 才是更自然的入口。它把外部系统变成 Hermes 能理解和调用的工具，同时还给你保留每个 server 的暴露面控制。
把这三者放在一起看，选择逻辑其实很清楚：内建工具优先解决“当下就能做”的问题，Skill 负责把“怎么做更稳”沉淀下来，而 MCP 负责把“原本不在 Hermes 里面的能力”接过来。官方文档里关于 Skill 条件激活和 MCP 过滤机制，其实都在服务同一件事：让真正该出现的能力出现，不该暴露的那部分尽量别露面。
一个很适合演示的组合案例
假设你想让 Hermes 帮你完成一次“资料收集到整理输出”的任务，完全没必要只押宝一种机制。更顺手的做法，往往是把三种能力各放回自己最擅长的位置：
- 用内建工具完成搜索、页面查看、终端命令和文件编辑。
- 用 Skill 固化“怎么收集、怎么筛选、怎么输出”的流程。
- 用 MCP 接入 repo 文件系统或内部文档接口，把 Hermes 需要碰到的外部能力控制在一个有限范围里。
这样拆开之后，边界会很清楚。工具负责干活，Skill 负责让干活更稳定，MCP 负责把该接的系统接进来，而且只接到刚好够用。Hermes Agent 的扩展能力，真正好用的地方也正在这里：它不是让你把所有能力堆成一团，而是给你一套能持续长大的结构。