企业官网建设流程全解析

Hermes Agent 响应速度调优：长对话首字延迟从 10 秒压到 1 秒

【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent

为什么 Hermes Agent 的响应速度会在对话进行到第 50 轮时肉眼可见地变慢？瓶颈不在模型推理，而在请求体每轮都在膨胀。下文拆解两个真正生效的优化点，把延迟从 10 秒压回 1 秒以内（文中数字均来自同一示例会话，标注"示例"）。

慢在哪里 🔍

跑过一轮长会话的你，大概都有过这些感受：

• 首 token 要等好几秒才出来，后面的流式输出反而正常
• 同样的问题，第 5 轮几秒回，第 50 轮要等十几秒
• 换个新会话再问一遍，立刻秒回

说白了，慢不慢取决于会话里堆了多少内容，而不是你这句话有多长。

给上下文瘦身

上面"越问越慢"的直接原因：每一轮请求都会把整段历史原样发给模型。上下文压缩模块在 agent/context_compressor.py 里，策略是头尾保留原文、中间交给轻量模型摘要。默认参数长这样：

# 触发条件与默认参数（agent/context_compressor.py） ContextCompressor( threshold_percent=0.50, # 占满窗口 50% 即触发压缩 protect_first_n=3, # 前 3 轮对话保留原文 protect_last_n=20, # 最近 20 条消息保留原文 )

中间内容会被摘要成结构化快照，摘要预算默认只占被压部分的 20%（summary_target_ratio=0.20）。另有一层防抖：连续两次压缩各省不到 10% 就跳过，避免压缩本身变成死循环。

把重复请求挡在缓存层

"第二次问同样的问题秒回"背后，是前缀大部分根本没变。提示缓存策略在 agent/prompt_caching.py 里，每次请求最多打 4 个缓存断点：静态系统前缀、系统提示结尾、工具定义后，以及最近两条非系统消息。TTL 分 5 分钟和 1 小时两档。前缀命中后，模型端直接复用缓存结果，不重新解析。

怎么验证它真的变快了

最关键的单项收益是首字延迟：tokens 先砍掉近三分之二，剩下的靠缓存补齐。想自己核对，可以用 agent/model_metadata.py 里的 token 估算工具，在每轮请求前后各采样一次请求体大小。

今天就能做的 3 件事 ✅

1. 检查压缩阈值：默认 50% 触发已适合多数模型，想更快就别调高它。
2. 保持系统提示为稳定前缀：它是跨会话命中提示缓存的前提，别往里塞时间戳。
3. 用 token 估算函数抽查请求体：确认压缩真的在触发，而不是只在空会话里生效。

压缩器的尾部保护还有一个新选项：tail_mode="lean"（compaction v2）改用 token 预算而非固定条数保护近期对话，节省更激进。这是项目正在迭代的下一步，你可以在仓库里搜 compaction 相关的 issue 跟踪进展。

【免费下载链接】hermes-agentThe agent that grows with you项目地址: https://gitcode.com/GitHub_Trending/he/hermes-agent