我有一个跑在自己服务器上的 AI 助手，给自己加了Hermes Agent，完整上线过程和踩坑记录。它基于开源项目 Hermes Agent 搭建，背后接的是智谱的 GLM-5.1 模型。日常通过飞书跟我对话，帮我处理各种任务。

前几天它突然”降智”了——开始忘记之前的对话内容，答非所问，像失忆了一样。

这篇文章记录了排查过程。原因出奇地简单，但找到它的过程绕了不少弯路。

症状

对话的质量突然下降。具体表现：

• 重复问我已经回答过的问题
• 之前明确交代过的偏好和要求，它全忘了
• 长对话进行到一半，突然”断片”

作为一个自建 AI 助手的重度用户，这种体验很糟糕。搞不清楚是谁在给谁打工了。

排查：查日志

AI 助手的对话质量下降，一般有两个方向：模型本身的问题，或者上下文管理出了故障。

我先排除了模型问题——GLM-5.1 是稳定运行的，没听说有降级或调整。那就看上下文管理。

Hermes Agent 有一个上下文压缩（context compression）机制。根据官方文档 Context Compression and Caching，当对话历史占用的 token 达到模型上下文窗口的 50%（默认阈值 compression.threshold: 0.50）时，系统会自动调一个辅助模型来做摘要，把中间的对话压缩成一段简短的总结，腾出空间。这个过程对用户是透明的——如果它正常工作的话。

我翻了系统日志，看到了这些：

context compression failed: model不存在 (code 1211)

连着四次，10:02 到 10:46，每次压缩都失败了。

原因

打开配置文件，压缩相关的设置长这样：

compression:
summary_model:google/gemini-3-flash-preview
summary_provider:auto

问题一目了然。

Hermes 官方文档（Fallback Providers）里写得很清楚：compression 属于 “auxiliary tasks”，有独立的 provider 解析链。summary_provider: auto 表示”使用当前主 provider”。我的主 provider 是 zai（智谱 BigModel 平台）。而 summary_model 填的是 google/gemini-3-flash-preview——Google 的模型，挂在一个中国大模型平台上调用。

换句话说，压缩任务会拿着 google/gemini-3-flash-preview 这个模型名去调智谱的 API。智谱平台上当然没有这个模型——服务端返回错误码 1211，”模型不存在”。

压缩失败，对话历史越积越长，最终撑爆了上下文窗口。模型只能看到最后一小段对话，前面的全丢了。这就是”降智”的真相——不是模型变笨了，是它真的看不见之前的对话了。

至于这个错误配置是怎么来的？大概率是当初切换 provider 的时候，只改了主模型和 provider 设置，忘了同步改压缩配置里的模型名。

修复

方向明确了：换一个 zai 平台实际存在的模型。

根据官方文档 Configuration Options，compression.summary_model 默认值就是 google/gemini-3-flash-preview——这说明默认配置是面向 OpenRouter 等国际 provider 的。如果你用的是国内平台（zai、minimax-cn 等），这个值必须手动改。官方文档没有对这一点做特别提醒，但 GitHub Issue #1591 已经有人提了 feature request，希望 compression 能支持独立的 base_url 配置，避免 model/provider 不匹配的问题。截至本文写作时该 issue 尚未关闭。

手上有三个候选：

1. glm-4.5-flash——智谱的轻量模型
2. glm-4-flash——更老的版本，更便宜

写了个脚本直接测。结果：

• glm-4.5-flash：能用，摘要质量可以
• glm-4-flash：也能用，而且更省 token（摘要任务 completion 只用了 23 个 token，4.5-flash 用了 155 个，其中 99 个是推理 token）

最终选了 glm-4.5-flash。理由是摘要质量略好一点，token 开销在可接受范围内。

改了一行配置：

compression:
summary_model:glm-4.5-flash
summary_provider:auto

重启服务，确认 active。开新会话测试，压缩恢复正常。

如何验证配置生效

改完配置、重启服务之后，怎么确认压缩真的能正常工作？有两种方法：

方法一：看日志（推荐）

Hermes 的日志在 ~/.hermes/logs/gateway.log。或者如果你的 Hermes 跑在 systemd 下，用 journalctl：

journalctl --user -u hermes-gateway.service --since "10 min ago" | grep -i compress

正常工作时你会看到类似这样的输出：

Context compression completed: 47 messages → summary (2,381 tokens) + 20 recent messages

如果配置有问题，你会看到 compression failed 或模型相关的错误码。

方法二：手动触发压缩

在 CLI 里直接运行 /compress 命令。Hermes 会立即尝试压缩当前会话的上下文。成功的话你会看到压缩结果的摘要；失败的话会直接报错——比等自动触发更快验证。

几个教训

改 provider 要全局搜索。 这次的问题本质是：改了主 provider 却忘了改依赖它的子系统。以后切换模型供应商，应该全局搜索配置文件里所有硬编码的模型名，而不是只改最显眼的那一行。

辅助模型的选型不能偷懒。 压缩用的摘要模型不需要多强，但要满足三个条件：能通、稳定、便宜。glm-4-flash 其实是更经济的选择，但 4.5-flash 也没贵到哪去。

日志是最好的朋友。 如果没有翻 journalctl 日志，我可能会怀疑是模型本身变差了，或者网络有问题，浪费更多时间在错误的方向上。系统日志说得很清楚——”模型不存在”，问题就是模型名不对。

备份再改。 改配置前跑了一下备份脚本。这个习惯救过我很多次。虽然这次改动很简单，但万一改坏了、需要回滚，有备份就安心得多。

一行配置，四次压缩失败，一个”失忆”的 AI 助手。排查花了大概半个分钟，但如果不熟悉这套系统的运转逻辑，很容易在错误的方向上浪费几个小时。

希望这篇记录对自建 AI 助手的朋友有点参考价值。

祝各位的AI Agent用得愉快～