Kimi-k2.6 明明是 256K，Hermes 为什么按 32K 拒绝启动？

使用 Hermes Agent 接入大上下文模型时，启动阶段会先检查模型 context window。如果模型上下文低于 Hermes 的最低要求，Agent 会直接拒绝启动。这种检查本身是合理的：长任务、代码库检索、压缩记忆和多轮工具调用都需要足够长的上下文。

但 NousResearch/hermes-agent issue #23949 记录了一个更微妙的问题：kimi-k2.6 在 Ollama Cloud 上实际报告的是 262,144 tokens，也就是 256K context，Hermes 却把它识别成 32,768 tokens，并抛出低于 64K 最低要求的错误。

这不是一个简单的“模型太小”问题，而是模型元数据解析链路里，真实 API 返回值、默认 provider 规则、外部模型目录和兜底值之间没有对齐。

典型报错：32,768 tokens below the minimum 64,000

用户看到的启动错误类似：

ValueError: Model kimi-k2.6 has a context window of 32,768 tokens,
below the minimum 64,000 required by Hermes Agent.

另一个评论里，错误出现在辅助压缩模型上：

Auxiliary compression model kimi-k2.6 has a context window of 32,768 tokens,
which is below the minimum 64,000 required by Hermes Agent.

这两个错误指向同一个核心判断：Hermes 最终拿到的 context length 是 32768，而不是 Kimi k2.6 应有的 262144。

问题的迷惑点在于，多个地方都能看到 256K 的线索。

API 返回值：Ollama Cloud 报的是 262,144

issue 中列出的证据显示，Ollama Cloud 的 show endpoint 能返回模型信息：

GET https://ollama.com/api/show

响应中包含：

"model_info": {
  "kimi-k2.context_length": 262144
}

也就是说，服务端并不是完全没有提供 context length。

同时，Hermes 源码里的默认上下文映射也已有 Kimi 的默认值：

DEFAULT_CONTEXT_LENGTHS["kimi"] = 262144

如果只看这两点，很容易以为 Hermes 一定能识别出 256K。但最终报错显示，实际走到 run_agent.py 校验时，值已经变成了 32K。

为什么会掉到 32K？关键在 context length resolution chain

这类问题通常不是单点错误，而是解析链路中的某一步没有命中。

可以把启动前的模型上下文判断拆成几层：

用户配置 model id
        ↓
provider / server type detection
        ↓
provider-specific metadata query
        ↓
external model directory / built-in defaults
        ↓
fallback context length
        ↓
minimum context validation

#23949 的现象说明：

最终校验阶段拿到的是 fallback 或错误目录值，而不是 Ollama Cloud API 的 262144。

issue 作者的假设是：

detect_local_server_type() 可能没有把 https://ollama.com/v1 识别为 ollama；
或者远程 Ollama Cloud 场景没有调用 query_ollama_num_ctx()；
因此没有使用 /api/show 中的 kimi-k2.context_length；
最后落到 32,768 的兜底值。

评论后续补充了另一个关键线索：models.dev 中 kimi-k2.6 的名称格式不符合预期，修复 models.dev 的模型名称后，本地 Hermes + Ollama 场景开始恢复正常。

这说明问题可能不只在 Hermes 的 provider detection，还和外部模型元数据源的命名规范有关。

同一个模型名，可能经过多个“翻译层”

kimi-k2.6 这类模型名在不同系统里可能并不完全一致。

例如：

kimi-k2.6
kimi-k2
moonshot/kimi-k2.6
ollama.com/kimi-k2.6
provider-specific internal id
models.dev canonical id

如果其中某一层期待的是一种格式，而实际传入的是另一种格式，就可能发生：

模型可用，但元数据查不到；
模型能响应，但 context length 查错；
模型目录里有记录，但 key 没匹配上；
provider API 返回了正确值，但没有被优先采用。

这也是为什么用户会看到看似矛盾的情况：

Ollama Cloud API: 262144
Hermes error: 32768

两者不一定互相矛盾，可能只是 Hermes 最终没有走到那条正确的 metadata path。

临时绕过：显式写 context_length

issue 中给出的 workaround 是在配置里显式设置上下文长度：

model:
  context_length: 262144

如果错误出现在辅助压缩模型上，则对应配置应落到 auxiliary compression 的 context length，例如：

auxiliary:
  compression:
    context_length: 262144

具体键名以当前 Hermes 版本配置为准，但思路一样：

绕过自动检测，直接告诉 Hermes 这个模型可用的 context window。

这类 override 适合用于：

provider 元数据还没同步；
model catalog 命名刚变更；
新模型刚上线；
OpenAI-compatible endpoint 返回的模型列表缺少上下文信息；
远程 Ollama / Moonshot / Kimi provider 的模型名映射还不稳定。

修复方向：优先使用 provider 实时返回的 context length

从工程角度看，最稳的顺序通常是：

