文章导读

本文围绕一个核心问题展开：MCP 解决了什么问题，为什么 Hermes Agent 不把所有工具都硬编码进核心系统？答案不是“为了更酷”，而是为了让工具接入更解耦、更安全、更容易扩展、更适合企业级系统。

一、先说结论：MCP 解决的是“工具扩展失控”问题

如果把 Hermes Agent 想象成一个会思考的调度中心，那么 Tools 就是它真正能动手的手脚。问题在于，真实世界的工具太多了：GitHub、数据库、文件系统、浏览器、工单系统、CRM、内部 API、支付系统、监控平台、知识库……如果每接一个系统都要改 Hermes 核心代码，Agent 很快就会变成难以维护的巨型工程。

MCP 的作用，就是把这些外部工具从 Hermes 核心里拆出去，让外部工具以统一协议接入。Hermes 不需要知道每个工具背后的业务细节，只需要知道：这个服务器有哪些工具、每个工具需要什么参数、调用后会返回什么结果。

一句话理解

MCP 就像 Agent 世界里的“USB 插口”：Hermes 负责识别和调用，外部系统负责提供具体能力。

1.1 普通硬编码工具为什么会失控

硬编码工具在早期很方便：写一个函数、注册一个 Schema、让模型调用它。但当工具数量从 10 个变成 100 个，再变成 1000 个时，问题就会集中爆发。每个工具都有自己的鉴权、参数、错误格式、版本升级、权限边界、依赖环境。如果这些都塞进 Hermes 核心仓库，核心系统就会越来越重。

这不是代码量的问题，而是边界问题。核心 Agent 应该负责推理、会话、上下文、工具调度；外部业务系统应该负责自己的业务能力。MCP 的价值，就是把这条边界画清楚。

1.2 MCP 不是另一个工具，而是工具接入协议

MCP 不是一个“新工具”，而是一种接入方式。外部系统可以把自己包装成 MCP Server，向 Hermes 暴露工具列表、参数 Schema 和调用接口。Hermes 启动后连接这些 Server，自动发现工具并注册到自己的 Tool Registry。这样模型看到的仍然是工具调用，但工具的实现已经不在 Hermes 核心里。

二、MCP 在 Hermes Agent 里的位置

从整体链路看，Hermes 的工具系统可以分成三层：第一层是模型输出 tool_call，第二层是 Hermes 的 Tool Registry 负责查找和调度，第三层才是真正执行动作的工具实现。MCP 接入的是第三层，它让外部服务器也能像内置工具一样被注册、被发现、被调用。

层级	负责什么	MCP 的作用
模型层	根据任务和工具 Schema 选择要调用的工具	看到 MCP 工具的 Schema，并生成 tool_call
调度层	Tool Registry 根据工具名找到 handler	把 MCP 工具注册成普通工具入口
执行层	真正访问文件、API、数据库或外部系统	由 MCP Server 执行业务动作并返回结果

官方 Tools Runtime 文档说明，Hermes 工具是自注册函数，按 toolsets 分组，并通过中央 registry/dispatch 系统执行；在核心工具发现之后，MCP 工具也会被发现并注册。官方 MCP 文档则说明，Hermes 会在启动时发现 MCP Server 的工具，并把它们注册到普通工具注册表中。

2.1 MCP 让工具变成“外部可插拔能力”

没有 MCP 时，新增一个企业内部系统可能意味着：要写 Hermes 原生工具、改注册表、处理依赖、处理凭证、测试发布。使用 MCP 后，这些逻辑可以放在独立的 MCP Server 里，Hermes 只读取配置、连接服务器、发现工具、注册工具。

这对企业落地特别重要。企业内部系统往往变化快、权限复杂、数据敏感，如果全部写进 Agent 核心，安全和维护都会变得困难。MCP 让业务系统用自己的节奏演进，Agent 核心保持稳定。

三、MCP 到底接入了什么：两类服务器

Hermes 官方文档把 MCP Server 分成两类：stdio 服务器和 HTTP 服务器。它们的区别主要在部署位置和通信方式。stdio 更像本地工具进程，HTTP 更像远程服务接口。Hermes 会把它们统一抽象成工具。

类型	怎么连接	适合什么场景	典型配置
Stdio MCP Server	本地启动子进程，通过 stdin/stdout 通信	本地文件系统、GitHub CLI、本地开发工具	command + args + env
HTTP MCP Server	连接远程 endpoint，通过 url/headers 通信	企业内部 API、云端服务、托管工具平台	url + headers + timeout

3.1 Stdio：把本地工具进程接进 Hermes

stdio 模式适合已经安装在本机的工具。例如文件系统工具、GitHub 相关工具、本地分析工具等。Hermes 根据配置中的 command 和 args 启动子进程，再通过标准输入输出与它通信。好处是低延迟、部署简单；风险是要注意环境变量和本地权限边界。

3.2 HTTP：把远程系统接进 Hermes

HTTP 模式适合组织内部已经托管好的 MCP 服务。例如公司把 CRM、工单系统、数据查询服务包装成 MCP Server，Hermes 只需要配置 url、headers 和超时参数即可连接。这样企业可以把鉴权、审计、限流、权限隔离放在服务端做，而不是让每个 Agent 客户端各写一套。

