前言如果你在用 Hermes Agent由 Nous Research 开发的开源 AI 智能体尤其是在飞书、Telegram 等平台通过 Gateway 模式使用很可能遇到过这个问题发一条消息等 10-15 秒才收到回复。这不是你的网络问题也不是 Hermes 本身有 bug。这是 Hermes 的架构设计带来的代价——它要加载大量工具定义、技能描述、记忆系统每轮对话发送给 LLM 的 prompt 高达18 万 tokens。本文记录了我今天对一个生产环境 Hermes 实例进行速度优化的完整过程包含每一步的实测数据和决策依据。最终效果从 15 秒降到 2.6 秒快了 5 倍。环境说明硬件Linux 服务器Hermes Agentv2026.5.x最新版连接方式飞书消息Feishu Gateway记忆系统HindsightDocker 部署初始 LLMMiMo v2.5Xiaomi token-plan 套餐替代 LLMDeepSeek V4 Flash一、慢在哪里先诊断1.1 每轮对话的时间线用户发消息 → 飞书 Webhook → Gateway → 组装 Prompt → LLM 推理 → 返回结果 200ms 50ms 50ms ????ms 200ms用tail -f ~/.hermes/logs/agent.log可以看到每条消息的延迟分布# MiMo v2.5 的日志 API call #10: modelmimo-v2.5 providerxiaomi in185K out94 latency13.5s cache100% API call #11: modelmimo-v2.5 providerxiaomi in180K out716 latency15.4s cache99%结论90% 的时间都花在 LLM 推理上其他环节加起来不到 1 秒。1.2 每轮发了多少 token通过~/.hermes/state.db查询每轮平均 新 Input需处理: 5,645 tokens Cache跳过: 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 tokens HERMES_AGENT_HELP_GUIDANCE ~200 MEMORY_GUIDANCE ~500 SESSION_SEARCH_GUIDANCE ~300 SKILLS_GUIDANCE ~200 TOOL_USE_ENFORCEMENT ~400 Skills 清单66个技能描述 ~3,000 Environment hints ~100 Platform hints飞书 ~300 Context 层 AGENTS.mdHermes 开发指南 ~17,000 ← 最大浪费 system_message ~0 Volatile 层每轮变化 MEMORY 快照 ~350 USER profile ~25 Hindsight recall 注入 ~2,048 时间戳Session信息 ~30 工具 JSON Schema79个工具定义 ~23,000 ← 第二大 ───────────────────────────────── 静态开销总计 ~50,000 tokens关键发现AGENTS.md~17K tokens这是一个 50KB 的 Hermes 开发指南记录项目结构、如何添加工具等跟日常聊天完全无关却被自动注入每一轮对话。工具 JSON Schema~23K tokens79 个工具文件的 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.md rm 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 / name if candidate.exists(): content candidate.read_text(encodingutf-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.513 次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.5DeepSeek V4 Flash模型定位推理型模型擅长复杂推理Flash 模型优化推理速度首 token 延迟高需要思考链低直接输出缓存机制内存级缓存TTL 5 分钟硬盘级缓存持久数小时到数天缓存命中价格套餐内 1x 计费¥0.02/M tokens网络延迟token-plan-cn 约 143mshttp://api.deepseek.com 约 143msDeepSeek 的缓存机制特别值得一提根据 DeepSeek 官方文档“Each user request will trigger the construction of a hard disk cache. Once the cache is no longer in use, it will be automatically cleared, usually within a few hours to a few days.”这意味着缓存存储在磁盘上不是内存没有固定 TTL只要在用就一直保留你白天用 Hermes隔天回来缓存大概率还在跨平台切换飞书 ↔ Web UIsystem prompt 部分继续命中缓存如何配置# ~/.hermes/config.yaml model: default: deepseek-v4-flash provider: deepseek同时确保.env中有 DeepSeek API KeyDEEPSEEK_API_KEYsk-your-key-here五、优化四优化 Prompt Caching 策略背景GitHub Issue #20880 揭示了一个关键问题“Tool-heavy agents pay ~70% input-token overhead —system_and_3caching skips tools schema.”Hermes 默认的system_and_3策略只在 system prompt 最后 3 条消息上设置缓存断点工具的 JSON Schema~12K tokens每次调用都不缓存。做了什么# ~/.hermes/config.yaml prompt_caching: strategy: system_tools_and_2 # 缓存 system 工具定义 最后 2 条消息 cache_ttl: 5m效果工具定义部分也从缓存提供服务进一步减少每轮需要处理的新 token。六、完整效果对比Token 维度指标优化前优化后变化每轮新 Input token5,645~1,926↓ 66%每轮 Cache token107,735~138,794↑缓存命中率95.0%98%↑时间维度场景优化前优化后提升简单问答13-15 秒2-3 秒5 倍多工具调用15-20 秒3-5 秒4-5 倍日志对比优化前MiMo v2.5API call #10: modelmimo-v2.5 providerxiaomi in178,977 out692 total179,669 latency13.5s cache98% API call #13: modelmimo-v2.5 providerxiaomi in180,951 out403 total181,354 latency15.4s cache99%优化后DeepSeek V4 FlashAPI call #3: modeldeepseek-v4-flash providerdeepseek in180,659 out118 total180,777 latency2.6s cache98% API call #9: modeldeepseek-v4-flash providerdeepseek in185,232 out109 total185,341 latency2.6s cache98%七、费用影响DeepSeek 定价项目价格缓存命中¥0.02 / M tokens输入未命中¥1 / M tokens输出¥2 / M tokens实际成本每轮对话~185K input tokens98% 缓存命中缓存命中: 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 内置了上下文压缩长对话后手动运行可减少历史 tokenHindsight 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工具调用多→ 考虑禁用不用的工具集前几轮慢后面快→ 缓存正在预热正常