前言

如果你在用 Hermes Agent（由 Nous Research 開發(fā)的開源 AI 智能體），尤其是在飛書、Telegram 等平臺通過 Gateway 模式使用，很可能遇到過這個問題：

發(fā)一條消息，等 10-15 秒才收到回復(fù)。

這不是你的網(wǎng)絡(luò)問題，也不是 Hermes 本身有 bug。這是 Hermes 的架構(gòu)設(shè)計帶來的代價——它要加載大量工具定義、技能描述、記憶系統(tǒng)，每輪對話發(fā)送給 LLM 的 prompt 高達(dá) 18 萬 tokens。

本文記錄了我今天對一個生產(chǎn)環(huán)境 Hermes 實例進(jìn)行速度優(yōu)化的完整過程，包含每一步的實測數(shù)據(jù)和決策依據(jù)。最終效果：從 15 秒降到 2.6 秒，快了 5 倍。

環(huán)境說明

• 硬件：Linux 服務(wù)器
• Hermes Agent：v2026.5.x（最新版）
• 連接方式：飛書消息（Feishu Gateway）
• 記憶系統(tǒng)：Hindsight（Docker 部署）
• 初始 LLM：MiMo v2.5（Xiaomi token-plan 套餐）
• 替代 LLM：DeepSeek V4 Flash

一、慢在哪里？先診斷

1.1 每輪對話的時間線

用戶發(fā)消息 → 飛書 Webhook → Gateway → 組裝 Prompt → LLM 推理 → 返回結(jié)果
                   200ms          50ms     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%

結(jié)論：90% 的時間都花在 LLM 推理上，其他環(huán)節(jié)加起來不到 1 秒。

1.2 每輪發(fā)了多少 token？

通過 ~/.hermes/state.db 查詢：

每輪平均：
  新 Input（需處理）: 5,645 tokens
  Cache（跳過）:      107,735 tokens
  總 Input:           113,380 tokens
  緩存率:             95.0%

即使 95% 緩存命中，那 5% 新 token（~5,600）加上 MiMo 自身的推理延遲，導(dǎo)致了 13-15 秒的響應(yīng)時間。

1.3 System Prompt 里到底有什么？

深入分析 Hermes 的 agent/system_prompt.py，發(fā)現(xiàn)每輪發(fā)給 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.md（Hermes 開發(fā)指南）       ~17,000  ← 最大浪費！
  system_message                      ~0

Volatile 層（每輪變化）：
  MEMORY 快照                        ~350
  USER profile                        ~25
  Hindsight recall 注入              ~2,048
  時間戳+Session信息                  ~30

工具 JSON Schema（79個工具定義）     ~23,000  ← 第二大
─────────────────────────────────
靜態(tài)開銷總計                        ~50,000 tokens

關(guān)鍵發(fā)現(xiàn)：

1. AGENTS.md（~17K tokens） ：這是一個 50KB 的 Hermes 開發(fā)指南，記錄項目結(jié)構(gòu)、如何添加工具等，跟日常聊天完全無關(guān)，卻被自動注入每一輪對話。
2. 工具 JSON Schema（~23K tokens） ：79 個工具文件的 JSON 定義，但大部分（browser、video、spotify 等）在飛書場景根本用不到。
3. 這兩項加起來占了 40,000 tokens，是最大的浪費。

二、優(yōu)化一：移除 AGENTS.md

做了什么

AGENTS.md 是 Hermes 的 prompt_builder.py 自動掃描當(dāng)前工作目錄加載的。它位于 ~/.hermes/hermes-agent/AGENTS.md。

# 備份并重命名，不再被自動掃描
cp AGENTS.md AGENTS.dev.md
rm AGENTS.md

影響

• 效果：每輪減少 ~17,000 個新 token
• 日常聊天：零影響，因為開發(fā)指南跟聊天無關(guān)
• 開發(fā) Hermes：需要時 mv AGENTS.dev.md AGENTS.md 恢復(fù)即可

核心代碼片段

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(encoding="utf-8").strip()
            return _truncate_content(result, "AGENTS.md")
    return ""

所以只要文件不叫 AGENTS.md 就不會被加載。

三、優(yōu)化二：禁用不需要的工具集

做了什么

在 ~/.hermes/config.yaml 中：

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

這些工具在飛書文字聊天場景完全用不到。

影響

• 工具 Schema 從 ~23K 減少到 ~15K
• 需要時隨時在 config 里刪掉對應(yīng)項恢復(fù)

四、優(yōu)化三：更換底層 LLM 模型

這是最關(guān)鍵的一步。

實測對比

在完全相同的 prompt（~185K tokens）下進(jìn)行對比：

為什么 DeepSeek 更快？

DeepSeek 的緩存機(jī)制特別值得一提

根據(jù) 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.”

這意味著：

• 緩存存儲在磁盤上，不是內(nèi)存
• 沒有固定 TTL，只要在用就一直保留
• 你白天用 Hermes，隔天回來緩存大概率還在
• 跨平臺切換（飛書 ↔ Web UI），system prompt 部分繼續(xù)命中緩存

如何配置

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

同時確保 .env 中有 DeepSeek API Key：

DEEPSEEK_API_KEY=sk-your-key-here

五、優(yōu)化四：優(yōu)化 Prompt Caching 策略

背景

GitHub Issue #20880 揭示了一個關(guān)鍵問題：

“Tool-heavy agents pay ~70% input-token overhead — system_and_3 caching skips tools schema.”

Hermes 默認(rèn)的 system_and_3 策略只在 system prompt + 最后 3 條消息上設(shè)置緩存斷點，工具的 JSON Schema（~12K tokens）每次調(diào)用都不緩存。

做了什么

# ~/.hermes/config.yaml
prompt_caching:
  strategy: system_tools_and_2  # 緩存 system + 工具定義 + 最后 2 條消息
  cache_ttl: "5m"

效果

工具定義部分也從緩存提供服務(wù)，進(jìn)一步減少每輪需要處理的新 token。

六、完整效果對比

Token 維度

時間維度

日志對比

優(yōu)化前（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%

優(yōu)化后（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 定價

實際成本

每輪對話：~185K input tokens，98% 緩存命中

緩存命中:  181K × ￥0.02/M = ￥0.0036
未命中:      4K × ￥1/M    = ￥0.004
輸出:      120 × ￥2/M     = ￥0.00024
────────────────────────────
每輪成本:                    ￥0.008

每天 500 輪對話：約 ¥4/天，遠(yuǎn)低于 MiMo 套餐 ¥411/月。

八、總結(jié)與建議

優(yōu)化清單（按效果排序）

其他可參考的優(yōu)化

• 用 /compress 命令壓縮長對話：Hermes 內(nèi)置了上下文壓縮，長對話后手動運(yùn)行，可減少歷史 token
• Hindsight recall tokens 調(diào)低：默認(rèn) 4096，可改為 1024
• 對話壓縮更激進(jìn)：compression.target_ratio: 0.15

排錯指南

如果你遇到類似問題，第一步是看日志：

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

根據(jù)輸出判斷：

• 延遲集中在 LLM 調(diào)用 → 換模型/優(yōu)化 prompt
• 緩存率低（<80%）→ 檢查 prompt_caching 策略和 cache_ttl
• 工具調(diào)用多 → 考慮禁用不用的工具集
• 前幾輪慢后面快 → 緩存正在預(yù)熱，正常

以上就是Hermes Agent響應(yīng)速度從15秒到2.6秒的優(yōu)化實戰(zhàn)的詳細(xì)內(nèi)容，更多關(guān)于Hermes Agent響應(yīng)速度優(yōu)化的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論