对话突然"失忆"别急着怀疑模型,真正的元凶是它
大家好，我是专注于持续分享数码家电、软件技巧相关知识的博主设计虱聊科技。希望能获得您的关注与支持。
最近跟一个 AI Agent 互动时，它突然就"忘记"了我之前说的话。而且是瞬间遗忘，这绝非上下文污染那么简单。
当时我的第一反应是：难道是模型能力不足？刚切换到小米 mimo-v2.5，之前用的是 Minimax-M 2.7。但仔细想想不太对劲。mimo 口碑一直不错，上下文窗口更是高达 1M tokens，如果是模型本身的问题，网上早就议论纷纷了。
那就只剩下一种可能性了——系统层面的故障。
我把这个现象反馈给 Hermes，让它进行系统性排查。
排查结论迅速出炉：
（1）mimo 在推理模式下，reasoning_content 必须回传给 API。
（2）mimo 无法识别压缩时 Hermes 所使用的 list 类型 model 参数。
因此重试三次均告失败后，系统发现压缩无法完成，Gateway 直接执行了 auto-reset，将整个对话历史清空，让你重新开始。
这下真相浮出水面。Agent 并非"遗忘"，而是被强制格式化了。
要弄明白这个问题，首先要了解 Hermes Agent 的上下文压缩机制是如何运作的。
简而言之，AI 的上下文窗口是有容量限制的。你与它交流得越频繁，消耗的 token 就越多。当 token 数量达到窗口的某个比例时，系统会自动触发"压缩"——让另一个模型将中间对话内容总结为摘要，用摘要替换原始消息，从而腾出空间继续交互。
问题就出在这里：负责生成摘要的模型和主对话模型都是 mimo，而 mimo 并不擅长做压缩摘要。
当压缩被触发时，Hermes 调用 mimo-v2.5 来生成摘要。但 mimo-v2.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）。如果你我志趣相投，就帮赏个免费的关注和赞呗。让我们共同打造互联网内容创作和知识分享的一股清流！ヾ(◍°∇°◍)ﾉﾞ