四、MCP 工具怎么进入 Hermes 的工具表

Hermes 并不是让模型“随便访问外部服务器”。它会先把外部工具转成自己能理解的工具定义。这个定义至少包含工具名、描述、参数 Schema 和真实调用 handler。模型只看到工具定义，不直接看到外部服务器内部逻辑。

为了避免重名，Hermes 会给 MCP 工具加上统一前缀：mcp_<server_name>_<tool_name>。例如 filesystem 服务器的 read_file 会注册为 mcp_filesystem_read_file，github 服务器的 create-issue 会注册为 mcp_github_create_issue。

4.1 命名规则解决了工具冲突

在真实项目中，不同外部系统可能都有 read、search、create、delete 这样的工具名。如果不加前缀，工具注册表很容易冲突。前缀让工具来源一眼可见，也让模型和日志更容易定位：这次调用到底来自哪个 server。

4.2 Toolset 让 MCP Server 变成一组可管理工具

官方 MCP 文档说明，每个配置过且贡献了工具的 MCP Server 会创建运行时 toolset，名称形如 mcp-<server>。这意味着你可以从“工具组”的角度管理它，而不是一个一个工具孤立管理。

五、一次 MCP Tool Call 的真实执行链路

从用户视角看，只是让 Hermes “帮我查一下 GitHub Issue”。但从系统视角看，链路要经过模型决策、工具调用、注册表调度、MCP handler、外部 server 执行、结果回填多个步骤。

步骤	发生了什么	关键价值
1. 模型选择工具	模型基于 Prompt 和 Tools Schema 输出 tool_call	模型只表达意图，不直接执行动作
2. Agent Loop 接管	run_agent.py 读取工具名和参数	把模型输出转成可执行流程
3. Registry 查找	根据工具名找到 ToolEntry	统一调度内置工具、插件工具和 MCP 工具
4. MCP Handler 调用	把参数发给对应 MCP Server	把外部工具封装为标准调用
5. Server 执行	外部系统访问 GitHub、数据库、API 等	真正动作发生在外部边界内
6. 结果回填	结果返回给模型继续推理	模型根据结果决定下一步或生成回答

5.1 模型不是执行者，Hermes 才是执行调度者

这是理解 Agent 安全的关键。模型输出的是工具调用意图，例如“调用 mcp_github_list_issues，参数是 label=bug”。真实执行由 Hermes 的 registry 和 MCP handler 接管。这样系统可以在执行前后做过滤、日志、错误包装、凭证脱敏、并发控制和权限限制。

六、为什么不能全量暴露外部工具：过滤就是安全边界

MCP 的强大之处也带来风险：外部系统可能有很多高危工具，比如删除客户、退款、修改权限、清空数据库、删除文件。Hermes 官方文档提供了 include、exclude、enabled、resources、prompts 等配置，让你只暴露模型真正需要的能力。

配置能力	作用	适用场景
enabled: false	完全禁用某个 MCP Server	旧系统、测试系统、风险过高的服务
tools.include	只允许白名单中的工具注册	敏感系统，只开放少数查询或创建能力
tools.exclude	排除危险工具，其余保留	第三方服务中少数工具风险较高
prompts/resources: false	关闭资源与提示词包装器	避免额外暴露服务端上下文或模板

工程实践里，推荐默认使用白名单思路：先只开放读取、查询、总结类工具，再逐步开放创建、修改类工具。对于删除、退款、权限变更等动作，应当通过单独审批、审计或人工确认流程处理。

七、MCP 解决的不是“接入工具”一个问题，而是一组工程问题

7.1 解耦：工具升级不拖累 Agent 核心

外部系统的变化频率远高于 Agent 核心。GitHub API 变了、数据库 Schema 变了、内部工单系统加字段了，如果每次都要改 Hermes 核心，迭代速度会被拖慢。MCP 把变化隔离在 MCP Server 侧。

7.2 复用：一个 MCP Server 可以服务多个 Agent

如果公司已经把内部 CRM 封装成 MCP Server，那么 Hermes、Claude Code、Cursor、其他 MCP 客户端理论上都可以复用这套能力。工具不再是某个 Agent 的私有实现，而是一个可复用服务。

7.3 权限：让可见工具变少，而不是让模型自觉不用

安全不是靠“告诉模型不要乱用”，而是靠系统只暴露它允许用的工具。MCP 的过滤配置可以让模型根本看不到不该看的工具。这比在 prompt 里写禁止规则更可靠。

7.4 隔离：工具可以运行在独立进程或远程服务中

stdio server 可以作为独立子进程运行，HTTP server 可以部署在远端服务中。这样工具的依赖、权限、日志、异常都可以与 Agent 核心隔离。核心系统只面对统一协议，不直接承担每个工具的运行复杂度。

八、动态发现：工具变化不一定要重启整套体系

官方 MCP 文档提到，MCP Server 可以通过 notifications/tools/list_changed 通知 Hermes 工具列表发生变化。Hermes 收到通知后会重新拉取工具列表并更新 registry。这个机制对动态系统很有价值。

