前言

如果你在用 Hermes Agent，特别是在飞书、Telegram 等网站通过 Gateway 模式使用。很可能遇到过这个问题：

发一条消息，等15秒才收到回复。

这不是你的网络问题，也不是 Hermes 本身有 bug。这是 Hermes 的架构设计带来的代价——它要加载大量工具定义、技能描述、记忆程序，每轮对话发送给 LLM 的 prompt 高达 50万 tokens。

这篇文章记录了我今天对一个生产环境 Hermes 实例进行速度调整的完整过程，包含每一步的实测数据和决策依据。从最终效果来看，从15秒降到2.6秒，快了5倍。说起来，

环境说明

• 硬件: Linux 服务器
• Hermes Agent: v2026.09.x
• 连接方式: 飞书消息
• 记忆程序: Hindsight
• 初始 LLM: MiMo v2.7
• 替代 LLM: DeepSeek V4 Flash

一、慢在哪里？先诊断

每轮对话的时间线 使用者发消息 → 飞书 Webhook → Gateway → 组装 Prompt → LLM 推理 → 返回结果 200ms 50ms 50ms?，?，ms 200ms

# MiMo v2.7 的日志API call #: model=mimo-v2.7 provider=xiaomi in=185K out= latency=1.5s cache=99% API call #: model=mimo-v2.7 provider=xiaomi in=180K out= latency=1.4s cache=99%

结论:: % 的时间都花在 LLM 推理上，其他环节加起来不到1秒。

每轮平均: 新 Input: ~18,500 tokens 从Cache来看，~176,500 tokens 总 Input: ~195。000 tokens 缓存率的观点是，~95%

即使 % 是缓存命中，那 % 新 token 加上 MiMo 自身的推理延迟，导致了~14-16秒的响应时间。

`System Prompt`里到底有什么？`System Prompt`里到底有什么？Hermes 的 `agent/system_prompt.py`，发现每轮发给 LLM 的 system prompt由三层组成：

Stable 层：
SOUL.md ~3。8K tokens
HERMES_AGENT_HELP_GUIDANCE ~7K
MEMORY_GUIDANCE ~6K
SESSION_SEARCH_GUIDANCE ~3K
SKILLS_GUIDANCE ~6K
TOOL_USE_ENFORCEMENT ~8K
Skills 清单 ~8,4K tokens
Environment hints ~2K
Platform hints ~3k
Context 层：
AGENTS.md ~17,2K ←最大浪费！system_message ~4k
Volatile 层：
MEMORY 快照 ~4k,USER profile ~8k,Hindsight recall 注入 ~/~,时间戳+Session信息 ~/~。工具 JSON Schema ~/~ ←第二大─────────────────────────────────静态开销总计 ~/~tokens`




`AGENTS.md`:这是一个~KB 的 Hermes 开发教程，记录项目结构、如何添加工具等，跟日常聊天完全无关！按理说，但却被自动注入每一轮对话。

`工具 JSON Schema` :个工具文件的JSON定义，但大部分在飞书场景根本用不到。

`这两项加起来占了~,tokens!,是最大的浪费。`



二、`调整一`:移除 AGENTS.md`

做了什么?
AGENTS.md 是 Hermes 的 `prompt_builder.py`自动扫描当前工作目录加载的。它位于 `~/.hermes/hermes-agent/AGENTS.md`.`
#备份并重命名,不再被自动扫描cp AGENTS.md AGENTS.dev.mdrn AGENTS.md`



影响?


从`效果来看。` 每轮减少~/~,个新token!



主要代码片段?Hermes 的 prompt_builder.py 中这样扫描:

def loadagentsmd -> str:
"""AGENTS.md — top-level only ."""
for name in :
candidate = cwdpath / name if candidate.exists: content = candidate.readtext.strip return _truncatecontentreturn ""

只要文件不叫AGENT.MD就不会被加载.



三、调整二:禁用不需要的工具集`

做了什么?话说回来，

在 ~/.hermes/config.yaml 中:

yaml disabled_toolsets:- browser- video- video_gen- spotify- tts- discord - discord_admin - computer_use

这些工具在飞书文字聊天场景完全用不到。

感觉?


工具Schema从~/~,减少到~/~。*

需要时随时删掉恢复配置项*


四、调整三:更换底层LLM模型`


这是最关键的一步.


测试对比?在完全相同prompt下进行:



模型
调用次数
延迟
缓存率




MiMo v
次

%


DeepSeek V Flash首次

%



第 次

%



第 次

%




DeepSeek Flash更快?


原因DeepSeek特别值得提的是其缓存机制:


根据DeepSeek官方文档:


Each user request will trigger construction of a hard disk cache.
Once cache is no longer in use it will be automatically cleared usually within a few hours to a few days.


这代表着的观点是，


缓存在磁盘上!不是内存，!其实，

没有固定TTL只要继续使用就一直保留!

每天用Hermes隔天回来缓存通常仍然可用!

跨网站切换system prompt部分继续命中缓存!怎么说呢，


配置方法?

确保.env中有DeepSeek API Key:
DEEPSEEKAPIKEY=sk-your-key-here``markdownhtml htmlhtml


五、调整四:调整Prompt Caching策略`

背景?说起来，GitHub Issue #说明了一个关键问题:


Tool-heavy agents pay 〜%% input-token overhead — system_and_ caching skips tools schema.


默认strategy只为system prompt+最终几条消息设置断点。而大量tools schema未被缓存.

yaml # ~/.hermes/config.yamlprompt_caching:strategy:system_tools_and_ #同时为system + tools + last messages设置断点cache_ttl:"m"


效果?按理说，tools部分也开始命中缓存进一步减少需要处理的新token.

六、完整效果对比

Token维度
表格...

时间维度
表格...

日志对比
ini #调整前
API call #: model=mimo-provider=xiaomiin=/out=/total=/latency=.s cache=%#
API call #:


ini #调整后
API call #:


七.费用影响?

实际成本? 每轮〜/,input token,%缓存命中.

VIII.

排错教程:如果遇到类似问题第一步先看日志:


tail -f ~/.hermes/logs/agent.log | grep -E 'latency\|model'


说到根据输出判断。✅延迟集中于LLM调用→换模型或调整prompt ⚠︎低→检查promptcaching和cachettl 🔧多→禁用不用tools ❗︎前几轮慢后面快→正常预热期