Hermes Agent 响应速度优化实战：从 15 秒到 2.6 秒

如果你正在使用 Hermes Agent（Nous Research 开发的那个开源 AI 智能体），尤其是在飞书、Telegram 这类平台上走 Gateway 模式，大概率遇到过这个让人抓狂的场景：

一条消息发出去，然后，等上 10 到 15 秒，才能看到回复。

别急着怀疑是网络问题，也别觉得 Hermes 本身有 bug。这其实是它架构设计中的“原罪”——为了功能强大，它要加载一堆工具定义、技能描述和记忆系统，每轮对话发给大模型的 prompt 动不动就飙到 18 万 tokens。

下面这份记录，详细拆解了今天对一个生产环境下的 Hermes 实例进行速度优化的全过程，每一步都有实测数据和决策依据。最终结果嘛——从 15 秒压缩到 2.6 秒，整整快了 5 倍。

环境说明

• 硬件：Linux 服务器
• Hermes Agent：v2026.5.x（最新版）
• 连接方式：飞书消息（Feishu Gateway）
• 记忆系统：Hindsight（Docker 部署）
• 初始 LLM：MiMo v2.5（Xiaomi token-plan 套餐）
• 替代 LLM：DeepSeek V4 Flash

一、慢在哪里？先诊断

1.1 每轮对话的时间线

用户发消息 → 飞书 Webhook → Gateway → 组装 Prompt → LLM 推理 → 返回结果 200ms50ms 50ms????ms 200ms

通过 tail -f ~/.hermes/logs/agent.log 可以很清楚地看到每条消息的延迟分布：

# MiMo v2.5 的日志API call #10: model=mimo-v2.5 provider=xiaomi in=185K out=94 latency=13.5s cache=100%API call #11: model=mimo-v2.5 provider=xiaomi in=180K out=716 latency=15.4s cache=99%

结论很明确：90% 的时间都消耗在 LLM 推理环节，其他环节加起来都不到 1 秒。

1.2 每轮发了多少 token？

通过 ~/.hermes/state.db 查询，可以看到：

每轮平均：新 Input（需处理）: 5,645 tokensCache（跳过）:107,735 tokens总 Input: 113,380 tokens缓存率: 95.0%

即使缓存命中率高达 95%，那 5% 的新 token（大约 5,600 个）加上 MiMo 自身的推理延迟，也足以让响应时间卡在 13-15 秒。

1.3 System Prompt 里到底有什么？

深入看了看 Hermes 的 agent/system_prompt.py，发现每轮发给 LLM 的 system prompt 由三层组成，结构如下：

Stable 层（跨轮不变）：SOUL.md（人格身份）~2,000 tokensHERMES_AGENT_HELP_GUIDANCE ~200MEMORY_GUIDANCE~500SESSION_SEARCH_GUIDANCE~300SKILLS_GUIDANCE~200TOOL_USE_ENFORCEMENT ~400Skills 清单（66个技能描述）~3,000Environment hints ~100Platform hints（飞书） ~300Context 层：AGENTS.md（Hermes 开发指南） ~17,000← 最大浪费！system_message~0Volatile 层（每轮变化）：MEMORY 快照~350USER profile~25Hindsight recall 注入~2,048时间戳+Session信息~30工具 JSON Schema（79个工具定义） ~23,000← 第二大─────────────────────────────────静态开销总计~50,000 tokens

关键发现有两个：
1.

：这是一个 50KB 的 Hermes 开发指南，记录了项目结构、如何添加工具等。问题是，它跟日常聊天完全无关，却被自动注入到每一轮对话中。
2. ：79 个工具文件的 JSON 定义，但像 browser、video、spotify 这些，在飞书场景下根本用不上。

这两项加起来就占了 40,000 tokens，是最大的浪费。

二、优化一：移除 AGENTS.md

做了什么

AGENTS.md 是 Hermes 的 prompt_builder.py 自动扫描当前工作目录加载的。它位于 ~/.hermes/hermes-agent/AGENTS.md。

# 备份并重命名，不再被自动扫描cp AGENTS.md AGENTS.dev.mdrm AGENTS.md

影响

• 效果：每轮减少约 17,000 个新 token
• 日常聊天：零影响，毕竟开发指南跟聊天无关
• 开发 Hermes 时：需要的话，执行 mv AGENTS.dev.md AGENTS.md 恢复即可

核心代码片段

Hermes 的 prompt_builder.py 中是这样扫描的：

def _load_agents_md(cwd_path: Path) -> str:"""AGENTS.md — top-level only (no recursive walk)."""for name in ["AGENTS.md", "agents.md"]:candidate = cwd_path / nameif candidate.exists():content = candidate.read_text(encoding="utf-8").strip()return _truncate_content(result, "AGENTS.md")return ""

所以很简单，只要文件名不叫 AGENTS.md，它就不会被加载。

三、优化二：禁用不需要的工具集

做了什么

在 ~/.hermes/config.yaml 中配置：

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

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

影响

