Nous Research 为 Hermes Agent 加入 Tool Search 功能，通过按需加载工具定义将 MCP 工具占用的上下文从 50% 降至按需调用，单次会话成本降低 0.07-0.10 美元，同时解决工具过载导致的决策准确率下降问题。

Hermes Agent 上线工具搜索：MCP 上下文开销砍一半

Nous Research 昨天（5 月 29 日）为开源智能体框架 Hermes Agent 推送了 Tool Search 功能更新。这个功能直接针对 MCP（模型上下文协议）部署中的一个老大难问题：工具定义吃掉一半上下文窗口。

按 Anthropic 去年 11 月的测试数据，一个接入 5 台 MCP 服务器、34 个工具的 Hermes 部署，平均每轮对话的 prompt 大小是 45000 tokens，其中 22000 tokens——整整 50%——全是工具模式（tool schema）的开销。今年 4 月的论文里数据更夸张：典型多服务器环境下，工具定义可以消耗 134000 tokens，每轮对话消耗 15000 到 60000 tokens。

这种"MCP 工具税"带来两个实际问题。第一是成本：会话开始时的缓存未命中，每次可能烧掉 0.07 到 0.10 美元。第二是准确率：当模型同时看到几百个不相关的工具选项时，就会出现决策瘫痪——选择太多反而不知道该用哪个。

按需加载：从"全家桶"到"点菜"

Tool Search 的核心思路是渐进式披露（progressive disclosure）。模型不再预先加载所有工具架构，而是按需逐轮加载所需内容。

启用 Tool Search 后，模型可见的工具数组中，所有 MCP 工具和插件工具会被替换为三个桥接工具：

tool_search(query, limit?) — 搜索延迟工具目录
tool_describe(name) — 加载单个工具的完整模式
tool_call(name, arguments) — 调用延迟工具

典型交互流程是这样的：

