Ollama 本地模型记不住上一轮？Hermes Agent num_ctx 与 2048 上下文截断排错指南

你在 Hermes Agent 里接入 Ollama / 本地模型后，可能会遇到一个很诡异的问题：明明是在同一个 hermes chat 会话里，刚刚告诉它“我叫 Okynos / 小明”，下一轮问“我叫什么”，模型却回答“我不知道你的名字”。

很多人会把它理解成：

Hermes Agent 没有 memory；
Ollama provider 没传历史；
本地模型太笨；
或者 context_length 配置没有生效。

但 Hermes Agent issue #14420 里暴露出的一个关键场景是：Hermes 其实发送了完整历史，但 Ollama 因为 num_ctx 没有正确设置，回落到默认 2048 token，上游服务端静默截断了历史。

这篇文章针对这些搜索词：

Hermes Agent Ollama forgets previous context
Hermes Agent 同一会话记不住名字
Ollama num_ctx 2048 context truncated
Hermes Agent model.context_length not working
qwen3 Ollama Hermes context memory
ollama_num_ctx config Hermes

结论先放前面：如果你用 LAN IP / 自定义 OpenAI-compatible URL 接 Ollama，且模型在同一会话里记不住上一轮，优先检查 num_ctx，不要只改 context_length。

典型现象：同一会话里也像“失忆”

issue 中的复现非常典型：

User: Hello my name is Okynos could you save that?
Assistant: hello Okynos. I have received your name!

User: what's my name?
Assistant: I don't have access to your personal information like your name.

中文场景也类似：

User: 记住我叫小明
Assistant: 好的，我已经记下了您叫小明。

User: 我叫什么？
Assistant: 我是一个大型语言模型……

如果这是不同会话，还可能是没有 --resume；但 issue 中用户强调是同一个交互会话，Telegram 场景也复现。

这时就要看更底层的上下文窗口，而不是只盯着 memory tool。

这不是“长期记忆”和“当前上下文”的同一个问题

很多新用户会把这两个概念混在一起：

概念	作用	典型问题
当前 conversation history	同一会话内上一轮消息是否能被模型看到	“刚说完名字，下一轮就忘了”
memory tool / user profile	跨会话长期记忆	“明天重新打开还记不记得我”
session resume	重新进入某个历史会话	“是不是开了新 session”
Ollama `num_ctx`	Ollama 服务端实际保留多少 token	“Hermes 发了历史，但 Ollama 静默截断”

#14420 的关键不是长期记忆没写入，而是：同一会话的历史上下文在进入模型前被 Ollama 服务端截断了。

根因：Ollama 检测失败时回落到默认 2048 token

讨论里维护者给出的根因是：用户通过 LAN IP 连接 Ollama，例如：

model:
  provider: custom
  base_url: http://192.168.21.205:11434/v1
  context_length: 128000

Hermes 会尝试通过 Ollama 的 /api/show 之类路径检测模型上下文和 num_ctx。但在远程 LAN endpoint、延迟、路径兼容、模型元数据缺失等情况下，检测可能失败。

一旦检测失败，self._ollama_num_ctx 可能保持为 None。这时 Ollama 可能使用内置默认上下文窗口：2048 tokens。

问题是 Hermes Agent 的系统提示词本身就可能超过或接近这个窗口。结果就变成：

1. Hermes Agent 在客户端侧正常维护 conversation history； 2. 请求发给 Ollama OpenAI-compatible endpoint； 3. Ollama 实际只按 2048 token 分配上下文； 4. 历史消息在服务端被静默截断； 5. 模型只看到当前问题，看不到上一轮“我叫 Okynos”； 6. 用户以为 Hermes 没有传历史或 memory 坏了。

这类问题最坑的地方是：没有明显 HTTP 400 / 500 错误，模型只是表现得像失忆。

为什么只改 context_length 可能没用？

很多用户会在 Hermes config 里写：

model:
  context_length: 128000
  max_tokens: 128000

但 context_length 更像是 Hermes 侧的“我认为这个模型能处理多长上下文”。Ollama 真正分配 KV cache / 上下文窗口，还需要 num_ctx 生效。