用户显式配置 > provider API 实时 metadata > 已知模型目录 > provider 默认值 > conservative fallback

对 kimi-k2.6 这类问题，修复重点包括：

1. 确认 https://ollama.com/v1 是否能被识别为 Ollama-compatible endpoint； 2. 确认是否调用了 Ollama /api/show 或等价 metadata endpoint； 3. 确认 model_info 里的 *.context_length 能被解析； 4. 确认 kimi-k2.6 和 catalog 里的 canonical model name 能匹配； 5. 确认外部 catalog 值不会覆盖 provider API 的真实返回值； 6. 保留用户 model.context_length override 作为最高优先级。

尤其是新模型上线时，模型目录经常落后于 provider API。此时 provider API 的实时返回值通常更可信。

为什么 Hermes 要设 64K 最低上下文？

Hermes Agent 这类 coding agent 不只是简单问答。

一次会话里可能包含：

系统提示词；
项目结构；
历史消息；
文件片段；
tool call 结果；
patch diff；
多轮错误日志；
memory / compression 摘要。

如果模型只有 32K context，很容易在复杂任务里提前触顶，导致记忆压缩频繁、工具结果被截断，甚至上下文污染。

所以 Hermes 做 64K minimum validation 是合理的。#23949 的问题不在最低要求，而在 kimi-k2.6 被错误识别成 32K。

排查清单：看到 32K context 误判时先看什么？

如果你遇到类似报错，可以按这个顺序查：

1. 确认模型真实 context

看 provider 是否提供 metadata endpoint，例如 Ollama 的 /api/show，是否有类似字段：

"context_length": 262144

或：

"kimi-k2.context_length": 262144

2. 确认 Hermes 实际使用的模型名

检查配置中的：

model:
  name: kimi-k2.6

以及辅助模型：

auxiliary:
  compression:
    model: kimi-k2.6

很多时候，主模型没问题，压缩模型或摘要模型先触发报错。

3. 检查 provider base URL

例如：

https://ollama.com/v1

这种远程兼容 endpoint 可能不完全等同于本地 Ollama server。检测逻辑如果只按 local server 假设写，就可能错过 provider-specific metadata 查询。

4. 临时写入 context_length

在修复或 catalog 同步前，可以显式设置：

model:
  context_length: 262144

如果是压缩模型报错，则给 compression model 设置对应 context length。

5. 检查外部模型目录是否已更新

评论里提到，models.dev 修复 kimi-k2.6 命名格式后，Ollama 场景恢复正常。这说明外部 catalog 的同步状态会影响 Hermes 的判断。

与 DeepAI API 中转站的关系：重点看模型元数据是否一致

很多用户会把 Hermes、Cherry Studio、Cline、Dify、Open WebUI 等工具接到 OpenAI-compatible API。此时最容易出问题的不是 chat completions 本身，而是模型元数据：

model id
context length
streaming support
tool calling capability
usage 字段
reasoning / thinking 字段

DeepAI API 中转站这类统一入口的价值在于把 Base URL、API Key、模型路由和多模型接入集中管理。对上层 Agent 来说，仍然要确认配置里的 model id、context length override、provider metadata 和工具侧最低上下文校验是否一致。

如果某个工具无法自动识别模型上下文，显式配置 context length 往往比反复切换 endpoint 更直接。

FAQ

为什么 Kimi-k2.6 明明是 256K，Hermes 还说只有 32K？

因为 Hermes 最终用于校验的 context length 可能来自兜底值或外部模型目录，而不是 provider API 返回的实时 262144。

`model.context_length: 262144` 是永久修复吗？

它是有效绕过方式，但更完整的修复应让 provider detection、metadata query 和模型目录命名都能正确识别 kimi-k2.6。

为什么辅助压缩模型也会报这个错？

Hermes 不只检查主模型，也会检查 compression / auxiliary model。若压缩模型配置为 kimi-k2.6，同样可能触发 32K 误判。

Ollama Cloud 和本地 Ollama 的检测逻辑一样吗？

不一定。远程 https://ollama.com/v1 虽然兼容接口，但 server type detection、metadata endpoint 和模型名格式可能与本地实例存在差异。

这个问题应该从哪里排查？

先看 provider API 返回的 context length，再看 Hermes 配置里的 model id 和 auxiliary model，最后检查是否需要显式设置 context_length。

总结

#23949 的关键不是 Kimi-k2.6 上下文不够，而是上下文长度解析链路没有把 256K 的真实信息传到 Hermes 的最低上下文校验处。

可以概括为：

Ollama Cloud API 报 262144；
Hermes 最终拿到 32768；
64K minimum validation 因此拒绝启动。

临时处理可以显式配置：

model:
  context_length: 262144

长期修复则应保证远程 Ollama provider、Kimi 模型命名、外部模型目录和 provider API metadata 的优先级一致。对 Agent 工具来说，模型“能调用”只是第一步；context length、tool calling、streaming 和 usage 元数据同样会影响能否稳定运行。