Hermes Agent响应速度优化实战：15秒降至2.6秒
通过移除无关的AGENTS md文件、禁用不必要工具集、更换为DeepSeekV4Flash模型并优化提示缓存策略，成功将HermesAgent每轮响应时间从15秒大幅压缩至2 6秒，实现约5倍速度提升，同时缓存命中率高达98%。
如果你正在使用 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. AGENTS.md（约 17K tokens）：这是一个 50KB 的 Hermes 开发指南，记录了项目结构、如何添加工具等。问题是，它跟日常聊天完全无关，却被自动注入到每一轮对话中。
2. 工具 JSON Schema（约 23K tokens）：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
- 工具调用多 → 考虑禁用不用的工具集
- 前几轮慢后面快 → 缓存正在预热，属于正常现象