如果 Hermes 没有把合适的 num_ctx 传给 Ollama，或者 Ollama 的 Modelfile 里固定了更小的 num_ctx，那么服务端仍可能按较小窗口截断。

issue 中的修复方向就是：

当 /api/show 检测失败时，如果用户设置了 model.context_length，用它作为 num_ctx fallback；
当 /api/show 返回的 Modelfile num_ctx 小于用户设置的 context_length，且没有显式 ollama_num_ctx override 时，把 num_ctx bump 到 context_length；
如果用户显式写了 model.ollama_num_ctx，则以这个显式值为准。

立即可用 workaround：显式设置 ollama_num_ctx

如果你现在就遇到这个问题，最实用的方案是直接在 Hermes 配置中加：

model:
  default: qwen3.5:9b
  provider: custom
  base_url: http://192.168.21.205:11434/v1
  context_length: 32768
  max_tokens: 32768
  ollama_num_ctx: 32768

重点是这一行：

ollama_num_ctx: 32768

它的作用是告诉 Hermes：请求 Ollama 时明确使用这个上下文窗口，不要依赖自动检测，也不要让 Ollama 回落到 2048。

32768、64000、128000 应该怎么选？

不要盲目写 128000。

上下文窗口越大，Ollama 需要的 KV cache / VRAM 越多。issue 中维护者提醒：对 qwen3.5:9b 这类 9B 级别模型，128K 上下文可能需要 20–24GB 甚至更多显存，不是所有消费级 GPU 都扛得住。

一个更现实的建议是：

显存/资源	建议起点
8GB 左右	8192 或 16384
12–16GB	16384 或 32768
24GB+	32768、64000，再逐步测试
CPU / 内存跑	从 8192 起，观察速度和内存

如果你写得太大，可能出现：

启动慢；
响应速度明显下降；
Ollama 静默 cap；
显存不足；
Hermes 初始化时报模型上下文不匹配。

所以建议先用 32768 验证“是否还会忘记上一轮”，再按硬件逐步提高。

如何判断是不是 num_ctx 截断？

可以按这个顺序排查。

1. 确认是不是同一个 session

先确认你不是每次都重新启动新会话。

如果你多次运行：

hermes chat

每次都可能是新 session。跨会话要用 resume 机制或平台会话映射。

但如果你在同一个交互窗口里连续问答仍然忘记，继续看 num_ctx。

2. 看 base_url 是否是 Ollama / LAN endpoint

高风险配置通常像这样：

base_url: http://192.168.x.x:11434/v1
provider: custom

也可能是：

base_url: http://localhost:11434/v1

本地 localhost 通常更容易被识别；远程 LAN IP 更容易遇到探测失败、路径兼容或超时。

3. 显式设置 ollama_num_ctx 后复测

把 ollama_num_ctx 加上后，重新启动 Hermes，再做最简单的测试：

User: 我的名字是 Okynos，请记住。
Assistant: 好的。
User: 我叫什么？

如果加了 ollama_num_ctx 后恢复正常，就基本坐实是上下文窗口被截断。

4. 看日志里是否出现 num_ctx 相关信息

如果你使用包含相关诊断的版本，可能会看到类似日志：

Ollama num_ctx: will request 32768 tokens
Ollama num_ctx bumped: 32768 -> 64000
Ollama num_ctx detection failed; using model.context_length=64000

这些日志可以帮助判断 Hermes 最终到底给 Ollama 请求了多大的上下文窗口。

PR #19613 的修复方向

与 #14420 相关的 PR #19613 标题是：

fix(ollama): fall back and bump num_ctx to model.context_length

它的核心逻辑有两部分：

1. Fallback 当 /api/show 检测失败，且用户显式设置了 model.context_length，Hermes 用 context_length 作为 num_ctx，避免 Ollama 默认 2048。

2. Bump 当 /api/show 成功，但返回的 Modelfile num_ctx 小于用户配置的 context_length，且用户没有显式 ollama_num_ctx，Hermes 将 num_ctx 提升到 context_length。

不过写作时需要注意：我查询到 #19613 仍显示为 open。因此对普通用户而言，文章更适合表述为：

问题根因已经明确；
PR 给出了修复方向；
在正式版本确认前，最稳的 workaround 是显式配置 ollama_num_ctx。

