Hermes Agent 与 MCP：连接每一款工具的统一协议
Hermes Agent 如何借助模型上下文协议接入数百种外部工具，无需定制集成，以及如何添加你自己的工具。
MCP 对 Hermes Agent 的意义
多年来，每款 AI 助手都需要为每种工具编写专属代码。GitHub 需要 GitHub 集成，Slack 需要 Slack 集成，Postgres 需要数据库适配器。每增加一个工具，工作量就随之叠加，而底层 API 一旦变更，这些代码往往又付诸东流。
模型上下文协议（MCP）以一套开放标准取代了这一模式。MCP 服务器以统一方式对外暴露工具、数据源或提示模板，任何支持 MCP 的智能体都可以直接接入，无需编写新的集成代码。从 2025 年底到一年后，MCP 生态已从约 500 个服务器增长至 10,000 至 12,000 个公开服务器，该协议每月的 SDK 下载量也已突破 9,700 万次。
Hermes Agent 原生支持 MCP。开箱即用，它可以连接你指定的任何 MCP 服务器，因此智能体不存在固定的工具目录——你给它哪些工具，它就拥有哪些工具。
MCP 究竟是什么
MCP 由 Anthropic 于 2024 年底推出，并在 2025 年获得 OpenAI、Google、Microsoft、AWS 和 Cloudflare 的采用。它最贴切的比喻是 AI 领域的"USB-C"——同一根线，同一种接口，适配无数设备。
该协议定义了三种基本原语：
- 工具（Tools）：模型可以调用的可执行函数。"读取这条 issue"、"发送这条消息"、"执行这条查询"——模型自行决定何时调用工具。
- 资源（Resources）：应用程序可以拉入上下文窗口的结构化数据，例如文件、数据库行、日历事件。由宿主应用程序决定加载哪些资源。
- 提示（Prompts）：用户可调用的可复用指令模板，类似于斜杠命令，由用户决定触发哪个提示。
MCP 服务器本质上是一个遵循该协议的进程，可以运行在本地、其他机器或远程服务上，传输层根据实现方式支持 JSON-RPC over stdio、HTTP 或 WebSockets。
Hermes Agent 如何使用 MCP
Hermes Agent 充当 MCP 宿主。启动 Hermes 运行时后，它会读取你的 MCP 配置，启动各个已配置的服务器，并在每一轮对话中将工具、资源和提示暴露给模型。
这正是 Hermes Agent 所说"开箱即带 40 余种工具"背后的机制。这些工具没有一个是硬编码进智能体的——它们都是默认配置中附带的 MCP 服务器：文件系统服务器、Shell 服务器、网络搜索服务器、记忆服务器，等等。你可以删除其中任何一个、换用社区替代方案，或者添加新的服务器，智能体重启后即可生效。
这带来了可组合性的优势。假设明天出现了一个你关心的新工具（Linear、Figma，或者你内部的账单系统）对应的 MCP 服务器，你无需等待新版 Hermes 发布，只需将该服务器加入配置，智能体即可立即使用它。
值得关注的 MCP 服务器
模型上下文协议项目官方维护了一批参考服务器，并指向一个更庞大的社区服务器目录。生态覆盖面已相当广泛，对于大多数主流 SaaS 工具，通常已有现成的 MCP 服务器可用。
目前可接入 Hermes Agent 的类别：
- 源代码管理：GitHub、GitLab、Git、Bitbucket
- 通讯工具：Slack、Discord、Microsoft Teams、电子邮件
- 知识库：Notion、Confluence、Linear、Jira
- 数据库：Postgres、SQLite、MongoDB、BigQuery
- 云平台：AWS、Cloudflare、Vercel
- 文件与搜索：文件系统、Google Drive、Brave Search、Puppeteer
- 自定义内部工具：用 Python 或 TypeScript 封装一个小型 MCP 服务器即可
两个值得收藏的主要目录：GitHub 上的官方 modelcontextprotocol/servers 仓库，以及精选的 awesome-mcp-servers 列表。两者结合，通常能找到你所需工具的维护服务器，且往往只需一行命令安装。
将 MCP 服务器连接到 Hermes Agent
在自托管的 Hermes Agent 中添加 MCP 服务器，只需在配置中加一小段 JSON。具体路径因部署方式而异，但配置结构是通用的：
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_..."
}
},
"postgres": {
"command": "uvx",
"args": ["mcp-server-postgres", "postgres://user@host/db"]
}
}
}
重启后，智能体会自动探测每个服务器、了解其暴露的工具，并将其添加到模型的可用操作中。你可以向智能体提问来验证连接是否正常，例如"列出仓库中的未解决 issue"或"显示 users 表的结构"。
对于 Hermify 托管服务方案，MCP 配置已通过控制台开放。你可以从目录中选择 MCP 服务器，或直接粘贴配置块，平台会重启运行时，下一条消息起工具即可使用。关于我们在生产环境中运行的更多内容，可参阅 Hermes Agent 记忆与技能，了解它与 MCP 层如何协同工作。
MCP 与定制集成的对比
有必要直接说清楚这里的权衡，因为仍有一些团队在纠结是否应该构建专属集成而非使用 MCP。
| 考量维度 | 定制集成 | MCP 服务器 |
|---|---|---|
| 首次工具调用耗时 | 数天至数周 | 数分钟 |
| 跨智能体复用 | 无 | 任何 MCP 宿主均可用 |
| API 变更后的维护 | 自行承担 | 由服务器维护者承担 |
| 精细控制粒度 | 完全可控 | 受限于服务器所暴露的能力 |
| 认证方式 | 任意方式 | Token 或 OAuth，取决于服务器 |
正确的默认选择是：当现有 MCP 服务器可用时就直接使用，仅在需要现有服务器无法提供的行为时才自行构建。即便如此，你自行构建的东西通常也应该是一个 MCP 服务器，而不是 Hermes 专属插件，这样它就能同时适用于 Claude Desktop、ChatGPT、Cursor 以及未来出现的任何智能体。
实用使用模式
以下是过去一年运行 Hermes Agent 与 MCP 过程中沉淀下来的几个习惯：
从最小可用服务器集开始。 每个 MCP 服务器都会扩展模型的工具列表，而工具列表越长，工具选择的准确性就越低。保持活跃集合精简，待发现智能体真正需要某个服务器时再添加。
为每个服务器单独管理凭证。 每个 MCP 服务器使用自己的凭证。为每个服务器使用最小权限 token——只读的 Postgres 用户、范围限定到单个仓库的细粒度 GitHub token——这样即使某个服务器行为异常，也不会造成超出预期的影响。
像对待基础设施一样对待你的 MCP 配置。 将其提交到私有仓库，审查变更，并像对待 Terraform 变更一样来推进。智能体的行为直接由这个文件决定。
审计智能体调用了什么。 Hermes Agent 会记录每次工具调用。每周浏览一次日志，看看哪些服务器真正被使用过。从未出现过的那些只是噪音，删除它们。
如果说记忆与技能赋予了 Hermes Agent 持续运行的价值，那么 MCP 赋予的则是持续扩展的价值。两者相互叠加：记忆记录上次什么有用，技能固化反复执行的流程，而 MCP 则为智能体提供了作用于真实世界的原始工具。三者合一，让 Hermes 从一个聊天界面，成长为更接近小型自主协作者的存在。
立即注册 Hermify，你的 MCP 服务器可以直接通过控制台接入，运行时、持久化和凭证管理均已为你处理好。如果想对比框架方案的异同，Hermes Agent vs LangChain 对同一问题进行了深入分析。