Model: tool_search(\"create a github issue\")
  → { matches: [\"github_create_issue\", \"github_create_pr\"] }

Model: tool_describe(\"github_create_issue\")
  → { schema: { title: string, body: string, labels?: string[] } }

Model: tool_call(\"github_create_issue\", { title: \"...\", body: \"...\" })
  → [actual tool execution]

模型先找工具，再看参数，最后调用目标工具。整个过程中，只有被实际使用的工具定义会进入上下文窗口。

Hermes Agent Tool Search 工作流程示意图，展示从 tool_search 到 tool_describe 再到 tool_call 的三步流程

实际效果：上下文开销从 50% 降到按需

Tool Search 是可选功能，默认关闭。启用后，原本占据上下文窗口一半的工具定义开销会被压缩到三个桥接工具的定义（几百 tokens）加上实际调用工具的定义（几千 tokens）。

对于工具密集型部署（比如接入 10+ MCP 服务器、100+ 工具的场景），这个优化直接影响两个指标：

成本：缓存未命中时的 prompt 成本从 0.07-0.10 美元降到几美分。对于高频使用的智能体，这个差异会在月账单上体现出来。
准确率：模型不再被几百个无关工具淹没，决策路径更清晰。Anthropic 的论文里提到"工具注意力"（Tool Attention）是衡量 MCP 工具税的关键指标——工具越多，模型越容易分心。

Tool Search 的设计哲学跟 Hermes Agent 的整体架构一致：不是把所有东西塞给模型，而是让模型主动去拿需要的东西。这跟它的四层记忆体系（L1 核心记忆、L2 技能库、L3 外部记忆提供者、L4 会话历史）是同一个思路。

Hermes Agent 的"学习循环"架构

Hermes Agent 跟其他开源智能体框架（Claude Code、OpenClaw、DeerFlow）最大的区别是它有一套闭环学习系统。

它的记忆体系分四层：

L1 核心记忆：MEMORY.md（最大 2200 字符）和 USER.md（最大 1375 字符），保存环境配置、项目规范、用户画像。这两个文件始终在上下文中，但容量极小。
L2 技能库：SKILL.md 文件，Agent 完成任务后会把流程沉淀成技能文件，下次遇到类似任务直接调用。这是 Agent 的"肌肉记忆"。
L3 外部记忆：支持 8 个插件（Honcho、Mem0、Zep 等），容量无限，但需要主动搜索加 LLM 摘要。
L4 会话历史：SQLite 存储的完整对话记录，用于离线分析和自进化训练。

Tool Search 本质上是把这套"按需加载"的逻辑扩展到了工具层。模型不需要记住所有工具，只需要知道怎么找工具、怎么用工具。

配合 Autonomous Curator 实现自主运维

今年 4 月发布的 v2026.4.30（代号 The Curator Release）引入了 Autonomous Curator 功能，这是一个后台常驻的自主代理，负责技能库的自动维护。

Curator 的工作包括：

对技能库进行评分
合并同类技能
清理失效技能
优先更新刚刚使用过的技能

它默认每 7 天运行一次，每次运行后生成日志文件（logs/curator/run.json）和复盘报告（Markdown 格式）。你可以用 hermes curator status 查看运行状态，按使用频率排序技能。

Curator 继承主程序的运行时配置（提供商、模型、凭证），但权限被限定在记忆与技能工具集，不会越权执行其他操作。这个设计很克制——它不是一个"全能管家"，而是一个专注于技能库维护的后台进程。

Tool Search 跟 Curator 配合使用时，效果更明显。Curator 会根据使用频率调整技能优先级，Tool Search 会根据查询结果优先加载高频技能。两者结合，形成一个正反馈循环：常用技能更容易被找到，不常用技能逐渐沉底或被清理。

MCP 生态的现实困境

MCP 是 Anthropic 去年 11 月推出的协议，目标是让智能体能够标准化地接入各种工具和数据源。理论上很美好，但实际部署中遇到的第一个问题就是上下文爆炸。

问题的根源在于 MCP 的设计假设：所有工具定义在会话开始时一次性加载到上下文中。这个假设在工具数量少（10 个以内）时没问题,但当你接入多个 MCP 服务器、工具数量上百时，上下文窗口就被工具定义占满了。

Anthropic 自己在论文里也承认这个问题，提出了"工具注意力"这个指标来量化工具开销。但他们没有给出解决方案——Tool Search 是 Nous Research 在 Hermes Agent 里的实现。

这个方案不是完美的。它引入了额外的推理步骤（先搜索、再描述、再调用），理论上会增加延迟。但在实际使用中，这个延迟可以忽略不计——相比节省下来的上下文窗口和成本,多一两轮工具调用完全可以接受。

更重要的是，Tool Search 是可选的。如果你的部署只有十几个工具，完全可以不开启这个功能。但如果你在构建一个工具密集型智能体（比如接入了 Spotify、Google Meet、ComfyUI、TouchDesigner 等十几个 MCP 服务器），Tool Search 就是刚需。

跟其他智能体框架的对比

Hermes Agent 的定位跟 Claude Code、OpenClaw 不太一样。

Claude Code 是 Anthropic 官方的 CLI 工具，专注于代码编辑和命令执行。它是无状态的，每次会话结束后不保留任何记忆。

OpenClaw 是一个消息网关包裹的智能体，核心是跨平台消息路由（Telegram、Discord、Slack 等）。它有被动记忆（你告诉它记住什么，它才记住），但没有主动学习能力。

Hermes Agent 的核心是"学习循环"。它不仅能记住你告诉它的东西（L1 核心记忆、L3 外部记忆），还能从任务执行中沉淀技能（L2 技能库），并通过 Curator 自动维护技能库。Tool Search 是这个循环的一部分——它让 Agent 能够在工具层面也实现"按需学习"。

如果你需要一个能够长期运行、持续学习、自主进化的智能体，Hermes Agent 是目前开源方案里唯一的选择。如果你只是需要一个临时的代码助手或消息机器人，Claude Code 或 OpenClaw 可能更合适。

实际部署建议

Tool Search 目前还是实验性功能，官方文档里没有详细的配置说明。根据社区反馈，启用方式是在 config.yaml 里添加：

tools:
  search:
    enabled: true
    limit: 5  # 每次搜索返回的最大结果数

启用后，所有 MCP 工具和插件工具会自动被延迟加载。如果你想保留某些工具的即时可用性（比如核心工具），可以在工具定义里添加 deferred: false 标记。

需要注意的是，Tool Search 会增加工具调用的轮次。如果你的任务对延迟敏感（比如实时对话场景），可能需要权衡一下。但对于大多数异步任务（代码生成、数据分析、内容创作等），这个延迟完全可以接受。

另一个建议是配合 Curator 使用。Curator 会根据使用频率调整技能优先级，Tool Search 会根据查询结果优先加载高频技能。两者结合，可以让 Agent 的工具使用效率逐渐提升。

写在最后

Tool Search 不是一个革命性的功能，但它解决了一个实际问题。MCP 生态要真正落地，必须解决上下文爆炸的问题。Anthropic 提出了问题，Nous Research 给出了一个可行的解决方案。

这个方案的价值不在于技术复杂度（实现起来并不难），而在于它跟 Hermes Agent 的整体架构是一致的：不是把所有东西塞给模型，而是让模型主动去拿需要的东西。这个设计哲学贯穿了 Hermes Agent 的记忆体系、技能库、Curator、Tool Search——它们都在做同一件事：让 Agent 更像一个会学习的学徒，而不是一个被动的工具。

从"工具"到"学徒"，这是智能体框架的范式转移。Hermes Agent 在这条路上走得比其他开源方案更远。Tool Search 是这个转移过程中的一小步，但它指向的方向是对的。

参考来源

Hermes Agent 加入工具搜索，"AI 养马"更省 tokens - IT之家 — IT之家对 Tool Search 功能的报道，包含 Anthropic 的测试数据
Hermes Agent 深度解析：从"工具"到"学徒"的范式转移 - 知乎 — 对 Hermes Agent 四层记忆体系的详细解读
拆解 Hermes Agent：开源 Agent 里唯一的闭环学习系统 - 腾讯云 — 对 Hermes Agent 学习循环架构的技术分析
Hermes Agent GitHub 仓库 — 官方开源代码和文档