跟Hermes聊着聊着它就失忆了？这次真不是上下文污染的锅

大家好啊，我是执着于持续分享数码家电、软件技巧相关知识，坚持创作有深度、高质量作品的博主 设计虱聊科技。期待您的关注。

最近用 AI Agent 用得挺顺的，飞书群里布了好几个群，工作群管待办、编程群搞代码、知识库群做笔记，各司其职。前阵子还让它帮我搭了个 Markdown 编辑小工具，从需求拆解到代码实现一路聊下来，全是 Hermes 写的。

但就是跟它聊着聊着，它突然就"忘了"我刚才说的话。而且是转头就忘，这根本不是上下文污染的问题。

现象：不是笨，是"失忆"

我当时的第一反应是：是不是模型不行？

因为我刚换的小米的 mimo-v2.5，之前用的 Minimax-M 2.7。但转念一想，不对啊。mimo 一直风评很好，上下文窗口更是达到 1M tokens，要是模型问题，网上早就炸锅了。

那就只剩一个可能了——是系统层面的问题。

排查：从日志里找线索

我把问题告诉 Hermes，让 Hermes 做一次系统的排查。

排查结果很快出来了：

（1）mimo在推理模式下，reasoning_content 必须传回给 API。
（2）mimo 不认压缩时 Hermes 用的 list 类型的 model 参数。

于是重试三次失败后，系统发现压缩搞不定了，Gateway 干脆直接执行了 auto-reset，把整个对话记录清零，让你从头开始。

这下真相大白了。Agent 不是"忘了"，是被人强制格式化了。

根因：推理模型做不了摘要

要理解这个问题，得先知道 Hermes Agent 的上下文压缩机制是怎么工作的。

简单说，AI 的上下文窗口是有限的。你跟它聊得越多，占用的 token 就越多。当 token 数达到窗口的一定比例时，系统会自动触发"压缩"——把中间的对话内容让另一个模型总结成摘要，用摘要替换原始消息，腾出空间继续聊。

这个设计本身没问题，几乎所有长对话 AI 系统都有类似的机制。

问题出在：用来做摘要的模型，和主对话模型都是 mimo，而 mimo 不适合做压缩摘要。

当压缩触发时，Hermes 调用了 mimo-v2.5 来生成摘要。但 mimo-v 2.5 是个"思考型"模型，它的 API 有一个特殊要求：下一次调用 API 的时候，你必须把上一轮的推理内容（reasoning_content）原样传回去。

但压缩系统的摘要是独立的单轮调用——它只是发一个 prompt 让模型总结，不携带任何历史对话。所以 API 直接报 400 错误："你的 reasoning_content 呢？"

重试三次，次次失败。系统判定"压缩耗尽"，触发 auto-reset，整个会话清零。

从触发压缩到会话清零，整个过程用户完全无感。你只是觉得聊着聊着它就忘了，完全不知道背后发生了什么。

配置：三个参数改了就好

找到原因，修复就简单了。

别让推理模型去做摘要。摘要是个简单活，换个便宜、兼容的普通模型就行。

我改了三个地方：

一、给压缩任务指定独立模型。
原来是 provider: auto，系统自动选主模型。我改成了智谱的 GLM-4.5-flash——轻量、便宜、不是推理模型，做摘要正好合适。

二、提高压缩触发阈值。
原来 threshold: 0.5，上下文用了 50% 就开始压缩，拉到 0.75，对话空间大了不少。

三、扩大近期消息保护范围。
原来 protect_last_n: 20，只保最近 20 条消息。改成 30，更多近期对话免于被压缩。

改完之后，新的会话自动用新配置。压缩不再调用 mimo-v2.5，改用 GLM-4.5-flash 生成摘要。推理模型的兼容性问题彻底消失。

几个容易踩的坑

排查的时候还踩了几个坑，记录一下：

坑一：配置改了但不生效

Hermes 的配置是懒加载的——改了 config.yaml 之后，已经存在的会话不会重新读取配置。只有新建的会话才会用新配置。所以改完配置后，记得在群里发个 /new 或者等会话自动重置。

坑二：auto 不一定是最优选择

很多人（包括我）觉得辅助任务用 auto 让系统自己选就行。大部分情况下确实没问题，但当主模型是推理模型（DeepSeek-R1、Qwen、mimo-v2.5 这类）时，auto 会把压缩任务也丢给推理模型，然后就是上面的翻车。

坑三：日志才是真相

如果 Agent 表现异常，别急着怀疑模型能力。先看日志。Hermes 的日志在 /opt/data/logs/agent.log，搜 compress、Failed、auto-reset 这几个关键词，大概率能找到线索。

坑四：飞书消息发不出去？可能是格式问题

这次排查过程中还遇到了一个意外——AI 回复明明生成了，但飞书就是收不到。去看日志，发现这样的报错：

[230001] message_content has wrong tag:{table}

原因是 AI 在回复里用了 markdown 表格（| 表头 | 内容 |），飞书的消息格式根本不支持这种写法。飞书只认 text、a（链接）、at（@人）、img（图片）、md、code_block 这几种标签，{table} 不在白名单里，直接被拒。

解决办法很简单：让 AI 在飞书回复里用代码块或纯文本对齐来展示表格数据，不要用 markdown 表格语法。 内容太长就分多条发。

这个坑特别隐蔽——Hermes 侧一切正常，消息也生成了，但就是发不到飞书，用户看到的就是"AI 又不说话了"。

一个小经验

这次排查让我意识到：AI Agent 已经越来越像一个"系统"，而不是"工具"了。上下文管理、压缩策略、会话重置、fallback 机制——单个都不复杂，但组合在一起，出了问题排查起来就很头疼。因为你的第一反应永远是"AI 怎么变笨了"，而不是去想"是不是哪个配置参数不对"。

说白了，AI 系统不是换个零件就能跑的，模型、工具链、存储策略是一整套。 你换了"大脑"，"记忆系统"也得跟着适配。换模型之前最好跑一轮完整测试。摘要、搜索、网关这些不起眼的后台功能，才是最容易翻车的地方。

坚持创作有深度、高质量的作品、致力于分享干货、抵制标题党和网络垃圾，是我的座右铭。

您的支持对我真的很重要O(∩_∩)O）。如果你我志趣相投，就帮赏个免费的关注和赞呗。让我们共同打造互联网内容创作和知识分享的一股清流！ヾ(◍°∇°◍)ﾉﾞ