AI Agent►工程实践

技能 vs MCP：Hermes Agent 扩展机制的选型指南

在和 Hermes Agent 的日常对话中，我发现它有两种扩展能力的方式：**技能（Skill）**和 MCP（Model Context Protocol）。我一直没搞清楚——两者看起来都是「让 Agent 能做更多事情」，到底有什么区别？什么时候用哪个？

跟 Hermes 深入聊了一轮，结论比我想象的清晰。

技能就是一个纯文本方法论？

是的。技能的本质就是一份 Markdown 文件，放在 ~/.hermes/skills/ 目录下。比如 claude-code 技能，就是一个 745 行的 SKILL.md，带 YAML 元数据头：

1
2
3
4
5
---
name: claude-code
description: "Delegate coding to Claude Code CLI"
version: 2.2.0
---

除此之外没有任何代码。

技能怎么工作？

三步：

  1. 存储 — Hermes 启动时扫描技能目录，建立索引
  2. 发现 — 当你提到「用 Claude Code」，LLM 的系统提示里出现了匹配的技能摘要
  3. 加载 — LLM 调用 skill_view(name)，Hermes 把整个 SKILL.md 的内容注入上下文窗口

到这一步，LLM 就「学会」了 Claude Code CLI 的所有参数、两种编排模式、安全注意事项……然后它通过已有的 terminal 工具去执行 claude 命令。

技能不创造新工具。 加载 claude-code 技能后，LLM 的工具列表没变化，还是 terminal、write_file、read_file 这些。技能只是让 LLM 知道怎么组合现有工具。

那技能依赖本地安装的工具？

是的。如果机器上没装 claude 二进制，技能里记的那些 --max-turns、--allowedTools 全是纸上谈兵。LLM 执行 terminal(command="claude -p ...") 只会得到一个 command not found。

技能 = 教 LLM 方法。实际干活靠系统里已有的工具。

那 MCP 又是什么？

MCP 是 Anthropic 提出的开放协议，让你可以给 AI Agent 接入新工具。它需要一个运行中的后台服务（MCP Server），Agent 通过 JSON-RPC 协议跟它通信。

MCP 怎么工作？

1
2
3
4
5
6
7
MCP Server (守护进程)
  ├── 启动时建立数据库连接池
  ├── 注册工具：query, insert, migrate...
  └── 等待 Agent 调用
          ↑ JSON-RPC
Hermes Agent
  └── 工具列表里多了 mcp__postgres__query(...)

MCP 实实在在地增加了 LLM 的工具集。调用 mcp__postgres__query 是直接跟后台服务通信，不是拼接 shell 命令。

核心差异一图看懂

维度 技能 MCP
本质 静态方法论文档 运行时工具协议
给谁用 LLM 自己看，学习怎么做 LLM 调用，获得新能力
运行时 无——就是读文件 需要常驻进程
工具变化 工具列表不变 增加新工具
状态 无状态 有状态（连接池、会话）
比喻 菜谱 新厨具

三张图看清调用链路

技能调用链路

1
2
3
4
5
6
7
8
9
10
用户说「用 Claude Code 审查代码」
        │
        ▼
  skill_view("claude-code")     ← 注入 34KB 使用手册
        │
        ▼
  terminal("claude -p 'review'") ← 还是用 terminal
        │
        ▼
  stdout 返回结果

MCP 调用链路

1
2
3
4
5
6
7
8
9
10
用户说「查一下最近的错误日志」
        │
        ▼
  mcp__log__query(since="1h")  ← 这个工具本来不存在！
        │
        ▼
  JSON-RPC → MCP Server → 数据库
        │
        ▼
  结构化 JSON 返回

两种模式叠加

1
2
3
4
5
6
7
8
9
10
11
12
用户请求
    │
    ▼
Hermes Agent
    │
    ├── 技能系统：注入知识，教我怎么用现有工具
    │       └── skill_view() → 上下文膨胀
    │
    ├── MCP 系统：提供新工具，扩展我的能力边界
    │       └── mcp__<server>__<tool>() → 工具膨胀
    │
    └── 内置工具：terminal, read_file, write_file, browser...

两者互补：技能加智力，MCP 加武力。

那日志查询到底用技能还是 MCP？

这是我最初的困惑。答案比我想的简单——命令行 + 技能就行。

日志查询是按需触发的：

1
2
3
4
5
查最近一小时的错误日志
    ↓
加载技能 → terminal 调脚本 → 拿到结果 → 完事
    ↓
进程退出，资源释放

MCP 要一个常驻进程蹲在那，99% 时间空转，就为了偶尔查一次日志——划不来。

MCP 到底什么时候用？

跟 Hermes 聊完，结论收敛为三个硬性条件：

需要持久连接

典型：数据库、Redis。每次调用都重新建立连接不现实——建立连接 100ms，复用连接池 1ms，差两个数量级。

需要双向实时通道

不是「我问你答」，而是「有事情发生你主动告诉我」。典型：GitHub MCP 监听 PR 状态变化、文件系统监控、实时日志 tail。CLI 方案只能轮询——有时差、浪费资源。

CLI 做不了的事情

典型：浏览器操作。terminal 调 curl 能拿 HTML，但渲染不了 JavaScript。MCP Puppeteer 给的是真正的浏览器实例，可以点按钮、填表单、截图。

一张决定流程图

1
2
3
4
5
6
7
                    ┌─ 需要持久连接（DB/缓存）？───→ MCP
                    │
需要新能力 ──→ 需要实时推送？──────────────→ MCP
                    │
                    ├─ CLI 做不了（浏览器/GUI）？──→ MCP
                    │
                    └─ 以上都不是 ────────────────→ CLI + Skill

一句话总结

用 MCP 买的不是功能，是「状态」和「连接」。 如果你的工具可以写成无状态的「接收参数→返回结果」脚本，CLI + Skill 就够了。

花十分钟写个脚本 + 五十行 SKILL.md，跟折腾 MCP Server 的常驻进程、协议实现、保活运维相比，前者的性价比碾压后者。只有当你真的需要一个永远在线的会话时，MCP 才值得那个开销。