Hermes 修改会话上下文压缩时间本文说明 Hermes Agent 在超长上下文和代理链路下出现会话压缩超时的原因，

Hermes 修改会话上下文压缩时间

通过 sub2api、cli-proxy-api 等代理环境使用超长上下文模型时，Hermes 的会话压缩可能会失败。典型场景是模型上下文很大，例如 gpt-5.5 约 272K，上下文压缩耗时超过默认窗口，最终看到：⚠ Compression summary failed: Request timed out.. Inserted a fallback context marker.

这份指南先说明问题和触发条件，再列出 Windows、Linux、macOS、Docker 下的 config.yaml 路径，最后给出 auxiliary.compression 的推荐配置与参数解释。

1. 遇到的问题

当会话很长时，Hermes 会尝试把历史对话压缩成 summary，再继续后续推理。正常情况下这能节省上下文；但在超长上下文模型加代理链路时，压缩请求本身可能变得非常慢。

你会在日志或界面里看到类似提示：

⚠ Compression summary failed: Request timed out.. Inserted a fallback context marker.

这表示压缩 summary 没有在限定时间内完成，Hermes 插入了 fallback context marker，避免会话彻底中断。

2. 为什么会发生

根因是：压缩任务需要处理很长的上下文，而默认压缩超时时间偏短；如果 auxiliary.compression.provider: auto 还沿用主模型，压缩就会变成一次昂贵且缓慢的大模型调用。

在 sub2api、cli-proxy-api 这类代理环境里，链路又多一层转发和等待。遇到 272K 级别上下文时，压缩请求很容易超过客户端或代理的超时窗口。

3. 典型触发场景

常见触发条件有三个：第一，主模型上下文很长，例如 gpt-5.5 272K。第二，通过 sub2api、cli-proxy-api 或类似代理访问模型。第三，压缩配置仍然使用 auto，导致压缩也走主模型。

这些条件叠加时，压缩不是“后台小任务”，而是一次完整的大上下文请求。请求越长，越容易被 timeout 打断。

4. 各平台 config.yaml 路径

不同部署环境里，Hermes 的配置文件位置不同。先找到当前 profile 对应的 config.yaml，再修改 auxiliary.compression。

平台	config.yaml 路径	说明
Windows	`%USERPROFILE%\.hermes\config.yaml`	通常是 `C:\Users\<你>\.hermes\config.yaml`
Linux	`~/.hermes/config.yaml`	`$HOME` 用户目录下
macOS	`~/.hermes/config.yaml`	与 Linux 类似，位于用户目录
Docker	`/home/hermes/.hermes/config.yaml`	取决于容器内运行用户，也可能挂载到 `/opt/data/.hermes`

5. 解决方案总览

最稳的方案是把压缩任务从主模型里拆出来：主模型继续负责回答，压缩 summary 交给一个极速、廉价、吞吐稳定的小模型。

推荐选择 gpt-4o-mini、claude-3-5-haiku-latest 或类似便宜模型。它们处理摘要整理足够快，也能显著降低成本和超时概率。

6. 推荐配置

在 config.yaml 中加入或修改以下配置：

auxiliary:
  compression:
    provider: openai
    model: gpt-4o-mini
    timeout: 600
    base_url: ''
    api_key: ''

如果你使用 Anthropic 体系，可以改成：

auxiliary:
  compression:
    provider: anthropic
    model: claude-3-5-haiku-latest
    timeout: 600

7. 参数解释

provider 表示压缩模型走哪个服务商或 provider 配置。model 是实际执行压缩 summary 的模型，不需要和主对话模型一致。

timeout 是压缩请求允许等待的时间。建议设置为 600 秒，给长上下文和代理链路留出足够空间。

base_url 和 api_key 只在压缩模型使用独立服务商或独立代理时填写；如果复用已有 provider 凭据，可以留空或省略。

8. 验证是否生效

修改后重启 Hermes 或重新加载配置，然后开启一段较长会话，观察是否还出现 compression timeout。

更直接的方式是查看日志：确认 compression provider 和 model 已经切换到你指定的小模型，而不是仍然使用主模型或 auto。

9. 常见误区

不要把默认对话模型换成廉价模型。要改的是 auxiliary.compression，不是主模型配置。

也不要只调大 timeout 而继续让主模型做压缩。这样可能减少偶发失败，但没有解决慢、贵、容易被代理超时打断的根因。

10. 最终建议

对超长上下文模型来说，压缩 summary 应该是一个独立后台任务。把它交给小模型，并把 timeout 放宽到 600 秒，才是长期稳定方案。

如果你经常通过 sub2api、cli-proxy-api 使用大上下文模型，这个配置应该作为默认基础项，而不是等出错后再临时修补。