• 工具 Schema 从约 23K 减少到约 15K
• 如果后续需要，随时在 config 里删掉对应项就能恢复

四、优化三：更换底层 LLM 模型

这是最关键的一步，没有之一。

实测对比

在完全相同的 prompt（约 185K tokens）下进行对比：

模型	调用次数	延迟	缓存率
MiMo v2.5	13 次	13-15 秒	99-100%
DeepSeek V4 Flash	首次	4.7 秒	80%
DeepSeek V4 Flash	第 3 次	2.6 秒	98%
DeepSeek V4 Flash	第 9 次	2.6 秒	98%

为什么 DeepSeek 更快？

对比维度	MiMo v2.5	DeepSeek V4 Flash
模型定位	推理型模型，擅长复杂推理	Flash 模型，优化推理速度
首 token 延迟	高（需要思考链）	低（直接输出）
缓存机制	内存级缓存，TTL 5 分钟	硬盘级缓存，持久数小时到数天
缓存命中价格	套餐内 1x 计费	¥0.02/M tokens
网络延迟	token-plan-cn 约 143ms	api.deepseek.com 约 143ms

DeepSeek 的缓存机制特别值得一提

根据 DeepSeek 官方文档，这意味着：

• 缓存存储在磁盘上，而不是内存里
• 没有固定 TTL，只要还在用就一直保留
• 你白天用 Hermes，隔天回来，缓存大概率还在
• 跨平台切换（飞书 ↔ Web UI），system prompt 部分也能继续命中缓存

如何配置

# ~/.hermes/config.yamlmodel:default: "deepseek-v4-flash"provider: "deepseek"

同时确保 .env 中有 DeepSeek API Key：

DEEPSEEK_API_KEY=sk-your-key-here

五、优化四：优化 Prompt Caching 策略

背景

GitHub Issue #20880 揭示了一个关键问题：Hermes 默认的 system_and_3 策略只在 system prompt + 最后 3 条消息上设置缓存断点，这就导致工具的 JSON Schema（约 12K tokens）每次调用都不走缓存。

做了什么

# ~/.hermes/config.yamlprompt_caching:strategy: system_tools_and_2# 缓存 system + 工具定义 + 最后 2 条消息cache_ttl: "5m"

效果

工具定义部分也开始从缓存提供服务，进一步减少了每轮需要处理的新 token 量。

六、完整效果对比

Token 维度

指标	优化前	优化后	变化
每轮新 Input token	5,645	~1,926	↓ 66%
每轮 Cache token	107,735	~138,794	↑
缓存命中率	95.0%	98%	↑

时间维度

场景	优化前	优化后	提升
简单问答	13-15 秒	2-3 秒	5 倍
多工具调用	15-20 秒	3-5 秒	4-5 倍

日志对比

优化前（MiMo v2.5）：

API call #10: model=mimo-v2.5 provider=xiaomi in=178,977 out=692 total=179,669 latency=13.5s cache=98%API call #13: model=mimo-v2.5 provider=xiaomi in=180,951 out=403 total=181,354 latency=15.4s cache=99%

优化后（DeepSeek V4 Flash）：

API call #3: model=deepseek-v4-flash provider=deepseek in=180,659 out=118 total=180,777 latency=2.6s cache=98%API call #9: model=deepseek-v4-flash provider=deepseek in=185,232 out=109 total=185,341 latency=2.6s cache=98%

七、费用影响

DeepSeek 定价

项目	价格
缓存命中	¥0.02 / M tokens
输入（未命中）	¥1 / M tokens
输出	¥2 / M tokens

实际成本

每轮对话：约 185K input tokens，98% 缓存命中

缓存命中:181K × ¥0.02/M = ¥0.0036未命中:4K × ¥1/M= ¥0.004输出:120 × ¥2/M = ¥0.00024────────────────────────────每轮成本:¥0.008

每天 500 轮对话的话，成本大约 ¥4/天，远低于 MiMo 套餐 ¥411/月。

八、总结与建议

优化清单（按效果排序）

优先级	优化	难度	效果
⭐⭐⭐	更换更快的 LLM 模型	低	5 倍提升
⭐⭐	移除 AGENTS.md	低	减少 ~17K token
⭐⭐	禁用不用的工具集	低	减少 ~8K token
⭐	优化 prompt_caching 策略	低	工具定义也缓存

其他可参考的优化

• 用 /compress 命令压缩长对话：Hermes 内置了上下文压缩，长对话后手动运行，可以减少历史 token
• 调低 Hindsight recall tokens：默认 4096，可改为 1024
• 对话压缩更激进一些：compression.target_ratio: 0.15

排错指南

如果你也遇到类似的问题，第一步永远是看日志：

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

根据输出判断：

• 延迟集中在 LLM 调用 → 换模型或者优化 prompt
• 缓存率低（<80%）→ 检查 prompt_caching 策略和 cache_ttl
• 工具调用多 → 考虑禁用不用的工具集
• 前几轮慢后面快 → 缓存正在预热，属于正常现象