不要把它写成“所有版本已经完全修复”。

常见误区

误区 1：把它当成 memory tool 没开启

如果你问的是“上一轮我刚告诉你的名字”，这首先是 conversation history 问题，不是长期 memory 问题。

memory tool 解决的是更长期的信息保存；而当前会话上下文被 Ollama 截断时，memory 开了也不一定能救回来。

误区 2：认为模型太小就一定没救

小模型确实更容易不稳定，尤其是中文、多轮指令和工具调用。但如果它连上一轮名字都完全看不到，先检查是否被 2048 token 截断，不要直接归因给模型智商。

误区 3：把 max_tokens 当成上下文窗口

max_tokens 通常控制输出上限或生成预算，不等于输入上下文窗口。对 Ollama 来说，关键仍然是 num_ctx。

误区 4：盲目设置 128K

上下文不是越大越好。过大的 num_ctx 会占用大量显存/内存，也可能让系统变慢甚至失败。先让它足够大，能覆盖 Hermes 系统 prompt + 当前任务历史即可。

和 DeepAI API 中转站有什么关系？

DeepAI API 中转站适合解决的是多工具、多模型接入时的基础设施问题：

统一 OpenAI-compatible API Base URL；
统一 API Key 管理；
在 Cherry Studio、Cline、Dify、Open WebUI 等支持自定义 OpenAI Compatible API 的工具中集中接入模型；
降低不同模型供应商切换成本。

但要明确边界：如果你后端实际是 Ollama，并且服务端 num_ctx 只有 2048，那么中转站不能魔法般让 Ollama 看到被截断的历史。

正确做法是：

1. 在 Ollama / Hermes 侧正确设置 num_ctx； 2. 在需要统一入口的工具里使用 DeepAI 这类 OpenAI-compatible 基础设施； 3. 不把“API 中转”误认为“自动修复本地模型上下文窗口”。

FAQ

Hermes Agent 同一会话记不住上一轮，一定是 Ollama num_ctx 吗？

不一定。也可能是新 session、没有 resume、小模型跟随能力差、上下文压缩策略、provider adapter 问题。但如果你用 Ollama LAN endpoint，并且默认上下文看起来只有 2048，num_ctx 是最该优先排查的点。

我已经设置了 context_length，为什么还会忘？

因为 context_length 不一定等于 Ollama 实际使用的 num_ctx。你需要确认 Hermes 是否把 num_ctx 传给 Ollama，或者显式设置 ollama_num_ctx。

`ollama_num_ctx` 设置越大越好吗？

不是。越大越吃显存/内存，还会变慢。建议从 8192、16384、32768 逐步测试。

这个问题和 DeepSeek / Gemini hidden metadata 丢失一样吗？

不是。DeepSeek reasoning_content、Gemini thought_signature 是供应商协议字段丢失；Ollama 这个问题是上下文窗口太小导致历史被截断。它们都会表现成“模型不按预期理解历史”，但根因不同。

PR #19613 已经合并了吗？

我查询时 PR 仍显示 open。因此文章建议把它当作修复方向和参考，不要假设你当前安装版本已经包含它。最稳妥做法是先显式配置 ollama_num_ctx 并用新会话复测。

总结

Hermes Agent 接入 Ollama 后“同一会话记不住上一轮”，不一定是 memory tool 坏了，也不一定是模型完全不行。#14420 暴露出的关键路径是：Ollama /api/show 探测失败或 Modelfile num_ctx 过低时，服务端可能回落到 2048 token 或较小上下文，导致 Hermes 发送的历史在进入模型前被静默截断。

最实用的排查顺序：

1. 确认是否同一 session； 2. 确认是否 Ollama / LAN endpoint； 3. 显式设置 ollama_num_ctx，例如 32768； 4. 不要盲目写 128K，按显存逐步测试； 5. 关注 PR #19613 的修复方向，但在合并确认前以 workaround 为准。

如果你正在用 DeepAI API 中转站管理 OpenAI-compatible 工具链，也要把边界分清：中转站负责统一接入，Ollama 的实际上下文窗口仍要在 Ollama / Hermes 配置侧正确处理。