例如数据库 MCP Server 发现新表、新字段后，可以更新自己的工具列表；业务系统上线新接口后，可以把新能力暴露出来。Hermes 不必把每种变化都写进核心发布流程。

8.1 /reload-mcp 解决配置变更

如果你手动修改 MCP 配置，Hermes 支持通过 /reload-mcp 重新加载 MCP Server 并刷新工具列表。动态发现负责 server 主动通知，reload 负责用户配置改变后的主动刷新。两者解决的是不同场景。

九、并发调用和 Sampling：MCP 的运行时能力

Hermes MCP 文档还提到两个进阶能力：Parallel Tool Calls 和 Sampling。前者让同一个 MCP Server 的多个工具在安全前提下并发执行，后者允许 MCP Server 通过 sampling/createMessage 向 Hermes 请求 LLM 推理。

能力	解决的问题	风险控制
Parallel Tool Calls	多个只读查询可以同时执行，提高效率	只有服务端工具可并发且无共享状态风险时才开启
Sampling	外部工具需要生成、总结、判断时，可请求 Hermes 调用模型	配置 token 上限、超时、速率限制、模型白名单、工具循环深度

这说明 MCP 不只是“远程函数调用”。它也参与运行时治理：哪些工具可以并发、外部 server 是否可以反向请求模型、请求模型时如何限制成本和风险。

十、反向能力：Hermes 自己也能作为 MCP Server

MCP 不仅能让 Hermes 使用别人提供的工具，Hermes 自己也可以作为 MCP Server。官方文档说明，hermes mcp serve 可以让其他 MCP 客户端使用 Hermes 的跨平台消息能力，例如列出会话、读取消息、发送消息、处理审批等。

这个设计非常重要：它说明 MCP 是一种双向生态接口。今天 Hermes 是客户端，接 GitHub、数据库、文件系统；明天 Hermes 也可以是服务端，把自己的 gateway、session、messaging 能力暴露给其他 Agent。

十一、如果你要自己设计 Agent 工具系统，应该学什么

Hermes 的 MCP 设计给我们一个很好的工程启发：不要一开始就把所有工具塞进核心。工具系统应该分层：核心工具少而稳定，插件工具处理本地扩展，MCP 处理外部系统和跨团队集成。

场景	推荐方式	原因
Agent 必须内置的基础能力	内置工具	如文件、终端、浏览器，属于运行时基本能力
团队自己的本地扩展	插件或 hooks	代码在本地可控，适合轻量扩展
已经存在的外部系统	MCP Server	系统边界清晰，复用性高，便于权限和审计
企业敏感业务系统	MCP Gateway 层	统一鉴权、过滤、审计、限流和脱敏

11.1 企业落地建议：先建工具网关，再接 Agent

对于企业内部系统，不建议让 Agent 直接持有所有系统的高权限凭证。更稳妥的方式是：企业先建设 MCP Gateway，把鉴权、审计、限流、过滤、数据脱敏放在网关层；Hermes 只连接网关暴露出来的最小工具集合。

这样做的好处是责任清晰：Agent 负责推理和调度，MCP Gateway 负责工具治理，业务系统负责业务动作。任何一层出现问题，都更容易定位和收敛风险。

十二、常见误区

12.1 误区一：MCP 会替代内置工具

不会。内置工具适合稳定、高频、基础的运行时能力，例如文件读写、终端执行、浏览器自动化。MCP 更适合外部系统能力，尤其是已经存在、变化频繁、跨团队维护的能力。

12.2 误区二：接了 MCP 就可以让模型随便调用外部系统

不能。MCP 只是接入方式，不是自动安全保证。真正的安全来自最小权限、工具过滤、凭证隔离、审计日志、危险动作审批、错误脱敏和环境隔离。官方文档也强调 stdio 服务器不会盲目传递完整环境变量，而是只传入显式配置和安全基线，降低密钥泄漏风险。

12.3 误区三：MCP 只是给开发者用的

不是。MCP 的价值在企业应用里更明显。客服系统、运营系统、财务系统、研发系统、数据平台都可以通过 MCP 变成 Agent 可调用的工具集。用户看到的是一句自然语言请求，背后是 Agent 通过 MCP 调度多个外部能力。

十三、总结：MCP 是 Hermes Agent 工具工程化的分水岭

Hermes Agent 不把所有工具写死，是因为长期运行的 Agent 必须面对真实世界的复杂工具生态。工具数量会增加，工具版本会变化，权限边界会变复杂，企业系统会不断演进。如果所有能力都硬编码进核心，系统很快就会失去可维护性。

MCP 解决的是工具接入的工程化问题：它让外部工具以标准协议接入 Hermes，让工具可以被发现、被注册、被过滤、被命名、被调度、被并发控制、被安全治理，也可以动态更新。

最终结论

写死工具适合 Demo，MCP 才适合长期运行的 Agent 系统。Hermes 通过 MCP 把“模型会思考”和“系统能行动”之间的边界变得清晰、可扩展、可治理。